MyHealth@Eu NCPeH API
0.0.1 - ci-build 150

MyHealth@Eu NCPeH API - Local Development build (v0.0.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Document Provisioning

This page describes the implementation options of Document Provision task.

Business View

The overall business scenarios associated to this task is described in the Business view page

Application View

The implementation-indipendent sequence diagrams associated to this task is described in the in the Application view page

Implementation pre-requisites

The Myhealth@EU general architecture requires that no assumptions are made on the way the service is implemented at the national level.

This implies that any solution adopted for the NCPeH to NCPeH communications has to work properly indipendently by the fact that a HL7 FHIR server, or an XCA registry/repository or any other solution solution is locally adopted.

Implementation alternatives

As for the other services, there are multiple alternatives, not mutually exclusive, for providing documents using the HL7 FHIR API.

The selected mechanism may depend on the type of document and the usage context.

In this first version, this service will be realized by posting (creating) or putting (updating) a DocumentReference, depending on the operation required.

Some alternatives - described only for documentation purposes - are listed below:

  1. posting/putting a FHIR document (Bundle)
  2. posting the resources that compose a FHIR document

Please note that Bundle transaction or batch can be used to issue multiple POST or PUT actions (e.g. providing multiple documents).

The service provider SHALL support transaction and batch interactions as described by the HL7 FHIR standard

Implementation

The main advatage of this solution is that of using the same mechanism for providing the document independently by its format. For example it could include and/or refer the PDF and the corresponding FHIR (or CDA) representation.

A DocumentReference resource can refer to or include multiple representations of the same document.

In the following diagram is described how the requesting NCP provides the document by using the DocumentReference.

Responding NCPResponding NCPRequesting NCPResponding NCPRequesting NCPRequesting NCPResponding NCPResponding NCPResponding NCPResponding NCPSend Metadata/DocumenteHDSI Transform, TranslateeHDSI DocumentReference Send RequesteHDSI TranslateRequest processedeHDSI DocumentReference Send Responseopt[Update Metadata/Document]eHDSI Transform, TranslateeHDSI DocumentReference Update RequesteHDSI TranslateRequest processedeHDSI DocumentReference Update Response

Figure 1 - Document Provisioning

Step-by-Step Breakdown: DocumentReference Send

This transaction uses the same call used by the IHE Simplified Publish [ITI-105] transaction
eHDSI DocumentReference Send Request

The Requesting NCP initiates a send request by sending an HTTP POST request method composed by an eHDSI DocumentReference

The document to be provided SHALL be encoded in the DocumentReference.content.attachment.data element.

Each DocumentReference may return or refer one or more representations (e.g. PDF, HL7 CDA, HL7 FHIR json) of the same document.

  POST $server/DocumentReference
eHDSI DocumentReference Search Response

In case of success the Responding NCP returns a DocumentReference of type eHDSI DocumentReference with the logical identifier assigned by the receiving partner.

If supported, this id can be used for updating the resource.

HTTP Error Response Codes

In case of processing failure the Responding NCP returns one of the following errors :

HTTP Response Description
400 Bad Request resource could not be parsed or failed basic FHIR validation rules
404 Not Found resource type not supported, or not a FHIR end-point
422 Unprocessable Entity the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail
Examples

POST myNCP.xyz/fhir/DocumentReference

Step-by-Step Breakdown: DocumentReference Update

eHDSI DocumentReference Update Request

The Requesting NCP initiates an update nd request for a DocumentReference using the FHIR API:

  PUT $server/DocumentReference/[docrefid]

[docrefid] is the id of the DocumentReference resource to be updated.

DocumentReference complies with the eHDSI DocumentReference

Each DocumentReference may return or refer one or more representations (e.g. PDF, HL7 CDA, HL7 FHIR json) of the same document.

eHDSI DocumentReference Update Response

In case of success the Responding NCP returns a DocumentReference of type eHDSI DocumentReference.

HTTP Error Response Codes
HTTP Response Description
400 Bad Request resource could not be parsed or failed basic FHIR validation rules (or multiple matches were found for conditional criteria)
401 Not Authorized authorization is required for the interaction that was attempted
404 Not Found resource type not supported, or not a FHIR end-point
405 Method Not allowed the resource did not exist prior to the update, and the server does not allow client defined ids
409/412 - version conflict management see Managing Resource Contention
422 Unprocessable Entity the proposed resource violated applicable FHIR profiles or server business rules
Examples

PUT myNCP.xyz/fhir/DocumentReference/12345