IBM® Integration Bus Healthcare
Pack se base sur IBM Integration Bus pour offrir une prise en charge pour les applications dans les environnements Healthcare.
IBM Integration Bus Healthcare
Pack fournit les fonctionnalités suivantes :
- Modèles de messages utilisés pour analyser, router et transformer des messages HL7 dans un flux de messages. Voir Modèles de message
- Noeud d'entrée et de sortie pour l'intégration des applications cliniques HL7 aux flux de messages. Voir Noeuds HL7
- Intégration aux périphériques médicaux pour vous permettre de capturer des données. Voir Intégration des périphériques médicaux
- Intégration aux systèmes PACS (Picture Archiving Communication Systems) DICOM ) and DICOM pour vous permettre de localiser, traiter et transférer les images DICOM en utilisant des flux de messages. Voir Intégration des images DICOM
- Modèles Healthcare permettant de générer des solutions pour la connexion d'applications médicales. Voir Modèles Healthcare
- Génération d'événements d'audit ATNA pour la prise en charge de la confidentialité des informations sur le patient, de l'intégrité des données et de la responsabilité des utilisateurs. Voir Evénements d'audit ATNA
- Possibilité d'extraire des informations à partir des données du système de santé dans des flux de messages et d'envoyer ces informations à des entrepôts de données à des fins d'analyse. Voir Analyse des données du système de santé
- Conversion des fichiers HIPAA en fichiers par le biais du modèle Healthcare : HIPAA en XML. Voir Modèles Healthcare
- Modèles permettant de créer des solutions d'intégration conformes aux profils d'intégration IHE (Integrating the Healthcare) PIX, PDQ et XDS ; voir Modèles Healthcare.
Le diagramme ci-dessous représente l'architecture de base d'une configuration de IBM Integration Bus Healthcare
Pack. Il indique comment IBM Integration Bus Healthcare
Pack peut se connecter à un grand nombre de systèmes de santé, parmi lesquels des périphériques médicaux, des applications cliniques, des passerelles de périphérique, des systèmes de facturation et des échanges d'informations relatives à la santé.
Pour plus d'informations sur HL7, voir Health
Level Seven International.
Modèles de message
IBM Integration Bus Healthcare Pack version
4.0 inclut deux modèles de messages pour le traitement des messages
HL7 :
- modèle de message DFDL
- ensemble de messages HL7v25P
- modèle de message DFDL
DFDL (Data Format Definition Language) est une description universelle, partageable et non normative des formats texte général et binaire utilisés dans IBM Integration Bus pour définir les modèles de messages. Pour plus d'informations sur l'utilisation de DFDL dans des modèles de messages, voir Modèles de message dans la documentation du produit IBM Integration Bus.
Remarque : L'
ensemble de messages HL7v25P, disponible dans
IBM WebSphere Message Broker Connectivity Pack for Healthcare version 7.0, est toujours pris en charge. Il est cependant recommandé d'utiliser si possible le
modèle de message DFDL pour les applications nouvelles et mises à jour car ce modèle présente les avantages ci-après.
- DFDL est un format standard ouvert tandis que le domaine MRM et l'ensemble de messages HL7v25P sont la propriété de IBM Integration Bus.
- Les outils de l'éditeur DFDL permettent de développer et de tester les extensions du schéma HL7
plus facilement qu'avec les outils MRM et l'ensemble de messages HL7v25P.
- Le modèle de message DFDL prend en charge HL7 versions 2.7, 2.6, 2.5.1
et les versions antérieures, tandis que MRM et
l'ensemble de messages HL7v25P ne prennent en charge que HL7 version 2.5.1 et les versions antérieures.
IBM Integration Bus Healthcare
Pack fournit trois versions du modèle de message DFDL, une pour HL7 version 2.7, une pour HL7 version 2.6 et une pour HL7 version 2.5.1 et antérieure. Chaque modèle de message DFDL inclut une définition d'un message HL7 générique. Ce dernier est utilisé avec l'analyseur DFDL dans le modèle dans le but de lire les messages provenant des applications cliniques source et d'écrire les messages vers les applications cliniques de destination. Ce message HL7 peut traiter n'importe quel segment valide défini dans HL7 versions 2.7, 2.6, 2.5.1 ou antérieure.
Remarque : Vous pouvez télécharger le
modèle de message DFDL à partir des ressources du modèle
Healthcare: HL7 to HL7 DFDL. Pour plus d'informations, voir
Intégration avec des applications HL7.
Remarque : Les modèles HL7 qui sont également disponibles dans
IBM WebSphere Message Broker Connectivity Pack for Healthcare version 7.0 (modèle Healthcare: HL7 to HL7,
modèle et modèle
Healthcare: Medical Devices to EMR) utilisent l'ensemble de messages HL7v25P. Toutefois, l'utilisation du modèle de message DFDL a été introduite dans IBM WebSphere Message Broker Connectivity Pack for Healthcare version 8.0, dans le modèle Healthcare: HL7 to HL7 DFDL. Le modèle de message DFDL est utilisé dans les modèles qui ont été ajoutés dans IBM Integration Bus Healthcare
Pack version 3.0 (modèles Healthcare : Transformation HL7 et Healthcare : Home Health.)
- ensemble de messages HL7v25P
L'ensemble de messages HL7v25P inclut une définition du message HL7 générique. Ce dernier est utilisé, avec l'analyseur MRM dans le modèle, pour lire les messages provenant des applications cliniques source et écrire les messages vers les applications cliniques de destination. Ce message HL7 peut traiter n'importe quel segment valide défini dans HL7 version 2.5.1 ou antérieure.
Bien qu'il soit recommandé d'utiliser le modèle de message DFDL à la place de l'ensemble de messages HL7v25P, il est préférable dans certains cas d'utiliser ce dernier. Par exemple, si vous convertissez des données HL7 v2 non standard XML en représentation XML par le biais de l'ensemble de messages HL7v25P, il n'est pas nécessaire de renommer les éléments de l'arborescence de messages.
Remarque : Vous pouvez télécharger l'
ensemble de messages HL7v25P à partir des ressources du modèle
Healthcare: HL7 to HL7. Pour plus d'informations, voir
Intégration avec des applications HL7.
Les applications cliniques peuvent également communiquer des informations non standard par le biais de segments Z dans des messages HL7.
Lorsque vous utilisez ce type de message avec les modèles, vous pouvez ajouter des segments Z non standard supplémentaires au message HL7 afin de prendre en charge ces segments Z propres au site.
Lorsqu'un message HL7 est lu dans une instance de modèle, vous pouvez également utiliser le modèle de message choisi pour sortir la forme canonique (format XML) qui est générée après le premier point de personnalisation. La forme canonique sortie par le modèle n'est pas un format XML HL7, mais vous pouvez l'utiliser pour contenir une représentation de vos données indépendantes de la plateforme. Ces données peuvent être conformes à n'importe quel format de date et heure normalisé ou format de nombre, ou à toute autre exigence normative imposée.
Les modèles de message peuvent également traiter les messages HL7 ayant un type et un code d'événement spécifique. Si vous voulez implémenter des applications de flux de messages qui traitent un message pour un chapitre HL7 spécifique, les messages doivent être lus et écrits en utilisant le type de message approprié provenant des définitions de chapitre dans le modèle de message.
HL7 divise tous ses messages en groupes appelés chapitres qui correspondent aux chapitres à la norme HL7. Lorsque vous utilisez des messages HL7 spécifiques à partir du modèle de message, il est possible de sortir les messages au format HL7 ou au format XML HL7. L'utilisation de ces formats simplifie également l'utilisation du mappage graphique dans la transformation d'un message entre les messages source et de destination.
Pour plus d'informations sur HL7, voir Health
Level Seven International.
Noeuds HL7
Si vous utilisez le
modèle de message DFDL, les noeuds
HL7 suivants sont fournis pour être utilisés dans les flux de messages dans le but d'envoyer et de recevoir des messages
HL7 :
- Le noeud HL7DFDLInput que vous pouvez utiliser dans un flux de messages pour recevoir les messages HL7 à traiter dans le flux de messages et pour déterminer si un message est un doublon.
- Le noeud HL7DFDLOutput que vous pouvez utiliser pour transmettre des messages HL7 à une destination via MLLP et pour vérifier qu'un accusé de réception valide est reçu.
Pour plus d'informations sur ces noeuds
HL7, voir
Noeud HL7DFDLInput et
Noeud HL7DFDLOutput.
Si vous utilisez l'ensemble de messages HL7v25P, les noeuds HL7 suivants sont fournis pour être utilisés dans les flux de messages dans le but d'envoyer et de recevoir des messages
HL7 :
- Le noeud GenericHL7Input que vous pouvez utiliser dans un flux de messages pour recevoir les messages HL7 à traiter dans le flux de messages et pour déterminer si un message est un doublon.
- Le noeud GenericHL7Output que vous pouvez utiliser pour transmettre des messages HL7 à une destination via MLLP et pour vérifier qu'un accusé de réception valide est reçu.
Pour plus d'informations sur ces noeuds
HL7, voir
Noeud GenericHL7Input et
Noeud GenericHL7Output.
Intégration des périphériques médicaux
IBM Integration Bus Healthcare
Pack inclut un noeud d'entrée, le noeud MedicalDeviceInput, qui autorise la transmission des informations provenant des périphériques médicaux connectés dans un flux de messages. A l'aide de ce noeud, vous pouvez développer des flux de messages dans le but d'envoyer les données des périphériques médicaux à d'autres systèmes, comme un entrepôt de données ou la station de surveillance d'une infirmière.
Chaque périphérique est connecté à un port de communication séparé (série ou réseau local), et des pilotes de périphérique dans le noeud MedicalDeviceInput sont configurés pour écouter sur ces ports de communication. La configuration du noeud identifie les périphériques connectés et les mesures requises à partir de chaque périphérique.
Le diagramme affiche le flux de données depuis les dispositifs cliniques de chaque lit 1, lit 2 et lit N vers les pilotes de périphérique. Par exemple, depuis les moniteurs de fréquence cardiaque vers le pilote 1 et depuis les pompes à perfusion via un serveur d'intégration vers le pilote 2. Le flux atteint ensuite le noeud MedicalDeviceInput qui envoie les données et le statut au reste du flux.
- Configuration du noeud MedicalDeviceInput
Le flux de données provenant des flux de messages ne doit pas être perturbé lorsque les configurations de périphérique sont mises à jour. Par exemple, lorsque vous modifiez les mesures requises ou les connexions physiques lorsque des périphériques sont ajoutés, déconnectés ou déplacés. Les données de configuration sont ainsi conservées en tant que service configurable afin que les modifications de configuration puissent être implémentées par le noeud sans qu'il soit nécessaire d'arrêter ou de redéployer le flux de messages qui reçoit les données médicales.
Le noeud MedicalDeviceInput est configuré par le biais de l'onglet Propriétés qui démarre un éditeur pour le service configurable. Dans l'éditeur Service configurable de périphérique médical, un administrateur sélectionne d'abord le type de service dans la liste des périphériques pris en charge, puis le type de communication (série ou réseau local) et fournit les informations de communication appropriées.
- Ensembles de mesures
Il arrive fréquemment qu'un certain nombre de périphériques du même type doivent fournir les mêmes types de mesures selon le même intervalle, par exemple, la fréquence cardiaque, la température du sang et la fréquence respiratoire toutes les 5 minutes. Cette exigence peut être remplie par un certain nombre de périphériques déployés sur tous les lits d'une salle hospitalière. L'éditeur Service configurable de périphérique médical prend donc en charge la configuration des ensembles de mesures qui indique un certain nombre de mesures et peut être appliquée à un nombre quelconque de périphériques.
Lorsque l'administrateur configure un ensemble de mesures, il sélectionne un type de périphérique et obtient une liste des mesures prises en charge par ce dernier. Il peut sélectionner les mesures requises et pour chacune d'elles, indiquer l'intervalle selon lequel elles sont transmises dans le flux de messages à des fins de traitement.
Lorsqu'un grand nombre de périphériques et de mesures doivent être configurés, le volume des données de configuration peut être important. Pour plus de clarté, l'administrateur peut alors fournir une description de l'emplacement de chaque périphérique, des informations sur l'ID du patient, des notes et des étiquettes pour chaque périphérique et ensemble de mesures.
- Utilisation du noeud MedicalDeviceInput dans les flux de messages
Les données qui transitent par le noeud MedicalDeviceInput peuvent être traitées par un flux de messages à l'aide de n'importe quel noeud disponible dans IBM Integration Bus. Les données de mesure sont transmises dans le flux de messages en tant qu'arborescence de messages logique. L'arborescence de messages utilise le domaine DataObject et possède le format de sérialisation XML (le message est sérialisé au format XML s'il est écrit dans une file d'attente de messages). Ces données peuvent être filtrées, transformées, agrégées et routées par le biais de fonctionnalités IBM Integration Bus standard avant d'être écrites vers des noeuds finaux cible, comme des bases de données, des files d'attente IBM WebSphere MQ ou des appels de service.
Pour plus d'informations sur l'utilisation du noeud MedicalDeviceInput, voir Utilisation des données provenant des périphériques médicaux dans les flux de messages et Noeud MedicalDeviceInput.
Intégration des images DICOM
DICOM (Digital Imaging and Communications in Medicine) est une norme de traitement, de stockage, d'impression et de transmission des informations sous forme d'image médicale. Ces informations peuvent inclure des images DICOM et des rapports structurés (SR) DICOM.
Vous pouvez utiliser IBM Integration Bus Healthcare
Pack pour connecter des systèmes PACS (Picture Archiving Communication Systems) DICOM et d'autres modalités DICOM à des flux de messages pour autoriser la localisation, le traitement et le routage des images DICOM au sein d'un système de santé.
La fonctionnalité
DICOM fournie par
IBM Integration Bus Healthcare
Pack prend en charge un certain nombre de scénarios clés.
- Collecte des études pour l'admission d'un patient
- Lorsqu'un patient est admis à l'hôpital, vous pouvez demander aux systèmes PACS DICOM situés sur un ou plusieurs sites de rechercher et de récupérer les études relatives au patient. Les images médicales pertinentes sont alors immédiatement mises à la disposition du personnel soignant qui traite le patient. Pour plus d'informations sur ce scénario, voir Collecte des études pour l'admission d'un patient.
- Deuxième avis ou consultation d'un spécialiste
- Sur les sites où les compétences en matière de radiologie sont réduites, vous pouvez router les images DICOM (à des fins de diagnostic ou de recherche) à des spécialistes dans d'autres hôpitaux au sein d'un système de santé. Pour plus d'informations sur ce scénario, voir Deuxième avis ou consultation d'un spécialiste.
- Portail clinique
- Vous pouvez utiliser une application Web pour afficher les informations détaillées des études DICOM relatives à un patient. Dans ce scénario, seuls les attributs de l'étude (et non les données d'image) sont présentés, comme la modalité et la date et heure de l'étude. Pour plus d'informations sur ce scénario, voir Portail clinique. Ce scénario est également implémenté dans le modèle Healthcare: Web Service to DICOM dans IBM Integration Bus Healthcare
Pack.
IBM Integration Bus Healthcare
Pack inclut trois noeuds.
- Le noeud DICOMInput que vous pouvez utiliser pour recevoir des images DICOM provenant d'un noeud SCU (Service Class User) DICOM, comme par exemple une modalité DICOM. A l'aide de ce noeud, vous pouvez extraire des données d'une image DICOM dans le but de les utiliser dans un flux de messages. Ce noeud prend en charge les demandes C-STORE DICOM.
- Le noeud DICOMOutput que vous pouvez utiliser pour envoyer des images DICOM à un noeud SCP (Service Class Provider) DICOM, comme par exemple un système PACS (Picture Archiving Communication System) DICOM. A l'aide de ce noeud, vous pouvez combiner les métadonnées d'un flux de messages à une image DICOM et envoyer le résultat à une destination externe. Ce noeud prend en charge les demandes C-STORE DICOM.
- Le noeud DICOMFindMove que vous pouvez utiliser pour interroger une source externe sur des images DICOM correspondant à des critères donnés et le cas échéant transférer ces images vers une autre destination.
Ce noeud prend en charge les demandes C-FIND et C-MOVE DICOM.
Remarque : La fonctionnalité DICOM fournie par IBM Integration Bus Healthcare
Pack ne prend pas en charge les demandes C-GET DICOM.
Pour plus d'informations sur l'utilisation des noeuds
DICOM dans le flux de messages, voir
Utilisation des données provenant des images DICOM dans les flux de messages.
Modèles Healthcare
IBM Integration Bus Healthcare
Pack inclut les modèles suivants :
- Modèle Healthcare : HIPAA en XML
- Le modèle Healthcare : HIPAA en XML crée un flux de messages que vous pouvez utiliser pour convertir les fichiers HIPAA en fichiers XML.
- Modèle Healthcare : Home Health
- Le modèle Healthcare : Home Health facilite le transfert les données qui sont enregistrées sur des périphériques Home Health, comme des échelles, vers l'application clinique demandeuse. Les périphériques Home Health envoient les données relatives aux relevés des patients à un périphérique hébergeant des applications (AHD). Ce dernier envoie les données via un réseau longue distance à l'application demandeuse.
- Modèle Healthcare: HL7 to HL7
- Le modèle Healthcare : Transformation HL7 génère des mappes de données graphiques que vous pouvez utiliser pour assembler des messages HL7.
- Modèle Healthcare: HL7 to HL7 DFDL
Remarque : Une autre version de ce modèle est disponible (le modèle
Healthcare: HL7 to HL7). Il est cependant recommandé d'utiliser si possible le modèle
Healthcare: HL7 to HL7 DFDL pour les applications nouvelles et mises à jour car ce dernier utilise le
modèle de message DFDL à la place de
MRM et de l'
ensemble de messages HL7v25P. Le
modèle de message DFDL présente les avantages ci-après.
- DFDL est un format standard ouvert tandis que le domaine MRM et l'ensemble de messages HL7v25P sont la propriété de IBM Integration Bus.
- Les outils de l'éditeur DFDL permettent de développer et de tester les extensions du schéma HL7
plus facilement qu'avec les outils MRM et l'ensemble de messages HL7v25P.
- Le modèle de message DFDL prend en charge HL7 versions 2.7, 2.6, 2.5.1
et les versions antérieures, tandis que MRM et
l'ensemble de messages HL7v25P ne prennent en charge que HL7 version 2.5.1 et les versions antérieures.
Le modèle Healthcare: HL7 to HL7 DFDL assure la médiation entre les applications cliniques qui utilisent la norme HL7 v2 pour les messages. Par exemple, il se peut qu'un système PAS (Patient Administration System) émette un message unique distribué à une ou plusieurs applications cliniques qui requièrent des informations sur le patient.
Le modèle n'est pas contraint de traiter des messages ayant un type (ADT par exemple) et un code (A01 par exemple) HL7 unique, mais il peut recevoir et traiter n'importe quel message possédant un type et un code valides. Les applications doivent être capables d'envoyer et de recevoir les messages par le biais de MLLP via TCP/IP.
Le modèle contient trois flux de messages différents (si vous choisissez plusieurs destinations, vous obtenez des flux de messages supplémentaires) et inclut des sous-flux personnalisables.
- Modèle Healthcare: Medical Devices to EMR
- Le modèle Healthcare: Medical Devices to EMR intègre des périphériques médicaux à une application de dossier médical électronique (EMR - Electronic Medical Record) qui peut recevoir des messages de résultat d'observation HL7 v2 (ORU R01). L'application doit être capable de recevoir des messages HL7
ORU R01 par le biais de MLLP via TCP/IP. Le modèle inclut des sous-flux personnalisables.
- Modèle Healthcare: Web Service to DICOM
- Le modèle Healthcare: Web Service to DICOM intègre une application écrite par le biais des services Web aux applications DICOM qui prennent en charge les opérations C-FIND et C-MOVE. Vous pouvez utiliser le modèle pour interroger un système PACS DICOM sur des patients, des études, des séries et des images par le biais d'un service Web implémenté par IBM Integration Bus.
- Modèle Healthcare : Patient Identifier Cross-reference Manager
- Le modèle Healthcare : Patient Identifier Cross-reference Manager permet d'utiliser IBM InfoSphere Master Data Management pour créer un gestionnaire
PIX (Patient Identifier Cross-reference Manager - Gestionnaire de concordance des identificateurs de patient) pouvant être utilisé dans le profil IHE
(Integrating the Healthcare Enterprise) PIX. Vous pouvez ensuite connecter les applications cliniques au modèle de sorte qu'elles agissent en tant qu'acteurs Emetteur d'identités de patient et Consommateur PIX, comme indiqué dans le profil PIX.
- Modèle Healthcare : Patient Demographics Query Supplier
- Le modèle Healthcare : Patient Demographics Query Supplier permet d'utiliser IBM InfoSphere Master Data Management pour créer un fournisseur
d'informations démographiques sur le patient pouvant être utilisé dans le profil IHE (Integrating
the Healthcare Enterprise) PDQ (Patient Demographics Query). Vous pouvez ensuite connecter vos applications cliniques au modèle de sorte qu'elles agissent
en tant qu'acteurs Consommateur d'informations démographiques sur le patient, comme défini dans le profil PDQ.
- Modèle Healthcare : Cross-Enterprise Document Sharing Consumer
- Utilisez le modèle Healthcare : Cross-Enterprise Document Sharing Consumer pour rechercher des identificateurs uniques universels (UUID) de document
stockés dans un registre XDS, puis pour utiliser l'identificateur unique universel afin d'extraire les documents associés du répertoire XDS. Pour plus
d'informations, voir le modèle Healthcare :
Cross-Enterprise Document Sharing Consumer.
- Modèle Healthcare : FHIR Transformation
- Utilisez le modèle Healthcare : FHIR Transformation pour transformer des ressources HL7 FHIR du format XML au format JSON et
inversement. Pour plus d'informations, voir le modèle Healthcare :
FHIR Transformation.
Pour plus d'informations sur les modèles, voir Développement de solutions d'intégration Healthcare en utilisant les modèles fournis dans IBM Integration Bus Healthcare Pack.
Evénements d'audit ATNA
Le profil d'intégration ATNA (Audit Trail and Node Authentication) couvre plusieurs aspects de la sécurité, y compris les standards et les processus pour le routage et le stockage sécurisés des messages d'événement d'audit dans un référentiel. A l'aide d'un noeud ATNAAudit, vous pouvez générer des messages d'événement d'audit ATNA à partir des données du système de santé routées via des flux de messages et envoyer ces messages d'événement d'audit à un référentiel d'audit ATNA spécifié.
Pour plus d'informations sur l'audit des données dans les flux de messages, voir Audit des données provenant des flux de messages.
Analyse des données du système de santé
Vous pouvez utiliser la perspective d'analyse des données
IBM Integration Bus avec un profil d'analyse des données fourni par
IBM Integration Bus Healthcare
Pack pour analyser et filtrer les données du système de santé dans les flux de messages. Les données du système de santé sont souvent acheminées dans des documents et messages complexes qui ne sont pas traités aisément par des applications en aval. A l'aide d'un projet d'analyse des données, vous pouvez analyser les données du système de santé, extraire les éléments clés et créer une structure de messages simplifiée pouvant être mappée directement dans les tables de base de données utilisées par des outils d'intelligence métier.
IBM Integration Bus Healthcare
Pack fournit des profils d'analyse des données. Chaque profil est utilisé pour un type spécifique de données du système de santé.
- Le profil HL7 v2 (ORU) est utilisé pour analyser les données de message ORU (Observation Result)
- Le profil HL7 CDA est utilisé pour analyser les documents CDA (Clinical Document Architecture)
- Le profil HL7 v2 est utilisé pour analyser d'autres données HL7
- Le profil DICOM est utilisé pour analyser des données DICOM
Pour plus d'informations sur l'analyse des données du système de santé, voir Analyse des données du système de santé dans les flux de messages.