MedMij:V2018.06 FHIR IG: verschil tussen versies
| Regel 1: | Regel 1: | ||
{{#customtitle:MedMij FHIR Implementation Guide}} | {{#customtitle:MedMij FHIR Implementation Guide}} | ||
| + | {{MedMij:V2018.06_Issuebox_FHIR_IG}} | ||
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]] | [[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]] | ||
Versie van 25 jul 2019 08:58
{{#customtitle:MedMij FHIR Implementation Guide}}
|
|
This version is obsolete - See current publication here. |
Quick links
|
|
|
|
|
|
|
|
|
|
|---|
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 the use of HL7® FHIR® between personal health records(PHR) and healthcare provider systems (XIS). PHR and XIS vendors that participate in MedMij conform to a framework of agreements, in Dutch this is called the 'afsprakenstelsel.' HL7 FHIR, or just '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 to implement FHIR in these situations. This guide outlines the FHIR building blocks, or profiles, involved in these use cases. Moreover, this guide provides a textual explanation of these building blocks and describes their relationship and boundaries.
Scope
The scope of this guide includes requirements to enable PHR and XIS in the Dutch realm to use standardized structured data in a defined inter-organizational transaction. Health is a vast 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 on more domains later. In scope domains are first described in the functional design that underlies this technical design.
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 to enable patients to become that true partner. The section #Afsprakenstelsel describes the relation to this implementation guide.
Information standards have a functional and technical component. The functional part contains definitions of relevant concepts (dataset) and scenario’s that define when to exchange which of those concepts. The technical part translates the functional scenario’s in an exchange format (such as HL7v3 or FHIR). The stakeholders in MedMij have chosen to introduce FHIR as a modern standard to exchange information in MedMij. A dutch factsheet that explains why FHIR is chosen is available on the MedMij website. MedMij delivers a FHIR representation (profiles) for each domain in scope.
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. MedMij information standards contain mappings to these ZIB's. MedMij creates FHIR profiles based on ZIB's which include mappings to the relevant ZIB concepts. As a result, the created profiles enable context-free implementation. Therefore, these profiles are applicable in a broader context than the described use cases or the MedMij context. Reuse of these profiles enables interoperability for health information.
Audience
The main target audience of this implementation guide is software vendors and developers that will implement FHIR as part of electronic information exchange under MedMij. This IG is intended for developers of PHR as well as XIS vendors. Users of this guide are expected to be familiar with the FHIR specification and resource processing. This guide provides links to relevant sections of the FHIR specification. 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 as follows. 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 the target audience, we have received overwhelming preference from the MedMij implementer community for English. English documentation saves them investments and risks in getting a translation agency on a per vendor basis for each version of the documentation, while at the 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.
Afsprakenstelsel
The 'afsprakenstelsel' references the MedMij information standards. In addition, the MedMij information standards are specified in the context of the 'afsprakenstelsel.' This applies to the implementation guidance of the use cases described in this implementation guide.
For example, all use cases 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.
Functional design
All use cases described in this implementation guide have a functional counterpart. The functional design pages are written in Dutch. The main overarching wiki page of the functional designs can be found at here. From this page, you can link to the specific use case through the patient journey image or the table index. It is possible to link to the specific functional design page from the technical use case pages in this wiki by clicking on the functional circle in the top image.
Use cases
Implementation guidance is provided per use case on separate wiki pages. The next section provides implemenation guidance that apply for all use cases. The green circles represent the available use cases. Click on the circle to go to the use case page.
|
|
|
|
|
|
|
|
|
|
|
|---|
Use case overarching principles
Content Types and encodings
MedMij uses the FHIR RESTful framework. This framework defines at least three content-types to send/retrieve information. Clients may ask servers specifically for information in a given content-type. Servers SHALL support server-driven content negotiation as described in section 12 of the HTTP specification.
- XML: application/fhir+xml
- JSON: application/fhir+json
- RDF: text/turtle - Not supported in MedMij
Servers in MedMij SHALL support both XML and JSON. Clients MAY negotiate using the HTTP standard which they prefer. If a client does not request a specific content-type, then it is server discretion if they respond using XML or JSON content-type.
FHIR uses UTF-8 for all request and response bodies. Since the HTTP specification (section 3.7.1) defines a default character encoding of ISO-8859-1, requests and responses SHALL explicitly set the character encoding to UTF-8 using the charset parameter of the MIME-type in the Content-Type header. Requests MAY also specify this charset parameter in the Accept header and/or use the Accept-Charset header.
Retrieve information: what's new
Retrieving information that was added, changed, deleted relative to a date may be done using the search parameter _lastUpdated available for any resource. Using the parameter _lastUpdated a system may query for data that is new since the previous query. Any FHIR server is expected to support this parameter _lastUpdated.
The search parameter _lastUpdated can be used to select resources based on the last time they were changed:
GET [base]/Observation?_lastUpdated=gt2018-10-01
This search finds any observations changed since Oct 1, 2018. More information may be found in the section _lastUpdated in the FHIR specification: http://hl7.org/fhir/STU3/search.html#lastUpdated.
An example search request is shown below.
GET [base]/Consent?category=http://snomed.info/sct|11291000146105&_lastUpdated=gt2018-10-01
This search finds all Consent resources with a category SNOMED code 11291000146105 that have been changed since Oct 1, 2018.
Use of coded concepts
Coded information is extremely important for interoperability between systems. It enables systems to act on information rather than have human read everything. It enables medication related alerts, exercise encouragements because your weight increased and many more things. Coded information only works properly when codes are predictable, and in the HCIMs and the profiles we strive towards that. However it is likely that unknown codes present itself in the communication, for example because the sending system has updated its medication codes to a newer version than the receiving system, or because an older record item is coded in a now deprecated way. When this happens it is vital that the sender includes the semantics of the code in his communication.
The generic profiles may not always require the use of (CodeableConcept.)Coding.display and/or CodeableConcept.text, because in closely coupled situations this may be overkill. Within the loosely coupled MedMij context however, systems SHOULD include .display and/or .text for coded data in FHIR instances.
FHIR Packages
MedMij adopts the FHIR Packaging mechanism to support consistent versioning of profiles and related conformance resources such as OperationDefinitions. FHIR Packaging is based on the NPM Packaging mechanism and offers developers a convenient way to include the conformance resources in their favorite IDE. The relevant package version is indicated and linked in the information standards technical design page.
For even more background information:
- Introducing the Simplifier FHIR Package Server (includes what problem packaging addresses)
- Firely Torinox introduction (this is one of the tools that's useful for working with FHIR packages)
- The HL7 wiki that outlines the base specification
|
|
It is not required to implement FHIR based information standards using the packaging mechanism. It is still possible to download all or selected resources from Simplifier on as-needed basis. You are however encouraged to invest in dealing with packages. |
Relevant links
HL7 FHIR specification
Repository of MedMij FHIR artefacts
- Simplifier.net
- GitHub (similar as Simplifier.net)
Test Tools
- MedMij FHIR server - https://vonk.test-nictiz.nl
- Windows desktop validator using .NET HL7 FHIR Profile Validation API - link to download
Contact
MedMij
E: standaarden@medmij.nl
Nictiz
Feedback on content in open consultation
FHIR Questions and Discussions
Release Notes
| Version | Date | Notes |
|---|---|---|
| 2018.06 | 2018-10-29 | Added GGZ |
| 2018.05 | 2018-09-24 | Added GGZ for open consultation |
| 2018.04 | 2018-08-29 | eAfspraak fase 2 |
| 2018.03 | 2018-05-07 | Published BgZ 2017 and GP Data |
| 2018.02 | 2018-03-29 | Added BgZ 2017 |
| 2018.01 | 2018-02-21 | Added GP patient data |
| 2017.04 | 2017-12-18 | Added Appointments, Medication, Laboratory results, AllergyIntolerance, Self-measurements |
| 2017.03 | 2017-11-07 | Added PDF/A |
| 2017.02 | 2017-10-11 | Unchanged. No wiki pages created for FHIR |
| 2017.01 | 2017-10-02 | Initial version containing Patient Administration Resources, Patient Summary (BgZ), |