1       Introduction

1.1          Purpose

With the Document Sharing Services (DDS), services have been established for sharing of documents in the health care domain. These document sharing services provide the opportunity for performing queries on which documents are registered for a given patient and subsequently retrieving the documents.

The present document provides an overview of the document sharing services and how they can be used. The document is intended as a starting point for more detailed documentation.

1.2          Reading Guide

The intended audience are developers and architects about to use document sharing services. Concepts are briefly explained with references to where more elaborate material can be found. As a reading guideline, references to additional documentation given in square brackets should suffice while references to additional material given as footnotes can be skipped.

Note that this document is a draft.

1.3          Document History

1.4          Definitions and References

2       Overview of Document Sharing

A health professional can by use of the document sharing service obtain an overview over which documents concerning a given patient that different health system have registered in a document sharing registry. In the registry, metadata is registered about documents, i.e. information about the documents, not the actual documents. Subsequently, a health professional can select which document(s) to obtain, whereby the documents are retrieved from the health systems. Correspondingly, a citizen can obtain an overview of documents registered about him or herself.

2.1     Actors in Document Sharing

Sharing of documents takes place through the following actors:

• Document source is an actor that registers metadata concerning its documents in a registry and provides access for retrieval of these documents.
• Document sharing service is an access point for querying against the registry, retrieving of documents and registration of metadata about documents.
• Registry is an actor where metadata about documents is stored.
• Document consumer is an actor that performs querying for metadata and typically also performs retrieving of documents. Often, the clinical purpose for this is to provide a health professional with an overview of information available about a given patient and the ability to select particular documents for closer examination.

2.2     Usage Scenarios

The usage scenarios described in the following are divided into those relevant for document sources and those relevant for document consumers, respectively.

2.2.1      Document Source Usage Scenarios

A document source has a (clinical) document about a patient and wants to make this accessible to a wider audience through the Document Sharing Services. To do this, the document source collects metadata about the document and registers these metadata at the Document Sharing Services, as depicted in step 1) in Figure 1. On receiving the metadata, the Document Sharing Service 2) forwards the metadata to its registry.

Figure 1 Document source registers metadata about a document it can provide.

As will be described shortly, the document source must be able to provide the document when requested by the Document Sharing Services.

2.2.2      Document Consumer Usage Scenarios

A document consumer wants to get an overview of available documents about a patient and/or get the content of one or more available documents. Typically, the document consumer wants to do both.

The overview of available documents about a patient is obtained by performing a query for document metadata about a patient, as depicted in Figure 2.

Figure 2 Document consumer querying for metadata about a patient. 

The steps involved are: 1) the document consumer submits a query request containing query parameters to the Document Sharing Service, that 2) forwards the query request to a registry and 3) returns found metadata as response to the query.

When a health professional wishes to view a document, it is retrieved as shown in Figure 3.

Figure 3 Document consumer retrieves selected documents from the Document Sharing Services using metadata.

Based on metadata, 1) the document consumer creates a document retrieve request and sends it to the Document Sharing Service that 2) forwards the request to the document source that registered the metadata. 3) The document source retrieves the requested document and returns it to the Document Sharing Service which 4) returns it to the document consumer.

2.3     Agreed Formats, Encoding Systems, and Value Sets

Technically, the document sharing actors interact independently of document formats. Typically, actors have agreed upon which formats are accepted. For metadata, that is, the descriptive data about documents, a standard model is used of such generality that it can provide metadata using values from different classification and encoding systems.

For instance, the metadata attribute containing a patient’s ID would contain:

• an identification of the attribute stating that it contains the patient ID
• the actual  ID (in Danish context, a social security number aka CPR number)
• the name/ID for the organization responsible for issuing the ID.

Collectively, the formats, classification systems, encoding systems, value sets and so forth used for metadata shall be known as metadata definitions.

To ensure that documents and metadata can be exchanged meaningfully, document definitions are agreed upon beforehand between the document sharing actors.

In principle, the Document Sharing Services can be used with a variety of metadata definitions with constraints applying only to a small but significant part. In practice, the Document Sharing Services are, however, known to be used with the metadata definitions described in [Metadata Profile].

2.4     Adhering to the Health Act

Sharing of documents in the health care domain is subject to the Health Act’s provisions, including provisions concerning retrieval of electronic health information. It is the responsibility of the individual organizations and systems to adhere to the Health Act. For instance, this entails that a. document consumer must ensure that queries and retrieving of documents are performed only when justified, that is, when the information is needed and while the patient is undergoing treatment.

Part of the Health Act provisions is that the patient may have consents governing access to his or her information and that such consents must be observed.

In the following, it is described how the document sharing actors split the responsibility for observing consents.

2.4.1      Consent

A citizen can provide so-called positive consent whereby a health professional is allowed to access information about the citizen. By negative consent, the citizen can oppose any or selected health professionals obtaining access to information about the citizen.

Under the auspices of NSI, a service for administration of consents has been established where positive and negative consents can be created, changed, and terminated. A consent can be general, i.e. independent of the specific information, or specific, i.e. attached to specific information. The latter is also designated a data-specific consent. A consent can apply to either all or specific health professionals, and likewise for organizations that a health professional is associated with at the time of access.

Also under the auspices of NSI, a service has been established which, based on a citizen’s consents, provides decision on whether a health professional is allowed to access information about the citizen (as a patient). Given the patient ID and context for a health professional, including the health professional’s ID and associated organization, this service decides whether the health professionals’ access:

• Must be limited due to general negative consent(s)
• Is unrestricted, e.g. in absence of negative consents or presence of positive consents
• Is conditionally restricted, i.e. depends on the specific information. This would be the case if, for instance, negative data-specific consent has been registered while a general positive consent for the health professional does not give access.

2.4.2      Responsibility for verification of consents in document sharing

Responsibility for verification of consent is split between the actors in document sharing as follows:

• Document sharing services must verify both general and data-specific consents on querying for document metadata
• Document sharing services must verify general consents on retrieving of documents.
• The document source must verify data-specific consents
• The registry does no verification, as it is accessed only through the document sharing services.
• Document consumer performs no verification, but is responsible for correctly communicating information about patient ID and the health professional’s context.

Actions to take on consents blocking access:

• Document sharing services must filter the results to be returned on requests
  • When general and data specific consents block metadata query results
  • When general consents block document retrieving
  • Document sources must filter the results of document retrieving when data specific consents blocks access
  • The document consumer should warn or otherwise indicate to the user that information has been withheld due to consent restrictions, that is, that the presented results do not constitute all existing information. A marking in results from the document sharing services signifies when information has been withheld.

2.4.3      Bypassing consent in emergency situations

On querying for metadata and retrieving of documents, it is possible to perform so-called consent override (in Danish: værdispring) by which the patient’s consents are bypassed and the querying/retrieving is completed without the blocking that the consents would ordinarily impose. Document sharing services perform separate logging of requests made with consent override in order to support auditing.

Consequently, if a document consumer allows a user to perform consent override, it should be made clear to the user that overriding of consents is possibly subjected to auditing.

3      Use of Document Sharing Services

In this section, the concepts for use of document sharing services are described.

3.1     Access to Document Sharing Infrastructure

Document sharing is going to take place in a production environment where actors are connected by the Health data net (Danish: Sundhedsdatanettet) and where Document sharing services are executed on the National Service Platform (NSP).

To use the document sharing services, an agreement between NSI and your organisation must be made stating terms and responsibilities.

3.2     Web Services Provided by Document Sharing Services

The web services provided by the Document sharing services provide methods for:

• Document consumers to query for document metadata and retrieve documents, as described in [Query and Retrieve User Guides]
• Document sources to register document metadata about documents they provide, as described in [Register User Guide]

The web services provided by the Document sharing services are based on:

• Integrating the Healthcare Enterprise (IHE) Cross-Enterprise Document Sharing (XDS.b)
• Security through use of Den gode webservice (DGWS) version 1.0.1
• Passing of usage context through use of the Health Service User Identification (HSUID) header

Interfaces for Document sharing services are described in [Interfaces], including necessary XDS.b-structures and DGWS. In the interface descriptions, it is specified how a document consumer detects possible filtering due to consent-imposed restrictions in responses to query and document retrieve requests.

3.2.1      XDS.b Profiles Used by Document Sharing Services

The Document Sharing Services support the following XDS.b[1] profiles for cross-enterprise document sharing:

• ITI-18 Registry Stored Query
• ITI-43 Retrieve Document Set
• ITI-42 Register Document Set-b
• ITI-61 Register On-Demand Document Entry

These profiles describe web service interfaces for querying for document metadata, retrieving of documents, and registration of document metadata. The profiles specify the structure of requests and responses from the web service in addition to the expected behaviour.

3.2.2      Security

Den gode webservice (DGWS)[2] version 1.0.1 specifies how security information must be exchanged between a web service consumer and a web service provider. DGWS prescribes use of the so-called ID card that identifies the user system and possibly the user, in addition to Offentlige Certifikater til Elektronisk Service (OCES) digital signature.

The web services provided by the Document Sharing Services employ a federated security model based on DGWS. A user system, whether it is document consumer or document source, establishes a security context as described in the following. In Figure 4 this is depicted for a document consumer querying for metadata.

Figure 4 Steps in establising a security context when using the Document Sharing Services.

On use of a web service provider based on DGWS, the web service consumer creates and fills in an ID card with data describing the user system and possibly the user and then signs it digitally using a certificate. The web service consumer sends 1) the signed ID card in a request to a Security Token Service known and trusted by the web service consumer as well as the web service provider. The STS verifies the signature and certain information in the ID card, and replaces the signature with one created using the STS certificate. This is 2) returned to the web service consumer.

The web service consumer can now 3) create a request to the desired web service operation, add the STS-signed ID card, and send it to the DGWS-based web service provider. Note that the web service consumer can reuse the STS-signed ID card as long as it is valid.

On receiving a request, the web service provider 4) verifies the STS signature, authorises the web service consumer, and performs the web service operation. In this case, it would be forwarding the request to the associated registry, and return the response to the document consumer consisting of the found document metadata.

The security level required by the web services of the Document Sharing Services will be evident from the service consumer agreement. If security level 3 is required, the web service consumer must use a company certificate, while an employee certificate must be used for security level 4.

A web service consumer must be authorised to use to the Document Sharing Services in order to make successful requests. This is handled as part of processing of the service consumer agreement, by adding the CVR number of the service consumer organization to a whitelist.

3.2.3      Usage Context (Document Consumer Only)

Whether the document consumer actor’s user is a citizen or health professional, the following must be provided: Type of user (citizen or health professional), system owner, name, and version of system in addition to the id of the organization responsible for operations (in Danish: driftsorganisation).

For a user who is a citizen, the social security number must be stated – as user and possibly as patient ID.

For a health professional, different information must be provided:

• Social security number
• Authorization ID in Danish Health Authority’s authorization register

If the health professional does not have an authorization ID, there is a possibility that the person works on behalf of or under supervision of one that has. In such case, the social security number and authorization ID of the health professional under whose responsibility the work is performed, must be provided.

It must be stated which organizational unit, the health professional belongs to. The organizational unit can be provided in several ways:

• Health service organization register[3] (SOR)
• General practitioner number (in Danish: ydernummer) of general practitioners, medical specialists, that can be looked up in SOR
• Hospital department number or hospital section number in the Hospital department classification[4] (in Danish: Sygehusafdelingsklassifikation)

3.3     Web Service Exposed by Document Source

A document source is required to expose a web service for retrieving of documents such that the Document Sharing Services can access it.  

As described above, the Document Sharing Services must forward document retrieve requests to document source’s web service. Prior to this, the service endpoint of the document source’s web service must be added to the document sharing service configuration.

4      Getting Started

This is the fast track to trying out the Document Sharing Services as a document consumer.

4.1     Get Access to the Test Environment

The Document Sharing Services and test data are available in one or more test environments, and possibly also in education, and pre-production environments.

An agreement for getting access to either environment must be made using the application form at https://www.nspop.dk/pages/viewpage.action?pageId=3672761.

4.2     Get and Run the Example Code

Code examples exists for Java that can be used to try out the document sharing services in practice. See [Examples] for descriptions of how to build the software and perform querying and retrieving of documents. The examples use a test certificate included with the code.

[1] ITI TF-2a: IHE IT Infrastructure Technical Framework, Volume 2a (accessible as http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2a.pdf) and ITI TF-2b: IHE IT Infrastructure Technical Framework, Volume 2b (accessible as http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf). These are linked from http://ihe.net/Technical_Frameworks/#IT.

[2] https://digitaliser.dk/resource/248323

[3]http://www.ssi.dk/Sundhedsdataogit/Standardisering/TerminologiOgKlassifikationer/SOR.aspx

[4]http://www.ssi.dk/Sundhedsdataogit/Standardisering/TerminologiOgKlassifikationer/SHAK.aspx