Réponse courte : les ressources FHIR de base sont volontairement souples : presque tout est optionnel et la plupart des codes ne sont que des exemples, afin qu'une seule norme convienne à tous les pays. Un profil est une StructureDefinition qui resserre une ressource pour un usage donné : dans ce contexte, Patient doit avoir un identifiant de ce type, Observation.code doit être un code LOINC de cette liste, cet élément doit être pris en charge, celui-là ne doit pas apparaître. Une extension ajoute un élément manquant à la ressource de base, identifié par une URL et défini par sa propre StructureDefinition. Les guides d'implémentation (US Core, l'IPS, guides nationaux) sont des collections de profils, d'extensions, d'ensembles de valeurs et d'exemples. Une ressource indique les profils qu'elle prétend suivre dans meta.profile, et un validateur la vérifie.
Ce qu'un profil peut changer
Un profil FHIR ne peut modifier une ressource qu'en la restreignant : en resserrant la cardinalité, en marquant des éléments comme devant être supportés, en fixant des valeurs ou des motifs, en liant des éléments à des jeux de valeurs avec une force, en découpant des listes en parties nommées, en restreignant les types de choix, en ajoutant des invariants FHIRPath et en limitant les cibles de référence. Un profil ne peut pas ajouter d'éléments, renommer quoi que ce soit ou assouplir la spécification de base.
| Contrainte | Ce qu'elle fait | Exemple |
|---|---|---|
| Cardinalité | Rend les éléments optionnels obligatoires, ou les interdit | Patient.identifier 1..*; Patient.photo 0..0 |
| Doit être pris en charge | Les récepteurs doivent pouvoir stocker et afficher l'élément s'il est envoyé | US Core marque birthDate comme "doit être pris en charge" |
| Valeur fixe ou modèle | Verrouille un élément sur une seule valeur | Observation.category fixé à vital-signs |
| Liaison | Associe un élément à un ensemble de valeurs avec une force | Observation.code lié à la liste des signes vitaux, requis |
| Découpage (Slicing) | Divise une liste en parties nommées avec leurs propres règles | Pression artérielle : composant découpé en systolique et diastolique |
| Restriction de type | Limite un choix | value[x] restreint à valueQuantity |
| Invariant | Une règle FHIRPath qui doit être respectée | "effective[x] doit être présent" ou "value ou dataAbsentReason" |
| Cible de référence | Limite ce à quoi une référence peut pointer | subject uniquement Patient, et uniquement les patients conformes à ce profil |
Un profil ne peut que restreindre. Il ne peut pas ajouter d'éléments (c'est le rôle des extensions), renommer quoi que ce soit ou assouplir la base.
Force de liaison (Binding strength)
FHIR définit quatre forces de liaison. required : le code doit provenir du jeu de valeurs. extensible : utilisez le jeu de valeurs si un concept correspond ; sinon, un autre code est autorisé. preferred : recommandé, mais pas obligatoire. example : à titre illustratif uniquement, ce qui est le cas pour la plupart des ressources de base. Mal interpréter extensible comme required est une source fréquente d'erreurs de validation erronées.
Extrait de profil lisible
Un profil FHIR est une StructureDefinition dont la différentielle ne liste que les contraintes qui diffèrent de la ressource de base, tandis que son instantané liste chaque élément. L'extrait lisible ci-dessous contraint une Observation à une tension artérielle à domicile : le code est fixé à LOINC 85354-9 et le composant est découpé en une partie systolique et une partie diastolique exactes.
Le différentiel d'un profil ne liste que ce qui a changé par rapport à la base ; le snapshot liste tout. Ce différentiel indique qu'une Observation de pression artérielle doit porter le LOINC 85354-9 et exactement deux composantes :
{
"resourceType": "StructureDefinition",
"url": "https://example.org/fhir/StructureDefinition/bp-home",
"name": "HomeBloodPressure",
"status": "active",
"kind": "resource",
"abstract": false,
"type": "Observation",
"baseDefinition": "http://hl7.org/fhir/StructureDefinition/Observation",
"derivation": "constraint",
"differential": {"element": [
{"id": "Observation.code", "path": "Observation.code",
"patternCodeableConcept": {"coding": [{"system": "http://loinc.org", "code": "85354-9"}]}},
{"id": "Observation.component", "path": "Observation.component", "min": 2, "max": "2",
"slicing": {"discriminator": [{"type": "pattern", "path": "code"}], "rules": "closed"}},
{"id": "Observation.component:systolic", "path": "Observation.component", "sliceName": "systolic", "min": 1, "max": "1"},
{"id": "Observation.component:systolic.code", "path": "Observation.component.code",
"patternCodeableConcept": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}},
{"id": "Observation.component:diastolic", "path": "Observation.component", "sliceName": "diastolic", "min": 1, "max": "1"},
{"id": "Observation.component:diastolic.code", "path": "Observation.component.code",
"patternCodeableConcept": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}}
]}
}
Les profils sont rarement écrits à la main ; les auteurs utilisent FHIR Shorthand (FSH) avec SUSHI, ou des outils tels que Forge et Simplifier, et publient avec l'IG Publisher de HL7. Les guides sont distribués sous forme de paquets (hl7.fhir.us.core#6.1.0, hl7.fhir.uv.ips#1.1.0) que les validateurs et les serveurs chargent.
Extensions
Une extension est un élément clé-valeur placé dans extension (ou modifierExtension lorsqu'il modifie le sens de la ressource et ne doit pas être ignoré). Son url est l'URL canonique de sa StructureDefinition ; sa valeur est un value[x] typé, ou des extensions imbriquées. Le lieu de naissance est une extension définie par HL7 sur Patient :
{
"resourceType": "Patient",
"id": "example",
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/patient-birthPlace",
"valueAddress": {"city": "Lyon", "country": "FR"}
}],
"name": [{"family": "Doe", "given": ["Jane"]}]
}
Règles de bonnes pratiques : recherchez une extension existante (le registre HL7 et les guides nationaux) avant d'en définir une ; donnez-lui une URL sous un domaine que vous contrôlez ; définissez-la dans une StructureDefinition afin que d'autres puissent la valider ; n'utilisez jamais une extension pour quelque chose qu'un élément de base couvre déjà.
meta.profile et validation
meta.profile est la liste des URL canoniques auxquelles une ressource FHIR prétend être conforme, et prétendre n'est pas prouver. Un validateur vérifie la ressource par rapport à la spécification de base et par rapport à chaque profil revendiqué, ou par rapport à un profil que vous nommez. Le validateur de référence HL7 s'exécute localement avec des packages, et les serveurs FHIR exposent une opération $validate qui accepte un paramètre de profil.
meta.profile liste les URL canoniques auxquelles une ressource prétend être conforme. Prétendre n'est pas prouver : un validateur vérifie la ressource par rapport à la spécification de base et par rapport à chaque profil revendiqué (ou par rapport à un profil que vous lui demandez d'utiliser). Le validateur de référence HL7 (validator_cli.jar) s'exécute localement et charge des paquets ; les serveurs proposent POST /Observation/$validate?profile=… ; l'IG Publisher valide tous les exemples d'un guide. Une ressource peut être conforme à plusieurs profils à la fois (un profil national Patient et le profil Patient IPS) tant qu'ils ne se contredisent pas.
Deux règles pratiques : un serveur qui déclare un profil dans sa CapabilityStatement doit rejeter les ressources qui ne le respectent pas ; un client qui reçoit des ressources ne doit pas rejeter les extensions inconnues ou les éléments supplémentaires qu'un profil n'a pas interdits, car la spécification de base les autorise.
Dans Anpheros
Anpheros Platform est un serveur FHIR R4 qui utilise LOINC pour les observations, ATC pour les médicaments et SNOMED CT lorsque applicable, et propose un validateur gratuit qui vérifie la structure d'une ressource par rapport à FHIR R4. Lorsqu'une clinique envoie des ressources avec meta.profile défini sur un profil national ou IPS, la revendication est préservée afin qu'un système en aval puisse la valider.
Le validateur gratuit se trouve sur le site développeur. Pour les guides eux-mêmes, consultez Explication des guides d'implémentation FHIR.
Pages associées
- Les guides d'implémentation FHIR expliqués
- CodeableConcept et Coding dans FHIR
- La ressource Observation FHIR expliquée
- La ressource Patient FHIR expliquée
- Serveurs de terminologie expliqués
- Validateur FHIR (site développeur)
Sources
- HL7 FHIR R4 : Profilage de FHIR
- HL7 FHIR R4 : Extensibilité
- HL7 FHIR R4 : StructureDefinition
- HL7 FHIR R4 : Liaisons de terminologie
- HL7 FHIR Shorthand
- Validateur HL7 FHIR
- HL7 FHIR R4 : extension patient-birthPlace
Questions fréquentes
Un profil peut-il ajouter un nouvel élément à une ressource ?
Non. Les profils ne font que contraindre. Les nouvelles données vont dans une extension, que le profil peut ensuite exiger ou interdire comme tout autre élément.
Que requiert réellement "doit être pris en charge" ?
Le guide d'implémentation le définit ; généralement, qu'un expéditeur peuple l'élément lorsqu'il dispose des données et qu'un récepteur le stocke et peut l'afficher. Cela ne rend pas l'élément obligatoire.
Si une ressource n'a pas de meta.profile, est-elle invalide ?
Non. meta.profile est une revendication, pas une exigence. Un serveur ou un guide peut l'exiger ; la spécification de base ne le fait pas. Les validateurs peuvent être invités à vérifier par rapport à un profil que la ressource ne déclare pas.
Comment savoir quel profil utiliser dans mon pays ?
Chaque communauté FHIR nationale publie un guide principal (US Core, UK Core, nl-core, les Basisprofile allemands, etc.) ; la page des guides d'implémentation explique comment les trouver. Les résumés transfrontaliers utilisent l'IPS.
Essayez gratuitement dans le sandbox
Votre premier appel FHIR en 5 minutes. Une API HL7 FHIR R4 avec le consentement du patient intégré : essayez-la dans le bac à sable, puis connectez votre propre application ou système de clinique.
Gratuit · 30 patients synthétiques · sans carte
Anpheros développe un dossier médical que le patient contrôle et peut partager avec n'importe quelle clinique, sur une plateforme HL7 FHIR R4, basée en UE. Ces guides vous aident à comprendre et organiser votre santé ; ils ne remplacent pas votre médecin.
À propos d'Anpheros →