MedMij FHIR Implementation Guide (publication 2017.03)

Inhoud

About the IG

This is the technical MedMij FHIR implementation guide based on HL7® FHIR® version STU3.

Purpose

An implementation guide for making use of FHIR in the Dutch context. This guide is developed specifically for use of FHIR in personal health environments. Vendors of personal health environments that participate in MedMij conform to a framework of agreements. FHIR plays an important role among those agreements and is used as a standard to exchange health information between the involved parties. The purpose of this guide is to describe use cases and provide technical guidance on how FHIR should be implemented in these situations. The FHIR building blocks, or profiles, involved in these use cases are outlined in this guide. Moreover, this guides provides more textual explanation of these building blocks and describes their relationship and boundaries.

Scope

The scope of this guide includes requirements to enable a particular implementation of Electronic Health Record Systems and Personal Health Environments in the Dutch realm to use standardized structured data in a defined inter-organizational transaction. Health is a very broad domain. Therefore, MedMij has made scoping choices for its roadmap. MedMij starts with a limited number of medical subdomains, but has the vision to elaborate into more domains later. However, MedMij does not do everything at once (“think big, act small”). The subdomains in scope for the current implementation guide of MedMij are:

Patient Administration Resources

Patient Summary (BgZ)

Medication

Laboratory results

Self-measurements

The FHIR profiles created based on the Dutch Patient Summary, or BgZ ( see background for more information), can be used more broadly than only exchanging a patient's summary.

Background

MedMij aims to stimulate electronic information exchange between patients and caregivers.
Caregivers generally have access to software applications to help them support their work in treating patients. Software applications for patients are evolving as we speak, but patients typically are not yet enabled to be regarded as a true partner in the care process. MedMij delivers an agreements scheme, in order to enable patients to become that true partner.

Information standards have a functional and technical component. The functional part contains definitions of appropriate concepts (dataset) and scenario’s that define when to exchange which of those concepts. MedMij will not create new functional components of information standards. The technical part translates the functional scenario’s in an exchange format (such as HL7v3 or FHIR). MedMij does make it possible to use a new exchange format: FHIR.

The program ‘Registratie aan de bron’ (Data capture at the point of Care) has defined Health and Care Information models (zorginformatiebouwstenen or ZIB's) for The Netherlands. ZIB's contain definitions of healthcare concepts. Next to these ZIB's, the program ‘Registratie aan de bron’ also made a selection of these ZIB's into the so called ‘Basisgegevensset Zorg’ (Common Clinical Dataset, a Dutch version of a ‘patient summary’, further referred to as ‘BgZ’). The BgZ serves as a minimal healthcare dataset that is always appropriate for caregivers in order to provide continuity of care for a patient.

MedMij uses the BgZ as the starting point for the functional part of the information standards that are part of MedMij. This means that every MedMij information standard is mapped to ZIB's, which are also in scope of BgZ. The BgZ does not always use the complete ZIB. MedMij information standards, however, will use the full ZIB, so as to enable context-free implementation. This enables interoperability for health information.

The stakeholders in MedMij have chosen to introduce FHIR as a modern standard to exchange information in MedMij. MedMij delivers a FHIR representation for each domain in #Scope. However, as noted before, already implemented standards may be part of MedMij as well. Just like the already implemented standards, FHIR is mapped to the ZIB's.

Audience

The target audience of this implementation guide are software vendors and developers that will implement FHIR as part of electronic information exchange under MedMij.
Users of this guide are expected to be familiar with the FHIR specification and resource processing. This implementation guide is not intended to be a tutorial on that subject.

Language

This implementation guide is written in English, even though the majority of the documentation in MedMij is in Dutch. A Dutch translation of this document may become available, however, the English version is and remains leading. The rationale for choosing English is described in this section.

Implementers in healthcare are in many cases foreign, e.g. through outsourcing or because the company is a multinational. But even if they are Dutch native speakers, the educational tracks, their programming language of choice, and the implementer communities they are part of will largely be based on the English language. In creating the documentation for this target audience we have received overwhelming preference from the MedMij implementer community for English. This saves them investments and risks in getting a translation agency on a per vendor basis for each version of the documentation, while at same time not alienating the native Dutch speaking audience. As a side effect it also helps Nictiz in the international realm in discussions with relevant initiatives such as Argonaut (US), Patients Know Best (UK), the Finnish PHR, and the HL7/FHIR community at large.

Use Cases

Functional explanation of MedMij use cases are described in more detail here (Dutch). This IG will narrow down to the technical FHIR implementation guidance of these use cases. From here you can link to a specific use case.

All use cases are performed in the context of a specific authenticated patient, for which an OAuth2 token has been retrieved using the Authentication mechanisms described in the 'Afsprakenstelsel'. This token must be passed in each call in the HTTP header named “Authorization”. Each XIS Gateway is required to perform filtering based on the patient associated with the OAuth2 token received for the request, so that only the records associated with the authenticated patient are returned.