L’intégration EHR en pratique : API Epic, Oracle Health et athenahealth, flux HL7 et calendrier
La carte, vue par un ingénieur, des vraies voies d’accès à un dossier patient informatisé : FHIR R4 et SMART on FHIR, flux HL7 v2, documents C-CDA, export en masse et réseaux d’échange, puis la façon dont Epic, Oracle Health et athenahealth ouvrent l’accès, et les étapes qui conditionnent un projet.
Ala Ben Aicha
Réponse directe
Intégrer un EHR (le DPI ou DSE des établissements américains), c’est choisir une ou plusieurs voies d’accès au système : une API FHIR R4 autorisée par SMART on FHIR, un flux HL7 v2 via un moteur d’interfaces, des documents C-CDA, l’export FHIR en masse, l’API propriétaire de l’éditeur, ou un réseau comme un HIE ou TEFCA. L’éditeur décide comment vous obtenez vos identifiants, mais chaque établissement client décide si votre application est activée dans son environnement. C’est cette activation site par site, plus que le code, qui fixe le calendrier.
Les voies d’accès en un coup d’œil
| Voie | Ce qui circule | Sens | Usage typique | Qui doit donner son accord |
|---|---|---|---|---|
| FHIR R4 REST + SMART on FHIR | Ressources JSON (Patient, Encounter, Observation…) | Surtout lecture ; l’écriture varie selon l’éditeur et la ressource | Applications patient, applications soignant lancées depuis le dossier, synchronisation backend | Enregistrement chez l’éditeur, puis chaque établissement |
| Flux HL7 v2 | Messages d’événements délimités par des barres (ADT, ORM/OML, ORU, SIU, MDM) | Émis par l’EHR, et résultats ou prescriptions en entrée | Événements en temps réel, résultats de biologie et d’imagerie | L’équipe interfaces du site ; moteur d’interfaces d’un côté ou des deux |
| Documents C-CDA | XML CDA (CCD, compte rendu de sortie, courrier d’adressage) | Les deux | Transitions de soins, échange de documents | Le site, parfois via un HIE |
| Export FHIR en masse | Fichiers NDJSON par type de ressource | Lecture | Analyses populationnelles, registres, flux payeurs et qualité | L’établissement, client backend |
| API propriétaire de l’éditeur | REST ou services web spécifiques | Lecture et écriture | Rendez-vous, facturation, flux que l’API FHIR certifiée ne couvre pas | Programme éditeur plus établissement |
| HIE / TEFCA | Documents et, de plus en plus, FHIR | Requête et envoi | Dossiers entre organisations | Accords de participation au réseau |
FHIR R4 et SMART on FHIR : le choix par défaut pour une nouvelle application
Aux États-Unis, les EHR certifiés doivent exposer une API FHIR R4 au titre du critère §170.315(g)(10) : services de lecture mono-patient et multi-patients, autorisation SMART, éléments de données US Core et export en masse au niveau d’un groupe. Depuis le 1er janvier 2026, US Core 3.1.1, US Core 4.0.0 et SMART App Launch 1.0.0 ne sont plus des options acceptées pour la certification ; les produits certifiés visent donc US Core 6.1.0 et SMART v2. C’est le socle sur lequel vous pouvez compter. Tout ce qui le dépasse dépend de l’éditeur.
SMART App Launch 2.2.0 prévoit trois formes d’application : le lancement depuis le dossier patient (EHR launch), le lancement autonome où le patient ou le soignant se connecte depuis votre application, et les Backend Services pour les traitements sans utilisateur. Le détail des lancements est dans le guide du lancement d’application SMART on FHIR.
Les Backend Services utilisent une assertion JWT signée au lieu d’un secret partagé. La spécification impose aux clients de supporter RS384 et ES384 et limite le exp de l’assertion à cinq minutes (authentification client asymétrique). Une demande de jeton générique ressemble à ceci :
POST /oauth2/token HTTP/1.1
Host: auth.example-ehr.org
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&scope=system/Patient.rs system/Observation.rs
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=eyJhbGciOiJSUzM4NCIsImtpZCI6ImtleS0xIn0.example.signature
Lisez expires_in dans la réponse et renouvelez le jeton avant son expiration. Ne codez pas de durée en dur : les éditeurs et les établissements les paramètrent différemment.
Flux HL7 v2 via un moteur d’interfaces
FHIR n’a pas remplacé HL7 v2 dans les hôpitaux. Admissions, transferts, prescriptions et résultats circulent toujours sous forme d’événements v2, et un établissement vous proposera généralement un flux ADT sortant bien avant un accès en écriture via FHIR. Le flux part du moteur d’interfaces du site (ou directement de l’EHR) en MLLP/TCP ou sur un canal adossé à un VPN, et vous acquittez chaque message par un ACK.
MSH|^~\&|ADT_SRC|NORTH_CAMPUS|YOUR_APP|YOUR_ORG|20261006091500||ADT^A01^ADT_A01|MSG00017|P|2.5.1
EVN|A01|20261006091500
PID|1||MRN000123^^^NORTH_CAMPUS^MR||DOE^JANE^Q||19800214|F
PV1|1|I|4W^412^B^NORTH_CAMPUS||||1234567890^SMITH^ALEX
Deux éléments décident du succès d’une interface v2 : la spécification d’interface du site (quels segments et champs sont réellement renseignés, segments Z compris) et la gestion des reprises, de l’ordre et des doublons par votre moteur. Le choix du moteur est traité dans le comparatif des moteurs d’interfaces HL7, et vous pouvez inspecter un message d’exemple avec le parseur HL7 dans le navigateur.
C-CDA, export en masse et réseaux d’échange
C-CDA reste le format de nombreuses transitions de soins, des messages Direct et des requêtes documentaires des HIE. Si votre produit a besoin du dossier sous forme de document, prévoyez du XML CDA même quand l’EHR propose aussi FHIR. Sa conversion vers FHIR est un chantier à part, décrit dans l’échange de documents C-CDA vers FHIR.
L’export FHIR en masse (Bulk Data Access, désormais en v3.0.0) est asynchrone : lancement, interrogation de l’état, téléchargement des fichiers NDJSON.
GET /fhir/r4/Group/example-cohort-01/$export?_type=Patient,Encounter,Observation HTTP/1.1
Host: fhir.example-ehr.org
Accept: application/fhir+json
Prefer: respond-async
Authorization: Bearer <access_token>
Le serveur répond 202 Accepted avec une URL de suivi dans Content-Location. Le groupe est en général défini par l’établissement : un projet d’export en masse commence donc par décider qui construit et maintient cette cohorte.
Les HIE et TEFCA comptent quand vous avez besoin de dossiers d’organisations avec lesquelles vous n’avez pas de contrat. Epic exploite par exemple Epic Nexus comme QHIN TEFCA. La participation relève autant de la gouvernance et du juridique que de la technique ; voir la mise en œuvre de US Core et TEFCA.
Epic : open.epic, Vendor Services et Showroom
Les noms des programmes Epic ont changé plusieurs fois, ce qui brouille les résultats de recherche. App Orchard n’existe plus. Aujourd’hui :
- open.epic publie les API gratuites et la documentation des interfaces, et Epic on FHIR sert à enregistrer une application, obtenir des client IDs de non-production et de production, et tester dans un bac à sable.
- Vendor Services est le programme payant optionnel : documentation supplémentaire, bac à sable étendu et accès au support Epic.
- Showroom est le catalogue destiné aux clients. Epic y a lancé Connection Hub pour que les éditeurs référencent les produits interopérables avec Epic ; Toolbox et Workshop sont les niveaux plus sélectifs.
Le public visé change le chemin. Selon la documentation OAuth 2.0 d’Epic, les applications qui remplissent ses critères d’auto-sync sont diffusées dans les environnements clients dès qu’un secret client ou une clé publique est fourni ; en pratique, cela concerne les applications patient qui utilisent les API FHIR certifiées. Les applications soignant et backend sont paramétrées et activées établissement par établissement, par les analystes du client. Pour les JWT backend, la documentation d’Epic désigne RS384 comme algorithme préféré. La vue côté start-up est dans Epic FHIR pour les start-ups HealthTech.
Oracle Health (Cerner) : FHIR R4 Millennium et code Console
Oracle documente les API FHIR R4 de la plateforme Oracle Health Millennium ; les API DSTU 2 ne sont plus prises en charge. Les applications s’enregistrent dans code Console, qui exige un compte CernerCare. Les URL racines de service comprennent un bac à sable ouvert, en lecture seule et sans authentification, et un bac à sable sécurisé, sur le tenant public :
https://fhir-open.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d/
https://fhir-ehr-code.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d/
https://fhir-myrecord.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d/
La mise en production est une action du client. Dans le processus de provisionnement des applications FHIR d’Oracle, vous transmettez votre application ID et votre client ID, le client obtient son tenant ID et ouvre des demandes de service pour provisionner votre application, et certains cas de production exigent un formulaire d’approbation. Le provisionnement en libre-service ne s’applique pas aux clients en domaine partagé. Les différences de culture et d’outillage entre les deux éditeurs sont détaillées dans Epic vs Cerner.
athenahealth : API athenaOne et FHIR R4 certifié
athenahealth propose deux familles d’API sur une même plateforme, documentées sur son portail développeur : les API FHIR R4 certifiées (surtout lecture et recherche, alignées sur US Core et décrites dans le guide d’implémentation FHIR d’athenahealth) et les API REST propriétaires athenaOne, cloisonnées par cabinet sous des chemins comme /v1/{practiceid}/. Les rendez-vous, le dépôt de documents et la plupart des écritures passent par la famille propriétaire. La diffusion auprès des cabinets passe par le programme partenaires athenahealth Marketplace, et chaque cabinet autorise encore votre application.
Les autres EHR, en bref
MEDITECH propose Greenfield Workspace pour tester sur un vrai système Expanse avec les API FHIR R4 US Core et de prise de rendez-vous. NextGen a un programme développeur avec des parcours distincts pour l’accès patient, les applications développées par les clients et les applications distribuées par des éditeurs tiers.
Les phases du projet et ce qui les conditionne
Aucune source publique sérieuse ne donne une durée unique pour « une intégration EHR », et quiconque en annonce une sans connaître le site devine. Ce qui est prévisible, c’est l’ordre des étapes :
| Phase | Ce qui se passe | Ce qui la conditionne |
|---|---|---|
| Cadrage | Données, sens des flux, déclencheur métier, voie d’accès par cas d’usage | Un référent clinique ou métier nommé dans l’établissement |
| Inscription éditeur et revue sécurité | Enregistrement de l’application, adhésion au programme si besoin, questionnaire sécurité du client, BAA | Les files d’attente sécurité et juridiques du client |
| Développement en bac à sable | Code sur les données de test de l’éditeur | Votre équipe seule ; en général la phase la plus rapide |
| Paramétrage du site | Activation du client ID, construction des interfaces, utilisateurs et scopes | Les analystes du client et son calendrier de changements |
| Validation avec le site | Tests dans l’environnement de non-production du client avec des données réalistes | Patients de test, utilisateurs de test, disponibilité des soignants |
| Mise en production | Identifiants de production, bascule, premiers messages réels | Validation du comité des changements, fenêtres d’interruption |
| Supervision | Files d’erreurs, échecs de jetons, alertes de volume et de latence | Un modèle de support convenu avec l’équipe interfaces du site |
Les pièges qui apparaissent après le bac à sable
- Paramétrage propre à chaque site. Deux hôpitaux sur la même version d’EHR renseignent des champs différents, utilisent des systèmes d’identifiants différents et exposent des scopes différents. Construisez une check-list d’intégration par site, pas par éditeur.
- Rapprochement d’identité. Les MRN sont locaux. Utilisez le système d’identifiants fourni par le site, conservez les données démographiques pour le rapprochement et n’utilisez
$matchque si le serveur le prend en charge. Le guide sur l’index patient maître décrit les cas d’échec. - Limites de l’écriture. Les API FHIR certifiées garantissent la lecture. L’écriture existe pour une partie des ressources et demande souvent une approbation supplémentaire ; résultats et comptes rendus repartent souvent en HL7 v2.
- Limites de débit. Les éditeurs limitent le débit, et tous ne publient pas leurs seuils. Regroupez les appels, mettez en cache et temporisez sur
429. - Durée de vie des jetons. Les jetons d’accès sont courts et les jetons de rafraîchissement varient selon le type d’application et la politique du site. Au titre du (g)(10), un EHR certifié doit délivrer aux applications patient confidentielles un jeton de rafraîchissement valable au moins trois mois. Ce plancher ne dit rien des applications soignant ou backend.
- Bac à sable contre production. Les patients du bac à sable sont propres. La production contient des dossiers fusionnés, des codes manquants, des résultats en texte libre et des terminologies locales. Prévoyez du temps de validation pour cet écart.
Intégration EMR ou EHR ?
Les deux termes sont employés indifféremment dans les recherches comme dans les contrats. La distinction d’origine de l’ONC : l’EMR est le dossier numérique d’un seul cabinet, tandis que l’EHR est conçu pour partager l’information au-delà de l’organisation qui l’a produite. En intégration, la différence se voit dans ce que le système expose : un petit logiciel de cabinet peut n’offrir qu’une API propriétaire ou un export de documents, alors qu’un EHR certifié doit offrir l’API FHIR R4 décrite plus haut.
Choisir sa voie d’accès
Partez du flux de travail. Si un soignant a besoin de votre application dans le dossier patient, utilisez SMART on FHIR. Si vous devez réagir aux admissions ou aux résultats en temps réel, demandez un flux HL7 v2. S’il vous faut le dossier complet d’une cohorte, utilisez l’export en masse. Si le cas d’usage écrit des rendez-vous ou de la facturation, attendez-vous à l’API propriétaire de l’éditeur et à son programme partenaires. La plupart des intégrations en production combinent deux de ces voies.
Si vous préparez l’une de ces intégrations et souhaitez un regard extérieur sur la voie d’accès, les étapes ou la check-list par site, voir les services d’intégration EHR et DPI.