Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Comment normaliser les données médicales

Tutoriel : transformer des données médicales de sources multiples en une forme comparable — recherche LOINC, unités UCUM, dates ISO, plages de référence, pas de doublons lors de nouvelles tentatives, et validation par rapport au profil de laboratoire européen.

La normalisation des données médicales consiste à transformer des valeurs arrivant sous de nombreuses formes en une forme comparable : le même code pour le même test, le même système d'unités, des dates dans un seul format, chaque valeur avec sa plage de référence et sa source, et aucun doublon. Ce tutoriel montre comment procéder avant que les données n'atteignent un enregistrement HL7 FHIR R4 : recherche des codes LOINC et ATC, utilisation des unités UCUM, refus des dates ambiguës, conservation des plages, évitement des doublons lors de nouvelles tentatives et vérification du résultat par rapport au profil de laboratoire européen. Chaque réponse présentée provient de l'API Anpheros.

Pourquoi c'est important

Le même résultat d'HbA1c peut vous parvenir sous la forme de « HbA1c 6,4 % », « Hemoglobina glicozilata: 6.4 », « Glycated haemoglobin 46 mmol/mol » ou d'un code de laboratoire que seul un laboratoire comprend. Tant que ces valeurs ne sont pas un seul code avec une seule unité :

un graphique de l'HbA1c du patient au fil du temps affiche trois lignes sans rapport ;
une alerte sur « HbA1c supérieur à 6,5 % » manque deux des valeurs ;
un modèle d'IA voit quatre faits au lieu d'une tendance ;
un autre système recevant l'enregistrement ne peut pas l'interpréter.

La normalisation doit avoir lieu au point d'entrée des données dans l'enregistrement, une seule fois, et non dans chaque application qui les lit ultérieurement.

Ce qu'une valeur normalisée contient

Partie	Forme normalisée	Exemple
Ce qui a été mesuré	un code d'un système standard	LOINC `4548-4` (HbA1c), RxNorm `6809` (metformine), ICD-10 `E11` (diabète de type 2)
La valeur	un nombre, ou du texte uniquement lorsque le résultat n'est pas numérique	`6.4`
L'unité	UCUM	`%`, `mg/dL`, `mm[Hg]`, `kg`
Quand	une date-heure ISO 8601, avec fuseau horaire lorsque l'heure est importante	`2026-10-01T07:30:00Z`
Plage normale	bas et haut, dans la même unité	`4.0`–`5.6`
Source	qui l'a produit et de quel système	`import` de `labx`
Identité	quelque chose qui rend une répétition reconnaissable	une clé d'idempotence ou un identifiant de source

Le système de codes qui correspond à chaque type de ressource est listé dans Systèmes de codes FHIR.

Étape 1 : trouver le code

Recherchez la terminologie de la plateforme par nom anglais ou roumain, ou par abréviation :

curl "https://platform.anpheros.com/v1/terminology/loinc?q=hba1c" -H "Authorization: Bearer $KEY"
curl "https://platform.anpheros.com/v1/terminology/loinc?q=hemoglobina%20glicozilata" -H "Authorization: Bearer $KEY"

Les deux renvoient le même concept :

{"data": [{"system": "http://loinc.org", "code": "4548-4", "display": "Hemoglobin A1c/Hemoglobin.total in Blood",
           "display_ro": "Hemoglobină glicozilată (HbA1c)", "category": "laboratory", "unit": "%"}], "total": 1}

Pour les médicaments, Anpheros Search trouve la substance par nom ou marque et donne son code d'ingrédient RxNorm et ses numéros de produit EMA :

curl "https://platform.anpheros.com/v1/search?q=metformin&type=treatment" -H "Authorization: Bearer $KEY"

Le champ unit est l'unité attendue par LOINC pour ce test. Utilisez-le pour vérifier ce que vous avez reçu. Construisez le mappage de chaque nom propre à sa source vers des codes une fois, par source, et conservez-le dans votre intégration. Ne devinez pas au moment de l'écriture : lorsqu'un nom est ambigu et que rien dans la source ne le résout, laissez-le non mappé et demandez à la source. Comment importer les résultats de laboratoire dans un enregistrement FHIR montre comment les marqueurs de laboratoire non mappés sont conservés et signalés.

Étape 2 : Écrire avec des codes, des unités et des plages

curl -X POST "https://platform.anpheros.com/v1/patients/$PID/observations" -H "Authorization: Bearer $KEY" \
     -H "Content-Type: application/json" -H "Idempotency-Key: lab-77-hba1c" -d '{
  "code": "4548-4", "category": "laboratory",
  "value": 6.4, "unit": "%", "effective_at": "2026-10-01T07:30:00Z",
  "reference_range": {"low": 4.0, "high": 5.6},
  "author_type": "import"
}'

{"id": "3296315c-…", "code": "4548-4", "system": "http://loinc.org", "display": "Hemoglobin A1c/Hemoglobin.total in Blood",
 "category": "laboratory", "effective_at": "2026-10-01T07:30:00Z", "value": 6.4, "unit": "%",
 "reference_range": {"low": 4.0, "high": 5.6}, "status": "final", "fhir": "Observation/3296315c-…"}

Lorsque vous envoyez uniquement le code, la plateforme remplit le nom LOINC standard, sur l'API REST comme sur l'API FHIR (/fhir/R4), de sorte que chaque application lise la même display. Une display que vous envoyez vous-même est conservée telle quelle.

Gardez également la formulation originale. Pour un rapport de laboratoire, code.text sur l'Observation FHIR contient le nom du laboratoire ("Hemoglobina glicozilata (HbA1c)") à côté du codage LOINC. Le patient reconnaît toujours son rapport papier, et rien ne est perdu si le mappage est remis en question.

Étape 3 : unités

Utilisez les codes UCUM : mg/dL, mmol/L, %, mm[Hg], kg, cm, /min, Cel. Deux règles permettent d'éviter la plupart des erreurs :

Ne pas convertir silencieusement. Si un laboratoire rapporte le glucose en mmol/L et que votre application affiche mg/dL, stockez ce que le laboratoire a mesuré et convertissez lors de l'affichage. La valeur stockée reste traçable au rapport.
Vérifiez l'unité par rapport au code. Les codes LOINC sont spécifiques : HbA1c en % est 4548-4, tandis que HbA1c en mmol/mol correspond à un code LOINC différent. Une valeur dont l'unité ne correspond pas à l'unité attendue du code est une erreur de mappage, pas un problème de conversion.

Anpheros ne convertit pas les unités pour vous ; il stocke l'unité que vous envoyez.

Étape 4 : dates

Convertissez les dates au format ISO 8601 avant de les écrire, en utilisant le format connu de la source. 01.10.2026 correspond au 1er octobre en Roumanie et dans de nombreux pays européens, mais 10/01/2026 correspond au 1er octobre uniquement aux États-Unis. L'API refuse tout ce qui n'est pas au format ISO, plutôt que de deviner :

{"error": {"type": "invalid", "message": "Input should be a valid datetime or date, invalid character in year (at effective_at)", "field": "effective_at"}}

Le connecteur de laboratoire fait exception : il accepte DD.MM.YYYY et DD/MM/YYYY car il sait qu'il lit un rapport européen.

Pour les mesures où l'heure de la journée est importante (tension artérielle, glycémie, doses de médicaments), envoyez l'heure avec son fuseau horaire. Une mesure à 23h30 à Bucarest correspond à la veille en UTC, et le patient s'attend à ce qu'elle soit enregistrée le jour où il l'a prise.

Étape 5 : pas de doublons

Les doublons proviennent des nouvelles tentatives, d'un même rapport envoyé deux fois et d'une même valeur arrivant par deux canaux.

Nouvelles tentatives : envoyez un Idempotency-Key qui identifie la valeur dans la source, par exemple l'identifiant du rapport et le test. L'envoi de la même requête à nouveau avec la même clé renvoie la première réponse et ne stocke rien de nouveau. Les SDK ajoutent un à chaque création.
Le même rapport deux fois : le connecteur de laboratoire construit un identifiant stable par ligne à partir du rapport, du code, de la date et de la valeur, et ignore les lignes déjà importées.
Deux canaux : stockez l'identifiant propre au système source avec X-Anpheros-Origin-Id (ou dans identifier sur les ressources FHIR), et recherchez-le avant d'écrire des valeurs qui peuvent revenir par un autre chemin.

Étape 6 : Vérification par rapport à un profil

Pour les résultats de laboratoire, demandez à la plateforme comment une ressource se compare au profil de rapport de laboratoire HL7 Europe avant de vous y fier :

curl -X POST "https://platform.anpheros.com/fhir/R4/Observation/\$validate?profile=eu-lab" -H "Authorization: Bearer $KEY" \
     -H "Content-Type: application/fhir+json" -d '{
  "resourceType": "Observation", "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory"}]}],
  "code": {"text": "HbA1c"}, "subject": {"reference": "Patient/'$PID'"},
  "valueQuantity": {"value": 6.4, "unit": "%"}
}'

Ce résultat non normalisé obtient une liste précise :

{"resourceType": "OperationOutcome", "issue": [
  {"severity": "error", "code": "invalid", "diagnostics": "Observation.code must carry a LOINC coding.", "expression": ["Observation.code"]},
  {"severity": "error", "code": "required", "diagnostics": "Observation.effective[x] is required.", "expression": ["Observation.effective"]},
  {"severity": "warning", "code": "business-rule", "diagnostics": "valueQuantity should carry a UCUM system and code.", "expression": ["Observation.valueQuantity"]},
  {"severity": "warning", "code": "informational", "diagnostics": "No referenceRange: interpretation will need the laboratory's ranges.", "expression": ["Observation.referenceRange"]},
  {"severity": "information", "code": "informational", "diagnostics": "No performer (laboratory) recorded.", "expression": ["Observation.performer"]},
  {"severity": "information", "code": "informational", "diagnostics": "No issued time (when the laboratory released the result).", "expression": ["Observation.issued"]}]}

Chaque problème correspond à l'une des étapes ci-dessus. Exécutez $validate dans vos tests d'intégration, avec des échantillons réels de chaque source.

Étape 7 : Conserver la source

La normalisation modifie la manière dont une valeur est écrite, jamais d'où elle provient. Envoyez author_type (device, import, practitioner, patient) et X-Anpheros-Source-System à chaque écriture. C'est ce qui permet à un médecin, un auditeur ou un modèle d'IA de distinguer un résultat de laboratoire d'une valeur saisie à domicile. Voir Explication de la provenance des données médicales.

Liste de contrôle

[ ] Chaque source a un mappage de ses noms vers LOINC / ATC / ICD-10, conservé dans votre intégration
[ ] Les noms ambigus restent non mappés et sont signalés, jamais devinés
[ ] Unités UCUM, correspondant au code ; pas de conversion silencieuse
[ ] Dates ISO 8601, avec fuseaux horaires lorsque l'heure est importante
[ ] Plages de référence conservées avec les valeurs de laboratoire
[ ] Formulation originale conservée (code.text)
[ ] Clés d'idempotence ou identifiants source sur chaque écriture
[ ] author_type et système source sur chaque écriture
[ ] $validate dans les tests pour les résultats de laboratoire

Foire aux questions

Qu'est-ce que la normalisation des données médicales ?

Conversion des données de santé provenant de différentes sources en une forme standard unique : codes partagés (LOINC pour les tests et mesures, ICD-10 pour les diagnostics, ATC pour les médicaments), unités UCUM, dates ISO, plages de référence et une source enregistrée, afin que les valeurs de différents systèmes puissent être comparées, combinées et échangées.

Dois-je convertir toutes les valeurs en une seule unité ?

Stockez l'unité dans laquelle la source a mesuré, tant qu'il s'agit d'une unité UCUM valide correspondant au code, et convertissez lors de l'affichage ou de l'analyse. Cela permet de retracer chaque valeur stockée jusqu'à son rapport d'origine.

La normalisation peut-elle être entièrement automatique ?

En grande partie. Les codes de la source, les noms connus et les unités bien formées peuvent être mappés automatiquement. Les noms ambigus et les codes locaux inconnus nécessitent une décision humaine une fois par source, après quoi le mappage est automatique.

Liens connexes

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card