General specifications FHIR Edition V2

NB: This is a draft specification!

Introduction

Since the introduction of the FHIR edition of ZorgDomein Integrator, this interface has focused on two different use cases:

• Starting a transaction in ZorgDomein to compose and send documents using data from the source XIS.
• Receiving documents that have been composed in ZorgDomein. With the development of ZorgDomein as a platform to facilitate the choice for the best healthcare, there is an emerging range of new use cases that should be supported by ZorgDomein Integrator. Some examples are interfaces used for the exchange of appointment details, digital patient intakes and patient consent records. Other uses cases are to be expected in the future. This development asks for an evaluation of the basic architecture of ZorgDomein Integrator.

Transactions

As mentioned above, the current FHIR interface focusses on composing, sending and receiving documents. However, documents are not the core element of the ZorgDomein application. Everything that happens within ZorgDomein is centered around transactions. From a technical perspective, a transaction is the digital exchange of a patient specific service request or report that is initiated by a single practitioner and is aimed at a specific organizational unit or practitioner. There are multiple actors that are involved in this transaction:

1. The patient being the subject of the transaction.
2. The initiator of the transaction: the initiator starts the transaction and is the first source of data input for the transaction.
3. The recipient of the transaction: the recipient of the transaction is responsible for following up on the transaction and delivering output if needed.
4. Other actors providing input for the transaction. Some examples:
   • A colleague of the initiator who provides additional data that is relevant for other actors in the transaction.
   • An external practitioner (other than the recipient of the transaction) who provides a patient examination that is relevant for other actors in the transaction.
   • A collector who collects a specimen in response to a lab order. All actors that are acting on this transaction (e.g., a referring GP, a specialist in a hospital and the patient), can enrich this transaction with new data. That data could or should then be consumed by the other actors of the transaction to act upon it. This way, a transaction in ZorgDomein enables all participants to collaborate and communicate fluently in a transmural workflow.

With this conceptual idea in mind, a transaction should be the center piece of ZorgDomein Integrator, with different actors hooking into it, providing input and generating output or status changes.

Transactions in FHIR

When mapping this model to the HL7 FHIR standard, a transaction can be represented by a Task resource, the different actors can be mapped to Practitioner, Organization and Patient resources that are referenced by the Task resource. The input, output and status changes that the actors provide on the transaction can be set on the Task resource and may reference additional FHIR resources that represent the input, output or status change. This way the Task resource serves as the main hub that connects several other related FHIR resources.

Read more

Read more about ZorgDomein Integrator FHIR Edition V2 in the pages listed below.