Prerequisites for Document Registering of Observation ResourcesPrerequisites for registering a document about an Observation are all of: Prerequisite (Logically) | Criteria |
|---|
Sharing is allowed for the activity. | The Observation.basedOn refers a ServiceRequest with ServiceRequest.ehealth-sharingPolicy allowing document sharing and designating a national health archive as the destination.
| The particular Observation is approved for document registering. | A ClinicalImpression must exist with ClinicalImpression.ehealth-clinicalimpression-decision set to a Coding for approved-for-sharing The ClinicalImpression.investigation.item shall refer the Observation
| The Observation has a measurement quantity/value. Rationale: Otherwise, the Observation cannot be shared as a PHMR document. | Observation.dataAbsentReason must not specify an absent data reason
|
| Info |
|---|
Before release FUT-I 2024.1 |
The criteria for registering an Observation as a document are: The ServiceRequest.ehealth-sharingPolicy must specify sharing is allowed and, currently, that this is sharing with a national health archive as the destination There must exist a ClinicalImpression referring to the measurement with ClinicalImpression.ehealth-clinicalimpression-decision set to a Coding for approved-for-sharing The Observation must not specify an absent data reason (.dataAbsentReason). Observations without a value can't be shared with CDA Personal Health Monitoring Report (PHMR).
Prerequisites for Document Registering of QuestionnaireResponse ResourcesPrerequisites for registering a document about an QuestionnaireResponse are all of: Prerequisite (Logically) | Criteria |
|---|
Sharing is allowed for the activity. | The QuestionnaireResponse.basedOn refers a ServiceRequest with ServiceRequest.ehealth-sharingPolicy allowing document sharing and designating a national health archive as the destination.
| The particular QuestionnaireResponse is approved for document registering. | A ClinicalImpression must exist with ClinicalImpression.ehealth-clinicalimpression-decision set to a Coding for approved-for-sharing The ClinicalImpression.investigation.item shall refer the QuestionnaireResponse
| The QuestionnaireResponse is a response to a Questionnaire which is marked up as corresponding to a known and generally accessible, external questionnaire represented as a Questionnaire Form Definition Document (QFDD). Rationale: A QRD document (here corresponding to a QuestionnaireResponse) is of reduced value to a clinician retrieving it from document sharing infrastructure if the corresponding questionnaire is not available as a QFDD. | | Info |
|---|
Before release 2024.1 |
A Composition exists (in the document-transformation service) with: Composition.section.entry which is a reference to the FHIR Questionnaire corresponding to the QFDD representation
Composition.section.entry which is a reference to a DocumentReference (the Reference.type shall be "DocumentReference")
A DocumentReference exists (in the document-transformation service) with: DocumentReference.content.attachment.url which is expected to provide the external location of the QFDD
DocumentReference.status set to current
DocumentReference.masterIdentifier matches that QFDD document id
QuestionnaireResponse.questionnaire must refer a Questionnaire (or advanced Questionnaire) which has a Questionnaire.identifier specifying a QFDD document.
A DocumentReference exists (in the document-transformation service) with: DocumentReference.type set to a Coding for QFDD
DocumentReference.status set to current
DocumentReference.masterIdentifier matches that QFDD document id
See Managing Questionnaires |
Prerequisites for Document Registering of Appointment ResourcesPrerequisites for registering a document about an Appointment are all of: Prerequisite (Logically) | Criteria |
|---|
The Appointment is for a single Patient type participant only | Appointment.serviceType must be regular or video (corresponding to use of the profiles https://docs.ehealth.sundhed.dk/latest-released/ig/StructureDefinition-ehealth-appointment.html or https://docs.ehealth.sundhed.dk/latest-released/ig/StructureDefinition-ehealth-videoappointment.html , respectively)
| The Appointment has legal basis for which national document sharing has been established | Appointment.ehealth-legalBasis must designate the Healthcare Act
| Document registering of the Appointment must not be denied | Appointment.ehealth-releasableResource must be unspecified or set to true.
| Any previous document registering of the Appointment must not have had its document metadata deprecated by manual procedure. Rationale: An update to an Appointment previously registered as a document leads to a new document with document metadata that replaces the document metadata of the prior document. Manually initiated deprecation must be respected in order for document metadata not “reappearing” of what was previously asked to be removed (deprecated). | Internal bookkeeping must not reflect that manual deprecation has been completed for the Appointment. |
| Info |
|---|
That is, once document metadata has been manually deprecated, further updates of the Appointment resource are not reflected in new Appointment Documents being document registered for that Appointment. |
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. The event driven process goes through the five steps outlined at the top of the page. determining whether criteria for document registering are met for the FHIR resource in question assemble to a volatile (in-memory) FHIR Composition transformation of assembled FHIR Composition to Danish profiles of Clinical Document Architecture (CDA) documents extract of document metadata from the document and context 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: 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: The following three distinct progressions in the transformation and registration process can be discerned using these elements: Progression | Distinct Qualities |
|---|
Transformation failed due to missing organizational identifier as SOR-ID | DocumentReference.docStatus=preliminary
DocumentReference.content.attachment.data is not present (has no data)
No DocumentReference.masterIdentifier No DocumentReference.identifier | Transformation successful but not registered | DocumentReference.docStatus=final
DocumentReference.content.attachment.data is present and has data
Has DocumentReference.masterIdentifier No DocumentReference.identifier | Transformed and registered | DocumentReference.docStatus=final
(DocumentReference.content.attachment.data is expected to be purged) Has DocumentReference.masterIdentifier Has DocumentReference.identifier |
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. Check if the attempt has been superseded by another successful attempt or a newer document. 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. Check if the attempt has been superseded by a successful attempt or a newer document. Check if SOR-ID is still missing assemble to a volatile (in-memory) FHIR Composition transformation of assembled FHIR Composition to Danish profiles of Clinical Document Architecture (CDA) documents extract of document metadata from the document and context 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). |