Montag, 7. Januar 2019

FHIR ist normativ!

Am 27.12. wurde FHIR als normativer Standard veröffentlicht!

Nach dem erfolgreichen Durchlauf des Ballotierungsverfahrens von HL7 International wurde nun die finale Fassung der Version "R4" publiziert.

Allerdings unterscheidet sich FHIR von anderen (normativen) Standards in einem wichtigen Punkt:
Da bei der Entwicklung von FHIR sehr großen Wert darauf gelegt wird, dass Artefakte erst dann normativ (und damit unveränderlich) werden können, wenn sie ausgiebig und unter realen Bedingungen von mehreren Entwicklern aus mehreren Organisationen in mehreren Ländern der Welt  getestet wurden, hat man für die FHIR-Ressourcen (Datenobjekte) das sogenannte "FHIR Maturity Model" (kurz: FMM) eingeführt.

Diese Metrik hilft einerseits den HL7-Arbeitsgruppen, den Reifegrad einer Ressource anhand von mess- und nachvollziehbaren Kriterien zu bewerten und andererseits den FHIR-Anwendern, die Stabilität einer Ressource einzuschätzen.

Die Kriterien des Maturity Models im Überblick (ausführliche Beschreibung hier):
  • FMM 0: die Ressource ist im current build publiziert (Entwurfsstadium)
  • FMM 1: die Ressource ist aus Sicht der verantwortlichen Arbeitsgruppe vollständig und bereit zur Implementierung
  • FMM 2: die Ressource wurde im Connectathon getestet
  • FMM 3: die Ressource wurde ballotiert
  • FMM 4: die Ressource wurde in einem FHIR-Release publiziert. Nicht rückwärts-kompatible Änderungen sind nur mit Zustimmung der Community möglich.
  • FMM 5: die Ressource wurde in mindestens zwei FHIR-Releases publiziert, und in mindestens fünf unabhängigen, produktiven Systemen in mehr als einem Land implementiert.
  • FMM 6/N: die Ressource ist normativ: Inkompatible Änderungen sind nicht mehr möglich, substantielle Änderungen nur in Ausnahmefällen.
Da sich FHIR inzwischen über ein weites Feld von Anwendungsszenarien erstreckt und immer noch neue Bereiche erschlossen werden, sind die Artefakte der Spezifikation nicht nur unterschiedlich alt, sondern haben auch unterschiedliche Reifegrade.

Dabei sind nicht nur die Prioritäten der zuständigen Arbeitsgruppe bei HL7 ausschlaggebend, sondern vor allem die Bereitschaft der Industrie bzw. der Anwender, die Ressourcen in Prototyp-Entwicklungen zu testen und Feedback zu geben.

In der Konsequenz haben in der aktuell publizierten Version noch bei weitem nicht alle Ressourcen den Reifegrad FMM 6 erreicht, der Voraussetzung für den normativen Status ist.

Folgende Ressourcen sind in R4 mit normativem Status enthalten:
Dabei fällt auf, dass es sich überwiegend um infrastrukturelle Ressourcen handelt und weniger um klinische Objekte, daher drängt sich natürlich die Frage auf, warum die aktuelle Version R4 als "normativ" gefeiert wird, wenn bei der großen Mehrheit der Datenobjeke noch immer "for trial use" im Beipackzettel steht?

Die wichtigste Eigenschaft von R4 ist, dass die technologische Basis von FHIR nun stabil ist.
Dies drückt sich weniger durch die Anzahl der normativen Ressourcen aus, sondern vielmehr durch die Anzahl der normativen Kapitel der Spezifikation.

So sind alle wichtigen technologischen Grundlagen von FHIR in R4 normativ und damit stabil, unter anderem:

Was bedeutet das alles für diejenigen, die 2019 mit der Implementierung von FHIR beginnen wollen?

Wie schon in der Version STU3 gilt auch in der normativen Version die Empfehlung, sich zunächst einen Überblick zu verschaffen, welche Ressourcen bei der eigenen Implementierung benötigt werden und welche Reifegrade diese haben.

Niedrige Reifegrade (FFM < 3) sind kein Grund, nicht mit der Implementierung und Nutzung zu beginnen (zur Erinnerung: Ressourcen können nur dann höhere Reifegrade erreichen, wenn sie von der Industrie getestet und implementiert werden!).
Es ist jedoch zwingend notwendig, den Kontakt zur Community herzustellen, um
  1. Fragen und Unklarheiten zu den jeweiligen Ressourcen zu klären und damit der Arbeitsguppe zu ermöglichen, die Dokumentation zu verbessern,
  2. Feedback in Form von Beteiligung an Connectathons oder Einreichung von Change Requests geben zu können, 
  3. bei anstehenden substantiellen Änderungen rechtzeitig informiert zu werden und vom Mitspracherecht der Community Gebrauch machen zu können.
Zwar birgt die Nutzung von unreifen Ressourcen die Gefahr von nicht-kompatiblen Änderungen in späteren Releases, jedoch auch die Chance, durch aktive Mitarbeit an der weiteren Gestaltung der Ressource mitwirken zu können und sie damit für das eigene Projekt besser nutzbar zu machen.

Der einfachste Weg in die Community führt über den FHIR-Chat: http://chat.fhir.org

Falls Sie Fragen zu Nutzung von FHIR R4 für ein konkretes Projekt oder FHIR im allgemeinen haben, verwenden Sie bitte das Kontaktformular auf unserer Homepage und wir helfen Ihnen gerne weiter.





Mittwoch, 21. November 2018

Was FHIR für die KI tun kann...

Auf der konstitutionierenden Sitzung der Arbeitsgruppe "Künstliche Intelligenz" des bvitg, wurden in den letzten beiden Tagen zahlreiche Problemfelder für die Nutzung von KI-Algorithmen im Deutschen Gesundheitswesen identifiziert. Gleichzeitig wurde jedoch immer wieder deutlich, dass FHIR an vielen Stellen technische Lösungen bieten kann. Daher wollen wir hier einige Aspekte des neuen HL7-Standards mit Relevanz für KI-Systeme aufführen:

1. Datenvalidierung

Gleichförmige, valide und strukturierte Daten bilden die Basis für die Entwicklung von KI-Systemen. Mit Hilfe des Conformance-Frameworks in FHIR und den umfangreichen Möglichkeiten der Profilierung, können die Mindest-Anforderungen an die gelieferten Daten und die Regeln zur Validierung sehr präzise formuliert und mittels der Validatoren zur Laufzeit auf die Instanzen angewendet werden.
(zur Community)

2. Terminologie-Framework

Um Daten aus verschiedenen Quellen vergleichen zu können, müssen Konzepte codiert werden. Medizinische Terminologien und CodeSysteme, wie z.B. ICD-10, LOINC oder SNOMED sind jedoch enorm umfangreich und komplex in der Handhabung. FHIR bieten Entwicklern die Möglichkeit diese Komplexitäten sowie das Mapping zwischen verschiedenen Terminologien von der eigenen Applikation fernzuhalten und in spezialisierte Terminologie-Server zu verlagern. Mittels der Terminologie-API ist eine einfache und standardisierte Anbindung der Systeme möglich.
(zur Community)

3. Einbindung in Primärsysteme als Clinical Decision Support Dienst

KI-Dienste werden häufig in Form von Entscheidungsunterstützungssystemen eingesetzt (z.B. zur Bewertung von Radiologischen Bildern, Auswertung von EKGs oder unterstützender Labordiagnostik). Um solche Dienste über eine standardisierte Schnittstelle in Klinische Primärsysteme integrieren zu können, liefert "CDS-Hooks" ein FHIR-basiertes Framework, das die Triggerung von CDS-Diensten sowie den Datenaustausch zwischen Primärsystem und CDS beschreibt und das Format für die Rückgabe von Hinweisen an den Anwender vereinheitlicht.
(zur Community)

4. "Datenspenden" von Patienten

Die Aquise von Daten für das Trainieren von Algorithmen ist aufgrund der hohen Datenschutzanforderungen im Gesundheitswesen eine besondere Herausforderung.
Für die "All of Us"-Studie wurde in den USA ein Framework entwickelt, mit dem Patienten aktiv entscheiden können, ihre Daten in pseudonymisierter Form zu "spenden". "Sync4Science" ist eine Kooperation US-amerikanischer EHR-Hersteller, des National Institutes of Health (NIH), des Office of the National Coordinator for Health IT (ONC) und der Abteilung für Biomedizinische Informatik an der Harvard Medical School.

5. Synthetische Massendaten

Ein weiterer Weg zu mehr Daten kann die Erzeugung synthetischer Patientendaten sein. Synthea ist eine OpenSource verfügbares Framework, das realistische, aber synthetische Massendaten im FHIR-Format erzeugt. Eine Übertragung des Modells auf deutsche Gegebenheiten ist technisch möglich.

6. Nachvollziehbarkeit

Die von KI-Systemen erzeugten Entscheidungen, Hinweise oder Daten müssen auf transparente und nachvollziehbare Weise für den Anwender als solche zu erkennen sein.
Mit Hilfe der Provenance-Ressource bietet FHIR eine Möglichkeit, die Herkunft von Daten detailliert festzuhalten. Ein Best-Practice-Ansatz für die Darstellung von Konfidenz und den präzisen Verweis auf  relevante Datenfelder oder -Bereiche, wird derzeit im FHIR-Chat diskutiert.

7. Einheitliches Datenmodell

Warum FHIR nicht nur zum Datenaustausch zwischen klinischem Primärsystem und KI-Service dienen kann, sondern direkt zum Datenmodell für Maschinelles Lernen taugt, kann Google am besten erklären: https://ai.googleblog.com/2018/03/making-healthcare-data-work-better-with.html


Abstimmungsverfahren für Deutsche Basisprofile eröffnet

Das Technische Komitee für FHIR von HL7 Deutschland e.V, bittet bis zum 17. Dezember um die Kommentierung der bisher erarbeiteten Conformance-Ressourcen.
Die stabile Ballot-Version ist seit dem 17. November unter ig.fhir.de/basisprofile-de/0.2 veröffentlicht.
Die maschinenlesbaren Conformance-Ressourcen können als zip und als FHIR-Package heruntergeladen werden.
Kommentare können in GitHub als "Issue" eingegeben (github.com/hl7germany/basisprofil-de/issues) oder formlos per eMail an tc@fhir.de gesendet werden.
Die Arbeitsversion, in der die Kommentarauflösung erfolgt (current build), befindet sich in der FHIR-Registry “Simplifier“ (simplifier.net/BasisprofilDE/~introduction).
Wichtige Zeitangaben:
Ankündigung der Kommentierungsphase: 17. Oktober 2018
Eröffnung der Kommentierungsphase: 17. November 2018
Schließen des Kommentierungsphase: 17. Dezember 2018
Besprechung und Auflösung der Kommentare erfolgt bis zum 30. Januar 2019.
Zur offiziellen Verlautbarung: http://newsletter.hl7.de/m/7199482/
Wir bitten um zahlreiche Beteiligung!
-->