# C_12708_Anlage

Motivation:

Zur Befüllung des Exportpakets wird für Ressourcen des Medication Service eine Reihenfolge vorgegeben. Durch diese Maßnahme soll sichergestellt sein, dass referenzierte Ressourcen im Paket vor den referenzierenden Ressouren angeordnet sind und eine Validierung der Ressourcereferenzen bei einem Import erleichtern.
Aufgrund von Anpassungen des Informationsmodell des Medication Service für den dgMP können jetzt zulässige zyklische Referenzen entstehen, die durch die Einhaltung einer Reihenfolge im Exportpaket nicht mehr aufgelöst werden können, so dass eine übergreifendere Methode zur Validierung von Referenzen erforderlich wird.
Die Vorgaben zur Befüllung des Exportpakets in einer bestimmten Reihenfolge werden dazu korrigiert.

Änderungen im Dokument: Healthrecord relocation export package.adoc

Kapitel 1.1.3 Medication

alt:

Innerhalb dieses Verzeichnisses werden alle Daten des Medical Service 'medication' abgelegt.

Jede FHIR-Ressource wird dabei im Format JSON als jeweils eine Datei abgelegt. Dateien versionierbarer Ressourcen verwenden dafür vollständige History-Bundle mit allen Versionen. Der Dateiname ist M_nnnnnn.json mit 'nnnnnn' aus der Menge {000000, 999999}, beginnend mit 'nnnnnn' = 000000 und fortlaufender Zählung.

Die jeweils enthaltene FHIR-Ressource einer Datei ist innerhalb der JSON Struktur über das Attribut "resourceType" identifizerbar, das spezifische Profil der Ressource über das Attribut "meta.profile".

Die exportierbaren FHIR-Ressourcen verwenden teilweise Referenzen auf weitere Ressourcen ("reference"). Zur Vermeidung nicht auflösbarer Referenzen bei einem Import des Exportpakets werden die Ressourcen in der vorgegebenen Reihenfolge angeordnet, so dass referenzierte Ressourcen vor dem Import von Ressourcen mit Referenzen schon bekannt sind.

Zusätzlich müssen bei der Migration alle Versionen der FHIR-Instanzen berücksichtigt werden. Dabei ist sicherzustellen, dass die Resource.id über alle Versionen hinweg konstant bleibt, während die Attribute Resource.meta.versionId und Resource.meta.lastUpdated in jede Version korrekt übernommen werden. Es muss gewährleistet sein, dass bei der Migration nur die jeweils aktuellste FHIR-Instanz mit der höchsten Resource.meta.versionId über die Standard-Query-API abrufbar ist. Frühere Versionen der Instanzen dürfen nicht direkt über die Standard-Query-API abgerufen werden, sondern sind über die URL-Struktur [base]/[resourceType]/[id]/_history/[versionId] zugänglich. Diese Versionsverwaltung ermöglicht es, auch auf ältere FHIR-Instanzen zurückzugreifen, ohne die Konsistenz der aktuellen Daten zu beeinträchtigen.

Die Ressourcenreihenfolge im Exportpaket ergibt sich zu:

1. Organization
2. Practitioner
3. PractitionerRole (enthält Referenzen auf Organization und Practitioner)
4. Medication
5. MedicationRequest (enthält Referenzen auf Medication und PractitionerRole)
6. MedicationDispense (enthält Referenzen auf Medication und Organization)
7. MedicationStatement (enthält Referenzen auf Medication, Organization, PractitionerRole, Practitioner)
8. Provenance (enthält Referenzen auf MedicationRequest, MedicationStatement, Organization, PractitionerRole, Practitioner)

Bei einem Import sollen die einzelnen Dateien gemäß der Dateinummerierung, startend bei M_000000.json, verarbeitet werden. D.h.: Alle Nummerierungen der Dateien mit Ressourcen des Typs 'Organization' sind kleiner als jede Nummerierung der Dateien mit Ressourcen des Typs 'Practitioner' und alle Nummerierungen zu 'Practitioner' sind kleiner als jede Nummerierung zu 'PractitionerRole'.

Beispiel: Inhalt M_123456.json (Resource: MedicationRequest gemäß Profil EMPMedicationRequest mit allen Versionen in einem Bundle)

neu:

Innerhalb dieses Verzeichnisses werden alle Daten des Medical Service 'medication' abgelegt.

Jede FHIR-Ressource wird im Format JSON als jeweils eine Datei abgelegt. Der Dateiname ist M_nnnnnn.json mit 'nnnnnn' aus der Menge {000000, ..., 999999}, beginnend mit 'nnnnnn' = 000000 und fortlaufender Zählung.

Die jeweils enthaltene FHIR-Ressource einer Datei ist innerhalb der JSON Struktur über das Attribut "resourceType" identifizerbar, das spezifische Profil der Ressource über das Attribut "meta.profile".

Versionierbare Ressourcen verwenden vollständige History-Bundle mit allen Versionen pro Datei. Die Resource.id muss dabei über alle Versionen hinweg konstant bleiben, die Attribute Resource.meta.versionId und Resource.meta.lastUpdated werden pro Version übernommen. Nach einem Import aller Versionen darf nur die jeweils aktuellste Version mit der höchsten Resource.meta.versionId über die Standard-Query-Api abrufbar sein. Alle älteren Versionen müssen dagegen über die URL [base]/[resourceType]/[id]/_history/[versionId] zugänglich sein.

Einige FHIR-Ressourcen verwenden Referenzen auf weitere FHIR-Ressourcen, welche (alle) nach einem erfolgreichen Import aller FHIR-Ressourcen auflösbar sein müssen.

Für

Bei einem Import eines Pakets müssen die Referenzen geprüft werden. Dabei können auch zyklische Referenzen zwischen FHIR-Ressourcen des Pakets vorhanden sein, welche nicht direkt, sondern erst bei Vorliegen aller FHIR-Ressourcen des Pakets validiert werden können.

Verbleiben nach der Verarbeitung des vollständigen Exportpakets dennoch offene, nicht aufgelöste Referenzen auf FHIR-Ressourcen, so ist der Import der Daten in ein Aktenkonto nicht erfolgreich durchführbar und muss abgebrochen werden.

Beispiel: Inhalt M_123456.json (Resource: MedicationRequest gemäß Profil EMPMedicationRequest mit allen Versionen in einem Bundle)