🔥 So erstellen Sie einen FHIR Implementation Guide

Das Interoperabilitätsproblem

Stellen Sie sich vor, Sie sind Arzt und behandeln einen neuen Patienten, der bereits mehrere Krankenhäuser aufgesucht hat, verschiedene Untersuchungen durchlaufen hat und derzeit mehrere Medikamente einnimmt. Doch all diese wichtigen Informationen sind auf verschiedene Systeme verteilt, die nicht effektiv miteinander kommunizieren. Das ist das Interoperabilitätsproblem im Gesundheitswesen.

IT-Systeme im Gesundheitswesen sind stark fragmentiert. Jedes Krankenhaus, jede Klinik, jedes Labor und jede Versicherungsgesellschaft speichert Patientendaten auf unterschiedliche Weise – mit eigenen Datenbanken, proprietären Formaten und inkompatiblen APIs. Wenn Patienten den Leistungserbringer wechseln, folgt ihnen ihre Krankengeschichte nicht nahtlos. Ihre Laborbefunde befinden sich in einem System, die Rezepte in einem anderen und die Bildgebung in einem dritten. Ärzte verschwenden Zeit mit der Suche nach Informationen oder treffen im schlimmsten Fall Entscheidungen auf Basis unvollständiger Daten.

Jede neue Verbindung zwischen Systemen erfordert individuelle Entwicklungsarbeit. Die Patientenakte aus Krankenhaus „A" sieht völlig anders aus als die aus Klinik „B". APIs sind inkonsistent. Datenformate variieren stark, und wichtige Informationen gehen bei der Übertragung verloren. Allergien, Medikamente und frühere Eingriffe – all das ist über inkompatible Systeme verstreut, die keine kohärenten Nachrichten austauschen können.

Gesundheitsorganisationen werden durch proprietäre Systeme gefesselt. Ein Anbieterwechsel bedeutet, alle Integrationen von Grund auf neu aufzubauen – ein kostspieliges und riskantes Unterfangen, das sich nur wenige leisten können.

FHIR: Die universelle Sprache des Gesundheitswesens

FHIR (Fast Healthcare Interoperability Resources) revolutioniert die Kommunikation zwischen Gesundheitssystemen. Betrachten Sie es als universellen Wortschatz, den jedes Gesundheitssystem verstehen kann. Anstatt individuelle Brücken zwischen jedem Systempaar zu bauen, verbindet sich jede Organisation über dieselbe standardisierte Sprache mit einem FHIR-Server.

Patient, Observation, Medication, Condition – alle Gesundheitsdaten in allen Kliniken verwenden dieselben Ressourcenstrukturen. Ein Patient-Datensatz aus Krankenhaus „A" sieht identisch aus wie einer aus Klinik „B". Keine benutzerdefinierten Parser oder Datentransformationsschichten mehr.

Im Kern ist FHIR eine RESTful-API, sodass jeder FHIR-Server dieselben Operationen unterstützt:

GET /Patient/001 – Patientendaten abrufen
GET /Observation?patient=001&code=blood-pressure – Beobachtungen suchen
POST /Patient – neuen Patientendatensatz anlegen

Dennoch schafft die Flexibilität von FHIR neue Probleme. Die Basis-Patient-Ressource verfügt über 50+ optionale Felder. Welche davon soll Ihre Kinderklinik verpflichtend machen? Ihr Herzzentrums? Ihr Versicherungssystem?

Verschiedene Teams interpretieren die FHIR-Spezifikation auf ihre eigene Weise: Das eine speichert das Patientengewicht in Kilogramm, das andere in Pfund. Ein Labor kodiert Tests mit LOINC, ein anderes erfindet lokale Codes. Suchparameter variieren zwischen den Implementierungen.

Ihr Krankenhaus benötigt wahrscheinlich spezifische Arbeitsabläufe, die das Kern-FHIR nicht abdeckt. Wie setzen Sie Ihre Datenqualitätsregeln durch? Welche benutzerdefinierten Suchoperationen benötigen Ihr klinisches Team und Ihre Integrationssysteme?

Anbieter wählen häufig nur Teilmengen von FHIR aus: System „A" unterstützt die Patient-Suche nach Name; System „B" nicht. Ihre Integration bricht zusammen, wenn Sie den Anbieter wechseln, obwohl beide „FHIR-Konformität" beanspruchen. Ohne Einschränkungen können „FHIR-konforme" Systeme immer noch keine sinnvollen Daten austauschen. Sie erhalten strukturelle Interoperabilität (gleiches JSON-Format), verlieren aber semantische Interoperabilität (gemeinsame Bedeutung).

Deshalb sperrt der nächste Schritt – ein maßgeschneiderter Implementation Guide (IG) – alle Beteiligten auf dasselbe Regelwerk ein und verwandelt FHIRs Versprechen in gelebte Praxis.

Implementation Guide: Ihr FHIR-Regelwerk

Ein FHIR Implementation Guide wandelt die FHIR-Spezifikation in einen eindeutigen, auf Ihre Organisation zugeschnittenen Vertrag um.

Anstatt 50+ optionaler Patient-Felder legt Ihr IG genau fest, welche davon Pflichtfelder sind. Kinderkliniken erfordern Geburtsdatum und Kontaktdaten des Erziehungsberechtigten, während Herzzentren Gewicht und Blutdruckverlauf vorschreiben.

Ihr IG legt fest, dass das Gewicht in Kilogramm erfasst werden muss, Datumsangaben dem ISO-Format folgen und Blutdruckbeobachtungen bestimmte LOINC-Codes verwenden. Kein Raum für Raterei oder inkonsistente Interpretationen.

Über ValueSets und CodeSystems schränkt Ihr IG die Blutgruppe auf gültige Werte ein (A+, B-, O+), Laborcodes auf zugelassene LOINC-Begriffe und Diagnosecodes auf die ICD-10-Teilmenge Ihrer Organisation.

Erweiterungen ermöglichen es Ihnen, „Staatsangehörigkeit", „Ethnizität" oder „Versicherungsstufe" zu erfassen, ohne die FHIR-Kompatibilität zu beeinträchtigen. Daten bleiben strukturiert und durchsuchbar und erfüllen gleichzeitig einzigartige Geschäftsanforderungen.

Ihr IG listet die Suchparameter auf, die jeder Server unterstützen muss. Da jeder Anbieter dasselbe Abfrageset implementiert, können Sie Systeme mit Zuversicht austauschen.

FHIR-Server können eingehende Daten gegen die Profile Ihres Implementation Guide (IG) validieren und unvollständige oder fehlerhafte Datensätze ablehnen, bevor sie in Ihr System gelangen.

Das Ergebnis: „FHIR-konform gemäß unserem IG" bedeutet, dass Systeme wirklich zusammenarbeiten, nicht nur dieselbe JSON-Struktur teilen.

Während FHIR das Fundament bildet, ermöglichen Implementation Guides Ihnen, genau festzulegen, wie Ihre Organisation FHIR einsetzt. Betrachten Sie FHIR als Englisch und Ihren IG als den Stilguide Ihres Unternehmens – dieselbe Sprache, aber mit spezifischen Regeln für Ihren Kontext.

Mit mehreren Diensten, Teams und Anbietern, die mit einem FHIR-Server arbeiten, müssen Sie dafür sorgen, dass alle denselben Dialekt sprechen: welche Felder erforderlich sind, welche Werte zulässig sind, welche APIs unterstützt werden müssen. Das bedeutet, dass eine Krankenhaus-App und ein Versicherungssystem beide mit denselben Patient-Daten arbeiten können, ohne Abstimmungsaufwand. Suchen wie GET /Observation?patient=123&code=loinc|1234-5 verhalten sich bei allen konformen Servern gleich und machen die Integration vorhersehbar.

Terminology: Dieselbe Sprache sprechen

Ein ValueSet und ein CodeSystem sind FHIR-Ressourcen, die Ihre kontrollierten Vokabulare repräsentieren. Sie legen fest, welche Codes in kodierten Feldern zulässig sind, und gewährleisten eine konsistente Terminology im gesamten System.

Warum ist das wichtig? Ein Feld „Blutgruppe" benötigt spezifische Werte wie A+, B-, O+ – keinen beliebigen Text wie „rotes Blut" oder „tolle Gruppe". Verschiedene Bereiche des Gesundheitswesens verwenden unterschiedliche Kodiersysteme – LOINC für Laborbefunde, SNOMED CT für klinische Begriffe, ICD-10-CM für Diagnosen.

Die CodeSystem-Ressource definiert die eigentlichen Codes und ihre Bedeutungen – wie das Erstellen eines domänenspezifischen Wörterbuchs. Anzeigewerte können in mehrere Sprachen übersetzt werden, wobei die beabsichtigte Bedeutung unabhängig von der verwendeten Sprache erhalten bleibt.

Die ValueSet-Ressource wiederum wählt aus, welche Codes aus einem oder mehreren CodeSystems in bestimmten Kontexten zulässig sind – stellen Sie sich ein „Blutgruppe"-ValueSet vor, das nur acht Codes (A+, A‑, B+, B‑, AB+, AB‑, O+, O‑) aus dem viel umfangreicheren SNOMED-Katalog entnimmt. Verschiedene ValueSets, die ihre kontextspezifischen Codes extrahieren, können auf demselben CodeSystem basieren, aber unterschiedliche Arbeitsabläufe bedienen.

Zu den Vorteilen zählen: ausschließlich gültige Codes in kodierten Feldern durchsetzen, Dateneingabefehler durch Validierung verhindern und semantische Interoperabilität ermöglichen, bei der Systeme Bedeutung verstehen, nicht nur Struktur. Anstatt beliebige Zeichenkettenwerte in kodierten Feldern zu akzeptieren, validiert Ihr System gegen vordefinierte Vokabulare und stellt sicher, dass klinische Daten eine standardisierte Terminology verwenden, die andere Systeme korrekt interpretieren können. Dieser kontrollierte Ansatz wandelt das Chaos unstrukturierter Texte in strukturierte, aussagekräftige Daten um, die klinische Entscheidungsfindung, regulatorische Compliance und Datenanalyse/maschinelles Lernen unterstützen.

Schauen wir uns ein praktisches Beispiel an: die Zeitzonenverwaltung in eHealth-Anwendungen. Wenn Ihre Anwendung Patienten in verschiedenen Regionen bedient, erfordert eine präzise Terminplanung Zeitzonenbewusstsein. Die CodeSystem-Ressource von FHIR bietet eine strukturierte Möglichkeit, diese Zeitzonenwerte zu definieren und zu verwalten.

{
  "url": "http://my-organization.io/pacakage-1/CodeSystem/timezone-codes",
  "status": "active",
  "content": "complete",
  "resourceType": "CodeSystem",
  "concept": [
    { "code": "America/Los_Angeles", "display": "Pacific Time (US & Canada)" },
    { "code": "Europe/Andorra", "display": "Central European Time (Andorra)" },
    { "code": "Australia/Melbourne", "display": "Australian Eastern Time (Melbourne)" }
  ]
}

Um Validierungsregeln mithilfe unseres CodeSystem durchzusetzen, erstellen wir ein ValueSet, das darauf verweist – Profile binden immer an ValueSets, nicht direkt an CodeSystems. Die kanonische URL dient als eindeutiger Bezeichner, der unserem Profil ermöglicht, auf dieses ValueSet zu verweisen, während das compose-Attribut als domänenspezifische Sprache fungiert, die Regeln für die Aufnahme von Codes aus CodeSystems definiert. In unserem einfachen Fall schließen wir alle Codes aus unserem Zeitzonen-CodeSystem ein.

{
  "url": "http://my-organization.io/pacakage-1/ValueSet/timezone-codes",
  "status": "active",
  "resourceType": "ValueSet",
  "compose": {
    "include": [{ "system": "http://my-organization.io/pacakage-1/CodeSystem/timezone-codes" }]
  }
}

Ergebnis: Der Server lehnt nun jeden Zeitzonencode ab, der nicht in dieser Liste enthalten ist, und hält Zeitpläne weltweit präzise.

Erweiterungen: Benutzerdefinierte Felder hinzufügen

Erweiterungen = FHIR-Ressourcen + Ihre benutzerdefinierten Felder für bestehende Ressourcen. Sie ermöglichen es Ihnen, Daten hinzuzufügen, die in Standard-FHIR-Ressourcen nicht vorhanden sind, ohne den Standard zu forken.

Warum der Aufwand? Die Kern-Patient-Ressource enthält keine „Staatsangehörigkeit", „Ethnizität" oder „Versicherungsstufe", aber unsere geschäftlichen und medizinischen Anforderungen hängen von diesen Informationen ab. Denken Sie daran: FHIR ist ein Backbone – umfassend, aber keine erschöpfende medizinische Ontologie.

Wichtige Vorteile

Domänenspezifische Felder hinzufügen und dabei 100 % FHIR-konform bleiben.
Interoperabilität wahren und gleichzeitig Ihre individuellen Anforderungen erfassen.
Benutzerdefinierte Daten in einem strukturierten, durchsuchbaren Format speichern – niemals in Freitext vergraben.

Anstatt Kern-FHIR-Ressourcen zu modifizieren oder unstrukturierte Textfelder zu verwenden, erfasst Ihr System präzise zusätzliche Daten in einem standardisierten, durchsuchbaren Format. Dieser strukturierte Ansatz stellt sicher, dass benutzerdefinierte Daten abfragbar und austauschbar bleiben und dabei FHIRs Interoperabilitätsversprechen bewahrt wird.

ValueSet ist an die Erweiterung gebunden

Mit unserem definierten ValueSet können wir es nun an unsere Zeitzonen-Erweiterung binden. Die Bindungsreferenz verweist auf die kanonische URL unseres ValueSets, während die Bindungsstärke auf „required" gesetzt ist, um eine strenge Validierung zu gewährleisten. Das bedeutet, dass der FHIR-Server alle Ressourcen ablehnt, die Zeitzonencodes verwenden, die nicht in unserem ValueSet enthalten sind.

{
  "url": "http://my-organization.io/package-1/time-zone",
  "baseDefinition": "http://hl7.org/fhir/StructureDefinition/Extension",
  "abstract": false,
  "name": "TimeZone",
  "status": "active",
  "kind": "complex-type",
  "type": "Extension",
  "derivation": "constraint",
  "resourceType": "StructureDefinition",
  "context": [{ "expression": "Patient", "type": "element" }],
  "differential": {
    "element": [
      {
        "path": "Extension.url",
        "id": "Extension.url",
        "fixedUri": "http://my-organization.io/package-1/time-zone"
      },
      {
        "id": "Extension.value[x]",
        "path": "Extension.value[x]",
        "type": [{ "code": "code" }],
        "min": 1,
        "binding": {
          "strength": "required",
          "valueSet": "http://my-organization.io/pacakage-1/ValueSet/timezone-codes"
        }
      }
    ]
  }
}

Profile: FHIR an Ihre Bedürfnisse anpassen

Profile = FHIR-Ressourcen + Ihre Einschränkungen für diese Ressourcen. Sie machen abstrakte Ressourcen für Ihre spezifischen Anforderungen nutzbar. FHIR stellt eine Reihe von Ressourcen mit einem bestimmten Schema bereit, und die meisten Felder einer Ressource sind standardmäßig optional.

Warum ein Profil erstellen? Eine Herzklinik benötigt andere Patientendaten als eine Kinderklinik. Jede medizinische Fachrichtung hat eigene klinische Leitlinien und Berichtspflichten, die vorgeben, welche Daten erfasst werden müssen und wie. Rechtliche Anforderungen variieren zudem je nach Land und Fachgebiet.

Anstatt jede Patient-Ressource zu akzeptieren, die der Basis-FHIR-Spezifikation entspricht, weist ein Profil Ihr System an, nur Datensätze zu akzeptieren, die Ihre spezifischen klinischen oder geschäftlichen Anforderungen erfüllen, und stellt sicher, dass Ihre Datenpipeline Informationen erfasst, die Datenqualität und -vollständigkeit verbessern. Dieser gezielte Ansatz reduziert Integrationsfehler und gewährleistet Datenkonsistenz in Ihrem gesamten Gesundheits-Ökosystem.

Betrachten wir ein Patient-Profil, das Datenqualität und Zeitzonenbewusstsein in unserer Gesundheitsanwendung durchsetzt. Dieses Profil zeigt, wie FHIRs Kernfunktionen mit benutzerdefinierten Erweiterungen kombiniert werden können, um spezifische Geschäftsanforderungen zu erfüllen.

Das Profil erfordert drei Schlüsselelemente:

Patientenname (erforderlich für eine korrekte Identifikation)
Geschlecht (erforderlich für den genauen klinischen Kontext)
Unsere Zeitzonen-Erweiterung (erforderlich für die Terminplanung)

Indem wir diese Felder als Pflichtfelder festlegen und unsere Zeitzonen-Erweiterung integrieren, gewährleisten wir eine konsistente Datenerfassung im gesamten System.

{
  "url": "http://my-organization.io/package-1/my-patient",
  "baseDefinition": "http://hl7.org/fhir/StructureDefinition/Patient",
  "name": "MyPatient",
  "status": "active",
  "kind": "resource",
  "type": "Patient",
  "abstract": false,
  "derivation": "constraint",
  "resourceType": "StructureDefinition",
  "differential": {
    "element": [
      {
        "id": "Patient.name",
        "path": "Patient.name",
        "min": 1
      },
      {
        "id": "Patient.gender",
        "path": "Patient.gender",
        "min": 1
      },
      {
        "id": "Patient.extension",
        "path": "Patient.extension",
        "min": 1,
        "slicing": {
          "rules": "open",
          "discriminator": [{ "path": "url", "type": "value" }]
        }
      },
      {
        "min": 1,
        "max": "1",
        "sliceName": "TimeZone",
        "path": "Patient.extension",
        "id": "Patient.extension:TimeZone",
        "type": [
          {
            "profile": [ "http://my-organization.io/package-1/time-zone" ],
            "code": "Extension"
          }
        ]
      }
    ]
  }
}

Hinweis: Egal wie spezialisiert Ihre Profile werden – ob Sie von mehreren Profilen erben oder strenge Validierungsregeln hinzufügen –, jede Ressource, die Ihre Profilvalidierung besteht, bleibt im Kern eine gültige FHIR-Ressource. Andere FHIR-Systeme können weiterhin mit Ihren Ressourcen arbeiten, auch wenn sie Ihre spezifischen Profilregeln nicht kennen. Das macht FHIR wirklich leistungsstark – Sie erhalten sowohl Standardisierung als auch Flexibilität.

Gültiges minimales Patientenbeispiel gemäß unserer endgültigen Profilversion:

{
  "meta": { "profile": ["http://my-organization.io/package-1/my-patient"] },
  "extension": [
    {
      "url": "http://my-organization.io/package-1/time-zone",
      "valueCode": "America/Los_Angeles"
    }
  ],
  "name": [{ "given": ["John"], "family": "Doe"}],
  "gender": "male",
  "resourceType": "Patient"
}

SearchParameter: Das Gesuchte finden

SearchParameter = FHIR-Ressourcen + Ihre benutzerdefinierten Suchfähigkeiten. Sie ermöglichen es Ihnen, neue Wege zur Suche und Filterung von Ressourcen über die standardmäßigen FHIR-Suchparameter hinaus zu entwickeln.

Warum die Suche erweitern? Standard-FHIR-Suchparameter wie „name" oder „birthdate" sind hilfreich, aber reale Arbeitsabläufe verlangen reichhaltigere Abfragen – Patienten nach benutzerdefinierten Feldern (Erweiterungen) finden, alle Laborbefunde oberhalb eines Schwellenwerts abrufen oder ressourcenübergreifend in einer Abfrage suchen.

Verschiedene Teams benötigen unterschiedliche Möglichkeiten, Daten zu finden: das klinische Team nach Symptomen und Diagnosen, die Abrechnung nach Versicherung und Prozedurcodes. Anstatt komplexe clientseitige Abfragelogik zu entwickeln oder benutzerdefinierte Such-Endpunkte zu pflegen, machen Ihre SearchParameter-Definitionen erweiterte Abfragen über Standard-FHIR-APIs verfügbar. Dieser standardisierte Ansatz stellt sicher, dass alle Systeme dieselben Suchen konsistent durchführen können.

Beispiel: Verwenden wir unsere Zeitzonen-Erweiterung erneut, um Patienten in bestimmten Zeitzonen zu identifizieren. Wenn eine Patient-Ressource eine Erweiterung enthält, die ihre Zeitzone angibt, kann ein SearchParameter FHIRPath verwenden, um Patienten basierend auf dem Wert dieser Erweiterung zu filtern. Dies ermöglicht Suchen wie GET /Patient?timezone=America/Los_Angeles, um Patienten in der Pacific Time Zone abzurufen.

{
  "url": "http://my-organization.io/package-1/SearchParameter/Patient-timeZone",
  "id": "Patient-timeZone",
  "base": ["Patient"],
  "description": "Search patient by their time zone",
  "expression": "Patient.extension.where(url='http://my-organization.io/package-1/time-zone').value",
  "name": "timezone",
  "status": "active",
  "type": "token",
  "code": "timezone",
  "resourceType": "SearchParameter"
}

Wie FHIRPath funktioniert (kurze Einführung)

Punktnavigation – Patient.address.city navigiert den JSON-Baum wie eine Objektnotation.
where()-Filter – extension.where(url='…') behält nur übereinstimmende Elemente.
ofType()-Cast – value.ofType(Quantity) begrenzt polymorphe Felder (die mehr als einen Datentyp enthalten können).
Verkettung – Sie können diese Ausdrücke aneinanderreihen, um jeden verschachtelten Wert zu erreichen.

Da jeder Server FHIRPath versteht, liefert derselbe Ausdruck bei allen Anbietern identische Ergebnisse.

Ihr IG kann die Unterstützung bestimmter Suchparameter vorschreiben. Damit wird sichergestellt, dass alle Implementierungen die von Ihrer Organisation benötigten Suchfunktionen bereitstellen.

Operationen: Domänenspezifische Geschäftslogik

Operationen = Standardisierte FHIR-API + Ihre benutzerdefinierten domänenspezifischen Endpunkte.

Sie ermöglichen es Ihnen, komplexe API-Methoden über einfache CRUD-Operationen auf Ressourcen hinaus zu definieren.

Warum Operationen definieren? Gesundheitliche Arbeitsabläufe erfordern manchmal die Berechnung von Arzneimittelwechselwirkungen, die Erstellung klinischer Berichte oder die Verarbeitung komplexer Leistungsanspruchsprüfungen. Standard-FHIR-REST-Operationen (GET, POST, PUT, DELETE) eignen sich hervorragend für die grundlegende Ressourcenverwaltung, führen jedoch keine ausgefeilte Geschäftslogik aus.

OperationDefinition beschreibt die Schnittstelle Ihrer benutzerdefinierten Operation – Eingabeparameter, Ausgabeformat und Verhaltensdokumentation.

Beispiel: Benutzerdefinierte Operation Patient/$schedule-teleconsultation-window

In verteilten Versorgungsumgebungen, insbesondere bei der Telemedizin, muss die Terminplanung sowohl die Zeitzonen des Patienten als auch des Leistungserbringers berücksichtigen. Eine benutzerdefinierte FHIR-Operation kann die Koordination geeigneter Zeitfenster für virtuelle Konsultationen automatisieren.

Diese Operation unterstützt optionale Eingabeparameter zur Anpassung der Terminplanungslogik:

practitioner (Reference) Mit wem der Patient einen Termin vereinbaren möchte. Ein Verweis auf eine Practitioner- oder PractitionerRole-Ressource. Deren Verfügbarkeit wird zur Berechnung möglicher Zeitslots verwendet.
daysAhead (integer, Standard: 7) Wie weit in die Zukunft geblickt werden soll. Begrenzt die Suche auf die bevorstehenden N Tage. Nützlich, um unnötige Berechnungen zu vermeiden.
slotDuration (Duration, Standard: 30 Minuten) Mindestdauer des Termins. Filtert kürzere Slots heraus – zum Beispiel muss eine Konsultation mindestens 30 Minuten lang sein.

Diese Parameter helfen dem Client (z. B. einer Patienten-App oder einem Pflegekoordinationswerkzeug), das Ergebnis an reale Einschränkungen wie Terminpläne der Leistungserbringer, Patientenbedürfnisse oder Systemrichtlinien anzupassen.

{
  "resourceType": "OperationDefinition",
  "id": "schedule-teleconsultation-window",
  "url": "http://my-organization.io/package-1/OperationDefinition/schedule-teleconsultation-window",
  "name": "ScheduleTeleconsultationWindow",
  "status": "active",
  "kind": "operation",
  "code": "schedule-teleconsultation-window",
  "resource": ["Patient"],
  "system": false,
  "type": true,
  "instance": true,
  "parameter": [
    {
      "name": "practitioner",
      "use": "in",
      "type": "Reference",
      "min": 1,
      "max": "1",
      "documentation": "Practitioner to check availability for"
    },
    {
      "name": "daysAhead",
      "use": "in",
      "min": 0,
      "max": "0",
      "type": "integer",
      "documentation": "Number of days into the future to check"
    },
    {
      "name": "slotDuration",
      "use": "in",
      "min": 0,
      "max": "1",
      "type": "Duration",
      "documentation": "Minimum desired duration for appointment slot"
    },
    {
      "name": "availableSlot",
      "use": "out",
      "min": 1,
      "max": "100",
      "type": "BackboneElement",
      "part": [
        { "name": "start", "use": "out", "type": "dateTime", "min": 1, "max": "1" },
        { "name": "end",   "use": "out", "type": "dateTime", "min": 1, "max": "1" }
      ]
    }
  ]
}

Hinweis: Die Definition einer OperationDefinition in Ihrem IG dokumentiert die Schnittstelle und Anforderungen der Operation, implementiert die Funktionalität jedoch nicht automatisch – Ihr FHIR-Server muss die eigentliche Implementierung bereitstellen.

Die Unterstützung jeder Operation aus allen bestehenden Implementation Guides wäre unpraktisch und ressourcenintensiv. Stattdessen implementieren FHIR-Server typischerweise häufig verwendete Operationen aus weit verbreiteten öffentlichen IGs und bieten die Möglichkeit, die FHIR-API mit eigenen Operationen zu erweitern. Aidbox beispielsweise bietet ein flexibles API-Gateway-Muster über seine „App"-Funktionalität, das es Ihnen ermöglicht, benutzerdefinierte Operationen über dedizierte Lambda-Funktionen/Microservices zu implementieren, die sich nahtlos in den FHIR-Server integrieren.

Distribution und Paketierung

FHIR Implementation Guides können als NPM-Pakete verteilt werden, was die Versionsverwaltung, Weitergabe und Integration in verschiedene Systeme erleichtert. Dieser Ansatz nutzt das vertraute NPM-Ökosystem, das Entwickler bereits für JavaScript/TypeScript-Abhängigkeiten verwenden.

Unsere minimale package.json für einen FHIR IG könnte wie folgt aussehen:

{
    "name": "my.organization.fhir",
    "version": "0.0.1",
    "description": "My Organization IG FHIR Package",
    "author": "My Organization",
    "dependencies": {
        "hl7.fhir.r4.core": "4.0.1"
    }
}

Diese Paketstruktur unterstützt semantische Versionierung Ihres IG, Abhängigkeitsverwaltung für Basis-FHIR-Spezifikationen und andere IGs, einfache Distribution über NPM-Registries, klare Identifikation der FHIR-Versionskompatibilität und automatisierte Tooling-Integration.

Um den Implementation Guide zu paketieren, navigieren Sie in Ihr IG-Verzeichnis und führen Sie aus: npm pack

Dies erstellt eine .tgz-Datei wie: my-organization-fhir-ig-package-1.0.0.tgz. Alternativ können Sie auch manuell ein Tarball-Archiv erstellen.

Das Implementation Guide-Beispiel aus dem Artikel ist verfügbar unter: https://storage.googleapis.com/my-implementation-guide/my.organization.fhir-0.0.1.tgz

Erstellen Sie Ihre Aidbox-Instanz und probieren Sie den Implementation Guide unter http://aidbox.app aus.

Um den IG zu laden, folgen Sie der Dokumentation.

Praxisnahe IG-Beispiele

FHIR IGs sind nicht nur theoretisch – sie sind grundlegend für reale Interoperabilitätsbemühungen. Hier sind einige weit verbreitete Leitfäden:

US Core: Definiert den Mindestdatensatz und die Einschränkungen für den klinischen Datenaustausch in den Vereinigten Staaten. Viele nationale APIs und EHR-Systeme basieren darauf.
International Patient Summary (IPS): Ermöglicht den grenzüberschreitenden Austausch von Patientenzusammenfassungen. Wird in der EU und international eingesetzt.
mCODE (Minimal Common Oncology Data Elements): Passt FHIR an die Onkologie an und ermöglicht strukturierte, analysierbare Krebsdaten für klinische Studien, Versorgung und Forschung.

Diese Beispiele zeigen, wie IGs spezifische Domänen und Anwendungsfälle adressieren und einen Standard für Dateninteroperabilität und -qualität setzen. Durch ihre Betrachtung können Sie Ihre eigenen IGs an bewährten Praktiken der Community ausrichten.

Siehe auch: Agentic FHIR IG Development.