ImplementationGuide

Die ImplementationGuide-Ressource enthält Markdown- bzw. HTML-Seiten, die alle technischen Anforderungen in eine menschenlesbare Form bringen im Quellformat und verknüpft sie mit der maschinenlesbaren Spezifikation (dem Package).

Auf Basis der ImplementationGuide-Ressource erstellen Tools wie Simplifier oder der IG Publisher den Implementierungsleitfaden, der als Webseite publiziert werden kann.

Was ist der Unterschied zwischen einem ImplementationGuide und einem Implementierungsleitfaden?

Der ImplementationGuide ist eine Resource aus dem FHIR Conformance Framework (einer Gruppierung von verschiedenen Ressourcentypen, die im Kontext der Erstellung von FHIR-basierten Spezifikationen benötigt werden), also ein strukturiertes, maschinenlesbares Objekt, das wie jede andere FHIR-Ressource wahlweise in XML oder JSON serialisiert werden kann. Es dient dazu, die Einzelteile, die einen Implementierungsleitfaden ausmachen (HTML-Webseiten mit Erläuterungstexten und darin eingebetteten Grafiken, Beispieldaten, Profile, ValueSets, Extensions …) zu einem Paket zu verschnüren, zu publizieren und zwischen verschiedenen Tools und Systemen austauschbar zu machen.

Für humanoide Konsumenten einer Spezifikation ist die ImplementationGuide-Ressource in der Regel uninteressant. Selbige wollen das HTML-Dokument in seiner menschenlesbaren Form betrachten können, nicht die maschinenlesbare Auflistung seiner Einzelteile.

Während im Englischen höchstens die Anordnung der Majuskeln zur Unterscheidung von ersterem, dem „ImplementationGuide“ und letzterem, dem „implementation guide“ herangezogen werden kann, hat es sich hierzulande etabliert, die Ressource bei ihrem englischen Namen zu nennen, jedoch das HTML-Dokument zu „(Implementierungs-)Leitfaden“ zu übersetzen. Schwierig wird es, wenn man mit hartgesottenen FHIR-Nerds spricht, die aus ökonomischen Gründen beides unter dem Akronym „IG“ zusammenfalten.

CAVE: Auf Simplifier, einer beliebten Plattform zur Erstellung und Publikation von FHIR-Spezifikationen, findet man in einem Projekt einerseits einen „ImplementationGuide“ im Tab „Resources“, andererseits aber auch das gerenderte Dokument als HTML-Seite(n) im Tab „Guides“!

Package

Das Package stellt eine Sammlung der maschinenlesbaren Anteile einer Spezifikation dar. Publizierte Packages werden in einer zentralen Registry bereitgestellt, wo sie für verschiedene Tools (z.B. FHIR-Server, Validatoren) auffindbar sind und einfach heruntergeladen und installiert werden können. Dbai folgen FHIR Packages dem weit verbreiteten Node Package Manager (NPM) Standard. Packages können Abhängigkeiten untereinander haben, wenn in Spezifikationen maschinenlesbare Artefakte aus anderen Spezifikationen wiederverwendet werden. So haben z.B. die meisten in Deutschland publizierten Packages eine Dependency auf das Package, das die Deutschen Basisprofile enthält.

Packages können niemals geändert oder gelöscht werden. Ein einmal publiziertes Package (das in der Regel ein Release einer Spezifikation darstellt) kann höchstens mit dem Status "deprecated" versehen und durch ein neueres Package ersetzt werden. Es verbleibt jedoch in der Registry. Dies gibt den Autoren von Spezifikationen, die Artefakte anderer Autoren verwenden, die Sicherheit, dass Änderungen an der fremden Spezifikation keine Auswirkungen auf ihre eigene Spezifikation haben. Autoren können selbst entscheiden, wann Sie die verwendeten Artefakte durch das Einbinden eines neueren Packages aktualisieren möchten.

Details:

• https://registry.fhir.org/learn

Profile

Ein Profil beschreibt in maschinenlesbarer Form (mittels einer StructureDefinition-Ressource), welche technischen Constraints für die Nutzung eines Ressourcentyps (z.B. Patient, Observation, Condition) bzw. eines Datentyps (z.B. Address, HumanName, Quantity) in einer konkreten Spezifikation gelten.

Solche Constraints umfassen unter anderem:

• Beschränkung der maximalen oder minimalen Kardinalität (Festlegung von Pflichtfeldern)
• Kennzeichnung der für die Spezifikation relevanten Elemente (MustSupport-Flags)
• Auswahl erforderlicher Extensions
• Definition von Regeln, die eine Ressourcen-Instanz befolgen muss (Invarianten)

Weiterhin können Profile genutzt werden, um die Bedeutung und Verwendung einzelner Elemente textuell zu erläutern und zu kommentieren.

Profile verweisen stets auf eine Basisdefinition (z.B. einen FHIR-Ressourcentyp) auf den die Constraints angewendet werden. Neben den FHIR Ressourcen- und Datentypen könne auch bereits existierende Profile als Basis genutzt und weiter eingeschränkt werden. Man spricht in diesem Fall von "abgeleiteten Profilen". Das Ableiten von Profilen hat den Vorteil, dass Instanzen, die gegen abgeleitete Profile valide sind, stets auch gegen das Profil, von dem abgeleitet wurde, validieren. Wer also sicherstellen möchte, dass die eigene Spezifikation vollständig kompatibel mit einer bereits existierenden Spezifikation bleibt, sollte das Erstellen abgeleiteter Profile in Betracht ziehen.

Profile können die Constraints ihrer Basisdefinition weiter einschränken, jedoch niemals auflösen/lockern. Wo eine Basisdefinition zum Beispiel die Kardinalität 0..1 vorschreibt, kann in einem Profil zwar die minimale Kardinalität auf 1 angehoben, die maximale Kardinalität kann jedoch nicht weiter erhöht werden. Selbst das Hinzufügen einer Extension entspricht aus technischer Betrachtung heraus einem Constraint, da die Eigenschaft aller FHIR-Basisdefinitionen, an beliebiger Stelle mit beliebig vielen Extensions beliebiger Art erweiterbar zu sein, durch das Konkretisieren einer dieser beliebigen Extensions eingeschränkt wird.

Was ist der Unterschied zwischen einem Implementierungsleitfaden und einem Profil?

Antwort 1: Es ist das gleiche!

Im Kontext von IHE-Spezifikationen meint der Begriff „Profil“ das Dokument, das beschreibt, wie ein internationaler Standard für einen bestimmten UseCase „profiliert“ wurde, also den Implementierungsleitfaden.

Antwort 2: Es ist nicht das gleiche!

Im Kontext von FHIR versteht man unter einem „Profil“ die Summe der Contraints, die beschreiben, wie ein konkreter FHIR-Ressourcentyp (z.B: "Condition") in einem konkreten Kontext (z.B. beim Datenaustausch zwischen Systemen in einem Krankenhaus) verwendet werden soll. In diesem Leitfaden wird der Begriff gemäß der FHIR-Definition verwendet.

Extensions

Eine Extension beschreibt in maschinenlesbarer Form (mittels einer StructureDefinition-Ressource), wie eine konkrete Erweiterung des FHIR-Standards verwendet wird.

Dies umfasst unter anderem:

• die Festlegung eines eindeutigen Namens (URL) der Extension
• die Festlegung des Datentyps
• die Beschreibung des Zwecks, dem die Extension dient
• die Aufzählung der Kontexte (Stellen in FHIR-Ressourcen) an denen die Extension verwendet werden kann

CapabilityStatement

Wenn in einer Spezifikation das REST-Paradigma zum Einsatz kommt, so dient die Capability-Ressource der Konkretisierung, welche Features von Client- bzw. Server-Implementierungen gefordert werden.

Dies umfasst u.A.

• die Ressourcentypen und Profile, die die Systeme verarbeiten können müssen,
• die Interaktionen (read, write, update, delete), die für die jeweiligen Ressourcentypen implementiert werden müssen,
• die Suchparameter, die für die jeweiligen Ressourcentypen unterstützt werden müssen, und
• die Operations, die über die REST-Interaktionen hinaus unterstützt werden müssen.

Im Kontext einer FHIR-Spezifikation stellt das CapabilityStatement eine Liste von Anforderungen dar, die Implementierungen erfüllen müssen um als konform zu der Spezifikation zu gelten.

Das CapabilityStatement kann jedoch auch dazu verwendet werden, die konkret implementierten Features einer Software, die als FHIR-Server agiert, zu dokumentieren.

Beispieldaten

Beispieldaten dienen der Verdeutlichung der Spezifikation und können von Implementierern als Testdaten verwendet werden.