Dienstag, 21. November 2017

Bericht von den FHIR Developer Days 2017

Vom 15.-17. November 2017 haben zum vierten mal die FHIR Developer Days in Amsterdam stattgefunden.

Kein Mitglied der Community lässt sich diese Gelegenheit gerne entgehen:
Den vertraut gewordenen Namen, mit denen man über Monate hinweg im FHIR-Chat kommuniziert hat Gesichter zuzuordnen; denjenigen,  die bei Problemen geholfen und beraten haben, persönlich zu danken; den Mitgliedern des FHIR-Core-Teams, die zu jeder Tages- und Nachtzeit bereit sind, Fragen zu beantworten, Unklarheiten zu beseitigen und die Welt von FHIR zu erklären, die Hand zu geben.

James Agnew  formuliert es trefflich: es ist die alljährliche  "health standard nerd pilgrimage" nach Amsterdam!

Die Teilnehmer spiegeln in Anzahl und Diversität die Entwicklung der FHIR-Community wieder: Aus 24 Ländern reisten in diesem Jahr 330 "standard nerds" von 140 verschiedenen Organisationen an, darunter viele große Namen wie Agfa, Cerner, IBM, Google, Microsoft, Epic, Philips und Samsung. Damit konnten die DevDays wie bereits im Vorjahr ihre Teilnehmerzahl um 50% steigern. 50% ist dabei auch der Anteil derer, die in diesem Jahr zum ersten Mal teilgenommen haben.

Deutschland ist nicht länger "nur Zuschauer"

Aus Deutschland nahmen über 40 Personen teil: Agfa, Gefyra, Gematik, Hasso Plattner Institut, Health-Comm, IBM, IKMB, InterSystems, LHIC, Medavis, Molit Institut, OSM, Siemens, Synedra sowie die Unis Aachen, Heilbronn, Lübeck, Köln, Bonn waren vertreten. Doch nicht nur zahlenmäßig war die deutsche Beteiligung ein großer Erfolg! So konnten die Studenten der TH Köln den begehrten "Student Award" mit nach Hause nehmen und auch der inoffizielle "Best Dressed Award",  ging an die deutsche Delegation.
Vollgepackt mit über 70 Tutorials, Vorträgen und Hack-a-thon-Sessions boten die DevDays erfahrenen Entwicklern eine Gelegenheit zum Austausch und ermöglichten Neulingen einen schnellen Einstieg in den FHIR-Standard.

Eine beliebte Tradition der DevDays sind die "Birds-of-a-feather"-Sessions, bei der sich Gleichgesinnte spontan zu einer Diskussionsrunde zusammenfinden. Diskutiert wurden in solchen ad-hoc-Sessions in diesem Jahr unter anderem die Frage nach poly-hierarchischen FHIR-Profilen, "SQL on FHIR", die Versionierung von Implementierungs-Leitfäden und die Weiterentwicklug von "R on FHIR".

Aufsehenerregende Keynotes 

Zielgruppengerechtes Give-Away
Rolf Hut von der Technischen Universität Delft überzeugte mit seiner Argumentation, dass APIs es uns erlauben, Technologien zu nutzen, ohne bis ins kleinste Details verstehen zu müssen, wie diese funktionieren; dass sie uns damit eine breite Palette von Werkzeugen und Bausteinen nutzbar machen, ohne dass wir uns den endlosen Tiefen ("Turtles all the way down") verweisender Spezifikationen verlieren. Dies belegte er anschaulich mit einem Kästchen aus zusammengeworfenen Elektronikbausteinen, das Temperaturen messen, über eine LED visualisieren und als FHIR-konforme Ressource an einen Server übermitteln konnte. Zur großen Freude aller gab es insgesamt 200 Kopien dieses Kästchens, die den Teilnehmern zum ausprobieren und weiterentwickeln überlassen wurden.

Eyal Oren von Google, USA überraschte mit der Enthüllung, dass Google de-identifizierte medizinische Massendaten in FHIR-Resourcen überführt, um sie einheitlich strukturiert als Datenbasis für das Training neuronaler Netze verwenden zu können. Die Funktionsweise des maschinellen Lernens demonstrierte Oren eindrucksvoll an einem Live-System. Auch Google hatte Geschenke für die FHIR-Community im Gepäck, nämlich die Zusage, dass die von Google entwickelten FHIR-Tools im Laufe der nächsten Monate als Open Source publiziert und damit der Community zur Verfügung gestellt werden.

Grahame Grieve, einer der "Erfinder" und Produktmanager von FHIR, verschob den Fokus fort von der Technologie: Die Community sei es, so Grieve, die FHIR zu einem Erfolg mache. Er appellierte an die Nutzer von FHIR, den Standard nicht nur passiv zu konsumieren, sondern sich zu engagieren, mitzureden, Fragen zu stellen und einen eigenen Beitrag zu leisten, um FHIR besser zu machen.

Save the date

Der nächste Termin für die FHIR DevDays steht bereits fest: In 2018 wird es vom 19.-21. Juni erstmals eine Veranstaltung auf amerikanischem Boden in Boston geben. Im November 2018 werden dann wieder die "Original"-DevDays in Amsterdam stattfinden.

Mittwoch, 15. November 2017

SAP bringt FHIR das (Ab)Rechnen bei

Nach einer ausgiebigen Phase der Analyse und Evaluation steht die Strategie von SAP fest:

Weg von proprietären Schnittstellen, hin zu FHIR!


Während FHIR - technologisch betrachtet - eine Ideallösung für die Kommunikation zwischen Krankenhaus-Informationssystemen und der cloud-basieren SAP S/4HANA-Plattform darstellt, so liegen die Herausforderungen vor allem darin, dass die Belange des Financial Managements im Gesundheitswesen von Internationalen Standards bisher nur minimale Unterstützung fanden.
Der Grund dafür bestand in den gravierend abweichenden Anforderungen zwischen Ländern, Versicherungsformen und Sektoren, die eine international standardisierte Lösung unerreichbar erscheinen ließen.

Dank des ausgeklügelten FHIR Conformance-Moduls ergibt sich jedoch erstmals die Möglichkeit, mit Hilfe von Constraints und Extensions diese Disparitäten standardisiert, austauschbar und maschinenlesbar abzubilden.
Für einen weltweit agierenden Konzern wie SAP die perfekte Grundlage, um systembedingte Mindestanforderungen, nationale Rahmenbedingungen sowie Spezifika der Kunden unter einen Hut zu bringen.

Die nationalen Anforderungen werden dabei von den jeweiligen HL7-Affiliates erarbeitet. Die Zusammenarbeit mit den technischen Komitees und die Verwendung nationaler FHIR-Basisprofile als Ausgangspunkt, stellt die Interoperabilität der SAP-Schnittstellen auf Landesebene sicher.

Die Zusammenarbeit mit HL7 lohnt sich

Auch wenn Konzerne traditionell nicht dazu neigen, ihre Expertise unentgeltlich zu teilen, so hat SAP dennoch die Konsequenzen aus leidvollen Erfahrungen mit proprietären Schnittstellenlösungen gezogen und sich der FHIR-Community geöffnet.
Gemeinsam mit Gefyra und dem Technischen Komitee für FHIR von HL7 Deutschland entwickelt SAP seit über einem Jahr Vorschläge, wie die Funktionalitäten von FHIR im Bereich des Financial Managements verbessert und erweitert werden können. Diese werden dann als "Change Request" eingereicht und von den jeweils zuständigen Arbeitsgruppen bei HL7 International diskutiert und beschieden.

Der Erfolg gibt dieser Strategie recht

So wurde zum Beispiel die ChargeItem-Ressource für den Austausch von Leistungsziffern einem solchen Vorschlag folgend  in die Version STU3 des Standards aufgenommen:



Zahlreiche Vorschläge zur Optimierung von Account und Coverage wurden ebenfalls gutgeheißen und in den Standard übernommen.

Die nächste Aufgabe wird die Erarbeitung einer Invoice-Ressource sein, um die Erstellung von Rechnungen basierend auf den in einem Account gesammelten ChargeItems für die Abrechnung mit Patienten, Organisationen oder für die interne Leistungsverrechnung zu ermöglichen.

Mit dieser Strategie bekennt sich SAP klar zum neuen HL7 Standard FHIR. S/4HANA ist dabei nur eines von vielen Produkten aus dem SAP Portfolio, das künftig "FHIR sprechen" wird.

Dienstag, 14. November 2017

FHIR-Anwendungen von A-Z

FHIR, der neue webbasierte Standard aus der HL7 Familie, findet dieser Tage viel Beachtung, wird jedoch häufig in einem Atemzug mit "mobilen Apps", "Wearables" und anderen "Gadgets" genannt, die zur Einschätzung verleiten, dass es sich bei FHIR-Implementierungen eher um Spielzeug als um unmittelbar nutzbringende Entwicklungen handelt.

Doch die potentiellen Einsatzbereiche für FHIR gehen weit über das Mobile Computing hinaus.

FHIR kann mehr als "mobile Apps"

FHIR basiert auf etablierten und weit verbreiteten Web-Technologien. Diese solide Basis zusammen mit einem Framework aus modularen Objekten, die verlinkt und dadurch immer wieder neu kombiniert und zu komplexen Strukturen zusammengefügt werden können, machen FHIR zu einer hochgradig flexiblen und skalierbaren Lösung, nicht nur zum Datenaustausch, sondern auch als standardisiertes Format für die Speicherung, Modellierung und Validierung von Daten.

FHIR ist anders als bisherige Standards

Anstatt Informationen zu einem Dokument oder einer Nachricht aggregiert von Sender zu Empfänger zu schicken, erhalten die einzelnen Informationseinheiten eine URL, auf die FHIR-Systeme wie ein Browser auf eine Webseite zugreifen können, nach denen sie "googeln" oder die sie herunterladen können. Konsequenter Weise sind diese Informationen über eben jene URLs miteinander verlinkt.

Die Informationseinheiten werden als "Ressourcen" bezeichnet. Beispiele für in FHIR definierte Ressourcen sind: ein Patient, ein Medikament, eine Allergie oder eine Diagnose.

Verlinkte, also zusammengehörende Ressourcen können - wenn erforderlich - zu einem Dokument oder einer Nachricht gebündelt versendet oder archiviert werden, so dass auch die von bisherigen Standards abgebildeten Funktionen eine Äquivalenz in FHIR finden.

Die größte Revolution ist jedoch die Abkehr vom "Push"-Modell, in dem jeder Datenempfänger darauf warten muss, dass beim Sender ein bestimmtes Ereignis eintritt, das den Dokumente- oder Nachrichtenversand auslöst, hin zu einem Query-getriebenen Ansatz, in dem Daten bereitgestellt und zu einem beliebigen Zeitpunkt in beliebigen Umfang abgefragt werden können.

"Zeige mir Deine API und ich integrier' dich"

Application programming interfaces (APIs) sind in anderen Industrien längst zum Schweizer Messer der Interoperabilität geworden. Entwickler stellen damit im Handumdrehen eine Verbindung zwischen ihrer Applikation und sozialen Netzwerken her oder integrieren die Standortdienste von Google Maps. Dass wir heute Portale nutzen können, die Hotel-, Flug- oder Produktpreise aus unterschiedlichen Systemen vergleichen und das günstigste Angebot für uns finden können, verdanken wir den APIs, die den standardisierten Zugriff auf unterschiedliche Datenquellen ermöglichen.

In Verbindung mit den standardisierten Datenstrukturen und dem Query-getriebenen Ansatz von FHIR sowie einem Framework für Autorisation und Authentifikation, ermöglichen APIs Interaktionen zwischen Systemen, die mit dem reinen Versand von Dokumenten niemals denkbar wäre.
Das Technische Komitee für FHIR von HL7 Deutschland erarbeitet derzeit eine Übersicht möglicher Einsatzszenarien mit Erläuterungen und weiteren Informationsquellen, die in Kürze auf den Wiki-Seiten von HL7 Deutschland veröffentlicht wird. 

Eine (unvollständige) Vorschau:

-A-
Arzneimittelwechselwirkungen
Ärzteverzeichnis
AuditTrails
Authentifikation und Autorisation

-B-
Big Data Analytics

-C-
Chemotherapie 
Clinical Decision Support

-D-
Dokumentenaustausch

-F-
Fragebögen und Formulare

-G-
Genomics

-H-
Hilfsmittelverzeichnis

-I-
IHE-Profile

-K-
Konformitäts- und Kompatibilitätsprüfung
Klinische Studien

-L-
Logische Modelle

-M-
Medikationsplan

-N-
Nachrichtenbasierte Kommunikation

-O-
Ontologien

-P-
Patient Empowerment
Personalisierte Medizin
Phamakogenomische Studien

-Q-
Query-getriebene Kommunikation

-R-
RDF - Resource Description Framework

-S-
SMART on FHIR
Strukturierte Dokumente

-T-
Terminvereinbarung
Terminologie-Dienste

-U-
Ultrakurzformat (Medikationsplan)

-V-
Versichertenstammdatenmanagement (VSDM)
Veterinärmedizin