Ein technischer Überblick über die Nutzung von FHIR zur Einholung einer Zweitmeinung

In unserem vorherigen Blogbeitrag haben wir beschrieben, wie ein Patient von FHIR profitieren kann, wenn Dokumente und Befunde zur Einholung einer Zweitmeinung an einen Radiologen übermittelt werden. Anstelle von USB-Sticks, CDs und der erneuten Eingabe von Daten kommunizieren die Systeme über standardisierte Schnittstellen direkt miteinander.

Aber wie funktioniert das alles in der Praxis? In diesem Blogbeitrag tauchen wir in die technische Seite des Anwendungsfalls ein: Welche FHIR-Ressourcen sind beteiligt, wie kommen der CH RAD-Order-Implementierungsleitfaden und SDC (Structured Data Capture) ins Spiel und wie könnte eine realistische Implementierung in Primärsystemen aussehen?

Dies ist der zweite Beitrag einer Reihe von Blogbeiträgen über FHIR.

FHIR (Fast Healthcare Interoperability Resources) ist ein moderner Standard für den Austausch von Gesundheitsdaten. Er wurde auf der Grundlage der Erfahrungen mit HL7 v2 und v3 sowie der Web-Community im Allgemeinen entwickelt.

Für mich ist der wesentliche Punkt bei FHIR folgender:

• Es ist einfach moderne Web-Technologie: FHIR nutzt RESTful-APIs über HTTP und stellt Daten als JSON oder XML dar – genau wie die meisten modernen Webdienste. Dadurch lassen sich Cloud-Dienste, mobile Apps und andere Telemedizin-Plattformen nahtlos integrieren. Tools müssen nicht von Grund auf neu geschrieben werden: Der Grossteil der Technologie und der Tools aus dem Web-Ökosystem kann wiederverwendet werden.
• Ressourcenbasiertes Modell: Anstelle der riesigen monolithischen Nachrichten, die in HL7 v3 verwendet werden, oder der Ad-hoc- und standortspezifischen Erweiterungen, die oft bei HL7 v2 zu finden sind, definiert FHIR kleine, kombinierbare Ressourcen wie Patient, ServiceRequest, DiagnosticReport, ImagingStudy, DocumentReference und viele mehr. Komplexe Arbeitsabläufe werden als Kombinationen dieser Ressourcen und Verweise zwischen ihnen modelliert.
• Auf Erweiterbarkeit ausgelegt (die 80/20-Regel): FHIR zielt darauf ab, etwa 80 % der weltweiten Anwendungsfälle in seiner Kernspezifikation abzudecken. Die verbleibenden 20 % werden bewusst Profilen und Implementierungsleitfäden (IGs) überlassen, die FHIR an ein bestimmtes Land, eine Region oder eine Organisation anpassen. Daher sind Erweiterungen und Einschränkungen in FHIR zentrale Konzepte.

In diesem Beitrag sehen wir uns an, wie sich dies auf unser konkretes Szenario der Zweitmeinung auswirkt.

Fassen wir noch einmal vereinfacht zusammen, was bei Mara passiert ist .

Akteure

• Die Patientin (Mara) und ihr EPD (Elektronisches Patientendossier)
• Der überweisende Arzt (Dr. Meier) und seine Praxisverwaltungssoftware
• Eine radiologische Praxis mit ihrem Radiologie-Informationssystem

Ablauf

• Dr. Meier erstellt eine radiologische Überweisung für eine Zweitmeinung und sendet diese an die Radiologiepraxis.
• Die radiologische Praxis ruft die Überweisung und die dazugehörigen klinischen Informationen ab.
• Der Radiologe begutachtet die vorliegende Untersuchung, verfasst einen Befundbericht und lädt die Ergebnisse in das elektronische Patientendossier hoch.
• Das System von Dr. Meier empfängt die Ergebnisse automatisch und zeigt sie an.

In diesem Beitrag konzentrieren wir uns auf den ersten Schritt: Wie Dr. Meiers Primärsystem eine Anfrage für eine Zweitmeinung so erstellt, dass andere Systeme – wie beispielsweise die Radiologiepraxis – diese zuverlässig verstehen und verarbeiten können.

Der erste technische Schritt besteht darin, den Auftrag und die für die Zweitmeinung erforderlichen Patientendaten zu erfassen. Mit anderen Worten: Wie teilt Dr. Meier der Radiologiepraxis auf maschinenlesbare Weise mit, dass sie eine Zweitmeinung zu einer bestehenden Röntgenaufnahme abgeben soll?

Wir beginnen mit der „ServiceRequest“-Ressource, die den radiologischen Auftrag selbst erfasst. Dabei werden wir auf zentrale FHIR-Konzepte wie Ressourcen, Referenzen, Profile und Implementierungsleitfäden eingehen. Anschliessend werden wir sehen, wie CH RAD-Order und SDC darauf aufbauend einen strukturierten Fragebogen hinzufügen, um alle Details des Auftrags zu erfassen.

ServiceRequest als FHIR-Ressource

Ein ServiceRequest ist eine maschinenlesbare Art zu sagen: „Bitte erbringen Sie diese Leistung für diesen Patienten aus diesem Grund.“

In unserem Fall: „Bitte geben Sie eine Zweitmeinung zu Maras bestehender Röntgenaufnahme des rechten Beins ab. Die klinische Frage lautet: Können Sie eine Stressfraktur des rechten Schienbeins bestätigen?“

Dies wird als FHIR-Ressource dargestellt. Ressourcen bilden das Herzstück von FHIR. Das steckt bereits im Namen. Fast Healthcare Interoperability Resources. Sie bieten strukturierte, maschinenlesbare und gut dokumentierte „Bausteine“ für klinische Informationen – in diesem Fall die Informationen, die erforderlich sind, um eine radiologische Untersuchung (wie eine Röntgenaufnahme, ein CT oder ein MRT) oder eine Zweitmeinung anzufordern.

Auch ohne detaillierte Kenntnisse von FHIR lassen sich einige wichtige Informationen erkennen:

• Die Kategorie zeigt, dass es sich um eine Anfrage für eine Zweitmeinung handelt (SecondOpinion).
• Der Betreff und der Anforderer beziehen sich auf Mara und Dr. Meier.
• Das Feld „supportingInfo“ verweist auf vorhandene Daten, die berücksichtigt werden sollten: das ausgefüllte Anforderungsformular (QuestionnaireResponse), die vorhandene ImagingStudy (das Röntgenbild) und den vorherigen DiagnosticReport (Befundbericht).

Woher wusste die Praxisverwaltungssoftware, wie sie diese JSON erstellen sollte? Hier kommen Profil- und Implementierungsleitfäden ins Spiel.

Ein Profil kann als maschinenlesbare Vorlage für einen bestimmten FHIR-Ressourcentyp betrachtet werden. Es definiert, welche Elemente obligatorisch, optional oder verboten sind, welche ValueSets und/oder CodeSystems verwendet werden müssen (mehr dazu später), welche Erweiterungen zulässig sind usw.

Wenn wir uns unser JSON noch einmal ansehen, stellen wir fest, dass es angibt, dem Profil zu folgen (oder im Fachjargon: „dem Profil zu entsprechen“), dessen Definition hier zu finden ist.

Ein Profil für sich allein reicht jedoch nicht aus; meistens ist ein Profil Teil eines Implementierungsleitfadens (IG). In unserem Fall ist der Implementierungsleitfaden „CH Rad-Order“. Er beschreibt, wie eine gemeinsame, interoperable Methode zur Darstellung von radiologischen Aufträgen (zur Erinnerung: eine Zweitmeinungsanfrage für bildgebende Untersuchungen ist ebenfalls ein radiologischer Auftrag) im Schweizer Gesundheitswesen definiert werden kann.

Bei genauerer Betrachtung existiert CH RAD-Order nicht isoliert. Es baut auf einem anderen Schweizer Leitfaden auf:

• Der Implementierungsleitfaden „Order & Referral by Form“ (CH ORF) definiert, wie Formulare für elektronische Überweisungen und Informationsanfragen (wie z. B. Ergebnisse der diagnostischen Bildgebung, Laborergebnisse, Entlassungsberichte usw.) definiert, bereitgestellt und verwendet werden können.
• CH ORF definiert ein CH ORF ServiceRequest-Profil.
• CH RAD-Order verfeinert dieses CH ORF ServiceRequest dann für radiologiespezifische Anforderungen (z. B. Bildgebungsregion, Körperregion, angeforderte Bildgebungsmodalität).
• Diese Schichtung ähnelt stark der regulären Softwareentwicklung:

  • Die meisten Projekte stützen sich auf bestehende Bibliotheken und Frameworks, anstatt alles von Grund auf neu zu entwickeln.
  • Ebenso baut CH RAD-Order auf CH ORF auf, das wiederum auf der internationalen FHIR-ServiceRequest-Definition basiert.

Bisher haben wir die Anforderung als klinische Ressource betrachtet, als einen ServiceRequest, der besagt:

„Bitte geben Sie aus diesem Grund eine Zweitmeinung zu dieser bestehenden Röntgenaufnahme von Mara ab.“

Diese Informationen werden von nachgelagerten Systemen für Workflow, Terminplanung und Berichterstellung genutzt.

Dies wirft jedoch eine sehr praktische Frage auf:

Wie gibt Dr. Meier eigentlich all die Informationen ein, die letztlich in dem ServiceRequest enthalten sind?

Eine Möglichkeit wäre, ein benutzerdefiniertes radiologisches Anforderungsformular in jedes Praxisverwaltungssystem und jedes Radiologie-Informationssystem direkt im System zu implementieren. Bei m verschiedenen Primärsystemen und n verschiedenen Auftragsformularen führt das zu m × n separaten Implementierungen. Leser dieses Artikels, die über etwas Entwicklungshintergrund verfügen, erleben hier vielleicht ein Déjà-vu. Dieses Muster findet sich auch bei Code-Editoren: bei m verschiedenen Editoren, die im Idealfall alle n Programmiersprachen unterstützen müssten. Die Lösung besteht darin, den Datenaustausch zwischen Editor und Sprachserver zu standardisieren und ihn auf jeder Seite einmal zu implementieren. In der Softwareentwicklung haben wir dies im Language Server Protocol für Code-Editoren gesehen; deshalb können Nischen- oder zweckgebundene Code-Editoren „kostenlos“ über intelligente Code-Vervollständigung, Sprung zur Definition usw. verfügen. Ein weiteres Beispiel ist das Model Context Protocol für KI-Tools. Auch hier können verschiedene Tools KI von unterschiedlichen Anbietern relativ einfach integrieren.

FHIR bietet genau ein solches gemeinsames Protokoll für Formulare gemäss der Structured Data Capture IG:

• Ein Questionnaire beschreibt ein Formular: welche Fragen gestellt werden, welche Antworttypen zulässig sind, wie die Abschnitte strukturiert sind usw.
• Eine „QuestionnaireResponse“ enthält einen konkreten Satz von Antworten für einen bestimmten Fall.

CH RAD-Order nutzt diese, um das radiologische Auftragsformular selbst (QuestionnaireRadiologyOrder) und die ausgefüllten Antworten zu beschreiben, die Dr. Meier übermittelt. Der Mehrwert für Anbieter von Primärsystemen besteht darin, dass sie lediglich einen generischen Questionnaire-Renderer sowie eine Möglichkeit zur Übermittlung der Antworten benötigen; das Zweitmeinungsszenario ist dann „nur“ ein weiterer Fragebogen, der denselben Regeln folgt.

Zusammenfassend:

• Das Formular, das Dr. Meier auf dem Bildschirm sieht, wird durch den „QuestionnaireRadiologyOrder“ aus CH RAD-Order beschrieben: eine strukturierte Definition aller Fragen, aus denen sich ein radiologischer Überweisungsbogen zusammensetzt (klinische Fragestellung, Bildgebungsregion, Hinweise usw.).
• Wenn Dr. Meier dieses Formular für Mara ausfüllt, entsteht ein QuestionnaireResponse: ein Satz von Antworten für diesen speziellen Fall. Dieser wird an die radiologische Praxis gesendet.

Hier möchte ich einige Punkte hervorheben:

• requestedService.service gibt an, dass es sich um eine Anfrage für eine Zweitmeinung handelt. Der Fragebogen ist vielseitig einsetzbar: Mit einem anderen Code könnte er für andere Dienste verwendet werden (z. B. eine „Anfrage für neue Bildgebung“). In dieser Hinsicht ist dieser Typ als ValueSet-Ressource kodiert. Man kann sich diese im Grunde als Enums mit erweiterten Funktionen vorstellen, wie wir beim nächsten Punkt sehen werden.
• Dabei fällt vielleicht auf, dass in requestedService.service ein System mit einer URL definiert ist. Diese gibt an, welche Referenzdaten verwendet werden sollen. Sie kann sich innerhalb eines IG befinden (wie bei requestedService), aber auch ausserhalb definiert sein, beispielsweise bei der imagingRegion. Dies ist besonders praktisch, wenn Sie ein externes ontologisches System (wie LOINC, SNOMED-CT und in unserem Fall Radlex) nutzen möchten. Die Zuordnung eines Konzepts oder Objekts zu einer eindeutigen Kennung ist ein häufiger Anwendungsfall im medizinischen Bereich. Dies hat mehrere Vorteile, unter anderem:

  • Verringerung von Mehrdeutigkeit, denn „Fieber“ kann verschiedene Bedeutungen haben: ein allgemeines Symptom, eine Diagnose, eine bestimmte Krankheit usw.
  • semantische Interoperabilität, d. h.: verschiedene Systeme können die Bedeutung der Daten interpretieren, um eine automatisierte Verarbeitung zu ermöglichen.
  • vereinfachte Mehrsprachigkeit und insgesamt einfachere maschinelle Verarbeitung (einschliesslich Machine Learning / AI).
• Und deshalb ist dieser Gedanke so wichtig, dass ihm in FHIR ein ganzes Modul gewidmet ist, das Terminologie heisst.

Zusammenfassend lässt sich sagen, dass die Anforderung einer Zweitmeinung wie folgt erfasst wird:

• Formulare werden einmalig als „Questionnaire“-Ressourcen in einem Implementierungsleitfaden definiert (hier: CH RAD-Order, basierend auf CH ORF und SDC).
• Primärsysteme (Praxissoftware) implementieren eine generische „Questionnaire-Engine". Diese Engine rendert Formulare, sammelt Antworten und sendet sie als „QuestionnaireResponse“. Die konkrete Umsetzung (Webformular, mobile App, KI-Assistent, der die Fragen vorliest und die Antworten des Radiologen sammelt…) ist irrelevant, solange eine „QuestionnaireResponse“ generiert wird.
• Zusammen mit den Antworten aus dem Fragebogen wird ein formeller klinischer Auftrag übermittelt.[Text Wrapping Break]Für dieses Beispiel können wir davon ausgehen, dass die ServiceRequest-Ressource aus der QuestionnaireResponse erstellt wird.
• National vereinbarte Profile und Codesysteme stellen sicher, dass die Systeme verschiedener Anbieter die Daten auf die gleiche Weise interpretieren.

In diesem Beitrag haben wir uns auf den ersten Schritt von Maras radiologischer Reise konzentriert: die Erstellung einer klinischen Anfrage an eine radiologische Praxis. Was haben wir gelernt?

• Grundlegende Konzepte von FHIR wie Ressourcen, Implementierungsleitfäden, Profile und wie diese miteinander in Beziehung stehen
• Wie eine radiologische Anfrage für eine Zweitmeinung mit FHIR modelliert werden kann
• Wie CH RAD-Order auf CH ORF und dem Basis-ServiceRequest aufbaut
• Wie SDC, Questionnaire und QuestionnaireResponse eine wiederverwendbare Möglichkeit zur Implementierung von Formularen bieten.