Query, Retrieve and Transform Documents from NSP

Query, Retrieve and Transform Documents from NSP

The eHealth Infrastructure document-query and document-transformation services provide integrations to the Danish national document-sharing infrastructure.

This page describes the eHealth infrastructure capabilities for

  1. How to query and retrieve documents from NSP

  2. How to upload CDA documents to NSP

  3. Details on transformations FHIR to CDA Document

  4. Details on transformations CDA Document to FHIR

Content

 

 

The national document-sharing infrastructure is based on Integrating the Health Enterprise (IHE) Cross-enterprise Document Sharing (XDS-b) profiles and uses Danish profiles for document metadata. While XDS-b is content-agnostic, currently shared documents are XML documents (ideally) adhering to Danish profiles of Clinical Document Architecture (CDA) document types.

Queries for document metadata and retrieval of documents can be performed through the healthcare domain National Service Platform (NSP) Document Sharing Service (Danish: Dokumentdelingsservice DDS). Acting as a front, the DDS encapsulates details about the topology of XDS-b components, whether this is one or more XDS Registry containing document metadata or one or more XDS Repository containing documents.

The eHealth Infrastructure:

The eHealth Infrastructure provides operations to transform between FHIR resources and Danish profiles of Clinical Document Architecture (CDA) XML documents.

The transformations to CDA documents are used (see details below) when the eHealth infrastructure uploads documents and metadata to the national document-sharing infrastructure.

The transformations to FHIR resources can be used by a client performing XDS-b document metadata query and document retrieving.

Services to perform Document Query and Document Retrieve

The Danish National Service Platform (NSP) in Healthcare provides a national document-sharing service (Danish: Dokumentdelingsservice DDS).

The DDS provides the following operations described in https://profiles.ihe.net/ITI/TF/Volume1/ch-10.html:

  • The Registry Stored Query (XDS-b transaction ITI-18) lets you search for document metadata using criteria like patient ID and period. It returns matching results, which could be none, one, or more.

  • The Retrieve Document Set (XDS-b transaction ITI-43) allows you to get documents based on their metadata. It returns the documents, which could be none, one, or more.

Further details on how the NSP DDS processes ITI-18 and ITI-43 requests, including possibly withholding data due to patient’s consent (Danish: Min Spærring) are described in Danish at https://www.nspop.dk/x/WJC6.

These operations are supported through the following eHealth infrastructure operations provided by the document-query service:

Querying document metadata is a necessary step before retrieving the actual document.

While the XDS-b transaction ITI-43 Retrieve Document Set supports the retrieval of multiple documents, the $retrieve-document supports the retrieval of a single document only.

Document Query Parameters Supported by the Infrastructure

The infrastructure supports a number of ITI-18 parameters. The table below is an expansion of Table 2:3.67.4.1.3.1-1: ITI-18 FindDocuments Query Parameter Mapping from the IHE documentation, showing which specific parameters are supported in the infrastructure and how they map to the ITI-18 and ITI-67 parameters.

Infrastructure Query Parameters

[ITI-67] Parameter Name

[ITI-18] Parameter Name

Infrastructure Query Parameters

[ITI-67] Parameter Name

[ITI-18] Parameter Name

patient

patient or patient.identifier

$XDSDocumentEntryPatientId

patient-identifier


date

creation

$XDSDocumentEntryCreationTimeFrom

creation

$XDSDocumentEntryCreationTimeTo

N/A

author.given / author.family

$XDSDocumentEntryAuthorPerson

status

status

$XDSDocumentEntryStatus

N/A

(Not supported)

$XDSDocumentEntryType

category

category

$XDSDocumentEntryClassCode

type

type

$XDSDocumentEntryTypeCode

setting

setting

$XDSDocumentEntryPracticeSettingCode



period

period

$XDSDocumentEntryServiceStartTimeFrom

period

$XDSDocumentEntryServiceStartTimeTo

period

$XDSDocumentEntryServiceStopTimeFrom

period

$XDSDocumentEntryServiceStopTimeTo

facility

facility

$XDSDocumentEntryHealthcareFacilityTypeCode

event

event

$XDSDocumentEntryEventCodeList

N/A

security-label

$XDSDocumentEntryConfidentialityCode

format

format

$XDSDocumentEntryFormatCode

N/A

related

$XDSDocumentEntryReferenceIdList

Mapping DocumentEntry Values to DocumentReference in Query Results

When performing a Query for documents, the result is a Bundle containing DocumentReferences representing the DocumentEntries (document metadata) found. IHE has a standard for mapping from DocumentEntry to fhir’s DocumentReference. The infrastructure is based on that standard and implements a subset thereof.

The table below is an overview of how the infrastructure maps from DocumentEntry to DocumentReference. Additionally, it shows where and how the implementation deviates slightly from the aforementioned standard that it is based upon.

fhir DocumentReference

XDS DocumentEntry

fhir DocumentReference

XDS DocumentEntry

DocumentReference.masterIdentifier

DocumentEntry.uniqueId

DocumentReference.identifier

DocumentEntry.entryUUID

DocumentReference.status

DocumentEntry.availabilityStatus

DocumentReference.category

DocumentEntry.classCode

DocumentReference.author

DocumentEntry.author

DocumentReference.authenticator

DocumentEntry.legalAuthenticator

DocumentReference.description

DocumentEntry.comments

DocumentReference.content.attachment.contentType

DocumentEntry.mimeType

DocumentReference.content.attachment.language

DocumentEntry.languageCode

 


DocumentReference.content.attachment.url

DocumentEntry.uniqueId, DocumentEntry.repositoryUniqueId and DocuemntEntry.homeCommunityId

Deviates from standard: By being a concatenated string of the above variables instead of simply DocumentEntry.repositoryUniqueId or DocuemntEntry.URI.

DocumentReference.content.attachment.title

DocumentEntry.title

DocumentReference.date

Deviates from standard: As it is assigned to DocumentReference.date instead of DocumentReference.content.attachment.creation

 

DocumentEntry.creationTime

DocumentReference.content.format

DocumentEntry.formatCode

DocumentReference.context.event

DocumentEntry.eventCodeList

DocumentReference.context.period.start

DocumetEntry.serviceStartTime

DocumentReference.context.period.end

DocumentEntry.serviceStopTime

DocumentReference.context.facilityType

DocumentEntry.healthcareFacilityTypeCode

DocumentReference.context.practiceSetting

DocumentEntry.practiceSettingCode

Special notes on retrieve-and-transform-QRD operation

The retrieval and transformation are offered as a single call via operations (one per document type).

The retrieve-and-transform-QRD operation is a little special as it requires QFDD to be present in the infrastructure and the corresponding FHIR Questionnaire.

Prerequisites:

  • The QFDD is uploaded to the infrastructure (e.g., via KAM), and the infrastructure has stored the QFDD in an FHIR DocumentReference.

  • The FHIR Questionnaire:

    • is an analogue (or close match) to the QFDD

    • has QFDD document ID as an identifier.

Client Applications must:

  1. Look up metadata for the QRD for specific QFDD (via document query and DocumentReference Search)

  2. Retrieve the FHIR Questionnaire from the Questionnaire service with the identifier of the QFDD document ID

  3. Call Retrieve and transform QRD providing the URL for the CDA document and the FHIR Questionnaire as input (optional)

  4. The Document-query service returns the FHIR QuestionnaireResponse if the FHIR Questionnaire is provided as input and the transformation is successful. Otherwise, it returns the QRD CDA XML.

Operations for Transformation between FHIR Resources and Danish CDA Profiles

The https://ehealth.sundhed.dk/fhir/CapabilityStatement-document-transformation.html provides operations for transforming documents between FHIR resources and Danish CDA document profiles.

Details on the transformations are provided in the table below which includes references to Danish CDA profiles.

The transformations have the following characteristics:

  • The transformations are idempotent (except for generated identifiers such as the CDA document ID in the output).

  • The transformations do not provide access to any FHIR resources. Client Applications must supply the necessary FHIR resources as input. This design prevents security breaches.

 

Transformation

Source (XML document in FHIR DocumentReference)

Target (XML document in FHIR DocumentReference)

Comment

Transformation

Source (XML document in FHIR DocumentReference)

Target (XML document in FHIR DocumentReference)

Comment

$transform-to-PHMR

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

Bundle of FHIR resources.

The primary source of information is a FHIR Observation.

PHMR v2.1 XML document.

Used in assembly, transformation and upload of FHIR Observation transformed to PHMR to XDS-based document sharing infrastructure as described in Sharing through Registering Documents in National Document Sharing Infrastructure.

$transform-to-QRD

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

 

Bundle of FHIR resources.

The primary source of information is an FHIR QuestionnaireResponse.

QRD v1.3 XML document

Used in assembly, transformation and upload of FHIR QuestionnaireResponse transformed to QRD to XDS-based document sharing infrastructure as described in Sharing through Registering Documents in National Document Sharing Infrastructure.

$transform-to-QFDD

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

Bundle of FHIR resources.

The primary source of information is the FHIR Questionnaire.

QFDD v1.2 XML document

 

$transform-to-APD

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

Bundle of FHIR resources.

The primary source of information is a FHIR Appointment.

APD v2.0 XML document

Used in assembly, transformation and upload of FHIR Appointment transformed to APD to XDS-based document sharing infrastructure as described in Sharing through Registering Documents in National Document Sharing Infrastructure.

$transform-from-PHMR

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

PHMR v2.1 XML document.

Bundle of FHIR resources.

The most significant information is within an FHIR Observation.

The resulting Observation(s) is not guaranteed to be a valid FHIR Observation.

$transform-from-QRD

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

QRD v1.3 XML document

Bundle of FHIR resources.

The most significant information is within a FHIR QuestionnaireResponse.

The resulting QuestionnaireResponse is not guaranteed to be a valid FHIR QuestionnaireResponse.

$transform-from-QRD-based-on-questionnaire

https://ehealth.sundhed.dk/fhir/OperationDefinition--s-transform-from-QRD-based-on-questionnaire.html

QRD v1.3 XML document

Bundle of FHIR resources

Most significant information is within an FHIR QuestionnaireResponse with a structure matching the Questionnaire given as input. The QuestionnaireResponse will have linkIDs matching the corresponding Questionnaire.

The resulting QuestionnaireResponse is not guaranteed to be a valid FHIR QuestionnaireResponse.

$transform-from-QFDD

https://ehealth.sundhed.dk/fhir/OperationDefinition--s-transform-from-QFDD.html

QFDD v1.2 XML document

The primary resource in the return bundle is the FHIR Questionnaire.

 

$transform-from-APD

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

APD v2.0 XML document

Bundle of FHIR resources.

The primary source of information is a FHIR Appointment.

The resulting Appointment is not guaranteed to be a valid FHIR Appointment.

 

HL7 DK CDA Profile

Description

Specification

HL7 DK CDA Profile

Description

Specification

PHMR v2.1

HL7 Implementation Guide for CDA Release 2.0,
Personal Healthcare Monitoring Report (PHMR),
(Danish profile – PHMR DK),

Release 2.1.0 May 13th 2025

https://svn.medcom.dk/svn/releases/Standarder/HL7/PHMR/Dokumentation/PHMR-DK-v2.1.0.pdf

QRD v1.3

HL7 Implementation Guide for CDA Release 2.0,
Questionnaire Response Document,
(Danish profile – DK QRD),

Release 1.3 February 11th 2022

https://svn.medcom.dk/svn/releases/Standarder/HL7/PRO/QRD/Dokumentation/DK-QRD-v1.3.pdf

 

QFDD v.1.2

HL7 Implementation Guide for CDA Release 2.0,
Questionnaire Form Definition Document,
(Danish profile – DK QFDD),

Release 1.2 February 11th 2022.

https://svn.medcom.dk/svn/releases/Standarder/HL7/PRO/QFDD/Dokumentation/DK-QFDD-v1.2.pdf

APD v2.0

HL7 Implementation Guide for CDA Release 2.0,
Appointment Document,
(Danish profile – DK APD),

Draft for Trial Use,
Release 2.0 November 4th 2019

http://svn.medcom.dk/svn/releases/Standarder/HL7/Appointment/Dokumentation/DK-APD-v2.0.pdf

Preparing Transformations by Assembling Required FHIR Resources

As described above, the transformations to CDA XML documents require that the client provides all the required FHIR resources. What FHIR resources must be part of the assembled FHIR bundle depends on the transformation.

When the eHealth infrastructure assembles FHIR resources to transform and upload to XDS-based document-sharing infrastructure, the assembled resources are fetched from the various eHealth services. Whether this is the case for a client’s possible use is up to the client, that is, they could be provided as in-memory FHIR resources that are not stored in the infrastructure.

Assembling FHIR Resources for Transformation to PHMR

A FHIR Bundle in-memory is prepared with the resources described below, based on a ClinicalImpression approving document sharing of the FHIR Observation. Typically, the assembly (and subsequent transformation and upload) is triggered by the creation of the ClinicalImpression, but might otherwise be triggered by a ServiceRequest update reflecting a Practitioner’s registering of the citizen’s decision to change sharing policy.

FHIR Resource

Logical Part in Transformation

Comment

FHIR Resource

Logical Part in Transformation

Comment

Observation (referenced from ClinicalImpression)

Observation Details

The Observation is the primary driver of the information contained in the generated PHMR document, including observation code, measured value and so on.

DocumentationOf (CDA Header)

 

 

Patient (possibly referenced from Observation.performer)

Author, Author Individual

When Observation.performer references the Patient, Author is the Patient

Practitioner (possibly referenced from ClinicalImpression.assessor)

When Observation.performer does not reference the Patient, Author is set to Practitioner referenced in ClinicalImpression.assessor (provided that ClinicalImpression.decision is approved-for-sharing)

Organization (referenced from ClinicalImpression.assessorOrganization)

Author, Author Organization

Author Organization is set to Organization referenced in ClinicalImpression.assessor (provided that ClinicalImpression.decision is approved-for-sharing)

 

 

 

 

DataEnterer

When Observation.quality contains ehealth-quality with:

  • qualityType = UQ (Usage Quality)

  • qualityCode = http://ehealth.sundhed.dk/cs/usage-quality | entered-manually

and Observation.performer type is Practitioner or Patient

Patient (referenced from ClinicalImpression.subject)

Patient Identification

Patient identifier (CPR number), name (given & family), gender, birth date (in format: yyyyMMdd000000+0000), telecom

Organization (referenced from EpisodeOfCare.managingOrganization) in EpisodeOfCare (referenced from ClinicalImpression.episodeOfCare)

Custodian Organization

SOR ID, name, telecom, address

Practitioner (possibly referenced from ClinicalImpression.assessor)

Legal Authenticator, Legal authenticator Individual

Legal authenticator is set only if the Observation has been approved for sharing manually (when ClinicalImpression.assessor is set and ClinicalImpression.decision is approved-for-sharing).

Organization (referenced from ClinicalImpression.assessorOrganization)

Legal Authenticator, Legal authenticator Organization

Composition (created as part of the assembly)

Document header (CDA Header)

The FHIR Composition resource represents the document and has fixed values as follows:

  • Document identifier

    • value = randomUUID

    • system = urn:oid: + OID value from NamingSystem.uniqueId.value (where uniqueId.type is oid) from eHealthIdentifier