SMART on FHIR: Praxisleitfaden zur Erweiterung von EMR-Anwendungen

Wie SMART on FHIR EMR-Funktionen erweitert

Es gibt kein EMR oder EHR, das alle Anwendungsfälle abdecken kann. Anstatt zu versuchen, alle benötigten Funktionen in einem einzigen Produkt zu bündeln, ist es in der Regel besser, externe Schnittstellen bereitzustellen, die von Drittanbieter-Erweiterungen genutzt werden können. FHIR stellt einen SMART App Launch-Implementierungsleitfaden bereit, der dieses Problem adressiert. Dieser Artikel bietet einen praxisorientierten, schrittweisen Leitfaden für Softwareentwickler, die nach einer effizienten Möglichkeit suchen, ihre Gesundheitsanwendungen zu erweitern.

Mein Name ist Ilya Beda. Ich bin CTO bei Beda Software.

Bei Beda Software entwickeln wir eine Open-Source-EMR-Lösung. Sie ist als Frontend konzipiert, das jeden FHIR-Server in ein FHIR-EMR verwandelt. Kürzlich habe ich am SMART Launch Track des HL7 AU FHIR Connectathon teilgenommen. Ich übernahm die Rolle des SMART Launch Providers, und das EMR von Beda wurde genutzt, um SMART on FHIR-Anwendungen von Drittanbietern zu starten. Ziel war es, die Implementierung zu überprüfen und die Integration zwischen den von den Teilnehmern bereitgestellten Anwendungen zu testen.

Bevor wir uns den technischen Details widmen, klären wir zunächst, was SMART ist. SMART (Substitutable Medical Applications, Reusable Technology) ist eine Plattform zur Entwicklung von Gesundheitsanwendungen, die auf verschiedenen EHR-Systemen (elektronische Krankenakte) ausgeführt werden können. Sie bietet ein Framework für die Entwicklung sicherer, interoperabler und austauschbarer Anwendungen. SMART-Apps sind darauf ausgelegt, einfach zu entwickeln und in verschiedenen Gesundheitsumgebungen bereitzustellen.

SMART on FHIR basiert auf OAuth 2.0, sodass das Verständnis der Funktionsweise recht einfach ist.
Das FHIR-EMR initiiert den SMART Launch, indem es zwei Parameter an die SMART-App übergibt.

Der erste Parameter, iss genannt, ist die Basis-URL des FHIR-Servers. Der zweite Parameter – launch – ist eine eindeutige Zeichenfolge, die den Launch-Prozess verfolgt und einer Sitzung einen Kontext zuweist.

Sobald die App gestartet ist, lädt sie Informationen vom FHIR-Server über den OAuth-Authentifizierungsendpunkt. Anschließend leitet sie den Benutzer zum Authentifizierungsendpunkt weiter. Diese Authentifizierung enthält eine Liste von Scopes, die die von der App angeforderten Berechtigungen definieren. Sehen wir uns genauer an, wie ein Scope aussieht: Der erste Teil identifiziert die Rolle. „Patient" bedeutet, dass die Daten auf einen bestimmten Patienten beschränkt werden, während „user" bedeutet, dass die Daten auf einen bestimmten Benutzer beschränkt werden. Wenn der Benutzer ein Patient ist, kann er nur auf seine eigenen Daten zugreifen. Wenn der Benutzer ein Behandler ist, sind die Daten aller Patienten verfügbar, die ihre Einwilligung erteilt haben.

Der „system"-Status bietet schließlich Zugriff auf alle Ressourcen.

Der Ressourcentyp ist selbsterklärend und definiert eine bestimmte FHIR-Ressource.

Die übrigen Teile sind buchstabencodierte Operationen:

• C für Erstellen (create);
• R für Lesen anhand der ID (read by id);
• U für Aktualisieren (update);
• D für Löschen (delete);
• S für Suchen (search).

Wenn Ihre App also Zugriff auf eine Patienten-Observation benötigt, müssen Sie den folgenden Scope angeben: "patient/Observation.rs".

Wenn Sie eine QuestionnaireResponse-Ressource beliebiger Art erstellen möchten, lautet der Scope: "system/QuestionnaireResponse.c".

Sobald die App die Scopes vom FHIR-Server anfordert, muss ein Benutzer die angeforderten Scopes autorisieren und Berechtigungen erteilen. Wenn dies geschieht, stellt der FHIR-Server einen Zugriffscode bereit, der gegen ein Access Token, ein ID Token und einen fhirContext ausgetauscht werden kann.

Wenn das FHIR-EMR den Launch durchführt, speichert es den Kontext, der unter dem Schlüssel fhirContext in der Token-Exchange-Antwort verfügbar ist.

Nun sind Sie mit den Grundlagen von SMART on FHIR und SMART Launch vertraut – sehen wir uns an, wie dies mit Aidbox implementiert werden kann.

Die zentrale Komponente ist die Client-Aidbox-Ressource, die den OAuth-Client repräsentiert. Diese Ressource enthält außerdem ein smart-Feld, das zur Definition von SMART on FHIR-spezifischen Eigenschaften wie Launch-URI, Name und Beschreibung verwendet wird: Der Code ist hier abrufbar.

Nun erstellen wir eine App-Galerie-Seite, die alle SMART on FHIR-Apps anzeigt. Dazu müssen wir Client-Ressourcen abfragen. Client-Ressourcen werden nicht ausschließlich für SMART on FHIR verwendet, daher ist ein Kriterium erforderlich, um nur die Clients auszuwählen, die SMART on FHIR-Apps repräsentieren. Ich habe das Feld Client.type verwendet und es auf den Wert "smart-on-fhir" gesetzt. Dadurch kann ich alle Daten wie folgt abfragen: Der Code ist hier abrufbar.

Hier verwende ich die Bibliothek https://github.com/beda-software/aidbox-react, um mit benutzerdefinierten Aidbox-Ressourcen zu interagieren.

Sobald die Daten geladen sind, kann das FHIR-EMR die SMART-App-Galerie rendern: Sehen wir uns an, wie die App gestartet wird. Aidbox stellt die RPC-API für viele interne Funktionen bereit.

Die aidbox.smart/get-launch-uri rpc-Funktion generiert die Launch-URI für die verwendete SMART-App. Der Code ist hier abrufbar.

Hier ist zu sehen, dass die RPC-Methode die Parameter user, iss und ctx erfordert. Ctx ist ein fhirContext, wie zuvor beschrieben. Ich verwende ihn, um Informationen über den aktuellen Patienten weiterzugeben.

Das Ergebnis dieses Aufrufs enthält die URI, die den Launch der SMART-App initiiert. Ich verwende sie, um die aktuelle Browserseite zu ersetzen: Der Code ist hier abrufbar.

Sobald ein Benutzer auf die Schaltfläche „Launch" klickt, wird er zur SMART-App weitergeleitet, die ihn wiederum zurück zum Aidbox-Authentifizierungsendpunkt und dann zur Autorisierungsseite mit einer Liste der angeforderten Scopes weiterleitet. Sobald der Benutzer den Zugriff gewährt, leitet Aidbox zurück zur SMART-App mit dem Autorisierungscode. Dieser Code wird gegen ein Access Token und einen fhirContext ausgetauscht.

Die App erhält Informationen über den aktuellen Benutzer und den aktuellen Patienten. Wenn ein Benutzer den Zugriff der App auf seine Daten beenden möchte, kann er diesen über die Aidbox-Sitzungsoberfläche widerrufen:

Live-Demo: FHIR-EMR + SMART-App

Sie können sich über die Funktionsweise dieses Prozesses anhand unserer Live-Demo-Version von Beda EMR hier informieren.

Wie Sie sehen, hält Aidbox die zuvor besprochenen Spezifikationen ein und ermöglicht es, die SMART Launch-Funktionalität dem Beda EMR in nur wenigen Tagen hinzuzufügen. Ich habe diesen Ansatz beim HL7 AU FHIR Connectathon getestet, und er funktionierte mit allen bereitgestellten Apps.

Wenn Sie an einer FHIR-nativen EMR-Lösung interessiert sind, die allen modernen Standards entspricht, wenden Sie sich bitte an Beda Software.

Um die Erweiterung Ihrer EMR-Funktionen mit SMART on FHIR-Anwendungen auszuprobieren, testen Sie die kostenlose Version von Aidbox. Sie bietet eine vollständig funktionsfähige Umgebung zum Testen und Entwickeln dieser Integrationen, mit allen erforderlichen Tools ohne Einschränkungen.

Autor:

Ilya Beda, CTO bei Beda Software

Mit Ilya über LinkedIn in Kontakt treten

Siehe auch: RBAC mit Keycloak und SMART on FHIR V2 und Warum Sie einen unabhängigen FHIR-Server benötigen.