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:

0. das Artefakt wurde im "current build" publiziert (gleichbedeutend mit "Entwurf")
   
1. 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
2. PLUS das Artefakt wurde von mindestens drei unabhängigen Systemen implementiert und unter realitätsnahen Bedingungen getestet (z.B. bei einem Connectathon). 
3. 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
4. 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.
5.  PLUS das Artefakt wurde in mindestens 5 verschiedenen Systemen in mehr als einem Land implementiert und produktiv genutzt.
6. "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:

FAQ: FHIR jetzt schon verwenden oder abwarten?

FHIR Product Director Blog: FHIR R4 Ballot & Community Consultation

Abstimmungsverfahren (Ballot) bei HL7 national und international

FHIR - current build

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