Kurze Antwort: Die grundlegenden FHIR-Ressourcen sind bewusst flexibel gestaltet: Fast alles ist optional und die meisten Codes sind nur Beispiele, damit ein Standard für jedes Land passt. Ein Profil ist eine StructureDefinition, die eine Ressource für einen bestimmten Zweck einschränkt: in diesem Kontext muss Patient eine Kennung dieses Typs haben, Observation.code muss ein LOINC-Code aus dieser Liste sein, dieses Element muss unterstützt werden, jenes darf nicht vorkommen. Eine Erweiterung fügt ein Element hinzu, das der Basisressource fehlt, identifiziert durch eine URL und definiert durch ihre eigene StructureDefinition. Implementierungsleitfäden (US Core, IPS, nationale Leitfäden) sind Sammlungen von Profilen, Erweiterungen, Wertesätzen und Beispielen. Eine Ressource gibt in meta.profile an, welche Profile sie zu erfüllen beansprucht, und ein Validator prüft sie.
Was ein Profil ändern kann
Ein FHIR-Profil kann eine Ressource nur ändern, indem es sie einschränkt: Kardinalität verschärfen, Elemente als „must-support“ markieren, Werte oder Muster festlegen, Elemente mit einer Bindungsstärke an Wertesätze binden, Listen in benannte Teile aufteilen, Auswahltypen einschränken, FHIRPath-Invarianten hinzufügen und Referenzziele begrenzen. Ein Profil kann keine Elemente hinzufügen, nichts umbenennen oder die Basisspezifikation lockern.
| Einschränkung | Was es tut | Beispiel |
|---|---|---|
| Kardinalität | Optionale Elemente zu Pflichtelementen machen oder sie verbieten | Patient.identifier 1..*; Patient.photo 0..0 |
| Muss unterstützt werden | Empfänger müssen das Element speichern und anzeigen können, wenn es gesendet wird | US Core markiert birthDate als "muss unterstützt werden" |
| Fester Wert oder Muster | Ein Element auf einen einzigen Wert festlegen | Observation.category auf vital-signs festgelegt |
| Bindung | Ein Element an einen Wertesatz mit einer Stärke binden | Observation.code an die Liste der Vitalzeichen gebunden, erforderlich |
| Slicing | Eine Liste in benannte Teile mit eigenen Regeln aufteilen | Blutdruck: Komponente in systolisch und diastolisch aufgeteilt |
| Typbeschränkung | Eine Auswahl einschränken | value[x] auf valueQuantity beschränkt |
| Invariante Regel | Eine FHIRPath-Regel, die eingehalten werden muss | "effective[x] muss vorhanden sein" oder "value oder dataAbsentReason" |
| Referenzziel | Einschränken, worauf eine Referenz zeigen darf | subject nur Patient, und nur Patienten, die diesem Profil entsprechen |
Ein Profil kann nur einschränken. Es kann keine Elemente hinzufügen (dafür sind Erweiterungen da), nichts umbenennen oder die Basis lockern.
Bindungsstärke
FHIR definiert vier Bindungsstärken. required: Der Code muss aus dem Wertesatz stammen. extensible: Verwenden Sie den Wertesatz, wenn ein Konzept passt; andernfalls ist ein anderer Code zulässig. preferred: Empfohlen, aber nicht erzwungen. example: Nur zur Veranschaulichung, was die meisten Basisressourcen haben. Das Missverständnis von extensible als required ist eine häufige Ursache für falsche Validierungsfehler.
Ein lesbarer Profilauszug
Ein FHIR-Profil ist eine StructureDefinition, deren Differential nur die Einschränkungen auflistet, die von der Basisressource abweichen, während ihr Snapshot jedes Element auflistet. Der lesbare Auszug unten schränkt Observation auf einen häuslichen Blutdruck ein: Der Code ist auf LOINC 85354-9 festgelegt und die Komponente ist in genau einen systolischen und einen diastolischen Teil aufgeteilt.
Das Differential eines Profils listet nur auf, was sich von der Basis geändert hat; der Snapshot listet alles auf. Dieses Differential besagt, dass eine Blutdruck-Observation LOINC 85354-9 und genau zwei Komponenten tragen muss:
{
"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"}]}}
]}
}
Profile werden selten von Hand geschrieben; Autoren verwenden FHIR Shorthand (FSH) mit SUSHI oder Tools wie Forge und Simplifier und veröffentlichen mit dem HL7 IG Publisher. Leitfäden werden als Pakete (hl7.fhir.us.core#6.1.0, hl7.fhir.uv.ips#1.1.0) verteilt, die Validatoren und Server laden.
Erweiterungen
Eine Erweiterung ist ein Schlüssel-Wert-Element, das in extension (oder modifierExtension, wenn es die Bedeutung der Ressource ändert und nicht ignoriert werden darf) platziert wird. Seine url ist die kanonische URL seiner StructureDefinition; sein Wert ist ein typisiertes value[x] oder verschachtelte Erweiterungen. Geburtsort ist eine von HL7 definierte Erweiterung für Patient:
{
"resourceType": "Patient",
"id": "example",
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/patient-birthPlace",
"valueAddress": {"city": "Lyon", "country": "FR"}
}],
"name": [{"family": "Doe", "given": ["Jane"]}]
}
Regeln guter Praxis: Suchen Sie nach einer vorhandenen Erweiterung (HL7-Registrierung und nationale Leitfäden), bevor Sie eine definieren; geben Sie ihr eine URL unter einer Domäne, die Sie kontrollieren; definieren Sie sie in einer StructureDefinition, damit andere sie validieren können; verwenden Sie niemals eine Erweiterung für etwas, das ein Basiselement bereits abdeckt.
meta.profile und Validierung
meta.profile ist die Liste der kanonischen URLs, die eine FHIR-Ressource als konform beansprucht, und Beanspruchung ist kein Beweis. Ein Validator prüft die Ressource gegen die Basisspezifikation und gegen jedes beanspruchte Profil oder gegen ein von Ihnen benanntes Profil. Der HL7-Referenzvalidator läuft lokal mit Paketen, und FHIR-Server bieten eine $validate-Operation an, die einen Profilparameter akzeptiert.
meta.profile listet die kanonischen URLs auf, denen eine Ressource zu entsprechen beansprucht. Beanspruchung ist kein Beweis: Ein Validator prüft die Ressource gegen die Basisspezifikation und gegen jedes beanspruchte Profil (oder gegen ein Profil, das Sie zur Verwendung angeben). Der HL7 Referenzvalidator (validator_cli.jar) läuft lokal und lädt Pakete; Server bieten POST /Observation/$validate?profile=…; der IG Publisher validiert alle Beispiele in einem Leitfaden. Eine Ressource kann mehreren Profilen gleichzeitig entsprechen (ein nationales Patientenprofil und das IPS-Patientenprofil), solange sie sich nicht widersprechen.
Zwei praktische Regeln: Ein Server, der ein Profil in seiner CapabilityStatement deklariert, sollte Ressourcen zurückweisen, die es nicht erfüllen; ein Client, der Ressourcen empfängt, sollte keine unbekannten Erweiterungen oder zusätzlichen Elemente zurückweisen, die ein Profil nicht verboten hat, da die Basisspezifikation diese zulässt.
In Anpheros
Die Anpheros Platform ist ein FHIR R4-Server, der LOINC für Beobachtungen, ATC für Medikamente und SNOMED CT, wo zutreffend, verwendet und einen kostenlosen Validator anbietet, der die Struktur einer Ressource gegen FHIR R4 prüft. Wenn eine Klinik Ressourcen mit meta.profile, die auf ein nationales oder IPS-Profil gesetzt sind, sendet, bleibt die Beanspruchung erhalten, sodass ein nachgelagertes System dagegen validieren kann.
Der kostenlose Validator befindet sich auf der Entwicklerseite. Die Anleitungen selbst finden Sie unter FHIR-Implementierungsleitfäden erklärt.
Verwandte Seiten
- FHIR-Implementierungsleitfäden erklärt
- CodeableConcept und Coding in FHIR
- FHIR Observation erklärt
- FHIR Patient-Ressource erklärt
- Terminologieserver erklärt
- FHIR-Validator (Entwicklerseite)
Quellen
- 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
Häufige Fragen
Kann ein Profil ein neues Element zu einer Ressource hinzufügen?
Nein. Profile schränken nur ein. Neue Daten kommen in eine Erweiterung, die das Profil dann wie jedes andere Element verlangen oder verbieten kann.
Was genau erfordert "muss unterstützt werden"?
Der Implementierungsleitfaden definiert es; typischerweise, dass ein Sender das Element befüllt, wenn er die Daten hat, und ein Empfänger es speichert und anzeigen kann. Es macht das Element nicht zwingend erforderlich.
Wenn eine Ressource kein meta.profile hat, ist sie dann ungültig?
Nein. meta.profile ist eine Beanspruchung, keine Anforderung. Ein Server oder Leitfaden kann es verlangen; die Basisspezifikation nicht. Validatoren können gebeten werden, gegen ein Profil zu prüfen, das die Ressource nicht deklariert.
Woher weiß ich, welches Profil ich in meinem Land verwenden soll?
Jede nationale FHIR-Community veröffentlicht einen Kernleitfaden (US Core, UK Core, nl-core, die deutschen Basisprofile usw.); die Seite mit den Implementierungsleitfäden erklärt, wie man sie findet. Grenzüberschreitende Zusammenfassungen verwenden das IPS.
Kostenlos in der Sandbox testen
Ihr erster FHIR-Aufruf in 5 Minuten. Eine HL7 FHIR R4 API mit der Zustimmung des Patienten: probieren Sie sie in der Sandbox aus und verbinden Sie dann Ihre eigene App oder Ihr Kliniksystem.
Kostenlos · 30 synthetische Patienten · keine Karte

