MedMij FHIR Implementation Guide: PDF/A

Dit is een tijdelijke pagina met wijzigingen voor issue MM-5349. De gepubliceerde versie vind je hier.

Work in progress - See official publication here.

1 Introduction

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-nen-iso.

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.

When implementing PDF/A, a minimum compliance must be assumed. That is, PDF/A-1 and PDF/A-b are also permitted within this. For more information, see the wiki page on this: https://en.wikipedia.org/wiki/PDF/A#Conformance_levels_and_versions

Note: This implementation guide builds on the general guidelines described in the use case overarching principles.

1.1 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)

2 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	CapabilityStatement: Client	PDF/A FHIR Client requirements
Healthcare Provider	The user of a XIS	XIS	Healthcare information system	CapabilityStatement: Server	PDF/A 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]

3 Boundaries and Relationships

3.1 masterIdentifier versus identifier

Both the DocumentReference and DocumentManifest resources contain the elements .masterIdentifier and .identifier. These identifiers each have different usages.

• The .masterIdentifier is assigned by the source of the document/manifest. There is always exactly one .masterIdentifier present for each DocumentReference/DocumentManifest resource (i.e. this element has cardinality 1..1 in both underlying profiles), and this identifier is used to uniquely identify that resource (and is often used in non-FHIR contexts for this purpose as well). In particular this identifier is version dependent, as each DocumentReference/DocumentManifest resource corresponds to a specific version of a document/manifest. Updating a document/manifest thus results in a new resource with a different .masterIdentifier.
• All other identifiers associated with the document/manifest can be included in the resource as .identifiers, including the version independent ones. Thus such an identifier could occur in multiple DocumentReference/DocumentManifest resources, where each resource represents a different version of the same document/manifest; in that case it can be seen as a bundling mechanism for these different versions.
  Note that DocumentManifest.identifier is mandatory (while DocumentReference.identifier isn't) without justification from the data set, since all 'Identification' (Dutch: 'Identificatie') concepts in the data set are mapped to masterIdentifier instead of identifier. This is a legacy of the IHE MHD specification.

4 Use case: Find and retrieve existing 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.

4.1 Introduction

This section summarizes the IHE MHD profile to find and retrieve PDF/A documents in a MedMij context.

4.2 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	CapabilityStatement: Client	PDF/A FHIR Client requirements
Healthcare Provider	The user of a XIS	XIS	Healthcare information system	CapabilityStatement: Server	PDF/A 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	Optionallity
Patient
	PHR
		Document Consumer	Find Document Manifest	Optional
			Find Document Reference	Required
			Retrieve Document	Required
Healthcare provider
	XIS
		Document Responder	Find Document Manifest	Optional
			Find Document Reference	Required
			Retrieve Document	Required

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

Implementation of the 'Find Document Reference' and 'Retrieve Document' transactions are required. The 'Find Document Manifest' transaction is optional for both the Document Consumer and Document Responder.

4.3 Find and retrieve existing PDF/A document(s)

4.3.1 Find PDF/A or PDF/A collection

Discovery of PDF/A documents is done with the MHD defined transaction 'Find Document Reference' or 'Find Document Manifest.' The Find Document Reference retrieves FHIR DocumentReference Resources that represents a single reference to document per resource, for example, one PDF/A file. The Find Document Manifest retrieves FHIR DocumentManifest Resources. A DocumentManifest Resource gathers a set of DocumentReference Resources into a single package together with metadata that applies to the collection.

The Document Consumer requests DocumentReference or DocumentManifest Resources, matching a set of criteria, from the Document Responder. The Document Responder returns DocumentReference or DocumentManifest Resources that match the search criteria provided by the Document Consumer.

4.3.1.1 Request message

Search

The Document Consumer executes an HTTP GET conform to the FHIR RESTful and search specification. A search query would have the following format.

GET [base]/DocumentReference?status=[status]{&[parameters]}
GET [base]/DocumentManifest?status=[status]{&[parameters]}

An example query to search for DocumentReferences which have status current and which are indexed/created after 01-01-2010:

GET [base]/DocumentReference?status=current&indexed=ge2010-01-01

Search Parameters The Document Consumer shall include search parameter status. The Document Consumer may supply, and the Document Responder shall be capable of processing, all search parameters listed below. These search parameters are a selection of the defined search parameters by the IHE MHD profile. The IHE MHD profile contains more search parameters that were deemed to pose a disproportionate implementation burden for Document Responders. The following subselection still allow Document Consumers with server-side filter capabilities while making this use case more implementable for Document Responders.

DocumentReference			DocumentManifest
Name	Type	Description	Name	Type	Description
indexed	date	When this document reference was created	created	date	When this document manifest created
status	token	current / superseded	status	token	current / superseded

4.3.1.2 Response message

The Document Responder shall process the query to discover the DocumentReference or DocumentManifest entries that match the search parameters given. The Document Responder returns an HTTP status code appropriate to the processing as well as a Bundle including the matching DocumentReference or DocumentManifest Resources.

• The Document Responder shall place into the DocumentReference.content.attachment.url element a full URL that can be used by the Document Consumer to retrieve the document using Retrieve Document transaction.
  • The Document Responder shall only include references which are resolved through the Document Responder to maintain control over the authentication and authorization. The Document Responder shall only serve DocumentReference or DocumentManifest resources that contain a reference which the Document Consumer may resolve.
• The Document Responder shall return only PDF/A documents and shall place into the DocumentReference.content.attachment.contentType element the value application/pdf.

4.3.2 Retrieve PDF/A document

After obtaining the location of the PDF/A document in the DocumentReference.content.attachment.url, the Document Consumer requests the document from the Document Responder. The Document Responder sequentially serves the PDF/A document to the Document Consumer. The context that was established in the initial request shall also apply when retrieving/serving the document contents.

4.3.2.1 Request Message

This message is an HTTP GET request to retrieve the document. See an example below.

GET http://example:9556/svc/fhir/Binary/1e404af3-077f-4bee-b7a6-a9be97e1ce32

The Document Consumer may provide an HTTP Accept header, according to the semantics of the HTTP protocols (see RFC2616, Section 14.1). The only MIME type assured to be returned is the MIME type indicated in the DocumentReference.content.attachment.contentType. Within MedMij this is set to application/pdf. The HTTP If-Unmodified-Since header shall not be included in the GET request.

4.3.2.2 Response Message

The Document Responder shall process the request message. The Document Responder returns an HTTP status code appropriate to the processing as well as the content of the requested PDF/A document in the HTTP message body.

The document may be placed inside a FHIR Binary resource if it is useful to handle pure binary content using the same framework as other resources. Binary resources behave slightly differently from all other resources on the RESTful API. Specifically, when a read request is made for the Binary resource that doesn't explicitly specify the FHIR content types application/fhir+xml or application/fhir+json, then the content should be returned using the content type stated in the resource. e.g. if the content type in the resource is application/pdf, then the content should be returned as a PDF directly.[2]

4.4 List of profiles

IHE has defined profiles and other conformance resources applicable to this use case. The FHIR Implementation Guide on the IHE MHD wiki lists these conformance resources.

Due to errors encountered when creating the send use case, that IHE did not intend to fix in STU3, Nictiz has fixed the errors and re-published the IHE.MHD profiles in the Nictiz namespace. Note that IHE originally created two profiles, one for Query DocumentReference and one for Provide DocumentReference which are identical to each other. For usability purposes, these two profiles have been merged.

Find and retrieve existing PDF/A document transaction uses the following profiles:

• DocumentReference from Query with Minimal Metadata (canonical URL http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference)
• DocumentManifest (canonical URL http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest)

The complete set of used profiles for the response message is listed in the table below.

MedMij uses the FHIR Packaging mechanism. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages: nictiz.fhir.nl.stu3.zib2017 version 2.0.0 or compatible (latest is ) Note: packages use Semantic Versioning. Other versions can be used at will as long as they have the same major.minor number or a minor number higher than the stated version.

Zib name NL	Zib name EN	FHIR Resource
Patient	Patient	Patient	http://fhir.nl/fhir/StructureDefinition/nl-core-patient
Zorgverlener	HealthProfessional	Practitioner	http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner
Zorgaanbieder	HealthcareProvider	Organization	http://fhir.nl/fhir/StructureDefinition/nl-core-organization
-	-	DocumentManifest	http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest
-	-	DocumentReference	http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference

5 Use case: Send PDF/A document(s)

5.1 Introduction

This section summarizes the IHE MHD profile to Send PDF/A document(s) in a MedMij context.

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.

5.2 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]

5.3 Send PDF/A

5.3.1 PHR: Request message

When the patient (PHR) wants to send one or more PDF/A documents, it issues a send PDF/A 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 below.

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

POST [base]

Read more:

• transaction
• create

5.3.2 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.

5.4 List of profiles

IHE has defined profiles 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.Minimal.ProvideDocumentBundle' are therefore copied, adjusted for the known issues and released in the Nictiz namespace. The table below shows the IHE MHD profiles used for the Providing Document Bundle transaction and the relevant HCIM profiles. Note that IHE originally created two profiles on DocumentReference, one for Query DocumentReference and one for Provide DocumentReference which are identical to each other. For usability purposes, these two profiles have been merged.

MedMij uses the FHIR Packaging mechanism. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages: nictiz.fhir.nl.stu3.zib2017 version or compatible Note: packages use Semantic Versioning. Other versions can be used at will as long as they have the same major.minor number or a minor number higher than the stated version.

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.Minimal.ProvideDocumentBundle
-	-	DocumentManifest	http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest
-	-	DocumentReference	http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference
-	-	List	http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.List

Even though the table above contains all profiles based on IHE MHD applicable to this use case, both the Bundle and List profiles aren't explicitly used within the PDF/A information standard, and are merely listed for completeness purposes.

6 Known-issues

Several technical issues have been identified with the current PDF/A information standard. These issues are outlined below and will be addressed in the next major release:

• Author: In the current version of the standard, the DocumentManifest and DocumentReference profiles do not allow the patient to be the author. This functionality will be included in the next major release.
• Class: For the .class element, the coding standard advised in the DocumentReference and DocumentManifest profiles and the qualification FHIR resources (i.e., LOINC) differ from the coding standard listed in Art Decor, which requires SNOMED. In the next major release, all sources will align, and a unified code list will be implemented.
• Type: Similar to .class, the preferred code lists for .type vary across the DocumentReference and DocumentManifest profiles and the qualification FHIR resources (i.e., LOINC), as opposed to Art Decor, which requires SNOMED. The next major release will standardize these code lists across all sources.
• Created: The .created element was removed from the DocumentReference profile. This issue (CP-ITI-1100) can be found on the IHE MHD wiki. Therefore, the qualification restricts the use of the .created element and the .indexed element is used to capture creation time. It remains in Art Decor and will also be reintroduced in the DocumentReference profile the next major release.
• docStatus: Like .created, this element was removed from the DocumentReference profile while it is still included in Art Decor. It will be reintroduced in the DocumentReference profile next major release.
• Status: As mentioned above, the DocumentReference profile omitted the .docStatus element. Therefore, the qualification restricts the use of the .docStatus element and the .status element can be included in the queries. However, Art Decor does not contain the element "Status" but does contain "docStatus" (referred to as "Status" there). Therefore, there is currently no functional and technical agreement on what "Status" refers to: the document or the DocumentReference.
• Duplicates: Currently, there is no system in place to prevent receiving duplicate documents in the PGO. A Nictiz-wide project is underway focused on the unique identification of objects. Once this project is completed, the results will be integrated into the PDF/A standard, ensuring that PGO users will only receive unique documents.

7 Release notes

Release notes can be found on the functional design page.

8 Support

For questions and change requests regarding the information on this page, please create a ticket in Servicedesk Portal.