C_12438_Anlage_V1.0.0
Prereleases:
C_12438_Anlage
Im Zuge von Change C_12517 erfolgt die Verschiebung der Anforderungen zu AuditEvents aus der Spezifikation in den IG Basisfunktionalitäten. Das betrifft auch die folgend dargestellten Änderungen bezüglich A_28413. Eine inhaltliche Änderung erfolgt dabei nicht, jedoch ergeben sich daraus geänderte Ids für die Anforderungen.
Inhaltsverzeichnis
1 Änderungsbeschreibung
Es soll eine Möglichkeit gegeben werden, zwei Aktenzustände derselben Akte zusammenzuführen.
2 Anpassungen gemSpec_Aktensystem
Die Vorgänge HealthRecord Relocation und Health Record Merge nutzen beide das gleiche Exportpaket für den Datenaustausch. Zur Vermeidung doppelter Anforderungen und für eine eindeutige Zuordnung von Anforderungen zu den jeweiligen Vorgängen, wird innerhalb des Kapitel 3.2.Health Record Relocation die Anordnung der schon vorhandenen Anforderungenneu gruppiert und mit ergänzendem Text versehen. Durch die eingefügten Kapitel ändert sich auch die Kapitelnummerierung für das nachfolgende Kapitel 3.2.1 "Ablauf eines Aktenkontoumzugs" im resultierenden Dokument.
Durch die geänderte Anordnung der bisher vorhandenen Anforderungen ändert sich deren Inhalt und Prüfverfahren nicht.
3.2 Health Record Relocation Service
Dieser Service ermöglicht den Transfer der Daten eines Aktenkontos von einem bisherigen Anbieter zu einem neuen Anbieter.
Ein Vorgang zur Übertragung der Daten eines Aktenkontos ist erforderlich für:
- einen Aktenkontoumzug, wenn der Versicherte die Versicherung wechselt und die Information zum generellen Widerspruch gegen die Nutzung der ePA und alle Inhalte eines existierenden Aktenkontos zu einem neuen Anbieter übertragen werden müssen.
- eine Aktenkontozusammenführung, wenn für den Versicherten bei mehr als einem Anbieter ein Aktenkonto vorhanden ist und die Inhalte in einem einzigen Aktenkonto zusammengeführt werden sollen.
Beide Vorgänge sind ähnlich und nutzen jeweils gleiche Schnittstellen und ein Paket gleicher Struktur. Bezüglich der Vor- und Nachbedingungen sowie der Vorgangsdetails weichen diese jedoch von einander ab..
3.2.1 Schnittstellen und Transportpaket
Seitens der Aktensysteme werden für einen Aktenkontoumzug zwei Schnittstellen angeboten: I_Health_Record_Relocation_Service zur Nutzung durch die Anbieter (alt und neu) für den Zugriff auf das Aktenkonto des Versicherten und I_Information_Service_Accounts für die Interaktion der Aktensysteme (alt und neu) untereinander. Die notwendige Kommunikation der Kassen-Backends mit ihren Aktensystemen außerhalb der VAU erfolgt dabei in Absprache der Beteiligten und ist nicht Bestandteil der genannten Schnittstellen.
Um eine Durchmischung der Vorgänge auszuschließen, verwendet jeder Vorgang jeweils eigene Operationen der Schnittstellen. Die Erstellung und Kodierung des Transportpakets (Exportpaket, bzw. Mergepaket) ist für beide Vorgänge identisch.
einfügen der Anforderungen (und assozierter Hinweise und Begleittexte):
A_24786 - Health Record Relocation Service - Realisierung der Schnittstelle I_Health_Record_Relocation_Service
A_25005-04 - Health Record Relocation Service - Daten des Exportpakets
A_25605 - Health_Record_Relocation_Service - Erstellung des Exportpakets
A_25012 - Health Record Relocation Service - Signatur der Befugnisse
A_25719 - Health Record Relocation Service - JWT der Befugnis im Exportpaket
A_24787-01 - Health Record Relocation Service - Verschlüsselung des Exportpaktes
A_24942 - Health Record Relocation Service – Prüfung Provider ENC Zertifikat
A_21750 - Health Record Relocation Service – Integritätsschutz Exportpake
A_15051 - Health Record Relocation Service - Authentisierung gegenüber einem neuen Aktenanbiete
A_15048 - Health Record Relocation Service - Authentifizierung des neuen Aktenanbieters
A_17236 - Health Record Relocation Service - Prüfung der TLS-Zertifikate
3.2.2 Aktenkontoumzug (Health Record Relocation)
Transfer eines Aktenkontos zu einem neuen Anbieter (Aktenkontoumzug).
Wechselt der Versicherte den Kostenträger bzw. den Anbieter seines Aktenkontos, so erfolgt der Umzug der Inhalte seines bestehenden Aktenkontos vom bisherigen Anbieter zu einem neuen Anbieter weitestgehend automatisiert.
einfügen der Anforderungen (und assozierter Hinweise und Begleittexte):
A_24821 - Health Record Relocation Service - Suspendierung des Aktenkontos
A_24827 - Health Record Relocation Service - Reaktivierung des Aktenkonto
A_15703 - Health Record Relocation Service - Verfügbarkeit Export-Paket
A_21239 - Health Record Relocation Service – Verhalten bei Nichtabholen des Exportpakets
A_14905-04 - Health Record Relocation Service – Import des Exportpakets des vorhergehenden Aktenkontos
A_28045 - Health Record Relocation Service - Übernahme von Widersprüchen
A_27616 - Health Record Relocation Service - Abbruch des Imports eines Exportpakets
A_21548-02 - Health Record Relocation Service - Information der Vertreter über neuen FQDN nach Abschluss des Anbieterwechsel
A_26257 - Health Record Relocation Service - Löschen der im Exportpaket enthaltenen E-Mail-Adressen der Vertrete
A_24788 - Health Record Relocation Service - Löschen des Exportpakets nach Umzug des Aktenkontos
A_24982-02 - Health Record Relocation Service – Protokollierung des Anbieterwechsels eines Aktenkontos
3.2.3 Aktenkontozusammenführung (Health Record Merge)
Transfer der Daten eines Aktenkontos und Integration in ein existierendes Aktenkonto des gleichen Versicherten bei einem neuen Anbieter.
A_28412 - Health Record Relocation Service - Regeln für eine Zusammenführung
Der Health Record Relocation Service des neuen (importierenden) Aktensystems MUSS bei der Operation startPackageMergeImport für Objekte obj_export im zu importierenden Export-Paket die folgenden Regeln umsetzen:
| Daten im Exportpaket | Regel für die Zusammenführung |
|---|---|
| XDS Document Service
obj_export = Replace-Kette bestehend aus 1...n Dokumenten (n>= 1) obj_export[1] bezeichnet das aktuellste Dokument der Kette |
Bemerkung; ein Dokument obj ist im Aktensystem vorhanden, falls es ein Dokument obj' im Aktensystem mit selber entryUUID, uniqueID oder selbem Hash-Wert gibt.
wenn im importierenden AS kein Dokument von obj_export vorhanden ist, dann ergänze obj_export wenn im importierenden AS mindestens ein Dokument von obj_export vorhanden ist und das aktuellste Dokument obj_export[1] ist nicht vorhanden, dann ergänze obj_export[1] und verwerfe den Rest der Kette obj_export[2..n], sonst verwerfe obj_export |
| XDS Document Service
obj_export = Unique-Dokument (z.B. NFD, DPE) |
wenn im importierenden AS das Unique-Dokument obj_export nicht vorhanden ist, dann ergänze obj_export
sonst verwerfe obj_export |
| XDS Document Service
obj_export = dynamischer Folder |
Bemerkung; ein Folder obj ist im Aktensystem vorhanden, falls es einen Folder obj' im Aktensystem mit dem selbem Foldertitel gibt.
wenn im importierenden AS der Folder obj_export nicht vorhanden ist, dann
1. ergänze obj_export und
2. generiere für obj_export eine neue entryUUID bzw. neue uniqueId, falls die entryUUID bzw. uniqeId von obj_export bereits im importierenden AS existieren.
wenn im importierenden AS der Folder obj_export vorhanden ist und SubmissionSet.submissionTime von obj_export älter als das SubmissionSet.submissionTime des vorhandenen Folders ist, dann übernimm SubmissionSet.submissionTime von obj_export für den vorhandenen Folder sonst verwerfe obj_export |
| XDS Document Service
obj_export = Anhangs-Graph bestehend aus 1...n Dokumenten (n>= 1) |
wenn im importierenden AS kein Dokument von obj_export vorhanden ist, dann ergänze obj_export
wenn im importierenden AS mindestens ein Dokument von obj_export vorhanden ist, dann
|
| Medication Service
obj_export = FHIR-Datum |
wenn obj_export im importierenden AS nicht vorhanden ist, dann ergänze obj_export, sonst verwerfe obj_export |
| Patient Service
obj_export = FHIR-Datum |
Es erfolgt keine Zusammenführung durch das Aktensystem. |
| Consent Decision Management
obj_export = Widerspruch |
wenn das importierende AS die Art des Widerspruchs unterstützt, und
Änderungsdatum von obj_export aktueller als Änderungsdatum des korrespondierenden existierenden Objekts im AS ist, dann füge obj_export hinzu, sonst verwerfe obj_export Hinweis: obj_export wird verworfen, wenn das Änderungsdatum von obj_export im importierenden AS nicht ermittelt werden kann. |
| Entitlement Management
obj_export = Eintrag auf der Blocked User Policy |
wenn obj_export im importierenden AS nicht vorhanden ist, dann ergänze obj_export und lösche eine ggf. vorhandene Befugnis für die in obj_export identifzierte LEI,
sonst verwerfe obj_export |
| Entitlement Management
obj_export = Befugnis |
wenn obj_export = Vertreter-Befugnis und obj_export im importierenden AS nicht vorhanden ist, dann ergänze obj_export,
sonst verwerfe obj_export |
| Constraint Management
obj_export = Eintrag in General Deny Policy |
wenn obj_export im importierenden AS nicht vorhanden ist (nach Import aller Dokumente aus dem Export-Paket) und das in obj_export referenzierte Objekt im importierenden AS vorhanden ist, dann ergänze obj_export,
sonst verwerfe obj_export |
| Audit Event Service
obj_export = Protokolleintrag |
wenn obj_export im importierenden AS nicht vorhanden ist, dann ergänze obj_export mit folgender Erweiterung in entyity.detail mit entity.detail.type="System-Zusammenführung" und entity.detail.value[x] = true,
sonst verwerfe obj_export |
| E-Mail Management
obj_export = E-Mail-Adresse |
Es erfolgt keine Zusammenführung durch das Aktensystem.
|
! Änderung nach Vorstellung im ePA Bi-Weekly !
(neue ID im IG Basisfunktionalitäten: IG-EPA89078Y44)
A_28413 - Health Record Relocation Service – Protokollierung der Zusammenführung bei Konfliktpotential
Der Health Record Relocation Service des neuen (importierenden) Aktensystems MUSS bei der Operation startPackageMergeImport jedes Hinzufügen eines Objekts zum Aktensystem entsprechend der Protokollierungsregeln für das Objekt protokollieren, wobei für agent.type und source.type "HRRSVC" (Health Record Relocation Service), für entity.name= "SystemMerge" und für entity.description="startPackageMergeImport" zu nutzen ist. <= [<=]
A_28414 - ePA-Aktensystem – Information des Versicherten über Zusammenführung durch Anbieter
Der Anbieter des ePA-Aktensystems MUSS den Versicherten über eine anstehende Zusammenführung seiner Akte informieren, sofern durch die Zusammenführung ein Zustand der Akte enstehen könnte, den der Versicherte überprüfen sollte. [<=]
Hinweis zu A_28414-*: In der Kommunikation mit den Versicherten kann der Anbieter eine eigene Sprachregelung wählen, es muss gegenüber dem Versicherten nicht von einer "Zusammenführung" gesprochen werden.
A_28415 - Health Record Relocation Service – Information des Versicherten über Zusammenführung per Mail
Falls der Versicherte eine E-Mail-Adresse im neuen (importierenden) Aktensystem hinterlegt hat oder eine E-Mail-Adresse des Versicherten im Export-Paket vorhanden ist, MUSS der Health Record Relocation Service bei der Operation startPackageMergeImport eine E-Mail an alle bekannten E-Mail-Adressen des Versicherten mit folgenden Hinweisen senden:
- Information über die Tatsache der Zusammenführung,
- ggf. Information, dass sich durch die Zusammenführung Daten oder Einstellungen in der Akte geändert haben und diese Änderungen in den Protokollen nachvollzogen werden können,
- ggf. könnten Protokolle durch die Zusammenführung inkonistent wirken.
Anpassungen in Kapitel 3.22.1 Übersicht der Schnittstellen des Aktensystems:
| I_Health_Record_Relocation_Service | |
| Schnittstelle zur Steuerung des eines Aktenkontoumzugs oder einer Aktenkontozusammenführung aus der Umgebung des Kostenträgers | |
| startPackageCreation | Diese Operation initiiert die Erstellung eines Export Pakets für den Umzug eines Aktenkontos zu einem neuen Anbieter. |
| startPackageImport | Diese Operation initiiert den Import eines Export Pakets in ein neu erstelltes Aktenkonto. |
| startPackageCreationForMerge | Diese Operation initiiert die Erstellung eines Merge Pakets für eine Aktenkontozusammenführung. |
| startPackageMergeImport | Diese Operation initiiert den Import eines Merge Pakets in ein existierendes Aktenkonto. |
| I_Information_Service_Accounts | |
| Schnittstelle des Information Service gemäß [I_Information_Service_Accounts] für Anbieter Aktensystem im Kontext eines Aktenkontoumzugs oder einer Aktenkontozusammenführung. | |
| getGeneralConsentDecision
|
Diese Operation dient der Abfrage eines Widerspruchs gegen die Nutzung der ePA bei einem anderen Aktensystemanbieter. |
| startRelocation
|
Diese Operation initiiert die Erstellung eines Export Pakets für die Relocation. |
| deleteExportPackage
|
Diese Operation schließt den Vorgang der Relocation erfolgreich ab. |
| postExportPackageIncident
|
Diese Operation erhält Benachrichtigungen zum Relocation-Prozess. |
| putDownloadUrlForExportPackage
|
Diese Operation initiiert den Import eines Export Packages. |
| postPackageDeliveryIncident
|
Diese Operation erhält Benachrichtigungen zum Relocation-Prozess. |
| startMerge | Diese Operation initiiert die Erstellung eines Merge Pakets für einen Merge-Prozess. |
| finalizeMerge | Diese Operation schließt eine Merge-Prozess erfolgreich ab. |
| postMergePackageIncident | Diese Operation erhält Benachrichtigungen zum Merge-Prozess. |
| putDownloadUrlForMergePackage | Diese Operation initiiert den Import eines Merge Packages. |
| postMergePackageDeliveryIncident | Diese Operation erhält Benachrichtigungen zum Merge-Prozess. |
| getProviderList | Diese Operation gibt eine Liste von FQDNs der Versicherungen / ePA-Anbieter aus |
3 Anpassungen gemSpec_ePA-FdV
Neu in Kapitel 6.2.9 Protokollverwaltung
A_28416 - ePA-Frontend des Versicherten – Filtern nach Zusammenführung
Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die Protokolldaten bei der Anzeige nach Protokolleinträgen einer Zusammenführung zu filtern. [<=]
4 Anpassung IG für Audit Event Service
Ergänzung ValueSet: EPA AuditEvent Service Type um den Code "SYSTEMMERGE":
| Code | System | Display | Display (Deutsch) |
| SYSTEMMERGE | https://gematik.de/fhir/epa/CodeSystem/epa-auditevent-sourcetype-cs | Record Merge | Record Merge |
Damit die Einträge im ePA-FdV dediziert angezeigt werden können, wird auch der Suchparameter source.type ergänzt.
5 Anpassung der openAPI
Ergänzung zu I_Health_Record_Relocation_Service:
Neue Operation für den Merge eines Exportpakets:
/relocationservice/v1/export/merge:
parameters:
- $ref: '#/components/parameters/insurantid'
- $ref: '#/components/parameters/useragent'
- $ref: '#/components/parameters/x-requestid'
get:
tags:
- Content merge
operationId: startPackageCreationForMerge
summary: (startPackageCreationForMerge) Create an export package of health record for download
externalDocs:
description: 'Reference implemenation for Health Record Migration'
url: https://github.com/gematik/ref-ePA-HealthRecordMigration
description: |
This operation creates an export package including all data of
the health record for relocation to another health record provider.</br>
A created export package equals a _startPackageCreation_ outcome and considers the same data for
export but it is not part of the regular health record relocation process and can be used by the insurance
when necessary.</br>
This operation is limited to entitled users of role oid_kostentraeger.
**Client**:</br>
A client shall use this operation to create an export package for a merge import to an
existing health record hosted by another provider.
**Provider**:</br>
The export package shall be encrypted and stored for later download and contain all transferable
data of all health record services. The export package download url shall
be returned in the response.
The certificate (of the receiving health record system) for encryption is a preinstalled
certificate and shall be retrieved from HSM by rule 'hsm-r7'. This certifcate shall be
validated before use.
The format and encryption requirements are stated in an additional repository (see: 'find more details' below)
The operation shall not cause a state change and can only be called while in state INACCESSIBLE with sole reason 'ready for merge'.
| Conditions | Status code | Error code | Remarks |
|------------|-------------|------------|---------|
| Successful operation | 201 |||
| Request does not match schema | 400 | malformedRequest ||
| Requestor has no valid entitlement | 403 | notEntitled ||
| Requestor role is not _oid_kostentraeger__ | 403 | invalidOid ||
| Invalid certificate provided | 403 | invalCert | the certificate from HSM (hsm-r7) |
| Health record does not exist (UNKNOWN) or is in state INITIALIZED | 404 | noHealthRecord | |
| Health record is not in state INACCESSIBLE with sole reason 'ready for merge' | 409 | statusMismatch |
also if state is INACCESSIBLE with another or additional reason than 'prepared for a merge' |
| Any other error | 500 | internalError | (see 'Retry interval') |
</br>
| Postconditions | Remarks |
|---------------------------------------|---------|
| Export package is created| |#
responses:
'201':
description: Ok.
headers:
X-Request-ID:
$ref: '#/components/headers/requestid'
content:
application/json:
example:
downloadurl: 'http://example.com'
schema:
type: object
properties:
downloadurl:
$ref: '#/components/schemas/UrlType'
required:
- downloadurl
+++ Standardfehler (in der yaml enthalten)
-------------------
Neue Operation für den Abruf eines Exportpakets außerhalb einer Relocation:
/relocationservice/v1/import/merge:
parameters:
- $ref: '#/components/parameters/insurantid'
- $ref: '#/components/parameters/useragent'
- $ref: '#/components/parameters/x-requestid'
post:
tags:
- Content merge
operationId: startPackageMergeImport
summary: (startPackageMergeImport) Import an export package and merge content with existing data of a health record
description: |
Start the import of an encrypted export package for data migration from another health record provider.</br>
This operation is similar to _startPackageImport_ but is not limited to new and empty health records and allows
integration of the imported data into an existing health record with data.</br>
This operation is not part of the regular health record relocation process and can be used by the insurance
when necessary.
This operation is limited to entitled users of role oid_kostentraeger.
**Client**:</br>
A client shall use this operation with a url for export package download. A client receives this url
by proprietary means.
**Provider**:</br>
Download the complete export package from the download point. Decrypt the package (rule 'hsm-r5') and
integrate the content into the existing health record data.
The rules how to merge incoming and existing data are stated in requirement A_28412-*
and shall be applied.
The merge of data shall be possible in state ACTIVATED only.
Any occuring error shall abort the data merge process and remove all already merged data completely
(roll back).
Entitlements contained in the export package combine a jwt and additional data.</br>
If an entitlement as part of the export package shall be merged into the current data than
the jwt of the entitlement shall be converted to a CMAC secured entitlement using HSM rule 'rr5'.
The CMAC secured result shall then be completed with the additional data from the export package entitlement element:
- _oid_ of the entitled user
- _displayName_ of the entitled user
- _issued-at_ original point in time
- _issued-actorId_ of requestor
- _issued-displayName_ of requestor
The completed entitlement shall then be stored, encrypted by SecureAdminStorageKey of the health record.</br>
Audit events for the merge process events shall be created according to requirement A_28413-*.
The search index for MHD Service shall be rebuild to reflect the merged changes.
If previously unknown email addresses of representatives are added by the merge operation, a notification
mail shall be sent to each of these representatives, including the information about the changed FQDN.
| Conditions | Status code | Error code | Remarks |
|------------|-------------|------------|---------|
| Successful operation | 204 |||
| Request does not match schema | 400 | malformedRequest ||
| Requestor has no valid entitlement | 403 | notEntitled ||
| Requestor role is not _oid_kostentraeger_ | 403 | invalidOid ||
| Health record does not exist | 404 | noHealthRecord | _insurantid_ unknown |
| Health record is not in state ACTIVATED | 409 | statusMismatch ||
| Any other error | 500 | internalError | (see 'Retry interval') |
</br>
| Postconditions | Remarks |
|---------------------------------------|---------|
| Export package data is merged ||
| Log-entries exist | |
| Notification for representatives are sent | succesful operation and new representatives only|
requestBody:
required: true
content:
application/json:
example:
downloadurl: 'http://example.com'
schema:
type: object
properties:
downloadurl:
$ref: '#/components/schemas/UrlType'
required:
- downloadurl
+++ Standardfehler (in der yaml enthalten)