Lire la data stack hospitalière : données cliniques EHR versus claims

# Lire la data stack hospitalière : données cliniques EHR versus claims

Mme Alvarez arrive pour une prothèse totale de genou. Son chirurgien documente tout dans Epic : l'assessment pré-opératoire, le numéro de série de l'implant, le dossier d'anesthésie, deux doses d'anticoagulant, une légère fièvre post-opératoire et trois jours de notes de kinésithérapie.

Deux semaines plus tard, le service facturation envoie un claim UB-04 à son assureur. Ce claim réduit tout son séjour à une poignée de codes et un montant en dollars. Presque aucune note de kinésithérapie n'y figure. La fièvre a disparu. Le numéro de série de l'implant est introuvable.

Même patiente. Même admission. Deux jeux de données qui racontent des histoires différentes. Les dirigeants hospitaliers consacrent un effort considérable à les réconcilier, et comprendre pourquoi est le socle de la data literacy hospitalière.

Les deux jeux de données, définis

EHR (Electronic Health Record) : le système clinique de référence. Epic et Oracle Health (anciennement Cerner) dominent le marché américain. L'EHR enregistre ce qui est arrivé au patient sur le plan clinique : constantes, médicaments, notes, analyses, images, prescriptions.

Claims : la sortie du système de facturation, envoyée aux payeurs (assureurs, Medicare, Medicaid) pour être payé. Pour un séjour hospitalier, le format standard est le UB-04 (aussi appelé CMS-1450), un formulaire de claim institutionnel défini par le National Uniform Billing Committee.

L'EHR répond à « qu'avons-nous fait pour le patient ? ». Le claim répond à « que va-t-on facturer, et comment le justifier ? ». Des questions liées, mais pas identiques.

Suivre la prothèse de genou

Suivez Mme Alvarez dans les deux systèmes.

Dans Epic, le dossier est granulaire et horodaté :

• Feuilles de surveillance infirmière avec constantes horaires
• Le compte rendu opératoire décrivant la voie d'abord chirurgicale
• Les enregistrements d'administration des médicaments (les heures exactes de chaque dose)
• Des notes de suivi en texte libre de trois praticiens
• L'évaluation de kinésithérapie et les séances quotidiennes

Sur le UB-04, tout cela se réduit à des codes structurés :

• Un DRG (Diagnosis Related Group), la catégorie de paiement que Medicare et de nombreux assureurs utilisent pour rembourser l'ensemble du séjour en forfait. Une prothèse articulaire majeure correspond à une famille de DRG spécifique.
• Des codes diagnostiques ICD-10-CM (pourquoi elle avait besoin de soins : arthrose du genou)
• Des codes d'acte ICD-10-PCS (ce qui a été fait, dans le langage de codage hospitalier)
• Des revenue codes regroupant les charges (bloc opératoire, pharmacie, kinésithérapie)
• Le total des charges et les dates de soins

Remarquez la compression. Des jours de narration clinique deviennent une douzaine de codes. C'est dans cette compression que les deux jeux de données divergent.

Pourquoi la même admission produit deux vérités différentes

1. La finalité façonne le contenu

L'EHR enregistre la réalité clinique. Le claim enregistre la réalité facturable et défendable. Si une infirmière documente un symptôme qui ne devient jamais un diagnostic formel, il reste dans Epic mais n'atteint jamais le claim.

2. Le codage est une interprétation, pas une copie

Un medical coder formé (ou, de plus en plus, un logiciel de codage assisté par ordinateur) lit le dossier et le traduit en codes. Cette traduction implique un jugement. La fièvre comptait-elle comme une complication documentée ? Seulement si un médecin a écrit un diagnostic qui l'étaye. C'est pourquoi les hôpitaux investissent dans des équipes CDI (Clinical Documentation Integrity) dont le rôle est de s'assurer que le dossier soutient un codage exact.

3. Le timing diffère

Les données Epic existent en temps réel. Le claim est assemblé après la sortie, parfois des semaines plus tard, et peut être corrigé et resoumis. Donc un jour donné, les deux systèmes se contredisent simplement parce que le claim n'a pas rattrapé son retard.

4. La granularité diffère

Epic connaît le numéro de série de l'implant, utile en cas de rappel de dispositif. Le claim s'en désintéresse. Inversement, le claim porte le DRG final qui pilote le chiffre d'affaires, un champ qui ne « vit » pas naturellement dans le dossier clinique.

Un exemple de données concret

Imaginez que vous extrayiez les deux dossiers de Mme Alvarez. Simplifiés, ils ressemblent à ceci :

EHR (Epic) extract
------------------
encounter_id: 88213
admit_ts: 2026-03-02 06:41
procedure_note: "TKA, right knee, cemented implant"
implant_serial: ZX-4471-A
meds_given: [enoxaparin x2, acetaminophen x6, ...]
vitals_rows: 214
pt_sessions: 3
discharge_ts: 2026-03-05 11:20

UB-04 claim extract
-------------------
encounter_id: 88213
drg: 470  (major joint replacement, no MCC)
principal_dx: M17.11 (osteoarthritis, right knee)
icd10_pcs: 0SRC0J9
revenue_codes: [0360 OR, 0250 pharmacy, 0420 PT]
total_charges: [amount]
from_date: 2026-03-02
thru_date: 2026-03-05

Le même encounter_id les relie. Mais l'EHR contient 214 lignes de constantes et un numéro de série d'implant ; le claim contient un DRG et des revenue codes. Aucun n'est « complet ». Un analyste hospitalier qui veut la vision d'ensemble doit joindre les deux.

Notez le détail du DRG : 470 contre 469 se distingue par la présence ou non d'une MCC (Major Complication or Comorbidity) pendant le séjour. Si la fièvre post-opératoire de Mme Alvarez avait été documentée comme un diagnostic éligible, le séjour aurait pu être groupé différemment et remboursé à un tarif plus élevé. Cette seule décision de documentation déplace de l'argent. C'est exactement pour cela que le CDI existe, et pourquoi les régulateurs l'examinent de près.

Pourquoi les dirigeants réconcilient les deux en permanence

Les dirigeants hospitaliers décident à partir des deux jeux de données, et les écarts crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éent de vrais problèmes.

Reporting qualité. Les programmes qualité publics utilisent souvent les claims parce qu'ils sont standardisés et disponibles pour tous les hôpitaux. Mais les claims manquent la nuance clinique. Un patient réellement plus gravement atteint peut apparaître comme une « complication » dans les données de claims si la documentation était faible. L'Agency for Healthcare Research and Quality maintient des indicateurs qualité basés sur les claims largement utilisés, qui illustrent à la fois la puissance et les limites des données de facturation.

Revenue integrity. Si l'EHR montre des soins qui n'ont jamais atteint le claim, l'hôpital sous-facture peut-être. Si le claim montre plus que ce que le dossier soutient, c'est un risque de conformité. La réconciliation protège des deux côtés.

Population health et value-based care. Dans les dispositifs où les hôpitaux sont payés sur les résultats, les dirigeants ont besoin du détail clinique (issu de l'EHR) rapproché du détail de coût (issu des claims). Aucun des deux ne suffit seul.

La couche d'interopérabilité

Un développement récent compte ici : FHIR (Fast Healthcare Interoperability Resources), le standard du secteur pour échanger des données de santé via des APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète →. La réglementation fédérale impose désormais aux EHR certifiés d'exposer les données via des APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → FHIR, ce qui facilite l'extraction programmatique de données cliniques structurées plutôt que le scraping de notes. Vous pouvez explorer le standard sur HL7 FHIR.

FHIR aide du côté clinique. Il ne remplace pas les claims. Les deux modèles de données restent distincts parce que leurs finalités restent distinctes. FHIR rend simplement la moitié clinique plus accessible pour l'analytics.

Comment les analystes utilisent réellement chaque jeu de données

Voyez cela comme le choix du bon outil.

Utilisez les claims quand vous avez besoin de :

• Comparabilité entre hôpitaux ou dans le temps (tout le monde code selon les mêmes standards)
• Coût total et remboursement par séjour
• Dénominateurs larges pour les tendances de population

Utilisez l'EHR quand vous avez besoin de :

• Détail clinique : valeurs de laboratoire, timing des médicaments, tendances des constantes
• Signaux en temps réel ou quasi réel (alertes sepsis, patients qui se dégradent)
• Traçabilité des dispositifs, contrôle des allergies, ou tout ce que le claim ne porte jamais

Utilisez les deux, joints, quand vous avez besoin de :

• Résultats ajustés au risque (sévérité clinique depuis l'EHR, coût depuis les claims)
• Contrôles de revenue integrity
• Performance en value-based care

Un piège classique pour les analystes débutants : supposer qu'un compte issu des claims équivaut à un compte clinique. « Combien de patients ont reçu un anticoagulant ? » est une question EHR. Le claim ne montre qu'un revenue code de pharmacie, pas chaque dose. Posez au claim une question clinique et vous obtiendrez une réponse fausse énoncée avec assurance.

Une note sur les systèmes humains derrière les données

La divergence n'est pas un défaut à éliminer. Elle reflète deux workflows légitimes : soigner les patients et être payé pour ces soins. Le travail de réconciliation (coders, spécialistes CDI, analystes revenue integrity, et de plus en plus d'outils automatisés) est une caractéristique permanente des opérations hospitalières, pas un bug temporaire.

Pour un dirigeant non technique, l'insight clé est celui-ci : quand on vous présente une « métrique hospitalière », votre première question doit être « vient-elle du dossier clinique ou du claim ? ». La réponse change ce que le chiffre peut et ne peut pas vous dire.

Points clés

• Une admission, deux jeux de données. L'EHR (Epic, Oracle Health) enregistre la réalité clinique ; le claim UB-04 enregistre la réalité facturable et codée. Ils divergent par construction.
• Le codage est une interprétation. Des coders humains et des logiciels traduisent les dossiers en codes ICD-10 et DRG. La qualité de la documentation (le travail des équipes CDI) affecte directement l'exactitude et le remboursement.
• Adaptez le jeu de données à la question. Les claims pour la comparabilité et le coût, l'EHR pour le détail clinique et les signaux temps réel, et les deux joints pour les résultats ajustés au risque.
• Demandez toujours la source. Avant de faire confiance à une métrique hospitalière, déterminez si elle vient du dossier clinique ou du claim. Cette seule question recadre ce que les données peuvent prouver.
• FHIR aide, mais ne fusionne pas les deux. Les standards d'interopérabilité rendent les données cliniques plus accessibles, mais les claims restent un modèle séparé conçu pour le paiement.