ANS IG document core
0.1.0-snapshot - ci-build
ANS IG document core
0.1.0-snapshot - ci-build
ANS IG document core - version de développement local (intégration continue v0.1.0-snapshot) construite par les outils de publication FHIR (HL7® FHIR® Standard). Voir le répertoire des versions publiées
FHIR® est un standard d’échange de données de santé publié par HL7® Pour en savoir plus, voir https://hl7.org/fhir/R4/index.html.
Les ressources FHIR peuvent être utilisées pour créer des documents sous la forme d’une composition : un ensemble cohérent d’informations rédigées et/ou attestées par des humains, des organisations ou des dispositifs et enregistrées dans des ressources.
Les documents FHIR peuvent être échangés entre les systèmes et conservés dans des plateformes de partage.
Les documents au format FHIR doivent respecter les spécifications FHIR Document (R4).
Un guide d’implémentation FHIR Clinical Documents produit par HL7 vient en support du standard.
Un document FHIR, par sa conception, permet de respecter les exigences spécifiques aux documents dématérialisés énoncées au paragraphe “Exigences spécifiques aux documents dématérialisés”.
Le standard FHIR permet de coupler dans un même document :
D’un point de vue technique, un document FHIR est un Bundle de type “document” contenant une première ressource Composition suivie d’autres ressources référencées dans la Composition. La Composition est similaire à un index, mais contient également des informations d’entête clés.
Le Bundle rassemble tout le contenu du document dans un seul document XML ou JSON qui peut être signé et géré selon les besoins.
Un document conforme au standard FHIR se compose :
Les éléments du Bundle et de la Composition rassemblent les informations générales et nécessaires à la gestion du document (cela correspond à l’entête d’un document CDA). Ces informations permettent de relier le document au contexte dans lequel il a été produit, de le classer dans les catégories adéquates et de gérer son évolution et son accessibilité dans la durée. La structure de base Bundle/Composition est identique quel que soit le type de document et quel que soit le degré de structuration choisi.
Les éléments du Bundle et de la Composition portent sur :
La ressource Composition contient les différentes sections du document dans des ressources Composition.section (l’ensemble de ces ressources Composition.section correspond au corps d’un document CDA).
Une Composition.section peut contenir :
Exemple :
<Binary>
<contentType value="application/pdf"/>
<language value="fr"/>
<data value="/9j/4...KAP//Z" /> <!-- document encodé en B64 -->
<title value="Document PDF"/>
</Binary>
Des données structurées : La section est organisée en structures de données afin de permettre les traitements informatiques. Chacune de ces sections possède un code (élément section.code), un titre (élément section.title) et un bloc narratif (élément section.text). En outre une section peut contenir des sous-sections (élément section.section) et des entrées (élément section.entry) fournissant les données du SI producteur à l’aide desquelles a été construit le bloc narratif. Ces données sont codées et structurées, importables et intégrables dans la base de données des SI consommateurs du document.
Une section DOIT contenir au moins un texte ou une entrée ou une sous-section. Par exemple, une section peut n’avoir que la partie narrative (Composition.section.text) et pas de sous-section, ni d’entrée.
Une section ne peut avoir un section.emptyReason que si elle est vide.
Les sous-sections FHIR ne peuvent pas contenir de partie narrative. Toute la partie narrative est dans la section de 1er niveau.
Les entrées des sections sont des références à d’autres ressources qui contiennent les données de l’entrée.
Les sections peuvent être slicées pour les préciser. Par exemple, dans un CR-BIO (ex HL7 Europe Laboratory Report), on pourra avoir les sections suivantes :
Les entrées peuvent aussi être profilées : Par exemple, dans un CR-BIO (ex HL7 Europe Laboratory Report), on pourra avoir les entrées suivantes :
Les spécifications françaises des documents FHIR définies dans le CI-SIS :
Pour être conforme aux exigences françaises de l’entête, un document FHIR DOIT respecter les profils suivants :
Les ressources référencées dans l’entête du document DOIVENT également respecter les profils français spécifiques :
Ces profils portent les exigences complémentaires et spécifiques au contexte français, notamment :
Au-delà de la conformité aux exigences générales de l’entête, chaque volet de contenu du CI-SIS définit un modèle de document spécifique adapté à un contexte métier particulier.
Pour être conforme à un modèle de document spécifique, un document FHIR DOIT :
Composition.type) : code fixé ou contraint selon la nomenclature du voletComposition.meta.profile en référençant le profil canonique du voletLa norme FHIR permet d’indiquer de façon optionnelle le rattachement d’une section et/ou d’une entrée d’un document FHIR à une personne différente du patient/usager. Dans ce cas, elle remplace la personne décrite au niveau supérieur.
Chaque entrée d’un document peut avoir un subject. Si l’entrée ne contient pas de subject, l’entrée concerne la personne indiquée dans l’élément Composition.section.focus de la section. Si la section ne contient pas d’élément Composition.section.focus, la section concerne la personne indiquée dans l’élément subject du document. C’est le principe de propagation du contexte et qui part du document vers les sections, sous-sections, entrées et sous-entrées emboitées.
En FHIR, l’élément section.emptyReason permet d’indiquer la raison pour laquelle une section est vide, c’est-à-dire qu’elle ne contient aucune entrée structurée. Son utilisation est conditionnée par le caractère obligatoire de la section dans le modèle de document.
Pour les sections obligatoires (ex : Allergies et intolérances, Problèmes, Traitements), lorsqu’aucune entrée structurée n’est fournie, l’élément section.emptyReason DOIT être renseigné avec une valeur issue du JDV list-empty-reason.
| Code | Libellé | Définition |
|---|---|---|
nilknown |
Pas d’élément connu | Constatation clinique d’un professionnel de santé concluant, après investigation, à l’absence d’éléments connus pour cette donnée. Cette valeur ne peut pas être fournie par défaut par un SIS en l’absence d’informations. Exemples : - Allergies : le patient ou son représentant a déclaré n’avoir connaissance d’aucune allergie. - Médicaments : le patient déclare ne prendre aucun médicament. - Diagnostics / problèmes : le patient déclare qu’aucun événement connu ne doit être enregistré. |
notasked |
Non demandé | Aucune investigation n’a été menée pour déterminer s’il existe des éléments pour cette liste. |
withheld |
Non divulgué | Aucune information n’est fournie pour des raisons de confidentialité. Cela ne signifie pas nécessairement que le contenu est sensible ; il peut s’agir d’une décision personnelle du patient. |
unavailable |
Indisponible | L’information est indisponible au moment de la production du document (ex : patient inconscient). |
notstarted |
Non démarré | Les actions permettant d’obtenir cette information n’ont pas encore démarré. |
closed |
Fermé | Cette liste est désormais fermée ou n’est plus pertinente ni utile. |
Lorsqu’aucune donnée n’est disponible pour une section facultative, le producteur ne doit pas créer la section. L’élément section.emptyReason ne s’applique pas aux sections facultatives absentes.
En résumé : section.emptyReason s’applique uniquement aux sections obligatoires vides. Pour les sections facultatives, l’absence de données se traduit simplement par l’absence de la section dans le document.
En FHIR, l’absence d’une valeur dans un élément doit être gérée de manière explicite lorsque cela est requis. Les règles diffèrent selon la cardinalité de l’élément et selon que la donnée est codée ou non.
(cardinalité 0..1 ou 0..*)
Si l’information n’est pas disponible, quelle que soit la raison, ne pas créer l’élément. L’absence de l’élément dans la ressource est suffisante pour exprimer l’indisponibilité.
(cardinalité 1..1 ou 1..*)
Si l’information n’est pas disponible, le motif de l’absence DOIT être précisé via les mécanismes décrits ci-dessous.
Utiliser l’extension Data Absent Reason avec :
"url" : "http://hl7.org/fhir/StructureDefinition/data-absent-reason""valueCode" : valeur issue du ValueSet data-absent-reasonLe ValueSet data-absent-reason contient les valeurs suivantes :
| Lvl | Code | Libellé | Définition |
|---|---|---|---|
| 0 | unknown |
Inconnu | Valeur inconnue. |
| 1 | asked-unknown |
Demandé - inconnu | Valeur demandée mais non connue. |
| 1 | temp-unknown |
Temporairement indisponible | Temporairement indisponible (mais pourrait ultérieurement être connue). |
| 1 | not-asked |
Non demandé | Valeur non demandée. |
| 1 | asked-declined |
Demandé - refus de réponse | Valeur demandée / refus de réponse. |
| 0 | masked |
Masqué | Valeur non disponible pour des raisons de sécurité, de confidentialité ou autres. |
| 0 | not-applicable |
Non applicable | Pas de valeur appropriée pour cet élément (par exemple, la date des dernières règles pour un homme). |
| 0 | unsupported |
Non supporté | Le système source ne gère pas cet élément. |
| 0 | as-text |
Voir narratif | Valeur fournie dans la partie narrative. |
| 0 | error |
Erreur | Valeur indisponible due à une erreur système ou de processus. |
| 1 | not-a-number |
Non numérique | La valeur numérique est indéfinie ou non représentable en raison d’une erreur de traitement des nombres à virgule flottante. |
| 1 | negative-infinity |
Borne inférieure infinie | La valeur numérique est excessivement basse et non représentable. |
| 1 | positive-infinity |
Borne supérieure infinie | La valeur numérique est excessivement élevée et non représentable. |
| 0 | not-performed |
Non effectué | La valeur n’est pas disponible car la procédure d’observation n’a pas été effectuée. |
| 0 | not-permitted |
Non autorisé | Cette valeur n’est pas autorisée dans ce contexte (par exemple, en raison des profils ou des types de données de base). |
Exemple : dans une ressource Procedure, lorsque la date d’exécution (performed[x]) est inconnue :
{
"resourceType": "Procedure",
...
"_performedDateTime": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
},
...
}
example, preferred ou extensible)Si l’information n’est pas connue et qu’il existe dans la terminologie ou le ValueSet associé un code d’exception spécifique, utiliser ce code en priorité.
Exemple : code SNOMED CT
1287211007— “No information available”.
Dans les autres cas, utiliser l’extension Data Absent Reason avec la syntaxe suivante :
{
"resourceType": "Observation",
...
"code": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/data-absent-reason",
"code": "masked"
}
]
},
...
}
required)Règle : lorsqu’une donnée est absente, utiliser le code d’exception du ValueSet ou de la terminologie associée. C’est la règle de référence pour une liaison
required.
En pratique, de nombreux ValueSets ou terminologies ne prévoient pas de code d’exception. Dans ce cas, faute de code applicable, utiliser l’extension Data Absent Reason comme mécanisme de repli.
| Situation | Traitement |
|---|---|
Le VS/terminologie contient un code d’exception (ex : unknown dans event-status) |
Utiliser ce code d’exception |
| Le VS/terminologie ne contient aucun code d’exception | Utiliser l’extension data-absent-reason |
Exemples d’instances : Allergies et Procédures :
- L’instance example-allergy-intolerance-data-absent-reason illustre l’usage de l’extension
data-absent-reasonsur les éléments obligatoires du profil FRAllergyIntoleranceDocument lorsque la valeur est inconnue ou temporairement indisponible.- L’instance example-procedure-data-absent-reason illustre les deux cas de figure sur le profil FRProcedureDocument :
extension data-absent-reasonpour les données codées à partir d’un codeSystem/valueSet non obligatoire (example,preferredouextensible) : élémentscode,performedDateTimecode d'exception natifdu ValueSetevent-status(unknown) pour les données codées à partir d’un codeSystem/valueSet obligatoire (required) : élémentstatus
Les documents au format FHIR définis dans le CI-SIS doivent être conformes :
Les documents doivent être conformes aux spécifications françaises de l’entête. Ces spécifications sont communes à l’ensemble des documents FHIR produits en France.
Exemples de volets du CI-SIS :
Guides d’implémentation dédiés par type de document :
Des guides d’implémentation FHIR dédiés à chaque type de document seront créés pour préciser spécifiquement la structure des documents selon leur contexte métier. Ces guides :
Chaque guide d’implémentation dédié précisera :
Une application productrice est autorisée à ajouter dans l’en-tête et dans le corps d’un document qu’elle produit des éléments non prévus dans le modèle dont se réclame le document, à condition que ces éléments restent conformes au standard FHIR.
Une application consommatrice de document n’est pas tenue de traiter les éléments non définis dans le modèle, et dans le cas où elle ne les comprend pas, elle doit les ignorer.
En d’autres termes, ce n’est pas une erreur de mettre dans un document plus d’éléments que n’en spécifie le modèle ; en revanche c’est une erreur de rejeter un tel document.
Cette convention préserve la capacité aux implémentations d’apporter de la valeur ajoutée par rapport aux modèles.
Elle protège en outre la compatibilité ascendante, en permettant que des versions ultérieures d’un modèle apportant des éléments nouveaux, restent compatibles avec des implémentations qui ne connaîtraient qu’une version plus ancienne du modèle.
L’ANS met à disposition des outils permettant de vérifier la conformité des documents FHIR. Voir https://interop.esante.gouv.fr/ig/documentation/tests.html
L’espace de test est composé de deux outils :
Ces outils sont accessibles en ligne sur le site https://interop.esante.gouv.fr/ et notamment utilisés lors des Projectathons organisés par l’ANS pour les éditeurs.
Attention : l’espace de tests ne doit pas être utilisé pour vérifier la conformité de documents de production (produits pour un patient réel).
Matchbox est un outil permettant notamment de valider des instances de ressources FHIR contre un profil.
Ce serveur FHIR open source est particulièrement utile pour importer des profils et tester la validité des ressources générées contre les profils.
FHIR core narrative guidance stipulent que la partie narrative d’une ressource “DOIT refléter tout le contenu de la ressource nécessaire à la compréhension par un humain des informations de cette ressource”.
De plus, pour assurer la compréhension sans ambiguïté de la partie narrative d’un document :
Comme les données de l’entête d’un document CDA, les métadonnées du document (par exemple, nom et date de naissance du patient, participants) doivent pouvoir être affichées.
Les parties narratives d’un document FHIR peuvent être contenues dans Composition.text et dans Composition.section.text. Il est recommandé de transmettre les métadonnées dans Composition.text et les contenus narratifs dans Composition.section.text.
De plus, bien que le destinataire du document doive être en mesure d’afficher le contenu de Composition.section.text, il peut choisir d’afficher ou d’ignorer Composition.text, en particulier lorsqu’il est capable d’analyser les champs structurés de la composition.
En résumé :
Le producteur du document FHIR :
Le consommateur d’un document FHIR :
Les bonnes pratiques recommandent que les éléments suivants soient affichés :