gms | German Medical Science

Einleitung: Der Interoperabilitätsstandard HL7 FHIR kommt in immer mehr Projekten der system- und einrichtungsübergreifenden übertragung medizinischer Daten zum Einsatz [1]. Neben dedizierten FHIR-Servern wie HAPI-FHIR [2] und Vonk [3] rüsten viele Hersteller von IT-Lösungen im Gesundheitswesen ihre Produkte mit FHIR-basierten Schnittstellen aus. Bei der Umsetzung konkreter Vorhaben zum Austausch von Daten ist neben der Funktionalität auch die Performance ein essentieller Faktor. Vor dem Hintergrund der Funktionsvielfalt und der Änderungsgeschwindigkeit der FHIR-Spezifikation [4], muss der Umfang der jeweils durch einen Hersteller unterstützten Anteile des Standards, je nach Bedarf in einem Projekt geprüft werden. Hierfür stehen bislang Herstellerangaben und die FHIR-Ressource CapabilityStatement zur Verfügung [5].

Methodik: In der hier beschriebenen Arbeit wurde eine Methode entworfen und implementiert, FHIR-Server und FHIR-Schnittstellen automatisiert auf die Umsetzbarkeit geplanter Use Cases zu validieren. Dabei wurden zwei Kategorien von Prüfungen unterschieden: Die erste Kategorie umfasst statische Tests, die den Umfang unterstützter FHIR-Ressourcen ermitteln und über das CapabilityStatement abgleichen. In der zweiten Kategorie werden dynamische Tests durchgeführt, die unterstützte Funktionen überprüfen: Anlegen, Suchen, Aktualisieren, inhaltliches Prüfen oder Löschen von konkreten FHIR-Ressourcen. über diese Kategorie kann die Unterstützung konkreter Workflows eines Produktes überprüft werden. Nach den erfolgten Prüfungen werden die im Rahmen der Tests entstandenen Inhalte wieder gelöscht. Die Bereinigung erfolgt entweder nach konkreten, vom FHIR-Server vergebenen IDs oder durch die Angabe eines Business Identifiers.

Ergebnisse: Die entwickelte zweiteilige Methode zum Test von FHIR-Servern und -Schnittstellen wurde mittels Skripten für den API-Client Postman implementiert [6]. Mit diesem weit verbreiteten Werkzeug können REST-, SOAP und GraphQL-Anfragen an Server gestellt werden. Der Entwurf der Skripte wurde mit Git versioniert. Es entstand eine Skriptbibliothek zum Test verschiedener Funktionalitäten einer FHIR-Schnittstelle, deren Ergebnis dem Nutzer zum Abschluss grafisch präsentiert wird: Wieviele Iterationen an Tests wurden durchgeführt, welche Fähigkeiten gibt der Server an, wieviele Tests wurden bestanden / nicht bestanden und welche Laufzeiten benötigten die jeweilig ausgeführten Tests. Auf diese Weise können konkrete Use Cases, z.B. das Nutzen bestimmter Typen von Ressourcen, die etwa angelegt, miteinander verlinkt, aktualisiert etc. werden müssen, konkret geprüft und über umfangreichere Iterationen die Performance einer Installation in Bezug auf diesen Anwendungsfall evaluiert werden.

Diskussion: Automatisierte Tests von FHIR-Servern können die Entscheidung für ein konkretes Produkt oder eine konkrete Ressourcennutzung in einem Projekt, zusätzlich zu Herstellerangaben und CapabilityStatement, auf eine bessere Bewertungsgrundlage stellen. Außerdem sind mit derartigen Tests auch Produkthersteller in der Lage, den Umfang ihrer Software insbesondere nach Anpassungen und Updates, zu testen und zu vergleichen. Wiederholte Testausführungen in einer Continuous Integration Umgebung können zudem zur Validierung des Funktionsumfang einer FHIR-Schnittstelle eingesetzt werden.

Durch die Implementierung der Testbibliothek als Postman-Skripte ist eine Weiterentwicklung und Anpassung an die Bedürfnisse in konkreten Projekten möglich. Hierfür könnten künftig weitere Sammlungen von Code Snippets entstehen, die für jeweils ähnlich gelagerte Vorhaben eingesetzt werden können. Um dies zu ermöglichen, ist eine Veröffentlichung der automatisierten Funktionstests als Git-Projekt und die Einladung an interessierte Personen, hieran gemeinsam weiterzuarbeiten, in Planung. Darüber hinaus können Postman-Test-Skripte automatisiert in Skripte des Load Testing Tools k6 (https://k6.io/) konvertiert werden. Dadurch werden die Aussagen bezüglich der Performance eines Produktes noch aussagekräftiger.

Die Autoren geben an, dass kein Interessenkonflikt besteht.

Die Autoren geben an, dass kein Ethikvotum erforderlich ist.