FHIR Standard

from a developers perspective

About the Presenter:

 

Jan Dahlke

 

* Professional Developer bei TAS seit 01.06.2023

* 2020 Wechsel nach Telemedizinischen UI's und dabei FHIR entdeckt

* Mitarbeit an der DentaMileConnect und an TeleMed5000

* vor allem als Client-Developer mit einer internen FHIR Implementation Erfahrungen gesammelt

refresher: Was ist Rest - Representational State Transfer

  • Vereinfachte Kommunikation: Verwendet standardisierte Methoden und Statuscodes.
  • Zustandslosigkeit: Jede Anfrage ist unabhängig; kein gespeicherter Kontext auf dem Server.
  • Einheitliche Schnittstelle: Ein konsistentes und begrenztes Set von wohldefinierten Methoden.
  • Geschichtetes System: Der Client kann normalerweise nicht feststellen, ob er direkt mit dem Endserver oder einem Zwischenvermittler verbunden ist.

REST - The mental model

  • Ressourcen: Alles ist eine Ressource, eindeutig identifiziert über URIs.
  • Standardmethoden: CRUD-Operationen (Erstellen, Lesen, Aktualisieren, Löschen) mit HTTP-Verben (POST, GET, PUT, DELETE).
  • Darstellung: Ressourcen können verschiedene Formen oder "Darstellungen" haben (z.B., JSON, XML).
  • Zustandslose Interaktionen: Jede Anfrage muss alle Informationen enthalten, die zum Verstehen und Verarbeiten der Anfrage benötigt werden.
  • Abfrageparameter: Werden verwendet, um Anfragen zu verfeinern, Ergebnisse zu filtern oder Details anzugeben (z.B., ?limit=10 oder ?sort=asc).

Von REST zu FHIR-REST

  • Spezialisierte Anwendung: FHIR nutzt die REST-Prinzipien speziell für das Gesundheitswesen.
  • Standardisierte Ressourcen: FHIR definiert klare Ressourcen wie Patient, Beobachtung, Diagnose, etc.
  • Globale Konsistenz: FHIR möchte sicherstellen, dass Gesundheitsdaten weltweit einheitlich und interoperabel sind.
  • Erweiterbarkeit: Während FHIR strenge Standards setzt, ermöglicht es dennoch kundenspezifische Erweiterungen und Profile.
  • Sicherheit im Fokus: Angesichts der Sensibilität von Gesundheitsdaten legt FHIR großen Wert auf Sicherheit und Datenschutz.

FHIR ist eine REST "Instance"

Kernkomponenten der FHIR Spezifikation

source: http://hl7.org/fhir/

  • REST API:
    • Nutzt standardisierte HTTP-Verben (GET, POST, PUT, DELETE).
    • Interaktion mit FHIR Ressourcen durch CRUD-Operationen (Create, Read, Update, Delete).
  • Suche (Search):
    • Möglichkeit, spezifische Ressourcen durch AbfrageParameter zu finden.
    • Unterstützung von Sortierung, Filterung und Paginierung und ResourcenHistorie
  • Ressourcenliste (Resource List):
    • Eine Übersicht aller verfügbaren RessourcenTypen in FHIR (z.B. Patient, Encounter, Observation).
    • Jede Ressource hat eigene Attribute, Beziehungen und Use-Cases.

FHIR-Ressourcen: Grundstruktur und Vererbung

http://hl7.org/fhir/datatypes.html

  • Resource:

    • Grundressource, von der andere erben; enthält allgemeine Elemente wie id, meta.

  • DomainResource:

    • Erweitert Resource. Fügt domänenspezifische Elemente hinzu wie text, contained, extension.

  • Spezifische Ressourcen (z.B. Patient, Beobachtung):

    • Konkrete Typen, die oft von DomainResource erben; haben spezifische Strukturen und Elemente.

  • Am Beispiel "Patient" Ressource:

    • Vererbung folgt: Resource -> DomainResource -> Patient.

  • Erweiterbarkeit:

    • Grundressourcen unterstützen Erweiterungen, um zusätzliche Elemente hinzuzufügen.

  • Profiling:

    • Anpassung der Kernressourcen an spezifische Bedürfnisse, bleibt aber interoperabel.

Exkurs: Basisresourcen, Valuesets and FHIR Types

  • Bundle: Eine Sammlung von Ressourcen.
  • Value Set: Eine Liste von Werten für ein bestimmtes Merkmal.
  • Timing: Eine Spezifikation von Ereignissen im Laufe der Zeit (z.B. Medikamenteneinnahmeplan).

Besonderheiten von Bundles

  • Eintrags-Typisierung: Jeder Eintrag in einem Bundle ist eine eigenständige Ressource und kann einen eigenen Typ haben (z.B. Patient, Observation, etc.). Dies ermöglicht die Zusammenstellung gemischter Daten in einem einzelnen Bundle.
  • --> der Developer muss beim "Auspacken" TypeOf machen!
    • das ist vor allem in RunTime Languages wie JS oder TS eine challenge, es gibt halt keinen <Result> Type wie in Rust

das ist nur eine kleine Auswahl

ResourcenAnfrage vs Suche

  • Ressourcenanfrage (Resource Request):
    • Ziel: Eindeutige Identifizierung und Abruf einer spezifischen Ressource.
    • Beispiel: Abruf eines spezifischen Patienten mit der ID '1234'.
    • Pseudo CURL Befehl: curl -X GET https://[FHIR-SERVER]/Patient/1234
  • Suche (Search) - Rückgabe eines Bundles:
    • Ziel: Finden einer Gruppe von Ressourcen, die bestimmten Kriterien entsprechen.
    • Beispiel: Suche nach allen Patienten mit dem Namen "Müller".
    • Pseudo CURL Befehl: curl -X GET https://[FHIR-SERVER]/Patient?name=Müller
    • Ergebnis: Ein Bundle von Patientenressourcen, die den Suchkriterien entsprechen.
  • Geltungsbereich (Scope): Definition des Anwendungsbereichs der Ressource.
  • Verwendung und Grenzen (Usage and Boundaries): Beschreibt, wie und wo die Ressource verwendet werden sollte.
  • Datenformate: FHIR unterstützt mehrere Formate, am häufigsten JSON und XML.
  • Kardinalität von Attributen: Definiert die Mindest- und Höchstzahl von Attributen, die eine Ressource haben kann (z.B. 0..1 oder 1..*).
  • Version: Jede Ressource hat eine Version, um Veränderungen zu verfolgen.
  • ID: Eindeutige Kennung für jede Ressource. (uuidv4 as best practice)
  • ! jede spezifische Ressource hat ihre eigenen Params zusätzlich zu den Standard Params von FHIR

der Aufbau einer FHIR-Resource

 

  • Definition: Zentrale Ressource, die Informationen über eine Person enthält, die Gesundheitsdienstleistungen nutzt.
  • Typische Felder: Vollständiger Name, Geburtsdatum, Geschlecht, Adresse, Kontaktinformationen, Versicherungsdetails.

Eine Beispiel: die Resource "Patient"

source: http://hl7.org/fhir/patient.html

Params für den Patienten

  • Name: Suche nach Patientennamen.
  • Geburtsdatum: Suche nach Geburtsdatum.
  • Adresse: Suche nach Adresse.
  • (u.a., je nach den spezifischen Anforderungen Ihrer Präsentation)

ein Einblick: FHIR-Werkzeuge: Nutzen und Vorteile

  • Nutzen eines FHIR-Clients (z.B. fhir.js):

    • Vereinfacht die Interaktion mit FHIR-EndPunkten durch vordefinierte Funktionen.
    • myFhirClient.search<Bundle<Patient>>(params: TypedParams)
    • Unterstützt den Entwickler durch integrierte FHIR-Validierung und -Konvertierung.
    • Optimiert und beschleunigt die AnwendungsIntegration und -entwicklung.

  • Vorteile der HAPI-FHIR-Server-Implementierung: (free instance: https://hapi.fhir.org/)

    • Robuste und bewährte Implementierung des FHIR-Standards.
    • Einfache Konfiguration und Anpassung an spezifische Anforderungen.
    • Integrierte Tools für Profiling, Validierung und Versionierung.

Thought Experiment: Bundeseinheitlicher Medikationsplan

https://de.wikipedia.org/wiki/Medikationsplan

working with FHIR-Rest

https://hapi.fhir.org/

https://gitlab.spree.de/strame-fhir/strame_fhir_curls

man braucht:

* vscode https://code.visualstudio.com/download

* das plugin rest-client https://marketplace.visualstudio.com/items?itemName=humao.rest-client

Aufgabe 1: https://gitlab.spree.de/strame-fhir/strame_fhir_curls/-/tree/main/aufgaben

1. create a patient on https://hapi.fhir.org

2. get the patient by id

3. (optional). alter the name of the patient

4. create a practioner

5. find a good field in the patient to apply a "hausarzt" and connect the ressources by using PUT on your patient

6. what are your experiences/ what worked well, what did not work well

 

Aufgabe2: Getting deeper into the Datamodell

http://hl7.org/fhir/medicationstatement.html

 

https://gitlab.spree.de/strame-fhir/strame_fhir_curls/-/blob/main/aufgaben/aufgabe_2_strame_beispiel_spot_the_difference.http

 

# dive deep in the fields of medication (Codeable Reference)
# describe your thinking on how you would reference a medication and which fields to use for what

# what would be missing here in either or to fulfill "Medikationsplan" ?

persist the results: (what are your findings?)

Bundeseinheitlicher Medikationsplan.         30min!

Aufgabe3 : Betrachte den Plan und finde die Beteiligten FHIR Ressourcen

Aufgabe3: Erzeuge alle notwendigen Ressourcen und setze Referenzen

hier kann man spicken inklusive der Fehler die der Presenter gemacht hat, beachte, wie der Name falsch behandelt wurde

https://gitlab.spree.de/strame-fhir/strame_fhir_curls/-/blob/main/bundeseinheitlicher_medikationsplan.http

fast eure Erkenntisse zusammen

Optional: Gedankenspiel: TAS FhirServerImplementation

Task:

* Besprecht im Plenum das grobe Ablaufvorgehen, wenn man auf Grundlage einer xml aller Ressourcen eine implementieren wollte analog/konkurrent zu hapi.fhir

 

* zeige https://github.com/HL7/fhir/tree/master/source, dass hier alle Resourcen in xml beschrieben sind.

* Was kann man damit anstellen als Entwickler/Projektmanager/Architect für MedProdukte?

 

* sichere ergebnisse auf whiteboard ?

 

15min!

Schluß:

wir wollen nun vom speziellen zum allgemeinen nochmal durch das Gelernte/Erfahrene gehen und zusammentragen

Client/Consumer:

Wie verhalten sich FHIR Types in GUI Templates?

Braucht man DTOS?

Wie aggregiert man von mehreren Endpunkten:

the good:
*

*

the bad:

*

*

Schluß

Schnittstelle REST:

 

* how should the implementer know tf?

* is fhir interop here? can interop be ensured here?

the good:

*

*

the bad:

*

*

Schluß

meta, meta: the "birds" view

the good:

*

*

 

 

the bad:

*

*

Made with Slides.com