informatiestandaarden - Gebruikersbijdragen [nl]

MedMij:V2020.01/FHIR VitalSigns

2022-11-18T10:09:04Z

Eduard de Rijcke: MM-3808 Added a known issue about lastn and BloodGlucose query

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Self-measurements_Icoon.png|link=|87px |links||Self-Measurements]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.

Use cases:
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve vital signs transaction is used by the PHR to retrieve vital signs from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Vital Signs(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request vital signs from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves vital signs to the PHR
|}

==Invocations==
===PHR: request message===
The request message represents an HTTP GET parameterized query from the PHR to the XIS.

====Trigger Events====
When the patient(PHR) wants to obtain vital signs, it issues a retrieve vital signs request message.

====Message Semantics====
'''Search'''

The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/Observation{/$lastn}{?[parameters]}
</pre>

'''Search Parameters'''

The PHR may supply, and the XIS shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification search parameters of [http://hl7.org/fhir/STU3/observation.html#search Observation].

{| class="wikitable"
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
| token
| The classification of the type of observation.

Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
|
Retrieve all Observation resources that are considered a vital sign observation:
<pre>GET [base]/Observation?category=vital-signs</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
| token
| The code of the observation type.

The different types of measurements are specified using the following LOINC codes:
* Respiration: 9279-1
* BloodPressure: 85354-9
* BodyWeight: 29463-7
* BodyHeight: 8302-2
* BodyTemperature: 8310-5
* Oxygenation, saturation, SpO2: 59408-5
* HeartRate: 8867-4
* PulseRate: 8889-8
* BloodGlucose
** fasting: 14770-2
** general: 14743-9
** post-meal: 14760-3
|
Retrieve all Observation resources that are a blood pressure observation:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
Retrieve the most recent body height and the most recent body weight observation:
<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|
Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
|}

=====Expected Actions=====
The XIS shall process the query to find and return the vital signs matching the provided query parameters.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of matching vital signs Observation.

====Trigger Events====
The XIS completed processing of the retrieve vital signs request message.

====Message Semantics====
The body of the response message shall be a Bundle of type "''searchset''" containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type "''searchset''" shall be returned without any Observation as entries.

In the table below, the vital sign zibs and their respective profiles are listed. Zibs that MUST be supported are marked with (M). Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}

<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}

====Expected Actions====
The PHR processes the results according to application-defined rules.

===The {{fhir|$lastn}} operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The {{fhir|$lastn}} query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The [http://hl7.org/fhir/STU3/observation-operations.html#{{fhir|$lastn}} FHIR STU3] specification is vague regarding the sorting mechanism of {{fhir|$lastn}}. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using {{fhir|$lastn}}, the {{fhir|effective[x]}} element is used for sorting of Observations, sorted from most recent to the oldest.

{{NoteBox|The {{fhir|$lastn}} operation applies differently to the blood glucose measurements, as it may return up to three Observation resources instead of just one. This is due to the fact that blood glucose measurements have three different categories (fasting, general and post-meal), resulting in three possible values for {{fhir|Observation.code}}. To query on blood glucose, the {{fhir|$lastn}} query on blood glucose Observations should include all these three values, but this will result in the latest Observation for ''each'' of these values.}}

=Use case: Send Vital Signs=

==Introduction==
The send vital signs transaction is used by the PHR to send vital signs to the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Vital Signs(PUSH)
|style="background-color: white;vertical-align:top;"|Send vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends vital signs to the XIS
|-
|style="background-color: white;vertical-align:top;"|Send vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives vital signs from the PHR
|}

==Invocations==
===PHR: request message===
The send vital sings request message uses the HTTP POST method on the target XIS's base.

====Trigger Events====
This message is invoked when the PHR needs to send one or more vital signs observations to the XIS.

====Message Semantics====
Because sending vital signs will most likely consist of multiple Observations, a {{fhir|batch}} operation is used. This allows for creating a set of resources in a single interaction and makes it possible to [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|include referenced secondary resources]] if needed.

A {{fhir|batch}} interaction is performed by an HTTP POST command as shown:

<pre>POST [base]</pre>

The body of the post submission is a Bundle with {{fhir|Bundle.type}}={{term|batch}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry. (Note: {{fhir|.request}} is optional, but SHALL be present, even for the resources which aren't Observations. See [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]] for more information.)

{{NoteBox|Sending systems are expected to use an internal reference to the Patient resource included in the request Bundle if they cannot refer to the subject in any other way (see [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]]). This contradicts the FHIR specification, which states that internal references cannot be used for {{fhir|batch}} operations. This is a known issue which will be addressed in the future versions of this information standard. See [https://bits.nictiz.nl/browse/MM-1620 MM-1620] for more information.}}

'''Identification:'''

Sending systems are strongly encouraged to assign a stable identifier to the {{fhir|.identifier}} element when sending vital signs, this helps receiving systems with detecting duplicates and re-identification of Observation resources. For more information on dealing with identifiers, see the [[MedMij:V2020.01/FHIR_IG#When_is_.identifier_expected.3F|general MedMij FHIR IG]].

'''Links:'''

* [http://hl7.org/fhir/STU3/http.html#transaction batch]
* [http://hl7.org/fhir/STU3/http.html#create create]

The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

====Trigger Events====
The XIS completed processing of the send vital signs request message.

====Message Semantics====
The XIS SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Read more:
[http://hl7.org/fhir/STU3/http.html#create create]
[http://hl7.org/fhir/STU3/http.html#transaction batch]

====Expected Actions====
The PHR processes the results according to application-defined rules.

====Handling Errors====
The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Handling_errors Handling Errors section] in the MedMij FHIR IG for more information.

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:Vprepub-2020.01/FHIR VitalSigns

2022-11-18T10:09:04Z

Eduard de Rijcke: MM-3808 Added a known issue about lastn and BloodGlucose query

MedMij:Vissue-MM-3808/FHIR VitalSigns

2022-11-11T13:06:15Z

Eduard de Rijcke: MM-3808 Added a known issue about lastn and BloodGlucose query

{{IssuePaginaWaarschuwing|MM-3808|MedMij:V2020.01/FHIR_VitalSigns}}
__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Self-measurements_Icoon.png|link=|87px |links||Self-Measurements]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.

Use cases:
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve vital signs transaction is used by the PHR to retrieve vital signs from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Vital Signs(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request vital signs from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves vital signs to the PHR
|}

==Invocations==
===PHR: request message===
The request message represents an HTTP GET parameterized query from the PHR to the XIS.

====Trigger Events====
When the patient(PHR) wants to obtain vital signs, it issues a retrieve vital signs request message.

====Message Semantics====
'''Search'''

The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/Observation{/$lastn}{?[parameters]}
</pre>

'''Search Parameters'''

The PHR may supply, and the XIS shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification search parameters of [http://hl7.org/fhir/STU3/observation.html#search Observation].

{| class="wikitable"
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
| token
| The classification of the type of observation.

Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
|
Retrieve all Observation resources that are considered a vital sign observation:
<pre>GET [base]/Observation?category=vital-signs</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
| token
| The code of the observation type.

The different types of measurements are specified using the following LOINC codes:
* Respiration: 9279-1
* BloodPressure: 85354-9
* BodyWeight: 29463-7
* BodyHeight: 8302-2
* BodyTemperature: 8310-5
* Oxygenation, saturation, SpO2: 59408-5
* HeartRate: 8867-4
* PulseRate: 8889-8
* BloodGlucose
** fasting: 14770-2
** general: 14743-9
** post-meal: 14760-3
|
Retrieve all Observation resources that are a blood pressure observation:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
Retrieve the most recent body height and the most recent body weight observation:
<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|
Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
|}

=====Expected Actions=====
The XIS shall process the query to find and return the vital signs matching the provided query parameters.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of matching vital signs Observation.

====Trigger Events====
The XIS completed processing of the retrieve vital signs request message.

====Message Semantics====
The body of the response message shall be a Bundle of type "''searchset''" containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type "''searchset''" shall be returned without any Observation as entries.

In the table below, the vital sign zibs and their respective profiles are listed. Zibs that MUST be supported are marked with (M). Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}

<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}

====Expected Actions====
The PHR processes the results according to application-defined rules.

===The <code>lastn</code> operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The [http://hl7.org/fhir/STU3/observation-operations.html#lastn FHIR STU3] specification is vague regarding the sorting mechanism of lastn. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using lastn, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

{{NoteBox|The lastn operation applies differently to the BloodGlucose Observation resource, as BloodGlucose has three different categories (fasting, general and post-meal). This means that the lastn query on BloodGlucose will result in the latest observation for each of these three categories and will therefore return three values instead of one.}}

=Use case: Send Vital Signs=

==Introduction==
The send vital signs transaction is used by the PHR to send vital signs to the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Vital Signs(PUSH)
|style="background-color: white;vertical-align:top;"|Send vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends vital signs to the XIS
|-
|style="background-color: white;vertical-align:top;"|Send vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives vital signs from the PHR
|}

==Invocations==
===PHR: request message===
The send vital sings request message uses the HTTP POST method on the target XIS's base.

====Trigger Events====
This message is invoked when the PHR needs to send one or more vital signs observations to the XIS.

====Message Semantics====
Because sending vital signs will most likely consist of multiple Observations, a {{fhir|batch}} operation is used. This allows for creating a set of resources in a single interaction and makes it possible to [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|include referenced secondary resources]] if needed.

A {{fhir|batch}} interaction is performed by an HTTP POST command as shown:

<pre>POST [base]</pre>

The body of the post submission is a Bundle with {{fhir|Bundle.type}}={{term|batch}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry. (Note: {{fhir|.request}} is optional, but SHALL be present, even for the resources which aren't Observations. See [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]] for more information.)

{{NoteBox|Sending systems are expected to use an internal reference to the Patient resource included in the request Bundle if they cannot refer to the subject in any other way (see [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]]). This contradicts the FHIR specification, which states that internal references cannot be used for {{fhir|batch}} operations. This is a known issue which will be addressed in the future versions of this information standard. See [https://bits.nictiz.nl/browse/MM-1620 MM-1620] for more information.}}

'''Identification:'''

Sending systems are strongly encouraged to assign a stable identifier to the {{fhir|.identifier}} element when sending vital signs, this helps receiving systems with detecting duplicates and re-identification of Observation resources. For more information on dealing with identifiers, see the [[MedMij:Vprepub-2020.01/FHIR_IG#When_is_.identifier_expected.3F|general MedMij FHIR IG]].

'''Links:'''

* [http://hl7.org/fhir/STU3/http.html#transaction batch]
* [http://hl7.org/fhir/STU3/http.html#create create]

The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

====Trigger Events====
The XIS completed processing of the send vital signs request message.

====Message Semantics====
The XIS SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Read more:
[http://hl7.org/fhir/STU3/http.html#create create]
[http://hl7.org/fhir/STU3/http.html#transaction batch]

====Expected Actions====
The PHR processes the results according to application-defined rules.

====Handling Errors====
The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Handling_errors Handling Errors section] in the MedMij FHIR IG for more information.

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:Vissue-MM-3808/FHIR VitalSigns

2022-11-09T10:47:09Z

Eduard de Rijcke: MM-3808 Added a known issue about lastn and BloodGlucose query

{{IssuePaginaWaarschuwing|MM-3808|MedMij:V2020.01/FHIR_VitalSigns}}
__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Self-measurements_Icoon.png|link=|87px |links||Self-Measurements]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.

Use cases:
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve vital signs transaction is used by the PHR to retrieve vital signs from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Vital Signs(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request vital signs from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves vital signs to the PHR
|}

==Invocations==
===PHR: request message===
The request message represents an HTTP GET parameterized query from the PHR to the XIS.

====Trigger Events====
When the patient(PHR) wants to obtain vital signs, it issues a retrieve vital signs request message.

====Message Semantics====
'''Search'''

The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/Observation{/$lastn}{?[parameters]}
</pre>

'''Search Parameters'''

The PHR may supply, and the XIS shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification search parameters of [http://hl7.org/fhir/STU3/observation.html#search Observation].

{| class="wikitable"
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
| token
| The classification of the type of observation.

Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
|
Retrieve all Observation resources that are considered a vital sign observation:
<pre>GET [base]/Observation?category=vital-signs</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
| token
| The code of the observation type.

The different types of measurements are specified using the following LOINC codes:
* Respiration: 9279-1
* BloodPressure: 85354-9
* BodyWeight: 29463-7
* BodyHeight: 8302-2
* BodyTemperature: 8310-5
* Oxygenation, saturation, SpO2: 59408-5
* HeartRate: 8867-4
* PulseRate: 8889-8
* BloodGlucose
** fasting: 14770-2
** general: 14743-9
** post-meal: 14760-3
|
Retrieve all Observation resources that are a blood pressure observation:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
Retrieve the most recent body height and the most recent body weight observation:
<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|
Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
|}

=====Expected Actions=====
The XIS shall process the query to find and return the vital signs matching the provided query parameters.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of matching vital signs Observation.

====Trigger Events====
The XIS completed processing of the retrieve vital signs request message.

====Message Semantics====
The body of the response message shall be a Bundle of type "''searchset''" containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type "''searchset''" shall be returned without any Observation as entries.

In the table below, the vital sign zibs and their respective profiles are listed. Zibs that MUST be supported are marked with (M). Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}

<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}

====Expected Actions====
The PHR processes the results according to application-defined rules.

===The <code>lastn</code> operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The [http://hl7.org/fhir/STU3/observation-operations.html#lastn FHIR STU3] specification is vague regarding the sorting mechanism of lastn. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using lastn, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

{{NoteBox|The Lastn query couldn't apply for the lastest BloodGlucose Observation because BloodGlucose has three different categories (fasting, general and post-meal). For each category of BloodGlucose, the lastn will be applied.}}

=Use case: Send Vital Signs=

==Introduction==
The send vital signs transaction is used by the PHR to send vital signs to the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Vital Signs(PUSH)
|style="background-color: white;vertical-align:top;"|Send vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends vital signs to the XIS
|-
|style="background-color: white;vertical-align:top;"|Send vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives vital signs from the PHR
|}

==Invocations==
===PHR: request message===
The send vital sings request message uses the HTTP POST method on the target XIS's base.

====Trigger Events====
This message is invoked when the PHR needs to send one or more vital signs observations to the XIS.

====Message Semantics====
Because sending vital signs will most likely consist of multiple Observations, a {{fhir|batch}} operation is used. This allows for creating a set of resources in a single interaction and makes it possible to [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|include referenced secondary resources]] if needed.

A {{fhir|batch}} interaction is performed by an HTTP POST command as shown:

<pre>POST [base]</pre>

The body of the post submission is a Bundle with {{fhir|Bundle.type}}={{term|batch}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry. (Note: {{fhir|.request}} is optional, but SHALL be present, even for the resources which aren't Observations. See [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]] for more information.)

{{NoteBox|Sending systems are expected to use an internal reference to the Patient resource included in the request Bundle if they cannot refer to the subject in any other way (see [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]]). This contradicts the FHIR specification, which states that internal references cannot be used for {{fhir|batch}} operations. This is a known issue which will be addressed in the future versions of this information standard. See [https://bits.nictiz.nl/browse/MM-1620 MM-1620] for more information.}}

'''Identification:'''

Sending systems are strongly encouraged to assign a stable identifier to the {{fhir|.identifier}} element when sending vital signs, this helps receiving systems with detecting duplicates and re-identification of Observation resources. For more information on dealing with identifiers, see the [[MedMij:Vprepub-2020.01/FHIR_IG#When_is_.identifier_expected.3F|general MedMij FHIR IG]].

'''Links:'''

* [http://hl7.org/fhir/STU3/http.html#transaction batch]
* [http://hl7.org/fhir/STU3/http.html#create create]

The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

====Trigger Events====
The XIS completed processing of the send vital signs request message.

====Message Semantics====
The XIS SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Read more:
[http://hl7.org/fhir/STU3/http.html#create create]
[http://hl7.org/fhir/STU3/http.html#transaction batch]

====Expected Actions====
The PHR processes the results according to application-defined rules.

====Handling Errors====
The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Handling_errors Handling Errors section] in the MedMij FHIR IG for more information.

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:Vissue-MM-3808/FHIR VitalSigns

2022-11-09T10:39:46Z

Eduard de Rijcke: MM-3808 Added a known issue about lastn and BloodGlucose query

{{IssuePaginaWaarschuwing|MM-3808|MedMij:V2020.01/FHIR_VitalSigns}}
__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Self-measurements_Icoon.png|link=|87px |links||Self-Measurements]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.

Use cases:
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve vital signs transaction is used by the PHR to retrieve vital signs from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Vital Signs(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request vital signs from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves vital signs to the PHR
|}

==Invocations==
===PHR: request message===
The request message represents an HTTP GET parameterized query from the PHR to the XIS.

====Trigger Events====
When the patient(PHR) wants to obtain vital signs, it issues a retrieve vital signs request message.

====Message Semantics====
'''Search'''

The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/Observation{/$lastn}{?[parameters]}
</pre>

'''Search Parameters'''

The PHR may supply, and the XIS shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification search parameters of [http://hl7.org/fhir/STU3/observation.html#search Observation].

{| class="wikitable"
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
| token
| The classification of the type of observation.

Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
|
Retrieve all Observation resources that are considered a vital sign observation:
<pre>GET [base]/Observation?category=vital-signs</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
| token
| The code of the observation type.

The different types of measurements are specified using the following LOINC codes:
* Respiration: 9279-1
* BloodPressure: 85354-9
* BodyWeight: 29463-7
* BodyHeight: 8302-2
* BodyTemperature: 8310-5
* Oxygenation, saturation, SpO2: 59408-5
* HeartRate: 8867-4
* PulseRate: 8889-8
* BloodGlucose
** fasting: 14770-2
** general: 14743-9
** post-meal: 14760-3
|
Retrieve all Observation resources that are a blood pressure observation:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
Retrieve the most recent body height and the most recent body weight observation:
<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|
Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
|}

=====Expected Actions=====
The XIS shall process the query to find and return the vital signs matching the provided query parameters.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of matching vital signs Observation.

====Trigger Events====
The XIS completed processing of the retrieve vital signs request message.

====Message Semantics====
The body of the response message shall be a Bundle of type "''searchset''" containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type "''searchset''" shall be returned without any Observation as entries.

In the table below, the vital sign zibs and their respective profiles are listed. Zibs that MUST be supported are marked with (M). Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}

<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}

====Expected Actions====
The PHR processes the results according to application-defined rules.

===The <code>lastn</code> operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The [http://hl7.org/fhir/STU3/observation-operations.html#lastn FHIR STU3] specification is vague regarding the sorting mechanism of lastn. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using lastn, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

{{NoteBox|With the Lastn query it isn't possible to receive the lastest BloodGlucose Observation because BloodGlucose has three different categories (fasting, general and post-meal). For each category of the BloodGlucose, the lastn will be applied.}}

=Use case: Send Vital Signs=

==Introduction==
The send vital signs transaction is used by the PHR to send vital signs to the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Vital Signs(PUSH)
|style="background-color: white;vertical-align:top;"|Send vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends vital signs to the XIS
|-
|style="background-color: white;vertical-align:top;"|Send vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives vital signs from the PHR
|}

==Invocations==
===PHR: request message===
The send vital sings request message uses the HTTP POST method on the target XIS's base.

====Trigger Events====
This message is invoked when the PHR needs to send one or more vital signs observations to the XIS.

====Message Semantics====
Because sending vital signs will most likely consist of multiple Observations, a {{fhir|batch}} operation is used. This allows for creating a set of resources in a single interaction and makes it possible to [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|include referenced secondary resources]] if needed.

A {{fhir|batch}} interaction is performed by an HTTP POST command as shown:

<pre>POST [base]</pre>

The body of the post submission is a Bundle with {{fhir|Bundle.type}}={{term|batch}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry. (Note: {{fhir|.request}} is optional, but SHALL be present, even for the resources which aren't Observations. See [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]] for more information.)

{{NoteBox|Sending systems are expected to use an internal reference to the Patient resource included in the request Bundle if they cannot refer to the subject in any other way (see [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]]). This contradicts the FHIR specification, which states that internal references cannot be used for {{fhir|batch}} operations. This is a known issue which will be addressed in the future versions of this information standard. See [https://bits.nictiz.nl/browse/MM-1620 MM-1620] for more information.}}

'''Identification:'''

Sending systems are strongly encouraged to assign a stable identifier to the {{fhir|.identifier}} element when sending vital signs, this helps receiving systems with detecting duplicates and re-identification of Observation resources. For more information on dealing with identifiers, see the [[MedMij:Vprepub-2020.01/FHIR_IG#When_is_.identifier_expected.3F|general MedMij FHIR IG]].

'''Links:'''

* [http://hl7.org/fhir/STU3/http.html#transaction batch]
* [http://hl7.org/fhir/STU3/http.html#create create]

The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

====Trigger Events====
The XIS completed processing of the send vital signs request message.

====Message Semantics====
The XIS SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Read more:
[http://hl7.org/fhir/STU3/http.html#create create]
[http://hl7.org/fhir/STU3/http.html#transaction batch]

====Expected Actions====
The PHR processes the results according to application-defined rules.

====Handling Errors====
The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Handling_errors Handling Errors section] in the MedMij FHIR IG for more information.

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:Vissue-MM-3808/FHIR VitalSigns

2022-11-09T10:38:07Z

Eduard de Rijcke: MM-3808 Added a known issue about lastn and BloodGlucose query

{{IssuePaginaWaarschuwing|MM-3808|MedMij:V2020.01/FHIR_VitalSigns}}
__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Self-measurements_Icoon.png|link=|87px |links||Self-Measurements]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.

Use cases:
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve vital signs transaction is used by the PHR to retrieve vital signs from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Vital Signs(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request vital signs from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves vital signs to the PHR
|}

==Invocations==
===PHR: request message===
The request message represents an HTTP GET parameterized query from the PHR to the XIS.

====Trigger Events====
When the patient(PHR) wants to obtain vital signs, it issues a retrieve vital signs request message.

====Message Semantics====
'''Search'''

The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/Observation{/$lastn}{?[parameters]}
</pre>

'''Search Parameters'''

The PHR may supply, and the XIS shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification search parameters of [http://hl7.org/fhir/STU3/observation.html#search Observation].

{| class="wikitable"
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
| token
| The classification of the type of observation.

Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
|
Retrieve all Observation resources that are considered a vital sign observation:
<pre>GET [base]/Observation?category=vital-signs</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
| token
| The code of the observation type.

The different types of measurements are specified using the following LOINC codes:
* Respiration: 9279-1
* BloodPressure: 85354-9
* BodyWeight: 29463-7
* BodyHeight: 8302-2
* BodyTemperature: 8310-5
* Oxygenation, saturation, SpO2: 59408-5
* HeartRate: 8867-4
* PulseRate: 8889-8
* BloodGlucose
** fasting: 14770-2
** general: 14743-9
** post-meal: 14760-3
|
Retrieve all Observation resources that are a blood pressure observation:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
Retrieve the most recent body height and the most recent body weight observation:
<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|
Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
|}

=====Expected Actions=====
The XIS shall process the query to find and return the vital signs matching the provided query parameters.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of matching vital signs Observation.

====Trigger Events====
The XIS completed processing of the retrieve vital signs request message.

====Message Semantics====
The body of the response message shall be a Bundle of type "''searchset''" containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type "''searchset''" shall be returned without any Observation as entries.

In the table below, the vital sign zibs and their respective profiles are listed. Zibs that MUST be supported are marked with (M). Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}

<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}

====Expected Actions====
The PHR processes the results according to application-defined rules.

===The <code>lastn</code> operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The [http://hl7.org/fhir/STU3/observation-operations.html#lastn FHIR STU3] specification is vague regarding the sorting mechanism of lastn. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using lastn, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

{{NoteBox|With the Lastn query it isn't possible to receive the lastest BloodGlucose Observation because BloodGlucose has three different categories (fasting, general and post-meal). For each category, the lastn will be applied.}}

=Use case: Send Vital Signs=

==Introduction==
The send vital signs transaction is used by the PHR to send vital signs to the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Vital Signs(PUSH)
|style="background-color: white;vertical-align:top;"|Send vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends vital signs to the XIS
|-
|style="background-color: white;vertical-align:top;"|Send vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives vital signs from the PHR
|}

==Invocations==
===PHR: request message===
The send vital sings request message uses the HTTP POST method on the target XIS's base.

====Trigger Events====
This message is invoked when the PHR needs to send one or more vital signs observations to the XIS.

====Message Semantics====
Because sending vital signs will most likely consist of multiple Observations, a {{fhir|batch}} operation is used. This allows for creating a set of resources in a single interaction and makes it possible to [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|include referenced secondary resources]] if needed.

A {{fhir|batch}} interaction is performed by an HTTP POST command as shown:

<pre>POST [base]</pre>

The body of the post submission is a Bundle with {{fhir|Bundle.type}}={{term|batch}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry. (Note: {{fhir|.request}} is optional, but SHALL be present, even for the resources which aren't Observations. See [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]] for more information.)

{{NoteBox|Sending systems are expected to use an internal reference to the Patient resource included in the request Bundle if they cannot refer to the subject in any other way (see [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]]). This contradicts the FHIR specification, which states that internal references cannot be used for {{fhir|batch}} operations. This is a known issue which will be addressed in the future versions of this information standard. See [https://bits.nictiz.nl/browse/MM-1620 MM-1620] for more information.}}

'''Identification:'''

Sending systems are strongly encouraged to assign a stable identifier to the {{fhir|.identifier}} element when sending vital signs, this helps receiving systems with detecting duplicates and re-identification of Observation resources. For more information on dealing with identifiers, see the [[MedMij:Vprepub-2020.01/FHIR_IG#When_is_.identifier_expected.3F|general MedMij FHIR IG]].

'''Links:'''

* [http://hl7.org/fhir/STU3/http.html#transaction batch]
* [http://hl7.org/fhir/STU3/http.html#create create]

The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

====Trigger Events====
The XIS completed processing of the send vital signs request message.

====Message Semantics====
The XIS SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Read more:
[http://hl7.org/fhir/STU3/http.html#create create]
[http://hl7.org/fhir/STU3/http.html#transaction batch]

====Expected Actions====
The PHR processes the results according to application-defined rules.

====Handling Errors====
The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Handling_errors Handling Errors section] in the MedMij FHIR IG for more information.

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:Vissue-MM-3808/FHIR VitalSigns

2022-11-09T10:36:00Z

Eduard de Rijcke: MM-3808 Added a known issue about lastn and BloodGlucose query

{{IssuePaginaWaarschuwing|MM-3808|MedMij:V2020.01/FHIR_VitalSigns}}
__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Self-measurements_Icoon.png|link=|87px |links||Self-Measurements]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.

Use cases:
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve vital signs transaction is used by the PHR to retrieve vital signs from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Vital Signs(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request vital signs from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves vital signs to the PHR
|}

==Invocations==
===PHR: request message===
The request message represents an HTTP GET parameterized query from the PHR to the XIS.

====Trigger Events====
When the patient(PHR) wants to obtain vital signs, it issues a retrieve vital signs request message.

====Message Semantics====
'''Search'''

The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/Observation{/$lastn}{?[parameters]}
</pre>

'''Search Parameters'''

The PHR may supply, and the XIS shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification search parameters of [http://hl7.org/fhir/STU3/observation.html#search Observation].

{| class="wikitable"
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
| token
| The classification of the type of observation.

Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
|
Retrieve all Observation resources that are considered a vital sign observation:
<pre>GET [base]/Observation?category=vital-signs</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
| token
| The code of the observation type.

The different types of measurements are specified using the following LOINC codes:
* Respiration: 9279-1
* BloodPressure: 85354-9
* BodyWeight: 29463-7
* BodyHeight: 8302-2
* BodyTemperature: 8310-5
* Oxygenation, saturation, SpO2: 59408-5
* HeartRate: 8867-4
* PulseRate: 8889-8
* BloodGlucose
** fasting: 14770-2
** general: 14743-9
** post-meal: 14760-3
|
Retrieve all Observation resources that are a blood pressure observation:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
Retrieve the most recent body height and the most recent body weight observation:
<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|
Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
|}

=====Expected Actions=====
The XIS shall process the query to find and return the vital signs matching the provided query parameters.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of matching vital signs Observation.

====Trigger Events====
The XIS completed processing of the retrieve vital signs request message.

====Message Semantics====
The body of the response message shall be a Bundle of type "''searchset''" containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type "''searchset''" shall be returned without any Observation as entries.

In the table below, the vital sign zibs and their respective profiles are listed. Zibs that MUST be supported are marked with (M). Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}

<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}

====Expected Actions====
The PHR processes the results according to application-defined rules.

===The <code>lastn</code> operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The [http://hl7.org/fhir/STU3/observation-operations.html#lastn FHIR STU3] specification is vague regarding the sorting mechanism of lastn. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using lastn, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

{{NoteBox|With the Lastn query it isn't possible to receive the lastest BloodGlucose Observation because BloodGlucose has three different categories (fasting, general and post-meal). For each category there will be }}

=Use case: Send Vital Signs=

==Introduction==
The send vital signs transaction is used by the PHR to send vital signs to the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Vital Signs(PUSH)
|style="background-color: white;vertical-align:top;"|Send vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends vital signs to the XIS
|-
|style="background-color: white;vertical-align:top;"|Send vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives vital signs from the PHR
|}

==Invocations==
===PHR: request message===
The send vital sings request message uses the HTTP POST method on the target XIS's base.

====Trigger Events====
This message is invoked when the PHR needs to send one or more vital signs observations to the XIS.

====Message Semantics====
Because sending vital signs will most likely consist of multiple Observations, a {{fhir|batch}} operation is used. This allows for creating a set of resources in a single interaction and makes it possible to [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|include referenced secondary resources]] if needed.

A {{fhir|batch}} interaction is performed by an HTTP POST command as shown:

<pre>POST [base]</pre>

The body of the post submission is a Bundle with {{fhir|Bundle.type}}={{term|batch}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry. (Note: {{fhir|.request}} is optional, but SHALL be present, even for the resources which aren't Observations. See [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]] for more information.)

{{NoteBox|Sending systems are expected to use an internal reference to the Patient resource included in the request Bundle if they cannot refer to the subject in any other way (see [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]]). This contradicts the FHIR specification, which states that internal references cannot be used for {{fhir|batch}} operations. This is a known issue which will be addressed in the future versions of this information standard. See [https://bits.nictiz.nl/browse/MM-1620 MM-1620] for more information.}}

'''Identification:'''

Sending systems are strongly encouraged to assign a stable identifier to the {{fhir|.identifier}} element when sending vital signs, this helps receiving systems with detecting duplicates and re-identification of Observation resources. For more information on dealing with identifiers, see the [[MedMij:Vprepub-2020.01/FHIR_IG#When_is_.identifier_expected.3F|general MedMij FHIR IG]].

'''Links:'''

* [http://hl7.org/fhir/STU3/http.html#transaction batch]
* [http://hl7.org/fhir/STU3/http.html#create create]

The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

====Trigger Events====
The XIS completed processing of the send vital signs request message.

====Message Semantics====
The XIS SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Read more:
[http://hl7.org/fhir/STU3/http.html#create create]
[http://hl7.org/fhir/STU3/http.html#transaction batch]

====Expected Actions====
The PHR processes the results according to application-defined rules.

====Handling Errors====
The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Handling_errors Handling Errors section] in the MedMij FHIR IG for more information.

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:Vissue-MM-3808/FHIR VitalSigns

2022-11-09T09:45:09Z

Eduard de Rijcke: Clone of V2020.01 production page for issue MM-3808

{{IssuePaginaWaarschuwing|MM-3808|MedMij:V2020.01/FHIR_VitalSigns}}
__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Self-measurements_Icoon.png|link=|87px |links||Self-Measurements]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.

Use cases:
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve vital signs transaction is used by the PHR to retrieve vital signs from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Vital Signs(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request vital signs from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves vital signs to the PHR
|}

==Invocations==
===PHR: request message===
The request message represents an HTTP GET parameterized query from the PHR to the XIS.

====Trigger Events====
When the patient(PHR) wants to obtain vital signs, it issues a retrieve vital signs request message.

====Message Semantics====
'''Search'''

The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/Observation{/$lastn}{?[parameters]}
</pre>

'''Search Parameters'''

The PHR may supply, and the XIS shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification search parameters of [http://hl7.org/fhir/STU3/observation.html#search Observation].

{| class="wikitable"
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
| token
| The classification of the type of observation.

Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
|
Retrieve all Observation resources that are considered a vital sign observation:
<pre>GET [base]/Observation?category=vital-signs</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
| token
| The code of the observation type.

The different types of measurements are specified using the following LOINC codes:
* Respiration: 9279-1
* BloodPressure: 85354-9
* BodyWeight: 29463-7
* BodyHeight: 8302-2
* BodyTemperature: 8310-5
* Oxygenation, saturation, SpO2: 59408-5
* HeartRate: 8867-4
* PulseRate: 8889-8
* BloodGlucose
** fasting: 14770-2
** general: 14743-9
** post-meal: 14760-3
|
Retrieve all Observation resources that are a blood pressure observation:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
Retrieve the most recent body height and the most recent body weight observation:
<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|
Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
|}

=====Expected Actions=====
The XIS shall process the query to find and return the vital signs matching the provided query parameters.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of matching vital signs Observation.

====Trigger Events====
The XIS completed processing of the retrieve vital signs request message.

====Message Semantics====
The body of the response message shall be a Bundle of type "''searchset''" containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type "''searchset''" shall be returned without any Observation as entries.

In the table below, the vital sign zibs and their respective profiles are listed. Zibs that MUST be supported are marked with (M). Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}

<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}

====Expected Actions====
The PHR processes the results according to application-defined rules.

===The <code>lastn</code> operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The [http://hl7.org/fhir/STU3/observation-operations.html#lastn FHIR STU3] specification is vague regarding the sorting mechanism of lastn. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using lastn, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

=Use case: Send Vital Signs=

==Introduction==
The send vital signs transaction is used by the PHR to send vital signs to the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Vital Signs(PUSH)
|style="background-color: white;vertical-align:top;"|Send vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends vital signs to the XIS
|-
|style="background-color: white;vertical-align:top;"|Send vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives vital signs from the PHR
|}

==Invocations==
===PHR: request message===
The send vital sings request message uses the HTTP POST method on the target XIS's base.

====Trigger Events====
This message is invoked when the PHR needs to send one or more vital signs observations to the XIS.

====Message Semantics====
Because sending vital signs will most likely consist of multiple Observations, a {{fhir|batch}} operation is used. This allows for creating a set of resources in a single interaction and makes it possible to [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|include referenced secondary resources]] if needed.

A {{fhir|batch}} interaction is performed by an HTTP POST command as shown:

<pre>POST [base]</pre>

The body of the post submission is a Bundle with {{fhir|Bundle.type}}={{term|batch}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry. (Note: {{fhir|.request}} is optional, but SHALL be present, even for the resources which aren't Observations. See [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]] for more information.)

{{NoteBox|Sending systems are expected to use an internal reference to the Patient resource included in the request Bundle if they cannot refer to the subject in any other way (see [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]]). This contradicts the FHIR specification, which states that internal references cannot be used for {{fhir|batch}} operations. This is a known issue which will be addressed in the future versions of this information standard. See [https://bits.nictiz.nl/browse/MM-1620 MM-1620] for more information.}}

'''Identification:'''

Sending systems are strongly encouraged to assign a stable identifier to the {{fhir|.identifier}} element when sending vital signs, this helps receiving systems with detecting duplicates and re-identification of Observation resources. For more information on dealing with identifiers, see the [[MedMij:Vprepub-2020.01/FHIR_IG#When_is_.identifier_expected.3F|general MedMij FHIR IG]].

'''Links:'''

* [http://hl7.org/fhir/STU3/http.html#transaction batch]
* [http://hl7.org/fhir/STU3/http.html#create create]

The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

====Trigger Events====
The XIS completed processing of the send vital signs request message.

====Message Semantics====
The XIS SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Read more:
[http://hl7.org/fhir/STU3/http.html#create create]
[http://hl7.org/fhir/STU3/http.html#transaction batch]

====Expected Actions====
The PHR processes the results according to application-defined rules.

====Handling Errors====
The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Handling_errors Handling Errors section] in the MedMij FHIR IG for more information.

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:V2020.01/FHIR VitalSigns

2022-10-05T12:02:05Z

Eduard de Rijcke: MM-3549 Added a known issue about the Batch Operation at Vital Signs

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Self-measurements_Icoon.png|link=|87px |links||Self-Measurements]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.

Use cases:
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve vital signs transaction is used by the PHR to retrieve vital signs from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Vital Signs(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request vital signs from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves vital signs to the PHR
|}

==Invocations==
===PHR: request message===
The request message represents an HTTP GET parameterized query from the PHR to the XIS.

====Trigger Events====
When the patient(PHR) wants to obtain vital signs, it issues a retrieve vital signs request message.

====Message Semantics====
'''Search'''

The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/Observation{/$lastn}{?[parameters]}
</pre>

'''Search Parameters'''

The PHR may supply, and the XIS shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification search parameters of [http://hl7.org/fhir/STU3/observation.html#search Observation].

{| class="wikitable"
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
| token
| The classification of the type of observation.

Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
|
Retrieve all Observation resources that are considered a vital sign observation:
<pre>GET [base]/Observation?category=vital-signs</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
| token
| The code of the observation type.

The different types of measurements are specified using the following LOINC codes:
* Respiration: 9279-1
* BloodPressure: 85354-9
* BodyWeight: 29463-7
* BodyHeight: 8302-2
* BodyTemperature: 8310-5
* Oxygenation, saturation, SpO2: 59408-5
* HeartRate: 8867-4
* PulseRate: 8889-8
* BloodGlucose
** fasting: 14770-2
** general: 14743-9
** post-meal: 14760-3
|
Retrieve all Observation resources that are a blood pressure observation:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
Retrieve the most recent body height and the most recent body weight observation:
<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|
Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
|}

=====Expected Actions=====
The XIS shall process the query to find and return the vital signs matching the provided query parameters.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of matching vital signs Observation.

====Trigger Events====
The XIS completed processing of the retrieve vital signs request message.

====Message Semantics====
The body of the response message shall be a Bundle of type "''searchset''" containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type "''searchset''" shall be returned without any Observation as entries.

In the table below, the vital sign zibs and their respective profiles are listed. Zibs that MUST be supported are marked with (M). Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}

<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}

====Expected Actions====
The PHR processes the results according to application-defined rules.

===The <code>lastn</code> operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The [http://hl7.org/fhir/STU3/observation-operations.html#lastn FHIR STU3] specification is vague regarding the sorting mechanism of lastn. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using lastn, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

=Use case: Send Vital Signs=

==Introduction==
The send vital signs transaction is used by the PHR to send vital signs to the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Vital Signs(PUSH)
|style="background-color: white;vertical-align:top;"|Send vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends vital signs to the XIS
|-
|style="background-color: white;vertical-align:top;"|Send vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives vital signs from the PHR
|}

==Invocations==
===PHR: request message===
The send vital sings request message uses the HTTP POST method on the target XIS's base.

====Trigger Events====
This message is invoked when the PHR needs to send one or more vital signs observations to the XIS.

====Message Semantics====
Because sending vital signs will most likely consist of multiple Observations, a {{fhir|batch}} operation is used. This allows for creating a set of resources in a single interaction and makes it possible to [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|include referenced secondary resources]] if needed.

A {{fhir|batch}} interaction is performed by an HTTP POST command as shown:

<pre>POST [base]</pre>

The body of the post submission is a Bundle with {{fhir|Bundle.type}}={{term|batch}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry. (Note: {{fhir|.request}} is optional, but SHALL be present, even for the resources which aren't Observations. See [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]] for more information.)

{{NoteBox|Sending systems are expected to use an internal reference to the Patient resource included in the request Bundle if they cannot refer to the subject in any other way (see [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]]). This contradicts the FHIR specification, which states that internal references cannot be used for {{fhir|batch}} operations. This is a known issue which will be addressed in the future versions of this information standard. See [https://bits.nictiz.nl/browse/MM-1620 MM-1620] for more information.}}

'''Identification:'''

Sending systems are strongly encouraged to assign a stable identifier to the {{fhir|.identifier}} element when sending vital signs, this helps receiving systems with detecting duplicates and re-identification of Observation resources. For more information on dealing with identifiers, see the [[MedMij:V2020.01/FHIR_IG#When_is_.identifier_expected.3F|general MedMij FHIR IG]].

'''Links:'''

* [http://hl7.org/fhir/STU3/http.html#transaction batch]
* [http://hl7.org/fhir/STU3/http.html#create create]

The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

====Trigger Events====
The XIS completed processing of the send vital signs request message.

====Message Semantics====
The XIS SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Read more:
[http://hl7.org/fhir/STU3/http.html#create create]
[http://hl7.org/fhir/STU3/http.html#transaction batch]

====Expected Actions====
The PHR processes the results according to application-defined rules.

====Handling Errors====
The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Handling_errors Handling Errors section] in the MedMij FHIR IG for more information.

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:Vprepub-2020.01/FHIR VitalSigns

2022-10-05T12:02:05Z

Eduard de Rijcke: MM-3549 Added a known issue about the Batch Operation at Vital Signs

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Self-measurements_Icoon.png|link=|87px |links||Self-Measurements]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.

Use cases:
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve vital signs transaction is used by the PHR to retrieve vital signs from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Vital Signs(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request vital signs from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves vital signs to the PHR
|}

==Invocations==
===PHR: request message===
The request message represents an HTTP GET parameterized query from the PHR to the XIS.

====Trigger Events====
When the patient(PHR) wants to obtain vital signs, it issues a retrieve vital signs request message.

====Message Semantics====
'''Search'''

The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/Observation{/$lastn}{?[parameters]}
</pre>

'''Search Parameters'''

The PHR may supply, and the XIS shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification search parameters of [http://hl7.org/fhir/STU3/observation.html#search Observation].

{| class="wikitable"
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
| token
| The classification of the type of observation.

Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
|
Retrieve all Observation resources that are considered a vital sign observation:
<pre>GET [base]/Observation?category=vital-signs</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
| token
| The code of the observation type.

The different types of measurements are specified using the following LOINC codes:
* Respiration: 9279-1
* BloodPressure: 85354-9
* BodyWeight: 29463-7
* BodyHeight: 8302-2
* BodyTemperature: 8310-5
* Oxygenation, saturation, SpO2: 59408-5
* HeartRate: 8867-4
* PulseRate: 8889-8
* BloodGlucose
** fasting: 14770-2
** general: 14743-9
** post-meal: 14760-3
|
Retrieve all Observation resources that are a blood pressure observation:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
Retrieve the most recent body height and the most recent body weight observation:
<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|
Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
|}

=====Expected Actions=====
The XIS shall process the query to find and return the vital signs matching the provided query parameters.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of matching vital signs Observation.

====Trigger Events====
The XIS completed processing of the retrieve vital signs request message.

====Message Semantics====
The body of the response message shall be a Bundle of type "''searchset''" containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type "''searchset''" shall be returned without any Observation as entries.

In the table below, the vital sign zibs and their respective profiles are listed. Zibs that MUST be supported are marked with (M). Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}

<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}

====Expected Actions====
The PHR processes the results according to application-defined rules.

===The <code>lastn</code> operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The [http://hl7.org/fhir/STU3/observation-operations.html#lastn FHIR STU3] specification is vague regarding the sorting mechanism of lastn. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using lastn, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

=Use case: Send Vital Signs=

==Introduction==
The send vital signs transaction is used by the PHR to send vital signs to the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Vital Signs(PUSH)
|style="background-color: white;vertical-align:top;"|Send vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends vital signs to the XIS
|-
|style="background-color: white;vertical-align:top;"|Send vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives vital signs from the PHR
|}

==Invocations==
===PHR: request message===
The send vital sings request message uses the HTTP POST method on the target XIS's base.

====Trigger Events====
This message is invoked when the PHR needs to send one or more vital signs observations to the XIS.

====Message Semantics====
Because sending vital signs will most likely consist of multiple Observations, a {{fhir|batch}} operation is used. This allows for creating a set of resources in a single interaction and makes it possible to [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|include referenced secondary resources]] if needed.

A {{fhir|batch}} interaction is performed by an HTTP POST command as shown:

<pre>POST [base]</pre>

The body of the post submission is a Bundle with {{fhir|Bundle.type}}={{term|batch}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry. (Note: {{fhir|.request}} is optional, but SHALL be present, even for the resources which aren't Observations. See [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]] for more information.)

{{NoteBox|Sending systems are expected to use an internal reference to the Patient resource included in the request Bundle if they cannot refer to the subject in any other way (see [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]]). This contradicts the FHIR specification, which states that internal references cannot be used for {{fhir|batch}} operations. This is a known issue which will be addressed in the future versions of this information standard. See [https://bits.nictiz.nl/browse/MM-1620 MM-1620] for more information.}}

'''Identification:'''

Sending systems are strongly encouraged to assign a stable identifier to the {{fhir|.identifier}} element when sending vital signs, this helps receiving systems with detecting duplicates and re-identification of Observation resources. For more information on dealing with identifiers, see the [[MedMij:V2020.01/FHIR_IG#When_is_.identifier_expected.3F|general MedMij FHIR IG]].

'''Links:'''

* [http://hl7.org/fhir/STU3/http.html#transaction batch]
* [http://hl7.org/fhir/STU3/http.html#create create]

The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

====Trigger Events====
The XIS completed processing of the send vital signs request message.

====Message Semantics====
The XIS SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Read more:
[http://hl7.org/fhir/STU3/http.html#create create]
[http://hl7.org/fhir/STU3/http.html#transaction batch]

====Expected Actions====
The PHR processes the results according to application-defined rules.

====Handling Errors====
The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Handling_errors Handling Errors section] in the MedMij FHIR IG for more information.

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:Vissue-MM-3549/FHIR VitalSigns

2022-09-15T11:13:36Z

Eduard de Rijcke: MM-3549 Added a known issue about the Batch Operation at Vital Signs

{{IssuePaginaWaarschuwing|MM-3549|MedMij:V2020.01/FHIR_VitalSigns}}
__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Self-measurements_Icoon.png|link=|87px |links||Self-Measurements]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.

Use cases:
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve vital signs transaction is used by the PHR to retrieve vital signs from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Vital Signs(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request vital signs from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves vital signs to the PHR
|}

==Invocations==
===PHR: request message===
The request message represents an HTTP GET parameterized query from the PHR to the XIS.

====Trigger Events====
When the patient(PHR) wants to obtain vital signs, it issues a retrieve vital signs request message.

====Message Semantics====
'''Search'''

The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/Observation{/$lastn}{?[parameters]}
</pre>

'''Search Parameters'''

The PHR may supply, and the XIS shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification search parameters of [http://hl7.org/fhir/STU3/observation.html#search Observation].

{| class="wikitable"
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
| token
| The classification of the type of observation.

Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
|
Retrieve all Observation resources that are considered a vital sign observation:
<pre>GET [base]/Observation?category=vital-signs</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
| token
| The code of the observation type.

The different types of measurements are specified using the following LOINC codes:
* Respiration: 9279-1
* BloodPressure: 85354-9
* BodyWeight: 29463-7
* BodyHeight: 8302-2
* BodyTemperature: 8310-5
* Oxygenation, saturation, SpO2: 59408-5
* HeartRate: 8867-4
* PulseRate: 8889-8
* BloodGlucose
** fasting: 14770-2
** general: 14743-9
** post-meal: 14760-3
|
Retrieve all Observation resources that are a blood pressure observation:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
Retrieve the most recent body height and the most recent body weight observation:
<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|
Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
|}

=====Expected Actions=====
The XIS shall process the query to find and return the vital signs matching the provided query parameters.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of matching vital signs Observation.

====Trigger Events====
The XIS completed processing of the retrieve vital signs request message.

====Message Semantics====
The body of the response message shall be a Bundle of type "''searchset''" containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type "''searchset''" shall be returned without any Observation as entries.

In the table below, the vital sign zibs and their respective profiles are listed. Zibs that MUST be supported are marked with (M). Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}

<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}

====Expected Actions====
The PHR processes the results according to application-defined rules.

===The <code>lastn</code> operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The [http://hl7.org/fhir/STU3/observation-operations.html#lastn FHIR STU3] specification is vague regarding the sorting mechanism of lastn. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using lastn, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

=Use case: Send Vital Signs=

==Introduction==
The send vital signs transaction is used by the PHR to send vital signs to the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Vital Signs(PUSH)
|style="background-color: white;vertical-align:top;"|Send vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends vital signs to the XIS
|-
|style="background-color: white;vertical-align:top;"|Send vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives vital signs from the PHR
|}

==Invocations==
===PHR: request message===
The send vital sings request message uses the HTTP POST method on the target XIS's base.

====Trigger Events====
This message is invoked when the PHR needs to send one or more vital signs observations to the XIS.

====Message Semantics====
Because sending vital signs will most likely consist of multiple Observations, a {{fhir|batch}} operation is used. This allows for creating a set of resources in a single interaction and makes it possible to [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|include referenced secondary resources]] if needed.

A {{fhir|batch}} interaction is performed by an HTTP POST command as shown:

<pre>POST [base]</pre>

The body of the post submission is a Bundle with {{fhir|Bundle.type}}={{term|batch}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry. (Note: {{fhir|.request}} is optional, but SHALL be present, even for the resources which aren't Observations. See [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]] for more information.)

<span id="BatchOperation"></span>{{NoteBox|The current post submission is using a post Batch operation. In this operation it isn’t allowed to use internal references to the Patient resource that’s included with the multiple vital signs resources. But it’s required to record the subject of the vital sign result. This is a known issue and will be addressed in the further development of Vital Signs that the type need to be changed to Transaction. See [https://bits.nictiz.nl/browse/MM-1620 MM-1620] for more information.}}

'''Identification:'''

Sending systems are strongly encouraged to assign a stable identifier to the {{fhir|.identifier}} element when sending vital signs, this helps receiving systems with detecting duplicates and re-identification of Observation resources. For more information on dealing with identifiers, see the [[MedMij:Vprepub-2020.01/FHIR_IG#When_is_.identifier_expected.3F|general MedMij FHIR IG]].

'''Links:'''

* [http://hl7.org/fhir/STU3/http.html#transaction batch]
* [http://hl7.org/fhir/STU3/http.html#create create]

The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

====Trigger Events====
The XIS completed processing of the send vital signs request message.

====Message Semantics====
The XIS SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Read more:
[http://hl7.org/fhir/STU3/http.html#create create]
[http://hl7.org/fhir/STU3/http.html#transaction batch]

====Expected Actions====
The PHR processes the results according to application-defined rules.

====Handling Errors====
The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Handling_errors Handling Errors section] in the MedMij FHIR IG for more information.

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:Vissue-MM-3549/FHIR VitalSigns

2022-09-15T09:37:07Z

Eduard de Rijcke: Clone of V2020.01 production page for issue MM-3549

{{IssuePaginaWaarschuwing|MM-3549|MedMij:V2020.01/FHIR_VitalSigns}}
__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Self-measurements_Icoon.png|link=|87px |links||Self-Measurements]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.

Use cases:
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve vital signs transaction is used by the PHR to retrieve vital signs from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Vital Signs(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request vital signs from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves vital signs to the PHR
|}

==Invocations==
===PHR: request message===
The request message represents an HTTP GET parameterized query from the PHR to the XIS.

====Trigger Events====
When the patient(PHR) wants to obtain vital signs, it issues a retrieve vital signs request message.

====Message Semantics====
'''Search'''

The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/Observation{/$lastn}{?[parameters]}
</pre>

'''Search Parameters'''

The PHR may supply, and the XIS shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification search parameters of [http://hl7.org/fhir/STU3/observation.html#search Observation].

{| class="wikitable"
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
| token
| The classification of the type of observation.

Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
|
Retrieve all Observation resources that are considered a vital sign observation:
<pre>GET [base]/Observation?category=vital-signs</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
| token
| The code of the observation type.

The different types of measurements are specified using the following LOINC codes:
* Respiration: 9279-1
* BloodPressure: 85354-9
* BodyWeight: 29463-7
* BodyHeight: 8302-2
* BodyTemperature: 8310-5
* Oxygenation, saturation, SpO2: 59408-5
* HeartRate: 8867-4
* PulseRate: 8889-8
* BloodGlucose
** fasting: 14770-2
** general: 14743-9
** post-meal: 14760-3
|
Retrieve all Observation resources that are a blood pressure observation:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
Retrieve the most recent body height and the most recent body weight observation:
<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|
Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
|}

=====Expected Actions=====
The XIS shall process the query to find and return the vital signs matching the provided query parameters.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of matching vital signs Observation.

====Trigger Events====
The XIS completed processing of the retrieve vital signs request message.

====Message Semantics====
The body of the response message shall be a Bundle of type "''searchset''" containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type "''searchset''" shall be returned without any Observation as entries.

In the table below, the vital sign zibs and their respective profiles are listed. Zibs that MUST be supported are marked with (M). Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}

<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}

====Expected Actions====
The PHR processes the results according to application-defined rules.

===The <code>lastn</code> operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The [http://hl7.org/fhir/STU3/observation-operations.html#lastn FHIR STU3] specification is vague regarding the sorting mechanism of lastn. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using lastn, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

=Use case: Send Vital Signs=

==Introduction==
The send vital signs transaction is used by the PHR to send vital signs to the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Vital Signs(PUSH)
|style="background-color: white;vertical-align:top;"|Send vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends vital signs to the XIS
|-
|style="background-color: white;vertical-align:top;"|Send vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives vital signs from the PHR
|}

==Invocations==
===PHR: request message===
The send vital sings request message uses the HTTP POST method on the target XIS's base.

====Trigger Events====
This message is invoked when the PHR needs to send one or more vital signs observations to the XIS.

====Message Semantics====
Because sending vital signs will most likely consist of multiple Observations, a {{fhir|batch}} operation is used. This allows for creating a set of resources in a single interaction and makes it possible to [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|include referenced secondary resources]] if needed.

A {{fhir|batch}} interaction is performed by an HTTP POST command as shown:

<pre>POST [base]</pre>

The body of the post submission is a Bundle with {{fhir|Bundle.type}}={{term|batch}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry. (Note: {{fhir|.request}} is optional, but SHALL be present, even for the resources which aren't Observations. See [[MedMij:Vprepub-2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]] for more information.)

'''Identification:'''

Sending systems are strongly encouraged to assign a stable identifier to the {{fhir|.identifier}} element when sending vital signs, this helps receiving systems with detecting duplicates and re-identification of Observation resources. For more information on dealing with identifiers, see the [[MedMij:Vprepub-2020.01/FHIR_IG#When_is_.identifier_expected.3F|general MedMij FHIR IG]].

'''Links:'''

* [http://hl7.org/fhir/STU3/http.html#transaction batch]
* [http://hl7.org/fhir/STU3/http.html#create create]

The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk (M)||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

====Trigger Events====
The XIS completed processing of the send vital signs request message.

====Message Semantics====
The XIS SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Read more:
[http://hl7.org/fhir/STU3/http.html#create create]
[http://hl7.org/fhir/STU3/http.html#transaction batch]

====Expected Actions====
The PHR processes the results according to application-defined rules.

====Handling Errors====
The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Handling_errors Handling Errors section] in the MedMij FHIR IG for more information.

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:Vissue-MM-test/FHIR IG

2022-07-25T07:51:25Z

Eduard de Rijcke: Clone of V2020.01 production page for issue MM-test

{{IssuePaginaWaarschuwing|MM-test|MedMij:V2020.01/FHIR_IG}}
__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>
__TOC__

{{large|Quick links}}
----
{|
! [[Bestand:BGZ_icoon.png |link=MedMij:Vprepub-2020.01/FHIR_BGZ_2017 |100px|Patient Summary (BgZ)]]
!   
! [[Bestand:Medication_Icoon.png |link=MedMij:Vprepub-2020.01/FHIR_MedicationProcess|100px |Medication Process]]
!   
! [[Bestand:AllergyIntolerance.png |link=MedMij:Vprepub-2020.01/FHIR_AllergyIntolerance|106px |Allergy Intolerance]]
!   
! [[Bestand:Self-measurements_Icoon.png |link=MedMij:Vprepub-2020.01/FHIR_VitalSigns|105px |Self-Measurements]]
!   
! [[Bestand:LabResults@2x.png |link=MedMij:Vprepub-2020.01/FHIR_LaboratoryResults |100px|Laboratory Results]]
!   
! [[Bestand:BgLZ-icon-text.png|link=MedMij:Vprepub-2020.01/FHIR_BGLZ|105px| BgLZ]]
|}

{|
! [[Bestand:PDF-A icoon.png|link=MedMij:Vprepub-2020.01/FHIR_PDFA |100px |PDF/A - Health Documents]]
!   
! [[Bestand:EAfspraak_-_text.png |link=MedMij:Vprepub-2020.01/FHIR_eAfspraak |98px |eAfspraak - Appointments]]
!   
! [[Bestand:Huisartsgegevens-met-tekst.png|link=MedMij:Vprepub-2020.01/FHIR_GP_Data |105px |Huisartsgegevens - GP Data]]
!   
! [[Bestand:MedMij-GGZ-63.png|link=MedMij:Vprepub-2020.01/FHIR_GGZ |105px |GGZ]]
!   
! [[Bestand:Beelden_met_EN_tekst.png|link=MedMij:Vprepub-2020.01/FHIR_Images |105px |Images]]
!   
! [[Bestand:Vragenlijsten_-_EN_dikkere_rand.png|link=MedMij:Vprepub-2020.01/FHIR_Questionnaire_and_Questionnaire_Response_(Vragenlijsten)|108px| Questionnaire]]
|}

=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 [[MedMij:Vprepub-2020.01/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 (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 [https://www.medmij.nl/wp-content/uploads/2017/06/Factsheet-MedMij-FHIR.pdf MedMij website]. MedMij delivers a FHIR representation ([https://hl7.org/fhir/STU3/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 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 [https://hl7.org/fhir/STU3 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 [https://www.medmij.nl/afsprakenstelsel/ '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.

=Functional design=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to 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 [[MedMij:Vprepub-2020.01/Ontwerpen|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 implementation 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.

{|
! [[Bestand:BGZ_icoon.png |link=MedMij:Vprepub-2020.01/FHIR_BGZ_2017 |100px|Patient Summary (BgZ)]]
!   
! [[Bestand:Medication_Icoon.png |link=MedMij:Vprepub-2020.01/FHIR_MedicationProcess|100px |Medication Process]]
!   
! [[Bestand:AllergyIntolerance.png |link=MedMij:Vprepub-2020.01/FHIR_AllergyIntolerance|106px |Allergy Intolerance]]
!   
! [[Bestand:Self-measurements_Icoon.png |link=MedMij:Vprepub-2020.01/FHIR_VitalSigns|105px |Self-Measurements]]
!   
! [[Bestand:LabResults@2x.png |link=MedMij:Vprepub-2020.01/FHIR_LaboratoryResults |100px|Laboratory Results]]
!   
! [[Bestand:BgLZ-icon-text.png|link=MedMij:Vprepub-2020.01/FHIR_BGLZ|105px| BgLZ]]
|}

{|
! [[Bestand:PDF-A icoon.png|link=MedMij:Vprepub-2020.01/FHIR_PDFA |100px |PDF/A - Health Documents]]
!   
! [[Bestand:EAfspraak_-_text.png |link=MedMij:Vprepub-2020.01/FHIR_eAfspraak |98px |eAfspraak - Appointments]]
!   
! [[Bestand:Huisartsgegevens-met-tekst.png|link=MedMij:Vprepub-2020.01/FHIR_GP_Data |105px |Huisartsgegevens - GP Data]]
!   
! [[Bestand:MedMij-GGZ-63.png|link=MedMij:Vprepub-2020.01/FHIR_GGZ |105px |GGZ]]
!   
! [[Bestand:Beelden_met_EN_tekst.png|link=MedMij:Vprepub-2020.01/FHIR_Images |105px |Images]]
!   
! [[Bestand:Vragenlijsten_-_EN_dikkere_rand.png|link=MedMij:Vprepub-2020.01/FHIR_Questionnaire_and_Questionnaire_Response_(Vragenlijsten)|108px| Questionnaire]]
|}
{{NoteBox|1= When considering an implementation of (parts of) BgLZ, please contact [mailto:standaarden@medmij.nl standaarden@medmij.nl].}}
{{#lst:FHIR:V1.0_FHIR_IG_STU3|OverarchingPrinciples}}
{{#lst:FHIR:V1.0_FHIR_IG_STU3|FHIRPackages}}
=Relevant links=
'''HL7 FHIR specification'''
* [https://hl7.org/fhir/STU3/index.html HL7 FHIR STU3]
* [https://confluence.hl7.org/ HL7 Confluence]

'''Repository of MedMij FHIR artefacts'''
* [https://simplifier.net/NictizSTU3-Zib2017 Simplifier.net]
** [https://github.com/Nictiz/Nictiz-STU3-Zib2017 GitHub] (similar to Simplifier.net)

=Contact=

'''MedMij'''

W: https://www.medmij.nl

E: standaarden@medmij.nl

'''Nictiz'''

W: https://www.nictiz.nl

T: [tel:+31703173450 +31-70 317 3450]

'''Feedback on content in open consultation'''
* [https://www.medmij.nl/consultatiedocumenten/ Documentation]
* [https://bits.nictiz.nl/secure/BrowseProjects.jspa#all BITS for issues]

'''FHIR Questions and Discussions'''

* [https://chat.fhir.org chat.fhir.org]

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/Ontwerpen#Release_Notes|functional design page]].

=Releases=
{| class="wikitable"
! Version !! Date !! Notes
|-
| [[MedMij:Vprepub-2020.01/FHIR_IG|2020.01]] || 2020-08-11 || Summer release containing fixes for MedMij information standards
|-
| [[MedMij:V2019.01_FHIR_IG|2019.01]] || 2019-03-11 || Spring release containing fixes for all information standards
|-
| [[MedMij:V2018.06_FHIR_IG|2018.06]] || 2018-10-29 || Added GGZ
|-
| [[MedMij:V2018.05_FHIR_IG|2018.05]] || 2018-09-24 || Added GGZ for open consultation
|-
| [[MedMij:V2018.04_FHIR_IG|2018.04]] || 2018-08-29 || eAfspraak fase 2
|-
| [[MedMij:V2018.03_FHIR_IG|2018.03]] || 2018-05-07 || Published BgZ 2017 and GP Data
|-
| [[MedMij:V2018.02_FHIR_IG|2018.02]] || 2018-03-29 || Added BgZ 2017
|-
| [[MedMij:V2018.01_FHIR_IG|2018.01]] || 2018-02-21 || Added GP patient data
|-
| [[MedMij:V2017.04_FHIR_IG|2017.04]] || 2017-12-18 || Added Appointments, Medication, Laboratory results, AllergyIntolerance, Self-measurements
|-
| [[MedMij:V2017.03_FHIR_IG|2017.03]] || 2017-11-07 || Added PDF/A
|-
| [[MedMij:V2017.02_Ontwerpen|2017.02]] || 2017-10-11 || Unchanged. No wiki pages created for FHIR
|-
| [[MedMij:V2017.01_FHIR_IG|2017.01]] || 2017-10-02 || Initial version containing Patient Administration Resources, Patient Summary (BgZ),
|}

MedMij:V2019.01 OntwerpPDFA

2022-07-05T08:07:47Z

Eduard de Rijcke: Relase notes van Patchrelease Juni 2022 toegevoegd

{{MedMij:Vprepub-2019.01_IssueBoxTD_NL}}
__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Functioneel Ontwerp PDF/A {{VersieInfo|PDFA|release=V2019.01}}}}
{{MedMij:Vprepub-2019.01_Issuebox}}

[[Bestand:PDF-A icoon.png |link=|links |87px|PDF/A]]
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2019.01_FHIR_PDFA|Technisch]]
desc none
</imagemap>

=Inleiding=

==Algemeen==
Voor de uitwisseling van documentgebaseerde, ongestructureerde medische gegevens of gezondheidsinformatie gebruikt MedMij de PDF/A-standaard. PDF/A is een ISO-gestandaardiseerde variant van het gewone PDF-formaat. PDF/A is een van de door Forum Standaardisatie aanbevolen standaarden. Meer informatie over PDF/A vindt u hier: https://www.forumstandaardisatie.nl/standaard/pdf-nen-iso.

Het formaat is specifiek ontwikkeld voor correcte weergave van de inhoud op langere termijn. Het beoogt statische paginainhoud weer te geven en is geschikt voor het opslaan van digitale documenten waar inhoud en context niet meer van mag veranderen. Zo kunnen patiënt en zorgverlener alvast allerlei ongestructureerde gezondheidsinformatie uitwisselen zonder te hoeven wachten tot dat deze gestructureerd opgeleverd kunnen worden.

Bij implemeneteren van PDF/A dient er uit te worden gegaan van een minimale compliance aan de PDF/A-standaard. Dat wil zeggen PDF/A-1 en daarbinnen is ook PDF/A-b toegestaan. Zie voor meer informatie de wiki pagina hierover: https://en.wikipedia.org/wiki/PDF/A#Conformance_levels_and_versions

De standaard PDF/A kent de use cases Raadplegen en Sturen. Algemene informatie betreffende use cases kan gevonden worden op de pagina [[MedMij:Vprepub-2019.01_Ontwerpen|Ontwerpen MedMij]].

==Doelgroep==
De doelgroep voor deze pagina wijkt niet af van [[MedMij:Vprepub-2019.01_Ontwerpen#Doelgroep| de algemene doelgroep]] van de MedMij functionele ontwerpen.

==Kaders en uitgangspunten==
===Richtlijn===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub-2019.01_Ontwerpen#Richtlijn| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Infrastructuur===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub-2019.01_Ontwerpen#Infrastructuur| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Geografische reikwijdte===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub-2019.01_Ontwerpen#Geografische_reikwijdte| de algemene inleiding]] van de MedMij functionele ontwerpen.

==Kwalificatie==
===Introductie===
{{#lst:MedMij:Vprepub-2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
Deze sectie vervolgt met de volgende use cases:
* [[MedMij:Vprepub-2019.01_OntwerpPDFA#Use_case:_Raadplegen_gezondheidsinformatie_in_PDF.2FA_door_pati.C3.ABnt| Raadplegen gezondheidsinformatie in PDF/A door patiënt]]
* [[MedMij:Vprepub-2019.01_OntwerpPDFA#Use_case:_Sturen_gezondheidsinformatie_in_PDF.2FA_door_pati.C3.ABnt| Sturen gezondheidsinformatie in PDF/A door patiënt]]
==Use case: Raadplegen gezondheidsinformatie in PDF/A door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in medische informatie die over henzelf gaan. Het is niet mogelijk om alle medische informatie direct gestructureerd te kunnen ontsluiten voor de patiënt. Dit ontwerp beschrijft het uitwisselen van ongestructureerde digitale informatie in een PDF/A format.

===Domein===
Documenten en ongestructureerde medische informatie in een PDF/A formaat in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch beschikbaar maken van medische gegevens in PDF/A formaat vanuit een zorgaanbiederssysteem (XIS) naar een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO).
Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.
De beschrijving is infrastructuur-onafhankelijk.

===Informatie===

====Raadplegen medische gegevens in PDF/A====
Het raadplegen van een medische informatie gaat van een specifieke patiënt naar een specifieke organisatie in de zorg (bijvoorbeeld een zorgaanbieder).

Informatie elementen in de vraag om PDF/A documenten staan hieronder. Dit betreft de filtermogelijkheden (query paramaters) in de vraag om documentgegevens. Deze filtermogelijkheden zijn afgeleid van het [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) IHE MHD profiel].

*patient
*periode (startdatum - einddatum)
*auteur
*type document
*categorie
*status
*setting (aanvullende details over waar de content is gemaakt / specialisme)
*medische handelingen (belangrijkste uitgevoerde medische handelingen)

====Beschikbaarstellen medische gegevens in PDF/A ====
De informatie-elementen voor het beschikbaarstellen van een PDF/A worden beschreven in het [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) IHE MHD profiel]. Dit betreft de inhoud van de transactie waarbij het om de volgende [http://hl7.org/fhir/STU3 HL7 FHIR STU3] informatie modellen en [https://zibs.nl/wiki/ZIB_Hoofdpagina Zorginformatiebouwstenen] gaat:

*HL7 FHIR
** [http://hl7.org/fhir/STU3/bundle.html Bundle]
** [http://hl7.org/fhir/STU3/documentmanifest.html DocumentManifest]
** [http://hl7.org/fhir/STU3/documentreference.html DocumentReference]
** [http://hl7.org/fhir/STU3/binary.html Binary]

*Zorginformatiebouwstenen
** [https://zibs.nl/wiki/Patient-v3.1(2017NL) Patient]
** [https://zibs.nl/wiki/Zorgverlener-v3.2(2017NL) Zorgverlener]

=== Bedrijfsrollen ===
Deze use case kent twee bedrijfsrollen.

{| class="wikitable" "cellpadding="10" width="50%"
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:top;"|Wil medische gegevens in PDF/A formaat raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt medische gegevens in PDF/A formaat beschikbaar
|}
<font size = "1">'''Bedrijfsrollen afspraak inzien'''</font>

Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren.

[[Bestand:Activity Diagram - PDFA raadplegen.png|Activiteitendiagram PFD/A raadplegen]]

<font size = "1">'''Activiteitendiagram PDF/A raadplegen'''</font>

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Roos_Dalstra_MedMij.pdf hier]. Hieronder een voor Roos relevante situatie waarbij het raadplegen van een PDF/A document rol speelt.

<blockquote> Na het ontslag komt de informatie over de opnameperiode vanuit het ziekenhuis beschikbaar in de PGO, zodat zij een goed beeld heeft van haar opname en haar medicatie. Dit kan zij ook delen met haar naasten.
</blockquote>

Roos zou in haar PGO bijvoorbeeld de ontslagbrief van haar opname kunnen opvragen.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de PDF/A beschikbaar aan het systeem van een patiënt (PGO).
Deze paragraaf vervolgt met een beschrijving van precondities, proces stappen, en post condities.
=====Preconditie=====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van medische gegevens in PDF/A tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil zijn medische gegevens inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om zijn medische gegevens op te halen, maar het is ook mogelijk dat een PGO geconfigureerd is om dit 'automatisch' te doen. Dit maakt voor de beschrijving van deze use case geen verschil.

=====Proces stappen=====
*Het systeem van de patiënt (PGO) vraagt om beschikbare medische gegevens bij een XIS aan de hand van een zoekopdracht.
*Het systeem van de zorgaanbieder (XIS) levert een lijst met metadata over de gevonden PDF/A documenten op voor de patiënt.
*De Patiënt gebruikt de persoonlijke gezondheidsomgeving om de gewenste PDF/A te raadplegen of te downloaden.
*Het systeem van de zorgaanbieder (XIS) levert de PDF/A op voor de patiënt.

=====Post conditie=====
De patiënt heeft zijn medische gegevens geraadpleegd via de persoonlijke gezondheidsomgeving.

=== Systemen & Systeemrollen ===
Zowel zorgaanbieder als patiënt maken gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om een document of documenten PDF/A van zorgaanbieder naar de patiënt.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Systeemrolcode
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;" rowspan="2"| PGO
| style="background-color: white;"| PDFAMetadataLijstRaadplegend
| style="background-color: white;"| MM-{{VersieInfo|PDFA1|release=V2019.01}}-PLR-FHIR
| style="background-color: white;"| Raadplegen PDF/A metadata lijst bij zorgaanbieder
|-
| style="background-color: white;"| PDFARaadplegend
| style="background-color: white;"| MM-{{VersieInfo|PDFA1|release=V2019.01}}-PDR-FHIR
| style="background-color: white;"| Raadplegen PDF/A document bij zorgaanbieder
|-
| style="background-color: white;" rowspan="2"| XIS
| style="background-color: white;"| PDFAMetadataLijstBeschikbaarstellend
| style="background-color: white;"| MM-{{VersieInfo|PDFA1|release=V2019.01}}-PLB-FHIR
| style="background-color: white;"| Beschikbaarstellen PDF/A metadata lijst bij patient
|-
| style="background-color: white;"| PDFABeschikbaarstellend
| style="background-color: white;"| MM-{{VersieInfo|PDFA1|release=V2019.01}}-PDB-FHIR
| style="background-color: white;"| Beschikbaarstellen PDF/A document bij patient
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component Diagram - PDFA raadplegen (Totaal).png|Componenten diagram PDF/A raadplegen]]

<font size = "1">'''Componenten diagram PDFA raadplegen'''</font>

De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.

=== Transacties, transactiegroepen en systeemrollen===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transactiegroep'''
! style="text-align:left;"| '''Transactie'''
! style="text-align:left;"| '''Systeemrolcode'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|PDFA metadata lijst (PULL)
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/decor/services/RetrieveTransaction?id=2.16.840.1.113883.2.4.3.11.60.59.4.11&effectiveDate=2019-06-27T12:52:37&language=nl-NL&ui=nl-NL&format=html&hidecolumns=45ghijklmnop Raadplegen PDF/A metadata lijst]
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|PDFA1|release=V2019.01}}-PLR-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="4"|[[MedMij:Vprepub-2019.01_FHIR_PDFA|PDF/A in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/decor/services/RetrieveTransaction?id=2.16.840.1.113883.2.4.3.11.60.59.4.12&effectiveDate=2019-06-27T12:52:37&language=nl-NL&ui=nl-NL&format=html&hidecolumns=45ghijklmnop Beschikbaarstellen PDF/A metadata lijst]
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|PDFA1|release=V2019.01}}-PLB-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|PDFA (PULL)
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/decor/services/RetrieveTransaction?id=2.16.840.1.113883.2.4.3.11.60.59.4.17&effectiveDate=2019-06-27T14:45:49&language=nl-NL&ui=nl-NL&format=html&hidecolumns=45ghijklmnop Raadplegen PDF/A]
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|PDFA1|release=V2019.01}}-PDR-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|-
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/decor/services/RetrieveTransaction?id=2.16.840.1.113883.2.4.3.11.60.59.4.18&effectiveDate=2019-06-27T14:45:49&language=nl-NL&ui=nl-NL&format=html&hidecolumns=45ghijklmnop Beschikbaarstellen PDF/A]
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|PDFA1|release=V2019.01}}-PDB-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:Use Case Diagram - PDFA raadplegen.png|Use case diagram PDF/A raadplegen]]

<font size = "1">'''Use case diagram PDF/A Raadplegen</font>

==Use case: Sturen gezondheidsinformatie in PDF/A door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door gezondheidsinformatie te delen met zorgverleners. Het is niet mogelijk om alle informatie direct gestructureerd te kunnen sturen. Dit ontwerp beschrijft het uitwisselen van ongestructureerde digitale informatie in PDF/A formaat.

===Domein===
Documenten en ongestructureerde gezondheidsinformatie in een PDF/A formaat in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch beschikbaar maken van een document of documenten in PDF/A formaat vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar zorgaanbiederssysteem (XIS).
Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.
De beschrijving is infrastructuur-onafhankelijk.

===Informatie===
De informatie-elementen die van toepassing zijn voor de standaard PDF/A Sturen, zijn gedefinieerd op het platform [https://www.nictiz.nl/standaardisatie/art-decor/ ART-DECOR] in het project [https://decor.nictiz.nl/art-decor/decor-project--docs- Documentuitwisseling].

====Sturen van gezondheidsinformatie in PDF/A====
Het sturen van een gezondheidsinformatie gaat van een specifieke patiënt naar een specifieke organisatie in de zorg (bijvoorbeeld een zorgaanbieder).

Om uitwisseling van PDF/A-bestanden tot stand te brengen, neemt MedMij zoveel mogelijk over van het [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) MHD-profiel] (Mobile access to Health Documents) van [https://wiki.ihe.net/index.php/Main_Page IHE] (Integrating the Healthcare Enterprise) dat een RESTful / HTTP-interface definieert naar een XDS-omgeving met behulp van HL7 FHIR STU3-bronnen. De informatie-elementen voor het beschikbaarstellen van een PDF/A worden beschreven in het [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) IHE MHD-profiel].

De inhoud van de transactie gaat om de volgende [http://hl7.org/fhir/STU3 HL7 FHIR STU3] informatie modellen en [https://zibs.nl/wiki/ZIB_Hoofdpagina Zorginformatiebouwstenen]:
*HL7 FHIR
** [http://hl7.org/fhir/STU3/bundle.html Bundle]
** [http://hl7.org/fhir/STU3/documentmanifest.html DocumentManifest]
** [http://hl7.org/fhir/STU3/documentreference.html DocumentReference]
** [http://hl7.org/fhir/STU3/binary.html Binary]

*Zorginformatiebouwstenen
** [https://zibs.nl/wiki/Patient-v3.1(2017NL) Patiënt]
** [https://zibs.nl/wiki/Zorgverlener-v3.2(2017NL) Zorgverlener]

=== Bedrijfsrollen ===
Deze use case onderscheidt twee bedrijfsrollen, namelijk de ''Patiënt'' en de ''Zorgaanbieder'' zoals te zien in onderstaande tabel.

{| class="wikitable" "cellpadding="10" width="50%"
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:top;"|Wil gezondheidsinformatie in PDF/A formaat sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt gezondheidsinformatie in PDF/A formaat
|}

Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren.

[[Bestand:Activity Diagram - Sturen sturen2.png|Activiteitendiagram PFD/A sturen]]

<font size = "1">'''Activiteitendiagram PDF/A sturen'''</font>

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Een voorbeeldsituatie die de meerwaarde schetst van het sturen van PDF/A vanuit het PGO is de 'patient journey' van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Roos_Dalstra_MedMij.pdf Roos Dalstra]. Hieronder een voor Roos relevante situatie waarbij het sturen van een PDF/A document rol kan spelen.

<blockquote>Roos is ’s nachts vanwege benauwdheid opgenomen op de afdeling cardiologie van het ziekenhuis. De internist in dienst die nacht wil graag weten welke medicatie Roos gebruikt. Aangezien Roos alles heeft bijgehouden in haar persoonlijke gezondheidsomgeving kan zij het ziekenhuis haar medicatiegegevens laten zien door deze te sturen naar het ziekenhuisinformatiesysteem.</blockquote>

Wanneer het XIS niet in staat is om het medicatieoverzicht gestructureerd te ontvangen, zou het PGO het medicatieoverzicht in een PDF/A kunnen sturen. Zo heeft de arts wel gelijk de beschikking over het medicatieoverzicht.

===='Patient journey' - Jelmer Postma ====
Een tweede voorbeeld waarbij de meerwaarde van raadplegen en sturen van PDF/A vanuit het PGO is de 'patient journey' van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Jelmer_Postma_MedMij.pdf Jelmer Postma]. Hieronder een voor Jelmer relevante situatie waarbij het sturen van een PDF/A document rol kan spelen.

<blockquote> De opname in de GGZ-instelling is van korte duur. Vanaf nu wordt Jelmer ambulant behandeld door een reguliere GGZ-instelling.</blockquote>

Vanuit zijn zorgtraject heeft Jelmer verschillende plannen en verslagen in zijn PGO opgeslagen. Onder andere het initiële plan van de bedrijfsarts en het behandelplan van de psychiater kan Jelmer raadplegen in zijn PGO.
De verslagen kan Jelmer als PDF/A sturen aan (nieuwe) begeleiders zodat alle betrokkenen de informatie rond Jelmer zijn ziekte hebben, waarmee zijn herstel zo spoedig mogelijk kan verlopen.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stuurt de PDF/A naar het systeem van een zorgverlener (XIS).
Deze paragraaf vervolgt met een beschrijving van precondities, proces stappen, en post condities.
=====Preconditie=====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van gezondheidsinformatie in PDF/A tussen eigen persoonlijke gezondheidsomgeving en het betreffende XIS.

De patiënt wil zijn gezondheidsinformatie sturen en de zorgaanbieder ontvangt deze.
:Een patiënt kan steeds zelf het initiatief nemen om zijn gezondheidsinformatie te sturen.

=====Proces stappen=====
*Het systeem van de patiënt (PGO) stuurt gezondheidsinformatie in PDF/A formaat naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt een PDF/A van de patiënt.

=====Post conditie=====
De patiënt heeft zijn gezondheidsinformatie in PDF/A formaat gestuurd via de persoonlijke gezondheidsomgeving.

=== Systemen & Systeemrollen ===
Zowel patiënt als zorgaanbieder maken ieder gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om een document of documenten PDF/A van patiënt naar zorgaanbieder.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Systeemrolcode
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| DocumentcollectieSturend
| style="background-color: white;"| MM-{{VersieInfo|PDFA|release=V2019.01}}-DCS-FHIR
| style="background-color: white;"| Sturen PDF/A document naar zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| DocumentcollectieOntvangend
| style="background-color: white;"| MM-{{VersieInfo|PDFA|release=V2019.01}}-DCO-FHIR
| style="background-color: white;"| Ontvangen PDF/A document van de patiënt
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component Diagram - PDFA sturen (Totaal)2.png |Componenten diagram PDFA sturen]]

<font size = "1">'''Componenten diagram PDF/A Sturen'''</font>

=== Transacties en Transactiegroepen ===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transactiegroep'''
! style="text-align:left;"| '''Transactie'''
! style="text-align:left;"| '''Systeemrolcode'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|PDFA (PUSH)
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/decor/services/RetrieveTransaction?id=2.16.840.1.113883.2.4.3.11.60.59.4.23&effectiveDate=2019-06-30T23:34:28&language=nl-NL&ui=nl-NL&format=html&hidecolumns=45ghijklmnop Sturen PDF/A Document(en)]
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|PDFA|release=V2019.01}}-DCS-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub-2019.01_FHIR_PDFA|PDF/A in FHIR]]

|-
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/decor/services/RetrieveTransaction?id=2.16.840.1.113883.2.4.3.11.60.59.4.24&effectiveDate=2019-06-30T23:34:28&language=nl-NL&ui=nl-NL&format=html&hidecolumns=45ghijklmnop Ontvangen PDF/A Document(en)]
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|PDFA|release=V2019.01}}-DCO-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:Use Case Diagram - PDFA sturen2.png|Use case diagram PFD/A sturen]]

<font size = "1">'''Use case diagram PDF/A sturen</font>

=Functionaliteit=

== Raadplegen ==
PGO raadpleegt als eerste bij het XIS, de index met referenties naar documenten. PGO raadpleegt in zijn tweede stap de documenten via deze referenties onder dezelfde condities - met name autorisatie- als de raadpleging van de index. Het XIS is gehouden aan de controle van deze condities. De referenties in de index moeten dus leiden naar een locatie die onder controle staat van het betreffende XIS. Om deze controlemogelijkheid af te dwingen kan het nodig zijn dat het XIS de referentie naar het werkelijke document in opgehaalde indexgegevens vervangt door een alternatieve referentie die onder controle staat bij het XIS. Voor een PGO is een eventuele vervangen referentie transparant: het blijft een referentie die het systeem kan volgen onder dezelfde condities als het indexgegeven zelf.

De transactie "Raadplegen PDF/A" door de PGO volgt de (aangepaste) referentie naar het document. Het raadplegen via het XIS is om context en controle te houden.

== Sturen ==
Bij Sturen van PDF/A door een PGO worden de PDF/A documenten direct in het bericht als een (binair) bestand meegezonden. Er wordt dus niet gewerkt met referenties zoals bij Raadplegen PDF/A het geval is.

De XIS zal het bericht ontvangen en het PDF/A afleveren bij de Ontvanger (vaak de zorgverlener) die in het bericht is opgenomen. Hoe het afleveren aan de XIS kant van de PDF/A naar een zorgverlener plaatsvindt wordt niet door de informatiestandaard bepaald.

=Verantwoordelijkheid voor informatie=
Er zijn geen specifieke toevoegingen over verantwoordelijkheden voor informatie.

=Afschermen van gegevens=
Er zijn geen afspraken over het afschermen van gegevens.

=Infrastructuur=
Er zijn geen afspraken over een specifieke infrastructuur waarop de informatie wordt uitgewisseld.

=Referenties=

{| class="wikitable" "cellpadding="10" width="100%"
!style="text-align:left;"|Auteur(s)
!style="text-align:left;"|Titel
!style="text-align:left;"|Versie
!style="text-align:left;"|Datum
!style="text-align:left;"|Bron
!style="text-align:left;"|Organisatie
|-
| style="background-color: white;"| -
| style="background-color: white;"| Mobile access to Health Documents (MHD)
| style="background-color: white;"| -
| style="background-color: white;"| 10-05-2019 (wijzigingsdatum)
| style="background-color: white;"| [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) Mobile access to Health Documents (MHD)]
| style="background-color: white;"| [https://wiki.ihe.net/index.php/Main_Page Integrating the Healthcare Enterprise (IHE)]
|-
| style="background-color: white;"| -
| style="background-color: white;"| FHIR STU3 Resource Index
| style="background-color: white;"| FHIR STU3
| style="background-color: white;"| 19-04-2017
| style="background-color: white;"| [http://hl7.org/fhir/STU3/resourcelist.html Resource Index]
| style="background-color: white;"| [http://hl7.org/fhir/ Hl7]
|-
| style="background-color: white;"| -
| style="background-color: white;"| Zorginformatie bouwstenen
| style="background-color: white;"| zib Publicatie 2017(NL)
| style="background-color: white;"| 23-12-2018 (wijzigingsdatum)
| style="background-color: white;"| [https://zibs.nl/wiki/ZIB_Hoofdpagina Zorginformatie bouwstenen]
| style="background-color: white;"| [http://www.nictiz.nl Nictiz]
|}

=Release notes=

In onderstaande tabel staan de wijzigingen voor deze informatiestandaard. Zie de [[MedMij:Vprepub-2019.01_Ontwerpen#Release_Notes|Ontwerpen landingspagina]] voor wijzigingen die op alle informatiestandaarden van toepassing zijn.

{| class="wikitable" "cellpadding="10" style="background-color: white;"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving
|-
{{ReleaseNotes|package=2019.01 - Juni 2022|release=2.1.2|issues=1|MM-3099}}
{{ReleaseNotes|package=2019.01 - Maart 2022|release=2.1.0|issues=1|MM-2983}}
{{ReleaseNotes|package=2019.01 - Mei 2021|release=2.0.16|issues=1|MM-1721}}
{{ReleaseNotes|package=2019.01 - Februari 2021|release=2.0.13|issues=1|MM-1772}}
{{ReleaseNotes|package=2019.01 - November|release=2.0.11|issues=1|MM-1466}}
{{ReleaseNotes|package=2019.01 - Mei|release=2.0.10|issues=2|MM-1168|MM-1082}}
{{ReleaseNotes|package=2019.01 - Maart|release=2.0.3|issues=2|MM-975|MM-945}}
{{ReleaseNotes|package=2019.01 - Februari|release=2.0.2|issues=1|MM-870}}
|-
| style="background-color: white;"| 2019.01 - Oktober
| style="background-color: white;"| 2.0.1
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-571 MM-571]
| style="background-color: white;"| The references to some of the profiles on the wiki page weren't resolvable. This has been changed, so that they link to Simplifier.
|-
| style="background-color: white;"| 2019.01 - September
| style="background-color: white;"| 1.2.3
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-335 MM-335]
| style="background-color: white;"| Verwijzing naar het IHE MHD pdf document gaat nu naar de STU3 versie i.p.v. de laatste versie (o.b.v. R4)
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-49 MM-49]
| style="background-color: white;"| Beschikbaarstellen van referenties alleen via dezelfde geraadpleegde resourceserver met de benodigde autorisatie.
|}

MedMij:Vprepub-2019.01 OntwerpPDFA

2022-07-05T08:07:47Z

Eduard de Rijcke: Relase notes van Patchrelease Juni 2022 toegevoegd

MedMij:V2019.01 OntwerpHuisartsgegevens

2022-07-05T08:06:36Z

Eduard de Rijcke: Relase notes van Patchrelease Juni 2022 toegevoegd

{{IssuePaginaWaarschuwing|MM-3099|MedMij:V2019.01_OntwerpHuisartsgegevens}}
__NOINDEX__
{{IssueBox|Deze versie van de informatiestandaard is verlopen per 1 juli 2022. De bijbehorende MedMij-gegevensdienst is nog actief tot 6 september.
Gebruik de [[MedMij:Landingspagina_MedMij|actuele publicatie]] voor implementatie van deze informatiestandaard binnen MedMij.}}
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Functioneel Ontwerp Huisartsgegevens {{VersieInfo|Huisartsgegevens|release=V2019.01}}}}
{{MedMij:Vprepub-2019.01_Issuebox}}

[[Bestand:Huisartsgegevens.png|link=|links|Huisartsgegevens|85px]]
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2019.01_FHIR GP Data|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
De basis voor de inhoud van dit ontwerp is de "[[#richtlijn-huisarts-patient|Richtlijn online inzage in het H-EPD door patiënt]]". Op basis van deze richtlijn wordt de patiënt in staat gesteld gegevens van zijn huisartsdossier online op te vragen.

==Doelgroep==
De doelgroep voor deze pagina wijkt niet af van de algemene doelgroep van de MedMij functionele ontwerpen, die [[MedMij:Vprepub-2019.01_Ontwerpen#Doelgroep| hier]] gevonden kan worden.

==Kaders en uitgangspunten==
===Richtlijn===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub-2019.01_Ontwerpen#Richtlijn| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Infrastructuur===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub-2019.01_Ontwerpen#Infrastructuur| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Geografische reikwijdte===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub-2019.01_Ontwerpen#Geografische_reikwijdte| de algemene inleiding]] van de MedMij functionele ontwerpen.

==Kwalificatie==
===Introductie===
{{#lst:MedMij:Vprepub-2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case: Raadplegen Huisartsgegevens door patiënt==
===Doel en relevantie===
Online inzage door de patiënt in het elektronisch patiëntendossier bij de huisarts (H-EPD) heeft als doel om de zorg beter te maken. De patiënt krijgt door online inzage meer overzicht en is beter geïnformeerd. Hierdoor heeft de patiënt meer begrip van en regie over de eigen gezondheid en het stimuleert zelfzorg. Ook kan het de kwaliteit van het dossier helpen verhogen.

===Domein===
Huisartsgegevens in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van een huisartsgegevens vanuit een zorgaanbiederssysteem (XIS) naar een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO).
Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.
De beschrijving is infrastructuur-onafhankelijk.

===Informatie===
De gegevens zoals deze door de huisarts worden aangeboden voor online inzage aan de patiënt bestaan uit 10 secties (zie bijlage 1 van de richtlijn). Een aantal daarvan overlappen met de [[MedMij:Vprepub-2019.01 OntwerpBGZ_2017|Basisgegevensset Zorg]] (BgZ) en een aantal daarvan zijn uniek voor het huisartsdossier. De richtlijn baseert zich op het [[#his-referentiemodel-2016|HIS referentiemodel]]. Die richtlijn heeft geen relatie met de [http://www.zibs.nl Zorginformatiebouwstenen] (zibs). Voor een aantal secties is deze relatie wel te leggen en voor een aantal ook niet (goed). De discrepanties zullen in de toekomst, in het Nictiz/NHG project "Huisartsoverdrachten", nog verder onderzocht en geslecht worden. Dit ontwerp Huisartsgegevens loopt daarop vooruit, omdat alle FHIR-profielen zich baseren op de zibs. Dit ontwerp en de technische uitwerking zal worden bijgewerkt, zodra de geharmoniseerde zorginformatiebouwstenen beschikbaar zijn. Dit zal naar verwachting niet vóór 2019 plaatsvinden.

In de MedMij FHIR implementatiegids staat de technische representatie van de betreffende zibs in zogenaamde FHIR profielen. In onderstaand overzicht is te zien welk FHIR profiel bij welke zib hoort.

{| class="wikitable collapsible collapsed" cellpadding="10" width="80%"
! style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:center; border: 1px solid black;" colspan="4" | Bijlage 1 Richtlijn Online inzage in het H-EPD door patiënt
! style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:center; border: 1px solid black;" colspan="2" | (Voorlopige) mapping naar zibs
|-
! style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px"| #
! style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px"| Onderdelen uit het Huisarts‑EPD
! style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px"| Beschrijving
! style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px"| Uitleg met voorbeelden
! style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px"| Zorginformatiebouwsteen
! style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px"| Opmerking
|-
| style="background-color: white;vertical-align:top;"| 1
| style="background-color: white;vertical-align:top;"|Huisarts/Huisartsenpraktijk
| style="background-color: white;vertical-align:top;"|De huisarts en/of de huisartsenpraktijk waar de gegevens van afkomstig zijn.
| style="background-color: white;vertical-align:top;"|
| style="background-color: white;vertical-align:top;"| [https://zibs.nl/wiki/Zorgverlener-v3.1(2017NL) Zorgverlener v3.1 (2017)]<br/>[https://zibs.nl/wiki/Zorgaanbieder-v3.1(2017NL) Zorgaanbieder v3.1 (2017)]
| style="background-color: white;vertical-align:top;"|
|-
| style="vertical-align:top;"| 2
| style="vertical-align:top;"|Patiënt
| style="vertical-align:top;"|De patiëntgegevens van de patiënt waarvoor de gegevens zijn.
| style="vertical-align:top;"|
| style="vertical-align:top;"| [https://zibs.nl/wiki/Patient-v3.1(2017NL) Patient v3.1 (2017)]
| style="vertical-align:top;"|
|-
| style="background-color: white;vertical-align:top;"| 3
| style="background-color: white;vertical-align:top;"|Episodes
| style="background-color: white;vertical-align:top;"|Een gezondheidsprobleem zoals een klacht of een aandoening, waarvan de aard in de loop der tijd kan veranderen door voortschrijdend inzicht of door het beloop van de aandoening.
| style="background-color: white;vertical-align:top;"|Ziekten, aandoeningen, klachten en symptomen. Bijvoorbeeld: blaasontsteking of droge hoest.
| style="background-color: white;" rowspan="3"| [https://zibs.nl/wiki/OverdrachtConcern-v1.2(2015NL) OverdrachtConcern v1.2 (2015)]<br/>[https://zibs.nl/wiki/Alert-v3.1(2017EN) Alert v3.1 (2017)]
| style="background-color: white;" rowspan="3"| Na 2015 is nog een versie 3.0 in 2016 uitgebracht die alleen in versie, niet in inhoud veranderd is. De versie van 2017 echter heeft expliciet gebruik voor episodes geschrapt.
|-
| style="vertical-align:top;"| 4
| style="vertical-align:top;"|Episodes met een attentievlag
| style="vertical-align:top;"|Episodes kunnen een attentievlag hebben om extra aandacht voor de episode te vragen. De attentievlag kan aanwezig blijven als een episode afgesloten wordt/is, wanneer de gebruiker het belangrijk vindt dit probleem in beeld te houden.
| style="vertical-align:top;"|Belangrijke ziekten, aandoeningen, klachten en symptomen. Bijvoorbeeld: reuma, suikerziekte, kanker, erfelijke ziekten.
|-
| style="background-color: white;vertical-align:top;"| 5
| style="background-color: white;vertical-align:top;"|Open en gesloten episodes
| style="background-color: white;vertical-align:top;"|Episodes kunnen open (actueel) of gesloten (niet langer actueel) zijn.
| style="background-color: white;vertical-align:top;"|Open/actueel: ziekten, aandoeningen, klachten en symptomen waarvoor nog zorg wordt verleend. Gesloten/niet actueel: ziekten, aandoeningen, klachten en symptomen waarvoor in het verleden zorg is verleend.
|-
| style="vertical-align:top;"| 6
| style="vertical-align:top;"|Behandeling
| style="vertical-align:top;"|Handeling aan de patiënt, die invloed heeft op de gezondheidstoestand van de patiënt.
| style="vertical-align:top;"|Operaties en (zware) behandelingen zoals bestraling of chemotherapie.
| style="vertical-align:top;"| ''[https://zibs.nl/wiki/Verrichting-v4.0(2017NL) Verrichting v4.0 (2017)]''
| style="vertical-align:top;"| zib ondersteunt alleen de DHD Verrichtingenthesaurus waarmee het huisartssysteem niet werkt.
|-
| style="background-color: white;vertical-align:top;"| 7
| style="background-color: white;vertical-align:top;"| Profylaxe en voorzorg
| style="background-color: white;vertical-align:top;"| In Profylaxe en voorzorg worden voorzorgsmaatregelen vastgelegd die nodig zijn bij of vanwege bepaalde medische aandoeningen.
| style="background-color: white;vertical-align:top;"| Bijvoorbeeld voorzorgen bij ooit doorgemaakte endocarditis (ontsteking van de binnenbekleding van het hart en de hartkleppen) of na een miltverwijdering.
| style="background-color: white;vertical-align:top;"|
| style="background-color: white;vertical-align:top;"| Er is in principe slechts een type uit NHG tabel 56
|-
| style="vertical-align:top;"| 8
| style="vertical-align:top;"| Actuele medicatie
| style="vertical-align:top;"| Medicatie-afspraak<br/>Het voorstel van een voorschrijver tot gebruik van medicatie waarmee de patiënt akkoord is. De afspraak kan zowel starten, herhalen, wijzigen als stoppen van medicatie betreffen.
| style="vertical-align:top;"| '''De actuele medicatie''' is het overzicht van de medicatieafspraken. Het is de lijst van geneesmiddelen die de patiënt nu gebruikt.
| style="vertical-align:top;"| [https://zibs.nl/wiki/Medicatieafspraak-v1.0(2017NL) Medicatieafspraak v1.0 (2017)]
| style="vertical-align:top;"|
|-
| style="background-color: white;vertical-align:top;"| 9
| style="background-color: white;vertical-align:top;"| Medicatie-overgevoeligheid
| style="background-color: white;vertical-align:top;"| Een medicatie-overgevoeligheid beschrijft een overgevoeligheid van een patiënt voor een geneesmiddel, een stof of een geneesmiddelengroep, waarmee rekening gehouden moet worden bij het voorschrijven van medicatie.
| style="background-color: white;vertical-align:top;"| Lijst van geneesmiddelen waarop in het verleden een overgevoeligheid of levensbedreigende allergische reactie is opgetreden. Bijvoorbeeld: allergie voor aspirine.
| style="background-color: white;vertical-align:top;"| [https://zibs.nl/wiki/AllergieIntolerantie-v3.1(2017NL) AllergieIntolerantie v3.1 (2017)]
| style="background-color: white;vertical-align:top;"|
|-
| style="vertical-align:top;"| 10
| style="vertical-align:top;"|Correspondentie
| style="vertical-align:top;"|Inkomend: Een binnengekomen brief betreffende een patiënt, die als zodanig is vastgelegd in het medisch dossier van de patiënt.<br/>Uitgaand: Een brief die opgesteld is door een praktijkmedewerker en naar een externe zorgverlener verstuurd is.
| style="vertical-align:top;"|Inkomende = brieven uit het ziekenhuis, polikliniek, zorginstelling.<br/>Uitgaande = verwijsbrieven.
| style="vertical-align:top;"| ''[https://zibs.nl/wiki/TekstUitslag-v4.0(2017NL) TekstUitslag v4.0 (2017)]''
| style="vertical-align:top;"| Correspondentie kan een binair bestand zijn zoals PDF/A, typen in de zib zijn niet toereikend voor alle typen correspondentie
|-
| style="background-color: white;vertical-align:top;"| 11
| style="background-color: white;vertical-align:top;"|Resultaten van bepalingen – ''laatste veertien maanden''
| style="background-color: white;vertical-align:top;"|Een bepaling is een objectiveerbare diagnostische verrichting. Het resultaat is de (uitkomst) van een bepaling.
| style="background-color: white;vertical-align:top;"|Uitslagen van fysieke metingen, zoals bloeddruk, gewicht en laboratoriumtesten, zoals ijzergehalte in het bloed.
| style="background-color: white;vertical-align:top;"|[https://zibs.nl/wiki/LaboratoriumUitslag-v4.0(2017NL) LaboratoriumUitslag v4.0 (2017)]<br/>
[https://zibs.nl/wiki/Bloeddruk-v3.1(2017NL) Bloeddruk v3.1 (2017)]<br/>
[https://zibs.nl/wiki/Lichaamsgewicht-v3.1(2017NL) Lichaamsgewicht v3.1 (2017)]<br/>
[https://zibs.nl/wiki/Lichaamslengte-v3.1(2017NL) Lichaamslengte v3.1 (2017)]<br/>
[https://zibs.nl/wiki/Lichaamstemperatuur-v3.1(2017NL) Lichaamstemperatuur v3.1 (2017)]<br/>
[https://zibs.nl/wiki/AlgemeneMeting-v3.0(2017NL) AlgemeneMeting v3.0 (2017)]<br/>
[https://zibs.nl/wiki/Hartfrequentie-v3.1(2017NL) Hartfrequentie v3.1 (2017)]<br/>
[https://zibs.nl/wiki/O2Saturatie-v3.1(2017NL) O2Saturatie v3.1(2017)]<br/>
[https://zibs.nl/wiki/Polsfrequentie-v3.1(2017NL) Polsfrequentie v3.1(2017)]
| style="background-color: white;vertical-align:top;"|
|-
| style="vertical-align:top;"| 12
| style="vertical-align:top;"|E- en P-regels van de SOEP- structuur - ''vastgelegd na invoering van online inzage''
| style="vertical-align:top;"|Informatie uit een deelcontact dat in vrije tekst wordt geregistreerd volgens de SOEP-structuur. Het acroniem SOEP staat voor Subjectief, Objectief, Evaluatie en Plan.
| style="vertical-align:top;"|In de E(valuatie)-regel staat de conclusie van het consult. In de P(lan)-regel staan de afgesproken zaken en eventuele vervolgstappen.
| style="vertical-align:top;"| ''[https://zibs.nl/wiki/TekstUitslag-v4.0(2017NL) TekstUitslag v4.0 (2017)]''
| style="vertical-align:top;"| Journaalregeltype en ICPC-codering, extra t.o.v. in zib
|}

====Raadplegen huisartsgegevens ====
De vraag wordt gesteld aan de huisarts of huisartsenpraktijk. Er zijn geen verdere parameters bekend. Zie de [[#richtlijn-huisarts-patient|richtlijn]] voor de verdere context van de vraag naar de huisartsgegevens.

Dit betreft de filtermogelijkheden (parameters) in de vraag om huisartsgegevens.

====Beschikbaar stellen huisartsgegevens====
Zie voor de Informatie-elementen in huisartsgegevens de [[#richtlijn-huisarts-patient|richtlijn]].

Dit betreft de inhoud van de transactie met huisartsgegevens.

=== Bedrijfsrollen ===
Deze use case kent twee bedrijfsrollen.

{| class="wikitable" cellpadding="10" width="50%
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:top;"|Wil huisartsgegevens raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt huisartsgegevens beschikbaar
|}
<font size = "1">'''Bedrijfsrollen huisartsgegevens'''</font>

Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren.

[[Bestand:Activity_Diagram_-_Huisartspatientsamenvatting.jpg|Activiteitendiagram Raadplegen huisartsgegevens]]

<font size = "1">'''Activiteitendiagram Raadplegen huisartsgegevens'''</font>

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra vindt u in de [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Roos_Dalstra_MedMij.pdf casus Roos Dalstra].

Hieronder een voor Roos relevante situatie waarbij het raadplegen van de huisartsgegevens een rol speelt.

<blockquote></blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt huisartsgegevens beschikbaar aan het systeem van een patiënt (PGO).
Deze paragraaf vervolgt met een beschrijving van precondities, processtappen, en postcondities.
=====Preconditie=====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van huisartsgegevens tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de huisartsgegevens inzien en de zorgaanbieder stelt deze ook beschikbaar.
Een patiënt kan steeds zelf het initiatief nemen om een huisartsgegevens op te halen, maar het is ook mogelijk dat een PGO geconfigureerd is om dit 'automatisch' te doen. Dit maakt voor de beschrijving van deze use case geen verschil.

=====Processtappen=====
*Het systeem van de patiënt (PGO) vraagt om de beschikbare huisartsgegevens bij een XIS.
*Het systeem van de zorgaanbieder (XIS) levert de huisartsgegevens op voor de patiënt.
*Patiënt gebruikt de persoonlijke gezondheidsomgeving om de huisartsgegevens in te zien.

=====Postconditie=====
De patiënt kan de huisartsgegevens inzien via de persoonlijke gezondheidsomgeving.

=== Systemen & Systeemrollen ===
Zowel zorgaanbieder als patiënt maken gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om de huisartsgegevens van zorgaanbieder naar de patiënt.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Systeemrolcode
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| HuisartsgegevensRaadplegend
| style="background-color: white;"| MM-{{VersieInfo|Huisartsgegevens|release=V2019.01}}-HGR-FHIR
| style="background-color: white;"| Raadplegen huisartsgegevens bij zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| HuisartsgegevensBeschikbaarstellend
| style="background-color: white;"| MM-{{VersieInfo|Huisartsgegevens|release=V2019.01}}-HGB-FHIR
| style="background-color: white;"| Beschikbaarstellen huisartsgegevens aan de patiënt
|-
|}
Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_Huisartspatientsamenvatting_(Totaal).jpg|Componentendiagram]]

<font size="1">'''Componentendiagram'''</font>

De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.

=== Transacties, Transactiegroepen en systeemrollen===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transactiegroep'''
! style="text-align:left;"| '''Transactie'''
! style="text-align:left;"| '''Systeemrolcode'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Link naar technische specificatie'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Huisartsgegevens (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen huisartsgegevens
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|Huisartsgegevens|release=V2019.01}}-HGR-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub-2019.01_FHIR GP Data|Huisartsgegevens in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen huisartsgegevens
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|Huisartsgegevens|release=V2019.01}}-HGB-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:Use_Case_Diagram_-_Huisartspatientsamenvatting.jpg|Use case diagram raadplegen Huisartsgegevens]]

<font size = "1">'''Use case diagram</font>

=Functionaliteit=
Er zijn geen aanwijzingen/eisen voor functionaliteit van de systemen.

=Verantwoordelijkheid voor informatie=
Er zijn geen specifieke toevoegingen over verantwoordelijkheden voor informatie.

=Afschermen van gegevens=
Er zijn geen afspraken over het afschermen van gegevens.

=Infrastructuur=
Er zijn geen afspraken over een specifieke infrastructuur waarop de informatie wordt uitgewisseld.

=Referenties=

{| class="wikitable" "cellpadding="10" width="100%"
!style="text-align:left;"|Auteur(s)
!style="text-align:left;"|Titel
!style="text-align:left;"|Versie
!style="text-align:left;"|Datum
!style="text-align:left;"|Bron
!style="text-align:left;"|Organisatie
|-
| style="background-color: white;"| <span id="richtlijn-huisarts-patient">-</span>
| style="background-color: white;"| Richtlijn Online inzage in het H-EPD door patiënt
| style="background-color: white;"|
| style="background-color: white;"| 2017
| style="background-color: white;"| https://www.nhg.org/themas/publicaties/richtlijn-online-inzage-het-h-epd-door-patient of de [https://www.nhg.org/sites/default/files/content/nhg_org/images/richtlijn_online_inzage_in_het_h-epd_door_patient_web_2017.pdf directe link (PDF)]
| style="background-color: white;"| NHG / Patiëntenfederatie
|-
| style="background-color: white;"| <span id="his-referentiemodel-2016">-</span>
| style="background-color: white;"| HIS referentiemodel Publieksversie (Utrecht 2016)
| style="background-color: white;"|
| style="background-color: white;"| 2016
| style="background-color: white;"| https://referentiemodel.nhg.org/inhoud/themas/publieksversie/published
| style="background-color: white;"| NHG
|}

=Release notes=

In onderstaande tabel staan de wijzigingen voor deze informatiestandaard. Zie de [[MedMij:Vprepub-2019.01_Ontwerpen#Release_Notes|Ontwerpen landingspagina]] voor wijzigingen die op alle informatiestandaarden van toepassing zijn.

{| class="wikitable" "cellpadding="10" style="background-color: white;"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving

{{ReleaseNotes|release=1.2.2|package=2019.01 - Juni 2022|issues=1|MM-3099}}
{{ReleaseNotes|release=1.2.0|package=2019.01 - Maart 2022|issues=1|MM-2983}}
{{ReleaseNotes|release=1.1.21|package=2019.01 - Mei 2021|issues=1|MM-2124}}
{{ReleaseNotes|release=1.1.19|package=2019.01 - Maart 2021|issues=1|MM-1796}}
{{ReleaseNotes|release=1.1.18|package=2019.01 - Februari 2021|issues=1|MM-1681}}
{{ReleaseNotes|release=1.1.15|package=2019.01 - Mei 2020|issues=2|MM-1117|MM-1097}}
{{ReleaseNotes|release=1.1.11|package=2019.01 - Maart 2020|packageIssues=2|issues=2|MM-940|MM-926}}
|-
| rowspan = 2; style="background-color: white; | 2019.01 - Januari 2020
| rowspan = 2; style="background-color: white; | 1.1.9
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-492 MM-492]
| style="background-color: white;"| Added comment to AllergyIntolerance.comment in the HCIM Allergyintolerance FHIR profile to explain the mapping for ValueSet AllergieStatusCodelijst to AllergyIntolerance.clinicalStatus and AllergyIntolerance.verificationStatus. Added dataAbsentReason extension to AllergyIntolerance.verificationStatus.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-467 MM-467]
| style="background-color: white;"| Added comment on MedicationRequest.reasonCode in HCIM MedicationAgreement profile to to explain mising HCIM mapping.
|-
| rowspan = 2; style="background-color: white;"| 2019.01 - November
| rowspan = 2; style="background-color: white;"| 1.1.8
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-655 MM-655]
| style="background-color: white;"| Cardinality of Observation.subject in the gp-journalEntry profile has been changed from 0..1 to 1..1. In addition, this profile is now based on the nl-core-observation profile to ensure consistency.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-618 MM-618]
| style="background-color: white;"| Changed faulty 'include:' to 'include=' in Search URL on TO for GP Data #8.
|-
| rowspan = 3; style="background-color: white;"| 2019.01 - Oktober
| rowspan = 3; style="background-color: white;"| 1.1.7
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-601 MM-601]
| style="background-color: white;"| Search parameters op codesysteem moeten eindigen op <nowiki>|</nowiki>.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-530 MM-530]
| style="background-color: white;"| Duiding toegevoegd bij het opvragen van contactverslagen ten aanzien van de samenstelregels voor Composition resources
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-528 MM-528]
| style="background-color: white;"| Parameter periodofuse is a required parameter for MedicationAgreements. Removed ''This may or may not be populated. If it is not, the Medicationagreement is assumed to be current.''
|-
| rowspan = 2; style="background-color: white; | 2019.01 - September
| rowspan = 2; style="background-color: white; | 1.1.6
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-436 MM-436]
| style="background-color: white;"| Aanpassen ConceptMap InterpretatieVlaggenCodelijst-to-observation-interpretation.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-422 MM-422]
| style="background-color: white;"| Aanpassen conceptnaam ResultaatVlaggen naar InterpretatieVlaggen in FHIR profiel voor LaboratoryResults.
|-
| rowspan = 11; style="background-color: white;"| 2019.01
| rowspan = 5; style="background-color: white;"| 1.1.5
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-308 MM-308]
| style="background-color: white;"| List of StructureDefinitions has been updated to reflect profiles that are currently implementable. As not the whole guideline is implementable at this point in time as reflected in the List of Invocations, this makes the List of StructureDefinitions smaller than it was. The Corresponce section is thus no longer present and this solves the dead link.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-307 MM-307]
| style="background-color: white;"| Aanpassen mapping van "Reden wijzigen of staken" en "Reden wijzigen of stoppen gebruik" van HCIM naar MP9.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-258 MM-258]
| style="background-color: white;"| HCIM PharmaceuticalProduct: Added ValueSet 'IngredientCodeGTINCodeLijst' + correct reference url to ValueSet.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-255 MM-255]
| style="background-color: white;"| Extensies DateLastEncounter, DateFirstEncounter en EpisodeOfCareTitle toegevoegd aan nl-core-episodeofcare profiel.
|-
| style="background-color: white;"| 1.1.4
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-269 MM-269]
| style="background-color: white;"| Huisartsgegevens: Discrepantie Technisch ontwerp en Kwalificatie
|-
| style="background-color: white;"| 1.1.3
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-251 MM-251]
| style="background-color: white;"| Fout in voorbeeld sectie Treatment van Huisartsgegevens
|-
| style="background-color: white;"| 1.1.1
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-206 MM-206]
| style="background-color: white;"| Reference vanuit Observation naar Specimen Isolate onjuist.
|-
| rowspan = 3; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-144 MM-144]
| style="background-color: white;"| Problem zib ClinicalStatus can take on values which are not defined by the HCIM.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-118 MM-118]
| style="background-color: white;"| Profiel naam zib-Product niet passend bij zib FarmaceutischProduct.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-100 MM-100]
| style="background-color: white;"| Mapping CBV naar SNOMED codes.
|-
| rowspan = 3; style="background-color: white;"| 2018.06
| rowspan = 3; style="background-color: white;"| 1.0.0
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-66 MM-66]
| style="background-color: white;"| Update mappings LaboratoriumUitslag in DiagnosticReport en Observation.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-64 MM-64]
| style="background-color: white;"| Koppelen van meetinstrument aan relevante profielen.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-51 MM-51]
| style="background-color: white;"| Extend query for AllergyIntolerance with parameter <code>code</code>. This parameter allows querying specifically medication intolerances.
|}

MedMij:Vprepub-2019.01 OntwerpHuisartsgegevens

2022-07-05T08:06:36Z

Eduard de Rijcke: Relase notes van Patchrelease Juni 2022 toegevoegd

MedMij:V2019.01 OntwerpGGZ

2022-07-05T08:05:10Z

Eduard de Rijcke: Relase notes van Patchrelease Juni 2022 toegevoegd

{{MedMij:Vprepub-2019.01_IssueBoxTD_NL}}
__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Functioneel Ontwerp Basisgegevens GGZ {{VersieInfo|BgGGZ|release=V2019.01}} (op basis van zibs release 2017)}}

[[Bestand:MedMij-GGZ-63.png |link=|links|80px|Use case GGZ|GGZ]]
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2019.01_FHIR_GGZ|Technisch]]
desc none
</imagemap>

=Inleiding=

==Algemeen==
Deze pagina beschrijft het functioneel ontwerp voor de uitwisseling van Basisgegevens GGZ op basis van een selectie zorginformatiebouwstenen (zibs) binnen MedMij. De algemene inleiding van de MedMij functionele ontwerpen kan [[MedMij:Vprepub-2019.01_Ontwerpen| hier]] gevonden worden.

Binnen het [https://www.vippggz.nl/regeling/doelstellingen.html VIPP GZZ programma] zijn een drietal modules opgenomen:
* Module "Patiënt & Informatie": de Basisgegevens GGZ is bedoeld voor deze module.
* Module "Patiënt & Medicatie": hiervoor wordt verwezen naar het [[MedMij:Vprepub-2019.01_OntwerpMedicatie| functioneel ontwerp]] voor [https://www.nictiz.nl/programmas/medicatieproces Medicatieproces 9.0].
* Module "Patiënt & eHealth".

Voor de module "Patiënt & Informatie" is een [https://zoek.officielebekendmakingen.nl/stcrt-2018-60877.html#d17e2089 lijst van verplichte zorginformatiebouwstenen (zibs)] vastgesteld die geschikt zijn verklaard voor de GGZ sector, de Basisgegevens GGZ. Deze lijst omvat momenteel alleen de reeds beschikbare zibs (publicatie 2017) met minimale inhoud en structuur als opmaat naar een volwaardige GGZ informatiestandaard (in ontwikkeling door GGZ Nederland en Nictiz). De lijst van zibs en hierop gebaseerd specificaties vertoont enige overlap met de [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz Basisgegevensset Zorg (BgZ)] maar is zeker niet hetzelfde: zie [[MedMij:Vprepub-2019.01_OntwerpGGZ#Informatie| Informatie]] voor een nadere toelichting over het samenstellen van de inhoud.

De use cases voor de toekomstige GGZ informatiestandaard zijn nog niet omschreven, echter staat voor het VIPP GGZ programma het perspectief van de patiënt centraal. Het doel van deze pagina is dan ook om de uitwisseling van de Basisgegevens GGZ met de patiënt te omschrijven.

==Doelgroep==
De doelgroep voor deze pagina wijkt niet af van de algemene doelgroep van de MedMij functionele ontwerpen, die [[MedMij:Vprepub-2019.01_Ontwerpen#Doelgroep| hier]] gevonden kan worden.

==Kaders en uitgangspunten==
===Richtlijn===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub-2019.01_Ontwerpen#Richtlijn| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Infrastructuur===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub-2019.01_Ontwerpen#Infrastructuur| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Geografische reikwijdte===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub-2019.01_Ontwerpen#Geografische_reikwijdte| de algemene inleiding]] van de MedMij functionele ontwerpen.

==Kwalificatie==
===Introductie===
{{#lst:MedMij:Vprepub-2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

===Specifieke informatie over deze kwalificatie===
Specifieke informatie over de kwalificatie van de transacties 'Raadplegen GGZ' en 'Beschikbaarstellen GGZ' is [[MedMij:Vprepub-2019.01_ToelichtingKwalificatieGGZ| hier]] te vinden.

=Use Cases=
==Use case 1: Raadplegen Basisgegevens GGZ in persoonlijke gezondheidsomgeving==
=== Doel en relevantie ===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de Basisgegevens GGZ die over henzelf gaan.

=== Domein ===
Basisgegevens GGZ in het domein van zorgaanbieders en patiënten.

=== Context ===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de Basisgegevens GGZ vanuit een zorgaanbiederssysteem (XIS) naar een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO).
Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie,
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.

De beschrijving is infrastructuur-onafhankelijk.

=== Informatie ===
De Basisgegevens GGZ bestaat uit een selectie van 24 zibs {{IssueBox|Met de invoering van de Wet verplichte ggz (Wvggz) die per 1 januari 2020 is ingegaan, is de zib VrijheidsBeperkendeMaatregelen (in publicatie 2017) achterhaald. Om deze reden wordt er vanaf nu niet meer gecontroleerd op deze zib tijdens kwalificatie van de BgGGZ en is het niet meer de bedoeling deze uit te wisselen.}}

Deze zibs vormen samen een verzameling van gegevens die binnen de GGZ sector toepasbaar zijn. Hierbij bestaat de selectie voorlopig alleen uit reeds bestaande zibs (publicatie 2017) die voor de GGZ sector geschikt zijn met een minimale inhoud en structuur zoals te vinden in dit [[MedMij:Vprepub-2019.01_InhoudGGZ|overzicht]]. Bij de ontwikkeling van de volwaardige GGZ informatiestandaard wordt dit nader gespecificeerd, met nadere uitwerking van GGZ-specifieke gegevens die nog niet gedekt worden door bestaande zibs. De Basisgegevens GGZ zal in de toekomst hiermee worden aangevuld. De huidige lijst aan geselecteerde zibs komt voor een deel overeen met de [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset Zorg (BgZ)], maar voor een deel ook niet: het gaat om twee aparte sets. Zie het [[MedMij:Vprepub-2019.01_InhoudGGZ|overzicht van de inhoud]] voor een nadere toelichting.

Medicatiegegevens vallen buiten de Basisgegevens GGZ, omdat hiervoor gebruik wordt gemaakt van het reeds bestaande [https://www.nictiz.nl/programmas/medicatieproces Medicatieproces 9.0] (zie [[MedMij:Vprepub-2019.01_OntwerpMedicatie| hier]] voor uitwisseling medicatiegegevens in PGO).

In de bestaande zibs valt de zogenaamde juridische status en vertegenwoordiging binnen de zib VrijheidsbeperkendeMaatregelen. Voor de GGZ sector is het loskoppelen van dit gegeven (als losstaande zib) van groot belang, omdat deze ook relevant is buiten de toepassing van vrijheidsbeperkende maatregelen. In de verdere uitwerking van de Basisgegevens GGZ is het element JuridischeStatus losgekoppeld van de verdere zib VrijheidsbeperkendeMaatregelen. Deze loskoppeling wordt tevens als wijzigingsverzoek behandeld bij de nieuwe publicatie zibs: de huidige uitwerking loopt op deze toekomstige ontwikkeling vooruit.

In de MedMij FHIR implementatie gids staat de technische representatie van de betreffende zibs in zogenaamde FHIR profielen. In dit [[MedMij:Vprepub-2019.01_FHIR_GGZ#List_of_StructureDefinitions|overzicht]] is te zien welk FHIR profiel bij welke zib hoort.

=== Bedrijfsrollen ===
Deze use case onderscheidt twee bedrijfsrollen, namelijk de ''Patiënt'' en de ''Zorgaanbieder'' zoals te zien in onderstaande tabel.

{| class="wikitable" "cellpadding="10" width="100%"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Bedrijfsrol'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:top;"|Wil de eigen Basisgegevens GGZ raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt de Basisgegevens GGZ beschikbaar
|}
<font size = "1">'''Bedrijfsrollen Basisgegevens GGZ'''</font>

Onderstaande afbeelding toont de verschillende activiteiten uit de procesbeschrijving die door de bedrijfsrollen worden uitgevoerd.

[[Image:InzienGGZ_activity.png|Activiteitendiagram Raadplegen GGZ]]

<font size = "1">'''Activiteitendiagram Raadplegen GGZ'''</font>

=== Procesbeschrijving ===
==== Patient journey - Jelmer Postma ====
De 'patient journey' van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Jelmer_Postma_MedMij.pdf Jelmer Postma] beschrijft enkele momenten waarop je als patiënt zijnde inzicht kan of zou willen hebben in zijn/haar Basisgegevens GGZ.

<blockquote>In zijn PGO kan Jelmer doorlezen wat de huisarts voorgeschreven heeft en vindt hij de verwijzing voor een psycholoog. Hij zoekt een psycholoog uit en maakt een afspraak waarbij hij de verwijzing bijvoegt.</blockquote>

<blockquote>‘Pling’, Jelmer krijgt van zijn PGO een reminder dat hij morgen om 10.00 zijn eerste afspraak heeft bij de psycholoog. Tevens kan hij vanuit zijn PGO een vragenlijst invullen voor de psycholoog over zijn klachten, gezondheid en verwachtingen. Wat zijn huisarts al vermoedde, wordt door de psycholoog bevestigd.</blockquote>

<blockquote>Gedurende de sessie komen er onverwerkte zaken uit zijn jeugd boven. Deze zijn zo heftig dat Jelmer in een acute depressie belandt. Zijn vriendin Karin geeft aan dat Jelmer op het moment niet thuis kan wonen en samen met de huisarts nemen ze het besluit dat Jelmer voor korte duur opgenomen wordt bij een GGZ-instelling in de buurt. Hier wordt een nieuw behandelplan opgesteld waarin groepstherapie een onderdeel gaat worden. Jelmer heeft Karin gemachtigd om in zijn PGO te kijken zodat ze onder andere het behandelplan in kan zien en ze goed betrokken wordt.</blockquote>

<blockquote>De opname in de GGZ-instelling is van korte duur. Vanaf nu wordt Jelmer ambulant behandeld door een reguliere GGZ-instelling. Gelukkig is deze met 5 minuten fietsen van huis lekker dichtbij. De psychiater van de instelling schrijft een overdracht voor zijn nieuwe hoofdbehandelaar. Zowel Karin als Jelmer kunnen via het PGO inzien wat daarin staat. Daarom weten ze nu dat de medicatie is aangepast.</blockquote>

==== Proces ====
Het stuk van het proces waar het in deze use case om gaat is:
* Het systeem van een zorgaanbieder (XIS) stelt de Basisgegevens GGZ van de patiënt beschikbaar aan het systeem van een patiënt (PGO).

Deze paragraaf vervolgt met een beschrijving van precondities, proces stappen, en post condities.

===== Preconditie =====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van de Basisgegevens GGZ tussen het betreffende XIS en het eigen PGO.

De Basisgegevens GGZ, of een gedeelte van de Basisgegevens GGZ, welke de persoon wil inzien, bestaat en de zorgaanbieder wil deze beschikbaar stellen.
:Soms zijn er valide redenen om de Basisgegevens GGZ, of gedeeltes daarvan, tijdelijk nog niet beschikbaar te stellen aan de patiënt. Bijvoorbeeld omdat de zorgverlener deze eerst zelf wil interpreteren en/of er eerst met de patiënt over wil spreken.
:Een patiënt kan steeds zelf het initiatief nemen om de Basisgegevens GGZ op te halen, maar het is ook mogelijk dat een PGO geconfigureerd is om dit 'automatisch' te doen. Dit maakt voor de scope van deze use case beschrijving geen verschil.

===== Proces stappen =====
* Het systeem van de patiënt (PGO) raadpleegt het systeem van de zorgaanbieder (XIS) voor de Basisgegevens GGZ van de patiënt.
* Het systeem van de zorgaanbieder (XIS) maakt (een deel van) de Basisgegevens GGZ beschikbaar voor de patiënt.
* De patiënt gebruikt de persoonlijke gezondheidsomgeving om de Basisgegevens GGZ in te zien.

===== Post conditie =====
De persoon kan de Basisgegevens GGZ inzien via een persoonlijke gezondheidsomgeving.

=== Systemen & Systeemrollen ===
Zowel de persoon als de zorgaanbieder maken ieder gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om de Basisgegevens GGZ van zorgaanbieder naar de persoon.

{| class="wikitable" "cellpadding="10"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Systeem
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Naam systeemrol
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Systeemrolcode
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| GGZRaadplegend
| style="background-color: white;"| MM-{{VersieInfo|BgGGZ|release=V2019.01}}-GGR-FHIR
| style="background-color: white;"| Raadplegen Basisgegevens GGZ bij zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| GGZBeschikbaarstellend
| style="background-color: white;"| MM-{{VersieInfo|BgGGZ|release=V2019.01}}-GGB-FHIR
| style="background-color: white;"| Beschikbaarstellen Basisgegevens GGZ aan de patiënt
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:InzienGGZ_componenten.png.PNG|Componenten diagram]]

<font size = "1">'''Componenten diagram van systemen en systeemrollen'''</font>

=== Transacties & Transactiegroepen ===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Transactiegroep'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Transactie'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Systeemrolcode'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Systeem'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Bedrijfsrol'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|GGZ (PULL)
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/decor/services/RetrieveTransaction?id=2.16.840.1.113883.2.4.3.11.60.57.4.11&language=nl-NL&effectiveDate=2020-10-16T10:16:01&format=html&hidecolumns=56bcdefgijklmnop Raadplegen GGZ (1.1)]
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|BgGGZ|release=V2019.01}}-GGR-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub-2019.01_FHIR_GGZ |GGZ in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/decor/services/RetrieveTransaction?id=2.16.840.1.113883.2.4.3.11.60.57.4.12&language=nl-NL&effectiveDate=2020-10-16T10:16:01&format=html&hidecolumns=56bcdefgijklmnop Beschikbaarstellen GGZ (1.1)]
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|BgGGZ|release=V2019.01}}-GGB-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:InzienGGZ_useCase.png|Use case diagram raadplegen Basisgegevens GGZ]]

<font size = "1">'''Use case diagram raadplegen Basisgegevens GGZ</font>

=Functionaliteit=
Er zijn geen aanwijzingen/eisen voor functionaliteit van de systemen.

=Verantwoordelijkheid voor informatie=
Er zijn geen specifieke toevoegingen over verantwoordelijkheden voor informatie.

=Afschermen van gegevens=
Er zijn geen afspraken over het afschermen van gegevens.

=Infrastructuur=
Er zijn geen afspraken over een specifieke infrastructuur waarop de informatie wordt uitgewisseld.

=Referenties=

{| class="wikitable" "cellpadding="10" width="100%"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Auteur(s)
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Titel
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Versie
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Datum
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Bron
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Organisatie
|-
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
|}
<font size = "1">'''Referenties</font>

=Release notes=

In onderstaande tabel staan de wijzigingen voor deze informatiestandaard. Zie de [[MedMij:Vprepub-2019.01_Ontwerpen#Release_Notes|Ontwerpen landingspagina]] voor wijzigingen die op alle informatiestandaarden van toepassing zijn.

{| class="wikitable" "cellpadding="10" style="background-color: white;"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Release
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Versie
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|BITS issue
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black; width:850px;"|Omschrijving

{{ReleaseNotes|package=2019.01 - Juni 2022|release=1.2.2|issues=1|MM-3099}}
{{ReleaseNotes|package=2019.01 - Maart 2022|release=1.2.0|issues=1|MM-2983}}
{{ReleaseNotes|package=2019.01 - April 2021|release=1.1.19|issues=1|MM-1959}}
{{ReleaseNotes|package=2019.01 - Februari 2021|release=1.1.17|issues=1|MM-1767}}
{{ReleaseNotes|package=2019.01 - Oktober 2020|release=1.1.14|issues=1|MM-1461}}
{{ReleaseNotes|package=2019.01 - April 2020|release=1.1.13|issues=3|MM-1025|MM-1003|MM-939}}
{{ReleaseNotes|package=2019.01 - Maart 2020|release=1.1.10|issues=4|MM-997|MM-953|MM-931|MM-657}}
|-
| rowspan = 2 style="background-color: white; | 2019.01 - November
| style="background-color: white; | 1.1.7
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-806 MM-806]
| style="background-color: white;"| Fixed MM-430: adjusted incorrect FHIRPath constraints, moved extension to Consent.extension and moved mappings in extension from extension.value[x].reference to extension.value[x] in zib TreatmentDirective profile.
|-
| style="background-color: white; | 1.1.6
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-430 MM-430]
| style="background-color: white;"| The TreatmentDirective profile allowed at most 1 reference to an AdvanceDirective resource, because of restrictions in the FHIR base. There is now an extension inside the source element to allow referencing additional AdvanceDirective resources.
|-
| style="background-color: white; | 2019.01 - Oktober
| style="background-color: white; | 1.1.5
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-594 MM-594]
| style="background-color: white;"| Updated date time example in profile to include timezone as required by the FHIR specification.
|-
| rowspan = 4 style="background-color: white;"| 2019.01 - September
| rowspan = 4 style="background-color: white;"| 1.1.4
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-358 MM-358]
| style="background-color: white;"| Tekstcorrectie op de kwalificatie pagina ToelichtingKwalificatieGGZ.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-336 MM-336]
| style="background-color: white;"| Aanpassen ConceptMap InterpretatieVlaggenCodelijst-to-observation-interpretation
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-327 MM-327]
| style="background-color: white;"|
Fixed reference to generalPractitioner in examples nl-core-patient-languageProficiency - example.xml and nl-core-patient-legalStatus - example.xml.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-322 MM-322]
| style="background-color: white;"| Aanpassen conceptnaam ResultaatVlaggen naar InterpretatieVlaggen in FHIR profiel voor LaboratoryResults.
|-
| rowspan = 10; style="background-color: white;"| 2019.01
|-
| rowspan = 3; style="background-color: white;"| 1.1.3
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-346 MM-346]
| style="background-color: white;"| Ongeldig discriminator pad in code slicing in zib Verrichting
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-294 MM-294]
| style="background-color: white;"| Naam mapping binnen div. FHIR profielen aangepast conform zib: HCIM LaboratoryTestResult-v4.1(2017EN).
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-252 MM-252]
| style="background-color: white;"| FreedomRestrictingMeasures incorrecte terminologie in profiel en technisch ontwerp pagina
|-
| style="background-color: white;"| 1.1.1
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-206 MM-206]
| style="background-color: white;"| Reference vanuit Observation naar Specimen Isolate onjuist.
|-
| rowspan = 5; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-143 MM-143]
| style="background-color: white;"| Aanpassing modellering Procedure.performer in het profiel voor HCIM Verrichting.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-118 MM-118]
| style="background-color: white;"| Profiel naam zib-Product niet passend bij zib FarmaceutischProduct.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-100 MM-100]
| style="background-color: white;"| Mapping CBV naar SNOMED codes.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-99 MM-99]
| style="background-color: white;"| Interval heeft Period maar geen PeriodUnit op simplifier.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-50 MM-50]
| style="background-color: white;"| Contact ondersteunt geen klinische contacten.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.0.0
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-128 MM-128]
| style="background-color: white;"| CanceledIndicator possible values.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-66 MM-66]
| style="background-color: white;"| Update mappings LaboratoriumUitslag in DiagnosticReport en Observation.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-55 MM-55]
| style="background-color: white;"| Profile for HCIM TobaccoUse was missing a specification for PackYears unit - profile updated to 2.0.1.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-54 MM-54]
| style="background-color: white;"| Wrong SNOMED code in search URL for FunctionalOrMentalStatus in BgZ and GGZ.
|}

MedMij:Vprepub-2019.01 OntwerpGGZ

2022-07-05T08:05:10Z

Eduard de Rijcke: Relase notes van Patchrelease Juni 2022 toegevoegd

MedMij:V2019.01 OntwerpLangdurigeZorg

2022-07-05T08:03:57Z

Eduard de Rijcke: Relase notes van Patchrelease Juni 2022 toegevoegd

__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Functioneel Ontwerp Basisgegevens Langdurige Zorg {{VersieInfo|BgLZ|release=V2019.01}} (op basis van zibs release 2017)}}
{{MedMij:Vprepub-2019.01_Issuebox}}
{{MedMij:V2019.01_Issuebox}}
{{MedMij:V2019.01_IssueBoxTD_NL}}
[[Bestand:BgLZ-icon.png|link=|links|95px|Use case BgLZ|BgLZ]]
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2019.01_FHIR_BGLZ|Technisch]]
desc none
</imagemap>

=Inleiding=

==Algemeen==
Deze pagina beschrijft het functioneel ontwerp voor de uitwisseling van Basisgegevens Langdurige Zorg (BgLZ) op basis van een selectie zorginformatiebouwstenen (zibs) binnen MedMij. De algemene inleiding van de MedMij functionele ontwerpen kan [[MedMij:Vprepub-2019.01_Ontwerpen|hier]] gevonden worden.

Binnen het [https://www.dus-i.nl/subsidies/inzicht InZicht programma] (VIPP langdurige zorg) zijn een drietal modules opgenomen.
* Module PGO: de Basisgegevens Langdurige Zorg is bedoeld voor deze module
* Module [https://www.nictiz.nl/standaardisatie/informatiestandaarden/verpleegkundige-overdracht eOverdracht] (gericht op de verpleegkundige overdracht tussen zorgprofessionals)
* Module Medicatieveiligheid: hiervoor wordt verwezen naar het [[MedMij:Vprepub-2019.01_OntwerpMedicatie| functioneel ontwerp]] voor [https://www.nictiz.nl/programmas/medicatieproces Medicatieproces 9.0].

De Basisgegevens Langdurige Zorg bestaat uit gegevens die relevant zijn voor uitwisseling met patiënten binnen de langdurige zorg via hun [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO). De Basisgegevens Langdurige Zorg vertoont enige overlap met de [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset Zorg (BgZ)] en [https://www.nictiz.nl/standaardisatie/informatiestandaarden/verpleegkundige-overdracht eOverdracht] maar is zeker niet hetzelfde: zie [[MedMij:Vprepub-2019.01_OntwerpLangdurigeZorg#Informatie| Informatie]] voor een nadere toelichting over het samenstellen van de inhoud.

Het doel van deze pagina is om de uitwisseling van de Basisgegevens Langdurige Zorg met de patiënt te omschrijven.

==Doelgroep==
De doelgroep voor deze pagina wijkt niet af van de algemene doelgroep van de MedMij functionele ontwerpen, die [[MedMij:Vprepub-2019.01_Ontwerpen#Doelgroep| hier]] gevonden kan worden.

==Kaders en uitgangspunten==
===Richtlijn===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub-2019.01_Ontwerpen#Richtlijn| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Infrastructuur===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub-2019.01_Ontwerpen#Infrastructuur| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Geografische reikwijdte===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub-2019.01_Ontwerpen#Geografische_reikwijdte| de algemene inleiding]] van de MedMij functionele ontwerpen.

==Kwalificatie==
===Introductie===
{{#lst:MedMij:Vprepub-2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

===Specifieke informatie over deze kwalificatie===
Specifieke informatie over de kwalificatie van de transacties 'Raadplegen Langdurige Zorg' en 'Beschikbaarstellen Langdurige Zorg' is [[MedMij:Vprepub-2019.01_ToelichtingKwalificatieLangdurigeZorg| hier]] te vinden.

=Use Cases=
==Use case 1: Raadplegen Basisgegevens Langdurige Zorg in persoonlijke gezondheidsomgeving==
=== Doel en relevantie ===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de Basisgegevens Langdurige Zorg die over henzelf gaan.

=== Domein ===
Basisgegevens Langdurige Zorg in het domein van zorgaanbieders en patiënten.

=== Context ===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de Basisgegevens Langdurige Zorg vanuit een zorgaanbiederssysteem (XIS) naar een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO).
Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie,
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.

De beschrijving is infrastructuur-onafhankelijk.

=== Informatie ===
De Basisgegevens Langdurige Zorg bestaat uit een selectie van 14 zibs zoals te vinden in dit [[MedMij:Vprepub-2019.01_InhoudLangdurigeZorg|overzicht]]. Deze zibs vormen samen een verzameling van gegevens die patiënten binnen de langdurige zorg zelf relevant vinden om via hun PGO in te zien, zoals bepaald tijdens een aantal veldverkenningen met zowel patiënten als zorgprofessionals. De Basisgegevens Langdurige Zorg komt voor een deel overeen met de [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset Zorg (BgZ)] en [https://www.nictiz.nl/standaardisatie/informatiestandaarden/verpleegkundige-overdracht/ eOverdracht], maar voor een deel ook niet: het gaat om drie aparte sets. Zie het [[MedMij:Vprepub-2019.01_InhoudLangdurigeZorg|overzicht van de inhoud]] voor een nadere toelichting.

Medicatiegegevens vallen buiten de Basisgegevens Langdurige Zorg, omdat hiervoor gebruik wordt gemaakt van het reeds bestaande [https://www.nictiz.nl/programmas/medicatieproces Medicatieproces 9.0] (zie [[MedMij:Vprepub-2019.01_OntwerpMedicatie|uitwisseling medicatiegegevens]] in PGO).

In de MedMij FHIR implementatiegids staat de technische representatie van de betreffende zibs in zogenaamde FHIR profielen. In dit [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_BGLZ#List_of_StructureDefinitions overzicht] is te zien welk FHIR profiel bij welke zib hoort.

=== Bedrijfsrollen ===
Deze use case onderscheidt twee bedrijfsrollen, namelijk de ''Patiënt'' en de ''Zorgaanbieder'' zoals te zien in onderstaande tabel.

{| class="wikitable" "cellpadding="10" width="100%"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Bedrijfsrol'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:top;"|Wil de eigen Basisgegevens Langdurige Zorg raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt de Basisgegevens Langdurige Zorg beschikbaar
|}
<font size = "1">'''Bedrijfsrollen Basisgegevens Langdurige Zorg'''</font>

Onderstaande afbeelding toont de verschillende activiteiten uit de procesbeschrijving die door de bedrijfsrollen worden uitgevoerd.

[[Image:InzienLZ_activity.PNG|Activiteitendiagram Raadplegen Langdurige Zorg]]

<font size = "1">'''Activiteitendiagram Raadplegen Langdurige Zorg'''</font>

=== Procesbeschrijving ===
==== Patient journey - Kenneth van Someren ====
De 'patient journey' van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Kenneth_van_Someren_MedMij.pdf Kenneth van Someren] beschrijft enkele momenten waarop je als patiënt zijnde inzicht kan of zou willen hebben in zijn/haar Basisgegevens Langdurige Zorg.

<blockquote>Op aanraden van zijn dochter heeft Kenneth nu ook een PGO, waarop hij kan zien wanneer de wijkverpleegkundige komt of de huishoudelijke hulp. Als het nodig is kan hij via zijn PGO doorgeven dat hij niet mee eet omdat hij bij een van zijn kinderen eet. De vrijwilligers van de bezorgdienst krijgen dit automatisch doorgegeven.</blockquote>

<blockquote>Hij krijgt een EVV-er (eerst verantwoordelijke verpleegkundige) toegewezen, die samen met Kenneth een zorgleefplan gaat opstellen. Zodra het zorgleefplan compleet is, komt dit beschikbaar in zijn PGO. Daarmee kan Kenneth goed zien welke afspraken er met de instelling zijn gemaakt.</blockquote>

==== Proces ====
Het stuk van het proces waar het in deze use case om gaat is:
* Het systeem van een zorgaanbieder (XIS) stelt de Basisgegevens Langdurige Zorg van de patiënt beschikbaar aan het systeem van een patiënt (PGO).

Deze paragraaf vervolgt met een beschrijving van precondities, proces stappen, en post condities.

===== Preconditie =====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van de Basisgegevens Langdurige Zorg tussen het betreffende XIS en het eigen PGO.

De Basisgegevens Langdurige Zorg, of een gedeelte van de Basisgegevens Langdurige Zorg, welke de persoon wil inzien, bestaat en de zorgaanbieder wil deze beschikbaarstellen.
:Soms zijn er valide redenen om de Basisgegevens Langdurige Zorg, of gedeeltes daarvan, tijdelijk nog niet beschikbaar te stellen aan de patiënt. Bijvoorbeeld omdat de zorgverlener deze eerst zelf wil interpreteren en/of er eerst met de patiënt over wil spreken.
:Een patiënt kan steeds zelf het initiatief nemen om de Basisgegevens Langdurige Zorg op te halen, maar het is ook mogelijk dat een PGO geconfigureerd is om dit 'automatisch' te doen. Dit maakt voor de scope van deze use case beschrijving geen verschil.

===== Processtappen =====
* Het systeem van de patiënt (PGO) raadpleegt het systeem van de zorgaanbieder (XIS) voor de Basisgegevens Langdurige Zorg van de patiënt.
* Het systeem van de zorgaanbieder (XIS) maakt (een deel van) de Basisgegevens Langdurige Zorg beschikbaar voor de patiënt.
* De patiënt gebruikt de persoonlijke gezondheidsomgeving om de Basisgegevens Langdurige Zorg in te zien.

===== Postconditie =====
De persoon kan de Basisgegevens Langdurige Zorg inzien via een persoonlijke gezondheidsomgeving.

=== Systemen & Systeemrollen ===
Zowel de persoon als de zorgaanbieder maken ieder gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om de Basisgegevens Langdurige Zorg van zorgaanbieder naar de persoon.

{| class="wikitable" "cellpadding="10"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Systeem
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Naam systeemrol
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Systeemrolcode
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| LZRaadplegend
| style="background-color: white;"| MM-{{VersieInfo|BgLZ|release=V2019.01}}-LZR-FHIR
| style="background-color: white;"| Raadplegen Basisgegevens Langdurige Zorg bij zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| LZBeschikbaarstellend
| style="background-color: white;"| MM-{{VersieInfo|BgLZ|release=V2019.01}}-LZB-FHIR
| style="background-color: white;"| Beschikbaarstellen Basisgegevens Langdurige Zorg aan de patiënt
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:InzienLZ_component.PNG|Componenten diagram]]

<font size = "1">'''Componenten diagram van systemen en systeemrollen'''</font>

=== Transacties & Transactiegroepen ===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Transactiegroep'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Transactie'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Systeemrolcode'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Systeem'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Bedrijfsrol'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|Basisgegevens Langdurige Zorg (PULL)
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/decor/services/RetrieveTransaction?id=2.16.840.1.113883.2.4.3.11.60.58.4.2&effectiveDate=2019-04-09T16:33:35&language=*&ui=nl-NL&version=2019-09-04T10:21:41&format=html&hidecolumns=34567 Raadplegen Basisgegevens Langdurige Zorg]
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|BgLZ|release=V2019.01}}-LZR-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub-2019.01_FHIR_BGLZ|Basisgegevens Langdurige Zorg in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/decor/services/RetrieveTransaction?id=2.16.840.1.113883.2.4.3.11.60.58.4.3&effectiveDate=2019-04-09T16:33:35&language=*&ui=nl-NL&version=2019-09-04T10:21:41&format=html&hidecolumns=34567 Beschikbaarstellen Basisgegevens Langdurige Zorg]
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|BgLZ|release=V2019.01}}-LZB-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:InzienLZ_usecase.PNG|Use case diagram raadplegen Basisgegevens Langdurige Zorg]]

<font size = "1">'''Use case diagram raadplegen Basisgegevens Langdurige Zorg</font>

=Functionaliteit=
Er zijn geen aanwijzingen/eisen voor functionaliteit van de systemen.

=Verantwoordelijkheid voor informatie=
Er zijn geen specifieke toevoegingen over verantwoordelijkheden voor informatie.

=Afschermen van gegevens=
Er zijn geen afspraken over het afschermen van gegevens.

=Infrastructuur=
Er zijn geen afspraken over een specifieke infrastructuur waarop de informatie wordt uitgewisseld.

=Referenties=

{| class="wikitable" "cellpadding="10" width="100%"
!style="text-align:left;"|Auteur(s)
!style="text-align:left;"|Titel
!style="text-align:left;"|Versie
!style="text-align:left;"|Datum
!style="text-align:left;"|Bron
!style="text-align:left;"|Organisatie
|-
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
|}

=Release notes=

In onderstaande tabel staan de wijzigingen voor deze informatiestandaard. Zie de [[MedMij:Vprepub-2019.01_Ontwerpen#Release_Notes|Ontwerpen landingspagina]] voor wijzigingen die op alle informatiestandaarden van toepassing zijn.

{| class="wikitable" "cellpadding="10" style="background-color: white"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving

{{ReleaseNotes|package=2019.01 - Juni 2022|release=1.1.2|issues=1|MM-3099}}
{{ReleaseNotes|package=2019.01 - Juni 2021|release=1.0.19|issues=2|MM-2166|MM-2148}}
{{ReleaseNotes|package=2019.01 - April 2021|release=1.0.17|issues=1|MM-1959}}
{{ReleaseNotes|package=2019.01 - Februari 2021|release=1.0.15|issues=1|MM-1814}}
{{ReleaseNotes|package=2019.01 - September 2020|release=1.0.11|issues=2|MM-1456|MM-1259}}
{{ReleaseNotes|package=2019.01 - April 2020|release=1.0.9|issues=3|MM-1059|MM-1025|MM-939}}
{{ReleaseNotes|package=2019.01 - Maart 2020|release=1.0.7|issues=3|MM-997|MM-953|MM-931}}
|-
| style="background-color: white; | 2019.01 - November
| style="background-color: white; | 1.0.4
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-806 MM-806]
| style="background-color: white;"| Fixed MM-430: adjusted incorrect FHIRPath constraints, moved extension to Consent.extension and moved mappings in extension from extension.value[x].reference to extension.value[x] in zib-TreatmentDirective profile.
|-
| style="background-color: white; | 2019.01 - Oktober
| style="background-color: white; | 1.0.2
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-599 MM-599]
| style="background-color: white;"| URL value on detailCodeableConcept.coding.system in HCIM TreatmentObjective example was incorrect, changed to the correct value.
|-
| style="background-color: white; | 2019.01 - September
| style="background-color: white; | 1.0.1
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-358 MM-358]
| style="background-color: white;"| Tekstcorrectie op de kwalificatiepagina's van BgZ, GGZ en BgLZ.
|}

MedMij:Vprepub-2019.01 OntwerpLangdurigeZorg

2022-07-05T08:03:57Z

Eduard de Rijcke: Relase notes van Patchrelease Juni 2022 toegevoegd

MedMij:V2019.01 OntwerpVragenlijsten

2022-07-05T08:02:13Z

Eduard de Rijcke: Relase notes van Patchrelease Juni 2022 toegevoegd

__NOINDEX__
{{MedMij:Vprepub-2019.01_IssueBoxTD_NL}}
__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Functioneel Ontwerp Vragenlijsten {{VersieInfo|Vragenlijsten|release=V2019.01}}}}
{{MedMij:Vprepub-2019.01_Issuebox}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Vragenlijsten-zonder-tekst-dun.png|link=|87px |links||media|Vragenlijsten]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2019.01_FHIR_Questionnaire_and_Questionnaire_Response_(Vragenlijsten)|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Op deze pagina wordt het functioneel ontwerp beschreven voor de uitwisseling van vragenlijsten en antwoorden binnen MedMij. De algemene inleiding van de MedMij functionele ontwerpen kan gevonden worden op de pagina [[MedMij:Vprepub-2019.01_Ontwerpen|Ontwerpen MedMij]].

Het ontwerp richt zich op de uitwisseling van informatie en niet op de gebruikersfunctionaliteiten en/of gebruiksvriendelijkheid van een PGO of het systeem van de zorgaanbieder (XIS).

==Doelgroep==
De doelgroep voor deze pagina wijkt niet af van de algemene doelgroep van de MedMij functionele ontwerpen.

==Kaders en uitgangspunten==
===Richtlijn===
Er zijn geen richtlijnen van het zorgaanbiedersdomein. Bij implementeren van de standaard gelden de volgende uitgangspunten:
* Maak gebruik gemaakt van de bestaande, internationale, FHIR-profielen van [http://hl7.org/fhir/us/sdc/index.html SDC (Structured Data Capture)]
** Bij het overnemen van een profiel, zijn deze in hun geheel toegepast
** Het gaat alleen om die profielen die voor deze use case toegevoegde waarde hebben
* Bij ieder overgenomen profiel is, een voor Nederland specifiek profiel opstellen. Er is bijvoorbeeld minimaal een referentie nodig naar het Nederlandse patiëntprofiel
* De SDC-profielen hebben reeds veel verschillende vraagsoorten & antwoordmogelijkheden gespecificeerd, deze worden overgenomen.

===Infrastructuur===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub-2019.01_Ontwerpen#Infrastructuur| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Geografische reikwijdte===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub-2019.01_Ontwerpen#Geografische_reikwijdte| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Informatie reikwijdte===
Het ontwerp richt zich op de uitwisseling van informatie en niet op de gebruikersfunctionaliteiten en/of gebruiksvriendelijkheid van een PGO of het systeem van de zorgaanbieder (XIS).
Het ontwerp bevat:
* Een eenvoudige zorgsituatie:

# Een zorgaanbieder maakt, buiten de persoonlijke gezondheidsomgeving om, een afspraak met een patiënt over het invullen van een vragenlijst
# Deze zorgaanbieder maakt de vragenlijst beschikbaar voor de persoonlijke gezondheidsomgeving van de patiënt
# De patiënt gebruikt zijn persoonlijke gezondheidsomgeving om de vragenlijst op te halen
# De patiënt vult de vragenlijst in en stuurt de antwoorden in zijn geheel terug naar het systeem van de zorgaanbieder (XIS).

Expliciet buiten scope van het ontwerp zijn de volgende onderwerpen:
* Workflow-gerelateerde zaken.
** Notificaties, anders dan waarin het afsprakenstelsel van MedMij wordt voorzien.
** Werkafspraken over (tijdigheid van) invullen en terug sturen.
** Aanpak voor multi-channel mogelijkheden (bijvoorbeeld: via PGO in combinatie met portaal en schriftelijk).

* Complexe computergestuurde vragenlijsten (bijvoorbeeld: Computer Adaptive Testing - CAT).
* Interpretatie van antwoorden. Een uitgangspunt is om PGO's nog niet te belasten met het berekenen van scores op basis van ingevulde antwoorden. Het uitwisselen van de definitie van score-berekening is daarom ook buiten scope. Een XIS kan eventueel berekende scores en terugsturen aan een PGO met de use case [[MedMij:Vprepub-2019.01_OntwerpPDFA#Use_case:_Raadplegen_medische_gegevens_in_PDF.2FA_door_pati.C3.ABnt|PDF/A]].
* Ontwikkeling van nieuwe zibs specifiek voor vragenlijsten.
* Standaardisatie van de inhoud van vragenlijsten (de deliverables van dit project zijn content-agnostisch).
* Toepassing van specifieke coderingen of codestelsels (met uitzondering van administratieve gegevens van patiënt).
* Mogelijke financiële consequenties van het gebruik van vragenlijsten, bijvoorbeeld licentiekosten.

'''Nb.''' Vragenlijsten kunnen gespecificeerde opmaak (bijvoorbeeld vet- of schuingedrukte tekst) hebben die betekenisvol is voor het invullen van een vragenlijst door een PGO-Gebruiker en hiermee relevant is voor een zorgverlener om de uitkomsten te interpreteren. De standaard voorziet in de mogelijkheden om opmaak te specificeren en van gebruikers van deze standaard wordt verwacht dat ze hiermee om kunnen gaan.

==Kwalificatie==
===Introductie===
{{#lst:MedMij:Vprepub-2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
Het raadplegen van de vragenlijstverwijzing, vragenlijst en het sturen van de antwoorden zijn 3 use cases die nadrukkelijk bij elkaar horen. Functioneel kunnen ze zelfs gezien worden als verschillende acties binnen een zelfde use case. Ze zijn echter als separate use case gedefinieerd omdat:
* Het raadplegen van een verwijzing naar een vragenlijst, de vragenlijst en het sturen van de antwoorden asynchroon plaatsvindt
* Het MedMij-afsprakenstelsel voor 'raadplegen en beschikbaarstellen' en voor 'sturen en ontvangen' separate use cases definieert.
Door dit ook in de informatiestandaard gescheiden te houden, kunnen de use cases uit de informatiestandaard goed gemapt worden op de use cases uit het [https://afsprakenstelsel.medmij.nl/display/MedMijAfsprakenstelsel120/MedMij+Afsprakenstelsel+1.2.0 MedMij-afsprakenstelsel]. De splitsing is alleen niet goed voor het totaaloverzicht van de verschillende scenario's.

Er zijn twee bedrijfsrollen, namelijk ''Patiënt'' en ''Zorgaanbieder''. Een zorgaanbieder biedt een verwijzing naar een vragenlijst aan, die gebruikt kan worden door een patiënt om bij de zorgaanbieder zelf of een externe repository een vragenlijst op te halen. De patiënt kan dan de vragenlijst invullen en terugsturen naar de zorgaanbieder. Onderstaande tabel geeft de rollen weer.

{| class="wikitable" "cellpadding="10" width="100%"
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:top;"|Wil vragenlijsten in een persoonlijke gezondheidsomgeving kunnen invullen en de antwoorden terugsturen.
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Wil dat patiënten vragenlijsten invullen en de antwoorden aan de zorgaanbieder sturen.
|}

Onderstaande afbeelding toont de verschillende activiteiten uit de procesbeschrijving die door de bedrijfsrollen worden uitgevoerd in samenhang met de beschreven use cases.

[[Image:Activity_Diagram_-_Vragenlijsten.png|Activiteitendiagram vragenlijsten]]

<font size = "1">'''Activiteitendiagram vragenlijsten'''</font>

==Use case: Raadplegen vragenlijstverwijzing ==
=== Doel en relevantie ===
Het voor patiënten mogelijk maken om in een PGO een vragenlijst te ontvangen en in te vullen.
=== Domein ===
Vragenlijsten in het domein van zorgaanbieders en patiënten.

=== Context ===
Het gaat om het elektronisch en gestructureerd aanbieden c.q. beschikbaarstellen van vragenlijsten door zorgaanbieders vanuit een zorgaanbiederssysteem (XIS) naar een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO).
Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.
De beschrijving is infrastructuur-onafhankelijk.

=== Informatie ===
De informatie-elementen voor raadplegen en beschikbaarstellen vragenlijstverwijzing staan in [https://decor.nictiz.nl/pub/vragenlijsten/ ART-DECOR]

==== Raadplegen vragenlijstverwijzing ====
Er zijn geen specifieke filtermogelijkheden (query parameters) gedefinieerd voor de raadplegen vragenlijstverwijzing.

==== Beschikbaarstellen vragenlijstverwijzing ====
Informatie-elementen in Vragenlijsten staan hieronder. Deze informatie is ook in een nieuw tabblad te openen.

<html>
<iframe width="100%" height="400" src=https://decor.nictiz.nl/pub/vragenlijsten/vl-html-20200403T135608/tr-2.16.840.1.113883.2.4.3.11.60.56.4.248-2019-04-11T132707.html frameborder="0" align="middle"></iframe>
</html>

=== Bedrijfsrollen ===
Onderstaande afbeelding toont de verschillende activiteiten uit de procesbeschrijving die door de bedrijfsrollen worden uitgevoerd in samenhang met de beschreven use cases.

[[Image:Activity_Diagram_-_Vragenlijsten.png|Activiteitendiagram vragenlijsten]]

=== Procesbeschrijving ===
==== Patient Journey – Jelmer Postma ====
Een voorbeeldsituatie die de meerwaarde van vragenlijsten met een PGO schetst is de patient journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Jelmer_Postma_MedMij.pdf Jelmer Postma].
<blockquote>Jelmer wordt door zijn GZ-psycholoog gevraagd een vragenlijst te vullen over zijn stemmingen gedurende een dag. De psycholoog spreekt met Jelmer af dat hij deze zal invullen voorafgaand aan het volgende consult. Een patiënt als Jelmer Postma kan via zijn PGO een vragenlijst van een zorgverlener ontvangen. Hij vult deze op een later moment in en stuurt de antwoorden volgens afspraak weer terug naar de zorgaanbieder. Bij het volgende consult kan de GZ-psycholoog samen met Jelmer de vragenlijst doornemen.</blockquote>

==== Proces ====
Deze use case ondersteunt geen workflow tussen zorgaanbieder en patiënt. Eventuele procesafspraken zijn dus geen onderdeel van deze use case. Voordat het proces start heeft een medewerker van de zorgaanbieder met een patiënt afgesproken om op of voor een bepaald moment een vragenlijst in te vullen. Het stuk van het proces waar het in deze use case om gaat is:
* Een zorgaanbieder (XIS) stelt de vragenlijstverwijzing beschikbaar.
Het resultaat is dat de patiënt (PGO) de beschikking over een verwijzing waarmee die vervolgens de relevante vragenlijst kan ophalen.

Deze paragraaf vervolgt met een beschrijving van precondities, processtappen, en post condities.

===== Preconditie =====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van vragenlijsten tussen zijn PGO en het betreffende XIS.
De patiënt en zorgaanbieder hebben onderling procesafspraken gemaakt over het invullen van de vragenlijst.
Het XIS van de zorgaanbieder is in staat vragenlijstverwijzingen specifiek beschikbaar te stellen aan een patiënt en vervolgens de antwoorden weer te ontvangen van de patiënt via zijn PGO.
De XIS is in staat de betreffende vragenlijst beschikbaar te stellen aan raadplegers.

===== Processtappen =====
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Stap
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 01
| style="background-color: white;"| Zorgaanbieder wijst een bepaalde vragenlijst toe aan patiënt (in het XIS)
|-
| style="background-color: white;"| 02
| style="background-color: white;"| PGO bevraagt het XIS om deze toewijzing te ontvangen in de vorm van een verwijzing naar een vragenlijst. Deze verwijzing is een URI waar het PGO de daadwerkelijke vragenlijst kan ophalen.
|}

===== Postconditie =====
Patiënt heeft de beschikking over de vragenlijst in zijn PGO en kan de vragen daar gaan invullen.

=== Systemen & Systeemrollen ===
Zowel de patiënt als de zorgaanbieder maken ieder gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om vragenlijsten en antwoorden tussen de persoon en de zorgaanbieder.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Systeemrolcode
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| Vragenlijstverwijzing raadplegend systeem
| style="background-color: white;"| VL-{{VersieInfo|Vragenlijsten|release=V2019.01}}-QLR-FHIR
| style="background-color: white;"| Raadplegen van verwijzing naar vragenlijst door patiënt
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Vragenlijstverwijzing beschikbaarstellend systeem
| style="background-color: white;"| VL-{{VersieInfo|Vragenlijsten|release=V2019.01}}-QLB-FHIR
| style="background-color: white;"| Beschikbaarstellen van verwijzing naar vragenlijst voor PGO
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_Vragenlijsten_(Raadplegen).png|Componenten diagram Vragenlijstverwijzing en Vragenlijst raadplegen]]

<font size = "1">'''Componenten diagram Vragenlijsten raadplegen'''</font>

De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.

=== Transacties & Transactiegroepen ===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transactiegroep'''
! style="text-align:left;"| '''Transactie'''
! style="text-align:left;"| '''Systeemrolcode'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|Verwijzing naar vragenlijsten(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen verwijzing naar vragenlijst
|style="background-color: white;vertical-align:top;"|VL-{{VersieInfo|Vragenlijsten|release=V2019.01}}-QLR-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub-2019.01_FHIR_Questionnaire_and_Questionnaire_Response_(Vragenlijsten)|Questionnaire(response) in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen verwijzing naar vragenlijst
|style="background-color: white;vertical-align:top;"|VL-{{VersieInfo|Vragenlijsten|release=V2019.01}}-QLB-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:Use_Case_Diagram_-_Vragenlijsten_(Raadplegen).png|Use case diagram Sturen Beelden]]

<font size = "1">'''Use case diagram raadplegen vragenlijstverwijzing en raadplegen vragenlijst</font>

==Use case: Raadplegen vragenlijst ==
{{NoteBox|Deze uitwisseling kan op dit moment niet via het MedMij Afsprakenstelsel / het MedMij-netwerk plaatsvinden.}}
=== Doel en relevantie ===
Het voor patiënten mogelijk maken om in een PGO een vragenlijst te ontvangen en in te vullen. Het vervolgens weer terugsturen van de antwoorden staat beschreven in een aparte use case: [[MedMij:Vprepub-2019.01_OntwerpVragenlijsten#Use_case:_Sturen_vragenlijstantwoorden|sturen vragenlijstantwoorden]].

=== Domein ===
Vragenlijsten in het domein van zorgaanbieders en patiënten.

=== Context ===
Het gaat om het elektronisch en gestructureerd aanbieden c.q. beschikbaarstellen van vragenlijsten door zorgaanbieders vanuit een zorgaanbiederssysteem (XIS) naar een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO).
Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.
De beschrijving is infrastructuur-onafhankelijk.

=== Informatie ===
De informatie-elementen voor raadplegen en beschikbaarstellen vragenlijst staan in [https://decor.nictiz.nl/pub/vragenlijsten/ ART-DECOR]

Deze informatie-elementen ondersteunen de volgende aspecten:
* Het al dan niet tonen van bepaalde vragen in de vragenlijst afhankelijk van de antwoorden:
** Hierbij gaat het er om dat sommige vragen overgeslagen worden op basis van een antwoord op een andere vraag (sprongvragen). De dataset kent hiervoor het element 'enableWhen'
* Specificeren van verschillende type vragen:
** Het gaat dan om bijvoorbeeld keuzelijst met één of meerdere selecties, vrije tekst, combinaties hiervan, schalen, et cetera
* Vragenlijsten kunnen ook bepaalde eisen aan de weergave van vragen/antwoordopties definiëren, welke dan verplicht zijn om te volgen. Het verschillend weergegeven van vragenlijsten compromitteren de validiteit en/of vergelijkbaarheid van de vragenlijst. Denk hierbij aan:
** volgorde van antwoordopties of
** het in één keer tonen van alle antwoordopties of
** het recht onder elkaar staan van antwoordopties
** specifieke opmaak zoals '''vet'''- of ''schuin''gedrukte tekst

==== Raadplegen vragenlijst ====
Er zijn geen specifieke filtermogelijkheden (query parameters) gedefinieerd voor de raadplegen vragenlijst.

==== Beschikbaarstellen vragenlijst ====
Informatie-elementen in Vragenlijsten staan hieronder. Deze informatie is ook in een nieuw tabblad te openen.

<html>
<iframe width="100%" height="400" src=https://decor.nictiz.nl/pub/vragenlijsten/vl-html-20200403T135608/tr-2.16.840.1.113883.2.4.3.11.60.56.4.255-2019-04-11T140121.html frameborder="0" align="middle"></iframe>
</html>

=== Bedrijfsrollen ===
Onderstaande afbeelding toont de verschillende activiteiten uit de procesbeschrijving die door de bedrijfsrollen worden uitgevoerd in samenhang met de beschreven use cases.

[[Image:Activity_Diagram_-_Vragenlijsten.png|Activiteitendiagram vragenlijsten]]

=== Procesbeschrijving ===
==== Patient Journey – Jelmer Postma ====
Een voorbeeldsituatie die de meerwaarde van vragenlijsten met een PGO schetst is de patient journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Jelmer_Postma_MedMij.pdf Jelmer Postma].
<blockquote>Jelmer wordt door zijn GZ-psycholoog gevraagd een vragenlijst te vullen over zijn stemmingen gedurende een dag. De psycholoog spreekt met Jelmer af dat hij deze zal invullen voorafgaand aan het volgende consult. Een patiënt als Jelmer Postma kan via zijn PGO een vragenlijst van een zorgverlener ontvangen. Hij vult deze op een later moment in en stuurt de antwoorden volgens afspraak weer terug naar de zorgaanbieder. Bij het volgende consult kan de GZ-psycholoog samen met Jelmer de vragenlijst doornemen.</blockquote>

==== Proces ====
Deze use case ondersteunt geen workflow tussen zorgaanbieder en patiënt. Eventuele procesafspraken zijn dus geen onderdeel van deze use case.
Voordat het proces start heeft een medewerker van de zorgaanbieder met een patiënt afgesproken om op of voor een bepaald moment een vragenlijst in te vullen.

Het stuk van het proces waar het in deze use case om gaat is:
* Een zorgaanbieder stelt de vragenlijst beschikbaar (bijvoorbeeld via een vragenlijst-repository waarbij het niet relevant is of de zorgaanbieder deze repository zelf aanbiedt of gebruik maakt van een externe partij).
* De zorgaanbieder koppelt een vragenlijst aan de patiënt.
* De patiënt haalt vervolgens de relevante vragenlijst op.
Het resultaat is dat de patiënt de beschikking heeft over de vragenlijst in zijn PGO en de vragen kan gaan beantwoorden.

Deze paragraaf vervolgt met een beschrijving van precondities, processtappen, en post condities.

===== Preconditie =====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van vragenlijsten tussen zijn PGO en het betreffende XIS.
De patiënt en zorgaanbieder hebben onderling procesafspraken gemaakt over het invullen van de vragenlijst.
Het XIS van de zorgaanbieder is in staat vragenlijstverwijzingen specifiek beschikbaar te stellen aan een patiënt en vervolgens de antwoorden weer te ontvangen van de patiënt via zijn PGO.
XIS is in staat de betreffende vragenlijst beschikbaar te stellen aan raadplegers.

===== Processtappen =====
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Stap
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 01
| style="background-color: white;"| PGO heeft vanuit het XIS een verwijzing naar een vragenlijst ontvangen. Zie use case [[MedMij:Vprepub-2019.01_OntwerpVragenlijsten#Use_case:_Raadplegen_vragenlijstverwijzing|Raadplegen vragenlijstverwijzing]]
|-
| style="background-color: white;"| 02
| style="background-color: white;"| PGO haalt vervolgens de vragenlijst op (Nb. Ophalen kán plaatsvinden buiten het MedMij-Afsprakenstelsel. Als dit buiten het MedMij-afsprakenstelsel plaatsvindt, wordt dit 'niet op de persoon herleidbaar' gedaan.).
|}

===== Postconditie =====
Patiënt heeft de beschikking over de vragenlijst in zijn PGO en kan de vragen daar gaan invullen.

=== Systemen & Systeemrollen ===
{{NoteBox|Deze uitwisseling kan op dit moment niet via het MedMij Afsprakenstelsel / het MedMij-netwerk plaatsvinden.}}
Zowel de patiënt als de zorgaanbieder maken ieder gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)
Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om vragenlijsten en antwoorden tussen de persoon en de zorgaanbieder.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Systeemrolcode
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| Vragenlijst raadplegend systeem
| style="background-color: white;"| VL-{{VersieInfo|Vragenlijsten|release=V2019.01}}-QER-FHIR
| style="background-color: white;"| Raadplegen van vragenlijst door PGO (zonder dat het herleidbaar is op de persoon)
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Vragenlijst beschikbaarstellend systeem
| style="background-color: white;"| VL-{{VersieInfo|Vragenlijsten|release=V2019.01}}-QEB-FHIR
| style="background-color: white;"| Beschikbaarstellen van vragenlijst voor PGO (zonder dat het herleidbaar is op de persoon)
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_Vragenlijsten_(Raadplegen).png|Componenten diagram Vragenlijstverwijzing en Vragenlijst raadplegen]]

<font size = "1">'''Componenten diagram Vragenlijsten raadplegen'''</font>

De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.

=== Transacties & Transactiegroepen ===
{{NoteBox|Deze uitwisseling kan op dit moment niet via het MedMij Afsprakenstelsel / het MedMij-netwerk plaatsvinden.}}
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transactiegroep'''
! style="text-align:left;"| '''Transactie'''
! style="text-align:left;"| '''Systeemrolcode'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|Vragenlijsten(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen vragenlijst
|style="background-color: white;vertical-align:top;"|VL-{{VersieInfo|Vragenlijsten|release=V2019.01}}-QER-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub-2019.01_FHIR_Questionnaire_and_Questionnaire_Response_(Vragenlijsten)|Questionnaire(response) in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen vragenlijst
|style="background-color: white;vertical-align:top;"|VL-{{VersieInfo|Vragenlijsten|release=V2019.01}}-QEB-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder

|}

===Use case diagram===
[[Bestand:Use_Case_Diagram_-_Vragenlijsten_(Raadplegen).png|Use case diagram Sturen Beelden]]

<font size = "1">'''Use case diagram raadplegen vragenlijstverwijzing en raadplegen vragenlijst</font>

==Use case: Sturen vragenlijstantwoorden ==
=== Doel en relevantie ===
Het voor patiënten mogelijk maken om vanuit een PGO de antwoorden op een vragenlijst terug te sturen naar de zorgaanbieder.

=== Domein ===
Antwoorden op vragenlijsten in het domein van zorgaanbieders en patiënten.

=== Context ===
Het gaat om het elektronisch en gestructureerd sturen van antwoorden op vragenlijsten door PGO-gebruiker aan zorgaanbieders vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar zorgaanbiederssysteem (XIS). Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.
De beschrijving is infrastructuur-onafhankelijk.

=== Informatie ===
De informatie-elementen voor sturen en ontvangen vragenlijstantwoorden staan in [https://decor.nictiz.nl/pub/vragenlijsten/ ART-DECOR]

Informatie-elementen in Vragenlijstantwoorden staan hieronder. Deze informatie is ook in een nieuw tabblad te openen.

<html>
<iframe width="100%" height="500" src=https://decor.nictiz.nl/pub/vragenlijsten/vl-html-20200403T135608/tr-2.16.840.1.113883.2.4.3.11.60.56.4.263-2020-04-01T135355.html frameborder="0" align="middle"></iframe>
</html>

=== Bedrijfsrollen ===
Onderstaande afbeelding toont de verschillende activiteiten uit de procesbeschrijving die door de bedrijfsrollen worden uitgevoerd in samenhang met de hieronder beschreven use cases.

[[Image:Activity_Diagram_-_Vragenlijsten.png|Activiteitendiagram vragenlijsten]]

=== Procesbeschrijving ===
==== Patient Journey – Jelmer Postma ====
Een voorbeeldsituatie die de meerwaarde van vragenlijsten met een PGO schetst is de patient journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Jelmer_Postma_MedMij.pdf Jelmer Postma].
<blockquote>Jelmer wordt door zijn GZ-psycholoog gevraagd een vragenlijst te vullen over zijn stemmingen gedurende een dag. De psycholoog spreekt met Jelmer af dat hij deze zal invullen voorafgaand aan het volgende consult. Een patiënt als Jelmer Postma kan via zijn PGO een vragenlijst van een zorgverlener ontvangen. Hij vult deze op een later moment in en stuurt de antwoorden volgens afspraak weer terug naar de zorgaanbieder. Bij het volgende consult kan de GZ-psycholoog samen met Jelmer de vragenlijst doornemen.</blockquote>

==== Proces ====
Deze use case ondersteunt geen workflow tussen zorgaanbieder en patiënt. Eventuele procesafspraken zijn dus geen onderdeel van deze use case.
Voordat het proces start heeft een medewerker van de zorgaanbieder met een patiënt afgesproken om op of voor een bepaald moment een vragenlijst in te vullen. Ook heeft de patiënt de vragenlijst opgehaald zoals beschreven in [[MedMij:Vprepub-2019.01_OntwerpVragenlijsten#Use_case_1:_Raadplegen_vragenlijst|de use case raadplegen vragenlijst]].

Het stuk van het proces waar het in deze use case om gaat is:
* De patiënt beantwoordt de vragenlijst in zijn PGO en stuurt de antwoorden terug naar de zorgaanbieder.

Afhankelijk van het doel van de vragenlijst kan een medewerker van de zorgaanbieder de vragenlijst met de patiënt op een later moment bespreken.

Deze paragraaf vervolgt met een beschrijving van precondities, proces stappen, en post condities.

===== Preconditie =====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van (antwoorden op) vragenlijsten tussen zijn PGO en het betreffende XIS.
De patiënt en zorgaanbieder hebben onderling procesafspraken gemaakt over het invullen van de vragenlijst. Het PGO heeft een vragenlijst opgehaald.

===== Proces stappen =====
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Stap
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 01
| style="background-color: white;"| PGO stelt de patiënt in staat de vragenlijsten in te vullen
|-
| style="background-color: white;"| 02
| style="background-color: white;"| Patiënt beantwoordt de vult de vragenlijsten in
|-
| style="background-color: white;"| 03
| style="background-color: white;"| Patiënt bepaalt wanneer het invullen gereed is
|-
| style="background-color: white;"| 04
| style="background-color: white;"| PGO stuurt de antwoorden terug naar het XIS
|}

===== Postconditie =====
De zorgaanbieder kan de vragenlijst met antwoorden inzien in het XIS.
De patiënt en zorgaanbieder kunnen hierover in overleg.

=== Systemen & Systeemrollen ===
Zowel de persoon als de zorgaanbieder maken gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om vragenlijsten en antwoorden tussen de persoon en de zorgaanbieder.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Systeemrolcode
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| Antwoorden op vragenlijst sturend systeem
| style="background-color: white;"| VL-{{VersieInfo|Vragenlijsten|release=V2019.01}}-QRS-FHIR
| style="background-color: white;"| Sturen van antwoorden op de vragenlijst aan zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Antwoorden op vragenlijst ontvangend systeem
| style="background-color: white;"| VL-{{VersieInfo|Vragenlijsten|release=V2019.01}}-QRO-FHIR
| style="background-color: white;"| Ontvangen van antwoorden op de vragenlijst van de patiënt
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_Vragenlijsten_(Sturen).png|Componenten diagram Vragenlijstverwijzing en Vragenlijst sturen]]

<font size = "1">'''Componenten diagram Vragenlijsten sturen'''</font>

De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.

=== Transacties & Transactiegroepen ===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transactiegroep'''
! style="text-align:left;"| '''Transactie'''
! style="text-align:left;"| '''Systeemrolcode'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|Antwoorden op vragenlijst (PUSH)
|style="background-color: white;vertical-align:top;"|Sturen antwoorden op vragenlijst
|style="background-color: white;vertical-align:top;"|VL-{{VersieInfo|Vragenlijsten|release=V2019.01}}-QRS-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub-2019.01_FHIR_Questionnaire_and_Questionnaire_Response_(Vragenlijsten)|Questionnaire(response) in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Ontvangen antwoorden op vragenlijst
|style="background-color: white;vertical-align:top;"|VL-{{VersieInfo|Vragenlijsten|release=V2019.01}}-QRO-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang met [[MedMij:Vprepub-2019.01_OntwerpVragenlijsten#Use_case_1:_Raadplegen_vragenlijst|de use case raadplegen vragenlijsten]].

[[Bestand:Use_Case_Diagram_-_Vragenlijsten_(Sturen).png|Use case diagram Sturen Vragenlijsten]]

<font size = "1">'''Use case diagram Vragenlijsten</font>

=Functionaliteit=
Er zijn geen aanwijzingen/eisen voor functionaliteit van de systemen.

=Verantwoordelijkheid voor informatie=
Er zijn geen specifieke toevoegingen over verantwoordelijkheden voor informatie.

=Afschermen van gegevens=
Er zijn geen afspraken over het afschermen van gegevens.

=Infrastructuur=
Er zijn geen afspraken over een specifieke infrastructuur waarop de informatie wordt uitgewisseld.

=Referenties=

{| class="wikitable" "cellpadding="10" width="100%"
!style="text-align:left;"|Auteur(s)
!style="text-align:left;"|Titel
!style="text-align:left;"|Versie
!style="text-align:left;"|Datum
!style="text-align:left;"|Bron
!style="text-align:left;"|Organisatie
|-
| style="background-color: white;"| <span id="sdc">-</span>
| style="background-color: white;"| Structured Data Capture (SDC)
| style="background-color: white;"| 2.0 (STU2)
| style="background-color: white;"| 2017-04-21
| style="background-color: white;"| https://hl7.org/fhir/us/sdc/STU2/
| style="background-color: white;"| U.S. Office of the National Coordinator (ONC)'s Standards and Infrastructure (S & I) Framework
|}
<font size = "1">'''Referenties</font>

=Release notes=

In onderstaande tabel staan de wijzigingen voor deze informatiestandaard. Zie de [[MedMij:Vdraft_Ontwerpen#Release_Notes|Ontwerpen landingspagina]] voor wijzigingen die op alle informatiestandaarden van toepassing zijn.
{| class="wikitable" "cellpadding="10" style="background-color: white;"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving
|-
{{ReleaseNotes|package=2019.01 - Juni 2022|release=1.1.2|issues=1|MM-3099}}
{{ReleaseNotes|package=2019.01 - Maart 2022|release=1.1.0|issues=1|MM-2983}}
{{ReleaseNotes|package=2019.01 - Februari 2022|release=1.0.20|issues=4|MM-2787|MM-2663|MM-2659|MM-2858}}
{{ReleaseNotes|package=2019.01 - Oktober 2021|release=1.0.16|issues=1|MM-2422}}
{{ReleaseNotes|package=2019.01 - Februari 2021|release=1.0.10|issues=1|MM-1879}}
{{ReleaseNotes|package=2019.01 - Februari 2021|release=1.0.9|issues=4|MM-1765|MM-1635|MM-1634|MM-1587}}
{{ReleaseNotes|package=2019.01 - September 2020|release=1.0.5|issues=1|MM-1353}}
{{ReleaseNotes|package=2019.01 - Mei 2020|release=1.0.4|issues=2|MM-1085|MM-1084}}

MedMij:Vprepub-2019.01 OntwerpVragenlijsten

2022-07-05T08:02:13Z

Eduard de Rijcke: Relase notes van Patchrelease Juni 2022 toegevoegd

FHIR:Vissue-MM-2759 Search result examples

2022-06-24T08:21:28Z

Eduard de Rijcke: MM-2759 Small JSON corrections at the second example

{{IssuePaginaWaarschuwing|MM-2759|FHIR:V1.0_Search_result_examples}}
__NOINDEX__
__NUMBEREDHEADINGS__
=Search result examples=
This page provides guidance on how a server could return search results. Examples are provided in XML format but could have been in JSON format as well. Please note: these examples are not considered to be part of the normative content of the implementation guide.

=Examples=
==Server supports the read operation for all resources==
{| class="wikitable" style="width: 100%;"
|-
| '''Scenario'''
| The server offers read support for all resources that it has, meaning that each resource has a stable {{fhir|Resource.id}} and is accessible through a stable RESTful URL.
|-
| '''Request'''
| <pre> GET [base]/Observation?code=http://loinc.org|85354-9</pre>
|-
| '''Response'''
|
* Searchset Bundle containing 1 Observation resource.
* References from the Observation resource are to other resources on the server.
|-
| '''Response content'''
(click to expand)
|
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-read_operations_xml"><span class="mw-customtoggle-read_operations_xml">▶ Response - XML</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="xml" highlight="">
<Bundle xmlns="http://hl7.org/fhir" >
...


<type value="searchset"/>


<total value="1"/>


<link>
<relation value="self"/>
<url value="https://example-server.nl/fhir/Observation?code=http://loinc.org|85354-9"/>
</link>

<entry>

<fullUrl value="https://example-server.nl/fhir/Observation/observation-123"/>

<resource>
<Observation>


<id value="observation-123" />
...
<subject>

<reference value="Patient/patient-123" />
</subject>
...
</Observation>
</resource>
<search>

<mode value="match"/>
</search>
</entry>
</Bundle>
</syntaxhighlight>
</div></div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-read_operations_json"><span class="mw-customtoggle-read_operations_json">▶ Response - JSON</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="json" highlight="">
{
"resourceType": "Bundle",
...

//Bundle.type should be set to 'searchset'
"type": "searchset",

// Bundle.total is set to the number of matches for the request
"total": 1,

// The 'self link' shows the search request as how it was understood by the server
"link": [
{
"relation": "self",
"url": "https://example-server.nl/fhir/Observation?code=http://loinc.org|85354-9"
}
],

"entry": [
{
// The Observation resource is accessible through a RESTful URL, which is used for the fullUrl
"fullUrl": "https://example-server.nl/fhir/Observation/observation-123",

"resource": {
"resourceType": "Observation",

// The Resource.id MUST be populated when it is accessible using a RESTful URL.
"id": "observation-123",
...
// The Patient resource resides on the same server and can be referenced using a relative URL.
// An absolute URL could be used in this case as well.
"subject": {
"reference": "Patient/patient-123"
}
},
"search": {
// Resources that match the search request have mode set to 'match'
"mode": "match"
}
}
]
}
</syntaxhighlight>
</div></div>
|}

==Server doesn't support read operations==
{| class="wikitable" style="width: 100%;"
|-
| '''Scenario'''
| The server supports doesn't support the read operation, for example because it's a FHIR facade that is unable to link a stable id to a certain entry in the underlying database. For this reason, it only supports searching for data.
|-
| '''Request'''
| <pre> GET [base]/Observation?code=http://loinc.org|85354-9</pre>
|-
| '''Response'''
|
* Searchset Bundle containing 1 Observation resource and all referenced resources.
* References from the Observation resource are to other resources within the Bundle.
* All resources in the Bundle are identified using a temporary {{fhir|fullUrl}}.
|-
| '''Response content'''
(click to expand)
|
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-no_read_operations_xml"><span class="mw-customtoggle-no_read_operations_xml">▶ Response - XML</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="xml" highlight="">
<Bundle xmlns="http://hl7.org/fhir">
...


<type value="searchset"/>


<total value="1"/>


<link>
<relation value="self"/>
<url value="https://example-server.nl/fhir/Observation?code=http://loinc.org|85354-9"/>
</link>


<entry>

<fullUrl value="urn:uuid:69aefd96-b37d-4323-866b-762536c03375">
<resource>
<Patient>

...
</Patient>
</resource>
<search>

<mode value="include" />
</search>
</entry>

<entry>

<fullUrl value="urn:uuid:799c5790-f2aa-4045-8c19-a0d54773a059"/>
<resource>
<Observation>
...
<subject>

<reference value="urn:uuid:69aefd96-b37d-4323-866b-762536c03375" />
</subject>
...
</Observation>
</resource>
<search>

<mode value="match"/>
</search>
</entry>
</Bundle>
</syntaxhighlight>
</div></div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-no_read_operations_json"><span class="mw-customtoggle-no_read_operations_json">▶ Response - JSON</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="json" highlight="">
{
"resourceType": "Bundle",
...

// Bundle.type should be set to 'searchset'
"type": "searchset",

// Bundle.total is still set to the number of _matches_, even though more resources are included in the Bundle.
"total": "1",

// The "self link" reflects the search as it was understood by the server
"link": [
{
"relation": "self",
"url": "https://example-server.nl/fhir/Observation?code=http://loinc.org|85354-9"
}
],
// The server is unable to offer a stable RESTful URL to the Patient resource, but it needs to satisfy the requirement
// that all resources are resolvable. Therefore, it includes the referenced Patient resource in the searchset Bundle.
"entry": [
{
// Since the server is unable to produce a RESTful URL for reading the resource, so it uses an ephemeral fullUrl so that other
// resources in the Bundle can refer to it.
"fullUrl": "urn:uuid:69aefd96-b37d-4323-866b-762536c03375",
"resource": {
"resourceType": "Patient",
// When returning a resource, Resource.id SHOULD be populated. When no stable .id is available, the temporary UUID, without the urn:uuid part, MAY be used instead.
// However, it is recommended in this case to simply leave out the Resource.id
// "id": "69aefd96-b37d-4323-866b-762536c03375",
...
},
"search": {
// When resources are additionally included in the searchset Bundle while there's no direct match, .search.mode should be set to 'include'.
"mode": "include"
}
},
{
// Note that the fullUrl MUST be populated, even if this resource is not referred by any other resource within the Bundle.
// Since the server is unable to produce a RESTful URL for reading the Observation resource, it creates an ephemeral fullUrl
// for this resource as well.
"fullUrl": "urn:uuid:799c5790-f2aa-4045-8c19-a0d54773a059",
"resource": {
"resourceType": "Observation",
...
"subject": {
// The server doesn't support read for the Patient resource, so it's included in the Bundle using an ephemeral fullUrl.
"reference": "urn:uuid:69aefd96-b37d-4323-866b-762536c03375"
},
...
}
}
],
"search": {
// Resources that match the search request have mode set to 'match'
"mode": "match"
}
]
}
</syntaxhighlight>
</div></div>
|}

==Server supports read for some resources (hypothetical)==
{| class="wikitable" style="width: 100%;"
|-
| '''Scenario'''
| The server is able to produce a stable RESTful URL for the Patient resource, but not for the Observation resource. This is a highly hypothetical situation to demonstrate the boundaries of the reference resolving mechanism in FHIR Bundles.
|-
| '''Request'''
| <pre> GET [base]/Observation?code=http://loinc.org|85354-9</pre>
|-
| '''Response'''
|
* Searchset Bundle containing 1 Observation resource.
* References from the Observation resource are to other resources on the server, using an absolute URL.
* The Observation resource is identified using a temporary {{fhir|fullUrl}}.
|-
| '''Response content'''
(click to expand)
|
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-hypothetical_xml"><span class="mw-customtoggle-hypothetical_xml">▶ Response - XML</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="xml" highlight="">
<Bundle xmlns="http://hl7.org/fhir" >
...


<type value="searchset"/>


<total value="1"/>


<link>
<relation value="self"/>
<url value="https://example-server.nl/fhir/Observation?code=http://loinc.org|85354-9"/>
</link>

<entry>

<fullUrl value="urn:uuid:e07ffa10-c043-4dd6-aa52-6ac273c82da9"/>
<resource>
<Observation>
...
<subject>

-->
<reference value="http://example-server.nl/Patient/patient-123" />
</subject>
...
</Observation>
</resource>
...
</entry>
</Bundle>
</syntaxhighlight>
</div></div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-hypothetical_json"><span class="mw-customtoggle-hypothetical_json">▶ Response - JSON</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="json" highlight="">
{
"resourceType": "Bundle",
...

// Bundle.type should be set to 'searchset'
"type": "searchset",

// Bundle.total is still set to the number of _matches_, even though more resources are included
"total": "1",

// The 'self link' shows the search request as how it was understood by the server
"link": {
"relation": "self",
"url": "https://example-server.nl/fhir/Observation?code=http://loinc.org|85354-9"
}

"entry": [
{
// Since the server is unable to produce a RESTful URL for reading the Observation resource, it creates an ephemeral fullUrl
// for this resource.
// Note that the fullUrl MUST be populated, even if this resource is not referred by any other resource within the Bundle.
"fullUrl": "urn:uuid:e07ffa10-c043-4dd6-aa52-6ac273c82da9",
"resource": {
"resourceType": "Observation",
...
"subject": {
// The server supports read for the Patient resource, so an absolute URL can be used.
// Note that a relative URL is invalid in this case, because it is deemed relative to the fullUrl of the Observation resource.
// Since this fullUrl is not a RESTful URL, a relative URL cannot be resolved to an actual URL.
"reference": "http://example-server.nl/Patient/patient-123"
},
...
},
...
}
]
}
</syntaxhighlight>
</div></div>
|}

==Invalid: server doesn't support read operations and uses contained resources instead==
{| class="wikitable" style="background-color: #f3d2d2; width: 100%;"
|-
| colspan="2" | {{warning|This example demonstrates how this SHOULD NOT be handled}}
|-
| '''Scenario'''
| The server supports doesn't support the read operation, for example because it's a FHIR facade that is unable to link a stable id to a certain entry in the underlying database. For this reason, it only supports searching for data.
|-
| '''Request'''
| <pre> GET [base]/Observation?code=http://loinc.org|85354-9</pre>
|-
| '''Response'''
|
* Searchset Bundle containing 1 Observation resource.
* The referenced Patient resource is contained within the Observation resource.

This approach is invalid! Resources should only be contained if they cannot have an independent existence outside of the resource containing it. This is not the case in the current situation.
|-
| '''Response content'''
(click to expand)
|
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-contained_xml"><span class="mw-customtoggle-contained_xml">▶ Response - XML</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="xml">
<Bundle xmlns="http://hl7.org/fhir" >
...
<entry>
<fullUrl value="urn:uuid:2290607c-79e8-47ed-a23e-b8c3d5f224b2"/>
<resource>
<Observation>
...
<contained>
<Patient>
<id value="patient1"/>
...
</Patient>
</contained>
...
<subject>

<reference value="#patient1" />
</subject>
...
</Observation>
</resource>
...
</entry>
</Bundle>
</syntaxhighlight>
</div></div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-contained_json"><span class="mw-customtoggle-contained_json">▶ Response - JSON</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="json">
{
"resourceType": "Bundle",
...
"entry": [
{
"fullUrl": "urn:uuid:2290607c-79e8-47ed-a23e-b8c3d5f224b2",
"resource": {
"resourceType": "Observation",
...
"contained": [
{
"resourceType": "Patient",
"id": "patient1",
...
}
],
...
"subject": {
// Wrong approach: the server is unable to offer a stable RESTful URL to the Patient resource, but it needs to
// satisfy the requirement that all resources are resolvable. Therefore, it sends the Patient resource as a contained
// resource within the Observation resource.
// Resources should only be contained if they cannot have an independent existence outside of the resource
// containing it. This is not the case in the current situation, so this approach is invalid!
"reference": "#patient1"
},
...
}
},
...
]
}
</syntaxhighlight>
</div></div>
|}

FHIR:Vissue-MM-2759 Search result examples

2022-06-24T08:10:44Z

Eduard de Rijcke: MM-2759 Small JSON corrections at the first example

{{IssuePaginaWaarschuwing|MM-2759|FHIR:V1.0_Search_result_examples}}
__NOINDEX__
__NUMBEREDHEADINGS__
=Search result examples=
This page provides guidance on how a server could return search results. Examples are provided in XML format but could have been in JSON format as well. Please note: these examples are not considered to be part of the normative content of the implementation guide.

=Examples=
==Server supports the read operation for all resources==
{| class="wikitable" style="width: 100%;"
|-
| '''Scenario'''
| The server offers read support for all resources that it has, meaning that each resource has a stable {{fhir|Resource.id}} and is accessible through a stable RESTful URL.
|-
| '''Request'''
| <pre> GET [base]/Observation?code=http://loinc.org|85354-9</pre>
|-
| '''Response'''
|
* Searchset Bundle containing 1 Observation resource.
* References from the Observation resource are to other resources on the server.
|-
| '''Response content'''
(click to expand)
|
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-read_operations_xml"><span class="mw-customtoggle-read_operations_xml">▶ Response - XML</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="xml" highlight="">
<Bundle xmlns="http://hl7.org/fhir" >
...


<type value="searchset"/>


<total value="1"/>


<link>
<relation value="self"/>
<url value="https://example-server.nl/fhir/Observation?code=http://loinc.org|85354-9"/>
</link>

<entry>

<fullUrl value="https://example-server.nl/fhir/Observation/observation-123"/>

<resource>
<Observation>


<id value="observation-123" />
...
<subject>

<reference value="Patient/patient-123" />
</subject>
...
</Observation>
</resource>
<search>

<mode value="match"/>
</search>
</entry>
</Bundle>
</syntaxhighlight>
</div></div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-read_operations_json"><span class="mw-customtoggle-read_operations_json">▶ Response - JSON</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="json" highlight="">
{
"resourceType": "Bundle",
...

//Bundle.type should be set to 'searchset'
"type": "searchset",

// Bundle.total is set to the number of matches for the request
"total": 1,

// The 'self link' shows the search request as how it was understood by the server
"link": [
{
"relation": "self",
"url": "https://example-server.nl/fhir/Observation?code=http://loinc.org|85354-9"
}
],

"entry": [
{
// The Observation resource is accessible through a RESTful URL, which is used for the fullUrl
"fullUrl": "https://example-server.nl/fhir/Observation/observation-123",

"resource": {
"resourceType": "Observation",

// The Resource.id MUST be populated when it is accessible using a RESTful URL.
"id": "observation-123",
...
// The Patient resource resides on the same server and can be referenced using a relative URL.
// An absolute URL could be used in this case as well.
"subject": {
"reference": "Patient/patient-123"
}
},
"search": {
// Resources that match the search request have mode set to 'match'
"mode": "match"
}
}
]
}
</syntaxhighlight>
</div></div>
|}

==Server doesn't support read operations==
{| class="wikitable" style="width: 100%;"
|-
| '''Scenario'''
| The server supports doesn't support the read operation, for example because it's a FHIR facade that is unable to link a stable id to a certain entry in the underlying database. For this reason, it only supports searching for data.
|-
| '''Request'''
| <pre> GET [base]/Observation?code=http://loinc.org|85354-9</pre>
|-
| '''Response'''
|
* Searchset Bundle containing 1 Observation resource and all referenced resources.
* References from the Observation resource are to other resources within the Bundle.
* All resources in the Bundle are identified using a temporary {{fhir|fullUrl}}.
|-
| '''Response content'''
(click to expand)
|
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-no_read_operations_xml"><span class="mw-customtoggle-no_read_operations_xml">▶ Response - XML</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="xml" highlight="">
<Bundle xmlns="http://hl7.org/fhir">
...


<type value="searchset"/>


<total value="1"/>


<link>
<relation value="self"/>
<url value="https://example-server.nl/fhir/Observation?code=http://loinc.org|85354-9"/>
</link>


<entry>

<fullUrl value="urn:uuid:69aefd96-b37d-4323-866b-762536c03375">
<resource>
<Patient>

...
</Patient>
</resource>
<search>

<mode value="include" />
</search>
</entry>

<entry>

<fullUrl value="urn:uuid:799c5790-f2aa-4045-8c19-a0d54773a059"/>
<resource>
<Observation>
...
<subject>

<reference value="urn:uuid:69aefd96-b37d-4323-866b-762536c03375" />
</subject>
...
</Observation>
</resource>
<search>

<mode value="match"/>
</search>
</entry>
</Bundle>
</syntaxhighlight>
</div></div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-no_read_operations_json"><span class="mw-customtoggle-no_read_operations_json">▶ Response - JSON</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="json" highlight="">
{
"resourceType": "Bundle",
...

// Bundle.type should be set to 'searchset'
"type": "searchset",

// Bundle.total is still set to the number of _matches_, even though more resources are included in the Bundle.
"total": "1",

// The "self link" reflects the search as it was understood by the server
"link": {
"relation": "self",
"url": "https://example-server.nl/fhir/Observation?code=http://loinc.org|85354-9"
}

// The server is unable to offer a stable RESTful URL to the Patient resource, but it needs to satisfy the requirement
// that all resources are resolvable. Therefore, it includes the referenced Patient resource in the searchset Bundle.
"entry": [
{
// Since the server is unable to produce a RESTful URL for reading the resource, so it uses an ephemeral fullUrl so that other
// resources in the Bundle can refer to it.
"fullUrl": "urn:uuid:69aefd96-b37d-4323-866b-762536c03375",
"resource": {
"resourceType": "Patient",
// When returning a resource, Resource.id SHOULD be populated. When no stable .id is available, the temporary UUID, without the urn:uuid part, MAY be used instead.
// However, it is recommended in this case to simply leave out the Resource.id
// "id": "69aefd96-b37d-4323-866b-762536c03375",
...
},
"search": {
// When resources are additionally included in the searchset Bundle while there's no direct match, .search.mode should be set to 'include'.
"mode": "include"
}
},
{
// Note that the fullUrl MUST be populated, even if this resource is not referred by any other resource within the Bundle.
// Since the server is unable to produce a RESTful URL for reading the Observation resource, it creates an ephemeral fullUrl
// for this resource as well.
"fullUrl": "urn:uuid:799c5790-f2aa-4045-8c19-a0d54773a059",
"resource": {
"resourceType": "Observation",
...
"subject": {
// The server doesn't support read for the Patient resource, so it's included in the Bundle using an ephemeral fullUrl.
"reference": "urn:uuid:69aefd96-b37d-4323-866b-762536c03375"
},
...
}
},
"search": {
// Resources that match the search request have mode set to 'match'
"mode": "match"
}
]
}
</syntaxhighlight>
</div></div>
|}

==Server supports read for some resources (hypothetical)==
{| class="wikitable" style="width: 100%;"
|-
| '''Scenario'''
| The server is able to produce a stable RESTful URL for the Patient resource, but not for the Observation resource. This is a highly hypothetical situation to demonstrate the boundaries of the reference resolving mechanism in FHIR Bundles.
|-
| '''Request'''
| <pre> GET [base]/Observation?code=http://loinc.org|85354-9</pre>
|-
| '''Response'''
|
* Searchset Bundle containing 1 Observation resource.
* References from the Observation resource are to other resources on the server, using an absolute URL.
* The Observation resource is identified using a temporary {{fhir|fullUrl}}.
|-
| '''Response content'''
(click to expand)
|
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-hypothetical_xml"><span class="mw-customtoggle-hypothetical_xml">▶ Response - XML</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="xml" highlight="">
<Bundle xmlns="http://hl7.org/fhir" >
...


<type value="searchset"/>


<total value="1"/>


<link>
<relation value="self"/>
<url value="https://example-server.nl/fhir/Observation?code=http://loinc.org|85354-9"/>
</link>

<entry>

<fullUrl value="urn:uuid:e07ffa10-c043-4dd6-aa52-6ac273c82da9"/>
<resource>
<Observation>
...
<subject>

-->
<reference value="http://example-server.nl/Patient/patient-123" />
</subject>
...
</Observation>
</resource>
...
</entry>
</Bundle>
</syntaxhighlight>
</div></div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-hypothetical_json"><span class="mw-customtoggle-hypothetical_json">▶ Response - JSON</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="json" highlight="">
{
"resourceType": "Bundle",
...

// Bundle.type should be set to 'searchset'
"type": "searchset",

// Bundle.total is still set to the number of _matches_, even though more resources are included
"total": "1",

// The 'self link' shows the search request as how it was understood by the server
"link": {
"relation": "self",
"url": "https://example-server.nl/fhir/Observation?code=http://loinc.org|85354-9"
}

"entry": [
{
// Since the server is unable to produce a RESTful URL for reading the Observation resource, it creates an ephemeral fullUrl
// for this resource.
// Note that the fullUrl MUST be populated, even if this resource is not referred by any other resource within the Bundle.
"fullUrl": "urn:uuid:e07ffa10-c043-4dd6-aa52-6ac273c82da9",
"resource": {
"resourceType": "Observation",
...
"subject": {
// The server supports read for the Patient resource, so an absolute URL can be used.
// Note that a relative URL is invalid in this case, because it is deemed relative to the fullUrl of the Observation resource.
// Since this fullUrl is not a RESTful URL, a relative URL cannot be resolved to an actual URL.
"reference": "http://example-server.nl/Patient/patient-123"
},
...
},
...
}
]
}
</syntaxhighlight>
</div></div>
|}

==Invalid: server doesn't support read operations and uses contained resources instead==
{| class="wikitable" style="background-color: #f3d2d2; width: 100%;"
|-
| colspan="2" | {{warning|This example demonstrates how this SHOULD NOT be handled}}
|-
| '''Scenario'''
| The server supports doesn't support the read operation, for example because it's a FHIR facade that is unable to link a stable id to a certain entry in the underlying database. For this reason, it only supports searching for data.
|-
| '''Request'''
| <pre> GET [base]/Observation?code=http://loinc.org|85354-9</pre>
|-
| '''Response'''
|
* Searchset Bundle containing 1 Observation resource.
* The referenced Patient resource is contained within the Observation resource.

This approach is invalid! Resources should only be contained if they cannot have an independent existence outside of the resource containing it. This is not the case in the current situation.
|-
| '''Response content'''
(click to expand)
|
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-contained_xml"><span class="mw-customtoggle-contained_xml">▶ Response - XML</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="xml">
<Bundle xmlns="http://hl7.org/fhir" >
...
<entry>
<fullUrl value="urn:uuid:2290607c-79e8-47ed-a23e-b8c3d5f224b2"/>
<resource>
<Observation>
...
<contained>
<Patient>
<id value="patient1"/>
...
</Patient>
</contained>
...
<subject>

<reference value="#patient1" />
</subject>
...
</Observation>
</resource>
...
</entry>
</Bundle>
</syntaxhighlight>
</div></div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-contained_json"><span class="mw-customtoggle-contained_json">▶ Response - JSON</span>
<div class="mw-collapsible-content">
<syntaxhighlight lang="json">
{
"resourceType": "Bundle",
...
"entry": [
{
"fullUrl": "urn:uuid:2290607c-79e8-47ed-a23e-b8c3d5f224b2",
"resource": {
"resourceType": "Observation",
...
"contained": [
{
"resourceType": "Patient",
"id": "patient1",
...
}
],
...
"subject": {
// Wrong approach: the server is unable to offer a stable RESTful URL to the Patient resource, but it needs to
// satisfy the requirement that all resources are resolvable. Therefore, it sends the Patient resource as a contained
// resource within the Observation resource.
// Resources should only be contained if they cannot have an independent existence outside of the resource
// containing it. This is not the case in the current situation, so this approach is invalid!
"reference": "#patient1"
},
...
}
},
...
]
}
</syntaxhighlight>
</div></div>
|}

MedMij:V2020.01/FHIR eAfspraak-LocationExample

2022-05-02T08:48:24Z

Eduard de Rijcke: MM-2714 Example added when the Location isn't supported at eAfspraak

__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Example: Location as forwarder}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

If a Location is not registered as separate data in relation to Organization data at the source system (especially at General Practitioner Systems (Huisartsen Informatie Systeem)), a Location resource with minimal data should be constructed as a forwarder to the Organization resource where the Appointment will take place, in the following way:

<syntaxhighlight lang="xml">
<Location>
<id value="locationresourceid" />
<meta>
<profile value="http://fhir.nl/fhir/StructureDefinition/nl-core-location" />
</meta>
<name value="Aesculaap" />
<managingOrganization>
<reference value="Organization/organizationresourceid" />
<display value="Aesculaap" />
</managingOrganization>
</Location>
</syntaxhighlight>

MedMij:Vprepub-2020.01/FHIR eAfspraak-LocationExample

2022-05-02T08:48:24Z

Eduard de Rijcke: MM-2714 Example added when the Location isn't supported at eAfspraak

MedMij:V2020.01/FHIR eAfspraak

2022-05-02T08:17:56Z

Eduard de Rijcke: MM-2714 Instructions added when the Location isn't supported at eAfspraak

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide - eAfspraak {{VersieInfo|eAfspraak}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:EAfspraak_icoon_zonder_tekst.png |link=|links |87px|eAfspraak]]
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpeAfspraken|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
This page describes how a patient can manage his health care related appointments in a MedMij context using the HL7 FHIR Standard. Initially, this guide will contain information on how to request existing appointment information. Guidance on how to create, update, or cancel appointments will be available here as well at a later stage.
The functional requirements for this use case can be found in the [[MedMij:Vprepub-2020.01/Ontwerpen|functional design]].

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

=Use case: retrieve appointments=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |128px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The goal of this use case is to give patients an overview of their appointments with all healthcare providers. The appointment information that is shared with the patient will contain start and end date/time, location, type of appointment, patient instructions, health care professionals present. Below is described how a PHR can retrieve this information and how a XIS should make this information available.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request appointments from the XIS
|-
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves appointments to the PHR
|}

==Invocations==
===Client - PHR===

====Search for appointments ====
The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Appointment endpoint. This search query URL is configurable by the PHR and has the following format:

<pre>GET [base]/Appointment?date=[date]</pre>

The PHR may use, and the XIS shall be capable of processing, the following parameters to configure the search query:
{| class="wikitable"
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/appointment.html#search <code>date</code>]
| date
| Appointment date/time based on '''start''' date/time.
| Retrieve appointments with a start date/time from 01-01-2018 onwards:
<pre>GET [base]/Appointment?date=gt2017-12-31</pre>
Retrieve appointments with start date/time from 01-01-2018 until 01-03-2018:
<pre>GET [base]/Appointment?date=ge2018-01-01&date=lt2018-03-01</pre>
|-
|}

===Server - XIS===
The returned data to the PHR should conform to the HCIMs and their associate profiles listed in the table below.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.eafspraak|v1Min=1.0.0|p2=nictiz.fhir.nl.stu3.zib2017|v2Min=2.0.0}}

{| class="wikitable" width="1400px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|Name NL||Name EN||FHIR Resource||URL profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patient
| #Zib Patient|Patient
| Patient
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="2" | Zorgverlener
| rowspan="2" | HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| PractitionerRole
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="2" | Zorgaanbieder
| rowspan="2" | HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
|-
| Location
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-location|nictiz.fhir.nl.stu3.zib2017}}
|-
| Afspraak
| Appointment
| Appointment
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment|nictiz.fhir.nl.stu3.eafspraak}}
|-
<span id="LocationNotSuporrted"></span>{{NoteBox|If a Location is not registered as separate data in relation to Organization data at the source system (especially at General Practitioner Systems (Huisartsen Informatie Systeem)), a Location resource with minimal data should be constructed as a forwarder to the Organization resource where the Appointment will take place ([[MedMij:Vprepub-2020.01/FHIR_eAfspraak-LocationExample|example]]).}}
|}

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpeAfspraak#Release_notes| functional design page]].

MedMij:Vprepub-2020.01/FHIR eAfspraak

2022-05-02T08:17:56Z

Eduard de Rijcke: MM-2714 Instructions added when the Location isn't supported at eAfspraak

MedMij:V2020.01/FHIR GGZ

2022-03-25T15:57:30Z

Eduard de Rijcke: MM-3011 Strikethrough the FreedomRestrictingMeasures at the profile list and added an explanation

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide basic GGZ data {{VersieInfo|BgGGZ}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:MedMij-GGZ-63.png |link=|links|80px|Use case GGZ|GGZ]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpGGZ|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
The page describes the FHIR requirements for exchanging GGZ information between the patients and healthcare providers in the context of MedMij.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Actors
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/ggz-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| FHIR Client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/ggz-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| FHIR Server requirements
|}

=Boundaries and Relationships=
The GGZ use case has similarities and differences with other use cases such as the BgZ, Medication Process, Vital Signs, GP Patient Data and Lab Results. These use cases use much of the same HCIM based FHIR profiles for exchanging information. Wherever possible every attempt is made to re-use the profiles as used in the BgZ. The GGZ use case also has unique profiles compared to the aforementioned use cases. In addition, it has a CareTeam profile without an underlying HCIM.
A second thing to note is that while the selection criteria of certain sections like procedure do not match with the BgZ or other use cases, this does not affect the profiles in use. For example, it is irrelevant for the response profile for procedures if you request ' surgical procedures' or 'every procedure'.

=Use case: retrieve GGZ information=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to MedMij Afsprakenstelsel]]

{{FHIR-IG-Afsprakenstelsel-Note}}

===PHR: request message===
The PHR system requests the patients GGZ information using individual [https://www.hl7.org/fhir/stu3/search.html search] interactions. The BgGGZ consists of multiple FHIR resources with certain constraints. To obtain the patient's BgGGZ, the client can use multiple individual search operations based on specified search queries. The interactions are performed by an HTTP GET as shown:

<code>GET [base]/[type]{?[parameters]}</code>

The table below shows in the first three columns the HCIM name in Dutch, in English and what HCIM content is requested. The last column shows the FHIR search queries to obtain this information. These queries and expected responses are based on profiles listed in [[#List_of_profiles|this section]].

{| class="wikitable" style="horizontal-align: right"

!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | HCIM NL
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | HCIM EN
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Content
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Search URL<ref>See [[MedMij:Vprepub-2020.01/FHIR_IG#Search_URLs_and_search_parameters|Search URLs and search parameters]] for the interpretation of these search URLs</ref>
|-
| Patient
| Patient
| Identification, birthdate, gender, deceasedindicator, contact details, marital status, legal status, and general practitioner (practitioner or organization)
| <pre>GET [base]/Patient?_include=Patient:general-practitioner</pre>
|-
| BurgerlijkeStaat
| MaritalStatus
| Known marital status
| style="font-style:italic;" | see Patient
|-
| Betaler
| Payer
| Insurance information
| <pre>GET [base]/Coverage?_include=Coverage:payor:Patient&_include=Coverage:payor:Organization</pre>
|-
| BehandelAanwijzing
| TreatmentDirective
| All known treatment directives
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105</pre>
|-
| Wilsverklaring
| AdvanceDirective
| All known advance directives
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11341000146107</pre>
|-
| JuridischeStatus
| LegalStatus
| Known legal status
| style="font-style:italic;" | see Patient and FreedomRestrictingMeasures procedure
|-
| VrijheidbeperkendeMaatregelen
| FreedomRestrictingMeasures
| All known freedom restricting measures
| ''see Procedure''
<span id="FunctionalOrMentalStatusRemark">{{IssueBox|Due to legislation (the 'Wet verplichte ggz' (Wvggz)) HCIM FreedomRestrictingMeasures-v3.1 (release 2017) has become obsolete. Therefore, this version of the BgGGZ will not require the use and exchange of this HCIM.
}}</span>
|-
| Contactpersoon
| Contact
| First relation/contact
| style="font-style:italic;" | see Patient.contact
|-
| FunctioneleOfMentaleStatus
| FunctionalOrMentalStatus
| All known functional / mental status
| <pre>GET [base]/Observation?category=http://snomed.info/sct|118228005,http://snomed.info/sct|384821006</pre>
<span id="FunctionalOrMentalStatusRemark"></span>{{NoteBox|The NL-CM:4.26.6 StatusDate concept is incorrectly mapped on the <code>effective[x]:effectivePeriod.start</code> element in the HCIM FunctionalOrMentalStatus profile, it is a date rather than a period. Presumed solution will come from a future HCIM release. See [https://bits.nictiz.nl/browse/MM-1570 MM-1570] for more information.}}
|-
| Probleem
| Problem
| All known problems
| <pre>GET [base]/Condition</pre>
|-
| Druggebruik
| DrugUse
| All known drug use
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228366006</pre>
|-
| Alcoholgebruik
| AlcoholUse
| All known alcohol use
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228273003</pre>
|-
| Tabakgebruik
| TobaccoUse
| All known tobacco use
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365980008</pre>
|-
| Woonsituatie
| LivingSituation
| Last known living situation
| <pre>GET [base]/Observation/$lastn?code=http://snomed.info/sct|365508006</pre>
|-
| Gezinssituatie
| FamilySituation
| All known family situations
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365470003</pre>
|-
| GezinssituatieKind
| FamilySituationChild
| All known family situations of child patient
| <pre>GET [base]/Observation?code=http://snomed.info/sct|55801000146105</pre>
|-
| Taalvaardigheid
| LanguageProficiency
| Known language proficiency
| style="font-style:italic;" | see Patient
|-
| ParticipatieInMaatschappij
| ParticipationInSociety
| All known participation in society status
| <pre>GET [base]/Observation?code=http://snomed.info/sct|314845004</pre>
|-
| HulpVanAnderen
| HelpFromOthers
| All known help from others
| <pre>GET [base]/CarePlan?category=http://snomed.info/sct|243114000</pre>
|-
| LaboratoriumUitslag
| LaboratoryTestResult
| Last known laboratory results per type (incl. medication levels like lithium)
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|275711006&_include=Observation:related-target&_include=Observation:specimen</pre>
|-
| AlgemeneMeting
| GeneralMeasurement
| All known questionaire (for example HONOS, OQ-45, CQ index, 4DKL) outcome scores.
| <pre>GET [base]/Observation?category=http://hl7.org/fhir/observation-category|survey</pre>
|-
| Verrichting
| Procedure
| All known GGZ procedures (includes all known freedom restricting measures)
| <pre>GET [base]/Procedure</pre>
|-
| TekstUitslag
| TextResult
| All known text results of GGZ procedures
| <pre>GET [base]/DiagnosticReport</pre>
|-
| -
| -
| CareTeam: primary healthprofessional and other relevant healthprofessionals including the healthcare provider.
| <pre>GET [base]/CareTeam?_include=CareTeam:participant</pre>
|-
| Zorgverlener
| HealthProfessional
| General Practitioner of the patient
| style="font-style:italic;" | see Patient, CareTeam
|-
| Zorgaanbieder
| HealthProvider
| General Practitioner's organization of the patient
| style="font-style:italic;" | see Patient, CareTeam
|}
<references/>

===Server - XIS===
The returned data to the PHR should conform to the profiles listed in [[#List_of_profiles]].

===The <code>lastn</code> operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The FHIR STU3 specification is vague regarding the sorting mechanism of <code>lastn</code>. In FHIR R4 however, this has been clarified and can be read as follows: when using <code>lastn</code>, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

==List of profiles==
The profiles represent their entire respective HCIM and are applicable in a broader context than the exchange of GGZ information.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable" style="horizontal-align: right"
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | HCIM NL
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | HCIM EN
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | FHIR Resource
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:400px" | FHIR Profile
|-
| Patient
| Patient
| Patient
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Betaler
| Payer
| Coverage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Payer|nictiz.fhir.nl.stu3.zib2017}}
|-
| BehandelAanwijzing
| TreatmentDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective|nictiz.fhir.nl.stu3.zib2017}}
|-
| Wilsverklaring
| AdvanceDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective|nictiz.fhir.nl.stu3.zib2017}}
|-
|-
| JuridischeStatus*
| LegalStatus*
| Extension
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|see Patient}} <s> or {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FreedomRestrictingMeasures|nictiz.fhir.nl.stu3.zib2017|see FreedomRestrictingMeasures}} </s>
|-
| <s>VrijheidbeperkendeMaatregelen</s>
| <s>FreedomRestrictingMeasures</s>
| <s>Procedure</s>
| <s>{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FreedomRestrictingMeasures|nictiz.fhir.nl.stu3.zib2017}}</s>
|-
| FunctioneleOfMentaleStatus
| FunctionalOrMentalStatus
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.zib2017}}
|-
| Probleem
| Problem
| Condition
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Problem|nictiz.fhir.nl.stu3.zib2017}}
|-
| Woonsituatie
| LivingSituation
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Druggebruik
| DrugUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse|nictiz.fhir.nl.stu3.zib2017}}
|-
| Alcoholgebruik
| AlcoholUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse|nictiz.fhir.nl.stu3.zib2017}}
|-
| Tabakgebruik
| TobaccoUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse|nictiz.fhir.nl.stu3.zib2017}}
|-
| Gezinssituatie
| FamilySituation
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FamilySituation|nictiz.fhir.nl.stu3.zib2017}}
|-
| GezinssituatieKind
| FamilySituationChild
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FamilySituationChild|nictiz.fhir.nl.stu3.zib2017}}
|-
| Taalvaardigheid
| LanguageProficiency
| Patient
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|see Patient}}
|-
| ParticipatieInMaatschappij
| ParticipationInSociety
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ParticipationInSociety|nictiz.fhir.nl.stu3.zib2017}}
|-
| HulpVanAnderen
| HelpFromOthers
| CarePlan
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HelpFromOthers|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017}}
|-
| AlgemeneMeting
| GeneralMeasurement
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-GeneralMeasurement|nictiz.fhir.nl.stu3.zib2017}}
|-
| Verrichting
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Procedure|nictiz.fhir.nl.stu3.zib2017}}
|-
| TekstUitslag
| TextResult
| DiagnosticReport
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TextResult|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgaanbieder
| HealthProfessional
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
|-
| -
| -
| CareTeam
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-careteam|nictiz.fhir.nl.stu3.zib2017}}
|}
<span id="FunctionalOrMentalStatusRemark">{{IssueBox|Due to legislation (the 'Wet verplichte ggz' (Wvggz)) HCIM FreedomRestrictingMeasures-v3.1 (release 2017) has become obsolete. Therefore, this version of the BgGGZ will not require the use and exchange of this HCIM.
}}</span>
<blockquote>* LegalStatus is a single concept of the HCIM FreedomRestrictingMeasures and does not represent a complete HCIM yet. This concept will become an independent HCIM in a future release of the HCIM.</blockquote>

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpGGZ#Release_notes|functional design page]].

MedMij:Vprepub-2020.01/FHIR GGZ

2022-03-25T15:57:30Z

Eduard de Rijcke: MM-3011 Strikethrough the FreedomRestrictingMeasures at the profile list and added an explanation

MedMij:V2020.01/BgZ Raadplegen

2022-03-10T08:59:35Z

Eduard de Rijcke: MM-3024 Fixed the hyperlinks to the Addenda and IG

__NOINDEX__
{{MedMij:Vprepub-2020.01/Issuebox}}

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Basisgegevensset Zorg - kwalificatie - Raadplegen Basisgegevensset Zorg {{VersieInfo|BgZ}}}}
<span class="toclimit-3">__TOC__</span>

= Versiebeheer =


{| class="wikitable"
|+ Versiebeheer
|-
! Datum !! BITS issue !! Omschrijving
|-
| 31-10-2021 || [https://bits.nictiz.nl/browse/MM-2446 MM-2446] || De tekst van de paragraaf 'Specifieke voorwaarden bij kwalificatie' is in overeenstemming gebracht met de corresponderende paragrafen in de kwalificatiescripts voor de BgLZ en BgGGZ- (géén toevoegingen).
|-
| 31-08-2021 || [https://bits.nictiz.nl/browse/MM-2294 MM-2294] || Kwalificatiescript omgezet van PDF-formaat naar wiki
|-
| 01-08-2020 || [https://bits.nictiz.nl/browse/MM-1119 MM-1119] || Scenario 1.3 toegevoegd t.b.v. de herleidbaarheid van gegevens
|}

= Doelgroep =
De doelgroep van dit document is een PGO leverancier die wil kwalificeren op de systeemrol ‘Raadplegen BgZ’ binnen het MedMij afsprakenstelsel.

De basis is de BgZ op basis van de publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

= Begrippenlijst =
Er zijn geen specifieke begrippen van toepassing.

= Inleiding =
Deze bladzijde bevat de te doorlopen scripts bij kwalificatie voor de systeemrol ‘Raadplegen BgZ’ binnen het MedMij afsprakenstelsel. De kwalificatie wordt door de kwalificator uitgevoerd met de Nictiz kwalificatiesimulator, die is ingericht op een FHIR server. De kwalificatiesimulator kan berichten verzenden en ontvangen. Er wordt gebruik gemaakt van testpatiënten met fictieve BSN's.

== Algemene voorwaarden voor kwalificatie ==




Een (kandidaat-) deelnemer kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van MedMij Afsprakenstelsel.
# Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie etc.
# Kennis en begrip van de betreffende MedMij informatiestandaard, zoals beschreven op de informatiestandaarden wiki van Nictiz.
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten andere referenties die de informatiestandaard gebruikt.
# Alle gegevens die de kwalificerende partij zelf moet invoeren zijn te vinden in de kwalificatiedocumentatie. Onjuist ingevoerde gegevens (ook tijd/datum etc.) zullen leiden tot vertraging van en kunnen blokkerend zijn voor het kwalificatieproces.
# Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker. De (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.
# Deze kwalificatie toetst geen infrastructurele eisen.

== Specifieke voorwaarden voor kwalificatie ==
Zie voor de algemene uitgangspunten bij kwalificatie op de algemene Kwalificatie-pagina de paragraaf [[MedMij:V2020.02/Kwalificatie#Uitgangspunten_voor_kwalificatie|Uitgangspunten voor kwalificatie]]

Voor deze informatiestandaard gelden de volgende specifieke voorwaarden en uitgangspunten:
* De kwalificatie is ingericht aan de hand van BgZ secties en de onderliggende zibs. Kennis van de zibs is een voorwaarde voor kwalificatie. BgZ omvat 18 secties, en 28 onderliggende zibs.
* De BgZ is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.
* Een PGO kan de gehele BgZ verwerken (gestructureerd opslaan in PGO database) en tonen. Dat geldt per zib voor alle onderliggende data-elementen (verplicht en optioneel).
* Een PGO raadpleegt altijd de gehele BgZ en daarmee dus alle secties (altijd alle FHIR searches).
* Voor de BgZ raadpleging verstuurt de PGO alle BgZ zoekopdrachten als losse queries en niet van bundeling als batch, onder andere om aan performance bezwaren tegemoet te komen.
* De BgZ secties, en de volgorde daarvan, zoals ook aangehouden in de addenda van de kwalificatiescripts, bepalen niet ''hoe'' de gegevens moeten worden weergegeven en gesorteerd in een PGO. Voor kwalificatie moeten wel alle functionele data-elementen conform de dataset van de informatiestandaard getoond worden aan de gebruiker.

* In de [[MedMij:Vprepub-2020.01/BgZ_Raadplegen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario's]] kunnen voorbeelden met data-elementen uitgewerkt zijn, die via FHIR references resolved moeten worden. Bijvoorbeeld het specialisme van een zorgverlener bij een verrichting, dat via PractitionerRole opgehaald kan worden. In het geval dat een dergelijk voorbeeld is uitgewerkt, zal bij de kwalificatie ook gecontroleerd worden of de referentie correct 'resolved' is. Het uitgangspunt is dat alle references resolvable moeten zijn, niet ''dat'' ze resolved worden. Een PGO zou er ook voor kunnen kiezen om een clickeable link te tonen, waarmee een gebruiker (de persoon) desgewenst zelf kan 'resolven', eventueel zelfs in een nieuwe sessie (na de initiële 15 minuten). Meer informatie over het gebruik van FHIR references binnen MedMij is te vinden in de informatiestandaard overstijgende principes op de [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vcurrent_FHIR_IG#Use_of_the_reference_datatype technische ontwerp pagina].
* Bij BgZ raadpleging geldt soms een specifieke filtering voor een zib. Labuitslagen is binnen BgZ bijvoorbeeld beperkt tot de bekende klinische chemie bepalingen, en daarvan de laatste uitslag. Andere use cases voor labuitslagen kunnen vanuit de separate informatiestandaard labuitslagen ondersteund worden.

*Mocht een PGO alleen enkele losse secties van de BgZ willen raadplegen, dan kan een PGO dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dit staat dan los van systeemrol ‘raadplegen BgZ’.

== Op te leveren kwalificatiemateriaal door de leverancier ==

# De berichten worden verstuurd vanuit de PGO. Verstuur de inhoudelijke gegevens van de kwalificatiescenario's naar de simulator (FHIR-server).
# Schermafdrukken van de kwalificatiescenario's, zoals aangegeven onder "Uit te voeren stappen". Stuur dit materiaal op in het [[Media: Aanleverformat - Raadplegen BgZ_V2020.01_20210324.zip|Aanleverformat - Raadplegen BgZ.]]

== Uit te voeren stappen Raadplegen ==


Voer – voor ieder scenario – de volgende stappen uit:
#De PGO stuurt een bevraging richting de kwalificatiesimulator voor een bepaalde persoon, zoals beschreven in [[MedMij:Vprepub-2020.01/BgZ_Raadplegen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]]
#De kwalificatiesimulator (FHIR server) zal de Basisgegevensset Zorg beschikbaarstellen. De gegevens komen overeen met de gegevens in [[MedMij:Vprepub-2020.01/BgZ_Raadplegen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]]
#Ontvang en verwerk de Basisgegevensset Zorg in het systeem.
#Maak schermafdrukken van de wijze waarop het PGO de Basisgegevensset Zorg toont, en leg deze vast in het [[Media: Aanleverformat - Raadplegen BgZ_V2020.01_20210324.zip|Aanleverformat - Raadplegen BgZ.]]

{| class="wikitable" width="85%"
|+
|-
! Doel !! Verwacht resultaat
|-
| Aantonen dat het systeem BgZ kan raadplegen || Het systeem genereert technisch correcte berichten
|-
| Aantonen dat ontvangen BgZ gegevens getoond worden || Het systeem ontvangt, verwerkt en toont de BgZ gegevens uit het retourbericht
|-
| Aantonen dat het systeem kan verwerken en tonen dat er geen zorginhoudelijke gegevens bekend zijn in geraadpleegde XIS (specifiek scenario 1.2) || Het systeem toont dat het beschikbaarstellende systeem kenbaar maakt dat er geen zorginhoudelijke gegevens aanwezig zijn
|-
| [[MedMij:Vprepub-2020.01/FunctionaliteitSystemen|Aantonen dat het systeem de herleidbaarheid van gegevens kan aantonen.]] (specifiek scenario 1.3) || Het systeem toont de bron en datum en tijdstip van raadpleging door de PGO
|}

Scenario's (vraag aan XIS van 1 specifieke Zorgaanbieder waarmee verbinding is gemaakt)''
*Scenario 1.1: BgZ van persoon 1, zoals beschreven in addendum 1.
*Scenario 1.2: BgZ van persoon 2, zoals beschreven in addendum 2.
*Scenario 1.3: De herleidbaarheid van een inhoudelijk data-element van persoon 1, zoals beschreven in addendum 3.

= Aandachtspunten voor inhoudelijke gegevens =
== Persoonsgegevens ==
De Basisgegevensset Zorg sectie Demografie en identificatie bevat algemene gegevens over de persoon zoals naam,
adres en woonplaats.
In het MedMij afsprakenstelsel is vastgelegd dat de BSN door de PGO niet gebruikt mag worden om XIS te
raadplegen, aangezien de PGO in het persoonsdomein valt en buiten het zorgaanbiedersdomein. Evenmin mag
een BSN geretourneerd worden naar het persoonsdomein.
Er is wel een fBSN (fictieve BSN voor testdoeleinden) in de persoonsgegevens opgenomen, aangezien het
beschikbaar stellende systeem (XIS) deze nodig kan hebben.

= Inhoudelijke gegevens scenario’s =
In dit hoofdstuk zijn de addenda van scenario 1.1, 1.2 en 1.3 te vinden.

De zorginhoudelijke gegevens die door XIS beschikbaargesteld worden per testpersoon, zijn te vinden op [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/BgZ_Beschikbaarstellen Kwalificatie Beschikbaarstellen BgZ]

==Scenario 1.1==
===Persoonsgegevens ===

{| class="wikitable" width=”40%”
!colspan='2'|Persoon 1
|-
|Achternaam ||XXX_Helleman
|-
|Voornaam ||Johan
|-
|Voorletter(s) ||J
|-
|Geslacht ||Man
|-
|Adresgegevens ||Knolweg 1000, 9999 XA, Stitswerd
|-
|Land ||Nederland
|-
|Geboortedatum ||25-07-1964
|-
|Patient_ID XIS ||1000000001
|}

==Scenario 1.2==

===Persoonsgegevens ===

{| class="wikitable" width=”40%”

!colspan='2'|Persoon 2
|-
|Achternaam ||XXX_Mesker
|-
|Voornaam ||Paul
|-
|Voorletter(s) ||P
|-
|Geslacht ||Man
|-
|Adresgegevens ||Knolweg 1002, 9999 ZZ, Stitswerd
|-
|Land ||Nederland
|-
|Geboortedatum ||01-08-1964
|-
|Patient_ID XIS ||1000000003
|}

{| class="wikitable"
==Scenario 1.3==
In scenario 1.3 wordt gevraagd om de herleidbaarheid van een inhoudelijk data-element van persoon 1 te tonen. Het verwachte resultaat is de bron en datum en tijdstip van raadpleging door de PGO van een zelfgekozen inhoudelijk data-element uit scenario 1.1.

MedMij:Vprepub-2020.01/BgZ Raadplegen

2022-03-10T08:59:35Z

Eduard de Rijcke: MM-3024 Fixed the hyperlinks to the Addenda and IG

MedMij:V2020.01/Kwalificatie aansluiten

2021-10-21T14:54:50Z

Eduard de Rijcke: MM-1886 Merge to vPrepub

{{MedMij:Vprepub-2020.01/Issuebox}}

===Doelgroep===
Doel van dit document is om een korte inleiding te geven aan leveranciers die willen starten met testen van een FHIR-zorgtoepassing.

Voor de uitwisseling van medische informatie maken zorgaanbieders gebruik van zorginformatiesystemen. Deze zogenaamde XIS-applicaties maken gebruik van informatiestandaarden zoals door MedMij worden ontwikkeld. MedMij biedt leveranciers de mogelijkheid hun producten en diensten te laten testen op correcte implementatie van informatiestandaarden.

NB: deze testen staan los van een formele kwalificatie. De scope tijdens testen is beperkter omdat er minder testen worden doorlopen dan tijdens een formele kwalificatie.

===Hoe verloopt het testproces?===

Tijdens testen worden een aantal fases doorlopen die hieronder zijn opgesomd.

Het traject verloopt als volgt:
* Leverancier meldt zich aan voor kwalificatie(s)
* MedMij verstrekt inhoudelijke scripts die door de softwareleverancier doorlopen kunnen worden.
* MedMij verstrekt de gegevens om de applicatie aan te sluiten op de simulator (zie [[MedMij:Vprepub-2020.01/Kwalificatie_aansluiten#Opzetten_connectiviteit|Opzetten connectiviteit]]).
* Leverancier meldt eigen organisatie en testsysteem aan bij de simulator.
* Kwalificatiecentrum biedt op verzoek hulp bij het koppelen van de applicatie naar de simulator
* Connectiviteit met de simulator wordt door de softwareleverancier en MedMij getest.
* Leverancier test zelfstandig op basis van scripts op de simulator en geeft aan klaar te zijn via [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]
* Indien van toepassing kan de leverancier extra materialen zoals screenshots insturen via email.
* Kwalificatiecentrum biedt op verzoek hulp bij het testen van de scripts.

====Testopzet DVP====
Bij testen waar de DVP het testobject is ziet de testopstelling er als volgt uit:

[[Bestand:Touchstone_DVP.png|link= |750px|Touchstone_DVP]]

De opzet is hier als volgt:
* De PGO/DVP is het testobject van de leverancier.
* Touchstone staat in het midden en stelt testen/testscripts, logging, validatie en overzicht beschikbaar.
* Daarachter staat een (WildFHIR) FHIR-server met de MedMij profielen en juiste testberichten, passend bij de testscripts.

====Testopzet DVZA====
Bij testen waar de DVZA het testobject is ziet de testopstelling er als volgt uit:

[[Bestand:Touchstone_DVZA.png|link= |550px|Touchstone_DVZA]]

De opzet is hier als volgt:
* Touchstone stelt testen/testscripts, logging, validatie en overzicht beschikbaar. Daarnaast is Touchstone ook een FHIR-client die interacties kan versturen volgens de testscripts.
* De DVZA is het testobject van de leverancier, in het algemeen een FHIR-server.

===Configureren simulator===
====Simulator====
MedMij organiseert testen zoveel mogelijk remote en via internet met behulp van een kwalificatiesimulator. MedMij gebruikt voor FHIR-testen de Touchstone simulator, zie https://touchstone.com

Het voordeel van het gebruik van deze tool is dat:
* Testen online kunnen gebeuren;
* Testen kunnen plaatsvinden op het moment dat het de softwareleverancier zelf uitkomt;
* Testen laagdrempelig is de focus ligt op de payload en infrastructurele zaken buiten scope van de test zijn;
* Meerdere testen tegelijkertijd kunnen plaatsvinden;
* De respons voorspelbaar is;
* De leverancier zelf inzicht heeft in de verstuurde berichten/documenten en validatieresultaten;
* De leverancier de mogelijkheid heeft om zichzelf te bevragen, of berichten naar zichzelf te sturen.

De simulator biedt tijdens de ontwikkeling de mogelijkheid om vooraf gedefinieerde inhoud terug te geven (zoals beschreven in de scripts). Hiermee kan de leverancier kijken of hij de data goed ontvangt en toont. Merk op dat hier vaak vaste inhoud teruggestuurd wordt. Ook kan de simulator het systeem bevragen in geval dat het systeem een bronsysteem is.

De simulator verzamelt informatie die van en naar een leverancier worden gecommuniceerd in een berichtenlog. Het is voor de leverancier mogelijk om zelf de berichtenlog in te zien, inclusief validatieresultaten.

Algemene opmerkingen over het gebruik van de simulator:
* de simulator is niet bedoeld voor loadtesten, maar voor inhoudelijke controles tegen informatiestandaarden;
* MedMij vraagt verantwoord gebruik van deze simulator, neem bij twijfel over gebruik contact op.

====Opzetten connectiviteit====
We maken gebruik van de TouchStone-simulator. Het is voor een leverancier nodig om een eigen account aan te maken. TouchStone biedt hiervoor verschillende subscripties/licenties aan, zie https://touchstone.aegis.net/touchstone/subscription

De Open subscriptie biedt genoeg mogelijkheden om te kunnen testen en kwalificeren maar heeft de volgende restricties:
* Er kan maar 1 gebruiker registreren. Bespreek in de eigen organisatie eerst goed welke gebruiker geregistreerd gaat worden.
* Er is een limiet aan het aantal testen dat per dag kan worden uitgevoerd.
Neem graag contact op als hier vragen over zijn, of problemen bij worden ervaren.

=====Organisatie aanmaken=====
Maak een account aan voor de organisatie, zie https://touchstone.aegis.net/touchstone/userguide/html/registration/index.html
Name en Email is redelijk vrij in te vullen (mits het echte namen en E-mailadressen betreft). Let er wel op dat de naam voor de Organisatie een naam moet zijn die herkenbaar is binnen MedMij als toekomstige deelnemer. Als er bijvoorbeeld een onderontwikkelaar wordt ingeschakeld en die naam wordt gebruikt tijdens registratie als Organisatie, dan is binnen MedMij de relatie naar de verantwoordelijke toekomstige deelnemende leverancier niet altijd duidelijk, waarbij de kans bestaat dat het verzoek voor Joinen van Org Groupen wordt afgekeurd.
Join de juiste Org Group voor testen:
Klik via Organizations, Org Groups
Kies de juiste Org Group om te joinen, in dit geval: '''MedMij-Testing'''

[[Bestand:Aansluiten_org_group.png|link= |750px|Joinen van een Org Group]]

* NB: voor formele kwalificaties wordt er gebruik gemaakt van een 2e Org Group, genaamd: '''MedMij-Certify'''
Het kwalificatiecentrum zal vervolgens het verzoek voor joinen goedkeuren. Merk op dat hierbij goedkeuring van één van onze medewerkers nodig is en er dus korte tijd overheen kan gaan. Nadat goedkeuring is verleend dient de gebruiker, als deze nog is ingelogd, uit te loggen en opnieuw in te loggen.

=====Pas eventueel privacy-settings aan=====
TouchStone toont per default e-mailadressen en de organisatie van geregistreerde gebruikers.
Pas eventueel de privacy-settings aan voor eigen gebruikers:
* Ga naar My Settings

[[Bestand:Aansluiten privacy settings.png|link= |750px|Aanpassen privacy settings]]

* Vink aan:
[[Bestand:Aansluiten privacy settings vink.png|link= |450px|Aanpassen privacy settings: Do not display my email]]
* Klik op Save Changes.

=====Testsysteem aanmaken=====
* Maak een testsysteem aan voor de eigen applicatie, zie https://touchstone.aegis.net/touchstone/userguide/html/test-systems/index.html
Bij het aanmaken graag de volgende instellingen gebruiken:
* Specification: FHIR 3.0.2
* Niet aanvinken: requires OAuth2
NB: we versturen wel degelijk een OAuth token, maar die configuratie vindt elders plaats.
* Can be viewed by: My organization groups
* Can be executed against by: My organization groups
* Supported profiles: maak de keuze tussen FHIR-client of FHIR-server
NB: als beide ondersteund wordt, is het aan te raden om daar 2 losse testsystemen voor op te zetten.

Het kwalificatiecentrum biedt op verzoek hulp bij het koppelen van de applicatie naar de simulator.
Connectiviteit met de simulator wordt door de softwareleverancier en MedMij getest.

===Gebruik simulator===
====Uitvoeren van testen====
Documentatie voor het uitvoeren van de testen is hier te zien: https://touchstone.aegis.net/touchstone/userguide/html/executing-tests/index.html

De leverancier kan zelfstandig testen op basis van scripts.
Indien van toepassing kan de leverancier extra materialen zoals screenshots insturen via email.
Het kwalificatiecentrum biedt op verzoek hulp bij het testen van de scripts.

Voor het uitvoeren van de tests kan (na inloggen) linksonder uit ‘Test Definitions’ een keuze worden gemaakt van de juiste testen.

[[Bestand:Aansluiten test definitions.png|link= |250px|Aansluiten test definitions]]

Klik onder ‘Test Definitions’ door naar:
* FHIRSandbox
** Nictiz
*** FHIR3-0-2-MM202001-Test (dit is de MedMij 2020.01 release)

In deze map zijn verschillende testen te vinden in het kader van MedMij testen.
Kies hierbij de juiste inhoudelijke rol en:
* PHR (= PGO) of
* XIS (= zorgaanbieder)

Selecteer de testen uit die map (meestal alle testen) dus select all, '''Create Test Setup'''.

[[Bestand:Aansluiten create test setup_20210318.png|link= |750px|Aansluiten create test setup]]

Bij het testen van '''PGO''' systemen moet de volgende informatie worden opgegeven:
* '''Origin''': Het eigen PGO test systeem.
* '''Destination''': Kies hierbij voor ‘Nictiz – Nictiz WildFHIR V202001 - FHIR 3.0.2’ (voor HTTP verkeer) of
* '''Destination''': Kies hierbij voor ‘Nictiz – Nictiz WildFHIR MedMij V202001-TLS - FHIR 3.0.2’ (voor HTTPS/TLS verkeer)
NB: voor HTTPS/TLS wordt er gebruik gemaakt van Let's Encrypt certificaten.

Bij het testen van '''XIS''' systemen moet de volgende informatie worden opgegeven:
* '''Origin''': AEGIS.net, Inc - TouchstoneFHIR
* '''Destination''': Het eigen XIS test systeem.

Daarna: '''execute'''

[[Bestand:Aansluiten create test setup execute.png|link= |750px|Aansluiten create test setup execute]]

Zie verder de documentatie van Touchstone voor het inzien van test resultaten:
https://touchstone.aegis.net/touchstone/userguide/html/executing-tests/index.html

====Volgorde van testen====
Het kwalificatiescript vraagt om een vaste volgorde voor het uitvoeren van testen, waar de informatiestandaard mogelijk meer ruimte laat om dit ook in een andere volgorde te doorlopen.
Het is daarom van belang om bij het uitvoeren van testen op de kwalificatiesimulator de interacties uit te voeren '''in dezelfde volgorde''' waarin ze worden gevraagd in de testscripts.

====Aandachtspunten Infrastructuur====
Bij het gebruik van Touchstone willen we de volgende punten onder de aandacht brengen:
* Touchstone maakt geen gebruik van tweezijdige TLS-authenticatie.

====Testen en ophalen van references====
Antwoorden uit de kwalificatiesimulator bevatten soms references naar extra informatie.
Een voorbeeld uit de BGZ:
<code><reference value="Practitioner/medmij-bgz-practitioner-ts-02"/></code>

Die references zijn los op te halen bij de kwalificatiesimulator.
Merk op dat omdat er een bepaalde volgorde wordt gevraagd tijdens uitvoer van de testen, het tussendoor ophalen van references mogelijk kan ervoor zorgen dat een test faalt.
We raden in dat geval aan om:
* De references pas op te halen als de test op de kwalificatiesimulator is afgelopen. Het ophalen van references zal er dan niet meer voor zorgen dat testen falen.
Indien dat niet mogelijk is:
* Testen 2 keer uit te voeren:
** De test één keer uit te voeren zonder het ophalen van references. Het doel hierbij is om aan te tonen dat de applicatie de juiste interacties kan versturen die worden gevraagd in het testscript.
** De test een tweede keer uit te voeren, maar dan zonder dat hiervoor een testexecutie is gestart op de kwalificatiesimulator. Tijdens deze test kunnen dan wel alle references tussendoor worden opgehaald. Het doel van deze test is om aan te tonen dat de applicatie goed om kan goed met de inhoud verstuurd tijdens de test, inclusief de los op te halen references.

====Vragen over uitvoer van testscript====
Indien er vragen zijn over uitgevoerde testen is het voor ons van belang om gericht te kunnen terugvinden welke interacties er uitgewisseld zijn.
Bij contact hierover vragen wij daarom om (indien mogelijk) hiervoor een testexecution uit te voeren op de kwalificatiesimulator.
Neem bij vragen daarover graag altijd de link op naar de uitgevoerde testexecution uit de history van Touchstone.
Dat geeft de mogelijkheid om gericht te kijken naar een uitgevoerde test.

Een voorbeeld in schermprints:

Klikken naar '''History''' in Touchstone:

[[Bestand:Touchstone_history.png|link= |250px|Touchstone history.png]]

Ophalen van de link van de testexecution uit de History:

[[Bestand:Touchstone_history_link_20210318.png|link= |750px|Touchstone_history_link.png]]

De link van de testexecution ziet er dan bijvoorbeeld zo uit:
<code><nowiki>https://touchstone.aegis.net/touchstone/execution?exec=201904050520537715673006</nowiki></code>

====Tijdnotatie====
Het meegeven van de tijd is bij de gestructureerde einddatum/tijd (dus niet de Resource.text, maar de velden met alleen de datum/tijd) verplicht in de standaard om eventuele verwarring tussen de precieze betekenis van "tot" en "tot en met" te voorkomen.

In de FHIR datatypes dateTime (indien uren en minuten worden gebruikt) en instant is de tijdzone verplicht. De tijdzone kan daarom niet worden weglaten uit de testgegevens.

Touchstone heeft helaas een beperking dat de Nederlandse tijdzone niet berekend kan worden bij een variabele datum. De tijdzone die nu in onze testgegevens staat, was een Nederlandse tijdzone bij de eerste keer invullen van dit scenario met concrete datums. Dit komt niet per definitie overeen met de geldende tijdzone in Nederland voor de (in een test-executie gebruikte, uiteindelijke) datum. In productie moet gerekend worden op een juiste tijdzone en het is dan ook juist om deze tijdzone gewoon te interpreteren, dit betekent dat de gegevens mogelijk soms een uur later of vroeger zijn dan in het addendum staat. Dit is geen reden voor afkeuren in kwalificatie.

===Mijn software is getest en nu?===
Geef graag aan als de testen zijn afgerond via [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]

MedMij:Vprepub-2020.01/Kwalificatie aansluiten

2021-10-21T14:54:50Z

Eduard de Rijcke: MM-1886 Merge to vPrepub

MedMij:V2020.01/Kwalificatie FAQ

2021-10-21T14:54:06Z

Eduard de Rijcke: MM-1886 Merge to vPrepub

{{MedMij:Vprepub-2020.01/Issuebox}}
=Kwalificatie Proces=
'''Wat is de gemiddelde doorlooptijd van een (pre-)kwalificatie'''
<div class="mw-collapsible mw-collapsed">
Een kwalificatieslot start altijd op maandag.
De gemiddelde doorlooptijd voor een DVP kwalificatie bedraagt één werkweek en voor een DVZA twee werkweken.</div>

'''Wanneer krijg ik terugkoppeling over mijn kwalificatie?'''
<div class="mw-collapsible mw-collapsed">
* Een DVP kwalificatie beslaat één werkweek en start altijd op maandag.
** Indien het materiaal niet volledig is of er blokkerende punten zijn op technisch vlak (geen 100% score op de Touchstone testexecutie), wordt dat op maandag al teruggekoppeld.
** Indien het materiaal volledig is en er geen blokkerende punten worden gevonden op technisch vlak, wordt het materiaal functioneel beoordeeld en vindt er uiterlijk vrijdag finale terugkoppeling plaats.
* Een DVZA kwalificatie beslaat twee werkweken en start altijd op maandag.
** In de eerste week wordt het materiaal technisch beoordeeld en indien deze positief is bevonden, vindt de functionele beoordeling plaats in week twee.
** Indien het materiaal niet volledig is, wordt dat op maandag in de eerste week al teruggekoppeld. Er vindt geen technische en functionele beoordeling plaats.
** Indien er op technisch vlak blokkerende punten zijn wordt dit op vrijdag in de eerste week teruggekoppeld. Er vindt geen functionele beoordeling plaats.
** Indien er op technisch vlak geen blokkerende punten zijn wordt de functionele beoordeling uitgevoerd en vindt terugkoppeling plaats op vrijdag in de tweede week.
</div>

'''Hoe moet ik de schermprinten aanleveren?'''
<div class="mw-collapsible mw-collapsed">
Op de kwalificatiepagina tref je de aanleverformaten onder het kopje [[MedMij:Vprepub-2020.01/Kwalificatie#Kwalificatiebenodigdheden|kwalificatiebenodigdheden]]. In het aanleverformat wordt aangegeven of de screenshots per scenario of per sectie uit een scenario aangeleverd dienen te worden. </div>

'''Wat is het verschil tussen een pre-kwalificatie, kwalificatie, kwalificatie 2 etc.?'''
<div class="mw-collapsible mw-collapsed">
De termen pre-kwalificatie, kwalificatie, kwalificatie 2, etc. zijn arbitrair. De pre-kwalificatie is het eerste toetsmoment en de kwalificatie het tweede toetsmoment. Indien je positief door de pre-kwalificatie heen komt, is er geen vervolg meer nodig voor dezelfde gegevensdienst. De pre-kwalificatie is dus gelijk aan de kwalificatie en dient niet gebruikt te worden als “oefenmoment” om het systeem functioneel of technisch te testen.
Normaliter spreken we een herstelperiode van één week af tussen de pre-kwalificatie en kwalificatie om alle fouten te herstellen. Mocht er behoefte zijn aan meer tijd om de blokkerende punten te herstellen, dan kan dat ingepland worden. Indien tijdens de kwalificatie niet alle blokkerende punten zijn opgelost dient er een nieuw kwalificatieslot aangevraagd te worden. We spreken dan over kwalificatie 2, 3 enzovoorts. </div>

'''Ik heb mijn materiaal hersteld, kan ik het direct aanleveren?'''
<div class="mw-collapsible mw-collapsed"> Nee, dat kan niet. Om er zeker van te zijn dat we het materiaal kunnen ontvangen en volgens de procedurele afspraken kunnen beoordelen, kan het materiaal alleen worden aangeleverd indien er een kwalificatieslot gepland staat. Afwijken hiervan kan alleen in overleg met en na akkoord van het kwalificatiecentrum. </div>

'''Ik wil graag een (technisch) expert spreken over mijn kwalificatie of Touchstone. Hoe kan ik dat het snelst doen?'''
<div class="mw-collapsible mw-collapsed"> Het snelste kun je hen bereiken door een issue te loggen in [https://bits.nictiz.nl/projects/MM/issues/ BITS], onder het project voor de MedMij-standaarden. Hier komt het direct bij de juiste experts terecht. Vragen rondom lopende kwalificaties kunnen ook gesteld worden via [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]. </div>

'''Ik kan niet het volledige kwalificatiescript ondersteunen, wat nu?'''
<div class="mw-collapsible mw-collapsed"> Om veilige gegevensuitwisseling te kunnen garanderen is het van belang dat het volledige kwalificatiescript wordt ondersteund. Kun je hier niet aan voldoen, is het van belang dit ruim voorafgaand aan je kwalificatie te loggen via BITS, onder het project voor de MedMij-standaarden t.a.v. de informatiestandaard die je wil kwalificeren. Kaart je dit pas aan tijdens kwalificatie of wordt dit tijdens kwalificatie door de (technische) kwalificatiespecialist geconstateerd, zal dit leiden tot vertraging in het kwalificatieproces. Zie ook de [[MedMij:Vprepub-2020.01/Kwalificatie#Procedurele_eisen_voor_kwalificatie|procedurele eisen]] op de kwalificatiepagina. </div>

'''Ik loop uit en ben bang dat ik mijn acceptatieslot niet ga redden, wat nu?'''
<div class="mw-collapsible mw-collapsed"> Kwalificatie is een voorwaarde voor Acceptatie. Zodra er vermoeden is van uitloop, wordt het aangeraden contact op te nemen met Acceptatie om de mogelijkheden te bespreken. </div>

'''Ik ben een integrator en kan geen schermprinten aanleveren, wat nu?'''
<div class="mw-collapsible mw-collapsed"> Het doel van kwalificatie is: een betekenisvol oordeel vellen of een systeem de systeemrol conform de in de informatiestandaard gestelde eisen op juiste wijze
ondersteunt. Zie ook onze [https://www.medmij.nl/wp-content/uploads/2020/04/Factsheet-DVZA-kwalificatie.pdf factsheet voor DVZA kwalificaties]. </div>

'''Welke kwalificatiescripts moet ik doorlopen?'''
<div class="mw-collapsible mw-collapsed"> Van de actuele gegevensdiensten waarop gekwalificeerd kan worden, bestaan er meerdere MedMij versies. Hierbij is het belangrijk dat het kwalificatiescript gekozen wordt waarin het nummer staat dat overeenkomt met het MedMij versienummer waarop er gekwalificeerd wordt. Als je bijvoorbeeld kwalificeert op de BgZ 2020.01, dient het kwalificatiescript benaderd te worden vanuit de map waarin 2020.01 in de titel staat: Nictiz/FHIR3-0-2-MM202001-Cert. Wanneer er gebruik wordt gemaakt van het verkeerde script, kan het materiaal helaas niet meegenomen worden. </div>

=Functionele Kwalificatie=
'''Waar vind ik de eisen terug?'''
<div class="mw-collapsible mw-collapsed"> Het is belangrijk alle functionele en technische eisen goed door te nemen en geïmplementeerd te hebben voorafgaand aan de kwalificatiepogingen. De eisen die gesteld worden, verschillen per gegevensdienst.
* Op de [[MedMij:Vprepub-2020.01/Kwalificatie|kwalificatiepagina]] staan de uitgangspunten en procedurele eisen voor kwalificatie. Hier vind je eveneens de addenda en de kwalificatiescripts.
* Voor een actueel overzicht van gegevensdiensten, met een verwijzing naar kwalificatie-informatie per systeemrol, raadpleeg de [https://afsprakenstelsel.medmij.nl/display/MMCatalogus/Actuele+gegevensdiensten MedMij Catalogus]. Via de catalogus kan doorgeklikt worden naar het functioneel ontwerp en technisch ontwerp per systeemrol. </div>

'''Binnen de standaard wordt een oudere zibversie vereist, dan de laatste release van zibs. Mag een nieuwere versie van de zib worden geïmplementeerd?'''
<div class="mw-collapsible mw-collapsed">
* De informatiestandaarden die worden gebruikt binnen MedMij zijn gebaseerd op de 2017 publicatie van de zibs. Binnen MedMij wordt er niet op zibs maar op gegevensdiensten gekwalificeerd, die gebaseerd zijn op een informatiestandaard. Een gegevensdienst kan herkend worden aan de unieke systeemrolcode die eraan toe is gekend. Een overzicht van de actuele gegevensdiensten is terug te vinden in de [https://afsprakenstelsel.medmij.nl/display/MMCatalogus/Actuele+gegevensdiensten MedMij Catalogus]. Doordat er wordt gekwalificeerd op gegevensdiensten is de publicatie van de zibs die in een informatiestandaard worden gebruikt leidend. Zodoende zijn op dit moment alle gegevensdiensten die uitgaan van zibs gebaseerd op de 2017 publicatie. Wanneer een (kandidaat-)deelnemer ervoor kiest om een nieuwere versie van de zibs te implementeren moet er rekening mee worden gehouden dat deze niet compatibel zijn met de versies die vereist zijn voor uitwisseling binnen het afsprakenstelsel. </div>

'''Hoe werkt de variabele T?'''
<div class="mw-collapsible mw-collapsed">
<br /> Voor veel kwalificaties wordt er gebruik gemaakt van een variabele datum. Dit is de zogenoemde T datum welke is opgenomen in de functionele testscripts, met name in de addenda, en in de technische testscripts op Touchstone. Deze variabele datum wordt gebruikt om zo dicht mogelijk tegen een productiewaardig scenario te testen en te kwalificeren. Middels de variabele datum kunnen de testgegevens actueel blijven. Deze T datum komt op twee plekken terug, namelijk in de datumvelden van de testgegevens en in de datumparameters in de search URL's. In de volgende twee paragrafen wordt dit toegelicht.
<br /> De functionele testscripts beschrijven in de addenda testgegevens waarin datumvelden staan op basis van een T datum. Als ergens staat T – 100D betekent dit: 100 dagen eerder dan de datum die voor T geldt. Deze T-datum wordt afgegeven door het kwalificatie team. Elke maandag wordt de Nictiz WildFHIR-server geschoond en opnieuw gevuld met een testgegevens op basis van een T datum gelijk aan de datum van die maandag. Bijvoorbeeld in 2021 is T datum in week 11 gelijk aan 15 maart 2021. </div>

'''Hoe stel ik datum T in?'''
<div class="mw-collapsible mw-collapsed">
<br /> Het vullen van de Nictiz WildFHIR-server kon in het verleden door kandidaatdeelnemers gebeuren door het draaien van het 'load script' op basis van een op te geven variable T. Dit is nu in beheer genomen door het kwalificatie team. Elke maandag wordt de Nictiz WildFHIR-server geschoond en opnieuw gevuld met een testgegevens op basis van een T datum gelijk aan de datum van die maandag. Bijvoorbeeld in 2019 is T datum in week 11 gelijk aan 15 maart 2021. </div>

''' Hoe werken parameters in de request URL's? '''
<div class="mw-collapsible mw-collapsed">
<br /> Bij sommige testscenario's wordt een datumfilter gebruikt. Deze datumfilters zijn ook op basis van de variabele T datum. De T datum die hier gebruikt dient te worden, is gelijk aan de datum van de maandag (waarop de gegevens geladen zijn). Wanneer een andere T datum wordt gebruikt kan het voorkomen dat er geen of te weinig testgegevens terugkomen op de uitgevoerde test. Dit kan er toe leiden dat de test niet slaagt. </div>

=Technische Kwalificatie=
Het technisch op de juiste manier FHIR-berichten genereren, blijkt in de praktijk vaak niet bij de eerste kwalificatie goed te gaan en levert daarmee vertraging op in het kwalificatieproces. Om het kwalificatieproces soepeler te laten verlopen, is een overzicht gemaakt van fouten in de FHIR-berichten die het vaakst opduiken tijdens de technische kwalificatie.
In het hieronder volgende overzicht wordt duidelijk gemaakt:
* Welke informatiestandaard wordt geraakt.
* Wat de fout betreft.
* Waar de fout doorgaans in het bericht te vinden is.
* De ernst van de fout (blokkerend betekent dat herkwalificatie nodig is).
* Uitleg over de fout met, waar mogelijk, links naar de relevante informatie en/of een stuk voorbeeldcode over wat verwacht wordt in de technische kwalificatie.
Het is sterk aan te raden om zelf voorafgaand aan de kwalificatie met behulp van deze tabel te controleren of FHIR-berichten correct worden gegenereerd. Bij verdere vragen kan een ticket worden ingeschoten in BITS op het MedMij-project.

Verder is het mogelijk om de technische kwalificatiesscripts ter naslagwerk in te zien. Deze zijn te vinden in [https://github.com/Nictiz/Nictiz-STU3-testscripts de Nictiz-STU3-testscripts repository op Github].

Disclaimer: de gegeven voorbeelden zijn in XML, dit kan in de praktijk ook JSON zijn.

{| class="wikitable sortable mw-collapsible"
! Informatiestandaard !! Veelvoorkomende fouten !! Element !! Blokkerend !! Uitleg

|-
| Alle || De codesysteem-OID uit een zib wordt gebruikt om de URI voor {{fhir|.system}} mee te construeren || {{fhir|.coding.system}} || Ja || Het FHIR-profiel schrijft voor welke URI gebruikt dient te worden, zie [[MedMij:V2020.01/FHIR IG#Code system URIs]].
|-
| Alle, vanaf publicatie 2020.01 || De server retourneert een lege Bundle als de resource niet wordt ondersteund || {{fhir|Bundle.resource}} || Ja || Als een niet-ondersteunde resource wordt bevraagd, dient de server een OperationOutcome te retourneren met {{term|not supported}} in {{fhir|.code}}. Zie de [[MedMij:Vprepub-2020.01/FHIR_IG#Handling_errors]].
|-
| Alle || Resource.id ontbreekt || Resource.id || Ja, maar || Zie [[MedMij:Vprepub-2020.01/FHIR_IG#When_is_id_expected.3F|FHIR IG: when is id expected?]]
|-
| Alle || Bundle.entry.fullUrl en Resource.id zijn niet consistent || Resource.id || Ja, maar ||
Zie [[MedMij:Vprepub-2020.01/FHIR_IG#Logical_ids.2C_fullUrls_and_references_in_Bundles|FHIR IG: fullUrls and references in Bundles]]

Fout
<syntaxhighlight lang="xml">

<entry>
<fullUrl value="http://example.org/fhir/AllergyIntolerance/f9125272-8305-11ea-5462-020000000000"/>
<resource>
<AllergyIntolerance>
<id value="allergy-01"/>

--------

<entry>
<fullUrl value="urn:oid:2.16.528.1.1007.3.3.2222"/>
<resource>
<Practitioner>
<id value="practitioner-01"/>
</syntaxhighlight>

Goed

<syntaxhighlight lang="xml">

<entry>
<fullUrl value="http://example.org/fhir/AllergyIntolerance/f9125272-8305-11ea-5462-020000000000"/>
<resource>
<AllergyIntolerance>
<id value="f9125272-8305-11ea-5462-020000000000"/>

--------

<entry>
<fullUrl value="urn:oid:2.16.528.1.1007.3.3.2222"/>
<resource>
<Practitioner>
<id value="2.16.528.1.1007.3.3.2222"/>

</syntaxhighlight>
|-
| Alle || Bundle.entry.fullUrl mag niet een relatieve URL zijn || Bundle.entry.fullUrl || Ja || Indien Bundle.entry.fullUrl URL's zijn, moeten deze absoluut zijn en niet relatief. De references binnen een resource mogen wel relatief te zijn als dit een URL is.

Verwacht in fullUrl is een absolute URL, een UUID of een OID. Zie

*https://www.hl7.org/fhir/STU3/bundle-definitions.html#Bundle.entry.fullUrl

*https://www.hl7.org/fhir/STU3/bundle.html#bundle-unique

*https://www.hl7.org/fhir/STU3/bundle.html#references"
<syntaxhighlight lang="xml">

<entry>
<fullUrl value="urn:oid:2.16.840.1.113883.2.4.6.6.90000258.4.6.525"/>
</syntaxhighlight>
|-
| Alle || FHIR-resources bevatten niet alle in het script gevraagde informatie || || Ja, maar || Voor kwalificatie doeleinden is het verplicht om alle informatie zoals vermeld in het addendum, mee te geven in het FHIR-bericht of te tonen in de user interface.
FHIR-profielen maken het mogelijk dat bepaalde informatie niet in alle gevallen bekend is en dwingen dus weinig af. Bij kwalificatie echter is de informatie wel bekend via het kwalificatiescript. Uitzonderingen kunnen gemaakt worden, bijvoorbeeld indien een XIS een bepaalde zib of data-element niet ondersteund. Per item dient dit voorafgaand kwalificatie te worden besproken en gewogen.

https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_Kwalificatie#Kwalificatie_scripts

|-
| Alle || FHIR-resources valideren niet tegen het verwachte profiel || || Ja || Controleer voor elk profiel in Simplifier of alle verplichte elementen zijn meegenomen. Deze verplichte elementen hoeven niet altijd onderdeel te zijn van het addendum. De validator in Touchstone geeft hier naar alle waarschijnlijkheid een foutmelding over, maar hoeft niet te resulteren in een gefaalde test. Let daarom goed op of de test een 'w' voor warning oplevert. Bij onduidelijkheid omtrent de waarschuwing kan een ticket in BITS worden aangemaakt.

|-
| Alle || Datatype Reference, Coding of CodeableConcept mist display || Meerdere elementen per resource mogelijk || Ja || Bij elke reference en CodeableConcept is een display value verplicht. Zie hiervoor de specificaties van het reference datatype in MedMij:
* https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG#Use_of_the_reference_datatype
* https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG#Use_of_coded_concepts
<syntaxhighlight lang="xml">
<generalPractitioner>
<reference value="Organization/nl-core-organization-01"/>
<display value="Maatschap Vaste Huisarts"/>
</generalPractitioner>
</syntaxhighlight>
|-
| Alle || Extensie code-specification waarin de zibwaarde staat, ontbreekt || Meerdere elementen per resource mogelijk || Ja, op plaatsen waar de mapping niet 1-op-1 is || De extensie code-specification is bedoeld voor het meegeven van de oorspronkelijke zibwaarde als de FHIR-resource dat op die plaats niet direct toelaat. Dat zijn vaak statuscodes waarvoor FHIR zelf verplichte terminologie heeft. Om geen zibinformatie kwijt te raken, bijvoorbeeld omdat de mapping op de FHIR codes niet geheel 1-op-1 is, is meegeven van de zibwaarde dus van belang.

Bijvoorbeeld: gender (https://zibs.nl/wiki/Patient-v3.1(2017NL)), adres (soort, landcode, nummergebruik https://zibs.nl/wiki/Adresgegevens-v1.0(2017NL), naam (use, https://zibs.nl/wiki/Naamgegevens-v1.0.1(2017NL)) en eventueel andere.
<syntaxhighlight lang="xml">
<gender value="male">
<extension url="http://nictiz.nl/fhir/StructureDefinition/code-specification">
<valueCodeableConcept>
<coding>
<system value="http://hl7.org/fhir/v3/AdministrativeGender"/>
<code value="M"/>
<display value="Man"/>
</coding>
</valueCodeableConcept>
</extension>
</gender>
</syntaxhighlight>
|-
| Alle || Burgerservicenummer mag niet worden gebruikt in query en/of resources || || Ja || Het MedMij-afsprakenstelsel definieert op basis van vigerende wetgeving dat burgerservicenummers niet mogen worden uitgewisseld. Uitzondering vormen plaats waar het onredelijk of onmogelijk is om te eisen dat deze worden verwijderd, zoals in een PDF-document.

Gebruik in query-parameters zoals patient of subject, in een Bundle.link, als Patient.id, Patient.identifier en andere gestructureerde locaties op basis van BSN is niet toegestaan.
|-
| Alle || Resource.text ontbreekt. Ook bekend als Narrative || Resource.text || Ja, maar || Resource.text is SHOULD en moet dan een klinisch relevante/veilige samenvatting bieden van hetgeen in de resource staat. Om discussie te voorkomen over wat wel of niet klinisch relevant is, wordt geadviseerd om alle elementen uit het bericht, toe te voegen aan de narrative. Een ontvanger MAG deze gebruiken om te tonen. Slechts in een enkel geval zoals bij conformance resources (StructureDefinition, ValueSet etc.) een text element met status empty te gebruiken. Uitzondering op dit alles is de contained resource. Deze MAG GEEN text hebben. Zie

* https://www.hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text

* https://www.hl7.org/fhir/STU3/narrative.html
|-
| Alle || FHIR server heeft geen CapabilityStatement, of kan deze niet opleveren met de verwachte minimale inhoud bij de informatiestandaard || || Ja || Geen CapabilityStatement beschikbaar op het /metadata endpoint. Dit is een SHALL vanuit de FHIR spec: https://www.hl7.org/fhir/stu3/http.html#2.21.0
|-
| Alle || Bundle van type searchset moet Bundle.link bevatten || Bundle.link || Ja || Bundle.link heeft een SHALL in de FHIR spec, zie voor meer informatie:
* http://hl7.org/fhir/STU3/bundle-definitions.html#Bundle.link
* https://www.hl7.org/fhir/stu3/search.html#conformance
<syntaxhighlight lang="xml">
<link>
<relation value="self"/>
<url value="http://nictiz.wildfhir.org/fhir3-i2/AllergyIntolerance?"/>
</link>
</syntaxhighlight>
|-
| Alle || HumanName mist extensies voor het identificeren van de verschillende naamdelen || HumanName.family || Ja || Bij HumanName.family wordt een extensie verwacht die extra informatie geeft over de naamdelen, zoals voorgeschreven door de zib. https://zibs.nl/wiki/Naamgegevens-v1.0.1(2017NL) https://simplifier.net/NictizSTU3-Zib2017/nl-core-humanname
<syntaxhighlight lang="xml">
<family value="Jongeneel-de Haas">
<extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-name">
<valueString value="Jongeneel"/>
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/humanname-partner-prefix">
<valueString value="de "/>
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/humanname-partner-name">
<valueString value="Haas"/>
</extension>
</family>

<given value="Irma">
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
<valueCode value="CL"/>
</extension>
</given>
<given value="I.">
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
<valueCode value="IN"/>
</extension>
</given>
</syntaxhighlight>
|-
| Alle || Address mist extensies voor het identificeren van de verschillende adresdelen || Address.line || Ja || Bij Address.line wordt een extensie verwacht die gebruikt wordt om elk specifiek onderdeel van het Address de kunnen onderscheiden, zoals voorgeschreven door de zib.
* https://zibs.nl/wiki/Adresgegevens-v1.0(2017NL)
* https://simplifier.net/NictizSTU3-Zib2017/nl-core-address
<syntaxhighlight lang="xml">
<address>
<extension url="http://fhir.nl/fhir/StructureDefinition/nl-core-address-official">
<valueBoolean value="true"/>
</extension>
<use value="home"/>
<type value="both"/>
<line value="Straatweg 12bII">
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-streetName">
<valueString value="Straatweg"/>
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-houseNumber">
<valueString value="12"/>
</extension>
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-buildingNumberSuffix">
<valueString value="bII"/>
</extension>
</line>
</syntaxhighlight>
|-
| PDF/A || Onjuist gebruik of afwezigheid identifier en/of masteridentifier || resource.masterIdentifier of resource.Identifier || Ja || De DocumentManifest.masterIdentifier en DocumentReference.masterIdentifier dienen door het XIS zelf te worden gegeneerd, met een eigen system. De .masterIdentifier is de versie specifieke identifier waar de .identifier een versie onafhankelijke identifier kan zijn (https://www.hl7.org/fhir/stu3/documentmanifest-definitions.html#DocumentManifest.masterIdentifier)
|}

MedMij:Vprepub-2020.01/Kwalificatie FAQ

2021-10-21T14:54:06Z

Eduard de Rijcke: MM-1886 Merge to vPrepub

FHIR:V1.0 FHIR IG STU3

2021-10-21T14:51:20Z

Eduard de Rijcke: MM-2436 Merge to vPrepub

__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:FHIR Implementation Guide}}

__TOC__

=Introduction=
This implementation guide describes the considerations for using '''HL7® FHIR®''' in context of information standards that are maintained by Nictiz. It applies specifically to HL7® FHIR® version 3 (STU3).

This implementation guide is aimed at software vendors and developers that need to implement FHIR based information standards maintained by Nictiz. Users of this guide are expected to be familiar with the [https://hl7.org/fhir/STU3 FHIR STU3 specification] and resource processing. Where relevant, links to the FHIR specification are provided. This implementation guide is not intended to be a tutorial on that subject.

<section begin=OverarchingPrinciples />
=Use case overarching principles=
==Content Types and encodings==
Unless stated otherwise, the information standards use the [https://hl7.org/fhir/http.html#mime-type FHIR RESTful framework]. This framework defines at least three content-types to send/retrieve information:
* XML: application/fhir+xml
* JSON: application/fhir+json
* RDF: text/turtle - Not supported in this context

Servers SHALL support both XML and JSON, while clients MAY use either format for the request and the response. For the response, servers SHALL support server-driven content negotiation as described in [https://www.hl7.org/fhir/stu3/http.html#mime-type the FHIR specification]. This means that clients can indicate the desired response format using the optional <code>_format=[mimetype]</code> URL parameter, or the acceptable response format(s) using the <code>Accept</code> header. The URL parameter takes precedence over the header. If a client does not request a specific content-type, then it is server discretion to respond using XML or JSON.

FHIR uses UTF-8 for all request and response bodies. Since the [https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1 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 <code>charset</code> parameter of the MIME-type in the <code>Content-Type</code> header. Requests MAY also specify this <code>charset</code> parameter in the <code>Accept</code> header and/or use the <code>Accept-Charset</code> header.

==Use of coded concepts==
===Textual description of coded concepts===
Coded information is extremely important for interoperability between systems. It enables systems to act on information rather than have humans read everything for interpretation - it enables medication related alerts, exercise encouragements because of weight increase, and many more things. In the HCIMs and profiles, we therefore strive for complete coverage of all possible situations.

However it is likely that unknown codes present themselves 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 way that now has been deprecated. It is therefore vital that, in addition to the code itself, the sender includes the semantics of the code. Therefore, systems SHOULD include [https://hl7.org/fhir/STU3/datatypes.html#coding {{fhir|(CodeableConcept).coding.display}}] and/or [https://hl7.org/fhir/STU3/datatypes.html#codeableconcept {{fhir|CodeableConcept.text}}] for coded data in FHIR instances. These fields may only be absent in rare circumstances, for example when dealing with historic data, or in data acquired without such info from a third party.

===Code system URIs===
A coded value in FHIR is communicated as a combination of a code (in {{fhir|.code}}) and the canonical URI for the code system from which it was drawn (in {{fhir|.system}}). Implementers SHALL use the canonical URI that is defined in the FHIR conformance resource. This canonical URI can be found by inspecting the ValueSet that is bound to a coded element in the appropriate FHIR profile.<ref>Although the canonical URI is not formally defined in the ValueSet, in practical terms it can be found here.</ref>

'''Please note''': it is an error to assume that the OID assigned to a code system can be used to construct its canonical URI. The canonical URI for use in a FHIR context will always be assigned through the conformance resources<ref>There are exceptions to this, in which case other rules apply, see [https://www.hl7.org/fhir/stu3/terminologies.html#system the FHIR specifications]. However, this situation is not expected to occur in the use cases that this IG covers.</ref>. It ''can'' align with this OID (as a (<code><nowiki>urn:oid:[oid]</nowiki></code> URI), but this is not always the case. For example, SNOMED CT is referenced by URL rather than by <code><nowiki>urn:oid:[oid]</nowiki></code>.

===Mapping of coded concepts===
Terminology from HCIMs or UCSDs (use case specific datasets) needs to be faithfully applied to the FHIR profiles, but this is not directly possible when the base FHIR resource defines required terminology that bears no direct relationship with the HCIM or UCSD. These cases include, but are not limited to, the FHIR resource elements of datatype {{datatype|code}} ({{fhir|Patient.gender}}, {{fhir|status}} elements, structural type elements, etc.). This datatype always describes FHIR specific terminology, which usually doesn't align with the HCIM/UCSD terminology.

In these cases, a mapping will be provided to explain the relationship between de HCIM/UCSD terminology and the FHIR terminology. This is normally done through a FHIR [https://hl7.org/fhir/STU3/conceptmap.html ConceptMap], which can translate between the terminology used in the HCIM/UCSD, and the terminology that FHIR instances need to adhere to. When the ConceptMap {{fhir|.equivalence}} is not {{term|equal}} or {{term|equivalent}}, the original terminology from the HCIM/UCSD SHALL be communicated as well using the extension [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/code-specification code-specification] on the same element. It is recommended to use this extension in other situations as well. This allows unambiguous interpretation on the receiver end.

Example snippet from an {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|title=AllergyIntolerance}} where both the FHIR terminology {{term|high}} and the SNOMED CT {{term|24484000}} terminology are communicated. The FHIR terminology is obtained from the HCIM terminology using ConceptMap {{Simplifier|http://nictiz.nl/fhir/ConceptMap/MateVanKritiekZijnCodelijst-to-allergy-intolerance-criticality|title=MateVanKritiekZijnCodelijst-to-allergy-intolerance-criticality}}:

<syntaxhighlight lang="xml">
<criticality value="high">
<extension url="http://nictiz.nl/fhir/StructureDefinition/code-specification">
<valueCodeableConcept>
<coding>
<system value="http://snomed.info/sct"/>
<code value="24484000"/>
<display value="Severe"/>
</coding>
</valueCodeableConcept>
</extension>
</criticality>
</syntaxhighlight>

==Use of the reference datatype==
A key feature of FHIR is the ability of resources to reference each other. This is done using the [https://hl7.org/fhir/STU3/references.html#Reference {{datatype|Reference}} datatype]. This datatype supports two modes of referencing:
; [https://hl7.org/fhir/STU3/references.html#literal Literal references], using the {{fhir|.reference}} element: A relative or absolute REST endpoint containing {{fhir|.id}} of the referenced resource. In a Bundle context, this may also be a reference to a {{fhir|Bundle.resource.fullUrl}}.
; [https://hl7.org/fhir/STU3/references.html#logical Logical references], using the {{fhir|.identifier}} element: Meaning a match on the business identifier ({{fhir|.identifier}}) for the referenced resource, without specifying where to find the referenced resource. Note: confusingly, although this reference type is called "logical reference", it does ''not'' act on the "logical identifier" ({{fhir|.id}}) of resources.

The resource/profile will usually constrain which resources may be targeted from a given element. For example, {{fhir|Patient.generalPractitioner}} may point only to an Organization or Practitioner resource, and the nl-core-patient profile further restricts this to the nl-core-organization and nl-core-practitioner profiles{{ref|weakness-target-unavailable}}.

The basic requirements for using references in this context are:
* Either a literal or logical reference SHALL be specified, unless specified otherwise.
** Literal references are preferred over logical references when multiple target resource types/profiles may be used{{ref|weakness-unknown-type}}.
* Literal references SHALL be resolvable.
** External references SHALL be regarded in the same context as the resource itself. If the current security context is insufficient for retrieving the reference, then additional negotiation for appropriate privileges may be required.
** Relative references are preferred over absolute references.
* A short description of the target resource SHALL be included using the {{fhir|.display}} element.

''Note 1'': {{note|weakness-target-unavailable}}In some circumstances, the constraints om the target are too strict for the use case and the appropriate resource can't be referenced (examples are {{fhir|Encounter.participant}}, which cannot reference a PractitionerRole resource to provide context of the attending physician, and {{fhir|Media.operator}}, which cannot target Patient resources and thus doesn't recognize patient-generated Media). In such cases, the proper reference type is added using an extension within the element that is used to refer the other resource. To aid receiving systems that cannot handle the extension, the sending system SHOULD give as much information as possible in the main element. In the case of the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/practitionerrole-reference|nictiz.fhir.nl.stu3.zib2017|title=PractitionerRole reference extension}}, this means that the sending system SHOULD populate the main element with the reference to the Practitioner resource. In most other cases, the sender SHOULD repeat the {{fhir|.display}} used in the extension in the main element.

''Note 2'': {{note|weakness-unknown-type}}There is a known weakness in the Reference datatype for FHIR STU3 which is fixed in FHIR R4: if the reference might have more than one type of resource as target, a receiving system cannot know what type is meant when only an identifier is provided.

==Relating FHIR profiles with their functional definitions==
All profiles have a traceable relationship with their functional counterpart(s) based on the element mapping mechanism in FHIR. This allows to:
# define one or more references from a FHIR profile to an external URL where the functional definition can be found
# define for each FHIR profile element to which concept ''within'' a functional definition it corresponds

The functional definition(s) underlying the profile can thus be resolved using the [https://hl7.org/fhir/STU3/structuredefinition-definitions.html#StructureDefinition.mapping {{fhir|StructureDefinition.mapping}}] metadata field of a profile. To relate a FHIR profile field to a concept from the functional description, the concept ID defined in the [https://hl7.org/fhir/STU3/dataelement-definitions.html#DataElement.mapping {{fhir|DataElement.mapping}}] can be used to look up the concept in the functional definition. It is possible that a single profile element refers concepts from multiple functional descriptions. Simplifier will show an overview of all the mappings for a FHIR profile on the dedicated 'mappings' tab, together with a clickable URL to the functional definition. In addition, on the 'overview' tab for each field the relevant mapping can be found.

For example, the profile nl-core-address defines a relationship with [https://simplifier.net/NictizSTU3-Zib2017/nl-core-address/~mappings with four functional definitions], one of which is [https://zibs.nl/wiki/AddressInformation-v1.0(2017EN) AddressInformation-v1.0(2017EN)]. This mapping is identified within the profile using 'hcim-addressinformation-v1.0-2017EN'. Looking at the {{fhir|Address.city}} element in this profile, one of the mappings is defined as 'hcim-addressinformation-v1.0-2017EN:NL-CM:20.5.3'. This reveals that this element implements (amongst others) the concept from the HCIM AddressInformation-v1.0(2017EN) described using ID 'NL-CM:20.5.3'.

==Profile use and declaration==
The implementation guides for the various information standards list the profiles to use for the FHIR resources. A profile is a statement about the rules that this resource was created against. In the interest of interoperability it is important that, when using said information standard:
* Each resource SHALL be a valid instance of the applicable profile. Note that this applies not only to profiles listed directly in the IG, but also to profiles referred from/used by listed profiles.
* Each resource SHALL include the canonical URL of this profile in the {{fhir|meta.profile}} element. The canonical of compatible base or derived profiles MAY be included as well.
* A receiving system MAY use the stated value of {{fhir|meta.profile}} for validation, documentation or other purposes.
* A receiving system MAY use other profiles than stated in {{fhir|meta.profile}}, e.g. when it has derived, more constrained profiles based on the stated meta.profile. Reasons for additional validation may include protecting the integrity of the receiving system or determination of internal process flow.

=={{fhir|Resource.text}} or "the narrative"==
The FHIR STU3 specification says instances SHOULD contain a human readable summary of the contained data, which can be used as fallback by the receiver. This human readable text is contained in the [https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text {{fhir|.text}} element] with datatype [https://hl7.org/fhir/STU3/narrative.html {{datatype|Narrative}}]. This human readable text is often referred to as "the narrative".

This implementation guide has the following expectations regarding the use of narratives:
* Senders SHOULD provide a "clinically safe" ([[#"Clinically safe" narratives|see below]]) narrative of status {{term|extensions}} (preferred) or {{term|generated}} ([[#Narrative status|see below]]), unless:
** The resource does not support narratives. This is the case for resources that do not derive from DomainResource, like Binary.
** The resource is contained in another resource.
** It is explicitly documented in the information standard to do otherwise.
* Receiver SHALL support the narrative. Ignoring the narrative is considered passive support. Support for the narrative SHALL be in accordance with the status and explicitly documented use in the relevant information standard.
* Receiver SHALL NOT generically depend on presence of a clinically safe narrative as their only means to present data to users when an explicitly documented use case for status empty or additional exists. Also, using just the narrative you would not expect to produce graphs, support for medication alerts and other functionality.

==="Clinically safe" narratives===
Regarding the contents of the narrative, the [https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text FHIR STU3 spec states] that:
<blockquote>The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative.</blockquote>
And for the Narrative datatype:
<blockquote>Structured data SHOULD NOT generally contain information of importance to human readers that is omitted from the narrative. Creators of FHIR resources should not assume that systems will render (or that humans will see) data that is not in the narrative.</blockquote>

The decision to what entails "clinically safe" information, is somewhat arbitrary. Guidelines for "clinically safe" inspired by the [https://hl7.org/fhir/STU3/w5.html FHIR W5 report]:
* If you only had the narrative: the intention and context should be clear to you.
* Who. Patient/subject, performer, author and/or other primary actors. Is this about family history or the actual patient.
* What. The topic for the resource is clear.
* When. Is this past, present, or future information.
* Why. What led up to the event. E.g. Condition, Referral that caused Encounter or Procedure.
* Where. Location of the event/action in the resource.
* Context. Relevant context as present as presented in the resource. status, Encounter, EpisodeOfCare, Diagnosis, Condition, BodySite.
* Rendering every identifier and/or code detail may not be necessary. {{fhir|Resource.text}} is for human assessment of the situation so emphasis should be on display text, representing identifier/code/system as relevant in the context.

Informal note: Producing a "clinically safe" narrative can be cumbersome. Various reference frameworks like [https://hapifhir.io/hapi-fhir/docs/model/narrative_generation.html HAPI] include a Narrative Generator of some sort.

===Narrative status===

Datatype {{datatype|Narrative}} [https://hl7.org/fhir/STU3/valueset-narrative-status.html defines different status codes] to indicate the origin of the narrative text. This implementation guide expects the most common use case to be the status {{term|extensions}}, which means that the narrative is generated entirely from the structured data and the extensions used. The reason for this is that most resources can have extension content defined on them. This status can still be used if a particular instance doesn't contain any extensions.

Alternatively, status {{term|generated}} may be used if the sender did not anticipate inclusion of regular extension content in the narrative.

'''Note''': for both status {{term|extensions}} and {{term|generated}}, all modifier extensions SHOULD be included in the narrative as they always affect the semantics.

Senders SHOULD NOT use the other possible statuses unless it is explicitly documented why, e.g. in an information standard. Receivers MAY choose to support narratives with status {{term|additional}}, which means that it holds information not contained in the structured data. Receivers - upon rendering narrative with status {{term|additional}} - SHOULD make it clear to the user that the information is a fragment, and not the entire thing, in some suitable way.

==Search==

===Search URLs and search parameters===
Each use case of the various information standards lists the search parameters to use for a client to query the relevant information on a server. Usually, this is done in the form of (a number of) search URL(s), although individual use cases may use some other form if necessary (for example, listing optional parameters). Regarding the search parameters, the following guidelines apply:

* Unless explicitly marked as optional, the listed search parameters are considered the minimum for a request, meaning that:
** All stated parameters and modifiers SHALL be supported both by clients and servers.
** All stated parameters and modifiers SHALL be used for searching as specified in the information standard.
* A client MAY use additional search parameters in the search (such as date-range) not defined in the information standard. These may serve to further constrain the result set.
* <span id="unknown_search_parameter_handling">A server MAY ignore and MAY support additional search parameters. A server SHALL report the applied parameters [https://www.hl7.org/fhir/stu3/search.html#conformance in the self link] of the response and SHOULD provide additional information about the search process using an OperationOutcome in the search result Bundle (as an entry with {{fhir|search.mode}} set to {{term|outcome}}). A client MAY use the self link and/or OperationOutcome to inform the user, independently apply these filters to the result set, or take some other action.</span>
* A server SHALL reject any search request that contains parameters suffixed by a modifier that the server does '''not''' support for that parameter. For example, if the server supports the name search parameter, but not the :exact modifier on the name, it should reject a search with the parameter {{fhir|1=name:exact=Bill}}, using an HTTP 400 error with an OperationOutcome with a clear error message.
* A server SHALL NOT return information that is out of scope for the defined use case or authorization, even if the request by the client is wider than the use case.
* Repeating search parameters constitute a logical AND. Repeating search parameter values constitute a logical OR. Where applicable, this will be described further in the implementation guide.
* The order of the search parameters is always irrelevant.

General guidance on the use of search parameters can be found [https://www.hl7.org/fhir/stu3/search.html in the FHIR specification].

====Search on date, number or quantity====
When a search parameter has a type of date, number or quantity, the request [https://www.hl7.org/fhir/stu3/search.html#prefix uses prefixes] to control the search behavior. Unless explicitly stated otherwise, the minimum set of supported prefixes for these types is {{fhir|eq}}, {{fhir|gt}}, {{fhir|lt}}, {{fhir|ge}} and {{fhir|le}}. For example:
GET [base]/Observation?date=ge2019-01-01&date=le2020-01-01
Searches on all Observation resources that have an {{fhir|.effective[x]}} between January 1, 2019 and January 1, 2020.

====The {{fhir|_lastUpdated}} search parameter====
Retrieving information that was added, changed, deleted relative to a date may be done using the search parameter {{fhir|_lastUpdated}}, which is available for any resource. Using the parameter {{fhir|_lastUpdated}}, a system may query for data that is ''new'' since a specified date. Any FHIR server is expected to support this parameter. More information can be found in [https://hl7.org/fhir/STU3/search.html#lastUpdated the section on {{fhir|_lastUpdated}}] in the FHIR specification.

An example search request is shown below.

<pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105&_lastUpdated=gt2018-10-01</pre>

This search finds all Consent resources with a category SNOMED code 11291000146105 that have been modified since Oct 1, 2018.

===Search results===
====Including referenced resources====
Servers may not support read interactions, but all references from search results need to be resolvable (see [[#Use of the reference datatype]]). Therefore servers MAY choose to include the referenced resources in the ''searchset'' Bundle, even if the client didn't use any <code>_include</code> parameters. These resources SHALL have <code>Bundle.entry.mode</code> set to "''include''". Servers SHOULD NOT use contained resources for this purpose.

====Paging====
Servers MAY use [https://www.hl7.org/fhir/stu3/search.html#count paging] for performance reasons. Client SHALL support this mechanism to prevent loss of information.

== Usage of the {{fhir|.id}}, {{fhir|.identifier}} and {{fhir|.fullUrl}} elements in FHIR instances ==

=== {{fhir|.id}} versus {{fhir|.identifier}} ===
FHIR recognizes two fields that are used as identifier for instances: {{fhir|.id}} and {{fhir|.identifier}}. Although these are both identifiers, they are unrelated and serve a completely different purpose:
* {{fhir|.id}} is the logical identifier, or technical identifier, akin to the id-field in a database. It is used as a unique handle for every instance on a particular server, and is needed to construct the URL to the instance. As such, it is used for referring between resources. The {{fhir|.id}} has no further meaning outside of the server.
* {{fhir|.identifier}} is a business identifier, which usually has a meaning ''outside'' of the server. Examples are a registration number of a healthcare provider, a BSN or social security number for citizens, ISBNs for books, etc. Any instance may have multiple kinds of identifiers.

=== When is {{fhir|.identifier}} expected? ===
Systems that use an (internal) stable identifier to track information are encouraged to assign it to the {{fhir|.identifier}} element of FHIR instances when sending the resource, using a custom identifier {{fhir|.system}} (e.g. an URL or OID that is under control of the sending organization). Because in HL7v3 (CDA) an identifier can only be composed using OIDs, the {{fhir|.system}} should preferably be an OID to accommodate compatibility in transformations from FHIR. Especially for resources that are used in information standards that have a HL7v3 (CDA) component, such as the BgZ, GP data and Medication process.

The presence of this element helps receiving systems with re-identification and deduplication of resources, especially when the sender system does not natively support logical ids.

Specific requirements for the usage of {{fhir|.identifier}} will be dictated on a use case basis by the particular profiles.

=== When is {{fhir|.id}} expected? ===
As stated above, the logical id is meant to uniquely identify instances on a particular server; it is a vital component when using FHIR within a RESTful context. So as a rule of thumb, the {{fhir|.id}} element should always be present when dealing with instances that have a logical id, thus with instances on a server. This means:
* When a client reads, updates or otherwise addresses an existing resource on a server, the {{fhir|.id}} element SHALL be populated in the request and response, and it SHALL match the id in the request URL.
* When a client sends a ''new'' instance to a server using a create operation, the <code>id</code> element is ''not'' expected to be present -- these new instances don't exist yet on the server, so a logical id has no meaning. However, the server SHALL assign a logical id and populate the {{fhir|.id}} element in the response.<br/>''Note'': It is not strictly prohibited to populate the {{fhir|.id}} field when sending a new instance, but the server SHOULD ignore it.
* When a client performs a search on a server, all instances in the returned searchset Bundle SHOULD have the {{fhir|.id}} field populated.<br/>''Note'': A server SHOULD try its best to create stable ids for the resources it serves. Omitting {{fhir|.id}} elements is strongly discouraged as it breaks the assumptions about RESTful behavior. However, a server that omits {{fhir|.id}}s is still considered conformant when the conditions below are met:
*# The server does not natively support logical ids, for example when it is a stateless middleware server that gets its input from a non-FHIR XIS backend.
*# ''And'' the use case doesn't require read / update / delete / patch support for any of the returned of referenced resources, as stated by the CapabilityStatement for the information standard.
*# ''And'' the server includes all referenced resources in the searchset Bundle (regardless of whether the client asked to do so). These resources refer to each other based on the fullUrl mechanism as described below.

=== Logical ids, {{fhir|.fullUrl}}s and references in Bundles ===

There are several FHIR operations, like searching or batch create operations, where multiple instances are placed together in a Bundle. These instances will usually contain references to each other. These internal references cannot be resolved simply by inspecting the {{fhir|.id}} element of every instance; it is not guaranteed that all instances have a logical id. Instead, Bundles allow an {{fhir|entry.fullUrl}} element for each instance which may be used for references. This is an additional mechanism to the logical id, not a replacement:
* The [[#When_is_id_expected.3F|guidelines above]] for populating the {{fhir|.id}} field still apply.
* If {{fhir|.id}} is present, {{fhir|.fullUrl}} SHALL correspond with it (see below).

{{fhir|.fullUrl}}s may be RESTful URLs, UUIDs or even OIDs, based on the situation (which may be mixed within the same Bundle):
; Instances with a logical id: If an instance can be accessed on the server using RESTful operations, the {{fhir|.id}} of that instance in the Bundle will be populated. The corresponding {{fhir|.fullUrl}} in this case SHALL be the absolute URL to the instance on the server.<p>Instances within the Bundle may use relative references to each other, like they are on the same server. The FHIR machinery specifies how to find the matching instance based on the {{fhir|.fullUrl}}.</p>
; Instances without a logical id: When instances are to be created on a server or when the server doesn't support reading individual instances, they don't have a logical id. When these id-less instances need to be referenced from within a Bundle, there are two alternatives:
:* <span id="uuid-as-logical-id"></span>UUIDs can be used as single-use ids that will change each time the Bundle is generated. The {{fhir|.fullUrl}} for the instance will be the UUID prefixed with <code><nowiki>urn:uuid:</nowiki></code>. <ref name="id-ambiguous">Some implementations may choose to populate the {{fhir|.id}} element with the unprefixed UUID or OID in cases when the {{fhir|.id}} field is expected, for example in searchset Bundles. The FHIR specification is ambiguous on the requirements to do so. For a long discussion on the topic, see [https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Confused.20about.20URN.20fullUrl's.20and.20resource.2Eid's chat.fhir.org].</ref>
:* <span id="oid-as-logical-id"></span>OIDs can be used if the instance has an OID-based ''business'' identifier (i.e. the {{fhir|.identifier}} field), like the UZI number of a healthcare provider. The {{fhir|.fullUrl}} will be the OID prefixed with <code><nowiki>urn:oid:</nowiki></code><ref name="id-ambiguous"/><ref>The use of OIDs as id has some limitations:
* The {{fhir|.id}} has a maximum length of 64 characters, so only OIDs that contain less than 64 characters can be used.
* OID based ids are expected to be stable, just like RESTful ids. Different Bundle instances SHALL always use the same OID based ids.
* Some ''objects'' may have multiple OID based identifiers, like AGB and UZI for practitioners. Which one do you choose? And what happens when the UZI number becomes available after you've already used the AGB as {{fhir|.id}}?
* Specifically for HL7 V3 based backends: an HL7 V3 II datatype normally consists of a <code>@root</code> (OID) and an <code>@extension</code> (string). Concatenation of <code>@root</code> and <code>@extension</code> only yields a new OID if <code>@extension</code> is numeric. Other combinations of <code>@root.@extension</code>, may yield a valid {{fhir|.id}} (pattern <code>[A-Za-z0-9\-\.]{1,64}</code>), but may not be a valid OID. In this case it is no longer possible to create a {{fhir|.fullUrl}} consistent with the {{fhir|.id}} based the <nowiki>urn:oid:</nowiki> scheme.</ref>.
: Instances within the Bundle should use the prefixed version of the UUID/OID for referencing.

==== Example ====
Consider a client that wants to send a new Observation instance to a server and simultaneously link it to an existing Task instance. This can be done using a transaction Bundle:
<syntaxhighlight lang="xml" highlight="7-8,11,23-24,27-28,33-34,41-42" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">

<type value="transaction"/>


<entry>

<fullUrl value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e"/>
<resource>
<Observation>

...
</Observation>
</resource>
</entry>
<request>
<method value="POST"/>
<url value="Observation"/>
</request>


<entry>

<fullUrl value="http://example-xis.com/Task/1234"/>
<resource>
<Task>

<id value="1234"/>
...
<output>
...
<valueReference>

<reference value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e"/>
</valueReference>
</output>
</Task>
</resource>
<request>
<method value="PUT"/>

<url value="Task/1234"/>
</request>
</entry>
</Bundle>
</syntaxhighlight>

The server response should then look like:
<syntaxhighlight lang="xml" highlight="5-6,9-10,28-29" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">
<type value="transaction-response"/>

<entry>

<fullUrl value="http://example-xis.com/QuestionnaireResponse/5678"/>
<resource>
<Observation>

<id value="5678"/>
...
</Observation>
</resource>
</entry>
<response>
....
</request>

<entry>
<fullUrl value="http://example-xis.com/Task/1234"/>
<resource>
<Task>
<id value="1234"/>
...
<output>
...
<valueReference>

<reference value="Observation/5678"/>
</valueReference>
</output>
</Task>
</resource>
<response>
....
</response>
</entry>
</Bundle>
</syntaxhighlight>

== 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/STU3/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|.detail}} 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/stu3/http.html on error handling in general], [https://www.hl7.org/fhir/stu3/security.html#AccessDenied access denied responses] and [https://www.hl7.org/fhir/stu3/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 an 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
* OperationOutcome with {{fhir|.code}} set to {{term|security}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Not_authorized|Example]]
|-
| 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:Vprepub-1.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:Vprepub-1.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:Vprepub-1.0 FHIR_Error_handling_examples#Syntactically_incorrect_parameter|Example]]
|-
| Known but unsupported value. This situation applies to non-supported HCIM profiles when the Resource endpoint itself is supported.
|
* HTTP 200 OK
* Empty Bundle of {{fhir|.type}} {{term|searchset}}
* OperationOutcome in Bundle as an entry marked with {{fhir|Bundle.entry.search.mode}} of {{term|outcome}}.
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}} and {{fhir|.severity}} not set to {{term|fatal}} or {{term|error}}.
| [[FHIR:Vprepub-1.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:Vprepub-1.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:Vprepub-1.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:Vprepub-1.0 FHIR_Error_handling_examples#Resource_syntax_or_data_is_incorrect_or_invalid|Example]]
|}
<section end=OverarchingPrinciples />
<section begin=FHIRPackages />

==CapabilityStatements==
Information standards may have a [https://www.hl7.org/fhir/stu3/capabilitystatement.html CapabilityStatement] that is informative in nature and does not represent the minimum or maximum set of capabilities the client or server should support. Nictiz will strive to provide CapabilityStatements that are as complete as possible, however for the exact set of capabilities the implementation guide of the corresponding information standard should be consulted.

==Referring other resources when sending information==
When the client creates/updates a resource on a server, it often needs to reference "secondary" resources which are not the primary focus of the interaction -- e.g. an Observation must indicate its subject using a reference to a Patient resource. The client may refer to existing resources on the server for this, but this is not always possible (for example, the client doesn't know about the existing resource or the server doesn't support the {{fhir|read}} operation for it). In this case, the client needs to send the secondary resources along with the primary resource in a Bundle, and the server should align these new resources with the ones it already has.

A data conflict may arise if these secondary resources carry details that are not of interest within the particular context of the information standard. For example, the client posts an Observation and sends along a Patient resource containing a different telephone number than the one that is on record at the server side. This change in telephone number is not relevant in this particular context, since the interaction is about creating the Observation.

Unless more specific guidance is given by the information standard, the following guidance applies:
* Sending secondary resources SHALL only be done when the information standard specifies that a {{fhir|batch}} or {{fhir|transaction}} operation is to be used.
* If so, the client MAY send a bare-bones instance as the secondary resource containing just minimal information, but this SHOULD include the information necessary for the server to match its own copy. The information standard MAY specify which information is minimally needed for such a secondary resource and MAY also restrict the information that is sent in the secondary resource.
* The client MUST include a {{fhir|Bundle.entry.request}} for each of the resources in the Bundle, including the secondary resources that are only there for referencing purposes<ref>Although {{fhir|Bundle.entry.request}} is not formally required in FHIR STU3, it is made clear in FHIR R4 that the expected behavior actually is to include it.</ref>. {{fhir|.request}} SHOULD be a <code>POST</code> to the appropriate endpoint. As an alternative, <code>PUT</code> MAY be used, but is strongly discouraged; if the client has knowledge on the id of the resource on the server, an absolute URL is strongly preferred.
* If the server can unequivocally de-duplicate this secondary resource (for example, because the patient is already known from the security context or the healthcare provider is recognized by the UZI number), it MAY choose to ignore the differences of this resource or it MAY incorporate them (see the [https://www.hl7.org/fhir/stu3/http.html#transactional-integrity the section on transactional integity] in the FHIR specification). Please note that absence of information should not result in deletion of information on the server, as the client could send a bare-bones instance.
** If a {{fhir|transaction}} operation is used and the server chooses to ignore the differences, it SHOULD do so silently by responding with a 200 OK status code for the corresponding {{fhir|Bundle.entry.response.status}} in the response Bundle.
** If a {{fhir|batch}} operation is used and the server chooses to ignore the differences, it SHOULD do so either silently using the mechanism described above, or explicitly by responding with a 422 Unprocessable Entity status code {{fhir|Bundle.entry.response.status}} to indicate that a business rule prevented the resource from being created (in combination with an OperationOutcome resource).
* The server SHALL rewrite the references in the primary resource to the resource it already has.

=FHIR Packages=
The information standards maintained by Nictiz adopt 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.

Please note that every effort has been made to ensure that the examples contained in the packages are correct and useful, but they are not a normative part of any information standard.

For even more background information:
* [https://confluence.hl7.org/display/FHIR/NPM+Package+Specification The HL7 base specification for FHIR pacakges]
* [https://blog.fire.ly/2017/11/28/versioning-and-canonical-urls/ What is the problem that packaging could address]
* [https://simplifier.net/organization/firely/news/55 Introducing the Simplifier FHIR Package Server] (includes what problem packaging addresses)
* [https://simplifier.net/organization/firely/news/56 Firely Torinox introduction] (this is one of the tools that's useful for working with FHIR packages)

{{NoteBox|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.}}
<section end=FHIRPackages />

FHIR:Vprepub-1.0 FHIR IG STU3

2021-10-21T14:51:20Z

Eduard de Rijcke: MM-2436 Merge to vPrepub

MedMij:V2020.02/Ontwerpen

2021-09-20T07:57:04Z

Eduard de Rijcke: MM-2325 Merged to veprepub 2020.02

__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Ontwerpen MedMij|Functioneel Ontwerpen}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.02/Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.02/FHIR_IG|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
{{#lsth:MedMij:V2020.01/Ontwerpen|Algemeen}}
==Doelgroep==
{{#lsth:MedMij:V2020.01/Ontwerpen|Doelgroep}}
==Kaders en uitgangspunten==
===Richtlijn===
====Zorginformatiebouwstenen en gegevenssets====
{{#lsth:MedMij:V2020.01/Ontwerpen|Zorginformatiebouwstenen en gegevenssets}}
====Terminologie en vertalingen====
Richtinggevend voor de applicaties die MedMij-standaarden implementeren is dat ze Nederlandse termen gebruiken. Dit wordt op de volgende wijze functioneel en technisch ondersteund.

'''Functioneel'''

De functionele definities van de MedMij-informatiestandaarden zijn zoveel mogelijk samengesteld uit bestaande zibs. De zibs bevatten veel (eigen) waardelijsten. Bij deze waardelijsten wordt een Nederlandse vertaling gegeven.

Voor het verwerken en tonen van waarden uit bestaande terminologie- en codestelsels (zoals SNOMED CT en LOINC) in een PGO, kan het volgende uitgangspunt gehanteerd worden:

*Indien er een Nederlandse patiëntvertaling beschikbaar is, toon deze aan de PGO-gebruiker.
*Indien een Nederlandse patiëntvertaling ontbreekt, maar er wel een Nederlandse zorgverlenervertaling beschikbaar is, toon deze aan de PGO-gebruiker.
*Indien zowel een Nederlandse patiëntvertaling als een zorgverlenervertaling ontbreken in het terminologie- of codestelsel, volg de dataset, waarin voor uitgewerkte waardelijsten ook Nederlandse termen beschikbaar zijn.
*Indien Nederlandse vertaling geheel ontbreekt, kan de Engelse term getoond worden.

Meer informatie over eventueel benodigde licentie en implementatie van terminologie- en codestelsels is te vinden in het [https://www.nictiz.nl/overzicht-standaarden/ standaarden overzicht van Nictiz]

Ook wat betreft de omschrijving van informatie geniet het de voorkeur om ze veel mogelijk gebruik te maken van Nederlandse termen. De (omschrijvingen van de) conceptnamen die in zibs gehanteerd worden, kunnen gebruikt worden, evenals correcte Nederlandse synoniemen daarvan die mogelijk beter aansluiten op het persoonsdomein.

'''Technisch'''

Voor de waardelijsten in de zibs zijn FHIR ValueSet-resources gemaakt. Deze bevatten gestructureerd de Nederlandse vertalingen van de zib-concepten en worden dus bij de standaard aangeboden. Leveranciers kunnen bij het weergeven van concepten uit deze ValueSets dan ook kiezen voor de Nederlandse vertaling.

De ValueSets zijn óf direct gekoppeld in de FHIR-profielen, of kunnen, indien dit niet mogelijk is, via een FHIR ConceptMap gerelateerd worden aan de waarden die binnen een profiel gebruikt worden. Zie hiervoor de specificaties in de [[MedMij:Vprepub-2020.02/FHIR_IG#Use_of_coded_concepts|FHIR-implementatiegids]].
====Referenties====
MedMij informatiestandaarden gebruiken zoveel mogelijk bestaande zibs. Deze zibs verwijzen naar elkaar middels referenties. FHIR kent ook het concept van referenties. Via zo'n referentie kan bijvoorbeeld ook het specialisme van een zorgverlener bij een verrichting opgehaald worden. Het uitgangspunt is dat alle references 'resolvable' (opvraagbaar) moeten zijn, niet dat ze resolved worden. Een PGO zou er ook voor kunnen kiezen om een klikbare link te tonen, waarmee een gebruiker (de persoon) desgewenst zelf kan 'resolven', eventueel zelfs in een nieuwe sessie (na de initiële 15 minuten). Meer informatie over het gebruik van FHIR-references binnen MedMij is te vinden in de informatiestandaardoverstijgende principes in de [[MedMij:Vprepub-2020.02/FHIR_IG#Use_of_the_reference_datatype |FHIR-implementatiegids]].

===Infrastructuur===
{{#lsth:MedMij:V2020.01/Ontwerpen|Infrastructuur}}
===Geografische reikwijdte===
{{#lsth:MedMij:V2020.01/Ontwerpen|Geografische reikwijdte}}
==Kwalificatie==
===Introductie===
<section begin=medmij_kwalificatie_introductie />
Op deze informatiestandaard is een Nictiz kwalificatie van toepassing. Kwalificatie vindt plaats per systeemrol.

Kwalificatiescripts en meer informatie over de kwalificatie is te vinden via de betreffende paragraaf op de [[MedMij:Vprepub-2020.02/Kwalificatie|kwalificatiepagina]].<section end=medmij_kwalificatie_introductie /><section end=medmij_kwalificatie_introductie />

=Wiki structuuroverzicht=
Onderstaande afbeelding geeft een overzicht van de MedMij wiki pagina structuur. Het afsprakenstelsel verwijst naar de MedMij landingspagina die op zijn beurt verwijst naar de functionele en technische ontwerpen. Vanaf deze pagina, de hoofdpagina van de functionele ontwerpen, wordt verwezen naar de onderliggende functionele ontwerp pagina's middels de onderstaande 'patient journeys' en tabel overzicht. De functionele ontwerp beschrijvingen hebben een technische wiki pagina als tegenhanger. Vanuit de leeswijzer afbeelding, bestaande uit drie iconen, bovenaan de pagina is het mogelijk makkelijk door te linken naar de technische pagina's.

<imagemap>Bestand:MedMij_wiki_structuur_overzicht.png||650px|alt=MedMij Wiki structuur overzicht
circle 344 894 333 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
rect 1017 1260 1517 1407 [[Landingspagina_MedMij#Mappings|Mappings]]
rect 2123 3 2740 847 [[MedMij:Vprepub-2020.02/Ontwerpen|Functioneel]]
rect 2123 945 2740 1789 [[MedMij:Vprepub-2020.02/FHIR_IG|Technisch]]
desc none
</imagemap>

=Ontwerpen=
Patient journeys beschrijven de mogelijkheden die MedMij biedt vanuit het perspectief van een fictieve patiënt. Deze paragraaf start met de [[#Patient_journeys| Patient journeys]] die MedMij hanteert.

De paragraaf vervolgt met een index in tabelvorm gesplitst naar de use cases van het afsprakenstelsel:
* [[#Haal_gegevens_op_uit_XIS|Haal gegevens op uit XIS]]
* [[#Stuur_gegevens_naar_XIS|Stuur gegevens naar XIS]]

==Haal gegevens op uit XIS==
===Algemeen===
Een persoonlijke gezondheidsomgeving (PGO) haalt gegevens op bij een zorginformatiesystemen (XIS). Onderstaande tabel geeft een overzicht van de use cases uit informatiestandaarden in publicatie 2020.02 die van toepassing zijn voor het raadplegen van informatie.
{| class="wikitable"
| style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:center; border: 1px solid black;" colspan="6" | Index raadplegen / beschikbaarstellen
|-style="background-color: #4AB8A7;; color: white; text-align:left; border: 1px solid black;"
|style="width:200px; border: 1px solid black;" colspan="2"| Informatiestandaard
|style="width:20px; border: 1px solid black;"| Versie
|style="width:600px; border: 1px solid black;"| Use case
|style="width:200px; border: 1px solid black;"| Functioneel
|style="width:200px; border: 1px solid black;"| Technisch
|-style="background-color: white;"
|[[Bestand:BgLZ-icon.png|link=MedMij:V2020.01/OntwerpLangdurigeZorg|49px|Basisgegevens Langdurige Zorg]]||Basisgegevens Langdurige Zorg||||Basisgegevens Langdurige Zorg raadplegen|| [[MedMij:Vprepub-2020.02/OntwerpLangdurigeZorg|BgLZ ]] ||[[MedMij:Vprepub-2020.02/FHIR_BGLZ|BgLZ in FHIR]]
|-style="background-color: white;"
|}
Onderstaande tabel geeft een overzicht van de use cases uit de overige informatiestandaarden die van toepassing zijn voor het raadplegen van informatie.
{{NoteBox|1= De informatiestandaarden in onderstaande tabel maken geen deel uit van publicatie 2020.02. De links verwijzen naar de meest recente publicatie.}}
{| class="wikitable"
| style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:center; border: 1px solid black;" colspan="6" | Index raadplegen / beschikbaarstellen
|-style="background-color: #4AB8A7;; color: white; text-align:left; border: 1px solid black;"
|style="width:200px; border: 1px solid black;" colspan="2"| Informatiestandaard
|style="width:20px; border: 1px solid black;"| Versie
|style="width:600px; border: 1px solid black;"| Use case
|style="width:200px; border: 1px solid black;"| Functioneel
|style="width:200px; border: 1px solid black;"| Technisch
|-style="background-color: white;"
|[[Bestand:BGZ_icoon_zonder_tekst.png|link=https://www.nictiz.nl/standaarden/basisgegevensset-zorg|Basissetgegevens Zorg|49px]]||[https://www.nictiz.nl/standaarden/basisgegevensset-zorg Basisgegevensset Zorg]||||[https://www.nictiz.nl/standaarden/basisgegevensset-zorg Basisgegevensset Zorg]||[[MedMij:V2020.01/OntwerpBGZ_2017#Use_case_1:_Raadplegen_Basisgegevensset_Zorg_in_persoonlijke_gezondheidsomgeving|BgZ]]||[[MedMij:V2020.01/FHIR_BGZ_2017|BgZ in FHIR]]
|-
|[[Bestand:Lab.png|link=https://www.nictiz.nl/standaardisatie/informatiestandaarden/laboratoria|Labuitwisseling|49px]]||[https://www.nictiz.nl/standaardisatie/informatiestandaarden/laboratoria Labuitwisseling]||||Laboratoriumresultaten ||[[MedMij:V2020.01/OntwerpLabresult#Use_case:_Raadplegen_laboratoriumresultaten_in_persoonlijke_gezondheidsomgeving|Laboratoriumresultaten]]||[[MedMij:V2020.01/FHIR_LaboratoryResults|Laboratoriumresultaten in FHIR]]
|-style="background-color: white;"
|rowspan="3"|[[Bestand:Medicatie.png|link=https://www.nictiz.nl/Paginas/Informatiestandaard-Medicatieproces.aspx|49px]]
|rowspan="3"|[https://www.nictiz.nl/Paginas/Informatiestandaard-Medicatieproces.aspx Medicatieproces]
|rowspan="3"|
||Medicatieoverzicht
||[[MedMij:V2020.01/OntwerpMedicatie#Use_case:_Raadplegen_medicatieoverzicht_in_persoonlijke_gezondheidsomgeving|Medicatieoverzicht]]
||[[MedMij:V2020.01/FHIR_MedicationProcess#Use_case:_retrieve_medication_overview |Medicatieoverzicht in FHIR]]
|-style="background-color: white;"
||Medicatiegegevens ||[[MedMij:V2020.01/OntwerpMedicatie#Use_case:_Raadplegen_medicatiegegevens_door_pati.C3.ABnt|Medicatiegegevens]]
||[[MedMij:V2020.01/FHIR_MedicationProcess#Use_case:_retrieve_medication_information |Medicatiegegevens in FHIR]]
|-style="background-color: white;"
||Verstrekkingenvertaling||[[MedMij:V2020.01/OntwerpMedicatie#Use_case:_Raadplegen_verstrekkingenvertaling_.28medicatieverstrekkingen_van_het_LSP.29_door_pati.C3.ABnt|Verstrekkingenvertaling]]
||[[MedMij:V2020.01/FHIR_MedicationProcess#Use_case:_retrieve_medication_information|Verstrekkingenvertaling in FHIR]]
|-
|rowspan="2"|[[Bestand:Allergie.png|link=MedMij:V2020.01/OntwerpAllergieIntolerantie| AllergieIntolerantie|49px]]
|rowspan="2"|[[MedMij:V2020.01/OntwerpAllergieIntolerantie | AllergieIntolerantie]]
|rowspan="2"|
||Allergie/intolerantie ||[[MedMij:V2020.01/OntwerpAllergieIntolerantie| AllergieIntolerantie]] ||[[MedMij:V2020.01/FHIR_AllergyIntolerance#Use_case:_Retrieve_AllergyIntolerance_information|AllergieIntolerantie in FHIR]]
|-
||Allergie/intolerantie vertaling ||[[MedMij:V2020.01/OntwerpAllergieIntolerantie#Use_case_2:_Raadplegen_medicatiegerelateerde_allergie-_en_intolerantiegegevensvertaling_door_pati.C3.ABnt| AllergieIntolerantieVertaling]] ||[[MedMij:V2020.01/FHIR_AllergyIntolerance#Use_case:_Retrieve_AllergyIntolerance612ToFHIRConversion|AllergieIntolerantieVertaling in FHIR]]
|-style="background-color: white;"
|[[Bestand:EAfspraak_icoon_zonder_tekst.png|link=MedMij:V2020.01/OntwerpeAfspraak|49px]]
||eAfspraak
||||Afspraken raadplegen
||[[MedMij:V2020.01/OntwerpeAfspraak#Use_case:_Afspraak_raadplegen_door_pati.C3.ABnt| eAfspraak]]
|| [[MedMij:V2020.01/FHIR_eAfspraak| eAfspraak in FHIR]]
|-
|[[Bestand:Self-Measuements_zonder_tekst.png|link=MedMij:V2020.01/OntwerpZelfmetingen|49px]]
||Zelfmetingen
||||Zelfmetingen raadplegen||[[MedMij:V2020.01/OntwerpZelfmetingen|Zelfmetingen]]||[[MedMij:V2020.01/FHIR_VitalSigns|Zelfmetingen in FHIR]]
|-style="background-color: white;"
|[[Bestand:PDF-A_icoon_zonder_tekst.png|PDF/A|49px]]
||PDF/A
||||PDF/A raadplegen ||[[MedMij:V2020.01/OntwerpPDFA| PDF/A]] ||[[MedMij:V2020.01/FHIR_PDFA|PDF/A in FHIR]]
|-
|[[Bestand:Huisartsgegevens-zonder-tekst-dun.png|link=MedMij:V2020.01/OntwerpHuisartsgegevens|49px|Huisartsgegevens]]||Huisartsgegevens|||| Huisartsgegevens || [[MedMij:V2020.01/OntwerpHuisartsgegevens|Huisartsgegevens]] ||[[MedMij:V2020.01/FHIR_GP_Data|GP data in FHIR]]
|-style="background-color: white;"
|[[Bestand:GGZ-59.-zondertekst.png|49px|GGZ]]
||Basisgegevens GGZ|||| Basisgegevens GGZ|| [[MedMij:V2020.01/OntwerpGGZ|Basisgegevens GGZ]] ||[[MedMij:V2020.01/FHIR_GGZ|GGZ data in FHIR]]
|-
|[[Bestand:vragenlijstenIcoon.png|link=MedMij:V2020.01/OntwerpVragenlijsten|49px|Vragenlijsten]]
||Vragenlijsten||||Vragenlijsten||[[MedMij:V2020.01/OntwerpVragenlijsten|Vragenlijsten]] ||[[MedMij:V2020.01/FHIR_Questionnaire_and_Questionnaire_Response_(Vragenlijsten)|Vragenlijsten in FHIR]]
|}

===What's new===
Een PGO kan na een eerste raadpleging nieuwe of gewijzigde gegevens raadplegen middels een "what's new" uitvraag. Voordeel van deze functionaliteit is dat niet onnodig reeds bekende gegevens opnieuw beschikbaar gesteld hoeven te worden. Denk hierbij aan wederom raadplegen van een volledige gegevensset zoals de BgZ. PGO dient hiervoor de datum van eerdere raadpleging te bewaren, om te gebruiken in een nieuwe raadpleging. XIS dient deze datum te kunnen verwerken. Technische uitwerking staat in de [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Use_case_overarching_principles "overarching principles" van het technisch ontwerp].

==Stuur gegevens naar XIS==
Een persoonlijke gezondheidsomgeving (PGO) stuurt gegevens naar een zorginformatiesystemen (XIS). Onderstaande tabel geeft een overzicht van de use cases uit informatiestandaarden die van toepassing zijn voor het sturen van informatie.
{{NoteBox|1= De informatiestandaarden in onderstaande tabel maken geen deel uit van publicatie 2020.02. De links verwijzen naar de meest recente publicatie.}}
{| class="wikitable"
| style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:center; border: 1px solid black;" colspan="6" | Index sturen / ontvangen
|-style="background-color: #4AB8A7;; color: white; text-align:left; border: 1px solid black;"
|style="width:200px; border: 1px solid black;" colspan="2"| Informatiestandaard
|style="width:20px; border: 1px solid black;"| Versie
|style="width:600px; border: 1px solid black;"| Use case
|style="width:200px; border: 1px solid black;"| Functioneel
|style="width:200px; border: 1px solid black;"| Technisch
|-

|-style="background-color: white;"
|[[Bestand:Self-Measuements_zonder_tekst.png|link=|50px|Zelfmetingen]]||Zelfmetingen||||Zelfmetingen sturen||[[MedMij:V2020.01/OntwerpZelfmetingen#Use_case:_Sturen_zelfmetingen_van_de_vitale_functies_door_pati.C3.ABnt|Zelfmetingen]]||[[MedMij:V2020.01/FHIR_VitalSigns|Zelfmetingen in FHIR]]
|-
|-style="background-color: white;"
|[[Bestand:PDF-A_icoon_zonder_tekst.png|link=|50px|PDF/A]]||PDF/A||||PDF/A|||[[MedMij:V2020.01/OntwerpPDFA#Use_case:_Sturen_medische_gegevens_in_PDF.2FA_door_pati.C3.ABnt| PDF/A]]||[[MedMij:V2020.01/FHIR_PDFA|PDF/A in FHIR]]
|-
|[[Bestand:Beelden.png|link=|50px|Beelden]]||Beelden||||Beelden sturen|||[[MedMij:V2020.01/OntwerpBeelden|Beelden]] || [[MedMij:V2020.01/FHIR_Images|Beelden in FHIR]]
|-style="background-color: white;"
|[[Bestand:vragenlijstenIcoon.png|link=MedMij:V2020.01/OntwerpVragenlijsten|50px|Vragenlijsten]]
||Vragenlijsten||||Vragenlijsten|| [[MedMij:V2020.01/OntwerpVragenlijsten|Vragenlijsten]] ||[[MedMij:V2020.01/FHIR_Questionnaire_and_Questionnaire_Response_(Vragenlijsten)|Vragenlijsten in FHIR]]
|}

==Patient journeys==
{{#lsth:MedMij:V2020.01/Ontwerpen|Patient journeys}}
=Systeemrollen=
{{#lsth:MedMij:V2020.01/Ontwerpen|Systeemrollen}}
=Release notes=
{| class="wikitable" "cellpadding="10" style="background-color: white;"
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving
|-
{{ReleaseNotes|package=2020.02 - Augustus 2021|issues=1|MM-2316}}
{{ReleaseNotes|package=2020.02 - Juli 2021|issues=2|MM-2227|MM-2205}}
{{ReleaseNotes|package=2020.02 - Juni 2021|issues=2|MM-2101|MM-2155}}
{{ReleaseNotes|package=2020.02 - Mei 2021|issues=7|MM-2102|MM-2093|MM-2074|MM-2057|MM-2056|MM-1882|MM-1839}}
{{ReleaseNotes|package=2020.02 - April 2021|issues=1|MM-1976}}
{{ReleaseNotes|package=2020.02 - Maart 2021|issues=9|MM-1911|MM-1906|MM-1899|MM-1861|MM-1846|MM-1752|MM-1750|MM-1122|MM-1091}}
{{ReleaseNotes|package=2020.02 - Februari 2021|issues=10|MM-1828|MM-1787|MM-1758|MM-1722|MM-1703|MM-1662|MM-1650|MM-1578|MM-1462|MM-836}}
{{ReleaseNotes|package=2020.02 - Januari 2021|issues=8|MM-1675|MM-1651|MM-1593|MM-1592|MM-1566|MM-1465|MM-1385|MM-1292}}
{{ReleaseNotes|package=2020.02 - November 2020|issues=4|MM-1557|MM-1542|MM-1522|MM-1517}}
{{ReleaseNotes|package=2020.01 - Oktober 2020|issues=8|MM-1457|MM-1454|MM-1446|MM-1441|MM-1418|MM-1386|MM-1248|MM-791}}
{{ReleaseNotes|package=2020.01 - September 2020|issues=8|MM-1406|MM-1374|MM-1358|MM-1261|MM-1256|MM-1207|MM-1116|MM-267}}
{{ReleaseNotes|package=2020.01 - Zomerrelease 2020|issues=12|MM-1220|MM-1177|MM-1165|MM-1119|MM-1118|MM-1090|MM-1050|MM-1036|MM-854|MM-437|MM-433|MM-221|}}
{{ReleaseNotes|package=2019.01 - Mei 2020|issues=8|MM-1175|MM-1169|MM-1167|MM-1155|MM-1095|MM-1083|MM-1081|MM-1054|}}
{{ReleaseNotes|package=2019.01 - April 2020|issues=7|MM-1053|MM-1015|MM-1002|MM-929|MM-770|MM-672|MM-513}}
{{ReleaseNotes|package=2019.01 - Maart 2020|issues=10|MM-969|MM-947|MM-943|MM-942|MM-938|MM-930|MM-894|MM-888|MM-815|MM-751}}
{{ReleaseNotes|package=2019.01 - Februari 2020|issues=4|MM-913|MM-857|MM-831|MM-827}}
|-
| rowspan = 10; style="background-color: white;"| 2019.01 - Januari 2020
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-800 MM-800]
| style="background-color: white;"| The contact info of the ValueSets included the invalid url "<nowiki>https://www.zibs.nl</nowiki>". This has been changed to the valid url "<nowiki>https://zibs.nl</nowiki>".
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-780 MM-780]
| style="background-color: white;"| Changed equivalence type from specializes to subsumes for 2 concept mappings in ConceptMap TelecomSoortCodelijst-to-ContactPointSystem.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-778 MM-778]
| style="background-color: white;"| Added bi-directional extension to each ConceptMap and set to true if bidirectional or false if not bidirectional. Secondly added the code.specification extension to the FHIR-profiles where the extension was not added yet: zib-AllergyIntolerance, zib-Encounter, zib-Problem, nl-core-contactpoint.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-738 MM-738]
| style="background-color: white;"| Changed required binding for extensible on Patient.maritalStatus ValueSet reference in nl-core-patient FHIR-profile.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-659 MM-659]
| style="background-color: white;"| Improved searchInclude element in all CapabilityStatements based on [resource]:[search param].
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-636 MM-636]
| style="background-color: white;"| Changed the mandatory nature of the display element in coded concepts from SHALL to SHOULD.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-632 MM-632]
| style="background-color: white;"| Restructured, renamed and optimized FHIR-examples.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-619 MM-619]
| style="background-color: white;"| In the LanguageProficiency extension for nl-core-patient:
* Added description on how to use the extension in the nl-core-patient profile in relation to HCIM LanguageProficiency
* Swapped type and level
* Changed display values to more descriptive terms
* Restricted cardinality of both type and level to 1..1
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-563 MM-563]
| style="background-color: white;"| Removed unnecessary constraint on Humanname.extension:humannameassemblyOrder extension in nl-core-humanname FHIR profile.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-296 MM-296]
| style="background-color: white;"| Added explanation for the use of ConceptMaps and mappings to the FHIR IG.
|-
| rowspan = 1; style="background-color: white;"| 2019.01 - November
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-734 MM-734]
| style="background-color: white;"| Remove old ValueSet files that still lingered in the package after they were re-exported under a different file name.
|-
| rowspan = 2; style="background-color: white;"| 2019.01 - Oktober
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-580 MM-580]
| style="background-color: white;"| Some ValueSet files used a notation that is not used anymore in newer exports from ART-DECOR. The ValueSet files in the repository and package are re-exported from ART-DECOR. ValueSet files that are not used anymore are removed from the repository and package.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-229 MM-229]
| style="background-color: white;"| Added base profile nl-core-observation to FHIR profiles based on core resource Observation.
|-
| rowspan = 6; style="background-color: white;"| 2019.01 - September
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-570 MM-570]
| style="background-color: white;"|
Removed duplicate files on Simplifier with the following id's:
* MediaContentTypeCodelijst
* careplan-activity-goal
* careplan-medicaldevice
Adjusted duplicate id's in examples.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-461 MM-461]
| style="background-color: white;"| De Richtlijn paragraaf was toegespitst op BgZ. Tekst is generiek herschreven met minder nadruk op BgZ.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-441 MM-441]
| style="background-color: white;"| Verbeteren richtlijn omtrent gebruik Nederlandse vertalingen.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-438 MM-438]
| style="background-color: white;"| Toevoegen nl-core-contactpoint.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-409 MM-409]
| style="background-color: white;"| Toevoegen ontbrekende ConceptMaps en zib FHIR ValueSets.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-401 MM-401]
| style="background-color: white;"| Nadere toelichting ten aanzien van gebruik Nederlandse termen bij omschrijving van informatie (labels) in PGO.
|-
| rowspan = 3; style="background-color: white;"| 2019.01 - April
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-222 MM-222]
| style="background-color: white;"| Update verouderde tekst van richtlijn paragraaf op FO Ontwerp pagina.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-220 MM-220]
| style="background-color: white;"| Nadere toelichting ten aanzien van FHIR references.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-219 MM-219]
| style="background-color: white;"| MedicationUse niet compleet na een resave in Forge.
|-
| rowspan = 3; style="background-color: white;"| 2019.01 - Maart
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-200 MM-200]
| style="background-color: white;"| Verloren wijzigingen d.m.v. foutieve commit goed zetten.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-198 MM-198]
| style="background-color: white;"| PractitionerRole extensie ontbreekt bij Patient.generalPractitioner.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-189 MM-189]
| style="background-color: white;"| Concept PractitionerRole wijkt af van FHIR core.
|-
| rowspan = 9; style="background-color: white;"| 2019.01
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-180 MM-180]
| style="background-color: white;"| Toelichting functionele definitie via zibs, inclusief Nederlandse termen zorggegevens.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-149 MM-149]
| style="background-color: white;"| Patient.gender mist ConceptMap voor GeslachtCodelijst.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-139 MM-139]<br/>[https://bits.nictiz.nl/browse/MM-133 MM-133]
| style="background-color: white;"| PractitionerRole reference extensie toegevoegd aan elementen die naar Practitioner verwijzen.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-122 MM-122]
| style="background-color: white;"| ConceptMaps benoemen + aanmaken.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-89 MM-89]
| style="background-color: white;"| Consistentie referenties naar (zib) profielen of base resources voor niet-zib concepten.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-88 MM-88]
| style="background-color: white;"| Mapping BasisElementen ontbreekt.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-72 MM-72]
| style="background-color: white;"| Added concept name to all profile mappings from HCIMs or datasets.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-70 MM-70]
| style="background-color: white;"| Updated links in technical design pages for profiles so they have less maintenance.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-65 MM-65]
| style="background-color: white;"| Generic guidance on references added.
|-
| rowspan = 6; style="background-color: white;"| 2018.06
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-136 MM-136]
| style="background-color: white;"| Payer.PayerPerson.PayerName is a String but simplifier says it is a nl-core-humanname.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-83 MM-83]
| style="background-color: white;"| Tegenstellende definities van land tussen de Nictiz zib wiki en de FHIR standaarden.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-81 MM-81]
| style="background-color: white;"| Gebruik van AddressType in AddresInformation zib.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-77 MM-77]
| style="background-color: white;"| Ambiguïteit bij HouseNumberAddition/HouseNumberLetter.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-76 MM-76]
| style="background-color: white;"| Wat hoort er thuis in het FirstNames veld in de NameInformation zib?
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-47 MM-47]
| style="background-color: white;"| Suggestion: require display or text on codes.
|}

=Releases=
{| class="wikitable"
! Versie !! Datum !! Omschrijving
|-
| [[MedMij:V2020.01/Ontwerpen|2020.01]] || 2020-08-11 || Zomerrelease met wijzigingen voor MedMij-standaarden
|-
| [[MedMij:V2019.01_Ontwerpen|2019.01]] || 2019-10-18 || Use case medicatiegerelateerde allergie- en intolerantiegegevensvertaling toegevoegd
|-
| [[MedMij:V2019.01_Ontwerpen|2019.01]] || 2019-10-02 || Use case PDF/A Sturen toegevoegd
|-
| [[MedMij:V2019.01_Ontwerpen|2019.01]] || 2019-03-11 || Alle MedMij-standaarden
|-
| [[MedMij:V2018.06_Ontwerpen|2018.06]] || 2018-10-29 || Basisgegevens GGZ
|-
| [[MedMij:V2018.05_Ontwerpen|2018.05]] || 2018-09-24 || Basisgegevens GGZ voor openbare consultatie
|-
| [[MedMij:V2018.04_Ontwerpen|2018.04]] || 2018-09-02 || eAfspraak fase 2
|-
| [[MedMij:V2018.03_Ontwerpen|2018.03]] || 2018-05-07 || BgZ 2017 en Huisartsgegevens
|-
| [[MedMij:V2018.02_Ontwerpen|2018.02]] || 2018-03-29 || BgZ 2017 voor openbare consultatie
|-
| [[MedMij:V2018.01_Ontwerpen|2018.01]] || 2018-02-21 || Huisartsgegevens voor openbare consultatie
|-
| [[MedMij:V2017.04_Ontwerpen|2017.04]] || 2017-12-18 || Medicatie, Laboratoriumresultaten, Allergie/intolerantie, Zelfmetingen
|-
| [[MedMij:V2017.03_Ontwerpen|2017.03]] || 2017-11-07 || PDF/A
|-
| [[MedMij:V2017.02_Ontwerpen|2017.02]] || 2017-10-11 || eAfspraak
|-
| [[MedMij:V2017.01_Ontwerpen|2017.01]] || 2017-10-02 || BgZ 2015
|}

MedMij:Vprepub-2020.02/Ontwerpen

2021-09-20T07:57:04Z

Eduard de Rijcke: MM-2325 Merged to veprepub 2020.02

MedMij:V2020.01/FHIR BGZ 2017

2021-09-20T07:54:58Z

Eduard de Rijcke: MM-2293 Merge to vprepub

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide: BgZ {{VersieInfo|BgZ}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:BGZ_icoon.png |link=|links|90px|Use case BgZ 2017|Patient Summary (BgZ)]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpBGZ_2017|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

==Introduction==
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

The program ‘Registratie aan de bron’ (Clinical documentation at the point of care) has defined Health and Care Information models ([https://zibs.nl/wiki/HCIM_Mainpage HCIMs] (English) or [https://zibs.nl/wiki/ZIB_Hoofdpagina zibs] (Dutch)) for The Netherlands. Next to these HCIMs, the program ‘Registratie aan de bron’ also made a selection of these HCIMs 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 and can be seen as a representation of a patient summary.

A subselection of the published [https://zibs.nl/wiki/HCIM_Release_2017(EN) HCIMs release 2017] constitute the [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ 2017]. The BgZ makes a subselection of the information concepts within the HCIMs or restricts the HCIMs to a certain category. For example, only include the general practitioner of the patient or only the last known value of 'X'. MedMij created FHIR profiles that represent these HCIMs completely if no existing and usable profiles were available. The profiles represent their entire respective HCIM, to make them applicable in a broader context than a patient summary or even the MedMij context. An overview of the profiles can be found at the [[MedMij:Vprepub-2020.01/FHIR_BGZ_2017#List_of_profiles|list of profiles]].

The patient journey of [https://www.nictiz.nl/ehealth/MedMij Thomas van Beek], provides a patients context for exchanging a patient summary from a healthcare provider's system (XIS) to a personal health record (PHR). MedMij created a [[MedMij:Vprepub-2020.01/Ontwerpen|functional design]] of the BgZ use case. This use case consists of enabling a patient to view his own BgZ in a PHR. This page will elaborate further on the HL7 FHIR details needed to exchange the BgZ information using FHIR.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

==Actors involved==
{| class="wikitable"
! colspan="2" style="text-align:left;" | Actors
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/bgz2017-clientcapabilities|nictiz.fhir.nl.stu3.bgz|title=CapabilityStatement: Client}}
| FHIR Client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/bgz2017-servercapabilities|nictiz.fhir.nl.stu3.bgz|title=CapabilityStatement: Server}}
| FHIR Server requirements
|}

==Boundaries and Relationships==
The BgZ 2017 v1.1 use case follows the BgZ v1.0 use case. The difference between the two is the underlying HCIMs, which have been upgraded from release 2015 to release 2017. The changes are documented in a [https://github.com/Nictiz/Nictiz-STU3-Zib2017/raw/master/ReleaseNotes%20FHIR%20profielen%20ZIB2017.pdf release notes] document.

The BgZ use case has similarities and differences with other use cases such as Medication Process, Vital Signs and Lab Results. These use cases use the same HCIM based FHIR profiles for exchanging information. The BgZ use case covers practically all profiles included in the other use cases. However, the BgZ differs in the scope of the actual health information content that should be exchanged. For example, the BgZ conveys only the last known lab result of each type while the Lab Results use case may cover all known information.

==Use Case: Retrieve BGZ information==
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to MedMij Afsprakenstelsel]]

{{FHIR-IG-Afsprakenstelsel-Note}}

===PHR: request message===
The PHR system requests the BgZ using individual [https://www.hl7.org/fhir/stu3/search.html search] interactions. The BgZ consists of multiple FHIR resources with certain constraints. To obtain the patient's BgZ, the client can use multiple individual search operations based on specified search queries. The interactions are performed by an HTTP GET as shown:

<code>GET [base]/[type]{?[parameters]}</code>

The table below shows in the first four columns the BgZ sections, the HCIMs that constitute those sections and the specific content of the BgZ. The last column shows the FHIR search queries to obtain the BgZ information. These queries and expected responses are based on profiles listed in [[#List_of_profiles| this section]].

{| class="wikitable collapsible" width="100%" style="horizontal-align: right"
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | #
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ Section
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | HCIM EN
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Content
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Search URL<ref>See [[MedMij:Vprepub-2020.01/FHIR_IG#Search_URLs_and_search_parameters|Search URLs and search parameters]] for the interpretation of these search URLs</ref>
|-
| 1
| Patient information
| Patient
| Identification, birth date, gender, deceased indicator, contact details, last known marital status, and general practitioner (practitioner or organization)
| <pre>GET [base]/Patient?_include=Patient:general-practitioner</pre>
|-
| 2
| Payment details
| Payer
| Insurance information
| <pre>GET [base]/Coverage?_include=Coverage:payor:Patient&_include=Coverage:payor:Organization</pre>
|-
| rowspan="2" | 3
| rowspan="2" | Treatment directives
| TreatmentDirective
| Known treatment directives
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105</pre>
|-
| AdvanceDirective
| Known advance directives
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11341000146107</pre>
|-
| 4
| Contact persons
| ContactPerson
| First relation/contact
| <pre style="font-style: italic;">see Patient</pre>
|-
| 5
| Functional status
| FunctionalOrMentalStatus
| Last known functional / mental status
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|118228005,http://snomed.info/sct|384821006</pre>
<span id="FunctionalOrMentalStatusRemark"></span>{{NoteBox|The NL-CM:4.26.6 StatusDate concept is incorrectly mapped on the <code>effective[x]:effectivePeriod.start</code> element in the HCIM FunctionalOrMentalStatus profile, it is a date rather than a period. Presumed solution will come from a future HCIM release. See [https://bits.nictiz.nl/browse/MM-1570 MM-1570] for more information.}}
|-
| 6
| Problems
| Concern
| All known problems
| <pre>GET [base]/Condition</pre>
|-
| rowspan="5" | 7
| rowspan="5" | Social history
| LivingSituation
| Current living situation
| <pre>GET [base]/Observation/$lastn?code=http://snomed.info/sct|365508006</pre>
|-
| DrugUse
| All known drug use
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228366006</pre>
|-
| AlcoholUse
| All known alcohol use
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228273003</pre>
|-
| TobaccoUse
| All known tobacco use
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365980008</pre>
|-
| NutritionAdvice
| All known current dietary recommendations
| <pre>GET [base]/NutritionOrder</pre>
|-
| 8
| Alerts
| Alert
| All known alerts
| <pre>GET [base]/Flag</pre>
|-
| 9
| Allergies
| AllergyIntolerance
| All known information regarding allergies
| <pre>GET [base]/AllergyIntolerance</pre>
|-
| rowspan="3" | 10
| rowspan="3" | Medication
| MedicationUse
| Known medication use
| <pre>GET [base]/MedicationStatement?category=urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&_include=MedicationStatement:medication</pre>
|-
| MedicationAgreement
| Known medication agreements
| <pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication</pre>
|-
| AdministrationAgreement
| Known administration agreements
| <pre>GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&_include=MedicationDispense:medication</pre>
|-
| 11
| Medical aids
| MedicalDevice
| Known medical aids
| <pre>GET [base]/DeviceUseStatement?_include=DeviceUseStatement:device</pre>
|-
| 12
| Vaccinations
| Vaccination
| Known vaccinations
| <pre>GET [base]/Immunization?status=completed</pre>
|-
| rowspan="3" | 13
| rowspan="3" | Vital signs
| BloodPressure
| Last known blood pressure
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|85354-9</pre>
|-
| BodyWeight
| Last known body weight
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|29463-7</pre>
|-
| BodyHeight
| Last known body height
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2,http://loinc.org|8306-3,http://loinc.org|8308-9</pre>
|-
| 14
| Results
| LaboratoryTestResult
| Last known laboratory results per type
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|275711006&_include=Observation:related-target&_include=Observation:specimen</pre>
|-
| 15
| Procedures
| Procedure
| Known surgical procedures
| <pre>GET [base]/Procedure?category=http://snomed.info/sct|387713003</pre>
|-
| 16
| Encounters
| Contact
| Known hospital admissions (no outpatient contacts)
| <pre>GET [base]/Encounter?class=http://hl7.org/fhir/v3/ActCode|IMP,http://hl7.org/fhir/v3/ActCode|ACUTE,http://hl7.org/fhir/v3/ActCode|NONAC</pre>
|-
| 17
| Planned care
| PlannedCareActivityForTransfer
| Known planned care activities
| <span id="PlannedCareRemark"></span>{{NoteBox|The HCIM PlannedCareActivityForTransfer represents a planned activity as a (reference to) the HCIM for that activity in the 'planned' status. However, FHIR doesn't recognize this status; instead it uses dedicated resources for planning. Therefore, the FHIR implementation of this HCIM uses these dedicated resources instead of a distinct profile::

*Planning an Encounter is done by using an Appointment
*Planning a Procedure is done by using a ProcedureRequest
*Planning an Immunization is done by using an ImmunizationRecommendation
*Planning a MedicalDevice is done by using a DeviceRequest
}}
<pre>GET [base]/ProcedureRequest?status=active</pre>
<pre>GET [base]/ImmunizationRecommendation</pre>
{{NoteBox|The NL-CM:11.1.5 DesiredDateForRevaccination concept is incorrectly mapped onto the {{fhir|.recommendation.date}} element in the HCIM ImmunizationRecommendation profile. The proper element is actually {{fhir|.recommendation.dateCriterion}}. This will be fixed in the next breaking release. See [https://bits.nictiz.nl/browse/MM-2281 MM-2281] for more information.}}<pre style="text-decoration: line-through;">GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&status=in-progress,preparation&_include=MedicationDispense:medication</pre>
<span id="MM115Remark"></span>{{NoteBox|PlannedCareActivityForTransfer for MedicationAdministration was found unimplementable as-is. Presumed solution will come from a future HCIM release. See [https://bits.nictiz.nl/browse/MM-115 MM-115] for more information.}}
<pre>GET [base]/DeviceRequest?status=active&_include=DeviceRequest:device</pre>
<pre>GET [base]/Appointment?status=booked,pending,proposed</pre>
|-
| 18
| General practitioner
| HealthProfessional
| General Practitioner of the patient
| <pre style="font-style: italic;">see Patient</pre>
|}
<references/>

===XIS: response message===
The returned data to the PHR should conform to the profiles listed in [[#List_of_profiles]].

===The <code>lastn</code> operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The FHIR STU3 specification is vague regarding the sorting mechanism of <code>lastn</code>. In FHIR R4 however, this has been clarified and can be read as follows: when using <code>lastn</code>, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

==List of profiles==
The profiles represent their entire respective HCIM, to make them applicable in a broader context than the exchange of BgZ or a MedMij context. An example of reuse of existing profiles is those of the patient administration resources and vital signs.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.bgz|p2=nictiz.fhir.nl.stu3.zib2017|v2Min=2.0.0|p3=nictiz.fhir.nl.stu3.eafspraak}}

{| class="wikitable" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Section
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:100px" | Zib NL
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:100px" | HCIM EN
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:100px" | FHIR Resource
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:400px" | FHIR Profile
|-
| 1
| Patient
| #Zib Patient|Patient
| Patient
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="3" |2
| rowspan="3" | Betaler
| rowspan="3" | Payer
| Coverage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Payer|nictiz.fhir.nl.stu3.zib2017}}
|-
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
|-
| Patient
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="2" |3
| BehandelAanwijzing
| TreatmentDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective|nictiz.fhir.nl.stu3.zib2017}}
|-
| Wilsverklaring
| AdvanceDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective|nictiz.fhir.nl.stu3.zib2017}}
|-
| 4
| Contactpersoon
| ContactPerson
| Patient.contact
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| 5
| Funct. OfMentaleStatus
| FunctionalOrMentalStatus
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.zib2017}}
|-
| 6
| Probleem
| Problem
| Condition
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Problem|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="5" | 7
| Woonsituatie
| LivingSituation
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation|nictiz.fhir.nl.stu3.zib2017}}
|-
| DrugsGebruik
| DrugUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse|nictiz.fhir.nl.stu3.zib2017}}
|-
| AlcoholGebruik
| AlcoholUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse|nictiz.fhir.nl.stu3.zib2017}}
|-
| TabakGebruik
| TobaccoUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse|nictiz.fhir.nl.stu3.zib2017}}
|-
| Voedingsadvies
| NutritionAdvice
| NutritionOrder
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice|nictiz.fhir.nl.stu3.zib2017}}
|-
| 8
| Alert
| Alert
| Flag
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Alert|nictiz.fhir.nl.stu3.zib2017}}
|-
| 9
| AllergieIntolerantie
| AllergyIntolerance
| AllergyIntolerance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="3" | 10
| MedicatieGebruik2
| MedicationUse2
| MedicationStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse|nictiz.fhir.nl.stu3.zib2017}}
|-
| Medicatieafspraak
| MedicationAgreement
| MedicationRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement|nictiz.fhir.nl.stu3.zib2017}}
|-
| Toedieningsafspraak
| AdministrationAgreement
| MedicationDispense
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="2" | 11
| rowspan="2" | MedischHulpmiddel
| rowspan="2" | MedicalDevice
| Device
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct|nictiz.fhir.nl.stu3.zib2017}}
|-
| DeviceUseStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="2" | 12
| rowspan="2" | Vaccinatie
| rowspan="2" | Vaccination
| Immunization
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination|nictiz.fhir.nl.stu3.zib2017}}
|-
| ImmunizationRecommendation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="3" | 13
| Bloeddruk
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="2" | 14
| rowspan="2" | LaboratoriumUitslag
| rowspan="2" | LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Specimen
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017}}
|-
| 15
| Verrichting
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Procedure|nictiz.fhir.nl.stu3.zib2017}}
|-
| 16
| Contact
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="5" | 17
| rowspan="5" | OverdrachtGeplandeZorgActiviteit
| rowspan="5" | PlannedCareActivityForTransfer
| ProcedureRequest [[#PlannedCareRemark|*]]
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017}}
|-
| <span style="text-decoration: line-through;">MedicationDispense</span> [[#MM115Remark|**]]
| <span style="text-decoration: line-through;">{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement|nictiz.fhir.nl.stu3.zib2017}}</span>
|-
| ImmunizationRecommendation [[#PlannedCareRemark|*]]
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation|nictiz.fhir.nl.stu3.zib2017}}
|-
| DeviceRequest [[#PlannedCareRemark|*]]
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceRequest|nictiz.fhir.nl.stu3.zib2017}}
|-
| Appointment [[#PlannedCareRemark|*]]
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment|nictiz.fhir.nl.stu3.eafspraak}}
|-
| rowspan="3" | 18
| rowspan="2" | Zorgverlener
| rowspan="2" | HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| PractitionerRole
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
|}

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpBGZ_2017#Release_notes|functional design page]].

MedMij:Vprepub-2020.01/FHIR BGZ 2017

2021-09-20T07:54:58Z

Eduard de Rijcke: MM-2293 Merge to vprepub

MedMij:V2020.01/BgZ Beschikbaarstellen

2021-09-20T07:49:24Z

Eduard de Rijcke: MM-2087 Merge to vprepub

__NOINDEX__
{{MedMij:Vprepub-2020.01/Issuebox}}

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Basisgegevensset Zorg - kwalificatie - Beschikbaarstellen Basisgegevensset Zorg {{VersieInfo|BgZ}}}}
<span class="toclimit-3">__TOC__</span>

= Versiebeheer =


{| class="wikitable"
|+ Versiebeheer
|-
! Datum !! BITS issue !! Omschrijving
|-
| 31-08-2021 || [https://bits.nictiz.nl/browse/MM-2294 MM-2294] || Kwalificatiescript omgezet van PDF-formaat naar wiki
|-
| 12-03-2020 || [https://bits.nictiz.nl/browse/MM-672 MM-672] || Terminologie zib en zibs consistent gemaakt
|}

= Doelgroep =
De doelgroep van dit document is de XIS-leverancier die wil kwalificeren op de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel.

De basis is de BgZ op basis van de publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

= Begrippenlijst =
Er zijn geen specifieke begrippen van toepassing.

= Inleiding =
Deze bladzijde bevat de te doorlopen scripts bij kwalificatie voor de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel. De kwalificatie wordt door de kwalificator uitgevoerd met de Nictiz kwalificatiesimulator, die is ingericht op een FHIR server. De kwalificatiesimulator kan berichten verzenden en ontvangen. Er wordt gebruik gemaakt van testpatiënten met fictieve BSN's.

== Algemene voorwaarden voor kwalificatie ==




Een (kandidaat-) deelnemer kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van MedMij Afsprakenstelsel.
# Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie etc.
# Kennis en begrip van de betreffende MedMij informatiestandaard, zoals beschreven op de informatiestandaarden wiki van Nictiz.
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten andere referenties die de informatiestandaard gebruikt.
# Alle gegevens die de kwalificerende partij zelf moet invoeren zijn te vinden in de kwalificatiedocumentatie. Onjuist ingevoerde gegevens (ook tijd/datum etc.) zullen leiden tot vertraging van en kunnen blokkerend zijn voor het kwalificatieproces.
# Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker. De (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.
# Deze kwalificatie toetst geen infrastructurele eisen.

== Specifieke voorwaarden voor kwalificatie ==
Voor deze informatiestandaard gelden de volgende specifieke voorwaarden:

De kwalificatie is ingericht aan de hand van BgZ secties en de onderliggende zibs. Kennis van de zibs is een voorwaarde voor kwalificatie. BgZ omvat 18 secties, en 28 onderliggende zibs.

Uitgangspunten voor de kwalificatie systeemrol ‘Beschikbaarstellen BgZ’ (XIS):

* Mocht XIS alleen enkele losse secties van de BgZ beschikbaar willen / kunnen stellen, dan kan XIS dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dan kwalificeert XIS voor die informatiestandaard, maar niet voor BgZ. Dit komt overzichtelijkheid ten goede voor persoon en PGO.
* Voorafgaand aan kwalificatie wordt vastgesteld welke BgZ-gegevens ondersteund worden door XIS.
* BgZ gegevens die in XIS vastgelegd worden, dienen ook ontsloten te worden.
* Idealiter ondersteunt een BgZ beschikbaarstellend systeem de gehele BgZ, maar om XIS-leverancier tegemoet te komen, kan XIS kwalificatie starten bij ondersteuning van minimaal 14 van de 18 BgZ secties of 20 van de 28 onderliggende zibs. Dit wijkt bewust af van het uitgangspunt voor PGO, omdat in het zorgproces dat XIS ondersteunt, doorgaans niet de gehele BgZ vastgelegd hoeft te worden. In tegenstelling tot PGO waarin de persoon een zo compleet mogelijk overzicht van zorggegevens wil hebben. Tijdens de kwalificatie moet XIS alle ondersteunde delen laten zien. Voor alle ondersteunde delen moet XIS slagen voor kwalificatie.
* Op technisch niveau moet per zib alle onderliggende data-elementen (verplicht en optioneel) ingebouwd zijn. De vulling van deze data-elementen is afhankelijk van de klinische relevantie bepaald door de use case.
* Als XIS na kwalificatie meer of minder BgZ secties of zibs gaat ondersteunen leidt dit tot een wijziging van de applicatie die herkwalificatie noodzakelijk maakt. Meer informatie over herkwalificatie is te vinden op de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/herkwalificatie herkwalificatie pagina].
* XIS-leverancier ondersteunt ‘Beschikbaarstellen BgZ’ vanaf een bepaalde softwareversie. Deze versie kan binnen het VIPP-programma (module A3) gebruikt worden voor de bepaling van de financiering per ziekenhuis.

Samenvatting:

De gehele BgZ wordt als use case gehanteerd, en de kwalificatie is daarop ingericht.
De gehele BgZ wordt geraadpleegd via losse queries. Er wordt geen gebruik gemaakt van FHIR bundle bij raadplegen en beschikbaarstellen.
XIS kwalificeert bij beschikbaarstellen en kunnen opslaan van minimaal 14 van de 18 BgZ secties. Of 20 van de 28 onderliggende zibs.

== Op te leveren kwalificatiemateriaal door de leverancier ==

# De berichten worden verstuurd vanuit XIS. Verstuur de inhoudelijke gegevens van de kwalificatiescenario's naar de simulator (FHIR-server).
# Schermafdrukken van de kwalificatiescenario's, zoals aangegeven onder "Uit te voeren stappen". Stuur dit materiaal op in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.]]

== Uit te voeren stappen Beschikbaarstellen ==

Voer – voor ieder scenario – de volgende stappen uit:

# Registreer in XIS de patiëntgegevens voor de testpersonen zoals beschreven in de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]]
# Maak in XIS de Basisgegevensset Zorg voor deze personen aan, gebruik hiervoor de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]].
# Maak schermafdrukken van de in XIS ingevoerde gegevens en plaats deze in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.'']]
# Vanaf de kwalificatiesimulator (FHIR-server) kan de uitvraag gegenereerd worden (door kwalificerende XIS zelf) conform de verschillende parameters (bijvoorbeeld voor een bepaalde persoon voor een bepaalde periode), zoals beschreven in de scenario’s.
# Basisgegevensset Zorg gegevens beschikbaarstellen conform de scenario’s.


{| class="wikitable"
|+
|-
! Doel !! Verwacht resultaat
|-
| Aantonen dat het systeem BgZ beschikbaar kan stellen met gebruik van FHIR berichten || Het systeem genereert technisch correcte berichten
|-
| Aantonen dat het systeem kan omgaan met een uitvraag voor persoon waarvoor -naast patiëntgegevens- geen BgZ gegevens bekend zijn (scenario 1.2) || Het systeem maakt op correcte wijze kenbaar dat er geen gegevens aanwezig zijn voor bewuste persoon
|}

Scenario's (vraag aan XIS van 1 specifieke Zorgaanbieder waarmee verbinding is gemaakt)''
*Scenario 1.1: BgZ van persoon 1, zoals beschreven in addendum 1.
*Scenario 1.2: BgZ van persoon 2, zoals beschreven in addendum 2 (nauwelijks BgZ gegevens aanwezig).

= Aandachtspunten voor inhoudelijke gegevens =
== Persoonsgegevens ==
De Basisgegevensset Zorg sectie Demografie en identificatie bevat algemene gegevens over de persoon zoals naam, adres en woonplaats. In het MedMij afsprakenstelsel is vastgelegd dat de BSN door de PGO niet gebruikt mag worden om XIS te raadplegen, aangezien de PGO in het persoonsdomein valt en buiten het zorgaanbiedersdomein. Evenmin mag een BSN door XIS geretourneerd worden naar het persoonsdomein. Er is wel een fBSN (fictieve BSN voor testdoeleinden) in de persoonsgegevens opgenomen, aangezien het beschikbaar stellende systeem (XIS) deze nodig kan hebben.

== Datum T ==
T is een datum die we tijdens de kwalificatie nader invullen / afspreken. Als ergens staat T-100D betekent dit: 100 dagen eerder dan de afgesproken datum.

= Inhoudelijke gegevens scenario’s =
In dit hoofdstuk zijn de addenda van scenario 1.1 en 1.2 te vinden.
== Scenario 1.1 ==
Dit betreft persoon 1 zoals hieronder beschreven.
Met scenario 1.1 wordt getoetst of XIS Basisgegevensset Zorg beschikbaar kan stellen met gebruik van FHIR berichten. Hieronder volgen de inhoudelijke gegevens conform de secties en zibs in publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

===Demografie en identificatie===
{| class="wikitable" width="60%"
!
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;font-weight: bold;;"
|Patiënt.Naamgegevens ||
|-
|Voornamen ||Johan
|-
|Initialen ||J
|-
|Roepnaam ||Johan
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Helleman
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Identificatienummer ||999911120
|-
|Geboortedatum ||25-7-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||
|-
|BurgerlijkeStaat ||Gehuwd
|}

=== Financiële informatie ===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Betaler ||Inhoudelijke gegevens Persoon 1
|-
|BetalerNaam ||XXX_Helleman
|-
|BankNaam ||ING
|-
|Bankcode ||INGBNL2A
|-
|Rekeningnummer ||NL85INGB0001234567
|-
|Verzekering ||
|-
|BeginDatumTijd ||1-1-2018
|-
|EindDatumTijd ||31-1-2019
|-
|Verzekeringssoort ||Basis verzekerd
|-
|IdentificatieNummer ||3332
|-
|OrganisatieNaam ||Menzis Zorgverzekeraar N.V.
|-
|VerzekerdeNummer ||12345678
|-style="background-color: #E3E3E3;;"
|Adresgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|-style="background-color: #E3E3E3;;"
|Contactgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|}

===Behandelrestricties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|BehandelAanwijzing ||Inhoudelijke gegevens Persoon 1
|-
|Geverifieerd ||1
|-
|GeverifieerdBij ||Patiënt
|-
|VerificatieDatum ||9-4-2018
|-
|Behandeling ||Kunstmatige beademing
|-
|BehandelingToegestaan ||Ja, maar met beperkingen
|-
|Beperkingen ||Eerst overleg met echtgenote
|-
|BeginDatum ||9-4-2018
|-
|EindDatum ||
|-
|Toelichting ||
|-
|Wilsverklaring ||
|-
|WilsverklaringType ||Niet reanimeren verklaring
|-
|WilsverklaringDatum ||9-4-2018
|-
|Aandoening ||ALS
|-
|WilsverklaringDocument ||
|-
|Toelichting ||Niet-reanimerenpenning
|-style="background-color: #E3E3E3;;"
|Vertegenwoordiger ||
|-
|Contactpersoon ||Zie contactgegevens contactpersoon BgZ sectie 4
|}

===Contactpersonen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contactpersoon ||Inhoudelijke gegevens Persoon 1
|-
|Voornamen ||Jannie
|-
|Initialen ||J.P.M.
|-
|Roepnaam ||-
|-
|Naamgebruik ||Eigen geslachtsnaam gevolgd door geslachtsnaam partner
|-
|Voorvoegsels ||van
|-
|Achternaam ||Putten
|-
|VoorvoegselsPartner ||-
|-
|AchternaamPartner ||XXX_Helleman
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Huisnummerletter ||-
|-
|Huisnummertoevoeging ||-
|-
|AanduidingBijNummer ||-
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Gemeente ||-
|-
|Land ||Nederland
|-
|AdditioneleInformatie ||-
|-
|AdresSoort ||Woon-/verblijfadres
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Rol ||Eerste relatie/contactpersoon
|-
|Relatie ||Echtgenote
|}

===Functionele status===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|FunctioneleOfMentaleStatus ||Inhoudelijke gegevens Persoon 1
|-
|StatusNaam ||Zich wassen
|-
|StatusWaarde ||Moeite met wassen
|-
|StatusDatum ||2001
|-
|Toelichting ||-
|-
|MedischHulpmiddel ||-
|}

===Klachten en diagnoses===

Let op: er wordt hier één probleem specifiek beschreven, maar in andere BgZ secties zijn meerdere verwijzingen opgenomen die als ‘FHIR condition resources’ beschikbaar gesteld worden. Bijvoorbeeld onder sectie 8. Waarschuwingen.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Probleem ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemAnatomischeLocatie ||Pols
|-
|ProbleemLateraliteit ||Rechts
|-
|ProbleemType ||Diagnose
|-
|ProbleemNaam ||Polsfractuur
|-
|ProbleemBeginDatum ||2001
|-
|ProbleemEindDatum ||
|-
|ProbleemStatus ||Niet actueel
|-
|VerificatieStatus ||Onbekend
|-
|Toelichting ||Gevallen op kunstijsbaan.
|}

===Sociale anamnese===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Woonsituatie || Inhoudelijke gegevens Persoon 1
|-
|WoningType ||Eengezinswoning
|-
|Datum ||30-06-2016
|-style="background-color: #FFFF00;font-weight: bold;;"
|DrugsGebruik ||Inhoudelijke gegevens Persoon 1
|-
|StartDatum ||1981
|-
|StopDatum ||1983
|-
|Hoeveelheid ||3x per jaar
|-
|Toelichting ||Op feestjes en in uitgaanscircuit.
|-
|DrugsOfGeneesmiddelSoort ||Amfetamine, speed
|-
|DrugsGebruikStatus ||heeft in het verleden drugs gebruikt
|-
|Toedieningsweg ||nasaal (snuiven)
|-style="background-color: #FFFF00;font-weight: bold;;"
|AlcoholGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|AlcoholGebruikStatus ||Drinkt alcohol
|-
|StartDatum ||1980
|-
|StopDatum ||
|-
|Hoeveelheid ||4 glazen per week
|-style="background-color: #FFFF00;font-weight: bold;;"
|TabakGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|SoortTabakGebruik ||Rookt sigaretten
|-
|TabakGebruikStatus ||Ex-roker
|-
|StartDatum ||1980
|-
|StopDatum ||1983
|-
|Hoeveelheid ||2 pakjes per week
|-
|PackYears ||1
|-style="background-color: #FFFF00;font-weight: bold;;"
|Voedingsadvies ||Inhoudelijke gegevens Persoon 1
|-
|DieetType ||Energie verrijkt
|-
|Consistentie ||Dikvloeibaar
|-
|Toelichting ||-
|}

===Waarschuwingen===

Let op: er wordt hier één waarschuwing specifiek beschreven, maar in andere BgZ secties zijn meerdere verwijzingen opgenomen die als ‘FHIR condition resources’ beschikbaar gesteld worden.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Alert ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemNaam ||-
|-
|AlertNaam ||Drager MRSA
|-
|BeginDatumTijd ||1-6-2010
|-
|AlertType ||Waarschuwing
|}

===Allergieën===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|AllergieIntolerantie ||Inhoudelijke gegevens Persoon 1
|-
|VeroorzakendeStof ||Bijengif
|-
|AllergieCategorie ||Stof of product
|-
|AllergieStatus ||Actief
|-
|BeginDatumTijd ||8-11-2008
|-
|MateVanKritiekZijn ||Ernstig
|-
|LaatsteReactieDatumTijd ||15-11-2009
|-
|Toelichting ||
|-style="background-color: #E3E3E3;;"
|Reactie ||
|-
|Symptoom ||Misselijk en braken
|-
|SpecifiekeStof ||
|-
|ReactieBeschrijving ||
|-
|Ernst ||Ernstig
|-
|WijzeVanBlootstelling ||
|-
|ReactieTijdstip ||
|}

===Medicatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieAfspraak ||Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||875452574
|-
|Afspraakdatum ||14-8-2016, om 16:30
|-
|RedenMedicatieafspraak ||Starten medicamenteuze behandeling
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||15-8-2016
|-
|Duur ||30 dagen
|-
|FarmaceutischProduct ||Metoclopramide zetpil 10mg, PRK 6920
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|Toedieningsweg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold
|Toedieningsafspraak || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||13610554
|-
|ToedieningsafspraakDatumTijd ||1-6-2018, om 12:25
|-
|RedenAfspraak ||
|-
|Geneesmiddel ||PRIMPERAN ZETPIL 20MG, HPK 229709
|-
|Verstrekker ||Apotheek de Gulle Gaper
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Vanaf 1-6-2018, gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|ToedieningsWeg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieGebruik2 || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||123457000000
|-
|Registratiedatum ||16-8-2018
|-
|GebruikIndicator ||Ja
|-
|VolgensAfspraakIndicator ||Ja
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||28-6-2018
|-
|Einddatum ||
|-
|GebruiksDuur ||3 weken
|-
|Gebruiksproduct ||Zestril tablet 10mg, HPK 615560
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|Gebruiksinstructie ||
|-
|Omschrijving ||1 maal per dag 1 tablet, oraal
|-
|ToedieningsWeg ||Oraal
|-
|Doseerinstructie ||1 maal per dag 1 tablet
|-
|Informatiebron ||Patiënt
|}

===Medische hulpmiddelen===

Let op: er wordt hier één medisch hulpmiddel specifiek beschreven, maar in andere BgZ secties, zoals sectie 15 Verrichtingen, kunnen verwijzingen opgenomen zijn die als ‘FHIR device resources’ beschikbaargesteld worden.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedischeHulpmiddel || Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;"
|Product ||
|-
|ProductID ||-
|-
|ProductType ||Gehoorapparaat
|-
|ProductOmschrijving ||-
|-
|BeginDatum ||2007
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Presbyacusis
|-
|Toelichting ||Apparaat niet zichtbaar (diep in de gehooringang)
|-
|AnatomischeLocatie ||Oor
|-
|Lateraliteit ||Rechts
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|Zorgaanbieder.Organisatienaam ||Test Medisch Centrum
|}

===Vaccinaties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Vaccinatie ||Inhoudelijke gegevens Persoon 1
|-
|ProductCode ||Hepatitis A vaccin
|-
|Dosis ||-
|-
|VaccinatieDatum ||5-3-1999
|-
|GewensteDatumHervaccinatie ||-
|-style="background-color: #E3E3E3;;"
|Toediener ||
|-
|Zorgverlener.Achternaam ||Spuijter
|-
|Toelichting ||Bezoek aan Guatemala.
|}

===Vitale functies===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Bloeddruk ||Inhoudelijke gegevens Persoon 1
|-
|Meetmethode ||Niet-invasief
|-
|ManchetType ||Groot
|-
|MeetLocatie ||Linker bovenarm
|-
|DiastolischEindpunt ||-
|-
|SystolischeBloeddruk ||108 mmHg
|-
|DiastolischeBloeddruk ||56 mmHg
|-
|GemiddeldeBloeddruk ||-
|-
|BloeddrukDatumTijd ||7-2-2013 08:53
|-
|Toelichting ||-
|-
|Houding ||Zittende positie
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamsgewicht ||Inhoudelijke gegevens Persoon 1
|-
|GewichtWaarde ||72 kg
|-
|Toelichting ||-
|-
|GewichtDatumTijd ||8-2-2013
|-
|Kleding ||Lichte kleding/ondergoed
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamslengte ||Inhoudelijke gegevens Persoon 1
|-
|LengteWaarde ||183 cm
|-
|LengteDatumTijd ||8-2-2013 06:43
|-
|Toelichting ||Met schoenen aan
|-
|Positie ||Staande positie
|-
|Uitvoerder ||G.Z.M. de Wit
|}

===Uitslagen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;font-weight: bold;;"
|LaboratoriumUitslag ||Inhoudelijke gegevens Persoon 1
|-
|ResultaatType ||Klinische chemie
|-
|TestCode ||Chloride
|-
|TestDatumTijd ||23-5-2012 12:00
|-
|TestUitslag ||109 mmol/l
|-
|TestUitslagStatus ||Definitief
|-
|ReferentieBovengrens ||108 mmol/l
|-
|ReferentieOndergrens ||99 mmol/l
|-
|InterpretatieVlaggen ||Boven referentie-waarde
|-style="background-color: #E3E3E3;;"
|Monster ||
|-
|Monstermateriaal ||Bloed
|-
|AfnameDatumTijd ||23-5-2012 08:08
|}

===Verrichtingen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Verrichting ||Inhoudelijke gegevens Persoon 1
|-
|VerrichtingStartDatum ||5-6-2012
|-
|VerrichtingEindDatum ||
|-
|VerrichtingAnatomischeLocatie ||Knie
|-
|VerrichtingLateraliteit ||Links
|-
|VerrichtingType ||Knie - prothese implantatie gewricht
|-
|VerrichtingMethode ||
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Artropathie
|-
|Toelichting ||Beperking bij het bewegen van het gewricht, drukpijn door slijtage van twee compartimenten van de linker knie.
|-style="background-color: #E3E3E3;;"
|MedischHulpmiddel ||
|-
|ProductType ||Orthopedic surgical implants
|-
|ProductID ||(01)05050474530799
(17)160131
(21)1148130801
|-
|Toelichting ||Implantant, Gen 2 Tibia Insert 5/6-9mm
|-
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-style="background-color: #E3E3E3;;"
|Uitvoerder ||
|-
|Specialisme ||Orthopedie
|-style="background-color: #E3E3E3;;"
|Aanvrager ||
|-
|Zorgverlener ||
|}

===Contacten===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contact ||Inhoudelijke gegevens Persoon 1
|-
|ContactType ||Klinisch
|-
|BeginDatumTijd ||16-8-2012
|-
|EindDatumTijd ||19-8-2012
|-style="background-color: #E3E3E3;;"
|ContactMet ||
|-
|ZorgverlenerNaam ||G.Z.M. de Wit
|-
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-
|-style="background-color: #E3E3E3;;"
|RedenContact ||
|-
|ProbleemNaam ||Fractuur van onderste extremiteit
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Chirurgische reductie van fractuur
|}

===Zorgplan===
Van de betreffende zib OverdrachtGeplandeZorgActiviteit, volgen hieronder instantiaties met verschillend OrderType.

Bij deze zib moet gebruik gemaakt worden van een opvraging van het geplande type zorg. Zo zal VaccinationRecommendation een opvraging moeten doen van de Vaccination (of meerdere Vaccinations). Dit staat verder toegelicht op het [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_BGZ_2017 Technisch Ontwerp.]

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|OverdrachtGeplandeZorgActiviteit ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Verrichting ||
|-
|OrderStatus ||Order geplaatst
|-
|BeginDatum ||12-3-2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Biopt huid
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Naevus wang
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||Test Medisch Centrum
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Vaccinatie ||
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Vaccinatie ||
|-
|ProductCode ||Hepatitis A vaccin
|-
|Toelichting ||Bezoek aan Guatemala.
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Afspraak ||
|-
|OrderStatus ||In afwachting van uitvoering
|-
|BeginDatum ||12 juli 2022 11:30 uur
|-
|EindDatum ||12 juli 2022 11:40 uur
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Afspraak ||
|-
|ContactType ||Poliklinisch
|-
|ContactOnderwerp ||Fysiotherapie Controle afspraak
|-
|OrganisatieNaam ||Test Medisch Centrum
|-
|OrganisatieLocatie ||West vleugel
|}

{| class="wikitable" width="60%"
!Medisch hulpmiddel !!
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Medisch hulpmiddel ||
|-
|ProductID
||(01)05050474530799
(17)220131
(21)0123456789
|-
|ProductType
||Gehoorapparaat
|-
|ProductOmschrijving
||-
|-
|BeginDatum ||2022
|}

===Zorgverleners===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Zorgverlener ||Inhoudelijke gegevens Persoon 1
|-
|Achternaam ||Vaste Huisarts 1
|-
|Specialisme ||0100
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Adresgegevens ||
|-
|Straat ||Valkendael
|-
|Huisnummer ||45
|-
|Postcode ||6245HK
|-
|Woonplaats ||Maastricht
|-
|Land ||Nederland
|-
|AdresSoort ||Werkadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Contactgegevens ||
|-
|Telefoonnummer ||+31434073576
|-
|TelecomType ||Vast telefoonnummer
|-
|NummerSoort ||Zakelijk telefoonnummer
|-
|EmailAdres ||huisarts@huisarts.nl
|-
|EmailSoort ||Zakelijk e-mailadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Zorgaanbieder ||
|-
|OrganisatieNaam ||Maatschap Vaste Huisarts
|-
|OrganisatieType ||Huisartspraktijk (zelfstandig of groepspraktijk)
|}

== Scenario 1.2 ==
Bij scenario 1.2 gaat het om persoon 2, zoals hieronder beschreven, die in XIS slechts bekend is met personalia.
Met scenario 1.2 wordt getoetst of XIS op correcte wijze kenbaar maakt dat er geen gegevens aanwezig zijn. Er zijn geen nadere inhoudelijke BgZ-gegevens die ingevoerd zijn en beschikbaargesteld kunnen worden.

===Demografie en identificatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 2
|-
|Voornamen ||Paul
|-
|Initialen ||P
|-
|Roepnaam ||Paul
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Mesker
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1002
|-
|Postcode ||9999ZZ
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-23456789
|-
|TelecomType ||Mobiel telefoonnummer
|-
|Identificatienummer ||999911284
|-
|Geboortedatum ||1-8-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||Inhoudelijke gegevens Persoon 2
|-
|BurgerlijkeStaat ||Geregistreerd partnerschap
|}

MedMij:Vprepub-2020.01/BgZ Beschikbaarstellen

2021-09-20T07:49:24Z

Eduard de Rijcke: MM-2087 Merge to vprepub

MedMij:V2020.01/BgZ Beschikbaarstellen

2021-09-20T07:46:01Z

Eduard de Rijcke: MM-1623 Merge to vprepub

__NOINDEX__
{{MedMij:Vprepub-2020.01/Issuebox}}

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Basisgegevensset Zorg - kwalificatie - Beschikbaarstellen Basisgegevensset Zorg {{VersieInfo|BgZ}}}}
<span class="toclimit-3">__TOC__</span>

= Versiebeheer =


{| class="wikitable"
|+ Versiebeheer
|-
! Datum !! BITS issue !! Omschrijving
|-
| 31-08-2021 || [https://bits.nictiz.nl/browse/MM-2294 MM-2294] || Kwalificatiescript omgezet van PDF-formaat naar wiki
|-
| 12-03-2020 || [https://bits.nictiz.nl/browse/MM-672 MM-672] || Terminologie zib en zibs consistent gemaakt
|}

= Doelgroep =
De doelgroep van dit document is de XIS-leverancier die wil kwalificeren op de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel.

De basis is de BgZ op basis van de publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

= Begrippenlijst =
Er zijn geen specifieke begrippen van toepassing.

= Inleiding =
Deze bladzijde bevat de te doorlopen scripts bij kwalificatie voor de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel. De kwalificatie wordt door de kwalificator uitgevoerd met de Nictiz kwalificatiesimulator, die is ingericht op een FHIR server. De kwalificatiesimulator kan berichten verzenden en ontvangen. Er wordt gebruik gemaakt van testpatiënten met fictieve BSN's.

== Algemene voorwaarden voor kwalificatie ==




Een (kandidaat-) deelnemer kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van MedMij Afsprakenstelsel.
# Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie etc.
# Kennis en begrip van de betreffende MedMij informatiestandaard, zoals beschreven op de informatiestandaarden wiki van Nictiz.
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten andere referenties die de informatiestandaard gebruikt.
# Alle gegevens die de kwalificerende partij zelf moet invoeren zijn te vinden in de kwalificatiedocumentatie. Onjuist ingevoerde gegevens (ook tijd/datum etc.) zullen leiden tot vertraging van en kunnen blokkerend zijn voor het kwalificatieproces.
# Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker. De (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.
# Deze kwalificatie toetst geen infrastructurele eisen.

== Specifieke voorwaarden voor kwalificatie ==
Voor deze informatiestandaard gelden de volgende specifieke voorwaarden:

De kwalificatie is ingericht aan de hand van BgZ secties en de onderliggende zibs. Kennis van de zibs is een voorwaarde voor kwalificatie. BgZ omvat 18 secties, en 28 onderliggende zibs.

Uitgangspunten voor de kwalificatie systeemrol ‘Beschikbaarstellen BgZ’ (XIS):

* Mocht XIS alleen enkele losse secties van de BgZ beschikbaar willen / kunnen stellen, dan kan XIS dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dan kwalificeert XIS voor die informatiestandaard, maar niet voor BgZ. Dit komt overzichtelijkheid ten goede voor persoon en PGO.
* Voorafgaand aan kwalificatie wordt vastgesteld welke BgZ-gegevens ondersteund worden door XIS.
* BgZ gegevens die in XIS vastgelegd worden, dienen ook ontsloten te worden.
* Idealiter ondersteunt een BgZ beschikbaarstellend systeem de gehele BgZ, maar om XIS-leverancier tegemoet te komen, kan XIS kwalificatie starten bij ondersteuning van minimaal 14 van de 18 BgZ secties of 20 van de 28 onderliggende zibs. Dit wijkt bewust af van het uitgangspunt voor PGO, omdat in het zorgproces dat XIS ondersteunt, doorgaans niet de gehele BgZ vastgelegd hoeft te worden. In tegenstelling tot PGO waarin de persoon een zo compleet mogelijk overzicht van zorggegevens wil hebben. Tijdens de kwalificatie moet XIS alle ondersteunde delen laten zien. Voor alle ondersteunde delen moet XIS slagen voor kwalificatie.
* Op technisch niveau moet per zib alle onderliggende data-elementen (verplicht en optioneel) ingebouwd zijn. De vulling van deze data-elementen is afhankelijk van de klinische relevantie bepaald door de use case.
* Als XIS na kwalificatie meer of minder BgZ secties of zibs gaat ondersteunen leidt dit tot een wijziging van de applicatie die herkwalificatie noodzakelijk maakt. Meer informatie over herkwalificatie is te vinden op de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/herkwalificatie herkwalificatie pagina].
* XIS-leverancier ondersteunt ‘Beschikbaarstellen BgZ’ vanaf een bepaalde softwareversie. Deze versie kan binnen het VIPP-programma (module A3) gebruikt worden voor de bepaling van de financiering per ziekenhuis.

Samenvatting:

De gehele BgZ wordt als use case gehanteerd, en de kwalificatie is daarop ingericht.
De gehele BgZ wordt geraadpleegd via losse queries. Er wordt geen gebruik gemaakt van FHIR bundle bij raadplegen en beschikbaarstellen.
XIS kwalificeert bij beschikbaarstellen en kunnen opslaan van minimaal 14 van de 18 BgZ secties. Of 20 van de 28 onderliggende zibs.

== Op te leveren kwalificatiemateriaal door de leverancier ==

# De berichten worden verstuurd vanuit XIS. Verstuur de inhoudelijke gegevens van de kwalificatiescenario's naar de simulator (FHIR-server).
# Schermafdrukken van de kwalificatiescenario's, zoals aangegeven onder "Uit te voeren stappen". Stuur dit materiaal op in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.]]

== Uit te voeren stappen Beschikbaarstellen ==

Voer – voor ieder scenario – de volgende stappen uit:

# Registreer in XIS de patiëntgegevens voor de testpersonen zoals beschreven in de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]]
# Maak in XIS de Basisgegevensset Zorg voor deze personen aan, gebruik hiervoor de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]].
# Maak schermafdrukken van de in XIS ingevoerde gegevens en plaats deze in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.'']]
# Vanaf de kwalificatiesimulator (FHIR-server) kan de uitvraag gegenereerd worden (door kwalificerende XIS zelf) conform de verschillende parameters (bijvoorbeeld voor een bepaalde persoon voor een bepaalde periode), zoals beschreven in de scenario’s.
# Basisgegevensset Zorg gegevens beschikbaarstellen conform de scenario’s.


{| class="wikitable"
|+
|-
! Doel !! Verwacht resultaat
|-
| Aantonen dat het systeem BgZ beschikbaar kan stellen met gebruik van FHIR berichten || Het systeem genereert technisch correcte berichten
|-
| Aantonen dat het systeem kan omgaan met een uitvraag voor persoon waarvoor -naast patiëntgegevens- geen BgZ gegevens bekend zijn (scenario 1.2) || Het systeem maakt op correcte wijze kenbaar dat er geen gegevens aanwezig zijn voor bewuste persoon
|}

Scenario's (vraag aan XIS van 1 specifieke Zorgaanbieder waarmee verbinding is gemaakt)''
*Scenario 1.1: BgZ van persoon 1, zoals beschreven in addendum 1.
*Scenario 1.2: BgZ van persoon 2, zoals beschreven in addendum 2 (nauwelijks BgZ gegevens aanwezig).

= Aandachtspunten voor inhoudelijke gegevens =
== Persoonsgegevens ==
De Basisgegevensset Zorg sectie Demografie en identificatie bevat algemene gegevens over de persoon zoals naam, adres en woonplaats. In het MedMij afsprakenstelsel is vastgelegd dat de BSN door de PGO niet gebruikt mag worden om XIS te raadplegen, aangezien de PGO in het persoonsdomein valt en buiten het zorgaanbiedersdomein. Evenmin mag een BSN door XIS geretourneerd worden naar het persoonsdomein. Er is wel een fBSN (fictieve BSN voor testdoeleinden) in de persoonsgegevens opgenomen, aangezien het beschikbaar stellende systeem (XIS) deze nodig kan hebben.

== Datum T ==
T is een datum die we tijdens de kwalificatie nader invullen / afspreken. Als ergens staat T-100D betekent dit: 100 dagen eerder dan de afgesproken datum.

= Inhoudelijke gegevens scenario’s =
In dit hoofdstuk zijn de addenda van scenario 1.1 en 1.2 te vinden.
== Scenario 1.1 ==
Dit betreft persoon 1 zoals hieronder beschreven.
Met scenario 1.1 wordt getoetst of XIS Basisgegevensset Zorg beschikbaar kan stellen met gebruik van FHIR berichten. Hieronder volgen de inhoudelijke gegevens conform de secties en zibs in publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

===Demografie en identificatie===
{| class="wikitable" width="60%"
!
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;font-weight: bold;;"
|Patiënt.Naamgegevens ||
|-
|Voornamen ||Johan
|-
|Initialen ||J
|-
|Roepnaam ||Johan
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Helleman
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Identificatienummer ||999911120
|-
|Geboortedatum ||25-7-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||
|-
|BurgerlijkeStaat ||Gehuwd
|}

=== Financiële informatie ===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Betaler ||Inhoudelijke gegevens Persoon 1
|-
|BetalerNaam ||XXX_Helleman
|-
|BankNaam ||ING
|-
|Bankcode ||INGBNL2A
|-
|Rekeningnummer ||NL85INGB0001234567
|-
|Verzekering ||
|-
|BeginDatumTijd ||1-1-2018
|-
|EindDatumTijd ||31-1-2019
|-
|Verzekeringssoort ||Basis verzekerd
|-
|IdentificatieNummer ||3332
|-
|OrganisatieNaam ||Menzis Zorgverzekeraar N.V.
|-
|VerzekerdeNummer ||12345678
|-style="background-color: #E3E3E3;;"
|Adresgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|-style="background-color: #E3E3E3;;"
|Contactgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|}

===Behandelrestricties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|BehandelAanwijzing ||Inhoudelijke gegevens Persoon 1
|-
|Geverifieerd ||1
|-
|GeverifieerdBij ||Patiënt
|-
|VerificatieDatum ||9-4-2018
|-
|Behandeling ||Kunstmatige beademing
|-
|BehandelingToegestaan ||Ja, maar met beperkingen
|-
|Beperkingen ||Eerst overleg met echtgenote
|-
|BeginDatum ||9-4-2018
|-
|EindDatum ||
|-
|Toelichting ||
|-
|Wilsverklaring ||
|-
|WilsverklaringType ||Niet reanimeren verklaring
|-
|WilsverklaringDatum ||9-4-2018
|-
|Aandoening ||ALS
|-
|WilsverklaringDocument ||
|-
|Toelichting ||Niet-reanimerenpenning
|-style="background-color: #E3E3E3;;"
|Vertegenwoordiger ||
|-
|Contactpersoon ||Zie contactgegevens contactpersoon BgZ sectie 4
|}

===Contactpersonen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contactpersoon ||Inhoudelijke gegevens Persoon 1
|-
|Voornamen ||Jannie
|-
|Initialen ||J.P.M.
|-
|Roepnaam ||-
|-
|Naamgebruik ||Eigen geslachtsnaam gevolgd door geslachtsnaam partner
|-
|Voorvoegsels ||van
|-
|Achternaam ||Putten
|-
|VoorvoegselsPartner ||-
|-
|AchternaamPartner ||XXX_Helleman
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Huisnummerletter ||-
|-
|Huisnummertoevoeging ||-
|-
|AanduidingBijNummer ||-
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Gemeente ||-
|-
|Land ||Nederland
|-
|AdditioneleInformatie ||-
|-
|AdresSoort ||Woon-/verblijfadres
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Rol ||Eerste relatie/contactpersoon
|-
|Relatie ||Echtgenote
|}

===Functionele status===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|FunctioneleOfMentaleStatus ||Inhoudelijke gegevens Persoon 1
|-
|StatusNaam ||Zich wassen
|-
|StatusWaarde ||Moeite met wassen
|-
|StatusDatum ||2001
|-
|Toelichting ||-
|-
|MedischHulpmiddel ||-
|}

===Klachten en diagnoses===

Let op: er wordt hier één probleem specifiek beschreven, maar in andere BgZ secties zijn meerdere verwijzingen opgenomen die als ‘FHIR condition resources’ beschikbaar gesteld worden. Bijvoorbeeld onder sectie 8. Waarschuwingen.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Probleem ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemAnatomischeLocatie ||Pols
|-
|ProbleemLateraliteit ||Rechts
|-
|ProbleemType ||Diagnose
|-
|ProbleemNaam ||Polsfractuur
|-
|ProbleemBeginDatum ||2001
|-
|ProbleemEindDatum ||
|-
|ProbleemStatus ||Niet actueel
|-
|VerificatieStatus ||Onbekend
|-
|Toelichting ||Gevallen op kunstijsbaan.
|}

===Sociale anamnese===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Woonsituatie || Inhoudelijke gegevens Persoon 1
|-
|WoningType ||Eengezinswoning
|-
|Datum ||30-06-2016
|-style="background-color: #FFFF00;font-weight: bold;;"
|DrugsGebruik ||Inhoudelijke gegevens Persoon 1
|-
|StartDatum ||1981
|-
|StopDatum ||1983
|-
|Hoeveelheid ||3x per jaar
|-
|Toelichting ||Op feestjes en in uitgaanscircuit.
|-
|DrugsOfGeneesmiddelSoort ||Amfetamine, speed
|-
|DrugsGebruikStatus ||heeft in het verleden drugs gebruikt
|-
|Toedieningsweg ||nasaal (snuiven)
|-style="background-color: #FFFF00;font-weight: bold;;"
|AlcoholGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|AlcoholGebruikStatus ||Drinkt alcohol
|-
|StartDatum ||1980
|-
|StopDatum ||
|-
|Hoeveelheid ||4 glazen per week
|-style="background-color: #FFFF00;font-weight: bold;;"
|TabakGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|SoortTabakGebruik ||Rookt sigaretten
|-
|TabakGebruikStatus ||Ex-roker
|-
|StartDatum ||1980
|-
|StopDatum ||1983
|-
|Hoeveelheid ||2 pakjes per week
|-
|PackYears ||1
|-style="background-color: #FFFF00;font-weight: bold;;"
|Voedingsadvies ||Inhoudelijke gegevens Persoon 1
|-
|DieetType ||Energie verrijkt
|-
|Consistentie ||Dikvloeibaar
|-
|Toelichting ||-
|}

===Waarschuwingen===

Let op: er wordt hier één waarschuwing specifiek beschreven, maar in andere BgZ secties zijn meerdere verwijzingen opgenomen die als ‘FHIR condition resources’ beschikbaar gesteld worden.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Alert ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemNaam ||-
|-
|AlertNaam ||Drager MRSA
|-
|BeginDatumTijd ||1-6-2010
|-
|AlertType ||Waarschuwing
|}

===Allergieën===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|AllergieIntolerantie ||Inhoudelijke gegevens Persoon 1
|-
|VeroorzakendeStof ||Bijengif
|-
|AllergieCategorie ||Stof of product
|-
|AllergieStatus ||Actief
|-
|BeginDatumTijd ||8-11-2008
|-
|MateVanKritiekZijn ||Ernstig
|-
|LaatsteReactieDatumTijd ||15-11-2009
|-
|Toelichting ||
|-style="background-color: #E3E3E3;;"
|Reactie ||
|-
|Symptoom ||Misselijk en braken
|-
|SpecifiekeStof ||
|-
|ReactieBeschrijving ||
|-
|Ernst ||Ernstig
|-
|WijzeVanBlootstelling ||
|-
|ReactieTijdstip ||
|}

===Medicatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieAfspraak ||Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||875452574
|-
|Afspraakdatum ||14-8-2016, om 16:30
|-
|RedenMedicatieafspraak ||Starten medicamenteuze behandeling
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||15-8-2016
|-
|Duur ||30 dagen
|-
|FarmaceutischProduct ||Metoclopramide zetpil 10mg, PRK 6920
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|Toedieningsweg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold
|Toedieningsafspraak || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||13610554
|-
|ToedieningsafspraakDatumTijd ||1-6-2018, om 12:25
|-
|RedenAfspraak ||
|-
|Geneesmiddel ||PRIMPERAN ZETPIL 20MG, HPK 229709
|-
|Verstrekker ||Apotheek de Gulle Gaper
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Vanaf 1-6-2018, gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|ToedieningsWeg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieGebruik2 || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||123457000000
|-
|Registratiedatum ||16-8-2018
|-
|GebruikIndicator ||Ja
|-
|VolgensAfspraakIndicator ||Ja
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||28-6-2018
|-
|Einddatum ||
|-
|GebruiksDuur ||3 weken
|-
|Gebruiksproduct ||Zestril tablet 10mg, HPK 615560
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|Gebruiksinstructie ||
|-
|Omschrijving ||1 maal per dag 1 tablet, oraal
|-
|ToedieningsWeg ||Oraal
|-
|Doseerinstructie ||1 maal per dag 1 tablet
|-
|Informatiebron ||Patiënt
|}

===Medische hulpmiddelen===

Let op: er wordt hier één medisch hulpmiddel specifiek beschreven, maar in andere BgZ secties, zoals sectie 15 Verrichtingen, kunnen verwijzingen opgenomen zijn die als ‘FHIR device resources’ beschikbaargesteld worden.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedischeHulpmiddel || Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;"
|Product ||
|-
|ProductID ||-
|-
|ProductType ||Gehoorapparaat
|-
|ProductOmschrijving ||-
|-
|BeginDatum ||2007
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Presbyacusis
|-
|Toelichting ||Apparaat niet zichtbaar (diep in de gehooringang)
|-
|AnatomischeLocatie ||Oor
|-
|Lateraliteit ||Rechts
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|Zorgaanbieder.Organisatienaam ||Test Medisch Centrum
|}

===Vaccinaties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Vaccinatie ||Inhoudelijke gegevens Persoon 1
|-
|ProductCode ||Hepatitis A vaccin
|-
|Dosis ||-
|-
|VaccinatieDatum ||5-3-1999
|-
|GewensteDatumHervaccinatie ||-
|-style="background-color: #E3E3E3;;"
|Toediener ||
|-
|Zorgverlener.Achternaam ||Spuijter
|-
|Toelichting ||Bezoek aan Guatemala.
|}

===Vitale functies===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Bloeddruk ||Inhoudelijke gegevens Persoon 1
|-
|Meetmethode ||Niet-invasief
|-
|ManchetType ||Groot
|-
|MeetLocatie ||Linker bovenarm
|-
|DiastolischEindpunt ||-
|-
|SystolischeBloeddruk ||108 mmHg
|-
|DiastolischeBloeddruk ||56 mmHg
|-
|GemiddeldeBloeddruk ||-
|-
|BloeddrukDatumTijd ||7-2-2013 08:53
|-
|Toelichting ||-
|-
|Houding ||Zittende positie
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamsgewicht ||Inhoudelijke gegevens Persoon 1
|-
|GewichtWaarde ||72 kg
|-
|Toelichting ||-
|-
|GewichtDatumTijd ||8-2-2013
|-
|Kleding ||Lichte kleding/ondergoed
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamslengte ||Inhoudelijke gegevens Persoon 1
|-
|LengteWaarde ||183 cm
|-
|LengteDatumTijd ||8-2-2013 06:43
|-
|Toelichting ||Met schoenen aan
|-
|Positie ||Staande positie
|-
|Uitvoerder ||G.Z.M. de Wit
|}

===Uitslagen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;font-weight: bold;;"
|LaboratoriumUitslag ||Inhoudelijke gegevens Persoon 1
|-
|ResultaatType ||Klinische chemie
|-
|TestCode ||Chloride
|-
|TestDatumTijd ||23-5-2012 12:00
|-
|TestUitslag ||109 mmol/l
|-
|TestUitslagStatus ||Definitief
|-
|ReferentieBovengrens ||108 mmol/l
|-
|ReferentieOndergrens ||99 mmol/l
|-
|InterpretatieVlaggen ||Boven referentie-waarde
|-style="background-color: #E3E3E3;;"
|Monster ||
|-
|Monstermateriaal ||Bloed
|-
|AfnameDatumTijd ||23-5-2012 08:08
|}

===Verrichtingen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Verrichting ||Inhoudelijke gegevens Persoon 1
|-
|VerrichtingStartDatum ||5-6-2012
|-
|VerrichtingEindDatum ||
|-
|VerrichtingAnatomischeLocatie ||Knie
|-
|VerrichtingLateraliteit ||Links
|-
|VerrichtingType ||Knie - prothese implantatie gewricht
|-
|VerrichtingMethode ||
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Artrose
|-
|Toelichting ||Beperking bij het bewegen van het gewricht, drukpijn door slijtage van twee compartimenten van de linker knie.
|-style="background-color: #E3E3E3;;"
|MedischHulpmiddel ||
|-
|ProductType ||Orthopedic surgical implants
|-
|ProductID ||(01)05050474530799
(17)160131
(21)1148130801
|-
|Toelichting ||Implantant, Gen 2 Tibia Insert 5/6-9mm
|-
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-style="background-color: #E3E3E3;;"
|Uitvoerder ||
|-
|Specialisme ||Orthopedie
|-style="background-color: #E3E3E3;;"
|Aanvrager ||
|-
|Zorgverlener ||
|}

===Contacten===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contact ||Inhoudelijke gegevens Persoon 1
|-
|ContactType ||Klinisch
|-
|BeginDatumTijd ||16-8-2012
|-
|EindDatumTijd ||19-8-2012
|-style="background-color: #E3E3E3;;"
|ContactMet ||
|-
|ZorgverlenerNaam ||G.Z.M. de Wit
|-
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-
|-style="background-color: #E3E3E3;;"
|RedenContact ||
|-
|ProbleemNaam ||Fractuur van onderste extremiteit
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Chirurgische reductie van fractuur
|}

===Zorgplan===
Van de betreffende zib OverdrachtGeplandeZorgActiviteit, volgen hieronder instantiaties met verschillend OrderType.

Bij deze zib moet gebruik gemaakt worden van een opvraging van het geplande type zorg. Zo zal VaccinationRecommendation een opvraging moeten doen van de Vaccination (of meerdere Vaccinations). Dit staat verder toegelicht op het [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_BGZ_2017 Technisch Ontwerp.]

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|OverdrachtGeplandeZorgActiviteit ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Verrichting ||
|-
|OrderStatus ||Order geplaatst
|-
|BeginDatum ||12-3-2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Biopt huid
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Naevus wang
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||Test Medisch Centrum
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Vaccinatie ||
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Vaccinatie ||
|-
|ProductCode ||Hepatitis A vaccin
|-
|Toelichting ||Bezoek aan Guatemala.
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Afspraak ||
|-
|OrderStatus ||In afwachting van uitvoering
|-
|BeginDatum ||12 juli 2022 11:30 uur
|-
|EindDatum ||12 juli 2022 11:40 uur
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Afspraak ||
|-
|ContactType ||Poliklinisch
|-
|ContactOnderwerp ||Fysiotherapie Controle afspraak
|-
|OrganisatieNaam ||Test Medisch Centrum
|-
|OrganisatieLocatie ||West vleugel
|}

{| class="wikitable" width="60%"
!Medisch hulpmiddel !!
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Medisch hulpmiddel ||
|-
|ProductID
||(01)05050474530799
(17)220131
(21)0123456789
|-
|ProductType
||Gehoorapparaat
|-
|ProductOmschrijving
||-
|-
|BeginDatum ||2022
|}

===Zorgverleners===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Zorgverlener ||Inhoudelijke gegevens Persoon 1
|-
|Achternaam ||Vaste Huisarts 1
|-
|Specialisme ||0100
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Adresgegevens ||
|-
|Straat ||Valkendael
|-
|Huisnummer ||45
|-
|Postcode ||6245HK
|-
|Woonplaats ||Maastricht
|-
|Land ||Nederland
|-
|AdresSoort ||Werkadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Contactgegevens ||
|-
|Telefoonnummer ||+31434073576
|-
|TelecomType ||Vast telefoonnummer
|-
|NummerSoort ||Zakelijk telefoonnummer
|-
|EmailAdres ||huisarts@huisarts.nl
|-
|EmailSoort ||Zakelijk e-mailadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Zorgaanbieder ||
|-
|OrganisatieNaam ||Maatschap Vaste Huisarts
|-
|OrganisatieType ||Huisartspraktijk (zelfstandig of groepspraktijk)
|}

== Scenario 1.2 ==
Bij scenario 1.2 gaat het om persoon 2, zoals hieronder beschreven, die in XIS slechts bekend is met personalia.
Met scenario 1.2 wordt getoetst of XIS op correcte wijze kenbaar maakt dat er geen gegevens aanwezig zijn. Er zijn geen nadere inhoudelijke BgZ-gegevens die ingevoerd zijn en beschikbaargesteld kunnen worden.

===Demografie en identificatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 2
|-
|Voornamen ||Paul
|-
|Initialen ||P
|-
|Roepnaam ||Paul
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Mesker
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1002
|-
|Postcode ||9999ZZ
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-23456789
|-
|TelecomType ||Mobiel telefoonnummer
|-
|Identificatienummer ||999911284
|-
|Geboortedatum ||1-8-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||Inhoudelijke gegevens Persoon 2
|-
|BurgerlijkeStaat ||Geregistreerd partnerschap
|}

MedMij:Vprepub-2020.01/BgZ Beschikbaarstellen

2021-09-20T07:46:01Z

Eduard de Rijcke: MM-1623 Merge to vprepub

__NOINDEX__
{{MedMij:Vprepub-2020.01/Issuebox}}

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Basisgegevensset Zorg - kwalificatie - Beschikbaarstellen Basisgegevensset Zorg {{VersieInfo|BgZ}}}}
<span class="toclimit-3">__TOC__</span>

= Versiebeheer =


{| class="wikitable"
|+ Versiebeheer
|-
! Datum !! BITS issue !! Omschrijving
|-
| 31-08-2021 || [https://bits.nictiz.nl/browse/MM-2294 MM-2294] || Kwalificatiescript omgezet van PDF-formaat naar wiki
|-
| 12-03-2020 || [https://bits.nictiz.nl/browse/MM-672 MM-672] || Terminologie zib en zibs consistent gemaakt
|}

= Doelgroep =
De doelgroep van dit document is de XIS-leverancier die wil kwalificeren op de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel.

De basis is de BgZ op basis van de publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

= Begrippenlijst =
Er zijn geen specifieke begrippen van toepassing.

= Inleiding =
Deze bladzijde bevat de te doorlopen scripts bij kwalificatie voor de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel. De kwalificatie wordt door de kwalificator uitgevoerd met de Nictiz kwalificatiesimulator, die is ingericht op een FHIR server. De kwalificatiesimulator kan berichten verzenden en ontvangen. Er wordt gebruik gemaakt van testpatiënten met fictieve BSN's.

== Algemene voorwaarden voor kwalificatie ==




Een (kandidaat-) deelnemer kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van MedMij Afsprakenstelsel.
# Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie etc.
# Kennis en begrip van de betreffende MedMij informatiestandaard, zoals beschreven op de informatiestandaarden wiki van Nictiz.
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten andere referenties die de informatiestandaard gebruikt.
# Alle gegevens die de kwalificerende partij zelf moet invoeren zijn te vinden in de kwalificatiedocumentatie. Onjuist ingevoerde gegevens (ook tijd/datum etc.) zullen leiden tot vertraging van en kunnen blokkerend zijn voor het kwalificatieproces.
# Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker. De (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.
# Deze kwalificatie toetst geen infrastructurele eisen.

== Specifieke voorwaarden voor kwalificatie ==
Voor deze informatiestandaard gelden de volgende specifieke voorwaarden:

De kwalificatie is ingericht aan de hand van BgZ secties en de onderliggende zibs. Kennis van de zibs is een voorwaarde voor kwalificatie. BgZ omvat 18 secties, en 28 onderliggende zibs.

Uitgangspunten voor de kwalificatie systeemrol ‘Beschikbaarstellen BgZ’ (XIS):

* Mocht XIS alleen enkele losse secties van de BgZ beschikbaar willen / kunnen stellen, dan kan XIS dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dan kwalificeert XIS voor die informatiestandaard, maar niet voor BgZ. Dit komt overzichtelijkheid ten goede voor persoon en PGO.
* Voorafgaand aan kwalificatie wordt vastgesteld welke BgZ-gegevens ondersteund worden door XIS.
* BgZ gegevens die in XIS vastgelegd worden, dienen ook ontsloten te worden.
* Idealiter ondersteunt een BgZ beschikbaarstellend systeem de gehele BgZ, maar om XIS-leverancier tegemoet te komen, kan XIS kwalificatie starten bij ondersteuning van minimaal 14 van de 18 BgZ secties of 20 van de 28 onderliggende zibs. Dit wijkt bewust af van het uitgangspunt voor PGO, omdat in het zorgproces dat XIS ondersteunt, doorgaans niet de gehele BgZ vastgelegd hoeft te worden. In tegenstelling tot PGO waarin de persoon een zo compleet mogelijk overzicht van zorggegevens wil hebben. Tijdens de kwalificatie moet XIS alle ondersteunde delen laten zien. Voor alle ondersteunde delen moet XIS slagen voor kwalificatie.
* Op technisch niveau moet per zib alle onderliggende data-elementen (verplicht en optioneel) ingebouwd zijn. De vulling van deze data-elementen is afhankelijk van de klinische relevantie bepaald door de use case.
* Als XIS na kwalificatie meer of minder BgZ secties of zibs gaat ondersteunen leidt dit tot een wijziging van de applicatie die herkwalificatie noodzakelijk maakt. Meer informatie over herkwalificatie is te vinden op de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/herkwalificatie herkwalificatie pagina].
* XIS-leverancier ondersteunt ‘Beschikbaarstellen BgZ’ vanaf een bepaalde softwareversie. Deze versie kan binnen het VIPP-programma (module A3) gebruikt worden voor de bepaling van de financiering per ziekenhuis.

Samenvatting:

De gehele BgZ wordt als use case gehanteerd, en de kwalificatie is daarop ingericht.
De gehele BgZ wordt geraadpleegd via losse queries. Er wordt geen gebruik gemaakt van FHIR bundle bij raadplegen en beschikbaarstellen.
XIS kwalificeert bij beschikbaarstellen en kunnen opslaan van minimaal 14 van de 18 BgZ secties. Of 20 van de 28 onderliggende zibs.

== Op te leveren kwalificatiemateriaal door de leverancier ==

# De berichten worden verstuurd vanuit XIS. Verstuur de inhoudelijke gegevens van de kwalificatiescenario's naar de simulator (FHIR-server).
# Schermafdrukken van de kwalificatiescenario's, zoals aangegeven onder "Uit te voeren stappen". Stuur dit materiaal op in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.]]

== Uit te voeren stappen Beschikbaarstellen ==

Voer – voor ieder scenario – de volgende stappen uit:

# Registreer in XIS de patiëntgegevens voor de testpersonen zoals beschreven in de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]]
# Maak in XIS de Basisgegevensset Zorg voor deze personen aan, gebruik hiervoor de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]].
# Maak schermafdrukken van de in XIS ingevoerde gegevens en plaats deze in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.'']]
# Vanaf de kwalificatiesimulator (FHIR-server) kan de uitvraag gegenereerd worden (door kwalificerende XIS zelf) conform de verschillende parameters (bijvoorbeeld voor een bepaalde persoon voor een bepaalde periode), zoals beschreven in de scenario’s.
# Basisgegevensset Zorg gegevens beschikbaarstellen conform de scenario’s.


{| class="wikitable"
|+
|-
! Doel !! Verwacht resultaat
|-
| Aantonen dat het systeem BgZ beschikbaar kan stellen met gebruik van FHIR berichten || Het systeem genereert technisch correcte berichten
|-
| Aantonen dat het systeem kan omgaan met een uitvraag voor persoon waarvoor -naast patiëntgegevens- geen BgZ gegevens bekend zijn (scenario 1.2) || Het systeem maakt op correcte wijze kenbaar dat er geen gegevens aanwezig zijn voor bewuste persoon
|}

Scenario's (vraag aan XIS van 1 specifieke Zorgaanbieder waarmee verbinding is gemaakt)''
*Scenario 1.1: BgZ van persoon 1, zoals beschreven in addendum 1.
*Scenario 1.2: BgZ van persoon 2, zoals beschreven in addendum 2 (nauwelijks BgZ gegevens aanwezig).

= Aandachtspunten voor inhoudelijke gegevens =
== Persoonsgegevens ==
De Basisgegevensset Zorg sectie Demografie en identificatie bevat algemene gegevens over de persoon zoals naam, adres en woonplaats. In het MedMij afsprakenstelsel is vastgelegd dat de BSN door de PGO niet gebruikt mag worden om XIS te raadplegen, aangezien de PGO in het persoonsdomein valt en buiten het zorgaanbiedersdomein. Evenmin mag een BSN door XIS geretourneerd worden naar het persoonsdomein. Er is wel een fBSN (fictieve BSN voor testdoeleinden) in de persoonsgegevens opgenomen, aangezien het beschikbaar stellende systeem (XIS) deze nodig kan hebben.

== Datum T ==
T is een datum die we tijdens de kwalificatie nader invullen / afspreken. Als ergens staat T-100D betekent dit: 100 dagen eerder dan de afgesproken datum.

= Inhoudelijke gegevens scenario’s =
In dit hoofdstuk zijn de addenda van scenario 1.1 en 1.2 te vinden.
== Scenario 1.1 ==
Dit betreft persoon 1 zoals hieronder beschreven.
Met scenario 1.1 wordt getoetst of XIS Basisgegevensset Zorg beschikbaar kan stellen met gebruik van FHIR berichten. Hieronder volgen de inhoudelijke gegevens conform de secties en zibs in publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

===Demografie en identificatie===
{| class="wikitable" width="60%"
!
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;font-weight: bold;;"
|Patiënt.Naamgegevens ||
|-
|Voornamen ||Johan
|-
|Initialen ||J
|-
|Roepnaam ||Johan
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Helleman
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Identificatienummer ||999911120
|-
|Geboortedatum ||25-7-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||
|-
|BurgerlijkeStaat ||Gehuwd
|}

=== Financiële informatie ===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Betaler ||Inhoudelijke gegevens Persoon 1
|-
|BetalerNaam ||XXX_Helleman
|-
|BankNaam ||ING
|-
|Bankcode ||INGBNL2A
|-
|Rekeningnummer ||NL85INGB0001234567
|-
|Verzekering ||
|-
|BeginDatumTijd ||1-1-2018
|-
|EindDatumTijd ||31-1-2019
|-
|Verzekeringssoort ||Basis verzekerd
|-
|IdentificatieNummer ||3332
|-
|OrganisatieNaam ||Menzis Zorgverzekeraar N.V.
|-
|VerzekerdeNummer ||12345678
|-style="background-color: #E3E3E3;;"
|Adresgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|-style="background-color: #E3E3E3;;"
|Contactgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|}

===Behandelrestricties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|BehandelAanwijzing ||Inhoudelijke gegevens Persoon 1
|-
|Geverifieerd ||1
|-
|GeverifieerdBij ||Patiënt
|-
|VerificatieDatum ||9-4-2018
|-
|Behandeling ||Kunstmatige beademing
|-
|BehandelingToegestaan ||Ja, maar met beperkingen
|-
|Beperkingen ||Eerst overleg met echtgenote
|-
|BeginDatum ||9-4-2018
|-
|EindDatum ||
|-
|Toelichting ||
|-
|Wilsverklaring ||
|-
|WilsverklaringType ||Niet reanimeren verklaring
|-
|WilsverklaringDatum ||9-4-2018
|-
|Aandoening ||ALS
|-
|WilsverklaringDocument ||
|-
|Toelichting ||Niet-reanimerenpenning
|-style="background-color: #E3E3E3;;"
|Vertegenwoordiger ||
|-
|Contactpersoon ||Zie contactgegevens contactpersoon BgZ sectie 4
|}

===Contactpersonen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contactpersoon ||Inhoudelijke gegevens Persoon 1
|-
|Voornamen ||Jannie
|-
|Initialen ||J.P.M.
|-
|Roepnaam ||-
|-
|Naamgebruik ||Eigen geslachtsnaam gevolgd door geslachtsnaam partner
|-
|Voorvoegsels ||van
|-
|Achternaam ||Putten
|-
|VoorvoegselsPartner ||-
|-
|AchternaamPartner ||XXX_Helleman
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Huisnummerletter ||-
|-
|Huisnummertoevoeging ||-
|-
|AanduidingBijNummer ||-
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Gemeente ||-
|-
|Land ||Nederland
|-
|AdditioneleInformatie ||-
|-
|AdresSoort ||Woon-/verblijfadres
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Rol ||Eerste relatie/contactpersoon
|-
|Relatie ||Echtgenote
|}

===Functionele status===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|FunctioneleOfMentaleStatus ||Inhoudelijke gegevens Persoon 1
|-
|StatusNaam ||Zich wassen
|-
|StatusWaarde ||Moeite met wassen
|-
|StatusDatum ||2001
|-
|Toelichting ||-
|-
|MedischHulpmiddel ||-
|}

===Klachten en diagnoses===

Let op: er wordt hier één probleem specifiek beschreven, maar in andere BgZ secties zijn meerdere verwijzingen opgenomen die als ‘FHIR condition resources’ beschikbaar gesteld worden. Bijvoorbeeld onder sectie 8. Waarschuwingen.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Probleem ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemAnatomischeLocatie ||Pols
|-
|ProbleemLateraliteit ||Rechts
|-
|ProbleemType ||Diagnose
|-
|ProbleemNaam ||Polsfractuur
|-
|ProbleemBeginDatum ||2001
|-
|ProbleemEindDatum ||
|-
|ProbleemStatus ||Niet actueel
|-
|VerificatieStatus ||Onbekend
|-
|Toelichting ||Gevallen op kunstijsbaan.
|}

===Sociale anamnese===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Woonsituatie || Inhoudelijke gegevens Persoon 1
|-
|WoningType ||Eengezinswoning
|-
|Datum ||30-06-2016
|-style="background-color: #FFFF00;font-weight: bold;;"
|DrugsGebruik ||Inhoudelijke gegevens Persoon 1
|-
|StartDatum ||1981
|-
|StopDatum ||1983
|-
|Hoeveelheid ||3x per jaar
|-
|Toelichting ||Op feestjes en in uitgaanscircuit.
|-
|DrugsOfGeneesmiddelSoort ||Amfetamine, speed
|-
|DrugsGebruikStatus ||heeft in het verleden drugs gebruikt
|-
|Toedieningsweg ||nasaal (snuiven)
|-style="background-color: #FFFF00;font-weight: bold;;"
|AlcoholGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|AlcoholGebruikStatus ||Drinkt alcohol
|-
|StartDatum ||1980
|-
|StopDatum ||
|-
|Hoeveelheid ||4 glazen per week
|-style="background-color: #FFFF00;font-weight: bold;;"
|TabakGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|SoortTabakGebruik ||Rookt sigaretten
|-
|TabakGebruikStatus ||Ex-roker
|-
|StartDatum ||1980
|-
|StopDatum ||1983
|-
|Hoeveelheid ||2 pakjes per week
|-
|PackYears ||1
|-style="background-color: #FFFF00;font-weight: bold;;"
|Voedingsadvies ||Inhoudelijke gegevens Persoon 1
|-
|DieetType ||Energie verrijkt
|-
|Consistentie ||Dikvloeibaar
|-
|Toelichting ||-
|}

===Waarschuwingen===

Let op: er wordt hier één waarschuwing specifiek beschreven, maar in andere BgZ secties zijn meerdere verwijzingen opgenomen die als ‘FHIR condition resources’ beschikbaar gesteld worden.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Alert ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemNaam ||-
|-
|AlertNaam ||Drager MRSA
|-
|BeginDatumTijd ||1-6-2010
|-
|AlertType ||Waarschuwing
|}

===Allergieën===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|AllergieIntolerantie ||Inhoudelijke gegevens Persoon 1
|-
|VeroorzakendeStof ||Bijengif
|-
|AllergieCategorie ||Stof of product
|-
|AllergieStatus ||Actief
|-
|BeginDatumTijd ||8-11-2008
|-
|MateVanKritiekZijn ||Ernstig
|-
|LaatsteReactieDatumTijd ||15-11-2009
|-
|Toelichting ||
|-style="background-color: #E3E3E3;;"
|Reactie ||
|-
|Symptoom ||Misselijk en braken
|-
|SpecifiekeStof ||
|-
|ReactieBeschrijving ||
|-
|Ernst ||Ernstig
|-
|WijzeVanBlootstelling ||
|-
|ReactieTijdstip ||
|}

===Medicatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieAfspraak ||Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||875452574
|-
|Afspraakdatum ||14-8-2016, om 16:30
|-
|RedenMedicatieafspraak ||Starten medicamenteuze behandeling
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||15-8-2016
|-
|Duur ||30 dagen
|-
|FarmaceutischProduct ||Metoclopramide zetpil 10mg, PRK 6920
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|Toedieningsweg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold
|Toedieningsafspraak || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||13610554
|-
|ToedieningsafspraakDatumTijd ||1-6-2018, om 12:25
|-
|RedenAfspraak ||
|-
|Geneesmiddel ||PRIMPERAN ZETPIL 20MG, HPK 229709
|-
|Verstrekker ||Apotheek de Gulle Gaper
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Vanaf 1-6-2018, gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|ToedieningsWeg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieGebruik2 || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||123457000000
|-
|Registratiedatum ||16-8-2018
|-
|GebruikIndicator ||Ja
|-
|VolgensAfspraakIndicator ||Ja
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||28-6-2018
|-
|Einddatum ||
|-
|GebruiksDuur ||3 weken
|-
|Gebruiksproduct ||Zestril tablet 10mg, HPK 615560
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|Gebruiksinstructie ||
|-
|Omschrijving ||1 maal per dag 1 tablet, oraal
|-
|ToedieningsWeg ||Oraal
|-
|Doseerinstructie ||1 maal per dag 1 tablet
|-
|Informatiebron ||Patiënt
|}

===Medische hulpmiddelen===

Let op: er wordt hier één medisch hulpmiddel specifiek beschreven, maar in andere BgZ secties, zoals sectie 15 Verrichtingen, kunnen verwijzingen opgenomen zijn die als ‘FHIR device resources’ beschikbaargesteld worden.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedischeHulpmiddel || Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;"
|Product ||
|-
|ProductID ||-
|-
|ProductType ||Gehoorapparaat
|-
|ProductOmschrijving ||-
|-
|BeginDatum ||2007
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Presbyacusis
|-
|Toelichting ||Apparaat niet zichtbaar (diep in de gehooringang)
|-
|AnatomischeLocatie ||Oor
|-
|Lateraliteit ||Rechts
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|Zorgaanbieder.Organisatienaam ||Test Medisch Centrum
|}

===Vaccinaties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Vaccinatie ||Inhoudelijke gegevens Persoon 1
|-
|ProductCode ||Hepatitis A vaccin
|-
|Dosis ||-
|-
|VaccinatieDatum ||5-3-1999
|-
|GewensteDatumHervaccinatie ||-
|-style="background-color: #E3E3E3;;"
|Toediener ||
|-
|Zorgverlener.Achternaam ||Spuijter
|-
|Toelichting ||Bezoek aan Guatemala.
|}

===Vitale functies===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Bloeddruk ||Inhoudelijke gegevens Persoon 1
|-
|Meetmethode ||Niet-invasief
|-
|ManchetType ||Groot
|-
|MeetLocatie ||Linker bovenarm
|-
|DiastolischEindpunt ||-
|-
|SystolischeBloeddruk ||108 mmHg
|-
|DiastolischeBloeddruk ||56 mmHg
|-
|GemiddeldeBloeddruk ||-
|-
|BloeddrukDatumTijd ||7-2-2013 08:53
|-
|Toelichting ||-
|-
|Houding ||Zittende positie
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamsgewicht ||Inhoudelijke gegevens Persoon 1
|-
|GewichtWaarde ||72 kg
|-
|Toelichting ||-
|-
|GewichtDatumTijd ||8-2-2013
|-
|Kleding ||Lichte kleding/ondergoed
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamslengte ||Inhoudelijke gegevens Persoon 1
|-
|LengteWaarde ||183 cm
|-
|LengteDatumTijd ||8-2-2013 06:43
|-
|Toelichting ||Met schoenen aan
|-
|Positie ||Staande positie
|-
|Uitvoerder ||G.Z.M. de Wit
|}

===Uitslagen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;font-weight: bold;;"
|LaboratoriumUitslag ||Inhoudelijke gegevens Persoon 1
|-
|ResultaatType ||Klinische chemie
|-
|TestCode ||Chloride
|-
|TestDatumTijd ||23-5-2012 12:00
|-
|TestUitslag ||109 mmol/l
|-
|TestUitslagStatus ||Definitief
|-
|ReferentieBovengrens ||108 mmol/l
|-
|ReferentieOndergrens ||99 mmol/l
|-
|InterpretatieVlaggen ||Boven referentie-waarde
|-style="background-color: #E3E3E3;;"
|Monster ||
|-
|Monstermateriaal ||Bloed
|-
|AfnameDatumTijd ||23-5-2012 08:08
|}

===Verrichtingen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Verrichting ||Inhoudelijke gegevens Persoon 1
|-
|VerrichtingStartDatum ||5-6-2012
|-
|VerrichtingEindDatum ||
|-
|VerrichtingAnatomischeLocatie ||Knie
|-
|VerrichtingLateraliteit ||Links
|-
|VerrichtingType ||Knie - prothese implantatie gewricht
|-
|VerrichtingMethode ||
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Artrose
|-
|Toelichting ||Beperking bij het bewegen van het gewricht, drukpijn door slijtage van twee compartimenten van de linker knie.
|-style="background-color: #E3E3E3;;"
|MedischHulpmiddel ||
|-
|ProductType ||Orthopedic surgical implants
|-
|ProductID ||(01)05050474530799
(17)160131
(21)1148130801
|-
|Toelichting ||Implantant, Gen 2 Tibia Insert 5/6-9mm
|-
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-style="background-color: #E3E3E3;;"
|Uitvoerder ||
|-
|Specialisme ||Orthopedie
|-style="background-color: #E3E3E3;;"
|Aanvrager ||
|-
|Zorgverlener ||
|}

===Contacten===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contact ||Inhoudelijke gegevens Persoon 1
|-
|ContactType ||Klinisch
|-
|BeginDatumTijd ||16-8-2012
|-
|EindDatumTijd ||19-8-2012
|-style="background-color: #E3E3E3;;"
|ContactMet ||
|-
|ZorgverlenerNaam ||G.Z.M. de Wit
|-
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-
|-style="background-color: #E3E3E3;;"
|RedenContact ||
|-
|ProbleemNaam ||Fractuur van onderste extremiteit
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Chirurgische reductie van fractuur
|}

===Zorgplan===
Van de betreffende zib OverdrachtGeplandeZorgActiviteit, volgen hieronder instantiaties met verschillend OrderType.

Bij deze zib moet gebruik gemaakt worden van een opvraging van het geplande type zorg. Zo zal VaccinationRecommendation een opvraging moeten doen van de Vaccination (of meerdere Vaccinations). Dit staat verder toegelicht op het [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_BGZ_2017 Technisch Ontwerp.]

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|OverdrachtGeplandeZorgActiviteit ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Verrichting ||
|-
|OrderStatus ||Order geplaatst
|-
|BeginDatum ||12-3-2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Biopt huid
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Naevus wang
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||Test Medisch Centrum
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Vaccinatie ||
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Vaccinatie ||
|-
|ProductCode ||Hepatitis A vaccin
|-
|Toelichting ||Bezoek aan Guatemala.
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Afspraak ||
|-
|OrderStatus ||In afwachting van uitvoering
|-
|BeginDatum ||12 juli 2022 11:30 uur
|-
|EindDatum ||12 juli 2022 11:40 uur
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Afspraak ||
|-
|ContactType ||Poliklinisch
|-
|ContactOnderwerp ||Fysiotherapie Controle afspraak
|-
|OrganisatieNaam ||Test Medisch Centrum
|-
|OrganisatieLocatie ||West vleugel
|}

{| class="wikitable" width="60%"
!Medisch hulpmiddel !!
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Medisch hulpmiddel ||
|-
|ProductID
||(01)05050474530799
(17)220131
(21)0123456789
|-
|ProductType
||Gehoorapparaat
|-
|ProductOmschrijving
||-
|-
|BeginDatum ||2022
|}

===Zorgverleners===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Zorgverlener ||Inhoudelijke gegevens Persoon 1
|-
|Achternaam ||Vaste Huisarts 1
|-
|Specialisme ||0100
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Adresgegevens ||
|-
|Straat ||Valkendael
|-
|Huisnummer ||45
|-
|Postcode ||6245HK
|-
|Woonplaats ||Maastricht
|-
|Land ||Nederland
|-
|AdresSoort ||Werkadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Contactgegevens ||
|-
|Telefoonnummer ||+31434073576
|-
|TelecomType ||Vast telefoonnummer
|-
|NummerSoort ||Zakelijk telefoonnummer
|-
|EmailAdres ||huisarts@huisarts.nl
|-
|EmailSoort ||Zakelijk e-mailadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Zorgaanbieder ||
|-
|OrganisatieNaam ||Maatschap Vaste Huisarts
|-
|OrganisatieType ||Huisartspraktijk (zelfstandig of groepspraktijk)
|}

== Scenario 1.2 ==
Bij scenario 1.2 gaat het om persoon 2, zoals hieronder beschreven, die in XIS slechts bekend is met personalia.
Met scenario 1.2 wordt getoetst of XIS op correcte wijze kenbaar maakt dat er geen gegevens aanwezig zijn. Er zijn geen nadere inhoudelijke BgZ-gegevens die ingevoerd zijn en beschikbaargesteld kunnen worden.

===Demografie en identificatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 2
|-
|Voornamen ||Paul
|-
|Initialen ||P
|-
|Roepnaam ||Paul
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Mesker
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1002
|-
|Postcode ||9999ZZ
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-23456789
|-
|TelecomType ||Mobiel telefoonnummer
|-
|Identificatienummer ||999911284
|-
|Geboortedatum ||1-8-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||Inhoudelijke gegevens Persoon 2
|-
|BurgerlijkeStaat ||Geregistreerd partnerschap
|}

MedMij:V2020.01/FHIR VitalSigns

2021-09-14T14:16:08Z

Eduard de Rijcke: MM-2276 Fixed the canonical urls for the nl-core profiles

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Self-measurements_Icoon.png|link=|87px |links||Self-Measurements]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.

Use cases:
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve vital signs transaction is used by the PHR to retrieve vital signs from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Vital Signs(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request vital signs from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves vital signs to the PHR
|}

==Invocations==
===PHR: request message===
The request message represents an HTTP GET parameterized query from the PHR to the XIS.

====Trigger Events====
When the patient(PHR) wants to obtain vital signs, it issues a retrieve vital signs request message.

====Message Semantics====
'''Search'''

The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/Observation{/$lastn}{?[parameters]}
</pre>

'''Search Parameters'''

The PHR may supply, and the XIS shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification search parameters of [http://hl7.org/fhir/STU3/observation.html#search Observation].

{| class="wikitable"
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
| token
| The classification of the type of observation.

Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
|
Retrieve all Observation resources that are considered a vital sign observation:
<pre>GET [base]/Observation?category=vital-signs</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
| token
| The code of the observation type.

The different types of measurements are specified using the following LOINC codes:
* BloodPressure: 85354-9
* BodyWeight: 29463-7
* BodyHeight: 8302-2
* BodyTemperature: 8310-5
* Oxygenation, saturation, SpO2: 59408-5
* HeartRate: 8867-4
* PulseRate: 8889-8
* BloodGlucose
** fasting: 14770-2
** general: 14743-9
** post-meal: 14760-3
|
Retrieve all Observation resources that are a blood pressure observation:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
Retrieve the most recent body height and the most recent body weight observation:
<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|
Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
|}

=====Expected Actions=====
The XIS shall process the query to find and return the vital signs matching the provided query parameters.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of matching vital signs Observation.

====Trigger Events====
The XIS completed processing of the retrieve vital signs request message.

====Message Semantics====
The body of the response message shall be a Bundle of type "''searchset''" containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type "''searchset''" shall be returned without any Observation as entries.

In the table below, the vital sign zibs and their respective profiles are listed. Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}

<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}

====Expected Actions====
The PHR processes the results according to application-defined rules.

===The <code>lastn</code> operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The [http://hl7.org/fhir/STU3/observation-operations.html#lastn FHIR STU3] specification is vague regarding the sorting mechanism of lastn. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using lastn, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

=Use case: Send Vital Signs=

==Introduction==
The send vital signs transaction is used by the PHR to send vital signs to the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Vital Signs(PUSH)
|style="background-color: white;vertical-align:top;"|Send vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends vital signs to the XIS
|-
|style="background-color: white;vertical-align:top;"|Send vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives vital signs from the PHR
|}

==Invocations==
===PHR: request message===
The send vital sings request message uses the HTTP POST method on the target XIS's base.

====Trigger Events====
This message is invoked when the PHR needs to send one or more vital signs observations to the XIS.

====Message Semantics====
Because sending vital signs will most likely consist of multiple Observations, a batch/transaction transaction is used. This allows for creating a set of resources in a single interaction.

A batch interaction is performed by an HTTP POST command as shown:

<pre>POST [base]</pre>

The body of the post submission is a Bundle with Bundle.type = batch. Each entry carries request details (Bundle.entry.request) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry (note: the request is optional, but SHOULD be present). Every bundle.entry creates a resource using an HTTP POST method. The resource of this entry shall be the vital sign observation.

'''Links:'''

* [http://hl7.org/fhir/STU3/http.html#transaction batch]
* [http://hl7.org/fhir/STU3/http.html#create create]

The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

====Trigger Events====
The XIS completed processing of the send vital signs request message.

====Message Semantics====
The XIS SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Read more:
[http://hl7.org/fhir/STU3/http.html#create create]
[http://hl7.org/fhir/STU3/http.html#transaction batch]

====Expected Actions====
The PHR processes the results according to application-defined rules.

====Handling Errors====
The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Handling_errors Handling Errors section] in the MedMij FHIR IG for more information.

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:Vprepub-2020.01/FHIR VitalSigns

2021-09-14T14:16:08Z

Eduard de Rijcke: MM-2276 Fixed the canonical urls for the nl-core profiles

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
{{MedMij:Vprepub-2020.01/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Self-measurements_Icoon.png|link=|87px |links||Self-Measurements]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.

Use cases:
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub-2020.01/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve vital signs transaction is used by the PHR to retrieve vital signs from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Vital Signs(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request vital signs from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves vital signs to the PHR
|}

==Invocations==
===PHR: request message===
The request message represents an HTTP GET parameterized query from the PHR to the XIS.

====Trigger Events====
When the patient(PHR) wants to obtain vital signs, it issues a retrieve vital signs request message.

====Message Semantics====
'''Search'''

The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/Observation{/$lastn}{?[parameters]}
</pre>

'''Search Parameters'''

The PHR may supply, and the XIS shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification search parameters of [http://hl7.org/fhir/STU3/observation.html#search Observation].

{| class="wikitable"
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
| token
| The classification of the type of observation.

Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
|
Retrieve all Observation resources that are considered a vital sign observation:
<pre>GET [base]/Observation?category=vital-signs</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
| token
| The code of the observation type.

The different types of measurements are specified using the following LOINC codes:
* BloodPressure: 85354-9
* BodyWeight: 29463-7
* BodyHeight: 8302-2
* BodyTemperature: 8310-5
* Oxygenation, saturation, SpO2: 59408-5
* HeartRate: 8867-4
* PulseRate: 8889-8
* BloodGlucose
** fasting: 14770-2
** general: 14743-9
** post-meal: 14760-3
|
Retrieve all Observation resources that are a blood pressure observation:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
Retrieve the most recent body height and the most recent body weight observation:
<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|
Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
|}

=====Expected Actions=====
The XIS shall process the query to find and return the vital signs matching the provided query parameters.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of matching vital signs Observation.

====Trigger Events====
The XIS completed processing of the retrieve vital signs request message.

====Message Semantics====
The body of the response message shall be a Bundle of type "''searchset''" containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type "''searchset''" shall be returned without any Observation as entries.

In the table below, the vital sign zibs and their respective profiles are listed. Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}

<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}

====Expected Actions====
The PHR processes the results according to application-defined rules.

===The <code>lastn</code> operation===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

The [http://hl7.org/fhir/STU3/observation-operations.html#lastn FHIR STU3] specification is vague regarding the sorting mechanism of lastn. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using lastn, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

=Use case: Send Vital Signs=

==Introduction==
The send vital signs transaction is used by the PHR to send vital signs to the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Vital Signs(PUSH)
|style="background-color: white;vertical-align:top;"|Send vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends vital signs to the XIS
|-
|style="background-color: white;vertical-align:top;"|Send vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives vital signs from the PHR
|}

==Invocations==
===PHR: request message===
The send vital sings request message uses the HTTP POST method on the target XIS's base.

====Trigger Events====
This message is invoked when the PHR needs to send one or more vital signs observations to the XIS.

====Message Semantics====
Because sending vital signs will most likely consist of multiple Observations, a batch/transaction transaction is used. This allows for creating a set of resources in a single interaction.

A batch interaction is performed by an HTTP POST command as shown:

<pre>POST [base]</pre>

The body of the post submission is a Bundle with Bundle.type = batch. Each entry carries request details (Bundle.entry.request) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry (note: the request is optional, but SHOULD be present). Every bundle.entry creates a resource using an HTTP POST method. The resource of this entry shall be the vital sign observation.

'''Links:'''

* [http://hl7.org/fhir/STU3/http.html#transaction batch]
* [http://hl7.org/fhir/STU3/http.html#create create]

The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

====Trigger Events====
The XIS completed processing of the send vital signs request message.

====Message Semantics====
The XIS SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Read more:
[http://hl7.org/fhir/STU3/http.html#create create]
[http://hl7.org/fhir/STU3/http.html#transaction batch]

====Expected Actions====
The PHR processes the results according to application-defined rules.

====Handling Errors====
The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Handling_errors Handling Errors section] in the MedMij FHIR IG for more information.

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-2020.01/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:V2020.01/Kwalificatie

2021-05-28T13:54:02Z

Eduard de Rijcke: MM-2068 mergen naar Vprepub

{{MedMij:Vprepub-2020.01/Issuebox}}
__NUMBEREDHEADINGS__





=Introductie=
Nictiz beheert voor Stichting MedMij de informatiestandaarden die binnen MedMij gebruikt worden. Om de informatiestandaarden te kunnen toepassen binnen MedMij, zijn gegevensdiensten gedefinieerd die bestaan uit één of meerdere systeemrollen vanuit een informatiestandaard. Stichting MedMij omschrijft de gegevensdiensten en bepaalt vanaf wanneer en tot hoelang de gegevensdienst op het MedMij-netwerk gebruikt kan worden. Dit doet Stichting MedMij in samenspraak met Nictiz als beheerder. Voor een actueel overzicht van gegevensdiensten, met een verwijzing naar kwalificatie-informatie per systeemrol, raadpleeg de [https://afsprakenstelsel.medmij.nl/display/MMCatalogus/Actuele+gegevensdiensten MedMij Catalogus].

Voor het implementeren van informatiestandaarden en daaruit de gedefinieerde gegevensdiensten voor MedMij, is een Nictiz kwalificatie van toepassing. De kwalificaties worden uitgevoerd door het kwalificatiecentrum van Nictiz en vinden plaats per systeemrolcode. De systeemrolcode vormt de koppeling van een (MedMij) informatiestandaard aan een, in de [https://afsprakenstelsel.medmij.nl/display/MMCatalogus/Actuele+gegevensdiensten MedMij Catalogus] vermelde, gegevensdienst van het MedMij-netwerk.

Kwalificatiescripts en meer informatie over een kwalificatie zijn te vinden via de betreffende paragrafen onder [[MedMij:Vprepub-2020.01/Kwalificatie#Kwalificatiebenodigdheden|kwalificatiebenodigdheden]].<section end=medmij_kwalificatie_introductie />

Voor een optimaal verloop van de kwalificatie is het belangrijk dat via de juiste kanalen wordt gecommuniceerd. Raadpleeg hiervoor het onderstaand communicatiekanalenoverzicht:
* Procedure en planninggerelateerde vragen: [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]
* Inhoudelijke vragen of opmerkingen over de implementatie van informatiestandaarden en gegevensdiensten: [https://bits.nictiz.nl/projects/MM BITS]
* Algemene vragen MedMij: [mailto:info@medmij.nl info@medmij.nl]

In onze [[MedMij:Vprepub-2020.01/Kwalificatie_FAQ|FAQ]] tref je de veelgestelde vragen tijdens het kwalificatietraject.

Het kwalificatiecentrum biedt ook aanvullende dienstverlening voor Stichting MedMij. Wijzigingen bij DVZA’s of DVP’s die een hoog risico vormen voor de interoperabiliteit en kwaliteit van de gegevensuitwisseling kunnen vrijblijvend worden geherkwalificeerd. Herkwalificatie kan noodzakelijk zijn indien:
* Eén van de bronsystemen wordt vervangen door een andere applicatie;
* Een versie-update aan de kant van het het bronsysteem en/of overige betrokken partijen van toepassing is;
* Er een grote update plaatsvindt aan de kant van de DVZA of DVP.

Voor het inplannen van een herkwalificatie kan contact opgenomen worden met [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]

== Kwalificatie gebruik van terminologie ==
Op de kwalificatiepagina wordt gesproken over DVP en PGO of DVZA en XIS. <br>
Een DVP dient altijd te kwalificeren met een PGO en een DVZA dient altijd te kwalificeren met achterliggend bronsysteem of bronsystemen (XIS).

{| class="wikitable"
|-
| '''DVP''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert een Persoonlijke gezondheidsomgeving, een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''DVZA''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert Diensten aan de Zorgaanbieder gerelateerd aan de uitwisseling tussen Persoon en Zorgaanbieder en committeert zich hiervoor aan de naleving van de afspraken van het MedMij Afsprakenstelsel.
|-
| '''Persoonsdomein''' || Alle Personen en alle Dienstverleners personen vormen samen het Persoonsdomein.
|-
| '''PGO''' || Een Persoonlijke gezondheidsomgeving is een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''XIS''' || Het systeem of geheel van de systemen waarin de zorgaanbieder het medisch dossier van de persoon bijhoudt.
|-
| '''Zorgaanbiedersdomein''' || Alle Zorgaanbieders en alle Dienstverleners zorgaanbieder vormen samen het Zorgaanbiedersdomein.
|}

=Algemene voorwaarden voor kwalificatie=
Een (kandidaat-) deelnemer kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van [https://www.medmij.nl/afsprakenstelsel/ MedMij Afsprakenstelsel].
# Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie etc.
# Kennis en begrip van de betreffende [[MedMij:Vprepub-2020.01/Ontwerpen|MedMij informatiestandaard]], zoals beschreven op de informatiestandaarden wiki van Nictiz.
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten andere referenties die de informatiestandaard gebruikt.
# Kennis en begrip en het naleven van de aandachtspunten zoals beschreven in het document '''2. Addenda - Kwalificaties''' als bijlage van de betreffende informatiestandaard.
# Alle gegevens die de kwalificerende partij zelf moet invoeren zijn te vinden in de kwalificatiedocumentatie. Onjuist ingevoerde gegevens (ook tijd/datum etc.) zullen leiden tot vertraging van en kunnen blokkerend zijn voor het kwalificatieproces.
# '''Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker. De (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.'''
# Deze kwalificatie toetst geen infrastructurele eisen.

=Procedurele eisen voor kwalificatie=
Naast de bovengenoemde algemene voorwaarden voor kwalificatie dient een kwalificerende (kandidaat-) deelnemer ook te voldoen aan de procedurele eisen voor kwalificatie. Om het kwalificatietraject niet onnodig te vertragen wordt van een (kandidaat-) deelnemer verwacht dat deze de onderstaande procedurele eisen in acht neemt.

* Indien niet kan worden voldaan aan de functionele en/of technische eisen van een gegevensdienst, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Indien gebruik gemaakt wordt van de vrijheidsgraden die de gegevensdiensten BgGGZ, BgLZ, BgZ en PDF/a bieden, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* De testexecutie dient 100% succesvol geslaagd te zijn voordat gestart kan worden met de kwalificatie. Indien dit niet het geval is dient dit '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Het uitgevoerde certificering-testscript dient niet ouder te zijn dan één week voor de aanlevering van het (pre)kwalificatiemateriaal. Nictiz staat in zijn recht om te bepalen of een test executie is verouderd en daarom af te wijzen.
* Bij het instellen van een variabele T datum door een DVZA, dient de datum gelijk te zijn aan de datum waarop de Touchstone testexecutie is uitgevoerd.
* Voor zowel DVP als DVZA geldt dat de schermafdrukken overeen dienen te komen met de uitgevoerde Touchstone testexecutie die is bijgevoegd in het aanleverformat. Wanneer hier niet aan wordt voldaan leidt dit tot een afwijzing.
* Het kwalificatiemateriaal dient in het juiste formaat aangeleverd te worden. Gebruik voor het aanleveren van het kwalificatiemateriaal altijd het aanleverformat behorende bij de gegevensdienst. In het aanleverformat staat per dia beschreven welke schermafdruk wordt verwacht.
** Voor een DVP geldt dat er schermafdrukken gemaakt dienen te worden van de interface van een PGO.
** Voor een DVZA geldt dat er schermafdrukken gemaakt dienen te worden (van de combinatie) van de achterliggende bronsystemen waarmee men kwalificeert. '''Let op''': Wanneer men voor een nieuwe combinatie van bronsystemen acht te kwalificeren wordt dit behandeld als een nieuwe kwalificatie waarbij ook van die nieuwe combinatie schermafdrukken dienen te worden gemaakt. Schermafdrukken van andere interfaces zoals van een XDS worden afgekeurd.

=Uitgangspunten voor kwalificatie=
In dit hoofdstuk worden de generieke uitgangspunten voor de kwalificatie per systeemrol uiteengezet. Per informatiestandaard kan het voorkomen dat er nog 'specifieke' uitgangspunten op van toepassing zijn, in dat geval, zijn deze opgenomen in een aparte paragraaf onder het hoofdstuk 'Kwalificatie' van het functioneel ontwerp van de informatiestandaard.

==Systeemrol 'Raadplegen' (Persoonsdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Raadplegen':
<section begin=Uitgangspunten_Systeemrol_Raadplegen />
* De set van de gegevensdienst is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.
* Een PGO dient alle functionele data-elementen conform de dataset van de informatiestandaard te tonen aan de gebruiker. De uitzonderingen per gegevensdienst zijn beschreven in de bijbehorende functionele ontwerpen.
* Een PGO biedt de persoon inzicht in de ontvangen respons. Als er géén gegevens beschikbaar gesteld worden, kan dat zijn omdat er geen informatie beschikbaar is in het XIS of vanwege een technische foutmelding. Er volgt bijvoorbeeld een foutmelding indien de resource, een specifieke zib, niet wordt ondersteund in het XIS. Het is een belangrijk inzicht voor de persoon als gegevens technisch niet beschikbaar gesteld kunnen worden.
* Een PGO biedt de persoon inzicht in herkomst van de verzamelde gegevens, en wanneer deze gegevens verzameld zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door de PGO bij ontvangst van de geraadpleegde gegevens.<section end=Uitgangspunten_Systeemrol_Raadplegen />

==Systeemrol 'Beschikbaarstellen' (Zorgaanbiedersdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Beschikbaarstellen':
<section begin=Uitgangspunten_Systeemrol_Beschikbaarstellen />
* Een DVZA dient de gehele gegevensdienst te ondersteunen. Uitzonderingen worden toegelicht in de bijbehorende functionele ontwerpen en kwalificatiescripts.
* Een DVZA geeft technisch correct antwoord op alle searches ongeacht of de gegevens in XIS beschikbaar zijn. XIS stelt alle gegevens beschikbaar voor zover aanwezig.

* Mochten gegevens niet beschikbaar gesteld kunnen worden, dan is uit de respons voor de persoon te herleiden waardoor dit veroorzaakt wordt:
**veroorzaakt door het ontbreken van de informatie
**veroorzaakt doordat het XIS dit technisch niet kan leveren.

* In het geval dat een vraag om gegevens goed wordt verwerkt door het XIS, volgt een respons met daarin 0 tot * FHIR resources die matchen aan de vraag. Als er dus 0 resources in zitten mag de persoon ervan uitgaan dat het XIS deze gegevens niet heeft, maar de vraag wel goed begrepen heeft.

* Als er technisch iets niet goed gaat, stuurt de DVZA conform de specificaties een foutcode terug samen met een OperationOutcome, waarin de oorzaak wordt getoond. Bijvoorbeeld dat de resource, een specifieke zib, niet wordt ondersteund in het XIS. Deze foutcode moet ingebouwd worden door het XIS. Hierop wordt de DVZA ook gekwalificeerd.<section end=Uitgangspunten_Systeemrol_Beschikbaarstellen />

==Systeemrol 'Ontvangen' (Zorgaanbiedersdomein)==
Hieronder volgt een generiek uitgangspunt voor de kwalificatie van de systeemrol 'Ontvangen':
* Een XIS biedt inzicht in herkomst van de ontvangen gegevens, en wanneer deze gegevens ontvangen zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door het XIS bij ontvangst van de gestuurde gegevens.

=Kwalificatie aansluiten op Touchstone=
Nictiz stelt het testsysteem Touchstone beschikbaar voor het testen van systeemrollen met bijbehorende MedMij gegevensdiensten als voorbereiding op het kwalificatieproces.
<br>MedMij (kandidaat-) deelnemers kunnen Touchstone eveneens gebruiken in de ontwikkel- en testfase voor het vroegtijdig testen en/of valideren van de FHIR berichten.
* Documentatie over het aansluiten op Touchstone is te vinden op de pagina Kwalificatie aansluiten in de sectie [[MedMij:Vprepub-2020.01/Kwalificatie_aansluiten#Configureren_simulator|configureren simulator]].
* Voor uitleg over gebruik van de simulator en tokens, zie [[MedMij:Vprepub-2020.01/Qualification | gebruik tokens]]
<section end=medmij_kwalificatie_introductie />
<span id="Kwalificatiescripts"></span><section begin=medmij_kwalificatiescripts />

=Kwalificatiebenodigdheden=
Het kwalificatiemateriaal voor de meest recente versies van de verschillende systeemrollen met bijbehorende MedMij gegevensdiensten is in dit hoofdstuk te vinden.
<br> Voor een actueel overzicht van gegevensdiensten, met een verwijzing naar kwalificatie-informatie per systeemrol, raadpleeg de [https://afsprakenstelsel.medmij.nl/display/MMCatalogus/Actuele+gegevensdiensten MedMij Catalogus].

=Kwalificatiescripts=
==Basisgegevensset Zorg 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen BgZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|3. Aanleverformat - Beschikbaarstellen_BgZ.zip]]
* [[Media: Aanleverformat - Raadplegen BgZ_V2020.01_20210324.zip|3. Aanleverformat - Raadplegen BgZ.zip]]
* [[Media: Beoordelingsformulier_BasisgegevenssetZorg_Beschikbaarstellen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media: Beoordelingsformulier_BasisgegevenssetZorg_Raadplegen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Raadplegen BgZ.pdf]]

===Uitgebreide gegevensset===
Nota bene: onderstaande kwalificatiescripts bevatten een uitgebreidere gegevens set voor de BgZ. Deze worden '''niet''' gebruikt voor kwalificatie.

* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ extended.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ extended.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen BGZ extended.pdf|1. Kwalificatiescript - MedMij Raadplegen BgZ extended.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ Extended.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ Extended.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ Extended.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ Extended.pdf]]

==Labuitwisseling 2.0==
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten_V2020.01_20201027.pdf|1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten_V2020.01.pdf|2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:2._Addenda_-_Kwalificatiescript_–_MedMij_Beschikbaarstellen_Laboratoriumresultaten_V2020.01_20210528.pdf|2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Aanleverformat_-_Beschikbaarstellen_Laboratoriumresultaten_V2020.01_20210528.pptx.zip |3. Aanleverformat - Beschikbaarstellen Laboratoriumresultaten.zip]]
* [[Media: Aanleverformat - Raadplegen Laboratoriumresultaten_V2020.01_20210324.zip|3. Aanleverformat - Raadplegen Laboratoriumresultaten.zip]]
* [[Media: Beoordelingsformulier_Laboratoriumresultaten_Beschikbaarstellen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Beoordelingsformulier_Laboratoriumresultaten_Raadplegen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Raadplegen Laboratoriumresultaten.pdf]]

==AllergieIntolerantie 2.0==

===AllergieIntolerantie===
* [[MedMij:Vprepub-2020.01/kw-MM-AIB-FHIR|1. Kwalificatiescript - MedMij Beschikbaarstellen AllergieIntolerantie gegevens]]
* [[MedMij:Vprepub-2020.01/kw-MM-AIR-FHIR|1. Kwalificatiescript - MedMij Raadplegen AllergieIntolerantie gegevens]]
* [[Media: Aanleverformat - Beschikbaarstellen AllergieIntolerantie_V2020.01_20210324.zip|3. Aanleverformat - Beschikbaarstellen AllergieIntolerantie.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantie_V2020.01_20210324.zip|3. Aanleverformat - Raadplegen AllergieIntolerantie.zip]]
* [[Media: Beoordelingsformulier_AllergieIntolerantie_Raadplegen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Raadplegen AllergieIntolerantie.pdf]]
* [[Media: Beoordelingsformulier_AllergieIntolerantie_Beschikbaarstellen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen AllergieIntolerantie.pdf]]

===AllergieIntolerantieVertaling===
* [[MedMij:Vprepub-2020.01/kw-MM-1.A-AIB-FHIR|1. Kwalificatiescript - MedMij Beschikbaarstellen medicatiegerelateerde allergie- en intolerantiegegevensvertaling]]
* [[MedMij:Vprepub-2020.01/kw-MM-1.A-AIR-FHIR|1. Kwalificatiescript - MedMij Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling]]
* [[Media: Aanleverformat - Beschikbaarstellen AllergieIntolerantieVertaling_V2020.01_20210324.zip|3. Aanleverformat - Beschikbaarstellen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantieVertaling_V2020.01_20210324.zip|3. Aanleverformat - Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.zip]]
* [[Media: Beoordelingsformulier_AllergieIntolerantieVertaling_Raadplegen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.pdf]]
* [[Media: Beoordelingsformulier_AllergieIntolerantieVertaling_Beschikbaarstellen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.pdf]]

==eAfspraak 2.0==
* [[Media:1. Kwalificatiescript - MedMij Raadplegen eAfspraak_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen eAfspraak.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen eAfspraak_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen eAfspraak.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen eAfspraak_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen eAfspraak.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen eAfspraak_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen eAfspraak.pdf]]
* [[Media:Aanleverformat - Raadplegen eAfspraak_V2020.01_20210324.zip|3. Aanleverformat - Raadplegen eAfspraak.zip]]
* [[Media:Aanleverformat - Beschikbaarstellen eAfspraak_V2020.01_20210324.zip|3. Aanleverformat - Beschikbaarstellen eAfspraak.zip]]

==Zelfmetingen 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_V2020.01_20210330.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen_V2020.01_20210330.pdf|1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen_V2020.01_20210330.pdf|1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen Zelfmetingen_V2020.01_20210330.pdf|1. Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_V2020.01_21330.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen_V2020.01_20210330.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen_V2020.01_20210330.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen_V2020.01_20210330.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Zelfmetingen_V2020.01_20210324_v2.zip|3. Aanleverformat - Beschikbaarstellen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Ontvangen Zelfmetingen_V2020.01_20210324_v2.zip|3. Aanleverformat - Ontvangen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Raadplegen Zelfmetingen_V2020.01_20210324_v2.zip|3. Aanleverformat - Raadplegen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Sturen Zelfmetingen_V2020.01_20210324_v2.zip|3. Aanleverformat - Sturen Zelfmetingen.zip]]
* [[Media: Beoordelingsformulier_Zelfmetingen_Beschikbaarstellen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media: Beoordelingsformulier_Zelfmetingen_Ontvangen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media: Beoordelingsformulier_Zelfmetingen_Raadplegen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media: Beoordelingsformulier_Zelfmetingen_Sturen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Sturen Zelfmetingen.pdf]]

==PDF/A 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA_V2020.01_20210429.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen PDFA_V2020.01_20210126.pdf|1. Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen PDFA_V2020.01_20210429.pdf|1. Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen PDFA_V2020.01.pdf|1. Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media:3._Aanleverformat_-_Beschikbaarstellen_PDFA_20210519_V2020.01.zip|3. Aanleverformat - Beschikbaarstellen PDFA.zip]]
* [[Media:3._Aanleverformat_-_Ontvangen_PDFA_20210519_V2020.01.zip|3. Aanleverformat - Ontvangen PDFA.zip]]
* [[Media:3._Aanleverformat_-_Raadplegen_PDFA_20210519_V2020.01.zip|3. Aanleverformat - Raadplegen PDFA.zip]]
* [[Media:3._Aanleverformat_-_Sturen_PDFA_20210519_V2020.01.zip|3. Aanleverformat - Sturen PDFA.zip]]
* [[Media: Beoordelingsformulier_PDFA_Beschikbaarstellen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media: Beoordelingsformulier_PDFA_Ontvangen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Ontvangen PDFA.pdf]]
* [[Media: Beoordelingsformulier_PDFA_Raadplegen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Raadplegen PDFA.pdf]]
* [[Media: Beoordelingsformulier_PDFA_Sturen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Sturen PDFA.pdf]]
* [[Media: PDFA Example Documents.zip|5. Voorbeelddocumenten PDFA voor use case Beschikbaarstellen]]

==Huisartsgegevens 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_V2020.01_20210317.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_V2020.01_20210317.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen huisartsgegevens_V2020.01_20210324.zip|3. Aanleverformat - Beschikbaarstellen huisartsgegevens.zip]]
* [[Media: Aanleverformat - Raadplegen huisartsgegevens_v2020.01_20210324.zip|3. Aanleverformat - Raadplegen huisartsgegevens.zip]]
* [[Media: Beoordelingsformulier_Huisartsgegevens_Beschikbaarstellen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Huisartsgegevens .pdf]]
* [[Media: Beoordelingsformulier_Huisartsgegevens_Raadplegen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Raadplegen Huisartsgegevens .pdf]]

==Basisgegevens GGZ 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_V2020.01_20210223.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_V2020.01_20210429.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Basisgegevens GGZ_V2020.01_20210324.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens GGZ.zip]]
* [[Media: Aanleverformat - Raadplegen Basisgegevens GGZ_V2020.01_20210324.zip|3. Aanleverformat - Raadplegen Basisgegevens GGZ.zip]]
* [[Media: Beoordelingsformulier_BasisgegevensGGZ_Beschikbaarstellen_24032021_2020.01.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Raadplegen_24032021_2020.01.pdf|4. Beoordelingsformulier - MedMij Raadplegen Basisgegevens GGZ.pdf]]

==Beelden 2.0==
* [[Media:1. Kwalificatiescript - MedMij Ontvangen beelden_V2020.01.pdf|1. Kwalificatiescript - MedMij Ontvangen beelden.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen beelden_V2020.01.pdf|1. Kwalificatiescript - MedMij Sturen beelden.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen beelden_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen beelden.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen beelden_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen beelden.pdf]]
* [[Media:Aanleverformat - Ontvangen Beelden_V2020.01_20210324.zip|3. Aanleverformat - Ontvangen Beelden.zip]]
* [[Media:Aanleverformat - Sturen Beelden_V2020.01_20210324.zip|3. Aanleverformat - Sturen Beelden.zip]]

==Basisgegevens Langdurige Zorg 2.0==
{{NoteBox|1= Meld je bij het Nictiz kwalificatiecentrum (via [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]) wanneer je voor de Basisgegevens Langdurige Zorg wilt kwalificeren.}}
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens Langdurige Zorg_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens Langdurige Zorg.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Basisgegevens Langdurige Zorg_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen Basisgegevens Langdurige Zorg.pdf]]
* [[MedMij:V2020.01/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.1|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.1]]
* [[MedMij:V2020.01/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.2|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.2]]
* [[MedMij:V2020.01/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.3|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.3]]
* [[MedMij:V2020.01/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.4|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.4]]
* [[Media: Aanleverformat - Beschikbaarstellen Basisgegevens Langdurige Zorg_V2020.01_20210324.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens Langdurige Zorg.zip]]
* [[Media:3. Aanleverformat - Raadplegen Basisgegevens Langdurige Zorg_V2020.01_20210324.zip|3. Aanleverformat - Raadplegen Basisgegevens Langdurige Zorg.zip]]
* [[Media: Beoordelingsformulier_BasisgegevensLangdurigeZorg_Beschikbaarstellen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Basisgegevens Langdurige Zorg.pdf]]
* [[Media: Beoordelingsformulier_BasisgegevensLangdurigeZorg_Raadplegen_20210324_2020.01.pdf|4. Beoordelingsformulier - MedMij Raadplegen Basisgegevens Langdurige Zorg.pdf]]

==Vragenlijsten 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Vragenlijsten_V2020.01_20210330.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Vragenlijsten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen Vragenlijsten_V2020.01_20210223.pdf|1. Kwalificatiescript - MedMij Ontvangen Vragenlijsten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Vragenlijsten_V2020.01_20210223.pdf|1. Kwalificatiescript - MedMij Raadplegen Vragenlijsten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen Vragenlijsten_V2020.01_20210223.pdf|1. Kwalificatiescript - MedMij Sturen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Vragenlijsten_V2020.01_20210223.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen Vragenlijsten_V2020.01_20210223.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Vragenlijsten_V2020.01_20210223.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Vragenlijsten_V2020.01_20210223.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen Vragenlijsten.pdf]]
* [[Media:Aanleverformat - Beschikbaarstellen vragenlijsten_V2020.01_20210324_v2.zip|3. Aanleverformat - Beschikbaarstellen vragenlijsten.zip]]
* [[Media:Aanleverformat - Ontvangen vragenlijsten_V2020.01_20210324_v2.zip|3. Aanleverformat - Ontvangen vragenlijsten.zip]]
* [[Media:Aanleverformat - Raadplegen vragenlijsten_V2020.01_20210324_v2.zip|3. Aanleverformat - Raadplegen vragenlijsten.zip]]
* [[Media:Aanleverformat - Sturen vragenlijsten_V2020.01_20210324_v2.zip|3. Aanleverformat - Sturen vragenlijsten.zip]]
* [[Media: Beoordelingsformulier_Vragenlijstverwijzing_Raadplegen_20210223.pdf|4. Beoordelingsformulier - MedMij Raadplegen Vragenlijstverwijzing.pdf]]
* [[Media: Beoordelingsformulier_Vragenlijstantwoorden_Sturen_20210223.pdf|4. Beoordelingsformulier - MedMij Sturen Vragenlijstantwoorden.pdf]]

<section end=medmij_kwalificatiescripts />
[[Categorie:Kwalificatie]]