ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

StructureDefinition — Méta-modèle de FHIR

La grammaire de FHIR. Chaque ressource, type primitif, type complexe, extension, profil national est défini par une StructureDefinition. Le moteur de tout ce qui est sémantiquement typé en FHIR.

Objet de la ressource

StructureDefinition définit la forme de toute chose typée en FHIR : les ressources publiées par HL7 (Patient, Observation, Bundle…), les types primitifs (string, date), les types complexes (HumanName, Address, Identifier), les extensions personnalisées et les profils nationaux (US Core, FR Core, NL Core…).

Une StructureDefinition est composée d'éléments décrivant chaque chemin (Patient.name.given) avec sa cardinalité, son type, son binding terminologique, ses contraintes FHIRPath, ses slicings, ses examples.

Champs clés

ChampTypeCardinalitéRôle
urluri1..1URL canonique.
identifierIdentifier[]0..*Identifiants métier.
versionstring0..1Version.
namestring1..1Nom technique.
titlestring0..1Titre humain.
statuscode1..1draft | active | retired | unknown.
fhirVersioncode0..1Version FHIR cible.
kindcode1..1primitive-type | complex-type | resource | logical.
abstractboolean1..1Type abstrait ou instanciable.
typeuri1..1Type FHIR sous-jacent (Patient, Observation…).
baseDefinitioncanonical0..1StructureDefinition parente.
derivationcode0..1specialization | constraint.
snapshotBackboneElement0..1Vue complète résolue.
differentialBackboneElement0..1Différentiel par rapport au parent (utilisé pour les profils).

Exemple JSON

json structuredefinition-example.json
{
  "resourceType": "StructureDefinition",
  "id": "us-core-patient",
  "url": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient",
  "version": "7.0.0",
  "name": "USCorePatientProfile",
  "title": "US Core Patient Profile",
  "status": "active",
  "publisher": "HL7 International — US Realm",
  "fhirVersion": "5.0.0",
  "kind": "resource",
  "abstract": false,
  "type": "Patient",
  "baseDefinition": "http://hl7.org/fhir/StructureDefinition/Patient",
  "derivation": "constraint",
  "differential": {
    "element": [{
      "id": "Patient.identifier",
      "path": "Patient.identifier",
      "min": 1
    }, {
      "id": "Patient.name",
      "path": "Patient.name",
      "min": 1
    }]
  }
}

Profils et extensions

  • Profilderivation=constraint restreint une ressource (US Core Patient = Patient + identifier 1..*).
  • Extensionkind=complex-type + type=Extension ajoute un champ ad-hoc à une ressource.
  • Logical modelkind=logical définit un modèle conceptuel (FHIR Shorthand, ABMD).
  • Slicing — découpe d'un champ multiple en sous-types (ex. identifier.use=usual vs official).

Pièges courants

  • Pas de baseDefinition pour un profil — l'éditeur ne sait pas par rapport à quoi valider.
  • Snapshot pas synchronisé — toujours générer le snapshot quand le différentiel change.
  • Slicing mal discriminé — sans discriminator clair, les outils ne peuvent pas trier.

Ressources liées