Exporter un calendrier mictionnel vers Epic, Cerner et les autres DSE

Bladder Diaries exporte le calendrier patient sous deux fichiers standard : un FHIR R4 Bundle (.fhir.json) pour les DSE modernes qui ingèrent du FHIR, et un HL7 C-CDA R2.1 CCD (.ccd.xml) pour les systèmes hérités et la messagerie Direct Secure Messaging. Les deux fichiers sont construits dans le navigateur, téléchargés localement, puis attachés au dossier via l'entrée standard du DSE récepteur. Aucune donnée patient ne transite par les serveurs bladderdiaries.com ; le placeholder de Patient synthétique est remplacé par l'outillage de chart-matching du récepteur à l'ingestion.

Vous venez d'achever un calendrier de 3 jours avec un patient. Le calculateur a retourné un MVV (volume mictionnel maximal) de 320 mL, un AVV (volume mictionnel moyen) de 145 mL, un NPi (indice de polyurie nocturne) de 32%, un 24hVV (volume mictionnel sur 24 heures) de 2,1 L et un FVC (frequency-volume chart) de 9 mictions par 24 heures. La question restante est mécanique : comment ces chiffres atterrissent-ils dans le dossier sous une forme que votre codeur, votre infirmière et la consultation suivante pourront lire ? Ce parcours couvre les deux formats de fichier, les surfaces d'entrée d'Epic, Cerner / Oracle Health, Athena Health, Prompt Health (via Kno2) et du DSE hérité, ainsi que le contrat de chart-matching côté récepteur.

Les deux formats de fichier : FHIR R4 Bundle vs HL7 C-CDA R2.1 CCD

Les deux standards du catalogue d'import au dossier sont FHIR (Fast Healthcare Interoperability Resources) et C-CDA (Consolidated Clinical Document Architecture). Tous deux sont des standards HL7 ; tous deux portent les mêmes données de calendrier sous des formes filaires différentes. Bladder Diaries émet les deux car l'écosystème DSE est bilingue : les installations modernes ingèrent du FHIR nativement, les installations ambulatoires héritées ingèrent du C-CDA, et les mandats fédéraux américains (21st Century Cures Act, ONC Cures Act Final Rule) exigent depuis 2023 des technologies EHR certifiées qu'elles supportent FHIR R4, avec C-CDA R2.1 comme rampe d'accès pour l'existant.

FHIR R4 Bundle : la voie moderne

FHIR R4 (publié en octobre 2019) est le standard JSON orienté ressources qu'ingère la cohorte DSE moderne. L'export est livré sous forme d'un Bundle de type: "collection" contenant :

• 1 ressource Patient placeholder portant la sentinelle REPLACE_WITH_MRN sur Patient.identifier. Le récepteur renseigne le MRN réel à l'ingestion.
• N ressources Observation au niveau événement : une par miction, une par apport hydrique, une par notation d'urgence (lorsqu'elle est documentée), une par épisode de fuite. Le récepteur voit la chronologie brute.
• 5 ressources Observation au niveau métrique calculée pour MVV, AVV, NPi, 24hVV et FVC, chacune portant un codage hybride LOINC plus un codage du CodeSystem Bladder Diaries (selon Phase 8 D-12). Le récepteur dispose d'un codage standard et d'un codage précis.
• 1 ressource DiagnosticReport qui synthétise les métriques, avec le PDF encodé en base64 dans presentedForm[0].data. Un artefact lisible par l'humain accompagne toujours la donnée structurée.

Le Bundle valide contre le schéma HL7 R4 et contre le profil US Core 6.1.0 Implementation Guide. Les récepteurs qui profilent contre US Core (Epic, Cerner / Oracle Health, Athena, Allscripts / Veradigm) retrouvent les champs attendus : Patient.identifier, Observation.code, Observation.value[x], Observation.effectiveDateTime, DiagnosticReport. Ceux qui ne profilent pas contre US Core conservent malgré tout la forme R4 de base, suffisante pour l'ingestion.

HL7 C-CDA R2.1 CCD : la rampe d'accès pour l'existant

C-CDA R2.1 (publié en juillet 2015) est le standard documentaire XML qu'ingèrent la cohorte ambulatoire héritée et le transport Direct Secure Messaging. L'export est livré sous forme d'un ClinicalDocument avec :

• Le US Realm Header (CONF:1198-*) couvrant le placeholder Patient, l'organisation custodian, l'auteur du document et l'ossature CDA standard.
• Un body contenant les six sections obligatoires d'un CCD (Allergies, Médicaments, Problèmes, Procédures, Résultats, Anamnèse sociale), avec nullFlavor="NI" sur les sections que le calendrier ne renseigne pas.
• Un organizer Results portant les cinq mêmes métriques calculées, chaque <observation> étant doublement déclarée avec le templateId Result Observation V3 (2.16.840.1.113883.10.20.22.4.2, extension 2015-08-01).
• Un élément observationMedia qui porte le rapport PDF encodé en base64 inline ; aucune pièce jointe séparée n'est nécessaire.

Le CDA valide contre le schematron HL7 SDWG C-CDA R2.1 (clôturé en Phase 11 Plan 11-01). La voie C-CDA est le bon choix lorsque le DSE récepteur est antérieur au cycle de conformité 21st Century Cures Act, lorsque le workflow est médié par Direct Secure Messaging, ou lorsque l'équipe IT du récepteur a désactivé l'entrée FHIR.

Lequel choisir ?

| DSE récepteur | Format | Surface d'entrée | | ------------------------ | ---------- | --------------------------------------------------------------------------- | | Epic | FHIR R4 | App SMART on FHIR, FHIR Inbox, pièce jointe au dossier sur une consultation | | Cerner / Oracle Health | FHIR R4 | Entrée FHIR R4, Bridges, Code App Gallery | | Athena Health | FHIR R4 | Entrée More Disruption Please (MDP) ; repli sur CCD si MDP désactivé | | Prompt Health | L'un ou l'autre | Partenariat Kno2 : le normaliseur côté récepteur accepte les deux | | Allscripts / Veradigm | FHIR R4 | Ingestion dbMotion / TouchWorks | | NextGen | C-CDA | Entrée CCD ; roadmap FHIR non livrée sur toutes les éditions | | eClinicalWorks | C-CDA | Entrée CCD | | Greenway / Intergy | C-CDA | Entrée CCD | | Long-tail hérité | C-CDA | Direct Secure Messaging (DSM), livraison HIE à la boîte de réception |

La règle de décision : envoyer FHIR R4 si vous savez que le récepteur supporte FHIR ; envoyer C-CDA si vous ne le savez pas, ou si le récepteur est explicitement sur la rampe d'accès héritée. Bladder Diaries émet les deux fichiers depuis la même sortie de calculateur ; vous pouvez donc garder les deux fichiers sous la main et utiliser celui que le récepteur accepte réellement.

Pas-à-pas : de /entry au dossier

Le workflow de bout en bout comporte quatre étapes. Les trois premières se déroulent dans votre navigateur, sur bladderdiaries.com. La quatrième se déroule dans le DSE récepteur.

Étape 1 : Saisir le calendrier sur /entry

Ouvrez le Calculateur sur bladderdiaries.com. Saisissez le calendrier patient sous forme de mictions, d'apports hydriques, de repères de coucher et (lorsqu'ils sont documentés) d'épisodes de fuite et de notations d'urgence. Le formulaire mono-écran prend environ 90 secondes pour un calendrier de 3 jours typique. L'âge du patient et le marqueur d'énurésie pilotent le seuil de NPi par tranche d'âge et la classification de continence.

Étape 2 : Lire les métriques sur /results

Le calculateur route vers /results après soumission. La page restitue MVV, AVV, NPi, 24hVV, FVC et la classification IPC (Integrated Pelvic Care) 4Is (Fluid Imbalance, Storage Impairment, Voiding Impairment, Incontinence). La grille à quatre piliers nourrit ensuite le langage du dossier pour la note de consultation ; voir le pilier d'interprétation du calendrier mictionnel pour la discipline clinique qui apparie les chiffres au différentiel.

Étape 3 : Appuyer sur le bouton d'export

La barre d'export en haut de /results porte trois boutons : PDF, FHIR Bundle et C-CDA CCD. Appuyez sur le format qu'accepte le DSE récepteur. Le fichier est construit dans le navigateur (FHIR Bundle en JSON, CCD en XML) et atterrit dans votre dossier de téléchargement local avec un nom de fichier déterministe : bladder-diary-YYYY-MM-DD.fhir.json ou bladder-diary-YYYY-MM-DD.ccd.xml. Aucun upload HTTPS vers bladderdiaries.com n'a lieu ; le toast confirme « téléchargé. Note : le fichier est stocké sur votre appareil, en dehors de ce calculateur ».

Étape 4 : Attacher au dossier dans le DSE récepteur

Epic via SMART on FHIR : si votre organisation a déployé une app SMART on FHIR à destination du patient, le patient charge le FHIR Bundle via MyChart. Si votre équipe IT a activé la FHIR Inbox, déposez-y le fichier. Si aucune de ces voies n'est disponible, attachez le FHIR Bundle comme pièce jointe au dossier sur une consultation de routine ; le fichier vit dans le dossier sous forme de binaire, et la donnée structurée peut être re-parsée plus tard.

Cerner / Oracle Health : l'entrée FHIR R4 accepte le fichier via l'opération R4/$import lorsque l'IT l'a activée. De nombreux établissements passent par Bridges (la couche d'interopérabilité Oracle Health). Le Code App Gallery offre une troisième voie : une surface SMART on FHIR où le fichier est chargé comme ressource attachée au patient.

Athena Health : l'entrée More Disruption Please (MDP) est la voie FHIR R4. Déposez le FHIR Bundle via l'endpoint MDP. Si votre instance Athena ne dispose que de l'entrée CCD héritée, envoyez plutôt le C-CDA CCD.

Prompt Health : le partenariat Kno2 accepte les deux formats de fichier. Kno2 joue le rôle d'un normaliseur côté récepteur qui convertit FHIR ou CCD vers le format qu'attend le DSE en aval. La même voie fonctionne pour tout DSE membre du réseau Kno2.

DSE hérité via Direct Secure Messaging (DSM) : le C-CDA CCD voyage via DSM en pièce jointe XML. Le Health Information Service Provider (HISP) du récepteur le livre à la boîte de réception du récepteur. La voie DSM est le bon choix pour les cabinets ambulatoires qui n'ont pas encore adopté FHIR.

L'option de courriel ordinaire n'est pas recommandée. Privilégiez l'entrée standard du DSE récepteur ; la voie courriel demeure un workflow manuel de dernier recours.

Le contrat de confidentialité : pur-client, pas de transit de PHI

La propriété la plus importante du pipeline d'export est qu'il ne transmet jamais de données patient. Les deux fichiers sont entièrement construits dans votre navigateur à partir des données de calendrier saisies par le clinicien sur /entry. Le calendrier vit uniquement dans le localStorage du navigateur : aucune base de données côté serveur, aucun upload HTTPS vers bladderdiaries.com, aucune analytique tierce sur la charge utile du calendrier.

Le DSE récepteur est l'autorité de chart-matching. Le placeholder Patient porte précisément REPLACE_WITH_MRN sur Patient.identifier pour que le récepteur puisse exécuter son propre matching contre l'espace de noms MRN local. La politique IT du récepteur détermine si le matching est automatique (R4/$import côté système, avec une règle de rattachement au dossier) ou manuel (le personnel d'accueil apparie le fichier entrant au dossier). Bladder Diaries ne voit, ne stocke et ne transmet aucune information de matching.

La posture HIPAA / RGPD découle de ce design. Bladder Diaries reste hors du périmètre HIPAA Covered Entity et hors du périmètre RGPD data-controller, parce qu'il ne détient jamais de données patient sur ses serveurs. Le navigateur local du clinicien détient le calendrier ; le système de fichiers du clinicien détient l'export ; le DSE récepteur détient le dossier. Chaque maillon est une surface de conformité connue pour l'équipe IT locale et pour le Business Associate Agreement local (lorsqu'il s'applique) ; le maillon bladderdiaries.com est vide par conception.

Ce point est documenté dans la Politique de confidentialité. L'invariant pur-client est le verrou architectural qui maintient Bladder Diaries hors du périmètre réglementaire ; le catalogue de formats de fichier est la rampe d'accès opérationnelle qui achemine malgré tout la donnée structurée au dossier.

Que représente l'OID CodeSystem 2.25.* dans mon journal d'audit ?

Les récepteurs qui auditent le document entrant par CodeSystem y verront un Object Identifier (OID) propre à Bladder Diaries, sous la forme 2.25.<uuid-décimal>. C'est intentionnel et mérite une explication brève, car les équipes IT cliniques signalent parfois les OID inconnus comme un sujet de sécurité.

Un OID est un identifiant hiérarchique enregistré dans un arbre global (l'arc OID ISO/IEC 9834). Les standards HL7 utilisent des OID pour identifier les systèmes de codage de manière non ambiguë : LOINC est 2.16.840.1.113883.6.1, SNOMED CT est 2.16.840.1.113883.6.96. Chaque OID correspond à une autorité enregistrée qui maintient les codes.

Les cinq métriques calculées de Bladder Diaries (MVV, AVV, NPi, 24hVV, FVC) ne sont pas encore intégralement couvertes par LOINC canonique. LOINC possède des codes pour les volumes sous-jacents (par exemple 28604-5 Voided volume, 28649-0 Urine output 24 hour), mais non pour les métriques calculées propres au calendrier mictionnel dans la forme précise qu'exige le cadre IPC. Le codage hybride émet à la fois un code LOINC (lorsqu'il en existe un) et un code Bladder Diaries personnalisé (toujours), de sorte que le récepteur obtient un codage standard pour ancrer une recherche et un codage précis pour ancrer un calcul.

Le CodeSystem personnalisé a besoin d'un OID. Plutôt que de demander un arc enregistré auprès de HL7 (un processus de plusieurs mois), Bladder Diaries emploie l'arc 2.25.* selon RFC 4122 §4.5, qui autorise toute partie à dériver un OID globalement unique à partir d'un UUID en traitant l'UUID comme un entier décimal. L'OID résultant est unique sans enregistrement, traçable et conforme au standard HL7 pour les identifiants de CodeSystem. L'équipe IT clinique peut documenter l'OID comme émis par Bladder Diaries (une approbation unique dans la liste d'autorisation des OID) ; le journal d'audit continue ensuite de circuler normalement.

Ce qu'il faut demander à votre service informatique avant le premier export

Cinq questions alignent les attentes avant le premier export patient. Les réponses déterminent le format de fichier et la surface d'entrée à utiliser :

1. Supportons-nous l'ingestion FHIR R4 ? La plupart des installations DSE en 2026 supportent FHIR R4 à un certain degré ; la variance porte sur la surface d'entrée (app SMART on FHIR, FHIR Inbox, R4/$import, voie spécifique à l'éditeur).
2. Supportons-nous l'ingestion C-CDA R2.1 ? Les récepteurs C-CDA R2.0 peuvent en général parser les documents R2.1 (le schéma est rétrocompatible), mais les avertissements de schematron peuvent différer.
3. Quelle est notre surface d'app SMART on FHIR ? Epic et Cerner / Oracle Health : cette réponse indique si le FHIR Bundle se charge via une app patient (MyChart) ou seulement via la FHIR Inbox back-office.
4. Notre adresse Direct Secure Messaging est-elle découvrable ? DSE ambulatoires hérités : l'adresse DSM est la destination du C-CDA CCD. Votre HISP peut confirmer que l'adresse est publiée dans le registre DirectTrust.
5. Disposons-nous d'un partenariat Kno2 ? Prompt Health et autres DSE connectés à Kno2 : l'entrée Kno2 est un point d'entrée unique qui route vers plusieurs DSE en aval.

Bonus : quelles sont les règles de chart-matching pour un fichier entrant avec un MRN placeholder ? Certains récepteurs auto-apparient sur la démographie (nom plus date de naissance plus sexe plus adresse) ; d'autres exigent un Patient.identifier entièrement renseigné. Connaître la politique du récepteur vous indique si le fichier route automatiquement ou si le personnel du récepteur appariera manuellement.

FAQ

Quel format de fichier envoyer à Epic ? FHIR R4 Bundle (.fhir.json). Epic ingère FHIR R4 via sa surface d'app SMART on FHIR, via la FHIR Inbox si votre équipe IT l'a activée, ou comme pièce jointe au dossier sur une consultation de routine. Valide contre US Core 6.1.0.

Quel format de fichier envoyer à Cerner ou Oracle Health ? FHIR R4 Bundle (.fhir.json). Cerner / Oracle Health ingère FHIR R4 via le même standard. Certains établissements passent par Bridges ou Code App Gallery ; l'entrée FHIR back-office est la voie standard.

Quel format de fichier envoyer à Athena Health ? FHIR R4 Bundle (.fhir.json) via l'entrée More Disruption Please (MDP). Si votre instance Athena ne dispose que de l'entrée CCD héritée, envoyez plutôt le C-CDA CCD (.ccd.xml).

Quel format de fichier envoyer à Prompt Health ? L'un ou l'autre. Prompt Health accepte les deux formats via son partenariat Kno2 ; le normaliseur côté récepteur de Kno2 convertit vers le format qu'attend le DSE en aval.

Bladder Diaries téléverse-t-il mes données patient quelque part ? Non. Les deux formats de fichier sont générés intégralement dans votre navigateur. Le fichier atterrit dans votre dossier de téléchargement local ; aucun upload HTTPS vers bladderdiaries.com ni vers un quelconque tiers. La Politique de confidentialité le décrit en détail.

Que représente le placeholder REPLACE_WITH_MRN ? Une valeur sentinelle délibérée sur la ressource Patient synthétique. L'outillage de chart-matching de votre DSE la remplace par le numéro de dossier médical réel à l'ingestion. Ce motif permet au fichier d'être expédié sans aucune donnée d'identification du patient et laisse au récepteur le soin d'appliquer sa propre politique de chart-matching.

Pourquoi mon journal d'audit DSE montre-t-il un OID CodeSystem 2.25. que je ne reconnais pas ?* Il s'agit du CodeSystem personnalisé de Bladder Diaries, auto-alloué sous l'arc OID RFC 4122 §4.5. Utilisé pour les cinq métriques calculées (MVV, AVV, NPi, 24hVV, FVC) que LOINC canonique ne couvre pas encore. Chaque métrique porte également un code LOINC hybride lorsqu'il en existe un.

Puis-je envoyer le même fichier à plusieurs DSE ? Oui. Les deux formats de fichier sont agnostiques au récepteur. Le même FHIR Bundle ou C-CDA CCD peut être routé vers plusieurs DSE en parallèle (par exemple soins primaires plus orientation spécialisée). Le chart-matching à chaque destination est indépendant.

Conclusion : essayez-le sur le prochain calendrier

Le prochain calendrier de 3 jours que vous achèverez avec un patient sur Bladder Diaries en est le cas test. Ouvrez le Calculateur, saisissez le calendrier, lisez les métriques sur /results, puis appuyez sur le bouton d'export qui correspond au DSE récepteur. Le fichier atterrit dans votre dossier de téléchargement ; attachez-le via l'entrée standard du DSE récepteur. Le clinicien dispose alors, dans le dossier, des mêmes chiffres structurés que ceux retournés par le calculateur à l'écran ; les serveurs bladderdiaries.com restent vides ; et le fichier standardisé atterrit là où il doit : dans le dossier, au côté du reste du dossier patient.

Auteur : Dr. Di Wu, MD, PT (membre fondateur de l'IPC). Le jalon v5.0 de Bladder Diaries livre l'interopérabilité DSE standardisée. Standards référencés : HL7 FHIR R4, HL7 C-CDA R2.1, US Core 6.1.0 Implementation Guide, LOINC, et RFC 4122 §4.5 (arc OID dérivé d'UUID). Photo : Vitaly Gariev sur Unsplash.