Intégration
Fonctionne avec le DME que vous utilisez déjà
EDFlow fonctionne avec les flux HL7 v2 que chaque hôpital possède déjà. Votre moteur d'intégration transforme les messages d'admission, de demandes d'examen et d'état des résultats en un petit flux d'événements signé, dans votre réseau, pour que seul le minimum nécessaire quitte l'hôpital. FHIR R4 est pris en charge, et une console du personnel couvre chaque étape en l'absence de flux.
En bref
HL7 v2 d'abord
Les messages d'admission, de demandes et d'état des résultats que vous produisez déjà, copiés par votre moteur. Aucune inscription à une boutique d'applications pour commencer.
Minimisé à la source
Le moteur retire tout champ que le contrat ne nomme pas. Nous refusons aussi les données qui contiennent des valeurs de résultats, des notes ou des numéros de carte santé.
Signé et idempotent
Signatures HMAC-SHA256, fenêtre anti-rejeu de 5 minutes, identifiants d'événements idempotents et livraison hors ordre sans risque.
Solution de repli manuelle
La console du personnel fait avancer chaque étape par le même pipeline : en service dès le premier jour, et toujours fonctionnelle quand un flux tombe.
Comment fonctionne le flux
Le flux principal est HL7 v2, par le moteur d'intégration de l'hôpital. Les messages d'admission (ADT), de demandes d'examen et d'état des résultats sont en temps réel, tous les grands DME les produisent, et l'hôpital possède et exploite déjà ces interfaces. Le moteur les traduit, dans le réseau de l'hôpital, en un petit vocabulaire de 23 types d'événements normalisés, les signe et les envoie à EDFlow par HTTPS.
| Voie | Quand l'utiliser | Minimisation des données |
|---|---|---|
| Événements normalisés (à privilégier) | Le moteur transforme lui-même le HL7 v2 ou le FHIR en événements | La meilleure : seuls les champs nommés quittent l'hôpital |
| Adaptateur FHIR | Le site exploite un relais FHIR ou préfère les ressources FHIR | Bonne : transformées aussitôt, ressources brutes jamais conservées |
| Adaptateur HL7 v2 | Transitoire : bac à sable ou début de projet pilote | La plus faible : messages complets transmis, analysés en mémoire et jamais conservés |
| Console du personnel | Toujours offerte; seule voie sans flux | Le personnel saisit seulement ce que l'écran demande |
Des principes que votre équipe d'interfaces reconnaîtra
- Sortant seulement. Le moteur se connecte vers l'extérieur sur le port 443 avec TLS 1.2 ou plus récent. Aucune règle entrante dans le pare-feu.
- Signé. Chaque lot porte une signature HMAC-SHA256 calculée sur l'horodatage, un identifiant de livraison et le contenu, avec des clés par source qui changent avec une période de chevauchement.
- Protégé contre le rejeu. Les horodatages doivent être à moins de 5 minutes, et un identifiant de livraison ne peut pas être réutilisé dans cette fenêtre.
- Idempotent et tolérant à l'ordre. Chaque événement décrit l'état actuel de son sujet avec un identifiant stable : les reprises, les doublons et la livraison hors ordre sont sans risque.
- Honnête quand le flux se tait. Un signal de vie chaque minute et une liste des patients présents toutes les 15 minutes permettent de détecter un flux silencieux et de fermer les visites dont le message de départ s'est perdu.
Des événements du DME aux étapes du patient
Les étapes découlent des événements, jamais de suppositions. La visite passe à « Vu par un médecin » quand le DME enregistre l'évaluation, à « Examens en cours » quand une demande est faite, et à « Résultats arrivés, en attente de revoir l'équipe » quand chaque résultat compté est final. Sans preuve, l'étape ne change pas.
Par DME et par norme
Choisissez votre DME ou votre norme pour les détails dont vos analystes d'interfaces auront besoin : les messages, les champs et les mises en garde.
- Epic : HL7 v2 par Bridges, FHIR R4 pour l'enrichissement, lancement SMART.
- Oracle Health Millennium : HL7 v2 sortant, CareTeam FHIR R4 et écriture facultative par Communication.
- HL7 v2 : les déclencheurs, les tables d'état et le canal de référence du moteur.
- FHIR R4 : les ressources que nous transformons, les abonnements et pourquoi FHIR n'est pas le flux du recensement.
Documentation technique
- Contrat d'événementsLe contrat d'événements normalisé : enveloppe, les 23 types d'événements, champs interdits, idempotence et ordre.
- Configuration du moteurConfiguration « stocker et transmettre » pour Mirth Connect, Rhapsody, Cloverleaf et d'autres moteurs, avec des extraits de signature.
- Mise en serviceListe de conformité, exécution parallèle et son seuil de concordance de 98 %, bascule et surveillance.
Questions fréquentes
Faut-il ouvrir des ports dans le pare-feu?
Non. Le moteur d'intégration de l'hôpital ouvre une connexion HTTPS sortante sur le port 443 avec TLS 1.2 ou plus récent. Aucun port n'est ouvert vers l'hôpital, et le moteur accuse réception au DME comme d'habitude : une panne de notre côté ne bloque jamais les flux de l'hôpital.
Quelles données quittent l'hôpital?
Le minimum pour montrer la visite : l'arrivée, le triage et les changements d'emplacement, les noms et rôles de l'équipe soignante, l'existence et l'état des demandes d'examen, l'état des consultations et des admissions, et les codes du service. Jamais de valeurs de résultats, d'indicateurs anormaux, de notes, de diagnostics, de numéros de carte santé, d'adresses ni de numéros de téléphone. Les identifiants ne sont conservés que sous forme de hachages à clé.
Que se passe-t-il si le flux tombe en panne?
Le personnel fait avancer chaque étape depuis la console, par le même pipeline que les événements du DME. Les patients voient « Les mises à jour peuvent être retardées » quand un flux se tait, jamais un ancien état présenté comme actuel.
Prenez-vous en charge d'autres DME qu'Epic et Oracle Health?
Oui. Le même contrat normalisé fonctionne pour tout DME dont le moteur peut envoyer du HL7 v2 ou du FHIR R4, y compris MEDITECH Expanse. Chaque site a seulement besoin de son profil de correspondance pour les emplacements, les examens et les rôles.
À lire aussi
- IntégrationIntégration HL7 v2 : ADT, demandes et état des résultats pour l'urgenceComment EDFlow transforme les messages HL7 v2 ADT, ORM/OML et ORU en événements de l'urgence en temps réel : déclencheurs, correspondance de l'état des résultats OBR-25, canal de référence du moteur d'intégration et signature, sans jamais lire les valeurs OBX.
- ConfianceSécurité et vie privée : LPRPS, résidence et mesures de protectionComment EDFlow protège la vie privée des patients à l'urgence : rôles selon la LPRPS, minimum de données, résidence des données au Canada, identifiants hachés, journalisation des accès, authentification à plusieurs facteurs, tests d'intrusion et divulgation responsable.
- 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.