MedMij FHIR Implementation Guide: PDF/A 2.0

Uit informatiestandaarden
Ga naar: navigatie, zoeken

Issue icon.png

Work in progress - See official publication here.

Naar medmij.nl
PDF/A
AfsprakenstelselFunctioneelTechnischAfspraken-Functioneel-Technisch

Introduction

Go to functional design

MedMij specifies the format PDF/A for exchanging unstructured documents containing health information. Forum Standaardisatie is a Dutch governmental organization that aims to stimulate the use of open standards. PDF/A is one of the standards that is recommended by Forum Standaardisatie. More information regarding PDF/A can be found here: https://www.forumstandaardisatie.nl/standaard/pdf-a1.

To achieve exchange of PDF/A files, MedMij adopts as much as possible from the Mobile access to Health Documents (MHD) profile from Integrating the Healthcare Enterprise (IHE) that defines a RESTful/HTTP interface to an XDS environment using HL7 FHIR STU3 resources. The MHD profile is written to be content agnostic and as such is suitable for much more than PDF/A. For this use case, we have limited the scope to PDF/A. The next section summarizes MHD and contains references to IHE MHD specification. The following sections provides an adaptation of the MHD profile to specify exchange of PDF/A documents in a MedMij context.

IHE MHD specification

Mobile access to Health Documents (MHD) profile defines a simple HTTP RESTful interface to an XDS like environment, based on HL7 FHIR. It describes four transactions:

  1. submit submission sets, folders, new documents, and document metadata from the mobile device to a document receiver (Provide Document Bundle),
  2. find submission sets matching query parameters (Find Document Manifest),
  3. find document entries containing metadata based on query parameters (Find Document Reference),
  4. retrieve a copy of a specific document (Retrieve Document).

These transactions leverage the document content and format agnostic metadata concepts from XDS but simplify them for access by constrained environments such as mobile devices, or other resource-constrained systems. The MHD profile does not replace XDS. It can be used to allow mobile devices, or other resource-constrained systems, access to an XDS health information exchange.[1]

Wiki: Mobile acces to Health Document (MHD)

Document: MHD Supplement (Rev 2.4 July 24, 2018)

Additional Supplement: Appendix Z on HL7 FHIR (Rev 1.2 July 21, 2017)

Actors and transactions involved

Table 1 shows the relevant actors, systems and FHIR capability statements in a MedMij context. The capability statements demonstrate the minimum requirements to be conformant to the full MHD specifications.

Persons Systems FHIR Capability Statements
Name Description Name Description Name Description
Patient The user of a personal healthcare environment. PHR Personal health record Verwijzing.png CapabilityStatement: Client PDFA FHIR Client requirements
Healthcare Provider The user of a XIS XIS Healthcare information system Verwijzing.png CapabilityStatement: Server PDFA FHIR Server requirements

Table 1. Actors, systems and FHIR capability statements

Table 2 shows the MHD actors and transactions in perspective of the systems used in a MedMij context.

Person System MHD Actors MHD Transactions
Patient
PHR
Document Consumer Find Document Manifests [ITI-66]
Find Document References [ITI-67]
Retrieve Document [ITI-68]
Document Source Provide Document Bundle [ITI-65]
Healthcare provider
XIS
Document Responder Find Document Manifests [ITI-66]
Find Document References [ITI-67]
Retrieve Document [ITI-68]
Document Recipient Provide Document Bundle [ITI-65]

Use case: Find and retrieve existing PDF/A document(s)

Note: The current version of find and retrieve existing PDFA will not be changed. The published version can be found here: https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_PDFA

Use case: Send PDF/A document(s)

This FHIR implementation guide assumes that the PHR system is able to make a connection to the right XIS that contains the patient's information. It does not provide information on finding the right XIS nor does it provide information about security. Moreover, each transaction is performed in the context of a specific authenticated patient, for whose context (token) has been established using the authentication mechanisms described in the 'Afsprakenstelsel'. Each XIS Gateway is required to perform filtering based on the patient associated with the context for the request, so only the records associated with the authenticated patient are returned. For this reason, search parameters should not be included for patient identification.

Go to Afsprakenstelsel

Introduction

Actors

Person System MHD Actors MHD Transactions
Patient PHR Document Source Provide Document Bundle [ITI-65]
Healthcare provider XIS Document Recipient Provide Document Bundle [ITI-65]

Send PDFA

PHR: Request message

When the patient (PHR) wants to send one or more PDF/A documents, it issues a send PDFA request message.

The PHR initiates a FHIR transaction using a create action by sending an HTTP POST request, composed of a FHIR Bundle resource containing one DocumentManifest resource, one or more DocumentReference resources, one or more Binary resources, one Patient resource, and zero or more Practitioner resources to the XIS recipient. References to the FHIR specification for the required transaction and POST requests are given in the interactions, operations and search parameters section below.

The PHR executes an HTTP POST against the XIS's base endpoint as shown below.

POST [base] {?_format=[mime-type]}

Read more:

The resources in the message SHALL be a valid instance of the listed StructureDefinitions below. All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.

Example - Bundle structure

<?xml version="1.0" encoding="UTF-8"?>
<Bundle xmlns="http://hl7.org/fhir">
    <type value="transaction"/>
    <entry>
        <fullUrl value="urn:uuid:96cf0274-9b2c-4bdc-b4c4-cb46f7a07097"/>
        <resource>
            <Patient xmlns="http://hl7.org/fhir">
                <!-- SNIP -->
            </Patient>
        </resource>
        <request>
            <method value="POST"/>
            <url value="Patient"/>
        </request>
    </entry>
    <entry>
        <fullUrl value="urn:uuid:278764fb-06b6-4f4f-8cef-4abaa3682111"/>
        <resource>
            <DocumentManifest xmlns="http://hl7.org/fhir">
                <!-- SNIP -->
            </DocumentManifest>
        </resource>
        <request>
            <method value="POST"/>
            <url value="DocumentManifest"/>
        </request>
    </entry>
    <entry>
        <fullUrl value="urn:uuid:2aa911db-9117-4e4b-97e4-d2f09dd28111"/>
        <resource>
            <DocumentReference xmlns="http://hl7.org/fhir">
                <!-- SNIP -->
            </DocumentReference>
        </resource>
        <request>
            <method value="POST"/>
            <url value="DocumentReference"/>
        </request>
    </entry>
    <entry>
        <fullUrl value="urn:uuid:6d035264-66ac-4df2-8bf8-d9a9bbf46111"/>
        <resource>
            <Binary xmlns="http://hl7.org/fhir" >
                <!-- SNIP -->
            </Binary>
        </resource>
        <request>
            <method value="POST"/>
            <url value="Binary"/>
        </request>
    </entry>
</Bundle>

XIS: Response message

The target XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

The target XIS SHALL return a Bundle with type set to transaction-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Handling Errors

When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error, and perform a rollback of the creation of any previous entries.

Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):

  • 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

Read more:

Interactions, operations, search parameters

Interactions

The following logical interactions are needed for this use case:

Operations

There are no defined operations for this use case.

Search parameters

No search parameters are needed for this use case.

List of StructureDefinitions

IHE has defined StructureDefinitions applicable to this use case. Although the IHE MHD Profile text (the published PDF) is Normative these conformance resources are labelled as Informative. Not all IHE MHD profiles are implementable as-is for the send use case because of errors that IHE does not intend to resolve in FHIR STU3, but instead, require updating to FHIR R4. MedMij is not ready upgrading to FHIR R4 for just this use case and has implemented the necessary fixes in the IHE FHIR STU3 profiles to support this use case. The IHE MHD profiles 'IHE.MHD.DocumentManifest' and 'IHE.MHD.ProvideDocumentBundle.Minimal' are therefore copied, adjusted for the known issues and released under Nictiz. The table below shows the IHE MHD profiles used for the Providing Document Bundle transaction and the relevant HCIM profiles.

Em.png

MedMij uses the FHIR Packaging mechanism. This conveniently bundles all examples, profiles and other conformance resources you need into a single download. For more background information see the the FHIR implementation guide. This version of the information standard depends on Nictiz package 1.1.4. Please note that the direct links to the various conformance resources below will take you to the latest version, which might not match the package version. At time of writing, there is no way to render the conformance resource as found in the package. This is on the roadmap for Simplifier.
ZIB name NL ZIB name EN FHIR Resource URL profile
Patient Patient Patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient
Zorgverlener HealthProfessional Practitioner http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner
PractitionerRole http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole
Zorgaanbieder HealthcareProvider Organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization
- - Bundle * http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Minimal
- - DocumentManifest * http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest
- - DocumentReference http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Provide.Minimal.DocumentReference
- - List http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.List

'* Adjusted version of IHE MHD profiles by Nictiz.

Annex: Document history

Release notes

Release notes can be found on the functional design page.

History

Release Date Description
01-08-2019
  • Added Nictiz copy of profiles for IHE MHD DocumentReference and List for reference integrity.
29-07-2019
  • Added IHE MHD and Nictiz correction of IHE MHD profiles for send use case
  • Adjusted CapabilityStatement for this profiles
  • Added IHE MHD transaction numbers (e.g. ITI-65) to transaction tables
01-07-2019
  • Changed URL's for MHD documents to correct FHIR STU3 version
09-05-2019
  • Restructured wiki page
  • Added send PDFA use case
  • MedMij coloured tables
2019.01 11-03-2019
  • Publication of changes in version 2019.01, conform release notes
  • Moved release notes to the functional design page.
2019.01 11-03-2019
  • Added StructureDefinitions of HCIMs for administration components which are applicable for this use case.
2018.06 15-10-2018
  • Added document history.
  • Added version in title.
  • XIS constraint based on BITS issue MSFOC-49.