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! 

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.

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.

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.