Prerequisites for Document Registering of Observation Resources

Prerequisites for registering a document about a FHIR Observation are all of:

Prerequisites for Document Registering of QuestionnaireResponse Resources

Prerequisites for registering a document about a FHIR QuestionnaireResponse are all of:

Prerequisites for Document Registering of Appointment Resources

Prerequisites for registering a document about an Appointment are all of:

Document Transformation and Registration Processing

The transformation of resources to documents and the subsequent registration to the national document sharing infrastructure is an automatic procedure split in two different processes. The initial process is event driven and is the first attempt at transforming and registering the transformed document. However, a periodic job will attempt to retry the transformation and registration of documents that failed due to either a lack of organizational identification using SOR-ID or a failed registration.

Event Triggered Transformation and Registration

The event driven process goes through the five steps outlined at the top of the page.

1. determining whether criteria for document registering are met for the FHIR resource in question

2. assemble to a volatile (in-memory) FHIR Composition

3. transformation of assembled FHIR Composition to Danish profiles of Clinical Document Architecture (CDA) documents

4. extract of document metadata from the document and context

5. registering of document and document metadata in the national health document sharing infrastructure.

If an error occurs during the processing of a resource, the event that triggered it is rolled back. The event is then automatically retried for some time before being put aside on a dead-letter-queue (DLQ) if it keeps failing. The only two exceptions to this are:

• When transformation (Step 3) fails due to Composition.authorOrganization or Composition.custodian missing a SOR-ID. In this case the event is not rolled back, the attempt is instead book-kept for a periodic retry job (currently, nightly). The rationale is that missing SOR-ID can occur due to lack of registration by municipalities in the municipal organization register and, once corrected by them, the transformation should be retried. It requires an import from the municipal registration system, see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/533528597/Importing+and+updating+Organization+information+from+SOR+and+FK-Organisation+into+eHealth+Infrastructure#eHealth-Infrastructure-imports-from-KOMBIT-F%C3%A6lleskommunalt-(FK)-Organisation , which occurs nightly.

• When the transformation is successful but the registration fails. In this case the event is still rolled back and then automatically retried for some time before being put aside on the dead-letter-queue if it keeps failing. However, an attempt is also book-kept for nightly retry. The reason for this is to allow a series of relatively immediate retries in case of a temporary connection issue, as well as periodic retries if the error is correctible.

Book-keeping of attempts is done internally in the Document-Transformation service in the form of FHIR DocumentReference resources formatted specifically to indicate how far in the process it came:

• DocumentReference.masterIdentifier is set only when transformation is successful

• DocumentReference.identifier is set only when registration is successful.

The following three distinct progressions in the transformation and registration process can be discerned using these elements:

Periodic Retry of Transformation and Registration

The periodic retry job starts by finding the DocumentReference resources for retry based on their distinct qualities (see above). Two different flows are used depending on whether the resources should retry just registration or both transformation and registration. However, the flows both start by checking that the attempt has not been superseded by another successful attempt or a newer document. If so, the DocumentReference is persisted with status=superseded and no further processing or retries will be attempted.

If only registration is retried, then there are only two primary steps.

1. Check if the attempt has been superseded by another successful attempt or a newer document.

2. registering of document and document metadata in the national health document sharing infrastructure.

Should the registration fail once again, an error message is persisted in the DocumentReference, but is still retried again in next period of the periodic retry job.

If both transformation and registration needs to be retried, the process is very similar to that of the event driven procedure.

1. Check if the attempt has been superseded by a successful attempt or a newer document.

2. Check if SOR-ID is still missing

3. assemble to a volatile (in-memory) FHIR Composition

4. transformation of assembled FHIR Composition to Danish profiles of Clinical Document Architecture (CDA) documents

5. extract of document metadata from the document and context

6. registering of document and document metadata in the national health document sharing infrastructure.

If the SOR-ID is still missing, the retry of the DocumentReference is abandoned, but is retried again the next time. However, should the transformation happen to fail due to something else, after the missing SOR-ID has been corrected, the error will be persisted in the DocumentReference resource and will not be retried again in the future, as only the SOR-ID transformation error is currently expected to be correctable (here by external correction in municipal organizational registration, see above).