FHIR Chat · eGK/VSDM-Daten in FHIR · german (d-a-ch)

Stream: german (d-a-ch)

Topic: eGK/VSDM-Daten in FHIR

Simone Heckmann (Sep 06 2019 at 15:45):

Wie bereits in https://chat.fhir.org/#narrow/stream/179183-german-(d-a-ch)/topic/Coverage.20(Profil.20GKV) andiskutiert, möchte ich hier die Überlegungen fortführen, wie ein Datensatz von der elektronischen Versichertenkarte (VSDM, künftig ggf. auch Notfalldaten etc) in FHIR kommuniziert werden könnte.
Wir waren uns bisher weitgehend einig dass

• so viel wie möglich aus dem Datensatz auf FHIR-Standard-Elemente gemappt werden sollte
• nicht alles was auf der EKG steht, sinnvoll zu mappen ist
• die komplexen STU3-Extensions, mit denen wir versucht haben, die VSDM-Inhalte in die Coverage-Ressource zu pressen etwas unhandlich sind
• es in einigen UseCases weniger darauf ankommt, die Inhalte in FHIR abzubilden, sondern lediglich der Orginial-Datensatz persistiert/transportiert/rekonstruiert werden muss.

Die Überlegungen gingen daher in die Richtung, den EGK-Datensatz als DocumentReference mit Base64-codierten Original-Daten abzubilden. Dessen ungeachtet sollten natürlich so viel Informationen wie sinnvoll/möglich auf FHIR gemappt werden, um über die API zur Verfügung zu stehen.

Christof Gessner (Sep 06 2019 at 15:54):

Bei Notfalldaten und Medikationsplan gibt es vermutlich use cases wo es sinnvoll sein kann, die jeweils als BLOB zu transportieren. Natürlich separat von den VSDM-Daten. Und für ein FHIR- mapping dieser eGK-Daten sollten wir uns m. E. mit diversen Beteiligten jedenfalls abstimmen. vgl. KBV-Schnittstelle für Verordnungssoftware und UKF-Spezifikation.

Stefan Lang (Sep 06 2019 at 15:59):

Richtig.

Der Medikationsplan (UKF) ist in der KBV-Verordnungsschnittstelle in DocumentReference profiliert (Profil https://fhir.kbv.de/StructureDefinition/74_PR_VoS_DokuRef ).
Das ganze direkt eingebettet in content.attachment.data und zwar ggf. sogar innerhalb einer DocumentReference der Medikationsplan sowohl als XML (aka UKF) als auch als PDF (2 content-Elemente).
Dies ganz im Sinn der FHIR-Spec: zu DocumentReference.content: "The document and format referenced. There may be multiple content element repetitions, each with a different format."

Simone Heckmann (Sep 06 2019 at 16:02):

Hier mal grob eine Idee, wie ein "Original"-Datensatz als DocumentReference aussehen könnte:

<DocumentReference xmlns="http://hl7.org/fhir">
  <status value="current"/>
  <!--DocType TBD-->
  <type>
    <coding>
        <system value="tbd"/>
        <code value="VSDM"/>
    </coding>
  </type>
  <subject>
    <!-- die Patientendaten können aus dem VSDM-Datensatz extrahiert worden sein-->
    <reference value="Patient/1234"/>
  </subject>
  <!--Einlesedatum-->
  <date value="2019-09-06"/>
  <description value="VSDM-Datensatz"/>
  <content>
    <attachment>
      <contentType value="application/xml"/>
      <!--hier Base64-codiert der Datensatz-->
      <data value="A64FCB746CFA6746B..."/>
    </attachment>
  </content>
  <related>
    <!--link auf Coverage, die aus VSDM-Daten erzeugt wurde-->
    <reference value="Coverage/5432"/>
  </related>
</DocumentReference>

Die Suche nach dem EGK-Datensatz zu Patient 1234 könnte dann mit
.../DocumentReference?subject:Patient._id=1234&type=VSDM erfolgen.

Christof Gessner (Sep 06 2019 at 16:07):

warum nicht die FHIR resources, die der eMP repräsentieren möchte?

Simone Heckmann (Sep 06 2019 at 16:20):

Versteh' die Frage nicht...

Christof Gessner (Sep 06 2019 at 16:24):

UKF war mal als komprimierte Repräsentation von FHIR gedacht. Falls man die Kompression nicht mehr braucht, würde man vielleicht FHIR verbatim speichern. Würde man sowas dann auch in dieser Form als DocumentReference übertragen wollen?

Simone Heckmann (Sep 06 2019 at 16:26):

Nein, DocumentReference nur, wenn man die Original-Daten zusätzlich oder anstelle der gemappten Informationen benötigt...

Stefan Lang (Sep 06 2019 at 16:26):

@Christof Gessner Entsprechende Einzelprofile in Äquivalenz zum BMP gibt es in VoS auch.
Das DokRef-Profil ist dazu gedacht den fertig gerenderten MP (PDF) oder/und eben 1:1 das darauf abzulegende strukturiererte XML (=UKF) zu übermitteln.

Simone Heckmann (Sep 06 2019 at 16:28):

Das Mapping ist halt viel entspannter, wenn man nicht jede - für den jeweiligen UseCase noch so irrelevante - Information aus den Originaldaten in eine FHIR-Ressource/-Extension pressen muss, nur um den vollständigen Original-Datensatz wiederherstellen zu können...

Stefan Lang (Sep 06 2019 at 16:28):

@Simone Heckmann Genau.
In diesem Fall ist es das Verordnungssystem (FHIR-Client), das die Daten hat und auch den MP generiert und das PVS (FHIR-Server), das genau dies eben nicht kann (bzw. können muss) und ggf. einfach nur als Dokumentenmanagementsystem für Medikationspläne in PDF und/oder XML agiert.

Simone Heckmann (Sep 06 2019 at 16:32):

Mir treibt nur gerade die Überlegung um, ob man sich die Liste der Dokumente zu einem Patienten dann nicht mit menschen-unlesbaren und für den Anwender irrelevanten Datensätzen zuspammt. :thinking:
Leider haben wir kein Flag, um ein Dokument als "nicht zum Konsum geeignet" zu flaggen. Müsste man also anhand des Dokumenttyps in der UI sinnvoll sortieren...

Stefan Lang (Sep 06 2019 at 16:34):

Einen ersten Hinweis liefert natürlich der contentType.
Für ein XML (wie den UKF) bräuchte es ein StyleSheet.
Weitere Infos zur Differenzierung könnten nach content.format passen

Simone Heckmann (Sep 06 2019 at 16:35):

Wenn man übrigens sowohl mappt als auch das Original als DocumentReference speichert, und man sich ein Fleiß-Sternchen verdienen möchte, dann könnte man eine Provenance-Ressource erstellen, die die gemappten Ressourcen als target verlinkt und die DocumentReference als entity mit der Rolle source und damit nachvollziehbar macht, welche Informationen aus dem eGK-Datensatz extrahiert wurden.
...aber das macht später alles die FHIR Mapping-Engine für uns, stimmt's @Alexander Zautke ;-)

Alexander Zautke (Sep 06 2019 at 17:04):

(deleted)

Alexander Zautke (Sep 06 2019 at 17:04):

This is left as an exercise to the reader ;D Ich möchte ja nicht der einzige bleiben der diese Sprache kann...

Christof Gessner (Sep 06 2019 at 17:23):

Ich meine, dass ich in der VoS spec eine recht ausdifferenzierte XML oder JSON Struktur für das eRezept gesehen habe, für den eMP aber nicht. Bloß daher meine Verwunderung...

Frank Oemig (Sep 09 2019 at 09:20):

haben wir dann 2 parallele Varianten wie in v2? Dann kann man wählen...

Simone Heckmann (Sep 16 2019 at 14:45):

Ich würde die Diskussion gerne mal im Hinblick auf die AWS-Spec der KBV lenken:
Ist es dort zwingend erforderlich, die Zusatzinformationen in die Coverage-Extensions zu mappen? Die Funktionalität Import/Export könnte man auch mit dem Original-Datensatz erzielen. Die Frage wäre, wie diese Daten in den PVSsen vorgehalten werden. Werden diese dort in die eigene DB-Struktur gemappt und der VSDM-Datensatz müsste erst wiederhergestellt werden (was auch nicht mehr oder weniger komplex wäre als die FHIR-Resource zu erstellen) oder speichern PVS-System das Originalformat?

Christof Gessner (Apr 09 2021 at 09:38):

Auf der Rückseite der deutschen eGK sind die EHIC-Daten aufgedruckt. Hat hierzu schonmal jemand was in FHIR erstellt?
Falls ja: bitte melden bei https://chat.fhir.org/#narrow/stream/242580-europe/topic/EHIC.20.2B.20FHIR

image.png

Last updated: Apr 12 2022 at 19:14 UTC