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!

Mittwoch, 4. Juli 2018

Festsetzung der §291d Schnittstellen auf FHIR

Die Kassenärztliche Bundesvereinigung (KBV) hat heute die Festlegung der Schnittstellen nach §291d basierend auf HL7 FHIR bekanntgegeben:

Die Spezifikation beruht auf dem HL7-Standard FHIR (ausgesprochen wie engl.: "fire") in der Version 3.0.1 ("STU3"). Zwischen Verordnungssystem und PVS werden FHIR-Ressourcen über eine REST-basierte API kommuniziert.

Quelle: kbv.de





Die Umsetzung der entsprechenden Schnittstellen ist für die Systemhersteller bis spätestens 2020 verpflichtend.



Was ist nun für PVS-Hersteller zu tun?

Niemand, der FHIR-Schnittstellen implementiert, muss "bei Null" anfangen. Es gibt Codebibliotheken für die meisten gängigen Programmiersprachen, wie zum Beispiel HAPI für Java oder die FHIR-API für .NET

Weiterhin gibt es fertige FHIR-Fassaden, die auf bestehende Systeme aufgesetzt werden können.
(Für Ungeduldige geht es hier direkt zum "Build your first FHIR facade"-Tutorial)

In Deutschland und weltweit hat sich inzwischen eine aktive Entwickler-Community gebildet, die sich zu allen Belangen rund um FHIR austauscht. Interessierte sind im FHIR-Chat stets willkommen!

Die Gefyra GmbH bietet ein breites Portfolio an FHIR-Schulungen an, um den Start mit FHIR zu erleichtern. Unsere Experten begleiten FHIR-Projekte und beraten System-Hersteller bei der Implementierung.


Mittwoch, 6. Juni 2018

Apple-Update

Es gibt Neuigkeiten zum Thema "Apple on FHIR" und damit ein weiteres Argument für "Argonaut für Deutschland":

Apple hat nun die "Health Records API" für Entwickler verfügbar gemacht:
zur Pressemeldung
zur technischen Dokumentation


Quelle: www.apple.com

Unklar ist derzeit noch, ob sich das DSTU2-basierte Framework von Apple auch mit aktuelleren FHIR-Releases nutzen lässt. Es ist jedoch davon auszugehen, das Apple die aktuelle Version "STU3" überspringt und dann Anfang 2019 auf das normative "Release 4" geht, analog zur Roadmap des US-amerikanischen Argonaut-Projektes.

Update zum Update (6.6.2018 13:30h):
Nach unseren Recherchen ist Apple Health derzeit noch ausschließlich nutzbar auf Geräten, deren Region auf "United States" eingestellt ist und auf die Kommunikation mit einer der 40 kooperierenden Kliniken in den USA limitiert. Zur Roadmap bezüglich der FHIR-Versionen liegen uns derzeit noch keine Informationen vor.

Update zum Update zum Update (6.6.2018 19:30h):
Hier kommt das Video und die weiteren Infos von der  Apple Worldwide Developers Conference (WWDC) 2018:
https://developer.apple.com/videos/play/wwdc2018/706/

Freitag, 18. Mai 2018

Argonaut für Deutschland


Benötigt Deutschland ein "Argonaut-Projekt"?


In einem vorherigen Beitrag ("Funktioniert Apple Health auch in Deutschland?") haben wir erläutert,
welche Voraussetzungen in den USA für die rasche Umsetzung von FHIR-Schnittstellen bei den Systemherstellern sorgen.

Dabei sind zwei Aspekte besonders interessant:

  1. das Subventionsprogramm im Rahmen des "HITECH Acts", das finanzielle Anreize für die Implementierung schafft
  2. ein fest vereinbarter Datensatz (hervorgegangen aus dem "Argonaut"-Projekt), bestehend aus etwa einem Dutzend FHIR-Ressourcen, mit fest vorgegebenen Pflichtfeldern und Terminologien, als "kleinster gemeinsamer Nenner" dieser Implementierungen.

Während sich ein 27 Milliarden dickes Subventionsprogramm für deutsche Systemhersteller im Gesundheitswesen nicht so ohne weiteres aus dem Ärmel schütteln lässt, so ist zumindest die Festlegung eines Minimal-Datensatzes, analog zu Argonaut, kein Hexenwerk.

Ein genauerer Blick in den "Argonaut Data Query Implementation Guide" zeigt, dass einige der dort definierten Ressourcen (z.B. Patient, Condition, AllergyIntolerance, Medication, Procedure...) zum Großteil über nur sehr wenige Pflichtfelder verfügen, andere (Goal, CarePlan, CareTeam) bestehen lediglich aus Freitexten oder dienen der logischen Gruppierung von Ressourcen.

Dennoch reichen die Vereinbarungen aus, um Diagnosen, Allergien, Impfungen, Medikations-, Vital- und Labordaten strukturiert und standardisiert über eine offene API zur Verfügung zu stellen.

Das Argonaut-Projekt hat darauf basierend bereits viele interessante Entwicklungen hervorgebracht, darunter nicht zuletzt die Möglichkeit für Patienten, Gesundheitsdaten auf das iPhone zu übertragen oder klinische Daten für die Forschung bereitzustellen ("Sync-4-Science"). Insbesondere für den Datentransfer zu und zwischen elektronischen Patientenakten, wie sie derzeit z.B. von der Techniker Krankenkasse betrieben werden, sind die Argonaut-Daten qualitativ und quantitativ ideal.

Um für deutsche Hersteller eine vergleichbaren Minimal-Datensatz zu erstellen, braucht es relativ wenig. Für einige der Ressourcen existieren bereits deutsche Basis-Profile, andere können ohne Änderung aus Argonaut übernommen werden.
Die größte Herausforderung besteht darin, einen adäquaten Ersatz für die in Argonaut häufig verwendeten, internationalen SNOMED-Terminologien zu finden, da für deren Nutzung in Deutschland keine landesweite Lizenz existiert und damit für Hersteller und Anwender nicht unerhebliche Lizenzkosten entstehen würden.

Das Technische Komitee für FHIR von HL7 Deutschland e.V. sucht derzeit nach Herstellern und Organisationen, die Interesse an einem "Deutschen Argonaut-Projekt" haben, sich an der Spezifikation des Datensatzes beteiligen möchten oder eine darauf basierende Implementierung erwägen.

Die Diskussion findet im internationalen FHIR-Community-Chat statt. Die Anmeldung ist kostenlos. Interessierte, Neugierige und Schaulustige sind herzlich willkommen!

Dienstag, 8. Mai 2018

Systemwechselschnittstelle nach SGB V? FHIR!

Die Änderungen des Paragraph 291d SGB V fordern die Festlegung einer System- bzw. Arztwechselschnittstelle:
In informationstechnische Systeme, die zum Erheben, Verarbeiten und Nutzen von personenbezogenen Patientendaten eingesetzt werden in
1. der vertragsärztlichen Versorgung,
2. der vertragszahnärztlichen Versorgung und
3. Krankenhäusern,
sind offene und standardisierte Schnittstellen zur systemneutralen Archivierung von Patientendaten sowie zur Übertragung von Patientendaten bei einem Systemwechsel zu integrieren. 
Einen §291 SGB V gibt es in den USA zwar nicht, jedoch einen Zusammenschluss zahlreicher Systemhersteller ("Argonaut-Projekt"), die um die rasche Spezifikation und Umsetzung von Interoperabilitätsanforderungen basierend auf dem FHIR-Standard, bemüht sind.
Die zugrunde liegenden Anforderungen lauten in den USA zwar etwas anders, z.B.:

  • Massendatenexport von pseudonymisierten Behandlungsdaten aus klinischen Systemen an Forschungseinrichtungen
  • Bereitstellung von anonymisierten Massendaten für KI-Systeme 
  • Aus-und Bewertung der Populationsgesundheit,
die hierfür konzipierte Lösung, die "FHIR Bulk Data API" deckt jedoch auch die Anforderungen an eine Systemwechselschnittstelle problemlos ab. Da das Argonaut-Projekt in dem Ruf steht, "Nägel mit Köpfen" zu machen, wird derzeit nicht nur an der Spezifikation gearbeitet, sondern auch eifrig implementiert und getestet. 

Interessanterweise findet der nächste großangelegte Test der Spezifikation ausgerechnet im Heimatland des Systemwechselschnittstellenproblems (Deutscher als ein Wort mit 35 Buchstaben wird's nicht) im Rahmen des Internationalen HL7 Work Group Meeting statt. 
Am Wochenende vom 12.-13. Mai wird in Köln programmiert und exportiert, bis die Leitungen glühen. Eine Beschreibung des zu testenden Szenarios findet sich hier.

Kurzeinführung in die FHIR Bulk Data API (engl.)



Aufgrund der modularen Architektur und der Profilierbarkeit des FHIR-Standards, ist die Spezifikation problemlos auf deutsche Gegebenheiten anpassbar. 

HL7 Deutschland e.V. arbeitet bereits seit mehreren Monaten an der Definition der deutschen Basisprofile für typische Datenobjekte, wie Patient, Organisation, Versicherungsdaten und Diagnosen. Mappings für die im niedergelassenen Bereich weit verbreiteten xDT-Formate wurden ebenfalls berücksichtigt. 

Es steht zur Erfüllung der §291-Anforderungen also eine Spezifikation zur Verfügung, die von zahlreichen Herstellern bereits implementiert und getestet wird, auf einem modernen, offenen und flexiblen Standard basiert und von einer breit aufgestellten Community von Entwicklern und Spezifizieren getragen wird.


In den kommenden Monaten werden aus dieser Community zahlreiche Tools, Frameworks, Code-Bibliotheken und Beispielimplementierungen hervorgehen, die die Umsetzung der entsprechenden Schnittstellen erheblich vereinfachen und beschleunigen.

Es bleibt zu hoffen, dass sich Deutschland den Argonauten anschließt, vielleicht im Rahmen eines "Epigonen-Projektes"?

Montag, 30. April 2018

FHIR-Workshop am 12./13.Juni in Berlin

Am 12. und 13. Juni 2018 veranstalten wir in Zusammenarbeit mit der ZTG GmbH einen FHIR® Workshop in Berlin.


Der Workshop umfasst unter anderem:
  • Entstehung, Motivation und Grundprinzipien und von FHIR 
  • Übung: demografische Patientendaten modellieren 
  • REST-Paradigma (mit Übung) 
  • Aggregation und Suche (mit Übung) 
  • Operationen (mit Übung) 
  • Resourcen verknüpfen (mit Übung) 
  • Terminologien (mit Übung) 
  • Transaktionen 
  • Paradigmen: Dokumente und Nachrichten 
  • Questionnaires 
  • FHIR-Applikationen, -Frameworks und Anwendungsszenarien (Live-Demo) 
  • FHIR und HL7 V2/IHE/CDA 
Das Programm richtet sich an Entwickler und technisch interessierte Personen, es sind jedoch keine Programmierkenntnisse erforderlich.
Vorkenntnisse in XML und Erfahrungen mit anderen Standards im Gesundheitswesen sind von Vorteil aber nicht notwendig.

Die Teilnahmegebühr beträgt 1.600,-€ inkl. MwSt. für die zweitägige Veranstaltung. Für Studierende beträgt die Gebühr 800,-€ inkl. MwSt. Die Gebühr beinhaltet neben dem eigentlichen Seminar Schulungsunterlagen, ganztägig Getränke, Snacks und ein tägliches Mittagessen. Reisekosten sind nicht enthalten. Die Teilnehmer werden gebeten, eigene Notebooks mitzubringen.

Weitere Informationen und Anmeldung: www.ztg-nrw.de

Termin: 12./13. Juni
Hinweis: am 14./15. Juni trifft sich - ebenfalls in Berlin - das Interoperabilitätsforum. Wer die Gelegenheit nutzen möchte, die Deutsche FHIR-Community kennen zu lernen, sollte den Aufenthalt um zwei Tage verlängern! Die Teilnahme steht ist kostenlos und steht jedem offen. Mehr Informationen und Anmeldung: http://interoperabilitaetsforum.de/



Veranstaltungsort: Beredsam Seminarräume Berlin

Montag, 23. April 2018

ConhIT Nachlese

Die ConhIT 2018 - und damit unsere zweite Präsenz auf der Fachmesse für IT im Gesundheitswesen - ist vorüber.
Im Vergleich zum Vorjahr konnten wir einen erheblichen Zuwachs am qualitativen und quantitativen Interesse für FHIR feststellen.


Auf der Akademie, der Innovations-Session, den Themenführungen und den Aussteller-Ständen: Das Thema "FHIR" war überall präsent.
Über 100 Besucher kamen zu unserem Kurzvortrag zum Thema "Apple on FHIR" bei den Innovations-Sessions und auch bei der FHIR-Themenführung des bvitg gab es nur noch Stehplätze ;)

Wir freuen uns über die vielen neuen FHIR-Projekte und -Initiativen und bedanken uns bei allen Kunden und Interessenten für die tollen Gespräche auf unserem Messestand.

Unser Dank gilt insbesondere auch der DMI für die Gelegenheit, im Rahmen der Kompetenz-Workshops das FHIR-basierte IHE-Profile "MHD" für den Dokumentenaustausch vorzustellen.


Donnerstag, 12. April 2018

Apple on FHIR auf der ConhIT-Innovationssession

Mit der Frage "Funktioniert Apple Health auch in Deutschland?" beschäftigen wir uns auf der ConhIT Innovationssession.

Datum:18. April 2018
Zeit: 14:15 - 15:30 Uhr
Ort: Networkingfläche, Halle 4.2

Besuchen Sie uns auch auf unserem Stand D-103 in Halle 4.2!

IHE MHD: XDS "in einfach"

Die DMI lädt auf der ConhIT 2018 im Veranstaltungsraum "Trier" zu Kompetenzworkshops mit
Fachreferenten ein, unter anderem:

IHE-Profil MHD: XDS „ in einfach“
(Referentin: Simone Heckmann)

Der Vortrag bietet eine Kurzeinführung in FHIR, einen Überblick über die Aktivitäten von IHE in Bezug auf den neuen HL7-Standard und stellt das neue, FHIR-basierte MHD-Profil (Mobile Access to Health Documents) dem etablierten XDS-Profil (Cross-Enterprise Document Sharing) gegenüber.

Mittwoch, 11. April 2018

Medikationsplan on FHIR - Der Workshop

Im Rahmen des HL7 International Working Group Meetings findet am 11. Mai 2018 im Maritim-Hotel Köln ein Workshop zum FHIR-basierten MedikationsplanPlus statt.

Der Workshop richtet sich an Personen, die bislang noch keine Erfahrung mit FHIR oder der MedikationsplanPlus-Spezifikation haben oder ihr vorhandenes Wissen vertiefen möchten.

Die Veranstaltung ist in vier Blöcke unterteilt:

12:00-13:30 Einführung in FHIR
14:00-15:00 Medikationsplan Überblick
15:30-17:00 Hands-on Workshop 1: cross-plattform FHIR-Apps mit NativeScript
17:30-19:00 Hands-on Workshop 2: FHIR implementieren mit dem Java-Framework

Dozenten: Simone Heckmann, Stefan Lang, Patrick Werner und Kai U. Heitmann

Auf dem Connectathon geht's weiter...


FHIR Connectathon San Antonio '17
Wer danach mit der Implementierung gleich durchstarten möchte, oder sogar schon eine (halb-)fertige FHIR-Implementierung hat, kann diese auf dem unmittelbar anschließenden 18. FHIR-Connectathon vom 12.-13. Mai testen und weiterentwickeln.
Unterstützt von einer großen Community und FHIR-Experten aus aller Welt, geht die Arbeit um vieles leichter!
Auf einem speziellen Track können Gleichgesinnte gemeinsam an Medikationsplan-Apps tüfteln

Aber auch fremd-testen ist erlaubt: Über 20 verschiedene Themenschwerpunkte stehen auf dem Connectathon zur Auswahl.


Die Anmeldung zu beiden Events erfolgt über HL7.org 
(dazu ist eine kostenlose Registrierung erforderlich).
Bis zum 17. April gibt es noch Early-Bird-Discounts!

Falls Sie Fragen zu der Veranstaltung haben, kontaktieren Sie uns über unser Kontaktformular oder sprechen Sie uns auf unserem ConhIT-Stand D-103 in Halle 4.2 an. 

Donnerstag, 5. April 2018

FHIR Cheatsheet R4

Das beliebte und unverzichtbare #FHIR-Cheatsheet ist wieder da!

Wer ein Exemplar der neuesten Auflage (R4) haben möchte, kann sich selbiges auf unserem ConhIT-Stand Nr. D-103 in Halle 4.2 abholen!

Und nicht vergessen, den 14.-16. November 2018 im Kalender anzustreichen für die FHIR DevDays 2018!!!


Dienstag, 3. April 2018

Die Community wächst

Die FHIR-Community ist eines der wichtigsten Alleinstellungsmerkmale des FHIR-Standards. Keine andere Spezifikation für Interoperabilität im Gesundheitswesen hat so viele aktive Nutzer aus aller Welt, die über eine zentrale Online-Plattform kooperieren.

Auf chat.fhir.org, dem "Wohnzimmer" der FHIR-Benutzergruppe, werden pro Woche im Schnitt knapp 2000 Nachrichten ausgetauscht. Die Plattform dient der Unterstützung von Entwicklern, die Fragen zur Nutzung von FHIR haben sowie der gemeinsamen Arbeit an der Spezifikation selbst.
In verschiedenen  "Streams" werden Aspekte der Spezifikation, landesspezifische Themen oder FHIR-bezogene Frameworks und Tools diskutiert.

Der Implementer-Stream ist die zentrale Anlaufstelle für Fragen und Probleme bei der Implementierung von FHIR. Dieser zählt inzwischen über 4000 Mitglieder!




Nicht nur Quantität, sondern auch Qualität

Ausschlaggebend für die Qualität einer Online-Community ist die Zahl der aktiven Nutzer. Doch auch diese zeigt, dass sich die Community seit dem Umzug von einem Skype-Channel auf die Zulip-basierte Chat-Plattform im April 2016 konstant guter Gesundheit erfreut:

Auch der deutsch-sprachige Stream gewinnt stetig an Interesse. Hier sind aktuell 238 Mitglieder verzeichnet:





Die Community steht jedem offen

Dem Plattform zugrunde liegt eine Zulip-Applikation. Die Registrierung an der FHIR-Chat-Plattform ist kostenlos und steht jedem offen. Nach der Erstellung eines Accounts, kann man über den Setup-Menüpunkt "manage streams" auswählen, welche Diskussionsthemen man verfolgen möchte. Bei gleichzeitiger Installation der Android- oder iPhone-App für Zulip können auch Push-Notifikationen für einzelne Streams erstellt werden, um keine Nachrichten zu verpassen.

Wer sich für FHIR interessiert, bereits implementiert oder plant dies zu tun, ist in der Community herzlich willkommen!

FHIR für Fortgeschrittene: Clinical Reasoning

Der FHIR-Standard strukturiert seine Ressourcen und Module in fünf Levels:
  • Level 1 bildet die strukturelle Basis des Standards
  • Level 2 bietet Informationen und Quellen zur Implementierungsunterstützung
  • Level 3 beinhaltet administrative Ressourcen von UseCase-übergreifender Relevanz
  • Level 4 gruppiert UseCase-spezifische Ressourcen
  • Level 5 erläutert, wie man - basierend auf den darunter liegenden Levels - strukturierte und standardisierte Daten für wissensbasierte Systeme nutzen kann.

Das "Clinical Reasoning"-Modul bietet Ressourcen und Operationen zur Erfassung, Präsentation, Verteilung und Anwendung klinischen Wissens, beispielsweise für Entscheidungsunterstützungs-Systeme, klinische Protokolle oder zur Evaluation von Erfolgskriterien.
Weiterhin enthält das Modul die Sprache und Syntax für die Definition dynamischer Regeln.
Dabei deckt das Modul sowohl einfache Szenarien, wie die Bereitstellung von OrderSets bei bestimmten Diagnosen als auch komplexe klinischen Pfade für multimorbide Patienten ab.

Im Gegensatz zum FHIR-basierten Framework "CDS-Hooks", das die standardisierte Einbindung von Decision Support-Diensten in der Cloud und/oder von Drittanbietern definiert, spezifiziert das Clinical Reasoning-Modul die Inhalte und Logiken solcher Systeme.

FHIR Level 5 zeigt auf, wie standardisierte, strukturierte Daten verwendet werden können, um einen effektiven Beitrag zur Verbesserung der Behandlungsqualität zu leisten und dient als Bindeglied zwischen Klinik und Forschung.

Freitag, 30. März 2018

Montag, 19. März 2018

Funktioniert das neue Apple Health auch in Deutschland?

Quelle: Wellness Corporate Solutions
Unlängst kündigte Apple für die neue Version seines mobilen Betriebssystems iOS 11.3 eine Neuerung für Apple Health an, die für einige Verwunderung sorgte:

Basierend auf dem HL7 Standard FHIR soll der Datentransfer zwischen Krankenhaus-/ Praxisverwaltungssystemen und Patienten-Smartphones ermöglicht werden.

Wie ist das möglich? Braucht es wirklich nur einen pfiffigen neuen Kommunikationsstandard um alle Barrieren, die uns im Gesundheitswesen seit Jahrzehnten Kopfzerbrechen bereiten, mit einem einzigen iPhone-Update niederzureißen?


Ist das, was in den USA anscheinend so mühelos funktioniert auch in Deutschland möglich?

Technisch betrachtet würde das Verfahren auch bei uns funktionieren. Allerdings besteht in den USA die einzigartige Situation, dass mit Hilfe des Subventionsprogrammes ("Meaningful Use") im Rahmen des HITECH Acts (Health Information Technology for Economic and Clinical Health Act) durch den ONC (Office of the National Coordinator for Health Information Technology) konkrete und verpflichtende Vorgaben auf nationaler Ebene gemacht wurden, welche Daten KIS und PVS-Systeme über eine offene API verfügbar machen müssen.
Konkret wurden die gesetzlichen Anforderungen von den US-Herstellern durch die Implementierung der FHIR-API in Kombination mit dem SMART-Framework für die Authentifizierung und Autorisierung von Apps implementiert.
Das Mapping des Datenkatalogs auf FHIR fand im Argonaut-Project statt, einem Zusammenschluss der Hersteller zur Förderung von FHIR.
Diese Regelung trat zum 1.1.2018 in Kraft, so dass Apple sich darauf verlassen kann, in den meisten amerikanischen Kliniken diese standardisierten Schnittstellen anzutreffen, die einen genau definierte Menge an Daten zur Verfügung stellen.

Die USA werden nun die Früchte geerntet, die vor fast 10 Jahren mit einer Gesetzesinitiative von Präsident Obama gesät wurden!

Eine entsprechende Initiative deutscher Gesetzgeber gibt es hingegen nicht. Es gibt weder einen definierten Datenkatalog, noch nationale Vorgaben zu den zu verwendenden Terminologien, noch eine verbindliche Vorgabe, die Hersteller dazu zwingt oder zumindest ermutigt, solche Schnittstellen umzusetzen.

Zwar gibt es in Deutschland agierende Hersteller, die die Meaningful-Use-Schnittstellen aufgrund einer internationalen Produktpalette implementiert haben, jedoch basieren diese auf dem amerikanischen Datenkatalog, der hierzulande nur eingeschränkt nutzbar ist. (Bspw. kommen dort SNOMED-Terminologien zum Einsatz, für die in Deutschland der Kauf einer Lizenz erforderlich wäre, ebenso enthält der dort verwendete Medikamenten-Katalog "RxNorm" nicht die in Deutschland zugelassenen Medikamente; die Erfassung von Datenelementen wie "Rasse" und "Ethnizität" sind in den USA verpflichtend, in Deutschland jedoch verboten.

In so fern würde Apple's Health-App in Deutschland auf keine kompatiblen KIS- oder PVS-Systeme stoßen.

...vorher muss Deutschland seine Hausaufgaben machen.

Insgesamt liegt Deutschland bei der Entwicklung national einheitlicher Standardisierungs-Konzepte für das Gesundheitswesen und der Adaption neuer Technologien wie FHIR im internationalen Vergleich weit hinten.
Selbst Vietnam und Chile sind da deutlich weiter.

Während die Politik noch zaudert, arbeitet die Deutsche FHIR-Community an Lösungen!

Auch ohne politisches Mandat interessieren sich mehr und mehr Organisationen, Hersteller und Implementierer für die Nutzung von FHIR in Deutschland. In einer offenen Community wird seit Monaten fleißig am Deutschen FHIR Implementierungsleitfaden gearbeitet.

Mitmachen ist erwünscht!

Sonntag, 18. März 2018

Informationen mit FHIR verfügbar machen: VONK bietet die Komplett-Lösung incl. Zugriffskontrolle


Gemeinsam mit unseren Partnern von fire.ly bieten wir mit Vonk einen vollständigen FHIR-Server an, der als FHIR-Fassade in Verbindung mit einer proprietären Datenbank implementiert werden kann aber auch FHIR-Ressourcen jeglicher Form entgegennehmen, validieren und nativ in einer eigenen Datenbank speichern kann.

Danach stellt Vonk die so gespeicherten Informationen über die FHIR-API für Dritt-Applikationen zur Verfügung.

Datenzugriff auf KIS/PVS? Nur per Export-Schnittstelle!


Stellen Sie sich also vor, Sie möchten Patientendaten, die in Ihrem Krankenhaus- oder Praxis-Informationssystem (KIS) erfasst wurden, einer App zur Verfügung stellen.
Ein direkter Zugriff der App auf das KIS ist kaum möglich, da die wenigsten Systeme über Query-Schnittstellen verfügen. Die meisten beherrschen jedoch irgendeine Form einer Export-Schnittstelle (z.B. HL7 V2, xDT oder - worst case - CSV).

Über einen Kommunkationsserver (z.B. "Cloverleaf" der Fa. Health-Comm) können diese Informationen in FHIR-Ressourcen übersetzt und an VONK übermittelt werden.
Dort stehen Sie nun für sämtliche Web-Applikationen, mobile Apps, Clinical-Decision-Support-Systeme oder mobile Geräte, die den FHIR-Standard unterstützen, zur Verfügung.

Wichtig ist dabei natürlich die Zugriffskontrolle

Daher unterstützt VONK nun eine auf den Standards OAUTH2 und OpenIDConnect basierte Zugriffskontrolle.
VONK folgt dabei dem Authorisierungs-Modell des SMART-on-FHIR-Frameworks, das als Best-Practice in diesem Bereich gilt.

Die erforderlichen Schritte sind

  1. Identifikation des Benutzers (Wer ist der Benutzer?)
  2. Authentifikation (Kann er es beweisen?)
  3. Autorisation (Welche Berechtigungen hat der Benutzer?)
  4. Zugriffskontrolle (Welche Daten darf Vonk an einen Benutzer mit diesen Berechtigungen ausliefern?)

Die ersten beiden Schritte finden außerhalb von Vonk statt, ausgehend davon, dass der Benutzer bereits in einem Portal, einem KIS oder dem ActiveDirectory bekannt ist. Wichtig ist, dass das jeweilige System die Ausgabe von JWT Tokens unterstützt.

Welche Berechtigungen einer App gewährt werden können, ist in SMART in Form von "Scopes" definiert:
patient/*.read verleiht lesenden Zugriff auf alle Ressourcen im Zusammenhang mit dem aktuellen Patienten,
user/Observation.write erlaubt Schreibzugriff auf alle Observation-Ressourcen im Zugriff des aktuellen Benutzers.

Die Verbindung zum konkreten Patienten- oder Benutzer-Objekt, stellt die App beim Start über den sog. Launch-Context her.

Bei der Vergabe des Tokens muss das Autorisierungssystem (bspw. ActiveDirectory) diese Informationen zusammen mit dem Token übergeben.

Vonk führt die Zugriffskontrolle dann basierend auf Scope, Launch-Kontext und den in FHIR definierten Compartments aus.

Vonk kann jedoch noch mehr!

Über die in SMART definierten Launch Contexts hinaus, die stets nur den Zugriff auf einen bestimmten Patienten oder Fall zulassen, kann in Vonk der Kontext auch über ein beliebiges Patienten-Attribut hergestellt werden, z.B. der Versicherung oder dem Zuweiser, wie es für die Implementierung von Portal-Systemen erforderlich sein kann.

Ausprobieren kann man Vonk online oder offline, sogar mit eigenem Identity-Server

Mehr Informationen:
http://www.gefyra.de/p/vonk.html
https://blog.fire.ly/2018/02/26/access-control-in-vonk/
https://fire.ly/vonk


FHIR Release 4 (normativ) geht in die Abstimmung

Aktuell durchläuft FHIR das erste HL7-Abstimmungsverfahren (Ballot) in seiner Geschichte, bei dem Inhalte als "normativ" abgestimmt werden. Noch besteht die Möglichkeit, auf diese Inhalte einzuwirken.

Ballot Status

Für das Ballot haben sämtliche Inhalte der Spezifikation einen "Ballot Status" erhalten:
  • Normative: Inhalte, die als normativ in die Abstimmung gehen. Werden Sie angenommen, können keine inkompatiblen Änderungen mehr vorgenommen werden.
  • Trial Use: Inhalte, die aktuell das FHIR maturity Model durchlaufen. Sobald sie ausreichend getestet sind, werden Sie in einer späteren Version als normativ ballotiert.
  • Informative: Inhalte, die generelle Informationen enthalten und keinen Bezug zur Konformität eines Systems zum Standard haben.
  • Draft: Inhalte, die erst kürzlich hinzugefügt wurden und nur zur allgemeinen Kenntnisnahme publiziert wurden, aber nicht formal zur Abstimmung stehen.
  • External: Inhalte, die von anderen Quellen (HL7 V2/3, DICOM...) stammen und nicht zur Abstimmung stehen
Einige normative Ressourcen können einzelne Elemente enthalten, die als "Trial Use" gekennzeichnet wurden, da diese im Gegensatz zum Rest der Ressource noch nicht ausreichend getestet wurden. Dazu würde Patient.animal zählen, wenn es nicht kurz vor Redaktionsschluss komplett aus der Patient-Ressource in eine veterinärmedizinische Extension verbannt worden wäre.
Bundle.signature ist ein weiteres Beispiel.

Ballot Ablauf

Das Ballot-Verfahren verläuft in drei Zyklen:
  1. Draft Ballot  (Dec 2017 - Jan 2018)
    Dient hauptsächlich der Qualitätskontrolle innerhalb der HL7-Arbeitsgruppen und der FHIR-Community 
  2. Full FHIR Ballot (Apr 2018 - May 2018)
    Vollständiger Ballot der Normative- und Trial-Use-Pakete für R4 
  3. Follow up Ballot (Aug 2018 - Sep 2018)
    Re-Ballot der Substantiellen Änderungen des normativen Paketes, die aus dem vorherigen Ballot hervorgehen.
    Re-Ballot der Ergänzungen, die dem Trial-Use-Paket hinzugefügt wurden.
Alle normativen Inhalte, die nach dem dritten Ballot nicht die erforderliche Zustimmung erhalten, werden automatisch auf "Trial Use" heruntergestuft und so in R4 veröffentlicht.

Ballot Inhalt

Folgende normativen Pakete gehen ins Ballot:
  • Infrastructure
    Datentypen, Repäsentations-Formate, die RESTFul API und allgemeine Regeln zur Verwendung des Standards 
  • Terminology and Conformance Terminologie- und Conformance-Infrastruktur und alle damit verbundenen Ressourcen 
  • Patient
    Die Patienten-Ressource und damit zusammenhängende Inhalte 
  • Observation
    Die Observation-Ressource und damit zusammenhängende Inhalte

Beteiligung am Ballot

Wer sich an der Abstimmung zu R4 beteiligen möchte, kann dies über zwei Wege tun:

über HL7 Deutschland

HL7 Deutschland e.V. verfügt als Affiliate Organisation (gemessen an der Zahl der Mitglieder) über 25 Stimmen. In der Regel werden die Kommentare der Mitglieder in Deutschland zentral gesammelt und alle Voter verweisen dann bei ihrere Stimmabgabe auf diese Kommentare.
Weitere Informationen zum Abstimmungsverfahren gibt es hier.

Speziell für das FHIR-Ballot-Verfahren werden wir die Kommentare im FHIR-Chat diskutieren und einsammeln. Wer sich also beteiligen möchte, kann dies jederzeit unter http://chat.fhir.org im Deutschen Stream tun.

über Change Requests

Wie auch außerhalb des Ballots, können Change Requests für FHIR jederzeit über das Issue-Tracking-System "GForge" eingereicht werden. Die dort eingereichten Kommentare haben zwar während des Ballots eine niedrigere Priorität als die offiziellen "Votes", werden aber dennoch von den jeweils zuständigen Arbeitsguppen abgearbeitet. Auch hier empfiehlt es sich jedoch, das Thema zuvor im Chat zu diskutieren.


Letzte Chance!

FHIR wird Ende des Jahres normativ! Das Ballot-Verfahren im April/Mai bietet die letzte Gelegenheit, Änderungswünsche an die Community heranzutragen!
Wer sich nicht beteiligt, ist automatisch verpflichtet, die betreffenden Ressourcen für immer kommentarlos hinzunehmen ;-)



Donnerstag, 8. März 2018

#MakingCENS in Santiago de Chile

Auf Einladung des Centro Nacional en Sistemas de Información en Salud (CENS) durften wir am 8.3.2018 bei den TechTalks in Anwesenheit des neuen Gesundheitsministers Emilio Santelices über unsere Erfahrungen bei der Integration von FHIR mit anderen Standards berichten. FHIR spielt bei den Plänen für den Aufbau einer Nationalen Health IT Infrastruktur in Chile eine zentrale Rolle. Dem CENS kommt dabei die Aufgabe zu, zwischen den verschiedenen Akteuren im Chilenischen Gesundheitswesen zu koordinieren und zentrale Vorgaben im Bereich der Standardisierung zu erarbeiten.
Im ersten Schritt wird an der Implementierung eines Healthcare-Provider-Directories gearbeitet.

Wir freuen uns besonders über die vielen positiven Rückmeldungen und die große Begeisterung für FHIR in Chile!
...und darauf, die Initiative beim geplanten Connectathon im Herbst weiter unterstützen zu dürfen!











































Mittwoch, 7. März 2018

KBV goes FHIR

Nur wenige Tage nach der Bekanntgabe des QMS, folgt der nächste Paukenschlag:
Dennoch: Die Einigung auf eine technologische Basis ist nur der erste Schritt.
Nur wir es nun schaffen, alle zusammenzuarbeiten und gemeinsam kompatible, abgestimmte Profile für Deutschland zu erstellen, kann Großartiges entstehen.



Google publiziert FHIR-Tools


Vor wenigen Tagen gab Google die Veröffentlichung der FHIR Protocol Buffer Implementierung bekannt.


Protocol Buffers (protobuf) ist ein Datenformat zur Serialisierung strukturierter Daten. Für eine Vielzahl an Programmiersprachen wird eine offizielle Implementierung von Google als freie Software bereitgestellt, unter anderem C#, C++, Objective-C, Java, Python und Ruby.

Mit Protobuf erhält FHIR eine alternative Möglichkeit, Ressourcen zu serialisieren, die deutlich performanter ist als XML.

Der folgende XML-Code benötigt mindestens 69 Bytes und ca. 5.000-10.000 Nanosekunden zum parsen:
  <person>
    <name>John Doe</name>
    <email>jdoe@example.com</email>
  </person>

Im Protobuf-Binär-Format benötigt die gleiche Information nur noch 28 Bytes und ca. 100-200 Nanosekunden zum parsen.

Dies bietet der FHIR-Community spannende Möglichkeiten, FHIR in high-volume und bandbreiten-begrenzten Szenarien zu nutzen.

Google verspricht in der gleichen Ankündigung die Veröffentlichung weiterer Tools, um die Entwicklung von FHIR-basierten Applikationen für die Forschung und das Management von Gesundheitsdaten zu unterstützen.

Wir warten gespannt...

Montag, 19. Februar 2018

QMS goes FHIR

Aktuelle Pressemitteilung des QMS vom 19.2.2018:

Auch der QMS e.V. widmet sich dem FHIR-Standard zu

Auch der Qualitätsring Medizinische Software e. V. (QMS) wendet sich nun FHIR zu. Dies kündigte er mit einer Pressemitteilung als "Strategische Entscheidung des QMS e.V. zur Abbildung nationaler IT-Schnittstellen des ambulanten Gesundheitssektors auf den international akzeptierten Standard FHIR" am 19. Februar an.
Quelle: https://www.ztg-nrw.de/2018/02/qms-goes-fhir/



Dienstag, 13. Februar 2018

FHIR Recruitment: Qualifizierte Mitarbeiter finden

Medium badgeWeltweit sind FHIR-Experten derzeit enorm gefragt. Seit Google, Apple und Microsoft den Arbeitsmarkt mit massiven Neueinstellungen leer fegen, hat sich die Lage nochmals verschärft. Auch hierzulande sieht man die Anforderung "Kenntnisse in FHIR" immer häufiger in Stellenausschreibungen für Medizin-Informatiker.
Da der Standard noch neu ist, gibt es bislang nur wenige Zertifizierungs- und Ausbildungsprogramme

Worauf Arbeitgeber und Bewerber achten sollten:

  • HL7 International bietet ein "FHIR Proficiency Exam" an, das auf einem anspruchsvollen Niveau breitgefächerte Grundkenntnisse im FHIR-Standard abfragt.
    Wer den Test erfolgreich abgelegt hat, darf sich mit der "FHIR Proficient Digital Badge" schmücken. 
  • Wer sich mit FHIR beschäftigt, findet sich früher oder später im FHIR-Chat wieder. Dort diskutieren Implementierer, Spezifizierer und Studenten auf nationaler sowie internationaler Ebene über Fragen zu FHIR. Das Aktivitätsniveau eines Benutzers in diesem Chat lässt Rückschlüsse auf dessen Engagement zu.
  • Gefyra und HL7 Deutschland bieten FHIR-Schulungen an. Schulungsteilnehmer können anhand von Teilnahmebestätigungen den Besuch solcher Veranstaltungen nachweisen.
  • Eine Teilnahme am Student Track der FHIR Developer Days weist Studenten aus, die sich auch außerhalb der Lehrveranstaltungen an FHIR-Projekten beteiligt haben.

Gewinner des "Student Awards"
auf den FHIR DevDays 2016

Google on FHIR: Deep Learning für elektronische Patientenakten

In dem uns als Pre-Print-Artikel vorliegenden Paper "Scalable and accurate deep learning for electronic health records" wird beschrieben, wie FHIR von Google für Deep Learning Algorithmen eingesetzt wird:


Quelle: https://arxiv.org/pdf/1801.07860.pdf

Samstag, 27. Januar 2018

Apple on FHIR

Nach Google und Microsoft bekennt sich mit Apple nun der dritte Technologie-Riese zu FHIR. Das Update der Health App für iOS 11.3 erlaubt es Patienten, relevante medizinische Daten, wie zum Beispiel Allergien, Impfungen und Medikationen auf ihrem Smartphone stets zur Hand zu haben. Dazu bedient sich Apple des HL7-FHIR-Standards um die Daten aus Krankenhäusern, Arztpraxen und Apotheken abzurufen und aktuell zu halten.
Quelle: https://www.apple.com/

Dabei setzt Apple auf den FHIR-Schnittstellen auf, die aus dem US-amerikanischen "Meaningful-Use"-Programm hervorgehen. Um sich ab 2018 weiterhin für das staatliche Subventionsprogramm zu qualifizieren, müssen Hersteller von KIS und PVS-Systemen offene, standardisierte Schnittstellen für den Abruf medizinischer Daten implementieren. Damit kann Apple im amerikanischen Raum auf eine klar spezifizierte, konsistente APIs setzen, die von den großen Herstellern wie Epic, Cerner oder McKesson bereits fertig implementiert sind. 
In den nächsten Monaten wird die App in einer Betaphase mit 12 amerikanischen Krankenhäusern getestet.

Quellen:
https://www.apple.com/newsroom/2018/01/apple-announces-effortless-solution-bringing-health-records-to-iPhone/
http://www.spiegel.de/wirtschaft/unternehmen/apple-startet-health-records-neuer-dienst-fuer-medizin-daten-a-1189706.html
https://www.heise.de/mac-and-i/meldung/Apples-elektronische-Gesundheitsakte-setzt-auf-Standard-FHIR-3952315.html

Freitag, 19. Januar 2018

Lesenswert: Microsoft on FHIR

Der Artikel "HL7 on Azure: what's next" ist an sich schon lesenswert genug, aber noch mehr Spaß macht es mit unserem Interoperabilitäts-Buzzword-Bingo!

IoT
Blockchain
Machine Learning
XML
Big Data
SMART-on-FHIR
Data Analysis
Plug-able
RESTful
eBook
Medical Devices
Bots
Precision Medicine
Office 365 on FHIR
OAUTH2
Artificial Intelligence

Donnerstag, 18. Januar 2018

Meditation über Interoperabilität

Der heute am weitesten verbreitete
Interoperabilitäts-Standard 
im Gesundheitswesen
(HL7 Version 2)
ist älter als das Internet.


Mittwoch, 17. Januar 2018

Lesenswert: Warum FHIR für KIS-Hersteller relevant ist


Der Artikel "There's a FHIR at the end of the tunnel" beleuchtet Kosten und Nutzen von FHIR für Hersteller von elektronischen Patientenakten bzw. KIS/PVS*-Systemen.

Die Highlights:
"FHIR verursacht einen Paradigmenwandel in der Healthcare IT. Elektronische Patientenakten werden künftig als Plattform gesehen werden, nicht mehr als Komplettlösung. Das gibt den Herstellern den Freiraum, sich auf Kernfunktionen zu fokussieren anstatt zu versuchen, die Bedürfnisse jedes einzelnen Benutzers zu erfüllen.
In diesem neuen Ökosystem haben Anwender die Möglichkeit, eine App auszuwählen, die genau die Funktion erfüllt, die der Hersteller nicht priorisieren konnte, da zu wenige Kunden danach verlangten. Die Hersteller werden nun sagen können: Dafür gibt es eine App!"
"FHIR hat die technologische Entwicklung im Gesundheitswesen demokratisiert und damit die Kosten für die Entwicklung innovativer Lösungen drastisch reduziert."
Quelle: https://www.mymipsscore.com




Dienstag, 16. Januar 2018

Lesenswert: Genes on FHIR

Der Artikel "These Genes are on FHIR" zeigt die ersten Ergebnisse des "Sync for Genes" Programmes, darunter FHIR-Profile und -Ressourcen für den standardisierten Austausch genetischer Informationen im Rahmen der "Precision Medicine Initiative" sowie fünf verschiedene Pilot-Programme, die diese Ressourcen implementieren.
"Der rasante Fortschritt im Bereich der Genetik und das Fehlen standardisierter Ansätze für Datensammlung und -Austausch haben inkompatible Infrastrukturen und Nomenklaturen hervorgebracht. Ein standardisierter Ansatz war dringend nötig um sicherzustellen, dass genetische Information zwischen Informationssystemen im Gesundheitswesen ausgetauscht und mit anderen klinischen Daten integriert werden kann.
Die Arbeitsgruppe "Clinical Genomics" macht sich die schnellen Fortschritte bei der Entwicklung des FHIR-Standards zu nutze und definiert geeignete Profile und Ressourcen damit genetische Informationen konsistent und interoperabel zwischen Forschern, leistungserbringern und Patienten ausgetauscht werden können."

FAQ: FHIR jetzt schon verwenden oder abwarten?

Die Tatsache, dass FHIR noch kein normativer Standard ist, lässt einige Organisationen und Firmen noch zögern, das jüngste Kind der HL7-Produktfamilie für eine Implementierung in Betracht zu ziehen.

Auch wenn FHIR bis Ende des Jahres normativ wird, werden im "Release 4" noch nicht alle Ressourcen das entsprechende Maturity Level erreichen (siehe hierzu den Artikel "3..2..1..normativ").

Eine Frage, die uns häufig gestellt wird, lautet:

"Können wir FHIR jetzt schon nutzen oder sollen wir weiter abwarten, bis alle für unseren UseCase benötigten Ressourcen normativ geworden sind?"

Auch wenn die letztendliche Entscheidung vom Einzelfall abhängig ist, gibt es folgende Gründe, die für eine Nutzung nicht-normativer FHIR-Artefakte sprechen:

  1. eines der wichtigsten Kriterien, die eine Ressource erfüllen muss, um normativ zu werden, ist die Implementierung und Kommentierung durch möglichst viele verschiedene Organisationen aus verschiedenen Ländern. Mit der Implementierung einer nicht-normativen Ressource kann man also aktiv dazu beitragen, dass diese möglichst bald diese Kriterien erfüllt.
  2. Bereits ab "Maturity Level 4" sind substantielle Änderungen nur nach Konsultation der Community möglich. Sie können als Implementierer also bei der Entscheidung, ob eine Änderung durchgeführt wird, mitreden.
  3. So lange eine Ressource noch nicht normativ ist, haben Sie die Möglichkeit, aktiv darauf hinzuwirken, dass diese Ihren UseCase besser unterstützt, indem Sie "Change Requests" einreichen.
  4. Mit jedem Release werden Routinen mit veröffentlicht, um Instanzen, deren Spezifikation sich verändert hat, von einer älteren auf eine neuere Version zu konvertieren.
Wir bieten Unterstützung bei der Evaluation von FHIR für Projekte an, begleiten bei der Implementierung und unterstützen bei der Einreichung von Change Requests.

Weitere Informationen: Unsere Leistungen

3..2..1..normativ

2018 wird ein Meilenstein für FHIR


Die Version "R4" wird in diesem Jahr ballotiert und soll zum Jahresende als erste normative Edition von FHIR publiziert werden.

Aktuell gilt die im April 2017 veröffentlichte Version "STU 3", die FHIR noch deutlich als "Standard for Trial Use" kennzeichnet. Bislang war es noch möglich, dass die Arbeitsgruppen substantielle Änderungen an den Ressourcen oder am Framework vornahmen, was einige Organisationen zögern ließ, FHIR bereits zu verwenden.

In der normativen Edition werden solche Änderungen nicht mehr möglich sein (oder nur in extremen Ausnahmefällen). Der Standard gilt dann als stabil.

Allerdings wird nicht der gesamte Standard als "normativ" ballotiert. Einige Teile, wie zum Beispiel neue Ressourcen im Bereich "Financial Management", das Modul "Public Health & Research" oder "Genomics" sind noch vergleichsweise jung und wenig getestet. Die Anforderungen, die FHIR an seine Module stellt, um normativ zu werden, sind jedoch sehr streng.

Jedes Artefakt des Standards muss die Stufen des "Maturity Models" erklimmen:
  1. das Artefakt wurde im "current build" publiziert (gleichbedeutend mit "Entwurf")
  2. PLUS das Artefakt muss alle automatisierten Qualitäts- Vollständigkeits- und Plausibilitätskriterien erfüllen und von der verantwortlichen Arbeitsgruppe "bereit zur Implementierung" eingestuft werden
  3. PLUS das Artefakt wurde von mindestens drei unabhängigen Systemen implementiert und unter realitätsnahen Bedingungen getestet (z.B. bei einem Connectathon). 
  4. PLUS das Artefakt erfüllt die Trial Use Quality Guidelines und wurde mindestens einmal ballotiert; mindestens 10 verschiedene Entwickler von mindestens 3 verschiedenen Organisationen müssen das Artefakt kommentiert haben
  5. PLUS das Artefakt wurde in verschiedenen Use Cases getestet, in einem FHIR-Release publiziert und in verschiedenen Prototypen implementiert. Die Arbeitsgruppe stimmt zu, dass weitere substantielle Änderungen nur nach Konsultation der Community möglich sind.
  6.  PLUS das Artefakt wurde in mindestens 5 verschiedenen Systemen in mehr als einem Land implementiert und produktiv genutzt.
  7. "Normative": das Artefakt ist stabil
Sowohl das aktuelle Maturity Level als auch das Kennzeichen für den normativen Ballot sind im current build klar zu erkennen:


Die Grundlagen-Kapitel sind überwiegend zum normativen Ballot gekennzeichnet:


Die Roadmap jenseits von R4 sieht vor, dass in einem halbjährlichen Zyklus weitere normative Ressourcen nachgeliefert werden, sobald diese die Kriterien des Maturity Models erfüllen.

Weitere Informationen:


Mittwoch, 10. Januar 2018

Continua on FHIR: Kommunikationslücke zwischen ConsumerHealthCare und Gesundheitsdienstleistern schließen!

Die Zeiten in denen Blutdruck- und Glukose-Messwerte von Patienten in Notizheftchen eingetragen wurden, um Fortschritt und Verlauf der eigenen Erkrankung im Blick zu behalten, sind vorbei.

Längst haben moderne, bezahlbare bluetooth-fähige Geräte verbunden mit Smartphone-Apps und Cloud-Diensten den Markt erobert.

Einerseits bietet dieser Trend große Chancen, die Betreuung chronisch Kranker zu verbessern, die Anzahl erforderlicher Arztbesuche zu verringern, Senioren länger ein unabhängiges Leben im eigenen zu Heim zu ermöglichen, Forschern eine kostengünstige Möglichkeit zum Follow-Up von Studienteilnehmern zu bieten oder mit pfiffigen Apps und integration Sozialer Netzwerke, Compliance und Motivation von Patienten zu erhöhen.

Doch wo viel Licht ist, ist auch viel Schatten. Bedenken bezüglich der Qualität und Vergleichbarkeit der gemessenen Daten werden ebenso angeführt, wie Mängel bei Sicherheit und Datenschutz.

Die Personal Connected Health Alliance (PCHA) ist ein Zusammenschluss von Herstellern mit dem Ziel, die Kommunikation mit medizinischen Geräten und Sensoren im Consumer-Bereich einfach, kompatibel und sicher zu gestalten und mit Hilfe von Standardisierung und Zertifizierung die Qualität der Geräte und der gemessenen Daten vergleichbar zu machen.

Ähnlich wie IHE definiert die PCHA dazu keine eigenen Standards, sondern setzt auf etablierte Definitionen z.B. IEEE, Bluetooth oder HL7 und füllt - wo erforderlich - die Lücken. Die resultierenden Spezifikationen werden als Continua Design Guidelines veröffentlicht.

Die Guidelines unterteilen die Kommunikation in ein mehrstufiges Modell:

Quelle: wiki.hl7.org
Am Beispiel eines konkreten Szenarios könnte die Kommunikation folgendermaßen ablaufen:

  1. Ein Glukose-Messgerät übermittelt die gemessenen Daten per Bluetooth an ein Smartphone
  2. der Patient entscheidet, die Messdaten mit seinem Hausarzt zu teilen und gibt Sie an einen entsprechenden (Cloud-)Service frei. 
  3. Nach einer Validierung der Daten kann der Hausarzt die Daten in die Elektronische Patientenakte übernehmen

Während die Kommunikation zwischen Gerät und "Personal Health Gateway" basierend auf IEEE 11073 und Transportstandards wie Bluetooth oder USB gesetzt und etabliert ist, bereitete die bisherige Spezifikation zur Kommunikation zwischen PHG und Cloud-Dienst sowie der Integration in die elektronische Patientenakte basierend auf dem IHE-Profil "PCD-01" bei der Implementierung immer wieder Kopfschmerzen.

PCD-01 setzt auf Nachrichten im HL7 V2 Format, das in der Krankenhaus-IT-Welt zwar seit Jahrzehnten etabliert ist, Web-Entwicklern jedoch geradezu anachronistisch erscheinen muss.

Weiterhin erforderte die Integration in die elektronische Patientenakte wiederum eine "Umschlüssselung" der V2 Nachricht in CDA und die Implementierung eines weiteren IHE-Profils: XDS.b

Insgesamt kommt man damit auf ein beachtliches Sammelsurium zu implementierender Standards: HL7 V2, HL7 V3 (CDA), SOAP, SAML, ebXML, ATNA (DICOM) ...
Entsprechend aufwendig und teuer gestaltet sich die Entwicklung darauf basierender Applikationen.

Der Ruf der Implementierer nach einheitlichen, modernen, webbasierten Protokollen wurde von der PCHA gehört: Am 14.12.2017 wurde die erste FHIR-basierte Continua Guideline veröffentlicht.
Damit schafft PCHA die Möglichkeit, Continua-zertifizierte Applikationen schneller und kostengünstiger zu implementieren, da auf etablierte Webstandards wie REST und OAUTH2 zurückgegriffen werden kann und der umfangreiche Stack an FHIR-Tools und Bibliotheken nutzbar wird.
Die Kommunikation zwischen Personal Health Gateway, CloudService und Elektronischer Gesundheitsakte kann damit basierend auf einem einheitlichen Standard-Framework implementiert werden. Für die Integration der Sensoren und Geräte bietet die Guideline Mappings zwischen IEEE 11073 und den FHIR-Ressourcen "DeviceComponent und Observation" an.

Am 24. Januar bietet die PCHA ein kostenloses Webinar zum Thema "Continua on FHIR" an!

Gute Nachrichten für Deutschland:
2017 trat die PCHA dem Spitzenverband IT-Standards im Gesundheitswesen (SITiG) bei, um gemeinsam mit IHE-DE und HL7-DE die Standardisierung in Deutschland zu fördern.


Links:
http://www.pchalliance.org/continua-design-guidelines
https://www.slideshare.net/DevDays/furore-devdays-2017-continua-implementing-fhir