Der Begriff „ImplementationGuide“ führt im Kontext von FHIR immer wieder zu Missverständnissen.

Hier folgt der Versuch einer Klärung der häufigsten Fragen:

Was ist eigentlich ein Implementierungsleitfaden?

Wikipedia definiert den Begriff „Leitfaden“ als „eine Handlungsvorschrift mit bindendem Charakter“.
Im Kontext der Standardisierung kennen wir Implementierungsleitfäden als Anleitung für die Entwicklung kompatibler Softwarelösungen. Als solche präzisiert ein typischer Implementierungsleitfaden (z.B. von IHE) i.d.R. die Verwendung eines internationalen Standards im Kontext eines konkreten UseCases.

Beispiele:

  • IHE-RAD beschreibt die konkrete Verwendung von (u.A.) HL7 Version 2 Nachrichten zur Implementierung des radiologischen Order-Entry-Workflows.
  • Der Implementierungsleitfaden „Arztbrief 2014“ beschreibt die Darstellung eines strukturierten Arztbriefes auf Basis von HL7 CDA
  • Der „International Patient Summary“ beschreibt die Vereinbarungen für eine internationale Patientenkurzakte auf Basis von FHIR.

Für Implementierungsleitfäden gibt es Standard-übergreifend kein einheitliches Format. In der Regel handelt es sich um menschenlesbare Dokumente (PDF, HTML), die auch auf maschinenlesbare Artefakte verweisen können, aber nicht müssen.

Was ist der Unterschied zwischen einem Implementierungsleitfaden und einem Profil?

Antwort 1: Es ist das gleiche!
Im Kontext von IHE-Spezifikationen beschreibt 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.

Die Aufgaben eines Profils sind unter anderem:

  • die Festlegung der UseCase-spezifischen Pflichtfelder
  • die Festlegung der darüber hinaus optional verwendeten Felder (mit rotem „S“ gekennzeichnet)
  • die Festlegung der verwendeten Extensions 
  • die Festlegung der verwendeten Terminologien (z.B. zur Codierung von Diagnosen)
  • die Festlegung von Regeln, die erfüllt werden müssen (sog. „Invarianten“)

Beispiel: https://simplifier.net/isik/diagnose

Dabei beschreibt ein Profil aber immer nur die Constraints für einen einzigen Ressourcentyp. Um einen UseCase (z.B. eine Patientenkurzakte) zu beschreiben, benötigt man in der Regel mehrere Profile für verschiedene Ressourcentypen. Artefakte wie Extensions, ValueSet oder Datentyp-Profile sind dabei eigenständige Objekte, die von den Profilen referenziert werden.

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 HMTL-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: In 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“. Da hat man schnell mal daneben geklickt und wundert sich!

Vergleiche:

https://simplifier.net/isik/~resources?category=ImplementationGuide

vs.

https://simplifier.net/IsiK/~guides

Wer darf Implementierungsleitfäden schreiben?

Hinter dieser Frage steckt vermutlich das größte Missverständnis!

Während Leitfäden in der Vergangenheit ausschließlich im Wortsinne als „Richtlinien“ aus der Feder von Organisationen wie HL7, IHE oder anderen STUs (Standards Defining Organizations) verwendet wurden, gibt es in FHIR technisch keinen Unterschied zwischen 

  • der Beschreibung einer Implementierung im Sinne einer Richtlinie von Standardisierungsorganisationen an die Industrie oder 
  • der Beschreibung einer Impementierung im Sinne eines Pflichtenheftes im Rahmen einer Beschaffung/Beauftragung oder 
  • der Beschreibung einer Implementierung im Sinne einer Schnittstellendokumentation.

In allen diesen Szenarien kommen die gleichen Artefakte zum Einsatz: Profile, Extensions, ValueSets, Beispieldaten sowie ein beschreibendes, menschenlesbares Dokument; alles verpackt zu einer ImplementationGuide-Ressource.

Es sollten sich also nicht nur Mitarbeiter von Standardisierungsorganisationen mit den Resourcen und Tools des FHIR Conformance Frameworks vertraut machen, sondern auch alle, die Requirements-Engineering betreiben oder Schnittstellen implementiern und dokumentieren müssen.

Von Herstellern, die ihr Produkt als „FHIR-enabled“ bezeichnen, wird erwartet, dass deren Schnittstellenspezifikation in Form eines ImplementationGuides bereitgestellt wird. Prosaische Dokumentationen in Form von unstrukturierten PDFs werden von der FHIR-Community wie auch von den FHIR-Tools und -Referenzimplementierungen als unzureichend abgelehnt.

Dabei ist der Aufwand für die Erstellung von FHIR-basierten Schnittstellendokumentationen erheblich geringer als bei der Erstellung von Spezifikationen. Oft können die Profile aus den Richtlinien, die vom Hersteller implementiert wurden, wiederverwendet werden und müssen nur durch die Nenung der optionalen bzw. die Beschreibung der zusätzlich implementierten Features ergänzt werden.

Tools wie Simplifier und der dort integrierte „ImplementationGuide Editor“ oder der IG Publisher machen die Erstellung, Pflege und Publikation der Schnittstellenbeschreibung besonders einfach. 

Unser Schulungsmodul „FHIR für Spezifizierer“ gibt einen Einblick in das FHIR Conformance Framework und demonstriert das Vorgehen zur Erstellung eines eigenen ImplementationGuides anhand einfach nachvollziehbarer Beispiele.