FHIR-spezifische Anforderungen

Abhängige Implementation Guides und Pakete

Dieser Leitfaden ist abhängig von folgenden weiteren Leitfäden oder FHIR-Paketen:

FHIR Server-spezifische Festlegungen

Die folgenden Rahmenbedingungen hinsichtlich der FHIR-Spezifikation sind für den Medication Service festgelegt.

Aufgrund der gesetzlich intendierten, fehlenden Leseberechtigung des E-Rezept-Fachdienstes kann keine FHIR-Ressource Patient in den zu übertragenden FHIR-Ressourcen referenziert werden, sodass lediglich eine Verknüpfung über einen übergebenen KVNR-Identifier eingesetzt wird. Konkret MÜSSEN E-Rezept-Fachdienst sowie Medication Service sicherstellen, dass die FHIR-Elemente MedicationRequest.subject.identifier sowie MedicationDispense.subject.identifier an den von HL7 Deutschland e.V. definierten Datentyp Identifier für Patient gebunden ist.
Das Löschen von Verschreibungsdaten oder Dispensierinformationen innerhalb des E-Rezept-Fachdienstes wird im Medication Service über ein Ändern des Status (d.h. Status = "cancelled") umgesetzt.
Für die FHIR Operations ist es erforderlich, dass eine Referenzierung der Ressourcen innerhalb des Parameters möglich ist.

Eindeutigkeit von FHIR-Ressourcen

Der Medication Service MUSS ausschließlich zeitbasierte Universally Unique IDentifier (UUID) gemäß RFC 4122 für logische IDs (d.h. FHIR-Element Resource.id) verwenden.

De-Duplizierung

Die zentrale De-Duplizierung bei inhaltlich identischen Ressourcen im Medication Service ist von entscheidender Bedeutung, um sowohl den Nutzen als auch die Qualität der Daten im Medication Service zu gewährleisten. Durch den nachstehenden Ansatz wird vermieden, dass ePA-Clients eigene, möglicherweise unterschiedliche Aggregierungsalgorithmen dezentral implementieren, was zu Inkonsistenzen in den Daten des Medication Service führen könnte. Zusätzlich verbessert eine zentrale De-Duplizierung die Verknüpfbarkeit und Integration der vorhandenen FHIR-Ressourcen.

Zur eindeutigen Identifizierung werden im Rahmen einer Verschreibung und ihr zugeordnete Dispensierinformationen die folgenden Identifier erzeugt und den notwendigen FHIR-Ressourcen hinzugefügt:

RxPrescriptionProcessIdentifier: Dieser im Medication Service erzeugte Identifier nach dem Schema (Prescription-ID + "_" + authoredOn[YYYYMMDD]) wird der MedicationRequest-, MedicationDispense- sowie Medication-Ressource hinzugefügt.
EPAMedicationUniqueIdentifier: Dieser im Medication Service erzeugte Identifier an Medication-Ressourcen stellt die Eindeutigkeit anhand von Hashwerten über Pharmazentralnummer (PZN), Wirkstoff oder Freitext sicher. Von der Hashwertbildung ausgenommen sind die FHIR-Elemente id, identifier, meta, amount, batch sowie status (siehe auch Anforderungen an den EPAMedicationUniqueIdentifier).
RxOriginatorProcessIdentifier: Dieser im Medication Service erzeugte Identifier verknüpft jede Prescription-ID mit der ursprünglichen Resource-ID des Erstellungssystems, um eine präzise Nachverfolgung und Koordination der Arzneimitteldaten zu gewährleisten. Die Erstellung erfolgt nach dem Schema Resource-ID + "_" + Prescription-ID

Damit können bei systeminternen Vergleichen in den Geschäftslogiken gleichartige Ressourcen erkannt und verknüpft werden, anstatt sie neu anzulegen. Bei eingestellten medizinischen Daten wird stets der Versicherte per KVNR referenziert. Im Medication Service selbst liegt eine korrespondierende Instanz der FHIR-Ressource Patient vor, sodass bei Abruf von medizinischen Daten eine Auflösung erfolgen kann.

Versionierung

Versionierungsunterstützung

Jede Änderung an einer FHIR-Ressource resultiert in einer neuen Version dieser Ressource, wobei jede Version eine eindeutige Meta.versionId und ein Meta.lastUpdated erhält. Auch eine erstmalig registrierte FHIR-Ressource MUSS der Medication Service mit diesen Metadaten versehen. Dies ermöglicht es, den vollständigen Änderungsverlauf einer Ressource nachzuvollziehen. Der Medication Service ist damit in der Lage, die Historie aller Versionen einer Ressource zu speichern und zugänglich zu machen. Dies schließt das Abrufen früherer Versionen einer Ressource über die FHIR API unter Verwendung der Meta.versionId ein. Bei einer gleichzeitigen Aktualisierung derselben Ressource muss der Medication Service Konflikte erkennen und lösen können.

Bei einer Aktualisierung einer FHIR-Instanz mit denselben Werten DARF der Medication Service NICHT neue Version der Instanz erstellen. Die FHIR-Instanz bleibt bei der aktuellen Version.

HTTP GET-Anfrage

Um eine spezifische Version einer Ressource abzurufen, kann eine einfache HTTP GET-Anfrage an den Medication Service gesendet werden. Die URL für den Abruf einer bestimmten Version einer Ressource folgt diesem allgemeinen Muster:

GET [base]/[resourceType]/[id]/_history/[versionId]

Dabei ist:

resourceType der Typ der Ressource (z.B. Medication, MedicationStatement)
id die eindeutige ID der Ressource
versionId der spezifische Meta.versionId der abzurufenden Ressourcenversion

Beispiel

Um die 3. Version einer MedicationStatement-Instanz mit der ID "391fc0c6-e045-48d9-8af6-3ac2466beb88" vom Medication Service abzurufen, muss die URL für die HTTP GET-Anfrage wie folgt aussehen:

GET [base]/epa/medication/api/v1/fhir/MedicationStatement/391fc0c6-e045-48d9-8af6-3ac2466beb88/_history/3

Versionierte Referenzen

Versionierte Referenzen in FHIR ermöglichen es, innerhalb einer FHIR-Ressource auf eine spezifische Version einer anderen Ressource zu verweisen. Dies ist besonders wichtig in Szenarien, in denen die Genauigkeit und der Kontext der bezogenen Daten über die Zeit erhalten bleiben müssen, wie zum Beispiel bei der Verifizierung einer Medikationsplanung.

In FHIR kann eine Referenz auf eine andere Ressource in der Regel durch die Angabe des Ressourcentyps und der ID erfolgen. Versionierte Referenzen erweitern dieses Konzept, indem sie es ermöglichen, zusätzlich die Version der referenzierten Ressource anzugeben. Dies stellt sicher, dass immer auf den exakten Zustand der referenzierten Ressource zum Zeitpunkt der Referenzerstellung Bezug genommen wird, unabhängig von späteren Änderungen oder Aktualisierungen dieser Ressource.

Eine versionierte Referenz in FHIR beinhaltet den Ressourcentyp, die Ressourcen-ID und die spezifische Meta.versionId der referenzierten Ressource. Das Format sieht wie folgt aus:

[resourceType]/[id]/_history/[versionId]

Beispiel für eine versionierte Referenz auf eine spezifische Version einer MedicationStatement-Instanz:

MedicationStatement/391fc0c6-e045-48d9-8af6-3ac2466beb88/_history/4

In diesem Beispiel bezieht sich die Referenz auf die 4. Version der MedicationStatement-Instanz mit der ID "391fc0c6-e045-48d9-8af6-3ac2466beb88".

Löschen als Versionierungsergebnis

Im Medication Service wird das Löschen einer Ressource als ein weiteres Ereignis im Lebenszyklus einer Ressource behandelt. Das bedeutet: Anstatt die Ressource physisch zu entfernen, wird die Ressource als gelöscht markiert und eine neue Version der Ressource erstellt, welche diesen Zustand widerspiegelt. Obwohl eine Ressource als gelöscht markiert wurde, können frühere Versionen über die versionsspezifischen Endpunkte (s.o.) abgerufen werden.

Hard Delete

Der Medication Service setzt weiterhin eine Hard-Delete-Funktion um. Ein Hard Delete bezieht sich auf das vollständige und unwiederbringliche Entfernen einer Ressource aus dem Medication Service, ohne dass eine Versionshistorie verbleibt. Diese Funktion MUSS ausschließlich für die Task-Ressource angewendet werden, beispielsweise beim asynchronen Verlinken von Verschreibungsdaten mit Medikationsplanungsdaten.

Persistieren der Profilversion

Beim Erzeugen von FHIR-Ressourcen im Medication Service (üblicherweise als Reaktion auf die Anfrage eines Clients hin) MUSS der Medication Service jede zu speichernde Ressource gegen das dazugehörige aktuelle Profil validieren. Die Information, gegen welches Profil in welcher Version geprüft wurde, MUSS der Medication Service in der jeweiligen Ressource in Meta.profile speichern.

Die Operation API des Medication Service nutzt FHIR-Profile, welche fachlichen Einschränkungen zum aktuellen Anwendungsfall unterliegen. Diese erlauben Entwicklerinnen und Entwickler das direkte Erkennen dieser Einschränkungen z.B. in der logischen Ansicht der Ressourcen als Baumstruktur. Generell speichert der Medication Service jedoch keine Instanzen dieser Profile, sondern diejenigen Profile ohne diese Einschränkungen. Der Hintergrund ist, dass die entsprechenden Profile bzw. deren Instanzen für weitere Anwendungsfälle anderer Versorgungsprozesse nachgenutzt werden. Bei der o.g. Anforderung zum Speichern der Profilversion MUSS das FHIR-Profil ohne den gekennzeichneten Einschränkungen bei den FHIR-Elementen unter Meta.profile durch den Medication Service getaggt werden. Potentiell vorhandene Meta.profile-Angaben als auch Literal References aus Client-Anfragen MUSS der Medication Service beim Erzeugen oder Aktualisieren des Profils für die Datenhaltung verwerfen bzw. darf sie nicht übernehmen.

Rückgabe des EPACapabilityStatementMedication

Der Medication Service MUSS die Funktion GET [base]/epa/medication/api/v1/fhir/metadata implementieren. Diese Funktionalität stellt sicher, dass bei einem Aufruf von /metadata das EPACapabilityStatementMedication des Servers zurückgegeben wird. Dieses Capability Statement bietet eine detaillierte Beschreibung der Fähigkeiten des Medication Service und ist entscheidend für das Verständnis der unterstützten FHIR-Funktionalitäten.

Must-Support

Als Must-Support deklarierte Elemente müssen durch jedes System, welches diese Spezifikation implementiert, unterstützt werden. Das bedeutet, dass das jeweilige System diese interpretieren und verarbeiten können muss. Die Deklarierung als Must-Support wird in der Anzeige der Profile auf Simplifier durch eine rotes "S" gekennzeichnet.

Es dürfen keine medizinisch relevanten Daten in Felder ohne MustSupport geschrieben werden.

Festlegungen für die Medikationsplanung

Umgang mit Code/Bezeichnung beziehungsweise CodeableConcept

Es gibt an vielen Stellen die Möglichkeit ein Konzept, also den Wert eines Elementes, über eine Anzahl von Codes und/oder einem Freitext abzubilden. Dies heißt im Informationsmodell in der Regel Code/Bezeichnung und entspricht in HL7®-FHIR® dem Datentyp CodeableConcept. Dieser kann, vereinfacht gesagt, entweder aus einer textuellen Beschreibung des Konzeptes bestehen (nur Text), der Codierung mithilfe eines in einem Codesystem definiertem Codes mit dazugehörigem Wiedergabename (nur Code/mehrere Codes) oder aber aus einer Kombination aus beidem (Text und Codes). Die Verwendung mehrerer Codes aus unterschiedlichen Codesystemen und eines Freitextes für ein und dasselbe Konzept ist hier explizit erlaubt und je nach Kontext auch fachlich sinnvoll. Hierbei ist nur zu beachten, dass alle Repräsentationen genau dasselbe Konzept abbilden und sich in der Granularität unterscheiden können, jedoch inhaltlich keine andere Bedeutung haben dürfen.

Technisch kann (ohne zugrundeliegendes Mapping) nicht überprüft werden, ob die Unterelemente des Konzeptes (Codes und/oder Text) inhaltlich zusammenpassen. Daher liegt die Verantwortung der Prüfung und gegebenenfalls Anpassung oder Entfernung, dieser Elemente bei der bearbeitenden Person. Technisch können Funktionen des Primärsystems hierbei unterstützen.

Um die Zahl der Fehlzuordnungen möglichst gering zu halten, sollte bei Bearbeitung des Konzeptes oder dazugehörigen Unterelementen ein entsprechender Hinweis an die bearbeitende Person ausgegeben werden.

Beispiele für Mehrfachcodierung

Körpergröße

Die Codierung in LOINC® und SNOMED CT® erhöht in diesem Fall die Interoperabilität der Ressource, da SNOMED CT® und LOINC® vor allem im internationalen Kontext unterschiedlich weit verbreitet sind.

 "code": {
    "coding":  [
        {
            "code": "8302-2",
            "system": "http://loinc.org",
            "version": "2.77",
            "display": "Körpergröße"
        },
        {
            "version": "http://snomed.info/sct/11000274103/version/20240515",
            "code": "1153637007",
            "system": "http://snomed.info/sct",
            "display": "Körpergröße"
        }
    ]
}

Medikationsinformation

Die Codierung in ICD-10-GM ist für den Austausch zwischen behandelnden Personen sinnvoll. Die Codierung in SNOMED CT® ist für den internationalen Austausch sinnvoll. Der Freitext in patientenverständlicher Form ist für Patient:innen sinnvoll.

"reasonCode": [{
  "coding": [
    {
        "system": "http://snomed.info/sct",
        "code": "70422006",
        "display": "Acute subendocardial infarction",
        "version": "http://snomed.info/sct/11000274103/version/20240515"
    },
    {
        "code": "I21.4",
        "system": "http://fhir.de/CodeSystem/bfarm/icd-10-gm",
        "version": "2020",
        "display": "Akuter subendokardialer Myokardinfarkt"
    }
  ],
  "text": "Herzinfarkt"
}]

SNOMED CT® Codes

Alle Editionen von SNOMED CT® haben dieselbe URI (http://snomed.info/sct) zur Identifikation des CodeSystems. Es ist also nicht möglich, die verwendete Edition anhand der hinterlegten URI zu erkennen. Dies bedeutet, dass es technisch möglich ist, einen Code aus einer beliebigen Edition anzugeben, wenn die Verwendung des CodeSystems SNOMED CT® vorgegeben ist. Es kann nicht davon ausgegangen werden, dass empfangende Systeme mit allen Editionen umgehen können. Daher gilt, dass nur SNOMED CT® Codes aus der Germany Edition verwendet werden dürfen. Dies gilt insbesondere an den Stellen, an denen dies nicht schon anderweitig festgelegt ist (z.B. durch Festlegung einer bestimmten Version oder einem required ValueSet mit einer vorgegebenen Version). Dabei sollten die Codes, an den Stellen wo es keine andere Festlegung gibt, aus dem für das Projekt verwendeten Release der Germany Edition genutzt werden.

Verwendung der Referenzdatenbank für Fertigarzneimittel gemäß § 31b SGB V

Die Referenzdatenbank für Fertigarzneimittel gemäß § 31b SGB V stellt Informationen wie Darreichungsform, die Wirkstoffbezeichnung und die Wirkstärke des Arzneimittels in einheitlicher und patientenverständlicher Form zur Verfügung. Sie ist daher eine sinnvolle und begrüßenswerte Datenquelle, um langfristig die einheitliche Dokumentation von Medikationen zu fördern und einen unkomplizierten Austausch zwischen den Systemen zu gewährleisten.

Aktuell sind noch nicht alle Details zur Umsetzung der Datenbank abschließend geklärt. Es kann daher in nachfolgenden Versionen der Spezifikation des ePA Medication Service noch zu Anpassungen kommen, die eine optimierten Abbildung der Informationen aus der Datenbank ermöglichen. Dies betrifft zum Beispiel die eingebundenen ValueSets und Codesysteme.

Handlungsempfehlungen für Codesysteme

In der Spezifikation des ePA Medication Service werden an manchen Stellen mehrere Codesysteme ermöglicht (z.B. bei Medication.code). Eine eindeutige Priorisierung eines bestimmten Codesystems bzw. einer Terminologie ist nicht pauschal möglich. Manche Codesysteme eignen sich inhaltlich besser zur Abbildung bestimmter Informationen, sind aber z.B. aufgrund mangelnder Verbreitung in der Versorgung aktuell schwer umsetzbar. Andere wiederum sind weit verbreitet und daher gut einsetzbar, aber aus medizinisch-fachlicher Perspektive nicht ganz passend oder nicht international nutzbar. Eine Entscheidung welches Codesystem wann anzuwenden ist, ist also immer auch vom Use-Case abhängig und davon welche Codesysteme in diesem Moment zur Verfügung stehen.

Nähere Informationen zu einzelnen Codesystemen finden Sie auch unter: https://www.bfarm.de/DE/Kodiersysteme/_node.html