C_12501_Anlage

Änderungen in gemSpec_Aktensystem_ePAfueralle

Änderung in Kapitel 3.2.1.1 Initialisierung des Aktenkontos bei einem neuen Anbieter

Der Anbieter (neu) lässt im Aktensystem (neu) ein neues Aktenkonto anlegen. Dieses erhält den Status INITIALIZED. Hierfür gelten die Anforderungen gemäß 3.1.3 Anlage eines neuen Aktenkontos.

Falls der Versicherte schon einen Widerspruch gegen die Nutzung der ePA bei seinem bisherigen Kostenträger erklärt hat, kann die Initialisierung eines neuen Aktenkontos ggf. entfallen. Ein Transfer, bzw. die Erstellung eines Exportpakets, ist in diesem Fall mangels eines existierenden Aktenkontos beim bisherigen Anbieter nicht erforderlich.

Die Abfrage eines existierenden Widerspruchs des Versicherten bei einem anderen Anbieter ePA-Aktensystem erfolgt über dessen Information Service.

Wenn bei einem Anbieter (neu) in dessen Aktensystem ein neues Aktenkonto für einen Versicherten angelegt werden soll, erfolgt bei allen weiteren Aktensystemen die Abfrage der dort eventuell vorhandenen Widerspruchsinformation gegen die Nutzung der ePA.

Als Ergebnis der Abfrage ergibt sich, dass ein Versicherter bei anderen Aktensystemen

• nicht bekannt ist, oder
• ein Widerspruch gegen die Nutzung der ePA vorliegt, oder
• ein Aktenkonto vorhanden sein kann

Ein Aktenkonto (neu) kann nur dann angelegt und für die Aktivierung vorbereitet werden, wenn die abgefragte Information eindeutig ist. Gegebenenfalls widersprüchliche Informationen erfordern dazu zunächst einer Klärung und Korrektur durch die verantwortlichen Beteiligten.

Abfrage eines existierenden Widerspruchs gegen die Nutzung der ePA Abfrage der Information zum Widerspruch des Versicherten gegen die Nutzung der ePA
I_Information_Service_Accounts (bisheriges Aktensystem)
getGeneralConsentDecision	Abfrage des ggf. schon erteilten Widerspruchs gegen die Nutzung der ePA durch den Versicherten

Änderung in Kapitel 3.2.1.2 Start Transfer eines existierenden Aktenkontos

Hat der Versicherte bei keinem Anbieter einen Widerspruch gegen die Nutzung der ePA erklärt und existiert bei einem bisherigen Anbieter (alt) ein Aktenkonto, wird der Transfer der Daten durch das Aktensystem (neu) initiiert.

Auf Basis der Ergebnisse der Operation getGeneralConsentDecision wird der Transfer der Daten durch das Aktensystem (neu) initiiert

Wenn bei einem anderen Anbieter ein Aktenkonto des Versicherten vorhanden sein kann, dann muss der Transfer der Daten dieses Aktenkontos zum neuen Anbieter vor der Aktivierung des neuen Aktenkontos erfolgen. Die folgende Operation startet den Prozess des Aktenumzugs beim bisherigen Anbieter und veranlasst die Erstellung eines Exportpakets mit den Daten des Aktenkontos

Das Aktensystem (alt), bei welchem das Aktenkonto existiert, bestätigt diese Anfrage zum Transfer mit einer Vorgangs-ID.

Starten des Transfers
I_Information_Service_Accounts (bisheriges Aktensystem)
startRelocation	initiieren der Exportpaketerstellung

Änderung in Kapitel 3.2.1.6 Abschluss des Transfers durch beide Anbieter

Das Aktensystem (neu) startet den Download des Exportpakets, entschlüsselt dieses und übernimmt die Daten in das initialisierte Aktenkonto des Versicherten. Nach erfolgreichem Abschluss wird (kann) das Aktenkonto (neu) in den Status ACTIVATED überführt werden.

Unter Verwendung des Information Service wird das Aktensystem (alt) über den erfolgreichen Import und den Abschluss des Transfers informiert. Das Aktenkonto (alt) kann daraufhin, ggf. unter Einhaltung weiterer Bedingungen des Kostenträgers bzw. gesetzlicher Vorgaben, gelöscht werden (Status = UNKNOWN).

Im Anschluss an die Rückmeldung des erfolgreichen Abschlusses des Transfers durch das Aktensystem (alt) wird (kann) das Aktenkonto (neu) in den Status ACTIVATED für die produktive Nutzung überführt werden,

Abschluss des Transfers
I_Information_Service_Accounts (bisheriges Aktensystem)
deleteExportPackage	Beenden des Vorgangs (Löschen Exportpaket und ggf. bisheriges Aktenkonto)

Änderungen an OpenApis

Änderungen in I_Information_Service_Accounts.yaml

Angepasste Beschreibung der Operation getGeneralConsentDecision sowie zusätzliche Fehlerbedingung und Status Code.

      description: |

       Check whether a certain KVNR is known among the insurances of a health record provider and get
       the consent decision regarding principle usage of a personal health record.

       Checks whether a specific KVNR (_insurantId_) is known among the insurances of a health record provider and retrieves
       the consent decision regarding the general use of a personal health record.

        **Client**:

       A client (a health record system) shall always and only invoke this operation just before when a new health
       record is or shall is to be activated created on client side (state == UNKNOWN or INITIALIZED) to retrieve the
       information about a general objection of the insurant against the provision of a personal Health
       record.
       This operation shall be used prior invocation of _startRelocation_, i.e. _startRelocation_ shall
       only be used in case _generalConsent_ is set to _true_.

       Since the request to relocate health record data must be based on the most up-to-date information,
       this operation should be executed immediately before a potential invocation of _startRelocation_
       to relocate health record data. A client shall not start a relocation if returned information is inconsistent.

       **Provider**:

       Indicates in the response the state and timestamp of the consent decision regarding the principle usage of
       a personal health record associated to a particular insurant (kvnr).
       The operation should be independent of the presence of a health record associated to
       the kvnr (_insurantid_).

       If no consent information is applicable or not available at all but the kvnr is known and hosted by the provider,
       status code '204' shall be used for the response. A health record may exist in this case.

       | Conditions | Status code | Error code | Remarks |
       |------------|-------------|------------|---------|
       | Successful operation | 200 |||
       | Successful operation without consent information| 204 || consent not applicable |
       | Request does not match schema | 400 | malformedRequest ||
       | No mutual TLS channel used | 403 | accessDenied ||
       | KVNR (insurant) unknown | 404 | noResource | _insurantid_ unknown |
       | contradictonary information available | 409 | informationMismatch | inconsistent local data, no information available |
       | Any other error | 500 | internalError ||

Angepasste Beschreibung der Operation startRelocation:

      description: |

       Initiates the preparation of an export package in case the requested health record exists and
       returns a requestId for reference.

       Starts a new health record relocation process and initiates the preparation of an export package
       in case the requested health record exists. A _requestId_ for reference is returned.

       **Client**:

       A client shall always and only invoke this operation when a new health record is created on client
       side (state == INITIALIZED), allowing consideration of a possible required import of
       existing health record data from different health record providers.</br>

       A client shall use this function before activation (record state ACTIVATED) of the health record to import
       contents of an existing health record from another provider.

       Before calling _startRelocation_, the client shall invoke the _getGeneralConsentDecision_
       operation **immediately before** _startRelocation_ to ensure the relocation decision is based
       on the latest consent status.

       **Provider**:

       Creates a _requestId_ in case the addressed health record exists and is in state ACTIVATED.
       A health record in state SUSPENDED has an already prepared export package which shall not
       be created twice.  
      The health record export package generation shall be initialized by passing the _requestId_
       to the responsible actors (insurance company associated to provider) by proprietary means.</br>

       The provider shall add a resource identified by _requestId_ (as just created) in provider's
       _Information Service Account_ path _/accounts/v1/exportpackagegeneration/{requestid}_
       to enable reception of notifications about the request.

       The provider shall reject the request if the health record has a pending migration from an epa-2.x health record.

       | Conditions | Status code | Error code | Remarks |
       |------------|-------------|------------|---------|
       | Successful operation | 200 |||
       | Request does not match schema | 400 | malformedRequest ||
       | No mutual TLS channel used | 403 | accessDenied ||
       | Health record does not exist (UNKNOWN) or is in state INITIALIZED | 404 | noHealthRecord | |
       | Health record is in state SUSPENDED or MAINTENANCE| 409 | statusMismatch | (see 'Retry interval') |
       | Health record with pending epa-2.x migration | 409 | pendingMigration ||
       | Any other error | 500 | internalError ||

Angepasste Beschreibung der Operation deleteExportPackage:

      description: |
       Request to delete an existing export package after successful relocation to
       a new health record provider

       Finalizes the relocation process and requests deletion of an existing export package
       after successful relocation to a new health record provider.

       **Client**:
       A client shall always invoke this operation when export package download
       and data migration was successful.

       The client (importing health record system) shall always invoke this operation after the
       export package has been successfully downloaded and the data import completed.
       This confirms the successful transfer of data and record responsibility to the new provider to
       the exporting provider and completes the transfer request.
       The client shall receive a 'successful operation' response ('204') from this operation
       **before** activating the importing health record (record state ACTIVATED).

       **Provider**:</br>

       The export package shall be deleted and the associated download url shall no longer be
       valid.
       Deletion shall only succeed in case the associated Health record is in state SUSPENDED.
       
       The information about successful relocation to the requesting health record provider
       shall be passed to the responsible actors (insurance company associated to provider) by proprietary means
       for subsequent deletion of the orphaned health record.

       Sending a 'successful operation' response definitively completes the relocation process.  
       The health record on the exporting provider’s side must **not** be reactivated thereafter
       (i.e., its state must never return to ACTIVATED under any circumstances).
       Finalize the relocation process and request to delete an existing export package after
       successful relocation to a new health record provider