MedMij information standards
Version 1.0, December 2016
Introduction
Purpose
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.
Personal health records give patients access to their personal health data. Personal health data may:
- Be related to professional caregivers, for example information being exchanged between patients and caregivers.
- Be related to personal health, without an active healthcare demand.
When exchanging information, it needs to be interpreted the same on both sides: this is known as interoperability. For true interoperability there should be agreement on different governance levels as shown in the figure below.
Health information interoperability is one of the aspects within the total MedMij agreements scheme.
This document focuses on health information interoperability and the resulting necessary agreements on information standards.
Audience
The target audience consists of:
- Software vendors (for both patient and caregivers oriented software).
- Information analysts and -architects.
- People who are interested in:
- using personal health records and
- standardization of health information.
- Caregivers and healthcare institutions.
Language
This document 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 below.
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.
Scope and vision
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 other domains later. The architectural decisions need to take the ultimate goal into account. However, MedMij does not do everything at once (“think big, act small”). The subdomains in scope for the current phase in MedMij are:
- Medication.
- Allergy / intolerance.
- Lab results.
- Self-measurements:
- Blood pressure.
- Blood glucose.
- Weight.
- Length.
This document is part of the 2016 deliverable of MedMij. This means that the scoping described here is applicable to the program in 2016. Scoping may be elaborated later.
Method
In 2016, MedMij does not intend to make new information standards but reuses already published and implemented information standards as much as possible.
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. In 2016, 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.
A lot of information standards are in use in day-to-day practice. In 2016, MedMij aims to make use of existing, already implemented, standards where appropriate, desirable and possible. This imposes a challenge for information interoperability, because it is not always clear how to interpret the meaning of the contents of each standard. The method to which MedMij approaches this challenge is explained in the sections below.
Functional
A different program, named ‘Registratie aan de bron’ (Data capture at the point of Care), has defined clinical building blocks (‘zorginformatiebouwstenen’) for The Netherlands. Clinical building blocks contain definitions of healthcare concepts. Next to these clinical building blocks, the program ‘Registratie aan de bron’ also made a selection of these clinical building blocks 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.
People are entitled to have access to any registered information about them. In 2016, however, MedMij has focus on information that is being exchanged between caregivers. MedMij assumes this information is also of interest to the patient. That assumption may not always be valid, but is considered a good starting point. It enables moving fast, since it is a small step to make information, which is already (defined to be) flowing between caregivers, also available to patients.
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 clinical building blocks, which are also in scope of BGZ. Sometimes the BGZ does not use a full clinical building block. MedMij information standards will use the full clinical building block, so as to enable context-free implementation. This enables interoperability for health information.
An exception is made for the medication domain. A parallel program ‘Medicatieproces’ has defined new clinical building blocks and published their draft information standard in July 2016 (‘Medicatieproces 9.0’). These new clinical building blocks are not yet part of the BGZ, but they are the starting point for the functional part of the subdomain Medication in MedMij. This means that every MedMij medication information standard is mapped to the Medicatieproces 9.0 clinical building blocks.
Technical
Patients typically (want to be able to) access information anytime, anywhere using the device / application of their choice. This means the exchange mechanism of the information standard needs to also be suitable for mobile communication. The already implemented standards in the healthcare provider domain are less to not suitable for mobile communication, which is one of the reasons the new standard FHIR has been introduced within HL7.
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 (see section Scope and vision). 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 BGZ / Medicatieproces 9.0 building blocks as described in the previous section. Again, this enables health information interoperability.
Structure
The next section contains a description of the terms and abbreviations used in this document.
The chapter MedMij Patient Journey describes a patient journey for a patient called ‘Roos’. Roos helps to clarify the purpose and scope by means of a very practical description of a (fictional) real life situation.
The chapter Overview introduces architectural roles for information standards.
The subsequent chapters further detail these roles for each medical domain in scope (see section Scope and vision).
Terms and abbreviations
| Term | Description |
|---|---|
| BGZ | ‘Basisgegevensset Zorg’ [Common Clinical Dataset] |
| FHIR | Fast Healthcare Interoperability Resources |
| LSP | Landelijk Schakelpunt |
| HL7 | Health Level 7 |
MedMij Patient journey
A patient journey tells a story of a fictitious patient and illustrates experiences in a given health context. This includes interactions with health care providers and health record software systems, such as the personal health record. Interactions with software systems can be analysed into so called ‘Use cases’. This chapter aims to do so for a patient using a personal health record. The use cases which are deducted from the patient journey focus on information standards.
The patient journey of a woman called ‘Roos Dalstra’ serves as a basis for analysing the requirements of information standards. By describing her interactions with her personal health record, the context and requirements of information standards for the personal health record are clarified.
This chapter proceeds with a description of the patient journey in section Roos Dalstra, followed by an analysis of use cases that are in scope for MedMij.
Roos Dalstra
A separate document describes the patient journey of Roos Dalstra: see [PJ Roos].
Roos’ use cases
Medication overview in the personal health record
Roos has access to an up-to-date medication overview using her personal health record. Up-to-date means that after she or a caregiver makes changes to her medication, she can view this in her personal health record.
Register actual drug use
Roos is able to update and amend her medication overview by registering her actual drug use (this is also known as ‘medication statement’). She may, for example, take less or more then was prescribed, or temporarily stop using a specific drug due to adverse effects.
Allergy / intolerance overview
Roos has access to her allergies and/or intolerances as those are registered with her caregivers.
Register allergy in personal health record
Roos may register any allergy or intolerance known to her in her personal health record. Or she may deny having an allergy that was registered by a caregiver.
Access to laboratory results
When Roos is in the hospital, her blood glucose levels are measured regularly in the hospital because of her diabetes condition. She can access these laboratory results using her personal health record.
Registering self-measurements
Roos measures her blood glucose levels using a measurement device. She registers her blood glucose measurements in her personal health record. Roos weighs daily and registers the weight data in her personal health record.
Roos can enter these self-measurements in her personal health record by typing manually or by an automatic interface using the device. How (automatic or manual) this is done is out of scope for the information standards, but what is registered, is in scope.
MedMij Architectural roles
This chapter explains possible architectural solutions in order to provide support for the required use cases. These solutions are limited in scope to information standards. This means there is no description of security, infrastructure and so forth, which can be found in [BR]. This chapter aims to clarify how the complex real life situation, with multiple information standards, may be handled. Subsequent chapters further detail this for each medical domain in scope.
Overview
This figure contains a graphical overview of the relevant roles when looking at information standards for personal health.
The left side represents the personal health domain. The personal health network is in the middle and transports information between the two domains. The personal health network is described in [BR] and not further explained here. The right side of the figure represents the healthcare provider domain. The circles and rectangles represent different roles and are further explained in the sections below.
Please note that the figure does not aim to have a complete overview of all possible roles. For example: healthcare providers do have applications that operate on professional health data, just like the patient has. However, the healthcare provider applications themselves are not addressed by MedMij, which is why those are not depicted in the figure.
This chapter describes roles and not organizational entities. This means an organizational entity can fulfill more than one role. For example:
- A provider of a personal health record may choose to offer an application, the personal health data, a health information transformer and possibly even a personal health infrastructure.
- A vendor may also choose to just offer an app for mobile phones (and integrate with personal health data offered by a different vendor).
- An organization may offer both a health network and a health information transformer.
- An organization chooses to offer both a health network and a personal health network.
- Etcetera.
Certification of the correct implementation of the MedMij information standards is done on the Health Information Transformer (HIT) role. For further information see section Certification.
Patient
Application
Personal health data
Health information transformer (HIT)
Certification
Certification of the correct implementation of the MedMij information standards is done on the HIT. However, the HIT may need other roles in order to successfully qualify. This is further explained below based on three scenarios:
- Transformation from a MedMij standard to another MedMij standard.
- Transformation from a non-MedMij format to a MedMij standard.
- Transformation from a MedMij standard to a non-MedMij format.
Ad a) from a MedMij standard to another MedMij standard When the HIT transforms from one MedMij standard to another MedMij standard the output is checked against expected results based on the provided input. Ad b) from a MedMij standard to a non-MedMij format When transforming from a MedMij standard to a non-MedMij format, certification of this transformation will be done with the representation on a user interface (for example using screen captures of an application operating on the transformed data). This is similar to the way Nictiz currently does certifications for parties receiving information in any Nictiz information standard. Ad c) from a non-MedMij format to a MedMij standard When transforming from a non-MedMij format to a MedMij standard, again the output is checked against expected results based on defined input. Proof of correct data entry of the input may be asked for during the certification process. Again this may be provided by supplying screen captures of an application. This is similar to the way Nictiz currently does certifications for parties sending information in any Nictiz information standard.
Health network
Healthcare provider
MedMij Medication
This chapter describes requirements on information standards in the medication domain.
Roos’ use cases
The use cases applicable to the medication domain are described in sections:
Architectural overview
The following medication standards are in scope for MedMij:
- Medicatieproces 6.12 – dispense query/response (LSP)
- Medicatieproces 9.0
- FHIR profiles for medication
Contrary to other domains the BGZ is not the base for information interoperability in the medication domain. Instead the information standards are mapped to the clinical building blocks as published by Medicatieproces 9.0, see [MP 9.0].
The following figure contains an overview of the relevant information standards for medication in relation to the roles that were introduced in the previous chapter. The lines have been annotated with possible use of (non‑)MedMij formats. The figure is not claiming to be complete, but it does give an idea of the possible information flows.
At the time of writing this document, healthcare providers (prescribers, pharmacists) typically make use of Medicatieproces 6.12 using the Landelijk Schakelpunt (LSP) as health network. Medicatieproces 6.12 is further described section Medicatieproces 6.12. The program “Medicatieproces” has recently published a new draft standard, version 9.0. This standard will be tested in Pilot environments in the same timespan as MedMij kick-start environments. It is foreseen that MedMij kick-start environments sometimes take place in Medicatieproces 9.0 pilots: there will be a joint environment for both MedMij and Medicatieproces 9.0. This means that healthcare providers may also make use of the 9.0 standard, which is further detailed in section Medicatieproces 9.0. In the future healthcare providers may choose to make use of the new FHIR standard for exchanging medication information, however, this is not foreseen within the timescales of MedMij. FHIR is more likely to be used in the personal health domain. More information on FHIR Medication is in section FHIR Medication.
Health information transformer (HIT)
The Health information transformer may choose to transform between the following formats in the Medication domain:
- Medicatieproces 6.12 to FHIR or vice versa.
- Medicatieproces 9.0 to FHIR or vice versa.
- Medicatieproces 6.12 to 9.0 or vice versa.
- Any of the fore mentioned standards to a non-MedMij format (such as a proprietary format).
The services a particular HIT needs or wants to offer, will depend on the requirements of the particular market situation the HIT operates in.
Medicatieproces 6.12
The exchange format of Medicatieproces 6.12 is based on HL7v3 messaging.
Out of the different transactions that are part of the standard, the following have been implemented:
- Verstrekkingenlijst query/response (dispense query/response) - almost all dispenses in the Netherlands can be queried using the LSP.
- Voorschrift sturen/ontvangen (prescription send/receive) – some vendors have been certified, it mainly concerns prescriptions from 2nd echelon to a community pharmacist.
The dispense query/response supplies the most complete information for creating a medication overview and has therefore been chosen as part of the MedMij agreements schema. The prescription send/receive is out of scope for now.
For further information, see [MP 6.12].
Medicatieproces 9.0
The exchange format of Medicatieproces 9.0 is based on HL7v3 CDA and communicating CDA compliant statements or CDA documents in HL7v3 messages.
For further information, see [MP 9.0].
FHIR Medication
Not surprisingly, the exchange format of FHIR medication is based on FHIR.
For further information, see [MP FHIR].
Medication mappings
Section Method explains the approach to mappings between different standards. In essence we map any standard to the Medicatieproces 9.0 clinical building blocks. The table below shows where these mappings can be found.
| Standard | Mapping |
|---|---|
| MP 6.12 dispense response | Click here for the mapping in wiki.
For working group members it is also available in xlsx on SharePoint, otherwise ask for it by email: MedMij standaarden |
| FHIR | For working group members it is available on SharePoint, otherwise ask for it by email: MedMij standaarden |
MedMij Allergy/intolerance
This chapter describes requirements on information standards in the allergy/intolerance domain.
Roos’ use cases
The use cases applicable to the allergy/intolerance domain are described in sections:
Architectural overview
The following allergy/intolerance standards are in scope for MedMij:
- Medicatieproces 6.12 – potential contra-indication query/response (LSP)
- FHIR profiles for allergy/intolerance
The BGZ is the base for information interoperability in the allergy/intolerance domain. The information standards are mapped to the clinical building blocks as published in the BGZ, see [BGZ].
At the time of writing this document, healthcare providers (prescribers, pharmacists) typically make use of Medicatieproces 6.12 using the Landelijk Schakelpunt (LSP) as health network. Allergy/intolerance is part of Medicatieproces 6.12 and is further described in section Allergy/Intolerance (part of Medicatieproces 6.12).
In the future healthcare providers may choose to make use of the new FHIR standard for exchanging allergy/intolerance information, however, this is not foreseen within the timescales of MedMij. FHIR is more likely to be used in the personal health domain. More information on FHIR Allergy/Intolerance is in section FHIR Allergy/Intolerance.
Health information transformer (HIT)
The Health information transformer may choose to transform between the following formats in the Medication domain:
- Allergy/Intolerance 6.12 to FHIR or vice versa.
- Any of the fore mentioned standards to a non-MedMij format (such as a proprietary format).
The services that a HIT needs or wants to offer, will depend on the requirements of the market situation the HIT operates in.
Allergy/Intolerance (part of Medicatieproces 6.12)
The standard for Allergy/Intolerance is part of the Medicatieproces 6.12 standard. It is based on HL7v3 messaging.
The transactions in the standard are:
- Potentiële contra-indicaties query/response (potential contra-indication query/response) – typically implemented using the LSP.
For further information, see [MP 6.12].
FHIR Allergy/Intolerance
These is a FHIR profile tailored for use based on the clinical building block AllergyIntolerance.
For further information, see [FHIR AI].
Mappings
Section Method explains the approach to mappings between different standards. Essentially we map any standard to the BGZ clinical building blocks. The table below shows where these mappings can be found.
| Standard | Mapping |
|---|---|
| MP 6.12 potential contra-indication response | For working group members it is available on SharePoint, otherwise ask for it by email: MedMij standaarden |
| FHIR | For working group members it is available on SharePoint, otherwise ask for it by email: MedMij standaarden |
MedMij Laboratory results
This chapter describes requirements on information standards in the laboratory domain.
Roos's use cases
The use cases applicable to the laboratory domain are described in sections:
Architectural overview
The following laboratory standards are in scope for MedMij:
- [MEDLAB 1.0] (Edifact)
- [HL7 V2.4 ORU^R01] Unsolicited Observation Message (login required)
- [HL7 V2.5 OUL^R22] (Lab2Lab)
- [Collab. Care Lab] (CDA)
- [FHIR Laboratory Results].
The standards above differ vastly in scope and coverage of the laboratory domain. While Edifact MEDLAB is used heavily for Lab to General Practitioner communication of clinical chemistry results there’s also IHE XD-LAB on the other end of the spectrum covering CDA based results reporting of ‘any’ kind. The “Information standards Laboratories” covers XD-LAB and adds IHE ILW capabilities and finally “Information standard Ketenzorg” seeks to be a minimalistic approach to XD-LAB.
Health information transformer (HIT)
The Health information transformer may choose to transform between the following formats in the laboratory domain:
- HL7 V2.4 ORU^R01 to / from FHIR Observation | DiagnosticReport;
- HL7 V2.5 OUL^R22 (Lab2Lab) to / from FHIR Observation | DiagnosticReport;
- HL7 V3.0 CDA Building Blocks (Ketenzorg) to / from FHIR Observation | DiagnosticReport;
- HL7 V3.0 CDA to / from FHIR Observation | DiagnosticReport.
The biggest challenges in the Lab domain however may not lie in syntactical transformation but in semantic transformation due to a myriad of terminology systems for coding tests, specimens, and results, deployed by the different laboratories, the first line of healthcare (mainly general practitioners) and the second and third lines in healthcare
The services that a HIT needs or wants to offer, will depend on the requirements of the market situation the HIT operates in.
MEDLAB 1.0
MEDLAB 1.0 is an Edifact standard and in use since 1989 by Laboratories specifically to communicate results to a general practitioner (GP) usually when he is the ordering provider (requesting party). Laboratories internally communicate using different standards and terminology, and MEDLAB is only relevant for this GP use case. The Edifact message uses free text specimen information, [NHG Tabel 45] (recommended) but at least free text and mostly free text test result
HL7 V2.4 ORU^R01 Unsolicited Observation Message
HL7 V2.4 ORU^R01 is the most widely used message type in hospitals, care settings and other second and third line healthcare settings for various goals, among which:
- Clinical chemistry;
- Microbiology (usually as free text or as RTF);
- Documents (inline or by reference).
Where terminology is applied, it could be from international terminology systems like LOINC, SNOMED CT or even HL7, but Laboratories usually also have at least terminology from their vendor complemented with their own, e.g. for newer tests. HL7 V2.4 ORU^R01 is not suited well for structured reporting of Microbiology results. This is where HL7 V2.5 OUL comes in
HL7 V2.5 OUL^R22 Unsolicited Specimen Oriented Observation Message (Lab2Lab)
HL7 V2.5 OUL^R22 is the message in use for result reporting in Inter Laboratory Workflow where labs outsource certain tests to other specialized labs. It is used for both clinical chemistry and microbiology reporting, and could potentially replace ORU^R01 (see above). While current practice with regards to terminology is the same as in ORU^R01, there is a terminology oriented project underway that covers all relevant lab terminology for ordering tests, specimens, and result reporting based on LOINC and SNOMED CT.
HL7 V3.0 CDA Building Blocks (Ketenzorg)
The Nictiz/VZVZ project Ketenzorg (Collaborative Care) has defined multiple building blocks, two of which are relevant here. The Lab observation (Dutch: Labbepaling) and the Generic observation (Dutch: Algemene bepaling). These contain a minimalistic set of data that could be viewed upon as a subset of the more complex HL7 V2.x specification, or even seen as similar to the Edifact MEDLAB 1.0 message. It’s use case is first line (GP <> Collaborative Care) and so the terminology is fully based on [NHG Tabel 45]. Some information may have originated from MEDLAB.
FHIR Laboratory Results
These are a set of FHIR profiles tailored for use based on the clinical building block LaboratoryTestResult.
For further information, see [FHIR LR].
Mappings
Section Method explains the approach to mappings between different standards. Essentially we map any standard to the BGZ clinical building blocks. The table below shows where these mappings can be found.
| Standard | Mapping |
|---|---|
| FHIR | For working group members it is available on SharePoint, otherwise ask for it by email: MedMij standaarden |
MedMij Self-measurements
This chapter describes requirements on information standards in the self-measurements domain.
Roos’ use cases
The use cases applicable to the self-measurements domain are described in sections:
Architectural overview
The following self-measurement standards are in scope for MedMij:
- Observation vital signs profiles:
- Respiratory rate
- Heart rate
- Oxygen saturation (arterial)
- Body temperature
- Body height
- Head circumference
- Body weight
- Body mass index
- Blood pressure systolic and diastolic
- Mean blood pressure
The BGZ is the base for information interoperability in the self-measurements domain. The information standards are mapped to the clinical building blocks as published in the BGZ, see [BGZ].
Healthcare providers may choose to make use of the new FHIR standard for exchanging (receiving) self-measurements information. FHIR may also be used in the personal health domain. More information on FHIR self-measurements is in section FHIR self-measurements.
Health information transformer (HIT)
The Health information transformer may choose to transform between the following formats in the self-measurements domain:
- See chapter Laboratory results for self-measurements that fit laboratory results.
The services that a particular HIT needs or wants to offer, will depend on the requirements of the particular market situation the HIT operates in.
Self-measurements
There are no dominant standards for registering self-measurements in The Netherlands. However self-measurements that fit laboratory results (such as blood glucose measurements) can be communicated using the standard described in chapter MedMij Laboratory results.
FHIR self-measurements
Not surprisingly, the exchange format of FHIR self-measurements is based on FHIR.
For further information, see [FHIR SM].
Other clinical domains
This chapter aims to be a "catch all" for standardization of things not covered elsewhere so future implementations can build upon work of their predecessors. There are always practical use cases that are not covered in general/generic information standards, but are very much worth noting for future reference. Terminology is a big part of that. For example there are thousands of devices producing results that can be represented using observations, but these results would not be comparable unless they use the same or comparable terminology. We foresee that better places will be found in future versions of the MedMij materials. Terminology for example could have a place in terminology server.
Most contents in this chapter have been identified in the MedMij kick-start environments. For example: a measurement result for a specific lung function is exchanged between specialists and patients. Even though this can be done using a generic vital signs resource, agreements are still made on the specific terminology choices
Respiratory system
Spirometer panel
The leading spirometer devices produce PDF without direct access to the underlying, structured data. In communicating structured Spirometer panel results:
- Use LOINC as leading terminology for the panel and constituents
- Each panel observation SHOULD be an independent observation.
- FHIR: Panel is an Observation where the PDF is Observation.valueAttachment (application/pdf) and each constituent spawns from there as Observation.related
- Implementation in other standards, V3 / V2 / Edifact not discussed
| Short | LOINC | Description |
|---|---|---|
| Panel | 81459-0 | Spirometer panel |
| VC IN (L) | 19866-3 | Vital capacity [Volume] Respiratory system by Spirometry |
| FVC (L) | 19868-9 | Forced vital capacity [Volume] Respiratory system by Spirometry |
| FEV 1 (L) | 20150-9 | FEV1 (forced expiratory volume in 1 second) |
| FEV1%l (%) | This is FEV1/VC: a deprecated ratio that has been replaced by FEV1/FVC. There's no LOINC for the deprecated result. | |
| FEV1%M (%) | 19926-5 | Volume expired during 1.0 s of forced expiration/Forced vital capacity |
| PEF (L/s) | 33452-4 | Maximum expiratory gas flow Respiratory system airway [alternative is 19935-6 Maximum expiratory gas flow Respiratory system by Peak flow meter, because it literally mentions ‘peak flow’. But a peak flow meter is a small device of a few Euros that a patient can use for self-measurement; and we are dealing with a spirometry test. Hence the choice for 33452-4 |
| FEF25 (L/s) | 65821-1 | Gas flow FEV 25% |
| FEF50 (L/s) | 65822-9 | Gas flow FEV 50% |
| FEF75 (L/s) | 65823-7 | Gas flow FEV 75% |