Send documents

Introduction

By implementing the “Send documents” component in a connector with ZorgDomein, you enable your application to initiate the creation of clinical documents such as appointment requests, referral letters, healthcare requests, reports and transfer dossiers directly from your application. As a general principle the clinical document will be composed in ZorgDomein based on clinical details that the application of the sender supplies to ZorgDomein. Also, the recipient of the document will be chosen in ZorgDomein.

This implies that the user will have to login to ZorgDomein to compose the document and choose the desired recipient. Hence the implementation of the SSO to ZorgDomein component is prerequisite to make a functional implementation of the “Send documents” component.

Please note that the “Send documents” component only supports the HL7 FHIR standard.

Transactions and document types

Most of the core functionalities of the ZorgDomein application are based on the concept of transactions. Each transaction involves the exchange of one or more documents to transfer the request or message. ZorgDomein has implemented different document types that are used in the different transaction types. See the functional documentation of transactions and documents for more details.

Getting patient context

All clinical documents that are sent with ZorgDomein are composed in the context of a patient. As part of the SSO, context parameters like patient and healthcare insurance details are requested at the application of the sender. See the SSO to ZorgDomein component for details.

Suggesting a recipient

When the patient context has been set, the user can start the flow for finding the recipient of the document in the ZorgDomein UI. When sending a report or a transfer dossier it is possible for the application of the sender to suggest a recipient through the FHIR interface. This can be achieved by providing the name or AGB-code of the intended recipient in the following elements of the Task resource that ZorgDomein requests during SSO:

• Task.owner.display: name of the intended recipient.
• Taks.owner.identifier.value where Task.owner.identifier.system = "http://fhir.nl/fhir/NamingSystem/agb-z": value of the AGB-code of the intended recipient.

If Task.owner is set, ZorgDomein will use this value to search for a known recipient in ZorgDomein and will suggest a recipient based on this search result.

The feature of suggesting a recipient is only supported for reports and dossier transfers (and not for referrals and requests for healthcare services or products).

Composing the document

When the recipient has been selected, the user can start composing the document in the ZorgDomein UI. A document is composed using a web form that consists of multiple questions and corresponding input fields. ZorgDomein supports many different document templates, which all consist of a number of different questions and corresponding input fields. These input fields can be linked to specific HL7 FHIR queries. For each input that is linked to a FHIR query, ZorgDomein will perform the FHIR query at the application of the sender. The response to this query will be used to prepopulate the input field in ZorgDomein. This way a large part of the document in ZorgDomein can be prepopulated with data from the application of the sender.

Currently ZorgDomein supports FHIR queries for the following fields and corresponding FHIR resource profiles (Dutch field names will be used):

Note that only a subset of these fields may be present in a document template in ZorgDomein.

Adding attachments to documents

Some document types in ZorgDomein support attachments, i.e. binary files that are added as an attachment to the document. If a document type support attachments, ZorgDomein will query relevant attachments at the information system of the sender. This is done in two ways:

• When opening the web form for document generation, ZorgDomein will perform a FHIR search request at the DocumentReference endpoint. This query includes a related-id parameter which contains the id of the Task resource that was provided to ZorgDomein at SSO. This way ZorgDomein queries for attachments that are directly related to the task or transaction in the information system of the sender. These attachments will be added automatically to the document in ZorgDomein.
• The web form for document generation also contains a dedicated button to select additional attachments from the information system of the sender. When clicking this button, the ZorgDomein UI will display a modal that should list additional attachments from the information system of the sender. ZorgDomein will query these attachements by a FHIR search request at the DocumentReference endpoint. After the XIS has returned the DocumentReference resources to ZorgDomein and the user has selected one or more documents to attach to the referral letter, ZorgDomein will query the selected Binary resources and add these to the document.

Note the that the DocumentReference resources that are returned to ZorgDomein should not contain the binary file by itself, but must contain a reference to a Binary resource in DocumentReference.content.attachment.url. ZorgDomein will perform individual GET requests for this reference to obtain the actual binary data of each attachment. This url must point to a Binary resource (eg https://[FHIRServerUrl]/Binary/1234) that contains the binary data of the attachment.

This mechanism for retrieving attachments is based on the MedMij PDF/A standard for exchanging unstructured documents containing health information. MedMij adopts as much as possible from the Mobile access to Health Documents (MHD) profile from Integrating the Healthcare Enterprise (IHE). Hence the request for relevant attachments is a query for DocumentReference resources that conform to IHE MHD Profile on DocumentReference from a Query with Minimal Metadata.

Providing a pregenerated document to ZorgDomein

In some situations the sender of the document has generated a document already in his own information system. In these cases the body text of the generated document can be supplied to ZorgDomein. ZorgDomein will then use a simple document template that consists of only one field (to contain the document body text). It is important that the information system of the sender communicates during SSO to ZorgDomein that the user has already generated a document. This can be achieved by providing an input value in the Task resource that ZorgDomein requests during SSO:

• Task.input.type.coding.code: "message"
• Task.input.type.coding.system: "http://zorgdomein.nl/terminology/code-system/launch-input-type"
• Task.input.valueReference.reference: reference to a Communication resource that contains the body text of the document in Communication.payload.contentString.

Once ZorgDomein receives this Task.input it will query the Communication resource and use the value of Communication.payload.contentString to prepopulate the corresponding field in the document template. See the ZD Communication profile for details about the use of this resource.

Note that the feature of providing pregenerated document text is only supported for reports (and not for referrals, requests for healthcare services or products, or dossier transfers).

Sending a copy document back to sender

After the document has been composed it is sent by ZorgDomein to the recipient. After submission, a copy of the document is sent back to the sender of the document for archiving purposes. This applies to all document types. The only exception is that attachments are never sent back to the sender.

The mechanism for sending a copy of a document back to the sender is similar to the mechanism of receiving documents as described in the Receive documents component. Note that the “Receive documents” component supports HL7v2 messages for some document types, while the “Send documents” component only supports HL7 FHIR Documents.

Validation criteria

Before a connector with ZorgDomein can be released, ZorgDomein will validate the connector against a set of validation criteria. These validation criteria consist of functional and technical validation criteria. The functional criteria for this component are listed below.

The application must support:

1. the SSO to ZorgDomein component.
2. answering all FHIR queries to prepopulate documents in ZorgDomein for all data that is managed within the information system, including FHIR queries to request binary attachments.
3. receiving and processing copies of documents that are sent back to the sender; these documents must be archived in the corresponding patient health record.
4. auto-activation (required if the connector is expected to be implemented at more than 10 customers).