Mittwoch, 20. Dezember 2017
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.
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".
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.
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.This year's winner of the #fhirdevdays17 Student Track trophy is the @th_koeln team. "Navigating complex medical data with FHIR". pic.twitter.com/95N9UTNpSe— Furore FHIR (@fhir_furore) 16. November 2017
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 |
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.
Grahame Grieve on the FHIR Foundation: "We don't just throw the specification over the wall. We care about the community" #fhirdevdays17— gefyra (@GefyraGmbH) 15. November 2017
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:
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.
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.
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.
Weg von proprietären Schnittstellen, hin zu FHIR!
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.
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.
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:
-B-
Big Data Analytics
-C-
Chemotherapie
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"
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.
Eine (unvollständige) Vorschau:
-A-
Arzneimittelwechselwirkungen
Ärzteverzeichnis
AuditTrails
Authentifikation und Autorisation
Ä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
-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
Montag, 13. November 2017
IHE-Profil "MMA": Mobile Medikamenten-Administration mit FHIR
 |
| Quelle: https://www.mechatronic.de |
Es ist damit Teil einer Serie von IHE-Profilen, die auf HL7 FHIR als Mechanismus für die Interaktion zwischen Primärsystemen und mobilen Endgeräte setzen. Weitere Profile werden künftig den gesamten Medikations-Workflow abdecken.
MMA beschreibt zwei Aspekte der Medikamenten-Verabreichung:
- Die Übermittlung geplanter Medikamenten-Verabreichungen vom Primärsystem an ein Endgerät
- Die Übermittlung eines Berichts über verabreichte Medikamente von einem Endgerät an das Primärsystem.
Beide Transaktionen sind optional, jedes System kann sowohl eines als auch beide Aspekte implementieren.
Typische Anwendungsszenarien sind:
- Ein Anwendungssystem in der mobilen Pflege informiert die Pflegekraft über die Medikamente, die ein bestimmter Patient in einem bestimmten Zeitraum einnehmen muss. Die Pflegekraft dokumentiert die Abgabe der Medikamente im Anwendungssystem.
- Ein intelligenter Medikamenten-Dispenser oder eine Smart-Phone-Applikation erhält Informationen zur Medikamenten-Verabreichung von einem Praxis- oder Apothekensystem und erinnert den Patienten an die Einnahme seiner Medikamente.
- Eine Smart-Phone-Applikation zur Erfassung der Patienten-Compliance im Rahmen eines Therapie-Programmes
- Die Dokumentation der Medikamenten-Verabreichung durch eine Infusionspumpe
- Die manuell oder durch Barcode-Scan erfasste Dokumentation verabreichter Medikamente durch eine Pflegekraft im Krankenhaus-Umfeld
 |
| Quelle: wiki.ihe.net |
Das IHE-Profil ist vollständig kompatibel mit der FHIR-STU3-Spezifikation, fügt dieser jedoch zusätzliche Constraints und UseCase-spezifische Leitfäden für Entwickler hinzu.
Folgende FHIR-Ressourcen werden von MMA verwendet:
- Patient
- Medication
- MedicationRequest
- MedicationAdministration
Anwendung in Deutschland:
Für die Abbildung der Medication-Ressource speziell in Deutschland unter Verwendung der hier üblichen und verbreiteten Formen der Kodierung wird im Rahmen des MedikationsplanPlus-Projektes ein entsprechendes Profil erarbeitet. Für die Patient-Ressource gibt es in den Basisprofilen für Deutschland bereits ein lokalisierte Fassung. Die im Rahmen der Umsetzung des Medikationsplans implementierten FHIR-Ressourcen Patient und Medication können für MMA wiederverwendet werden.
Mittwoch, 8. November 2017
R on FHIR: FHIR für Statistiker
R ist eine freie Programmiersprache für statistische Berechnungen und Grafiken. Sie wurde von Statistikern für Anwender mit statistischen Aufgaben entwickelt.
Zahlreiche Pakete enthalten zusätzliche Funktionen, um Daten hinsichtlich Fragestellungen aus unterschiedlichen Fachbereichen zu analysieren. Die Sprache bietet Schnittstellen zu anderen Programmiersprachen und Möglichkeiten zur Integration in verschiedene Software. R grenzt sich von anderen Programmiersprachen durch die für Statistik entworfenen Datenstrukturen und Funktionen sowie die Möglichkeiten bei der Grafikerzeugung ab.
R gilt zunehmend als die Standardsprache für statistische Problemstellungen sowohl in der Wirtschaft als auch in der Wissenschaft.
Gerade wurde die Programmiersprache R von StackOverflow zur beliebtesten Programmiersprache gekürt, oder - genauer gesagt - zur am wenigsten gehassten.
Nun gibt es noch einen weiteren Grund R zu lieben:
Unsere Partner von Furore veröffentlichten ein Paket zur Integration von R und FHIR, das es R-Programmierern erlaubt, auf die Daten eines FHIR-Servers zuzugreifen.
FHIR-Produktmanager Grahame Grieve berichtet in seinem Blog von den ersten Erfahrungen und weiteren Pläne.
Wer es gleich selbst ausprobieren möchte, findet hier eine ausführliche Anleitung.
Auf den FHIR DeveloperDays in der kommenden Woche wird es ein Tutorial zu "R on FHIR" geben.
Dienstag, 7. November 2017
Sync4Science: Ich spende meine Daten der Wissenschaft!
Im Februar 2016 startete das US-amerikanische National Institute of Health (NIH) in Zusammenarbeit mit der Harvard Medical School ein Projekt namens Sync for Science (S4S), dessen erklärtes Ziel es ist, Patienten in die Lage zu versetzen, klinischen Forschern Zugriff auf ihre Behandlungsdaten zu gestatten - gewissermaßen als "Datenspende" an die Wissenschaft.
Auf diese Prinzip setzt auch das "All-of-Us"-Programm, das Daten zum Lebenswandel, der Umwelt und Genetik von über einer Million Amerikanern sammelt, um die Forschung im Bereich der "Precision Medicine" voranzubringen. Hierfür kommt bereits das speziell für S4S konzipierte FHIR/OAUTH-Framework zum Einsatz.
Inzwischen sind auch die Hersteller der Klinischen Informationssysteme (KIS) mit an Bord, die diese Daten liefern müssen. Große Namen wie Allscripts, Athenahealth, Cerner, DrChrono, Epic, und McKesson tauchen in der Liste der Pilot-Entwickler auf. Da in den USA die Implementierung von FHIR-APIs im Rahmen von "Meaningful Use Stage 3" ab 2018 ohnehin obligatorisch ist und sich FHIR-Interfaces aufgrund ihrer Modularität immer wieder verwenden lassen, fällt der Mehraufwand entsprechend gering aus.
Einmal implementiert, wird es das S4S-Framework Patienten gestatten, einer studien-spezifischen App Zugriff auf dessen Behandlungsdaten im KIS zu gewähren, den Zugriff einzuschränken, oder auch wieder ganz zu entziehen.
Weitere Informationen zum nachlesen:
https://www.healthit.gov
http://www.healthcareitnews.com
http://syncfor.science/
https://www.healthit.gov
http://www.healthcareitnews.com
http://syncfor.science/
...oder einfach von Obama erklären lassen:
...oder am 17.11.2017 auf die FHIR DeveloperDays nach Amsterdam kommen und an Josh Mandel's (Harvard Medical School) S4S-Tutorial teilnehmen!
FHIR Foundation akzeptiert persönliche Mitglieder
Die FHIR Foundation, eine 2016 gegründete gemeinnützige Stiftung, die das Zentrum der FHIR Entwickler-Community bildet, akzeptiert seit dem 30.10.2017 persönliche Mitgliedschaften.
Ziel der Stiftung ist es, die weltweite Verbreitung und Implementierung des FHIR-Standards zu fördern. Sie bietet Informationen, Schulungsmaterialien, Tools, Webseiten und Projektunterstützung um die Zusammenarbeit, die Abstimmung und das Wachstum der FHIR Community voranzutreiben.
Persönliche Mitglieder der HL7 FHIR Foundation profitieren von:
Weitere Informationen unter: http://www.fhir.org/
Ziel der Stiftung ist es, die weltweite Verbreitung und Implementierung des FHIR-Standards zu fördern. Sie bietet Informationen, Schulungsmaterialien, Tools, Webseiten und Projektunterstützung um die Zusammenarbeit, die Abstimmung und das Wachstum der FHIR Community voranzutreiben.
Persönliche Mitglieder der HL7 FHIR Foundation profitieren von:
- Zugang zu exklusiven Informationen wie z.B.:
- monatliche und jährliche Berichte über die Entwicklung der Community
- Projektberichte, Webinars
- Zugang zum FHIR Foundation Forum (web/email) zur Diskussion von Ausrichtung und Vorgehensweise der Stiftung sowie Priorisierung von Projekten
- Benachrichtigungen zu Chancen im (Arbeits-)Markt
- Beteiligung an der Wahl des Vorstandes
- Das Recht, FHIR-Implementierungs-Leitfäden, Dokumentationen und Projekte unter fhir.org bereitstellen zu lassen
- Rabatte bei der Teilnahme an Veranstaltungen der FHIR Foundation
- Öffentliche Anerkennung als Unterstützer der FHIR Foundation
Wer sich bis zum 31.3.2018 anmeldet, profitiert zusätzlich von Sonderkonditionen, darf sich als "FHIR Foundation Founder" bezeichnen und sich mit dieser "Badge" schmücken:
Weitere Informationen unter: http://www.fhir.org/
Dienstag, 31. Oktober 2017
IHE-Profil "MHD": XDS in einfach
Das IHE-Profil für den Dokumentenaustausch "XDS" hat in den vergangenen Jahren viel Aufmerksamkeit erfahren. Darin wird der Dokumentenaustausch zwischen einem "Document Producer", also einem System, das digitale Dokumente erzeugt und einer "Document Registry", die digitale Dokumente verwaltet, verbunden mit dem "Document Repository", das die Dokumente archiviert, beschrieben.
Der Bedarf einer derartigen Kommunikation ist unbestritten, dennoch geht die Umsetzung in der Praxis nur schleppend voran. Ursächlich sind dafür die hohen Anforderungen an die Implementierung.
In vielen Fällen mag dieser Aufwand gerechtfertigt sein - für komplexe Anforderungen kann es keine einfachen Lösungen geben!
Häufig jedoch sind die Anforderungen in diesem Kontext relativ einfach:
Basierend auf FHIR bietet MHD Lösungen, die sich schneller umsetzen lassen, was nur in geringem Maße auf eine Reduktion der Funktionalität zurückzuführen ist.
IHE empfiehlt existierenden XDS-Registries/Repositories die Gruppierung von XDS mit MHD, um MHD-basierten Applikationen den Zugriff auf die Dokumente zu ermöglichen:
Hier entfaltet sich der ganze Charme der FHIR-basierten Profilvarianten:
Wer MHD mit mPDQ (der FHIR-basierten Variante des "Patient Demographic Query"-Profils) gruppiert, wird feststellen, dass sowohl die Repräsentation der Patientendaten (Ressource: Patient)
als auch die Mechanismen der Suche (googeln!*) über beide Profile hinweg identisch sind:
HTTP GET [basis-url]/Patient?family=Mustermann&given=Max
FHIR ist wie Lego. Die Ressourcen bilden die Bausteine, IHE liefert die Baupläne dazu. Die Bausteine sind jedoch immer wieder die selben, lediglich die Art der Zusammensetzung ändert sich.
Wer einmal begonnen hat, FHIR zu implementieren, kann daher immer wieder auf bereits implementierte Ressourcen zurückgreifen, um neue Funktionen zu nutzen, sei es, um weitere FHIR-basierte IHE-Profile zu implementieren, Web-Applikationen über das SMART-Framework anzubinden oder Decision-Support-Dienste - beispielsweise für den Arzneimittel-Interaktionscheck - standardisiert zu integrieren.
Somit ist MHD nicht nur eine einfache Alternative für XDS, sondern auch eine zukunftssichere Investition.
Denn, dass sich FHIR duchsetzen wird, daran hegt auch IHE inzwischen keine Zweifel mehr, wie sich aus der Einführung zum MHD-Profil, bezug nehmend auf den noch-nicht-normativen Status von FHIR, ablesen lässt:
Der Bedarf einer derartigen Kommunikation ist unbestritten, dennoch geht die Umsetzung in der Praxis nur schleppend voran. Ursächlich sind dafür die hohen Anforderungen an die Implementierung.
In vielen Fällen mag dieser Aufwand gerechtfertigt sein - für komplexe Anforderungen kann es keine einfachen Lösungen geben!
Häufig jedoch sind die Anforderungen in diesem Kontext relativ einfach:
- Ein (mobiles) Gerät hat Daten erfasst und möchte dieses nun als strukturiertes Dokument mit Patientenkontext und einem minimalen Umfang an Metadaten an die zentrale Dokumentenverwaltung übergeben.
- Ein (mobiles) Gerät möchte eine Liste der verfügbaren Dokumente zu einem Patienten anzeigen und der Benutzer soll die Möglichkeit haben, ein ausgewähltes Dokument zu betrachten.
- Eine Arztpraxis mit minimaler IT-Ausstattung möchte auf die Dokumente im Archiv eines angebundenen Krankenhauses zugreifen
- Eine elektronische Patientenakte möchte Dokumente für den Import in eine elektronische Fallakte bereitstellen.
Für diese (und ähnliche) Anwendungsfälle bietet IHE nun alternativ das MHD-Profil an.
IHE: Mobile access to Health Documents (MHD)
Basierend auf FHIR bietet MHD Lösungen, die sich schneller umsetzen lassen, was nur in geringem Maße auf eine Reduktion der Funktionalität zurückzuführen ist.
Die Vereinfachung ergibt sich vorwiegend aus der Natur des FHIR-Standards.
Durch die Verwendung weit verbreiteter Web-Standards für den Datentransport sowie die Verfügbarkeit ausgereifter Programmbibliotheken und Referenzimplementierungen für viele Programmiersprachen, sind Entwickler mit erheblich geringerem Aufwand in der Lage, Integrationslösungen zu realisieren.
Dabei ist der Zusatz "mobile" irreführend! Wie die oben genannten Szenarien (die alle der MHD Spezifikation entnommen sind) zeigen, ist der Einsatz von MHD keines Falls auf mobile Endgeräte begrenzt. Viel mehr handelt es sich um eine Alternative zu XDS, die für mobile Endgeräte aufgrund der dort vorliegenden technologischen Beschränkungen alternativlos, für andere Geräte und Applikationen jedoch aus den gleichen Gründen attraktiv sein kann.
Alles ist eine Ressource
Ein wichtiger Aspekt von FHIR ist die einheitliche Betrachtung aller Dinge als Ressourcen.
Eine Ressource ist ein (wahlweise in JSON oder XML repräsentiertes) Objekt, das über eine eindeutige URL adressiert werden kann und über ein definiertes Set an Suchparametern verfügt.
Alle in FHIR spezifizierten Ressourcen gehorchen den gleichen Gesetzen.
MHD spiegelt diesen Ansatz wieder.
Die Dokumenten-Metadaten (Ressource: DocumentReference), der Patient (Ressource: Patient), das Dokument (Ressource: Binary) an sich (ein PDF, ein CDA-Dokument, eine Grafik, ein Word-Dokument..), der Autor (Ressource: Practitioner):
Alle werden durch FHIR-Ressourcen abgebildet. Für die Übermittlung eines Dokumentes werden diese Ressourcen zusammengefasst (Ressource: Bundle) und dem REST-Paradigma folgend per HTTP POST [basis-url]/ an die Dokumentenverwaltung übergeben.
Dokumentensuche in der Registry: einfach "googlen"*
Auch die Suche nach Dokumenten folgt dem REST Paradigma:
Zeige mir alle Laborbefunde zu Patient "123456" - so einfach wie googlen*:
HTTP GET [basis-url]/DocumentReference?subject=123456&type=Laborbefund
Das Ergebnis ist eine Liste der zutreffenden Dokumente, die deren vollständigen Metadaten enthält sowie die URL des jeweils zugehörigen Dokumentes.
Das Dokument zur Anzeige abzurufen ist nichts anderes, als die Ressource an der entsprechenden URL anzufordern:
HTTP GET [basis-url]/Binary/34567
MHD oder XDS? Warum nicht beides!
Die Spezifikation von XDS und MHD sind bezüglich des Umfangs und der Notation der Metadaten abgestimmt, so dass ein Mapping von einem Profil in das andere ohne Probleme möglich ist.IHE empfiehlt existierenden XDS-Registries/Repositories die Gruppierung von XDS mit MHD, um MHD-basierten Applikationen den Zugriff auf die Dokumente zu ermöglichen:
 |
| Quelle: http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) |
PIX/PDQ: Das Gleiche in grün
Zumeist wird XDS mit dem PIX- oder PDQ-Profil gruppiert, da sich Document Producer und Document Registry zunächst über die eindeutige Identifizierung eines Patienten verständigen müssen.Hier entfaltet sich der ganze Charme der FHIR-basierten Profilvarianten:
Wer MHD mit mPDQ (der FHIR-basierten Variante des "Patient Demographic Query"-Profils) gruppiert, wird feststellen, dass sowohl die Repräsentation der Patientendaten (Ressource: Patient)
als auch die Mechanismen der Suche (googeln!*) über beide Profile hinweg identisch sind:
HTTP GET [basis-url]/Patient?family=Mustermann&given=Max
Einmal implementieren - endlos wiederverwenden
FHIR ist wie Lego. Die Ressourcen bilden die Bausteine, IHE liefert die Baupläne dazu. Die Bausteine sind jedoch immer wieder die selben, lediglich die Art der Zusammensetzung ändert sich.
Wer einmal begonnen hat, FHIR zu implementieren, kann daher immer wieder auf bereits implementierte Ressourcen zurückgreifen, um neue Funktionen zu nutzen, sei es, um weitere FHIR-basierte IHE-Profile zu implementieren, Web-Applikationen über das SMART-Framework anzubinden oder Decision-Support-Dienste - beispielsweise für den Arzneimittel-Interaktionscheck - standardisiert zu integrieren.
Somit ist MHD nicht nur eine einfache Alternative für XDS, sondern auch eine zukunftssichere Investition.
Denn, dass sich FHIR duchsetzen wird, daran hegt auch IHE inzwischen keine Zweifel mehr, wie sich aus der Einführung zum MHD-Profil, bezug nehmend auf den noch-nicht-normativen Status von FHIR, ablesen lässt:
Whenever possible, IHE profiles are based on established and stable underlying standards. However, if an IHE committee determines that an emerging standard offers significant benefits for the use cases it is attempting to address and has a high likelihood of industry adoption, it may develop IHE profiles and related specifications based on such a standard.
* Um dem Aufschrei der Datenschützer zuvorzukommen:
Dies bedeutet nicht, dass alle Dokumente im WWW ungeschützt offenliegen!! Lediglich die zugrunde liegende Technologie für die Kommunikation von FHIR-Client und -Server ist die gleiche wie zwischen Browser und Webserver. Die in MHD empfohlenen Mechanismen zur Autorisation, Authentifikation und Verschlüsselung zu beschreiben, würde jedoch den Umfang dieses Artikels sprengen, sind jedoch im MHD (bzw. referenzierten Profilen) nachzulesen.
Montag, 23. Oktober 2017
Neu: Unser 2-tägiger FHIR-Intensiv-Workshop
Wer stellt sich der Herausforderung?
Themen:
Tag 1
Einführung in FHIR
Übung: Demografische Patientendaten
Das REST Paradigma
Tools: REST-Client
Übung: REST Interaktionen
Bundles & Search
Übung: Suchen mit HTTP
~ FHIR-Abend ~
Tag 2
Das Operations Framework
Übung: Operations mit HTTP
Ressourcen und Referenzen
Übung: Ressourcen verlinken
Terminologien
Übung: Terminologien
Transaktionen
Paradigmen: Dokumente und Messaging
Questionnaires
Use-Case: SMART Apps
Use-Case: CDS-Hooks
FHIR und V2/CDA/IHE
Wrap-Up
~ FHIR-Abend ~
Die Schulung kann wahlweise in Deutsch oder Englisch gehalten werden.
Weitere Informationen erhalten Sie über unser Kontaktformular oder hier.
FAQ: Was passiert auf einem Connectathon?
Frage
Was passiert auf einem Connectathon?Antwort
Im Gegensatz zu IHE-Connectathons, wird bei FHIR-Connectathons nicht die Software getestet, sondern der Standard.Entwickler kommen mit einer Idee oder einem UseCase, möglicherweise sogar mit einer (halb-)fertigen Implementierung auf den Connectathon und testen, in wie weit sich FHIR als Basis dieser Implementierung eignet. Dabei erhalten Sie Unterstützung von FHIR-Experten und erfahrenen Entwicklern. Daher spricht man häufig auch von einem "Hackathon". Wenn ein Problem nicht mit der geballten Community-Wissenspower gelöst werden kann, dann wird darüber diskutiert, ob und wie der Standard angepasst werden muss, um den konkreten UseCase besser zu unterstützen.
Die Connectathons sind daher ein Win/Win für Entwickler und Standardisierer.
Für Neulinge bieten die Connectathons (insbesondere jene im Rahmen der DeveloperDays) zusätzlich Tutorials und Workshops.
Ein wichtiger Termin für alle, die sich für die Teilnahme an einem Connectathon interessieren, ist der 12./13. Mai 2018. Im Rahmen des HL7 International WorkGroupMeetings in Köln wird dort ein Connectathon stattfinden, zu dem über 300 Teilnehmer erwartet werden!
FAQ: Unendliche Mannigfaltigkeit in unendlicher Kombination: FHIRs Schwäche?
Frage
Sind die schier unendlichen Möglichkeiten, FHIR Resourcen zu kombinieren und zu verlinken nicht ein Hindernis bei der Interoperabilität?Antwort
Der Standard als ein Lego-Baukasten zu sehen. Es gibt viele verschiedene Klötzchen, aus denen man einen Würfel, ein Raumschiff oder das Taj Mahal bauen kann.Wichtig ist, dass es Baupläne gibt, die beschreiben, wie man aus den unzähligen Möglichkeiten, Klötzchen zusammenzusetzen, genau die richtigen Klötzchen und Verbindungen wählt, damit am Ende das gewünschte Ergbnis herauskommt. In der Standardisierung spricht man hierbei von "Implementation Guides" (IG).
Das Konzept der IGs ist nicht neu. Diese gab es auch schon für V2 und V3/CDA. Allerdings waren IGs bislang meist mehrere hundert Seiten starke PDFs.
Wie gut sich eine Implementierung an solche IGs hält, ist daher immer davon abhängig, wie gründlich der Implementierer den Bauplan studiert hat.
Und dabei haben sich in der Vergangenheit die Abgründe aufgetan.
FHIR ist sich mehr als seine Vorgänger der Bedeutung der IGs bewusst. Daher sind diese nun nicht länger nur "Beipackzettel" sondern ein integraler Teil des Standards, der es erstmals möglich macht, die IGs in maschinenlesbarer Form zu veröffentlichen, so dass diese unmittelbar zur Code-generierung, Validierung und für Compliance-Tests verwendet werden können.
Siehe hierzu auch: http://hl7.org/implement/standards/fhir/conformance-module.html
Die Aufgabe, IGs für die Nutzung von FHIR in Deutschland zu erstellen, fällt dem Technischen Komitee von HL7 Deutschland zu.
Dieses entwickelt fortlaufend den "FHIR Basisleitfaden für Deutschland". Dort werden Gemeinsamkeiten vereinbart, die allen in und für Deutschland implementierten Produkten zueigen sein sollten, um die Interoperabilität zu gewährleisten.
Dort wird zum Beispiel festgelegt, wie
- eine Lebenslange Arztnummer
- eine ICD-10-Diagnose
- eine gesetzliches Versicherungsverhältnis
- oder die von einer eGK eingelesenen Patientendanten
in FHIR repräsentiert werden.
Der deutschsprachige Bereich des FHIR-Chats bildet dazu die Arbeits- und Diskussions-Plattform: https://chat.fhir.org/#narrow/stream/german.20(d-a-ch).
Die Beteiligung steht jedem offen, die Anmeldung ist kostenlos.
Unter der Rubrik "FAQ" veröffentlichen wir Fragen, die uns auf unterschiedlichen Wegen erreichen. Wenn auch Sie uns eine Frage zum Thema "FHIR" stellen möchten, nutzen Sie bitte das Kontaktformular auf unserer Homepage.
Mittwoch, 18. Oktober 2017
Forderungen der Ärzte an elektronische Patientenakten: FHIR bietet die Basis für die Umsetzung!
Dr. med. Christiane Groß, Ärztlicher Beirat zur Begleitung des Aufbaus einer Telematik-Infrastruktur fasst auf dem 2. Deutschen Interoperabilitätstages in Dortmund die Anforderungen der Ärzte an eine elektronische Patientenakte zusammen:
- zeitgleicher Zugriff auf einzelne Behandlungsdaten verschiedener Institutionen für alle an der Behandlung Beteiligten
- Übernahme einzelner Daten in die eigene Akte
- Umfangreiche Suchfunktionen
- einheitliche Datenformate
- Möglichkeit des Patienten einzelne Aktenteile zu verbergen
- Patient soll Daten beitragen können, die der Arzt bei Bedarf übernehmen kann
- Wiederauffindbarkeit und Erkennbarkeit von Befunden und deren Quellen
- Datensparsamkeit
- Plattformunabhängigkeit
- Semantische Datenvernetzung
- Intelligente Akte mit Vorschlägen und Hinweise auf Leitlinien
- Gleiche Strukturen in elektronischer Patientenakte und Fallakte
- offene, herstellerunabhängige Schnittstellen
- Herstellerunabhängige Modularität der Lösungsbausteine
FHIR hat die technische Basis für die Umsetzung:
- zeitgleicher Zugriff auf einzelne Behandlungsdaten verschiedener Institutionen für alle an der Behandlung Beteiligten
- Die REST-basierte Kommunikation in FHIR ermöglicht den transparenten Zugriff auf verteilte Daten
- Die Integration des OpenID/OAUTH2-Standards ermöglicht einrichtungsübergreifende Autorisation und Authentifikation
- Übernahme einzelner Daten in die eigene Akte
- Einzelne Datenelemente (Resourcen) können zwischen Systemen ausgetauscht werden, die Provenance-Resource macht die Herkunft der Daten nachvollziehbar
- Umfangreiche Suchfunktionen
- FHIR verfügt über sehr umfangreiche Suchfunktionen mit definierten Suchparametern pro Resource und der Möglichkeit, komplex verknüpfter Bedingungen.
- einheitliche Datenformate
- Alle Datenelemente (Resourcen) in FHIR sind konkret spezifiziert und haben ein wohldefiniertes Verhalten.
- Patient soll Daten beitragen können, die der Arzt bei Bedarf übernehmen kann
- Eine der Kernanwendungen für FHIR ist die Implementierung patientenbezogener Applikationen.
- Möglichkeit des Patienten einzelne Aktenteile zu verbergen
- Über Security-Labels können einzelne Resourcen als besonders schutzbedürftig gekennzeichnet werden.
- Wiederauffindbarkeit und Erkennbarkeit von Befunden und deren Quellen
- Diese Funktionalität wird in FHIR über REST-Queries und die Provenance-Resource abgebildet.
- Datensparsamkeit
- FHIR strukturiert die Daten in Resourcen (Patient, Behandler, Medikament, Messwert...), die einzeln eine vollständige medizinische Bedeutung haben. Aus solchen Resourcen zusammengestellte strukturierte Dokumente können nach konkreten Informationen durchsucht werden und müssen nicht als Ganzes ausgetauscht werden. Jede Resource verfügt über eine "Summary", die nur die wichtigsten Informationen enthält.
- Plattformunabhängigkeit
- FHIR ist an keine Plattform gebunden. Es gibt verschiedene Möglichkeiten der Datenrepräsentation und es sind bereits fertige Referenzimplementierungen in Java, .NET, Delphi und vielen anderen Programmiersprachen verfügbar
- Semantische Datenvernetzung
- Mit Hilfe des umfangreichen Terminologie-Frameworks integriert FHIR nicht nur die semantische Interoperabilität durch die Nutzung von Terminologien, sondern ermöglicht es auch den Entwicklern, die Pflege und Handhabung dieser Terminologien an Spezialsysteme zu delegieren
- Intelligente Akte mit Vorschlägen und Hinweise auf Leitlinien
- Das FHIR-basierte CDS-Hooks-Framework ermöglicht die nahtlose, standardisierte Integration von Entscheidungs-Unterstützungs-Systemen in Primärsysteme
- Gleiche Strukturen in elektronischer Patientenakte und Fallakte
- Die FHIR Resourcen können wiederverwendet und immer wieder zu neuen Strukturen zusammengestellt werden (ein vom Patienten gemessener Blutdruckmesswert kann aus der Patientenakte in das Praxissystem übernommen, von dort in einen Arztbrief eingebunden, elektronisch an ein Klinikum übermittelt und von dort wieder in die elektronische Patientenakte übernommen werden).
- offene, herstellerunabhängige Schnittstellen
- FHIR ist frei verfügbar und lizenz-offen. Es bestehen keine Einschränkungen bei der Nutzung und Implementierung. Viele OpenSource-Implementierungen sind ebenfalls frei verfügbar.
- Herstellerunabhängige Modularität der Lösungsbausteine
- Das FHIR-basierte SMART-Framework zeigt, wie verschiedene "Insellösungen" von Drittherstellern nahtlos und standardisiert in Primärsysteme eingebettet werden können.
Dienstag, 17. Oktober 2017
"FHIR für Programmierer" auf dem 2. Deutschen Interoperabilitätstag
Nach erfolgreicher Premiere im Rahmen des IHE-Europe Connectathons 2016 in Bochum wird der Deutsche Interoperabilitätstag im Jahr 2017 fortgesetzt. Bei dem Erfolgsformat diskutieren führende Persönlichkeiten aus Politik und Selbstverwaltung, Anwenderinnen und Anwender im Gesundheitswesen sowie Vertreterinnen und Vertreter der Industrie über ihre Ansätze zur Schaffung von Interoperabilität.
2017 wird die Veranstaltung in Kombination mit der HL7-/IHE-Jahrestagung in Nordrhein-Westfalen stattfinden.
--> https://www.ztg-nrw.de/veranstaltungen/dit_2017/ <--
| DATUM/ZEIT | VERANSTALTUNGSORT | ||
|---|---|---|---|
| 18.10.2017 - 20.10.2017 ganztägig | Kongresszentrum Westfalenhallen Dortmund, 44137 Dortmund |
Die Anmeldung zum Deutschen Interoperabilitätstags 2017, zur HL7-/IHE-Jahrestagung und den begleitenden Tutorials ist kurzfristig vor Ort an der Teilnehmerregistrierung im Kongresszentrum Westfalenhallen Dortmund möglich.
Die Veranstaltung ist im Rahmen der Zertifizierung der ärztlichen Fortbildung der Ärztekammer Westfalen-Lippe mit 8 Punkten (Kategorie: A) anrechenbar.
Teilnahmegebühren:
| Veranstaltung | Preis (inkl. MwSt.) | Studierende |
| 2. Deutscher Interoperabilitätstag (DIT) | 170,- € | 90,- € |
| HL7/IHE-Jahrestagung | 330,- € | 100,- € |
| Kombiticket (DIT/HL7/IHE) | 395,- € | |
| Tutorials | je 50,- € |
Die Tagungsgebühr schließt Verpflegung und Getränke in den Pausen ein.
Die Übernachtung wird von den Teilnehmern selbst reserviert.
Montag, 16. Oktober 2017
Deutsche FHIR Basisprofile: Kommentarauflösung hat begonnen
Am gestrigen Sonntag, dem 15.10.2017 ging die erste Kommentierungsphase für die FHIR Basisprofile zu Ende.
Nun beginnt die Auflösung der eingegangenen Kommentare.
Insgesamt gilt es, 28 offene Kommentare zu bearbeiten.
Die Diskussion und Abstimmung zu den jeweiligen Punkten findet im FHIR-Chat statt.
Die Beteiligung steht jedem offen und das verantwortliche Technische Komitee von HL7 Deutschland würde sich sehr freuen, eine möglichst große Zahl von Stimmen und Meinungen zu hören, um sicherzustellen, dass die Anforderungen Aller in den Basisprofilen repräsentiert sind.
Einige der aktuell diskutierten Themen umfassen zum Beispiel:
Issue #50: GKV-Hilfsmittelnummer in Basisprofil
Issue #54: ValueSet-Bindung für Bundesländer
Weiterhin werden aktuell auch Themen aus dem Ballot des Medikationsplanes besprochen, die Auswirkungen auf das Basisprofil haben.
Für folgenden Kommentar liegt bereits ein Lösungsvorschlag zur Abstimmung vor.
Issue #16: NamingSystem für Apotheken ID (IDF)
Weitere Diskussionsthreads werden in den kommenden Tagen erstellt.
Das Technische Komitee bittet um Beachtung der Tatsache, dass zum Zeitpunkt der Abstimmung nur noch "dafür" oder "dagegen" gestimmt werden kann. Die Diskussion ist dann abgeschlossen.
Auch die Beteiligung an der Abstimmung steht jedem Interessierten offen, Es ist lediglich ein (kostenfreier) Account für den FHIR Chat erforderlich.
Nun beginnt die Auflösung der eingegangenen Kommentare.
Insgesamt gilt es, 28 offene Kommentare zu bearbeiten.
Die Diskussion und Abstimmung zu den jeweiligen Punkten findet im FHIR-Chat statt.
Die Beteiligung steht jedem offen und das verantwortliche Technische Komitee von HL7 Deutschland würde sich sehr freuen, eine möglichst große Zahl von Stimmen und Meinungen zu hören, um sicherzustellen, dass die Anforderungen Aller in den Basisprofilen repräsentiert sind.
Einige der aktuell diskutierten Themen umfassen zum Beispiel:
Issue #50: GKV-Hilfsmittelnummer in Basisprofil
Issue #54: ValueSet-Bindung für Bundesländer
Weiterhin werden aktuell auch Themen aus dem Ballot des Medikationsplanes besprochen, die Auswirkungen auf das Basisprofil haben.
Für folgenden Kommentar liegt bereits ein Lösungsvorschlag zur Abstimmung vor.
Issue #16: NamingSystem für Apotheken ID (IDF)
Weitere Diskussionsthreads werden in den kommenden Tagen erstellt.
Das Technische Komitee bittet um Beachtung der Tatsache, dass zum Zeitpunkt der Abstimmung nur noch "dafür" oder "dagegen" gestimmt werden kann. Die Diskussion ist dann abgeschlossen.
Auch die Beteiligung an der Abstimmung steht jedem Interessierten offen, Es ist lediglich ein (kostenfreier) Account für den FHIR Chat erforderlich.
Mittwoch, 11. Oktober 2017
Neue IHE-Profile für den Austausch strukturierter Dokumente mit klinischem Mehrwert
IHE International kündigte am 9. Oktober die Veröffentlichung von zwei neuen IHE-Profilen an: mXDE und QEDm
Das Ziel dieser Profile ist es, den unmittelbaren Zugriff auf relevante Datenelemente innerhalb eines strukturierten Dokumentes zu ermöglichen um Klinikern damit einen schnellen Überblick über den Verlauf einzelner Messwerte zu liefern, ohne dazu unzählige Dokumente durchforsten zu müssen, sowie die Option, die strukturiert vorliegenden Daten zu statistischen und wissenschaftlichen Zwecken zu aggregieren.
mXDE (Mobile Cross-Enterprise Document Data Element Extraction) kombiniert die grob-granularen Query-Funktionen des IHE XDS-Profils und dessen FHIR-basierten pendant MHD (Mobile access to Health Documents) mit den feingranularen, ebenfalls FHIR-basierten Funktionen des QEDm (Query for Existing Data for Mobile)
Weitere Informationen findet man auf der mXDE-Homepage.
IHE ergänzt damit die inzwischen stattliche Liste der bereits vorhandenen FHIR-basierten Workflow-Profile:
Das Ziel dieser Profile ist es, den unmittelbaren Zugriff auf relevante Datenelemente innerhalb eines strukturierten Dokumentes zu ermöglichen um Klinikern damit einen schnellen Überblick über den Verlauf einzelner Messwerte zu liefern, ohne dazu unzählige Dokumente durchforsten zu müssen, sowie die Option, die strukturiert vorliegenden Daten zu statistischen und wissenschaftlichen Zwecken zu aggregieren.
mXDE (Mobile Cross-Enterprise Document Data Element Extraction) kombiniert die grob-granularen Query-Funktionen des IHE XDS-Profils und dessen FHIR-basierten pendant MHD (Mobile access to Health Documents) mit den feingranularen, ebenfalls FHIR-basierten Funktionen des QEDm (Query for Existing Data for Mobile)
Die neue Gleichung für den strukturieren Dokumentenaustausch lautet also
mXDE = XDS + QEDm,
wobei für Entwickler die äquivalente Gleichung
mXDE = MHD + QEDm
einfacher zu lösen sein dürfte, da sie durchgehend auf den Prinzipien eines einzigen Standards beruht: FHIR!
Weitere Informationen findet man auf der mXDE-Homepage.
IHE ergänzt damit die inzwischen stattliche Liste der bereits vorhandenen FHIR-basierten Workflow-Profile:
Donnerstag, 21. September 2017
FHIR Proficiency Certificate: Die FHIR-Probe!
Auf dem HL7-Workgroup-Meeting in San Antonio konnten Wagemutige ihr FHIR-Wissen unter Beweis stellen. Bei der Pilotierung des FHIR Proficiency Exams erreichten neun von dreizehn Teilnehmern nach gründlicher Vorbereitung auf Anhieb das angestrebte Zertifikat.
Der Test prüft das Verständnis der fundamentalen Konzepte von FHIR, breitgefächerte Grundkenntnisse der Spezifikation sowie das Wissen über die praktische Anwendung des Standards.
Der Test kann deutschlandweit in kooperierenden Zentren online abgelegt werden. Wir freuen uns, in Kürze auch Vorbereitungskurse in Deutscher Sprache anbieten zu können.
Bitte kontaktieren Sie uns bei Interesse am FHIR Proficiency Exam, damit wir Sie über die geplanten Schulungstermine auf dem laufenden halten können.
Testfrage:
Eine Messung der Körpertemperatur wird in FHIR dargestellt als
a) eine Condition-Ressource mit dem ICD-10-Code für "Fieber"
b) eine Observation-Ressource der Kategorie "vital-signs"
c) eine DeviceMetric-Ressource vom Typ "temperature"
Hätten Sie's gewusst?
Der Test prüft das Verständnis der fundamentalen Konzepte von FHIR, breitgefächerte Grundkenntnisse der Spezifikation sowie das Wissen über die praktische Anwendung des Standards.
Der Test kann deutschlandweit in kooperierenden Zentren online abgelegt werden. Wir freuen uns, in Kürze auch Vorbereitungskurse in Deutscher Sprache anbieten zu können.
Bitte kontaktieren Sie uns bei Interesse am FHIR Proficiency Exam, damit wir Sie über die geplanten Schulungstermine auf dem laufenden halten können.
Testfrage:
Eine Messung der Körpertemperatur wird in FHIR dargestellt als
a) eine Condition-Ressource mit dem ICD-10-Code für "Fieber"
b) eine Observation-Ressource der Kategorie "vital-signs"
c) eine DeviceMetric-Ressource vom Typ "temperature"
Hätten Sie's gewusst?
FHIRwork: Implementierungsleitfaden für Deutschland
Auf dem HL7-Workgroup-Meeting in San Diego erhielten die FHIR-Basisprofile und der Implementierungsleitfaden für Deutschland den letzten Schliff:
Das Ergebnis steht nun bis zum 15. Oktober zur Kommentierung.
Deutschen FHIR®-Basisprofile stehen zur Kommentierung
Ankündigung des Technischen Komitees für FHIR bei HL7 Deutschland e.V.:
*****
Abstimmung/Kommentierung zu den deutschen FHIR®-Basisprofilen
Die deutschen FHIR®-Basisprofile verfolgen das Ziel,- Use Case übergreifend relevante Vorgaben für die Implementierung von FHIR in Deutschland zu machen, um die Interoperabilität sicher zu stellen.
- Use Case-spezifischen Profilen eine gemeinsame Basis zu bieten, um die Interoperabilität der Use Case-übergreifenden Kerninformationen zu gewährleisten.
- Allgemeingültige Codesysteme und Value Sets zu definieren
- Allgemeingültige Nomenklaturen festzulegen (NamingSystems)
Kommentare können nach Anmeldung in GitHub als "Issue" eingegeben werden oder per eMail an tc@fhir.de.
Gut durchdachte, vollständige und getestete Basis-Profile sind die Grundvoraussetzung für die Erstellung sämtlicher Implementierungsleitfäden in Deutschland. Das Technische Komitee bittet daher bis zum 15. Oktober 2017 um die Kommentierung der bisher erarbeiteten Conformance-Ressourcen.
Die Diskussion und Auflösung der eingegangenen Kommentare findet im internationalen FHIR-Chat und auf den Meetings des Interoperabilitätsforums statt.
Die Teilnahme steht jedem offen!
Wichtige Zeitangaben:
Für Fragen steht das Technische Komitee für FHIR bei HL7 Deutschland Ihnen gerne zur Verfügung unter tc@fhir.de oder im internationalen FHIR-Chat.
Wenn Sie im Rahmen eines FHIR-Projektes oder einer Produktentwicklung eigene FHIR-Implementierungsleitfäden erstellen möchten und Interesse an einer Schulung zur Nutzung des Profiling-Tools Forge®und der Profil-Registry Simplifier®haben, kontaktieren Sie uns!
Die Gefyra GmbH bietet individuelle In-House-Schulungen sowie Unterstützungsleistungen von kompetenter projektbegleitender Beratung bis hin zu "schlüsselfertigen" Implementierungsleitfäden an.
Wichtige Zeitangaben:
- Ankündigung der Kommentierungsphase: 7. August 2017
- Eröffnung der Kommentierungsphase: 15. September 2017
- Schließen der Kommentierungsphase: 15. Oktober 2017
- Besprechung und Auflösung der Kommentare erfolgt bis Mitte November 2017
******
Wenn Sie im Rahmen eines FHIR-Projektes oder einer Produktentwicklung eigene FHIR-Implementierungsleitfäden erstellen möchten und Interesse an einer Schulung zur Nutzung des Profiling-Tools Forge®und der Profil-Registry Simplifier®haben, kontaktieren Sie uns!
Die Gefyra GmbH bietet individuelle In-House-Schulungen sowie Unterstützungsleistungen von kompetenter projektbegleitender Beratung bis hin zu "schlüsselfertigen" Implementierungsleitfäden an.
Montag, 17. Juli 2017
EU Datenschutz-Grundverordnung: Patienten haben ein Recht auf Standards! FHIR!
Am 25. Mai 2018 tritt die Datenschutz-Grundverordnung (DSGVO) in Kraft, eine Verordnung der Europäischen Union, mit der die Regeln für die Verarbeitung von personenbezogenen Daten durch private Unternehmen und öffentliche Stellen EU-weit vereinheitlicht werden.
Die Verordnung ersetzt die aus dem Jahr 1995 stammende Richtlinie 95/46/EG.
Die Auswirkungen dieser Verordnung auf den Einsatz von Interoperabilitätsstandards im Gesundheitswesen sind gravierend.
Die wichtigsten Unterschiede im Überblick:
- Die Zustimmung zur Sammlung und Weiterverarbeitung personenbezogener Daten muss explizit und zweckgebunden eingeholt werden (so genanntes Opt-In). Daten im Kontext medizinischer Behandlung sind hiervon teilweise ausgenommen.
- EU-Bürger haben das Recht, die Löschung der über Sie gesammelten personenbezogenen Daten zu fordern.
- EU-Bürger haben das Recht, ihre persönlichen Daten von einem elektronischen System in ein anderes zu übertragen, ohne vom Besitzer dieser Daten daran gehindert zu werden. Die Daten müssen in einem strukturierten, standardisierten, maschinenlesbaren Format zur Verfügung gestellt werden.
- Im Gegensatz zur vorhergehenden Richtlinie, die auf Staatsebene in geltendes Recht übersetzt wurde, hat die DSGVO Europaweit unmittelbar die Kraft eines Gesetzes.
- Die Verordnung gilt auch außerhalb der EU für alle Organisationen, die Daten von EU-Bürgern speichern, verarbeiten oder übermitteln, unabhängig davon, ob diese Firmen in der EU ansässig sind oder nicht.
Recht auf Datenübertragung (Artikel 12 EU-DSGVO)
Das Recht auf Datenübertragung umfasst:- automatisch erfasste Daten
- Daten, zu denen die Person selbst beigetragen oder die sie erfasst hat
(z.B. Anamnese, Dauermedikation, Allergien, Messdaten von Wearables, Heimgeräten etc.) - alle für die Interpretation dieser Daten relevanten Metadaten
(z.B. Datum, Uhrzeit, Ort, Kontext)
Es umfasst nicht
- Daten, die vom Dienstleister selbst erhoben wurden.
(z.B. Diagnosen, Prozeduren, Behandlungspläne)
Zwar hat jeder Patient grundsätzlich das Recht, seine Medizinischen Daten einzusehen, das in der DSGVO verankerte Recht auf elektronische Übertragbarkeit betrifft jedoch nur die vom Patienten selbst beigetragenen Informationen.
Während die für die Medizinische Versorgung und Vorsorge erforderlichen Daten einerseits von der Verordnung ausgeschlossen sind, schließt eine weitere Klausel jene Daten ein, für deren Erfassung und Weiterverarbeitung der Patient eine explizite Zustimmung erteilt hat.
Daher werden vorwiegend regionale und nationale Netzwerke für den Austausch patientenbezogener Daten von der Verordnung betroffen sein.
Die größte Herausforderung, die alle Dienstleiter im Gesundheitswesen betrifft, ist unterscheiden zu können, welche der erfassten Patientendaten dem Recht auf Übertragbarkeit unterliegen und welche nicht. Wenn dies nicht möglich ist, bleibt keine andere Wahl, als alle Daten in einem standardisierten, maschinen-lesbaren Format zum Transfer bereitzustellen.
Auswirkungen auf die Verwendung von Interoperabilitätsstandards im Gesundheitswesen
Die EU Verordnung schreibt keinen konkreten Standard für den Datenaustausch vor. In den Leitlinien zum Recht auf Datenübertragbarkeit (Artikel 20) heißt es:Die DSGVO verpflichtet die für die Verarbeitung Verantwortlichen dazu, die von der Person angeforderten personenbezogenen Daten in einem Format bereitzustellen, das eine Weiterverwendung ermöglicht. Gemäß Artikel 20 Absatz 1 der DSGVO müssen die personenbezogenen Daten „in einem strukturierten, gängigen und maschinenlesbaren Format“ bereitgestellt werden.Jedoch lassen die hohen Anforderungen an einen solchen Standard wenig Wahlfreiheit:
ein geeigneter Standard für die Abbildung der DSGVO muss
- die patientenbezogenen Daten strukturiert und maschinenlesbar repräsentieren
- ebenso die zur Interpretation dieser Informationen erforderlich Metadaten
- vom Patienten explizit erteilte Einwilligungen verwalten und mit den darunter fallenden Daten verlinken
- den Informationen verschiedene Sicherheitsstufen zuweisen (abhängig davon, ob Sie unter das Übertragungsrecht fallen oder nicht)
- die Herkunft der Information nachhalten (Artikel 15).
Weiterhin verlangt die Verordnung die Anwendung der allgemeinen Datenschutzgrundsätze, insbesondere Datenqualität (Auditing) und in Bezug auf personenbezogene Daten Informationen über Zugriffe darauf oder Empfänger davon (Artikel 15).
Die DSGVO fordert damit wie schon erwähnt ebenso ein, dass die Herkunft der Daten festgehalten werden muss. Diese unter dem Begriff Provenance geführte Anforderung wurde bisher nur wenig bis gar nicht beachtet oder implementiert und dürfte entsprechende Folgen haben.
Zudem wird zu beachten sein, dass der §203 Strafgesetzbuch Verletzung von Privatgeheimnissen nach der Anpassung auch für IT-Personal im Gesundheitswesen gültig sein wird.
Die DSGVO fordert damit wie schon erwähnt ebenso ein, dass die Herkunft der Daten festgehalten werden muss. Diese unter dem Begriff Provenance geführte Anforderung wurde bisher nur wenig bis gar nicht beachtet oder implementiert und dürfte entsprechende Folgen haben.
Zudem wird zu beachten sein, dass der §203 Strafgesetzbuch Verletzung von Privatgeheimnissen nach der Anpassung auch für IT-Personal im Gesundheitswesen gültig sein wird.
Die EU-Leitlinien fordern Industrie und Handel dazu auf, sich gemeinsam auf Standards und Formate zu einigen, um die Anforderungen der Übertragungsrechtes zu implementieren.
Weiterhin wird die Bereitstellung einer sicheren und wohldokumentierten API empfohlen.
Der wichtigste momentan verfügbare (Prä-)Standard, der diese Anforderungen abdecken kann, ist FHIR. FHIR bietet einerseits die dokumentierte API inklusive eines Frameworks für Authentifizierung und Autorisierung (SMART-on-FHIR) als auch die Artefakte um die relevanten medizinischen und personenbezogenen Daten maschinenlesbar und strukturiert erfassen, auswerten und übertragen zu können.
Auch Auditing, Herkunftsverfolgung (Provenance), SecurityLabels und Einwilligungen können mit Hilfe des umfassenden Security/Privacy-Moduls in FHIR abgebildet werden.
René Spronk, langjähriger Berater, Blogger und Anbieter von Schulungen im Bereich der Standardisierung im Gesundheitswesen schreibt dazu in seinem Artikel, der als Grundlage und Anregung zu diesem Beitrag diente:
FHIR could be that standard.
Quelle: http://www.ringholm.com/column/GDPR_impact_on%20healthcare_data_interoperability.htm
Weitere Quelle:
https://www.healthcare-informatics.com/blogs/david-raths/interoperability/could-european-data-protection-regulation-give-fhir-boost