gms | German Medical Science

Einleitung: Dieser Abstrakt analysiert den gegenwärtigen Stand der Qualitätssicherungs- und -kontrollmechanismen in Deutschland und stellt eine mögliche Migration hin zu HL7 FHIR vor.

Methoden: In Deutschland müssen Qualitätssicherungsdaten (QS) [1] bereitgestellt werden. Gegenwärtig wird die QS-Basisspezifikation hauptsächlich als Microsoft Access Datenbanken verteilt, in denen die notwendigen Details für die Datenzusammenstellung und -übermittlung bereitgestellt werden [2].

Ergebnisse: Die QS-Basisspezifikation enthält Module, die typischerweise aus einem oder mehreren hierarchisch geschachtelten Formularen besteht, die mehrere (Gruppen von) Felder(n) enthalten. Regeln unterstützen die Plausibilität der Dateneingabe und die Anzeige von Feldern. Für einige Felder werden die Daten als Auswahlliste vorgegeben. Triggerevents definieren, welche Fälle berichtet werden müssen bzw. welche Daten aus den Formularen erzeugt werden müssen.

Ein QS-Modul kann direkt auf eine FHIR Questionnaire Resource abgebildet werden, in der die Formulare eines Moduls als spezielle Item Groups enthalten sind. Felder werden dann als Items (d.h. Data Elements) und Feldgruppen als geschachtelte Items hinterlegt. Die Regeln können dann als FHIR Structure Definition definiert werden und als Extensions in einem Questionnaire enthalten sein. Die Auswahllisten der QS-Basisspezifikation können als Value Sets und der Triggermechanismus selbst kann als FHIR Event Ressource umgesetzt werden. Die erfassten Daten können für den Export als Resource Bundles repräsentiert werden.

Regeln validieren die eingegebenen Werte von einzelnen Feldern oder ganzen Gruppen und können über Abhängigkeiten von Attributen einer Questionnaire Resource („enableWhen“) umgesetzt werden. Allerdings erfordern die Plausibilitätsregeln eine Erweiterung der FHIR Ressourcen: Zum Beispiel kann ein Feld erfordern, dass mindestens ein eingegebener Wert (oder nur Werte) aus einer gegebenen Liste enthält, während ein anderes Feld bestimmte Werte eben nicht enthalten darf. In der gegenwärtigen QS-Basisspezifikation werden diese Details nicht über eine formale Sprache mit einer Grammatik ausgedrückt. FHIR-Path könnte diese Sprache sein und würde daher von diesen Funktionen profitieren. Die Nutzung weiterer Eigenschaften von FHIR wie bspw. externer Referenzen kann die derzeit fehlende Funktionalität wie das Retrieval fehlender Daten lösen und eine notwendige manuelle Neueingabe von Daten und damit Fehleingaben verhindern.

Diskussion: Die gegenwärtige QS-Basisspezifikation ist sehr mächtig und erlaubt eine einfache Implementierung über ein graphisches User-Interface, um meldepflichtige Fälle zu identifizieren, die Formulare entsprechend auszufüllen und abschließend die pseudonymisierten Daten im gewünschten Format zu exportieren. Die proprietäre Repräsentation als Access-Datenbank ist hierbei das größte Manko. Die fehlende klare Festlegung der Semantik der Datenelemente macht es zudem sehr schwierig, die Daten aus einem Primärsystem abzufragen. Darüber hinaus können die Daten nur für den definierten Zweck genutzt werden. Diese genannten Limitierungen können durch HL7 FHIR in Kombination mit einem entsprechenden Implementierungsleitfaden gelöst werden.

Darüber hinaus bleibt die Herausforderung, die grammatikfreie Sprache, die im QS-Prozess genutzt wird, durch eine formale Sprache zu ersetzen. FHIR-Path könnte durchaus mit den Konstrukten/Funktionen aus der Basisspezifikation ergänzt werden.

Jetzt wäre der richtige Zeitpunkt, die Erweiterungen in die internationale Community zu tragen, so dass die FHIR-Verbesserungen von den Erfahrungen aus der Vergangenheit profitieren.

Die Autoren geben an, dass kein Interessenkonflikt besteht.

Die Autoren geben an, dass kein Ethikvotum erforderlich ist.