Some FHIR resources in the eHealth Infrastructure are transformed to document form and registered in national document sharing infrastructure. This way, the patient and other healthcare professionals can access the health data registered through other health systems while subjected to various access controls and audit logging.

The document registering process involves:

determining whether criteria for document registering are met
assembly to a volatile (in-memory) FHIR Composition (as described in Query, Retrieve and Transform Documents from NSP | Preparing Transformations by Assembling Required FHIR Resources )
transformation of assembled FHIR Composition to Danish profiles of Clinical Document Architecture (CDA) documents (as described in Query, Retrieve and Transform Documents from NSP | Transformation Details ) to a document
extract of document metadata from the document and context
registering of document and document metadata in the national document sharing infrastructure.

Primary FHIR Resource Type	Assembling of Resources for Transformation	Transformation	Registered as Document Type

Primary FHIR Resource Type

Assembling of Resources for Transformation

Transformation

Registered as Document Type

Observation

Description of assembly of resources

$transform-to-PHMR

https://ehealth.sundhed.dk/fhir/OperationDefinition--s-transform-to-PHMR.html

CDA Header transformation

PHMR Transformation

PHMR

QuestionnaireResponse

Description of assembly of resources

$transform-to-QRD

https://ehealth.sundhed.dk/fhir/OperationDefinition--s-transform-to-QRD.html

CDA Header transformation

QRD Transformation

QRD

Appointment

$transform-to-APD

https://ehealth.sundhed.dk/fhir/OperationDefinition--s-transform-to-APD.html

APD

This description below focuses on the criteria for this registration to take place.

Content

Prerequisites for Document Registering of Observation Resources
Prerequisites for Document Registering of QuestionnaireResponse Resources
Prerequisites for Document Registering of Appointment Resources
Document Transformation and Registration Processing
- Event Triggered Transformation and Registration
- Periodic Retry of Transformation and Registration

Prerequisites for Document Registering of Observation Resources

Prerequisites for registering a document about a FHIR 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
The particular FHIR Observation is not invalidated	A FHIR ClinicalImpression for the Observation must not exist with `ClinicalImpression.status=copmleted` and `ClinicalImpression.finding.code` set to a Coding for `measurement-invalidated`

Prerequisites for Document Registering of QuestionnaireResponse Resources

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

Prerequisite (Logically)	Criteria
Sharing is allowed for the activity.	The FHIR `QuestionnaireResponse.basedOn` refers a FHIR ServiceRequest with `ServiceRequest.ehealth-sharingPolicy` allowing document sharing and designating a national health archive as the destination.
The particular FHIR QuestionnaireResponse is approved for document registering.	A FHIR ClinicalImpression must exist with `ClinicalImpression.ehealth-clinicalimpression-decision` set to a Coding for `approved-for-sharing` The `ClinicalImpression.investigation.item` shall refer the FHIR QuestionnaireResponse
The FHIR QuestionnaireResponse is a response to a FHIR Questionnaire which is marked up as corresponding to a known and generally accessible, external questionnaire represented as a Questionnaire Form Definition Document (QFDD). Rationale: Document registering of a FHIR QuestionnaireResponse as a Questionnaire Response Document (QRD) document is of reduced value to a clinician retrieving the QRD from document sharing infrastructure if the corresponding questionnaire is not available as a QFDD.	The FHIR `QuestionnaireResponse.questionnaire` must refer a FHIR Questionnaire (or advanced Questionnaire) which has a `Questionnaire.identifier` specifying the document id of a QFDD document. A FHIR 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 (`DocumentReference.content.attachment` contains the QFDD XML document - this is not enforced as a prerequisite but assumed and needed) See Managing Questionnaires
The particular FHIR QuestionnaireResponse is not invalidated	A FHIR ClinicalImpression for the QuestionnaireResponse must not exist with `ClinicalImpression.status=copmleted` and `ClinicalImpression.finding.code` set to a Coding for `measurement-invalidated`

Prerequisites for Document Registering of Appointment Resources

Prerequisites 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://ehealth.sundhed.dk/fhir/StructureDefinition-ehealth-appointment.html or https://ehealth.sundhed.dk/fhir/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.

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.

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.

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:

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 Importing and updating Organization information from SOR and FK-Organisation into eHealth Infrastructure , 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:

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

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.

Check if the attempt has been superseded by another successful attempt or a newer document.
register 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
transform the assembled FHIR Composition to Danish profiles of Clinical Document Architecture (CDA) documents
extract document metadata from the document and context
register 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).

Document Metadata for Document Registering

The eHealth Infrastructure prepares document metadata that adhere to:

Version 0.96 dated 24 October 2018 of XDS Metadata for Document Profile, Danish Profile
Version 1.0.1 of XDS Metadata ValueSet, Danish Profile

The document metadata described here are those prepared in the IHE XDS.b DocumentEntry structure cf. XDS Metadata for Document Profile, Danish Profile, consisting of a number of attributes.

For the most part, document metadata attributes associated with a document reflects values within the document. Notably, there are the following two exceptions:

DocumentEntry attribute practiceSettingCode - which reflects the clinical specialty in which the document was authored. The eHealth Infrastructure uses an organisational specialty, as described below.
DocumentEntry attribute healthcareFacilityTypeCode - which reflects the organisational unit type

Determining the Organisational Context

The organisational context to use as source for the two document metadata attributes depends on the FHIR resource type which served as the primary driver of the document content:

For FHIR Observation and FHIR QuestionnaireResponse resources, the FHIR Organization is the one referenced from the ClinicalImpression.assessorOrganizationof the FHIR ClinicalImpression approving document sharing.
For FHIR Appointment resources, the FHIR Organization is the one referenced in Appointment.responsibleOrganization.

Determining the practiceSettingCode Attribute Value

Whether a FHIR Organization specialty is primary or regular is determined from the Organization.specialty.primaryIndicator, see https://ehealth.sundhed.dk/fhir/StructureDefinition-ehealth-organization-specialty.html .

If the FHIR Organization is from the municipal source (imported from the municipal registry FK Organisation), determining the specialty possibly involves traversing the FHIR Organization tree (with municipal source), and using the specialty/specialties (expected to be) registered in the related SOR imported FHIR Organization.
- An acceptable specialty is one included in IHE XDS ValueSet https://ehealth.sundhed.dk/fhir/ValueSet-dk-ihe-practicesettingcode-vs.html.
- Starting with the Organization resource identified in the organisational context (see above):
  - If the corresponding SOR imported Organization has a single primary specialty which is acceptable, it is used.
  - If the corresponding SOR imported Organization has a single primary specialty which is unacceptable, the document registrering is terminated.
  - If the corresponding SOR imported Organization has multiple primary specialties, the document registrering is terminated.
  - if the corresponding SOR imported Organization has no specialty/specialties, the parent Organization of the municipal source Organization is considered.
- If no specialty has been determined, a fallback value for municipal source Organization specialty is used. Currently the fallback is configured to code=2903041000005106, system=http://www.snomed.org/, display=det kommunale omsorgs-, social- og sundhedsområde.

If the FHIR Organization has SOR source (has been imported from SOR), then the first primary specialty found on that specific Organization is used, if no primary specialty is present the first regular specialty is used.

The determined specialty code is validated against the IHE XDS ValueSet https://ehealth.sundhed.dk/fhir/ValueSet-dk-ihe-practicesettingcode-vs.html . When valid, the value is used, otherwise the document registering is terminated.

Determining the healthcareFacilityTypeCode Attribute Value

The value of Organization.type is validated against the IHE XDS ValueSet https://ehealth.sundhed.dk/fhir/ValueSet-dk-ihe-healthcarefacilitytypecode-vs.html . When valid, the value is used, otherwise the document registering is terminated.

Document Sharing Reaction to Measurement Invalidation and Retraction of Invalidation

The following is a description on how user’s invalidation and retraction of invalidation through the custom operation $set-measurement-validity (see Adhering to Care Plans and Measurement Regimes | Managing Validity of Measurements) impacts document registering performed by the infrastructure.

Invalidation of a measurement results in:

prevention of document registration in case not already performed
document metadata status change to deprecated in case document has already been registered.

Retraction of invalidation results in:

re-attempting document registration in case not already performed
re-transformation and registering of newly formed document in case document metadata in case document was previously registered and deprecated. The new document will have document metadata with status Approved.

Rationale: Re-transformation and registering of a new document is needed, as the IHE XDS operation involved in changing document metadata status (interaction ITI-57) does not allow transition from Deprecated to Approved. It allows the other way around only.

An exception to the handling on invalidation and retraction of invalidation is if the document has been manually deprecated (through the service request Deprecate document metadata in the national document sharing infrastructure) or if an error occurred during transformation of the measurement which was deemed to be unresolvable.

Rationale: Manual deprecation is a citizen decision. If the infrastructure did not observe this, the citizen could experience a whack-a-mole scenario where a manually deprecated document re-appeared, requiring a new manual deprecation service request and so on.

Therefore, the infrastructure does not perform deprecation (as reaction to invalidation) nor re-transformation and registering (as reaction to retraction of invalidation) when the citizen has already decided for manual deprecation.

Document Sharing State

The maintaining of document sharing information and state described below is for internal use in the infrastructure’s document-transformation service.

Document sharing state is maintained through use of the profile ehealth-transformation-documentreference of FHIR DocumentReference.

The link to ehealth-transformation-documentreference will function momentarily. In the mean time, the profile can be accessed through https://build.fhir.org/ig/fut-infrastructure/implementation-guide/branches/master/StructureDefinition-ehealth-transformation-documentreference.html .

When a measurement (FHIR Observation, FHIR QuestionnaireResponse or FHIR Media) or appointment (FHIR Appointment) is deemed eligible for document registration, a DocumentReference is created automatically, at some point in time as part of the processing, referencing the measurement or appointment with both a specific technical version (versioned reference) and a non-versioned reference.

The document sharing state is captured in DocumentReference.documentSharingState through use of two codes both defined in ValueSet document-sharing-code :

an overall document sharing state code
a detailed document sharing state code

The following table describes overall sharing states codes, used to describe the sharing state on a high level. At most one overall document sharing code shall be used in DocumentReference.documentSharingState.

Overall Document Sharing State Code	Description of meaning

Overall Document Sharing State Code	Description of meaning
`shared`	The document is shared and should exist in XDS.
`being-shared`	Prerequisites for sharing have been met, and the document is in the process of being shared. This state will often represent documents, where sharing is being retried due to some missing information (which can be corrected) or due to XDS being unreachable.
`prevented-shared`	The document is prevented from being shared, due to an invalidation.
`deprecated`	The document has been deprecated, either due to manual deprecation or invalidation of the measurement.
`not-shared`	The document cannot be shared due to specific data values, unsolvable transformation errors or newer version of document exists. Examples of this could be missing/invalid QFDD reference for QuestionnaireResponses or errors when resolving FacilityType or PracticeSetting when determining sharing meta data.

The following table describes detailed document sharing states codes, which are used in combination of the overall document sharing code, to provide further details regarding the state of the document. A DocumentReference can contain multiple of these detailed document sharing codes.

Detailed Document Sharing State Code	Description of meaning

Detailed Document Sharing State Code	Description of meaning
`invalidated`	The related measurement for this particular document has been invalidated.
`invalidation-retracted`	The related measurement for this particular document has been previously invalidated, but invalidation has been retracted.
`manually-deprecated`	The document has been manually deprecated through a service request. No newer versions of the measurement / appointment will result in attempts to share.
`facility-type-error`	An error related to the FacilityTypeCode was encountered during publishing attempt. This state will result in the document not being attempted to be published.
`practice-setting-error`	An error related to the PracticeSettingCode was encountered during publishing attempt. This state will result in the document not being attempted to be published.
`missing-sor-identification`	SOR Id missing for Organization used during transformation of measurement/appointment. This state will be retried as part of the PeriodicRetryJob.
`sharing-target-unavailable`	Error was encountered during publishing, which would indicate that the XDS service is unavailable. This state will be retried as part of the PeriodicRetryJob.
`missing-qfdd-reference`	Unable to determine QFDD reference for QuestionnaireResponse which is attempted to be published.
`contains-data-absent-reason`	Observation contains data absent reason, and will not be attempted to be published.
`out-of-date-resource`	Publishing of the specific document has been stopped, due to a newer version of the measurement / appointment existing. The processing of this DocumentReference should stop, since the update could result in the document not supposed to be published.
`yielded-to-duplicate-document`	Encountered duplicate DocumentReference for same measurement/appointment version. This code indicates that the specific DocumentReference has yielded.
`general-transformation-failure`	General transformation failure. FUT-I will periodically investigate these occurrences to see if it is possible to create a new detailed state code to represent the scenario.
`general-publication-failure`	General publication failure. FUT-I will periodically investigate these occurrences to see if it is possible to create a new detailed state code to represent the scenario.
`no-idref-binding-in-document`	Example of specific error occurring during publishing, that was analysed to not be able to be resolved.
`invalid-observation-code`	Observation or Observation.component contains code which is not valid for document sharing (not valid against ValueSet `http://sundhedsdatastyrelsen.dk/terminologi/dk-ihe-eventcodelists-vs` )

Sharing through Registering Documents in National Document Sharing Infrastructure