Documentation des guides d'implémentation de l'ANS
0.1.2 - release
Documentation des guides d'implémentation de l'ANS
0.1.2 - release
This page is part of the Documentation des guides d'implémentation de l'ANS (v0.1.2: Release) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 0.1.8. For a full list of available versions, see the Directory of published versions
Avant de commencer à développer un guide d’implémentation, il faut choisir la version FHIR sur laquelle se baser : R4, R4B, R5 ? L’objectif étant d’avoir un écosystème uniforme et simple qui hérite systématiquement de fr-core pour avoir des modélisations les plus cohérentes possibles.
A l’heure actuelle, les spécifications des projets nationaux utilisent la R4 (fr-core, IG ANS, Annuaire, ROR…). Or travailler sur R4 et R5 parallèlement engendre beaucoup de questions : travaux de maintenance doublés, nécessité de maintenir des mappings/connecteurs entre versions (R4 <-> R5, R4 <-> R6, R5 <-> R6, + FHIR/CDA ?), augmentation de la complexité de l’écosystème avec certains acteurs en R4, d’autres en R5… Les ressources étant limitées, il est préférable de se concentrer sur l’amélioration de nos profils nationaux en R4 et de faire monter l’écosystème en compétences.
La release R5 reste cependant intéressante, notamment pour l’amélioration de sa documentation et de certaines ressources (Documentation FHIR Search, Ressources MedicinalProduct…). Ce choix n’est pas tranché, c’est l’écosystème qui dictera quelle version utiliser. Si vous ressentez un besoin d’utiliser R5 (notamment pour des cas d’usages internationaux ou profiter de ressources non matures en R4), nous vous invitons à nous le signaler pour réévaluer le bénéfice/risque de travailler sur FHIR R5. A noter que FHIR R6, dont la première concertation est prévue mi-2024, apportera beaucoup de contenu normatif, et sera peut-être l’objectif de transition.
En conclusion : privilégier R4 pour ne pas être “hors système” et être cohérent avec fr-core et les IGs de l’ANS. Utiliser R5 uniquement si l’écosystème l’exige (ex : héritage d’un IG international en R5, héritage de ressources retravaillées en R5…) et partager ce besoin en issue GitHub.
Pour être intéropérable, il faut tout d’abord éviter la sur-profilisation, c’est à dire créer des profils qui existent déjà. Pour cela, il est nécessaire d’hériter au maximum des profils internationaux, pour que les contraintes et modélisations soit partagées au maximum entre les acteurs répondant à un cas d’usage.
De la même manière, l’usage des extensions est à éviter au maximum. Si leur usage est nécessaire, il est préférable d’hériter d’extensions déjà créées.
Où chercher les profils-extensions déjà créés ?
Ce paragraphe sera complété lorsque le FHIR Terminology Service sera en service.
Ces règles de nommages ont été établies en s’inspirant des ressources us-core
| Attribut | Description | Exemple us-core |
|---|---|---|
| id | utiliser le format kebab-case, ex : fr-patient. (/!\ sur Forge, l’id n’est pas obligatoire, il est important de le rajouter !). Lors de la création d’un IG pour un projet en particulier, il est possible de préfixer l’ensemble des ressources de conformité par le trigramme du projet (ex : “ror-…”) | us-core-patient |
| title | similaire au nom, avec espaces. Ex : Fr Patient | US Core Patient Profile |
| name | Utiliser le format PascalCase sans espace. Ex : FrPatient | USCorePatientProfile |
| url | [base]/[ResourceType]/[id] (généré automatiquement par sushi). A noter que [ResourceType] doit respecter le nom et la casse des ressources définies dans FHIR core (ex: StructureDefinition). | http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient |
| SearchParameter.code | toujours en minuscule, mots séparés par des tirets “-“ si besoin | - |
Nom des slices:
La documentation officielle se trouve sur le confluence d’HL7
L’id de package ne doit pas avoir de majuscule.
Le package doit toujours dépendre de fr-core et/ou les projets de l’ANS pour assurer une cohérence globale à l’échelle française. Ces packages sont publiés sur le FHIR Package Registry et doivent être indiqués dans le fichier sushi-config.yaml. La duplication des fichiers ou la référence par URL est une très mauvaise pratique car on perd tout l’intérêt du versioning.
L’URL canonique est un outil très puissant dans le standard HL7 FHIR, il permet d’identifier de manière unique chaque implementation guide (IG) et chaque profil.
L’URL canonique de l’IG permet d’accéder à sa page web, c’est à dire la spécification narrative et technique (ex : https://www.hl7.org/fhir/us/core). Dans le cas des IG de l’ANS, l’url canonique est https://interop.esante.gouv.fr/ig/[fhir/][code]
A partir de ce lien, il y a une API Rest FHIR, qui permet d’accéder aux ressources de conformité conformément à la FHIR search (https://www.hl7.org/fhir/search.html). On obtient ainsi les url canoniques de chaque profil (ex : http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient). L’URL canonique des profils est construite au format : [base]/[ResourceType]/[id] pour qu’elle corresponde à une requête FHIR Search
L’outil HL7 IG Publisher, combiné avec sushi, gère automatiquement certaines redirections et génère automatiquement les urls des profils à partir de l’url base indiquée.
Ainsi, l’url canonique d’un profil permet de facilement retrouver la spécification d’où elle est issue de manière très efficace et claire.
A noter le ResourceType doit respecter la même casse et le même nom que les ResourceName FHIR.
Documentation :
Sushi et FSH permettent de factoriser beaucoup d’informations, et de les centraliser afin d’en faciliter l’accès et la gestion. Il est recommandé de faire bénéficier au maximum les projets de cette possibilité de centraliser les informations redondantes.
Dans le cas où les structures-definitions d’un projet sont au même niveau de statut ( Active, draft etc…) , il est recommandé de configurer le statut dans le fichier sushi-config.yaml et de supprimer le paramètre “status” renseigné dans les profils.
Idem pour la version du profil.
Le statut et la version des l’ensemble des profils seront renseignées exclusivement dans sushi-config.yaml:
status: active
version: 0.1.3 (utiliser le semver)
Il est recommandé de classer les extensions et les valueSets source (FSH) dans des sous-répertoires spécifiques, input\fsh\Extensions et input\fsh\ValueSets. Les structure-definitions des profils seront placés dans input\fsh.
Les alias FSH sont des variables permettant de définir un raccourci pour une URL ou un OID.
Par exemple, on peut ainsi définir l’alias $phdDevice pour représenter l’URL «http://hl7.org/fhir/uv/phd/StructureDefinition/PhdDevice» et l’utiliser de la manière suivante au sein d’un profil FSH :
Alias: $PhdDevice = http://hl7.org/fhir/uv/phd/StructureDefinition/PhdDevice * device only Reference($PhdDevice)
Par soucis de clarté, il est recommandé de rassembler tous les alias dans un fichier unique, appelé « aliases.fsh » et situé dans le répertoire racine (évite les redondances et facilite la gestion).
Exemple:
Alias: $PhdDevice = http://hl7.org/fhir/uv/phd/StructureDefinition/PhdDevice
Alias: $UCUM = http://unitsofmeasure.org
Alias: $vitalsigns = http://hl7.org/fhir/StructureDefinition/vitalsigns
Alias: $FrObservationBp = http://interopsante.org/fhir/StructureDefinition/FrObservationBp
Alias: $fr-patient = http://interopsante.org/fhir/StructureDefinition/FrPatient
Pour plus d’informations, consultez la liste des guides d’implémentation à titre d’exemple.