Risposta breve: le risorse FHIR di base sono volutamente flessibili: quasi tutto è opzionale e la maggior parte dei codici sono solo esempi, in modo che uno standard si adatti a ogni paese. Un profilo è una StructureDefinition che definisce in modo più restrittivo una risorsa per un determinato uso: in questo contesto, Patient deve avere un identificatore di questo tipo, Observation.code deve essere un codice LOINC da questa lista, questo elemento deve essere supportato, quello invece non può apparire. Un'estensione aggiunge un elemento che manca alla risorsa di base, identificato da un URL e definito dalla sua stessa StructureDefinition. Le guide di implementazione (US Core, l'IPS, guide nazionali) sono raccolte di profili, estensioni, value set ed esempi. Una risorsa indica quali profili dichiara di seguire in meta.profile, e un validatore la controlla.
Cosa può cambiare un profilo
Un profilo FHIR può modificare una risorsa solo restringendola: modificando la cardinalità, contrassegnando gli elementi come "must-support" (devono essere supportati), fissando valori o pattern, associando elementi a value set con una forza specifica, suddividendo elenchi in parti nominate, limitando i tipi di scelta, aggiungendo invarianti FHIRPath e limitando i target di riferimento. Un profilo non può aggiungere elementi, rinominare nulla o allentare la specifica di base.
| Vincolo | Cosa fa | Esempio |
|---|---|---|
| Cardinalità | Rende obbligatori elementi opzionali o li vieta | Patient.identifier 1..*; Patient.photo 0..0 |
| Must support | I ricevitori devono essere in grado di memorizzare e visualizzare l'elemento se inviato | US Core contrassegna birthDate come must-support |
| Valore fisso o pattern | Blocca un elemento a un singolo valore | Observation.category fissato a vital-signs |
| Binding | Collega un elemento a un value set con una forza specifica | Observation.code collegato alla lista dei segni vitali, obbligatorio |
| Slicing | Suddivide una lista in parti nominate con regole proprie | Pressione sanguigna: componente suddivisa in sistolica e diastolica |
| Restrizione del tipo | Limita una scelta | value[x] ristretto a valueQuantity |
| Invariante | Una regola FHIRPath che deve essere rispettata | "effective[x] must be present" o "value or dataAbsentReason" |
| Target del riferimento | Limita a cosa un riferimento può puntare | subject solo Patient, e solo pazienti conformi a questo profilo |
Un profilo può solo restringere. Non può aggiungere elementi (per questo servono le estensioni), rinominare nulla o allentare le regole di base.
Forza del binding
FHIR definisce quattro livelli di forza per il binding. required (obbligatorio): il codice deve provenire dal value set. extensible (estensibile): usa il value set se un concetto è appropriato; altrimenti è consentito un altro codice. preferred (preferito): raccomandato, ma non imposto. example (esempio): solo illustrativo, che è ciò che la maggior parte delle risorse di base hanno. Interpretare erroneamente extensible come required è una fonte comune di errori di validazione errati.
Estratto di un profilo leggibile
Un profilo FHIR è una StructureDefinition la cui "differential" elenca solo i vincoli che differiscono dalla risorsa di base, mentre la sua "snapshot" elenca ogni elemento. L'estratto leggibile qui sotto vincola una Observation alla pressione sanguigna domiciliare: il codice è fissato a LOINC 85354-9 e il componente è suddiviso esattamente in una parte sistolica e una diastolica.
Il differenziale di un profilo elenca solo ciò che è cambiato rispetto alla base; lo snapshot elenca tutto. Questo differenziale indica che un'Observation di pressione sanguigna deve contenere LOINC 85354-9 e esattamente due componenti:
{
"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"}]}}
]}
}
I profili sono raramente scritti a mano; gli autori usano FHIR Shorthand (FSH) con SUSHI, o strumenti come Forge e Simplifier, e pubblicano con l'IG Publisher di HL7. Le guide sono distribuite come pacchetti (hl7.fhir.us.core#6.1.0, hl7.fhir.uv.ips#1.1.0) che i validatori e i server caricano.
Estensioni
Un'estensione è un elemento chiave-valore posto in extension (o modifierExtension quando cambia il significato della risorsa e non deve essere ignorato). Il suo url è l'URL canonico della sua StructureDefinition; il suo valore è un value[x] tipizzato, o estensioni annidate. Il luogo di nascita è un'estensione definita da HL7 su Patient:
{
"resourceType": "Patient",
"id": "example",
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/patient-birthPlace",
"valueAddress": {"city": "Lyon", "country": "FR"}
}],
"name": [{"family": "Doe", "given": ["Jane"]}]
}
Regole di buona pratica: cerca un'estensione esistente (il registro di HL7 e le guide nazionali) prima di definirne una; assegnale un URL sotto un dominio che controlli; definiscila in una StructureDefinition in modo che altri possano validarla; non usare mai un'estensione per qualcosa che un elemento di base già copre.
meta.profile e validazione
meta.profile è l'elenco degli URL canonici a cui una risorsa FHIR dichiara di conformarsi, e dichiarare non è dimostrare. Un validatore controlla la risorsa rispetto alla specifica di base e rispetto a ciascun profilo dichiarato, o rispetto a un profilo da te indicato. Il validatore di riferimento HL7 viene eseguito localmente con i pacchetti, e i server FHIR espongono un'operazione $validate che accetta un parametro di profilo.
meta.profile elenca gli URL canonici a cui una risorsa dichiara di conformarsi. Dichiarare non è provare: un validatore controlla la risorsa rispetto alla specifica di base e rispetto a ogni profilo dichiarato (o rispetto a un profilo che gli chiedi di usare). Il validatore di riferimento di HL7 (validator_cli.jar) viene eseguito localmente e carica pacchetti; i server offrono POST /Observation/$validate?profile=…; l'IG Publisher valida tutti gli esempi in una guida. Una risorsa può conformarsi a più profili contemporaneamente (un profilo nazionale Patient e l'IPS Patient) purché non si contraddicano.
Due regole pratiche: un server che dichiara un profilo nella sua CapabilityStatement dovrebbe rifiutare le risorse che non lo rispettano; un client che riceve risorse non dovrebbe rifiutare estensioni sconosciute o elementi aggiuntivi che un profilo non ha vietato, perché la specifica di base li consente.
In Anpheros
Anpheros Platform è un server FHIR R4 che utilizza LOINC per le osservazioni, ATC per i farmaci e SNOMED CT dove applicabile, e offre un validatore gratuito che controlla la struttura di una risorsa rispetto a FHIR R4. Quando una clinica invia risorse con meta.profile impostato su un profilo nazionale o IPS, la dichiarazione viene mantenuta in modo che un sistema a valle possa validarla.
Il validatore gratuito si trova sul sito per sviluppatori. Per le guide stesse, consulta Le guide all'implementazione FHIR spiegate.
Pagine correlate
- Spiegazione delle guide di implementazione FHIR
- CodeableConcept e Coding in FHIR
- Spiegazione della risorsa Observation FHIR
- Spiegazione della risorsa Patient FHIR
- Spiegazione dei server di terminologia
- Validatore FHIR (sito sviluppatori)
Fonti
- HL7 FHIR R4: Profiling FHIR
- HL7 FHIR R4: Extensibility
- HL7 FHIR R4: StructureDefinition
- HL7 FHIR R4: Terminology bindings
- HL7 FHIR Shorthand
- HL7 FHIR validator
- HL7 FHIR R4: patient-birthPlace extension
Domande frequenti
Un profilo può aggiungere un nuovo elemento a una risorsa?
No. I profili solo vincolano. Nuovi dati vanno in un'estensione, che il profilo può poi richiedere o vietare come qualsiasi altro elemento.
Cosa richiede effettivamente must-support?
La guida di implementazione lo definisce; tipicamente che un mittente popoli l'elemento quando ha i dati e un ricevitore lo memorizzi e possa visualizzarlo. Non rende l'elemento obbligatorio.
Se una risorsa non ha meta.profile, è invalida?
No. meta.profile è una dichiarazione, non un requisito. Un server o una guida possono richiederlo; la specifica di base no. I validatori possono essere richiesti di controllare rispetto a un profilo che la risorsa non dichiara.
Come faccio a sapere quale profilo usare nel mio paese?
Ogni comunità FHIR nazionale pubblica una guida principale (US Core, UK Core, nl-core, i Basisprofile tedeschi, ecc.); la pagina delle guide di implementazione spiega come trovarle. I riassunti transfrontalieri utilizzano l'IPS.
Provalo gratis nella sandbox
La tua prima chiamata FHIR in 5 minuti. Un'API HL7 FHIR R4 con il consenso del paziente integrato: provala nella sandbox, poi collega la tua app o il sistema della tua clinica.
Gratis · 30 pazienti sintetici · senza carta
Anpheros sviluppa una cartella clinica che il paziente controlla e può condividere con qualsiasi studio medico, su una piattaforma HL7 FHIR R4, con sede in UE. Queste guide ti aiutano a comprendere e organizzare la tua salute; non sostituiscono il tuo medico.
Chi siamo →