|
|
| (9 tussenliggende versies door 2 gebruikers niet weergegeven) |
| Regel 1: |
Regel 1: |
| − | {{#customtitle:MedMij information standards|MedMij information standards}}
| + | #REDIRECT [[MedMij:V1.0_Standards]] |
| − | | |
| − | Program “Meer regie over gezondheid” (Patient empowerment)
| |
| − | | |
| − | Version 0.3 October 2016 (draft)
| |
| − | | |
| − | =Introduction=
| |
| − | ==Purpose and audience==
| |
| − | The program ‘Patient empowerment’ -further referred to as “the program”- 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. The program delivers an agreements scheme named ‘MedMij’, in order to enable patients to become that true partner.
| |
| − | | |
| − | Patient applications give patient 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.
| |
| − | | |
| − | <div style="overflow: hidden">[[Image:levels_of_interoperability.png|thumb|700px|left|Levels of interoperability]]</div>
| |
| − | | |
| − | 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.
| |
| − | | |
| − | The target audience consists of:
| |
| − | *Software vendors (for both patient and caregivers oriented software).
| |
| − | *Information analysts and -architects.
| |
| − | *Patients who are interested in standardization of health information.
| |
| − | *Caregivers and healthcare institutions.
| |
| − | | |
| − | ==Scope and vision==
| |
| − | Health is a very broad domain. Therefore, the program has made scoping choices for its roadmap. The program 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, the program does not do everything at once (“think big, act small”). The subdomains in scope for the current phase in the program are:
| |
| − | *Medication.
| |
| − | *Allergy / intolerance.
| |
| − | *Lab results.
| |
| − | *Self-measurements:
| |
| − | **Blood pressure.
| |
| − | **Blood glucose.
| |
| − | **Weight.
| |
| − | **Length.
| |
| − | | |
| − | ==Method==
| |
| − | The program 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. The program 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). The program does make it possible to use a new exchange format: FHIR.
| |
| − | | |
| − | A lot of information standards are in use in day-to-day practice. The program 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 the program 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.
| |
| − | | |
| − | The current assumption is that information exchanged between caregivers is also of interest to the patient. This 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.
| |
| − | | |
| − | The program ‘Meer regie over gezondheid’ (Patient empowerment) 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 the BGZ. 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 the program have chosen to introduce FHIR as a modern standard to exchange information in MedMij. The program delivers a FHIR representation for each domain in scope (see section [[#Scope and vision|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.
| |
| − | | |
| − | Chapter 2 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.
| |
| − | | |
| − | Chapter 3 introduces architectural roles for information standards.
| |
| − | | |
| − | The subsequent chapters further detail these roles for each medical domain in scope (see section [[#Scope and vision|Scope and vision]]).
| |
| − | | |
| − | ==Terms and abbreviations==
| |
| − | | |
| − | {| class="prettytable" width="100%"
| |
| − | |- style="background-color:#4f81bd; font-weight: bold; color: white; text-align:left;"
| |
| − | ! Term
| |
| − | ! Description
| |
| − | |- style="background-color:#b8cce4;"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | BGZ
| |
| − | | ‘Basisgegevensset Zorg’ <nowiki>[</nowiki>[[#ref_BGZ|Common Clinical Dataset]]<nowiki>]</nowiki>
| |
| − | |-
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | FHIR
| |
| − | | Fast Healthcare Interoperability Resources
| |
| − | |- style="background-color:#b8cce4;"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | LSP
| |
| − | | Landelijk Schakelpunt
| |
| − | |-
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | MedMij
| |
| − | | Agreements scheme delivered by program ‘Meer regie over gezondheid’ (Patient empowerment)
| |
| − | |- style="background-color:#b8cce4;"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | HL7
| |
| − | | Health Level 7
| |
| − | |}
| |
| − | | |
| − | =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|Roos Dalstra]], followed by an analysis of use cases that are in scope for the program.
| |
| − | | |
| − | ==Roos Dalstra==
| |
| − | A separate document describes the patient journey of Roos Dalstra: see <nowiki>[</nowiki>[[#ref_PJ_Roos|PJ Roos]]<nowiki>]</nowiki>.
| |
| − | | |
| − | ==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 physician 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.
| |
| − | | |
| − | =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 <nowiki>[</nowiki>[[#ref_BR|BR]]<nowiki>]</nowiki>.
| |
| − | 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.
| |
| − | | |
| − | <div style="overflow: hidden">[[Image:medmij_architectural_overview.png|thumb|700px|left|Architectural Roles]]</div>
| |
| − | | |
| − | 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 <nowiki>[</nowiki>[[#ref_BR|BR]]<nowiki>]</nowiki> 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 the program, 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|Certification]].
| |
| − | | |
| − | ==Patient==
| |
| − | <div style="overflow: hidden">
| |
| − | [[Image:medmij_patient_role.png|thumb|75px|left|Patient]]
| |
| − | | |
| − | The patient is represented by the circle all the way on the left in the architectural figure under [[#Overview|Overview]] and uses her personal health record via an application. The patient chooses the device and application to access personal health data. The patient also chooses the vendor of her personal health data based on competitive offerings.
| |
| − | </div>
| |
| − | ==Application==
| |
| − | <div style="overflow: hidden">
| |
| − | [[Image:medmij_application_role.png|thumb|75px|left|Application]]
| |
| − | | |
| − | The application is typically a mobile app (for example for iOS, Android, et cetera) or a desktop application. An application may run on a smartphone, a tablet, a personal computer, et cetera. It is a piece of software that:
| |
| − | *Provides a user interface to the patient.
| |
| − | *May contain modules with business logic.
| |
| − | *Provides an interface to personal health data. This can either be based on a MedMij standard or be proprietary.
| |
| − | </div>
| |
| − | ==Personal health data==
| |
| − | <div style="overflow: hidden">
| |
| − | [[Image:medmij_personal_health_data.png|thumb|75px|left|Personal health data]]
| |
| − | | |
| − | The role of ‘Personal health data’ offers services to access personal health data. These services may be used by:
| |
| − | *An application to give a patient access to her data.
| |
| − | *Another software vendor for ‘Personal health data’ in order to transfer health data. For example, when a patient chooses to change between vendors for her personal health record. This functionality is mandatory for a personal health domain, but may also be offered by a health information transformer.
| |
| − | *A health information transformer in order to transform data from one format to another to enable meaningful information exchange.
| |
| − | *A health network in order to exchange information between patients and healthcare providers.
| |
| − | *Directly by a healthcare provider, when there is no need or desire for transformation nor for a health network.
| |
| − | | |
| − | Please note that personal health data may be stored persistently but may also be acquired ‘on-the-fly’ (virtual data store) or may be characterized as a hybrid situation, which combines the two options. The choice is up to the vendor and does not have effect on the requirements on information standards. However, it may have effect on other requirements, such as security and/or privacy, if so, then it is described in <nowiki>[</nowiki>[[#ref_BR|BR]]<nowiki>]</nowiki>.
| |
| − | </div>
| |
| − | ==Health information transformer (HIT)==
| |
| − | <div style="overflow: hidden">
| |
| − | [[Image:medmij_health_information_transformer.png|thumb|150px|left|Health information transformer]]
| |
| − | | |
| − | The role of ‘Health information transformer’ (HIT) can be applicable in both the personal health domain and the healthcare provider domain. The HIT transforms the format of data, but does not change or add any data. Examples of transformation are:
| |
| − | *From a proprietary interface of personal health data to an open MedMij standard and vice versa. A proprietary interface of personal health data may, for example, be Apple Health kit or Microsoft HealthVault.
| |
| − | *From an open MedMij standard to another open, already implemented, standard and vice versa. An example of such an already implemented standard is medication 6.12 as used on the Landelijk Schakelpunt (LSP) in The Netherlands.
| |
| − | *Another combination of transformation between proprietary, MedMij and legacy standards.
| |
| − | </div>
| |
| − | ===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:
| |
| − | <ol style="list-style-type:lower-alpha">
| |
| − | <li>Transformation from a MedMij standard to another MedMij standard.</li>
| |
| − | <li>Transformation from a non-MedMij format to a MedMij standard.</li>
| |
| − | <li>Transformation from a MedMij standard to a non-MedMij format.</li>
| |
| − | </ol>
| |
| − | 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==
| |
| − | <div style="overflow: hidden">
| |
| − | [[Image:medmij_health_network.png|thumb|75px|left|Health network]]
| |
| − | | |
| − | The Health network operates in the healthcare provider domain. Since there are many healthcare providers, the health network resolves the problem of many-to-many connections in this domain. A health network is responsible for transporting data amongst healthcare providers and/or between healthcare providers and patients.
| |
| − | The transport to and/or from patients should be done through the personal health network as is shown in the architectural figure under [[#Overview|Overview]].
| |
| − | </div>
| |
| − | ==Healthcare provider==
| |
| − | <div style="overflow: hidden">
| |
| − | [[Image:medmij_healthcare_provider.png|thumb|50px|left|Healthcare provider]]
| |
| − | | |
| − | The Healthcare provider can have an interface to a health network, a health information transformer and/or directly to a personal health network. Healthcare providers typically make use of various already implemented standards.
| |
| − | </div>
| |
| − | =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:
| |
| − | *[[#Medication overview in the personal health record|Medication overview in the personal health record]]
| |
| − | *[[#Register actual drug use|Register actual drug use]]
| |
| − | | |
| − | ==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 <nowiki>[</nowiki>[[#ref_MP9|MP 9.0]]<nowiki>]</nowiki>.
| |
| − | | |
| − | 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.
| |
| − | | |
| − | <div style="overflow: hidden">[[Image:medmij_architectural_overview_medication_example.png|thumb|700px|left|Medication and architectural roles (example)]]</div>
| |
| − | | |
| − | 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|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|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 the program. FHIR is more likely to be used in the personal health domain. More information on FHIR Medication is in section [[#FHIR Medication|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 <nowiki>[</nowiki>[[#ref_MP612|MP 6.12]]<nowiki>]</nowiki>.
| |
| − | ==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 <nowiki></nowiki>[[#ref_MP9|MP 9.0]]<nowiki>]</nowiki>.
| |
| − | ==FHIR Medication==
| |
| − | Not surprisingly, the exchange format of FHIR medication is based on FHIR.
| |
| − | | |
| − | For further information, see <nowiki>[</nowiki>[[#ref_FHIR_MP|MP FHIR]]<nowiki>]</nowiki>.
| |
| − | ==Mappings==
| |
| − | Section [[#Method|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.
| |
| − | | |
| − | {| class="prettytable" width="100%"
| |
| − | |- style="background-color:#4f81bd; font-weight: bold; color: white; text-align:left;"
| |
| − | ! Standard
| |
| − | ! Mapping
| |
| − | |- style="background-color:#b8cce4;"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | MP 6.12 dispense response
| |
| − | | https://nictiznl.sharepoint.com/sites/MedMij/werkgroepen/Gedeelde%20%20documenten/Werkgroep%20-%20standaarden/Medicatie
| |
| − | |-
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | MP 9.0
| |
| − | | N/A, is part of <nowiki></nowiki>[[#ref_MP9|MP 9.0]]<nowiki>]</nowiki>
| |
| − | |- style="background-color:#b8cce4;"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | FHIR
| |
| − | | https://nictiznl.sharepoint.com/sites/MedMij/werkgroepen/Gedeelde%20%20documenten/Werkgroep%20-%20standaarden/FHIR/Medicatie9.xlsx?web=1
| |
| − | |}
| |
| − | | |
| − | =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:
| |
| − | *[[#Allergy / intolerance overview|Allergy / intolerance overview]]
| |
| − | *[[#Register allergy in personal health record|Register allergy in personal health record]]
| |
| − | | |
| − | ==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 <nowiki>[</nowiki>[[#ref_BGZ|BGZ]]<nowiki>]</nowiki>.
| |
| − | | |
| − | 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)|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 the program. FHIR is more likely to be used in the personal health domain. More information on FHIR Allergy/Intolerance is in section [[#FHIR Allergy/Intolerance|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 <nowiki>[</nowiki>[[#ref_MP612|MP 6.12]]<nowiki>]</nowiki>.
| |
| − | | |
| − | ==FHIR Allergy/Intolerance==
| |
| − | Not surprisingly, the exchange format of FHIR allergy/intolerance is based on FHIR.
| |
| − | | |
| − | For further information, see <nowiki>[</nowiki>[[#ref_FHIR_AI|FHIR AI]]<nowiki>]</nowiki>.
| |
| − | | |
| − | ==Mappings==
| |
| − | Section [[#Method|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.
| |
| − | | |
| − | {| class="prettytable" width="100%"
| |
| − | |- style="background-color:#4f81bd; font-weight: bold; color: white; text-align:left;"
| |
| − | ! Standard
| |
| − | ! Mapping
| |
| − | |- style="background-color:#b8cce4;"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | MP 6.12 potential contra-indication response
| |
| − | | https://nictiznl.sharepoint.com/sites/MedMij/werkgroepen/Gedeelde%20%20documenten/Werkgroep%20-%20standaarden/Allergy
| |
| − | |-
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | FHIR
| |
| − | | https://nictiznl.sharepoint.com/sites/MedMij/werkgroepen/Gedeelde%20%20documenten/Werkgroep%20-%20standaarden/FHIR/AllergieIntolerantie.xlsx?web=1
| |
| − | |}
| |
| − | | |
| − | =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:
| |
| − | *[[#Access to laboratory results|Access to laboratory results]].
| |
| − | | |
| − | ==Architectural overview==
| |
| − | The following laboratory standards are in scope for MedMij:
| |
| − | | |
| − | *<nowiki>[</nowiki>[[#ref_MEDLAB_1|MEDLAB 1.0]]<nowiki>]</nowiki> (Edifact)
| |
| − | *<nowiki>[</nowiki>[[#ref_HL7v2.4_ORU_R01|HL7 V2.4 ORU^R01]]<nowiki>]</nowiki> Unsolicited Observation Message (login required)
| |
| − | *<nowiki>[</nowiki>[[#ref_HL7v2.5_OUL_R22|HL7 V2.5 OUL^R22]]<nowiki>]</nowiki> (Lab2Lab)
| |
| − | *<nowiki>[</nowiki>[[#ref_CollabCareLab|Collab. Care Lab]]<nowiki>]</nowiki> (CDA)
| |
| − | | |
| − | 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, <nowiki>[</nowiki>[[#ref_NHG_Tabel45|NHG Tabel 45]]<nowiki>]</nowiki> (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 <nowiki>[</nowiki>[[#ref_NHG_Tabel45|NHG Tabel 45]]<nowiki>]</nowiki>. Some information may have originated from MEDLAB.
| |
| − | | |
| − | ==Mappings==
| |
| − | Section [[#Method|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.
| |
| − | | |
| − | {| class="prettytable" width="100%"
| |
| − | |- style="background-color:#4f81bd; font-weight: bold; color: white; text-align:left;"
| |
| − | ! Standard
| |
| − | ! Mapping
| |
| − | |- style="background-color:#b8cce4;"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | FHIR
| |
| − | | https://nictiznl.sharepoint.com/sites/MedMij/werkgroepen/Gedeelde%20%20documenten/Werkgroep%20-%20standaarden/FHIR/LaboratoriumResultaat.xlsx?web=1
| |
| − | |-
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" |  
| |
| − | |  
| |
| − | |}
| |
| − | | |
| − | =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:
| |
| − | | |
| − | *[[#Registering self-measurements|Registering self-measurements]].
| |
| − | | |
| − | ==Architectural overview==
| |
| − | The following self-measurement standards are in scope for MedMij:
| |
| − | *<nowiki>[</nowiki>TODO<nowiki>]</nowiki>
| |
| − | *[http://hl7.org/fhir/2016May/observation-vitalsigns.html#4.31.15.1 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 <nowiki>[</nowiki>[[#ref_BGZ|BGZ]]<nowiki>]</nowiki>.
| |
| − | | |
| − | In the future healthcare providers may choose to make use of the new FHIR standard for exchanging (receiving) self-measurements information, however, this is not foreseen within the timescales of the program. FHIR is more likely to be used in the personal health domain. More information on FHIR self-measurements is in section [[#FHIR Allergy/Intolerance|FHIR Allergy/Intolerance]].
| |
| − | | |
| − | ==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|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 [[#Laboratory results|Laboratory results]].
| |
| − | | |
| − | ==FHIR self-measurements==
| |
| − | Not surprisingly, the exchange format of FHIR self-measurements is based on FHIR.
| |
| − | | |
| − | For further information, see <nowiki>[</nowiki>[[#ref_FHIR_SM|FHIR SM]]<nowiki>]</nowiki>.
| |
| − | | |
| − | ==Mappings==
| |
| − | Section [[#Method|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.
| |
| − | | |
| − | {| class="prettytable" width="100%"
| |
| − | |- style="background-color:#4f81bd; font-weight: bold; color: white; text-align:left;"
| |
| − | ! Standard
| |
| − | ! Mapping
| |
| − | |- style="background-color:#b8cce4;"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" |  
| |
| − | |  
| |
| − | |-
| |
| − | |  
| |
| − | |  
| |
| − | |}
| |
| − | | |
| − | =Other clinical domains=
| |
| − | This chapter describes agreements in information standards which cannot be captured in currently existing information standards. These agreements may have derived from some specific 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. These agreements should be adhered to in any new implementation of the same thing.
| |
| − | | |
| − | =Respiratory system=
| |
| − | | |
| − | ==FEV 1==
| |
| − | | |
| − | | |
| − | =Appendix A. References=
| |
| − | | |
| − | {| class="prettytable" width="100%"
| |
| − | |- style="background-color:#4f81bd; font-weight: bold; color: white; text-align:left;"
| |
| − | ! ID
| |
| − | ! Description
| |
| − | ! Location
| |
| − | |- style="background-color:#b8cce4;" id="ref_BGZ"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | <nowiki>[</nowiki>BGZ<nowiki>]</nowiki>
| |
| − | | Basisgegevensset Zorg
| |
| − | | https://www.registratieaandebron.nl/pdf/Basisgegevensset_Zorg_v1_0.pdf<br/>or also available in xlsx format as used for MedMij<br/>https://nictiznl.sharepoint.com/sites/MedMij/werkgroepen/Gedeelde%20%20documenten/Werkgroep%20-%20standaarden/BGZ/BGZ%20v0%201.xlsx?web=1
| |
| − | |- id="ref_BR"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | <nowiki>[</nowiki>BR<nowiki>]</nowiki>
| |
| − | | Basic Requirements
| |
| − | | https://nictiznl.sharepoint.com/sites/MedMij/werkgroepen/Gedeelde%20%20documenten/Werkgroep%20-%20BVI/Basic%20requirements%20for%20Interoperability%20v1%20Working%20Draft%208.pdf?web=1
| |
| − | |- style="background-color:#b8cce4;" id="ref_CollabCareLab"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | <nowiki>[</nowiki>Collab. Care Lab<nowiki>]</nowiki>
| |
| − | | Collaborative Care (Dutch: Ketenzorg) Lab content
| |
| − | | https://www.nictiz.nl/standaardisatie/informatiestandaarden/ketenzorg
| |
| − | |- id="ref_FHIR_AI"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | <nowiki>[</nowiki>FHIR AI<nowiki>]</nowiki>
| |
| − | | Allergy/intolerance FHIR standard
| |
| − | | http://simplifier.net/Nictiz
| |
| − | |- style="background-color:#b8cce4;" id="ref_FHIR_MP"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | <nowiki>[</nowiki>FHIR MP<nowiki>]</nowiki>
| |
| − | | Medicatieproces FHIR standard
| |
| − | | http://simplifier.net/Nictiz, resource names starting with ‘MP9’
| |
| − | |- id="ref_FHIR_SM"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | <nowiki>[</nowiki>FHIR SM<nowiki>]</nowiki>
| |
| − | | Self-measurements FHIR
| |
| − | | http://simplifier.net/Nictiz
| |
| − | |- style="background-color:#b8cce4;" id="ref_HL7v2.4_ORU_R01"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | <nowiki>[</nowiki>HL7 V2.4 ORU^R01<nowiki>]</nowiki>
| |
| − | | HL7 V2.4 ORU^R01 Unsolicited Observation Message
| |
| − | | http://www.hl7.nl/downloads/category/10-implementatiegids-hl7v24.html
| |
| − | |- id="ref_HL7v2.5OUL_R22"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | <nowiki>[</nowiki>HL7 V2.5 OUL^R22<nowiki>]</nowiki>
| |
| − | | HL7 V2.5 OUL^R22 Unsolicited Specimen Oriented Observation Message (Lab2Lab)
| |
| − | | https://www.nictiz.nl/Paginas/Informatiestandaard-laboratoria.aspx
| |
| − | |- style="background-color:#b8cce4;" id="ref_IHE_XDLAB"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | <nowiki>[</nowiki>IHE XD-LAB<nowiki>]</nowiki>
| |
| − | | IHE XD-LAB
| |
| − | | http://www.ihe.net/Technical_Frameworks/#laboratory
| |
| − | |- id="ref_MEDLAB_1"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | <nowiki>[</nowiki>MEDLAB 1.0<nowiki>]</nowiki>
| |
| − | | Medisch Laboratoriumbericht versie 1.0
| |
| − | | https://www.nictiz.nl/publicaties/overige-publicaties/edifact-implementatiehandleiding-diverse-berichten
| |
| − | |- style="background-color:#b8cce4;" id="ref_MP612"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | <nowiki>[</nowiki>MP 6.12<nowiki>]</nowiki>
| |
| − | | Medicatieproces 6.12 standard
| |
| − | | https://www.nictiz.nl/Paginas/Informatiestandaard-medicatieveiligheid.aspx
| |
| − | |- id="ref_MP9"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | <nowiki>[</nowiki>MP 9.0<nowiki>]</nowiki>
| |
| − | | Medicatieproces 9.0 standard
| |
| − | | https://www.nictiz.nl/Paginas/Medicatieproces.aspx
| |
| − | |- style="background-color:#b8cce4;" id="ref_NHG_Tabel45"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | <nowiki>[</nowiki>NHG Tabel 45<nowiki>]</nowiki>
| |
| − | | NHG Labcodetabel 45
| |
| − | | http://aut.nhg.org/labcodeviewer/
| |
| − | |- id="ref_PJ_Roos"
| |
| − | | style="background-color:#4f81bd; font-weight: bold; color: white;" | <nowiki>[</nowiki>PJ Roos<nowiki>]</nowiki>
| |
| − | | Patient Journey van Roos Dalstra
| |
| − | | https://nictiznl.sharepoint.com/sites/MedMij/werkgroepen/Gedeelde%20%20documenten/Algemene%20documenten/PatientJourney
| |
| − | |}
| |
