Planification de votre solution
Cette section fournit des informations sur ce que vous devez prendre en compte lors de la planification de votre solution Accélérateur Microsoft BizTalk pour HL7 (BTAHL7).
Vous pouvez implémenter BTAHL7 des manières suivantes :
Projet greenfield. Ce scénario est une nouvelle installation de BTAHL7.
Projet de migration. Ce scénario se produit lorsque le organization de soins de santé supprime progressivement un répartiteur d’intégration existant. Le organization migre vers BTAHL7.
Coexistence. Ce scénario implique une installation de BTAHL7 côte à côte avec un autre moteur d’intégration.
Incorporé. Ce scénario implique l’intégration de BTAHL7 dans une application métier. Vous utilisez BTAHL7 pour ajouter des fonctionnalités de messagerie HL7 à cette application.
Personnes ont tendance à sous-estimer la quantité d’efforts nécessaires pour gérer les applications au fil du temps par rapport au travail nécessaire pour les créer en premier lieu. Cela est particulièrement vrai lorsque l’on examine les grandes institutions distribuées qui doivent effectuer un éventail complexe de tâches de traitement et de gestion des données. Les hôpitaux ou les organismes de prestation de services de santé intégrés en sont d’excellents exemples. Ces institutions sont confrontées à la nécessité de fournir des logiciels pour prendre en charge une myriade de fonctions, de permettre la transmission des informations d’une application à l’autre afin d’éviter la nécessité d’une saisie de données en double et défectueuse, de fournir une formation aux utilisateurs et aux responsables de la maintenance du logiciel, et de prévoir le remplacement d’applications obsolètes ou obsolètes par des applications améliorées. Ce processus de remplacement a ses propres exigences pour les tests et l’éducation.
Il serait impossible (d’un coût prohibitif) pour ces institutions de gérer toutes leurs fonctions avec une seule application intégrée. En premier lieu, les institutions ne veulent pas lier leur fortune à un seul fournisseur, et ne trouveront pas toute la fonction dont elles ont besoin par le biais d’un seul fournisseur. En deuxième lieu, les simples besoins opérationnels du traitement institutionnel empêchent les institutions d’être satisfaites d’une seule application intégrée. Par conséquent, les institutions prendront en charge leurs besoins avec plusieurs applications. Pour que ces applications interagissent, les applications ont besoin d’interfaces pour échanger des informations. Le nombre d’applications et d’interfaces impliquées est souvent assez important. Compte tenu de cette architecture d’application distribuée, le moteur d’interface est un instrument clé pour gérer le traitement des données pour les institutions au fil du temps. Les principaux problèmes sont la migration, la cartographie et l’éducation. Le travail de BTAHL7 est de faire en sorte que le traitement de ces problèmes soit aussi simple et efficace que possible :
Mappage. La tâche la plus importante dans l’implémentation d’interface consiste à créer le mappage entre les structures d’application/base de données et les structures de données utilisées dans l’interface. Tout ce que l’outil fait pour rendre cela facile et naturel est bon. En outre, étant donné que le document de mappage deviendra une spécification utilisée par les développeurs d’interface et d’application, il est important de pouvoir générer facilement la documentation de celui-ci. Vous utilisez les Explorer de configuration BTAHL7, Microsoft Visual Studio et les outils BizTalk Server pour développer et implémenter ces cartes.
Migration. Vous devez maintenir l’interopérabilité des applications au fil du temps à mesure que les applications changent. Si vous considérez les problèmes liés au remplacement d’une application unique, il est nécessaire de mettre à jour les mappages de source de données vers les interfaces applicables. Avec un moteur d’interface, il ne doit y en avoir qu’un seul. Vous devez déterminer où les interfaces ont été installées et si les normes d’interface ont changé au fil du temps. Vous constaterez qu’au fil du temps, les normes d’interface changent et doivent être migrées vers les normes courantes. Il est recommandé que votre plan de migration prenne en compte toute modification future de l’interface. Vous devez mapper entre les normes et entre les différentes versions de la norme. En outre, dans les limites d’une seule norme, en particulier d’une norme flexible telle que HL7 V2, vous devez gérer (sur de nombreuses applications) plusieurs implémentations d’une même norme. Le moteur d’interface doit gérer cette complexité de manière à ce qu’elle soit facile à gérer.
Une tâche de migration clé consiste à migrer un corps d’interfaces d’une norme vers une autre. Ici, la tâche consiste à migrer tous les mappages qui utilisent l’ancienne version vers la nouvelle, en prenant en compte la localisation et les extensions spécifiques de l’interface de compte, ce qui peut être un processus complexe. L’outil doit fournir une assistance pour cette migration.
Vous utilisez l’onglet Validation de la configuration Explorer BTAHL7 pour spécifier l’espace de noms d’un schéma de type de message supplémentaire.
Formation. Les personnes impliquées dans la gestion et la prise en charge des applications changeront au fil du temps. En outre, étant donné que les interfaces sont au cœur des fonctionnalités d’interopérabilité de la collection d’applications, leur documentation sera des outils clés dans la gestion de l’entreprise globale. Pour ces deux raisons, il est utile de fournir une documentation facile à utiliser et facile à gérer sur a) les spécifications de l’interface, b) les mappages d’application et d’introversion, et c) la justification des activités de personnalisation et de localisation.