Intégration · HL7 v2
Du HL7 v2 aux mises à jour des patients, sans lire un seul résultat
EDFlow transforme les messages ADT, de demandes et d'état des résultats que votre moteur d'intégration achemine déjà en un flux d'événements normalisé et signé. La correspondance est publiée, les tables d'état des résultats sont explicites, et les valeurs des résultats ne sont jamais lues.
En bref
Déclencheurs ADT
Arrivée A04 et A01, mises à jour A08, transferts A02, départ A03, annulations A11 et A13, fusions A40.
Demandes et état des résultats
Nouvelles demandes et changements d'état ORM, OMG, OML et OMI; état ORU selon OBR-25 et OBR-22.
Canal de référence
Un canal de référence, des données synthétiques et un script de conformité qui rejoue votre trafic de test.
Déclencheurs
| Message | Événements |
|---|---|
| ADT^A04 / A01 (visite à l'urgence) | Arrivée; triage si une observation ÉTG est présente; équipe soignante si PV1-7 ou ROL est présent |
| Mise à jour ADT^A08 | Emplacement, équipe soignante, triage et mises à jour du patient, chacun seulement si son segment est présent |
| Transfert ADT^A02 | Changement d'emplacement; départ (admis) si le nouvel emplacement est une unité d'hospitalisation |
| Congé ADT^A03 | Décision et départ |
| ADT^A11 / A13 | Visite annulée ou départ sans avoir été vu; annulation du congé |
| ORM^O01, OMG^O19, OML^O21, OMI^O23 | Demande faite; changements d'état; annulations; consultations et demandes de jeûne |
| ORU^R01 | État de la demande selon OBR-25 et OBR-22 seulement; segments OBX ignorés |
| SIU^S12 à S15 | Heure prévue d'une demande liée |
Correspondance de l'état des résultats
| OBR-25 | Sens | État affiché |
|---|---|---|
| O | Demande reçue | Demandé |
| S | Planifié | Prévu |
| I | Échantillon reçu, incomplet | Au laboratoire / examen en cours |
| R | Enregistré, non vérifié | Au laboratoire / en lecture |
| A, P | Résultats partiels ou préliminaires | En finalisation |
| F | Final | Arrivé |
| C | Corrigé | Arrivé (corrigé) |
| X | Annulé | Annulé |
« Arrivé » signifie qu'un résultat existe. Les patients ne voient jamais ce qu'il dit, et un résultat arrivé n'est jamais présenté comme une bonne nouvelle : l'équipe soignante explique les résultats en personne.
Le canal de référence du moteur
- Source : copier les flux ADT, de demandes et de résultats existants plutôt que de bâtir de nouvelles interfaces au DME.
- Filtre : garder les visites à l'urgence (PV1-2 = E) et les emplacements du service; retirer tout le reste au moteur.
- Transformation : bâtir les événements normalisés, retirer tout champ que le contrat ne nomme pas, calculer des identifiants stables.
- Destination : un expéditeur HTTP qui signe chaque lot, avec une file de reprise par flux pour garder l'ordre.
- Tâches planifiées : un signal de vie toutes les 60 secondes et la liste des patients présents toutes les 15 minutes; le recensement actuel envoyé à la mise en service.
Les correspondances suivent les cartes de concepts du guide de mise en œuvre HL7 Version 2 vers FHIR lorsqu'elles s'appliquent, pour que les sites HL7 v2 et FHIR obtiennent le même sens.[1]
Documentation technique
- Adaptateur HL7 v2L'adaptateur HL7 v2 : versions et déclencheurs pris en charge par fournisseur, correspondances de champs et tables d'état.
- Configuration du moteurConfiguration « stocker et transmettre » pour Mirth Connect, Rhapsody, Cloverleaf et d'autres moteurs, avec des extraits de signature.
- Contrat d'événementsLe contrat d'événements normalisé : enveloppe, les 23 types d'événements, champs interdits, idempotence et ordre.
Questions fréquentes
Acceptez-vous le MLLP directement?
Non. Les hôpitaux gardent le MLLP dans leur propre réseau. Le moteur reçoit les messages, les transforme et les signe, puis envoie les événements par HTTPS. Il accuse réception au DME comme d'habitude; notre destination est une file asynchrone.
Lisez-vous les valeurs des segments OBX?
Non. Les segments OBX sont ignorés et jamais analysés pour leurs valeurs. Seuls l'état de la demande (OBR-25 ou ORC-5) et son heure sont utilisés.
À lire aussi
- IntégrationIntégration FHIR R4 pour l'état de l'urgenceComment EDFlow utilise FHIR R4 pour l'état de l'urgence : correspondances d'Encounter, ServiceRequest, Specimen, ImagingStudy et de l'état du DiagnosticReport, Subscriptions Backport, services d'arrière-plan SMART et pourquoi HL7 v2 reste le flux du recensement.
- IntégrationIntégration Epic pour l'état des patients de l'urgence en temps réelComment EDFlow s'intègre à Epic pour l'état de l'urgence en temps réel : HL7 v2 ADT, demandes et état des résultats par Bridges et le moteur d'intégration, enrichissement FHIR R4, lancement SMART on FHIR et ce qu'il faut confirmer avec votre équipe Epic.
- ArticleIntégrer Epic et Oracle Health pour l'état de l'urgence en temps réelGuide pratique de l'état de l'urgence en temps réel depuis Epic et Oracle Health : HL7 v2 par le moteur d'intégration, la place de FHIR, la minimisation et l'exécution parallèle.
Nous joindre
Voyez-le avec votre propre service d'urgence en tête
Nous parcourons les vues du patient, des proches et du personnel avec des données fictives, puis nous les arrimons à votre DME, à vos façons de faire et à ce qu'un projet pilote devrait démontrer.
Sources
- [1]HL7 Version 2 to FHIR Implementation Guide (s'ouvre dans un nouvel onglet) · HL7 International