Brontekst bekijken van MedMij:IG:Vissue-MM-4755/FHIR IG

{{IssuePaginaWaarschuwing|MM-4755|MedMij:IG:V1/FHIR_IG}}
__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR R4 Implementation Guide {{VersieInfo|MedMij_FHIR_IG_R4}}}}
{{MedMij:IG:Vprepub-1/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]

=About the IG=
This is the technical MedMij FHIR implementation guide based on '''HL7® FHIR® version R4'''. 

==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 [https://www.medmij.nl/afsprakenstelsel/ '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 relationships and boundaries.

==Scope==
The scope of this guide includes requirements to enable PHR and XIS vendors 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 [[MedMij:FO:V1/Ontwerpen|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 (data set) and scenarios that define when to exchange which of those concepts. The technical part translates the functional scenarios 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 fact sheet that explains why FHIR is chosen is available on the [https://medmij.nl/wp-content/uploads/2021/12/Factsheet-FHIR-november-2021.pdf MedMij website]. MedMij delivers a FHIR representation ([https://hl7.org/fhir/R4/profiling.html profiles]) for each domain in scope. 

The program ‘Registratie aan de bron’ (Data capture at the point of Care) has defined [https://zibs.nl/wiki/HCIM_Mainpage Health and Care Information models] (zorginformatiebouwstenen or zibs) for The Netherlands. Zibs contain definitions of healthcare concepts. MedMij information standards contain mappings to these zibs. MedMij creates FHIR profiles based on zibs 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 are software vendors and developers that are implementing FHIR as part of electronic information exchange under MedMij. This IG is intended for developers of both PHR and XIS vendors.
Users of this guide are expected to be familiar with the [https://hl7.org/fhir/R4 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=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to 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 <code>Authorization</code>. 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.
=Overarching principles=
{{#lst:FHIR:V1.0_FHIR_IG_R4|FunctionalDefinitions}}
{{#lst:FHIR:V1.0_FHIR_IG_R4|ProfilingGuidelines}}
{{#lst:FHIR:V1.0_FHIR_IG_R4|HTTPHeaders}}
{{#lst:FHIR:V1.0_FHIR_IG_R4|UseOfCodedConcepts}}
{{#lst:FHIR:V1.0_FHIR_IG_R4|UseOfTheReferenceDataType}}
{{#lst:FHIR:V1.0_FHIR_IG_R4|ProfileUseAndDeclaration}}
{{#lst:FHIR:V1.0_FHIR_IG_R4|Search}}
== Handling errors==
Errors in FHIR interactions are usually communicated using the combination of an appropriate HTTP status code in the 4xx-5xx range, and an [https://hl7.org/fhir/R4/operationoutcome.html OperationOutcome] resource providing more details regarding the error. The OperationOutcome resource contains mandatory elements to indicate the overall type and severity of the error (respectively {{fhir|.code}} and {{fhir|.severity}}) and MAY express the location (using {{fhir|.location}} or {{fhir|.expression}}) and a free-form or coded description of the error (using the {{fhir|.diagnostics}} or {{fhir|.details}} element). Although these latter elements are not required, their usage is strongly encouraged.

For the most common errors, the expected handling is listed in the table below. This should be interpreted as a guideline, as the nature of an error is not always unambiguous and various FHIR reference implementations will make different choices. The FHIR specification provides more detail [https://www.hl7.org/fhir/R4/http.html on error handling in general], [https://www.hl7.org/fhir/R4/security.html#AccessDenied access denied responses] and [https://www.hl7.org/fhir/R4/search.html#errors for search operations specifically].

In general, most FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues) will result in one of these HTTP status codes:
* 400 Bad Request - resource could not be parsed, search could not be processed or basic FHIR validation rules failed
* 401 Unauthorized - authorization is required for the interaction that was attempted (usually emitted by the authorization server)
* 403 Forbidden - the server was unable to execute the search, due to an authorization failure (usually emitted by the resource server)
* 404 Not Found - resource type not supported, or not a FHIR endpoint
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules

{| class="wikitable"  
|- 
! Interaction 
! Error 
! Expected action 
! Example 
|-
| rowspan=3 |All 
| Not authorized, absent or expired access token
|
* HTTP 401 Unauthorized
* <del>OperationOutcome with {{fhir|.code}} set to {{term|security}}.</del><br />Please note: the MedMij Afsprakenstelsel explicitly forbids that servers divulge additional information in case of an authorization failure, so servers SHOULD NOT send an OperationOutcome within the MedMij context
| <del>[[FHIR:V1.0 FHIR_Error_handling_examples#Not_authorized|Example]]</del>
|-
| Invalid authorization, scope of the access token is not sufficient for the request
| 
* HTTP 403 Forbidden
* OperationOutcome with {{fhir|.code}} set to {{term|security}}.
| [[FHIR:V1.0 FHIR_Error_handling_examples#Invalid_authorization|Example]]
|-  
| Resource is not supported
|
* HTTP 404 Not Found
* OperationOutcome with {{fhir|.code}} set to {{term|not-supported}}.
| [[FHIR:V1.0 FHIR_Error_handling_examples#Resource_is_not_supported|Example]]
|- 
| rowspan=4 |search
| No match for the given search parameters
| colspan="2" |''This is not considered an error, but a normal search without results.''
|-
| Unknown search parameter
| colspan="2" | ''This is not considered an error. See the [[#unknown_search_parameter_handling|guidance in the section on searching]].''
|- 
| Syntactically incorrect parameter
| 
* HTTP 400 Bad Request
* OperationOutcome. There are various issue type codes that could be used, depending on the nature of the error
| [[FHIR:V1.0 FHIR_Error_handling_examples#Syntactically_incorrect_parameter|Example]]
|-
| Known but unsupported value. This situation applies to non-supported profiles when the Resource endpoint itself is supported.
|
* HTTP 200 OK
* Empty Bundle of {{fhir|.type}} {{term|searchset}}.
* OperationOutcome in Bundle as an entry with {{fhir|Bundle.entry.search.mode}} set to {{term|outcome}}.
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}} and {{fhir|.severity}} not set to {{term|fatal}} or {{term|error}}.
| [[FHIR:V1.0 FHIR_Error_handling_examples#Unkown_or_unsupported_search_parameter_value|Example]]
|- 
| read
| Read request with unknown id
| 
* HTTP 404 Not Found
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}}.
| [[FHIR:V1.0 FHIR_Error_handling_examples#Request_on_an_unknown_id|Example]]
|- 
| update
|  No or incorrect Resource id 
|
* HTTP 400 Bad Request
* OperationOutcome with {{fhir|.code}} set to {{term|invalid}}.
| [[FHIR:V1.0 FHIR_Error_handling_examples#No_or_incorrect_Resource_id|Example]]
|- 
| create/update
| Resource syntax or data is incorrect, invalid or unsupported
| 
* HTTP 400 Bad Request or HTTP 422 Unprocessable Entity
* OperationOutcome with {{fhir|.code}} set to {{term|invalid}} or preferably a more specific child code.
| [[FHIR:V1.0 FHIR_Error_handling_examples#Resource_syntax_or_data_is_incorrect_or_invalid|Example]]
|}
{{#lst:FHIR:V1.0_FHIR_IG_R4|CapabilityStatements}}
{{#lst:FHIR:V1.0_FHIR_IG_R4|ValidationAndTerminology}}
{{#lst:FHIR:V1.0_FHIR_IG_R4|MissingInformation}}
{{#lst:FHIR:V1.0_FHIR_IG_R4|TheNarrative}}

=Release notes=
{{#lsth:Tabellen met release notes|MedMij FHIR R4 Implementation Guide 1}}

{{MedMij:Sjabloon_Support}}