informatiestandaarden - Gebruikersbijdragen [nl]

MedMij:V2019.01 FHIR VitalSigns

2019-08-15T07:57:01Z

Tim Ruijters:

{{#customtitle:MedMij FHIR Implementation Guide Vital Signs 1.2.2}}
{{MedMij:V2019.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:V2019.01_OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.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.

'''Technical note:'''

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:V2019.01_FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:V2019.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]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities CapabilityStatement: Client]
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities CapabilityStatement: Server]
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
{{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 RESTfull] 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?[parameters]{&_format=[mime-type]}
</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="3" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| category
| token
| The classification of the type of observation
|-
| code
| token
| The code of the observation type
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

'''Example searches'''

The PHR should be able to fetch all of a patient's vital signs by searching on:
# category (all vital signs),
# category and date,
# code (specific vital sign),
# code and date,
# code and Last N.

<pre>1. GET [base]/Observation?category=vital-signs
2. GET [base]/Observation?category=vital-signs&date=[date]{&date=[date]}
3. GET [base]/Observation?code[vital sign LOINC{,LOINC2,LOINC3,...}]
4. GET [base]/Observation?code=[vital sign LOINC{,LOINC2,LOINC3,...}]&date=[date]{&date=[date]}
5. GET [base]/Observation/$lastn?code[vital sign LOINC{,LOINC2,LOINC3,...}
</pre>
The following table lists vital signs that have a corresponding ZIB. The column 'LOINC code' shows the LOINC code that can be used in the search query. Other possible codes, including the codes mentioned here, can be found [http://hl7.org/fhir/STU3/observation-vitalsigns.html#vitals-table here].

{| class="wikitable"
|-style="font-weight: bold; "
||ZIB ||LOINC code
|-
|BloodPressure||85354-9
|-
| BodyWeight||29463-7
|-
| BodyHeight||8302-2
|-
| BodyTemperature||8310-5
|-
| Oxygenation, saturation, SpO2||59408-5
|-
| HeartRate||8867-4
|-
| Glucose|| 41604-0 (fasting) 14743-9 (general) 14760-3 (post-meal)
|}
=====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====
Based on the retrieve vital signs request message processing results, the XIS will either return an error or success. When the XIS needs to report an error, it shall use HTTP error response codes and shall include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not vital signs are found or generated, the HTTP status code shall be 200.

''Response Class:''
* Status 200: successful operation
* Status 400: invalid parameter
* Status 401/4xx: unauthorized request
* Status 403: insufficient scope

If the XIS is sending warnings, the Bundle resource shall also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/observation-vitalsigns.html Vital Signs Profile]
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/STU3/search.html Search]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome resource]

=====Message Resource content=====
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 ZIB's 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.]

All returned resources to the PHR SHALL include their related profile canonical URL in the meta.profile element in order to show compliance. The Observation resources in the response message SHALL be a valid instance of these profiles.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.1.x|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| Polsfrequentie||PulseRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate]
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|}

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

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#search Search]

===Operations===
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 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.

===Search parameters===
The following search parameter types and search result parameters need to be supported for this transaction.

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
* [http://hl7.org/fhir/STU3/search.html#date date]

=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] {?_format=[mime-type]}</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.

The resources in the response message SHALL be a valid instance of these profiles. All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.1.x|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable" width="1200px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|-
|}

=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code. If the XIS encounters any errors or if validation fails, the XIS shall return an error as documented in the Message Semantics of the response message.

===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.

When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error.

Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):

* 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules
* 404 Not Found - resource type not supported, or not a FHIR end-point
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail

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.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#create create]
* [http://hl7.org/fhir/STU3/http.html#transaction batch/transaction]

===Operations===
No operations are defined or needed for this transaction.

===Search parameters===
No search parameters are defined or needed for this transaction.

=Terminology, NamingSystems, Mappings=

===Terminology===
Relevant ValueSets can be found through the ValueSet bindings in the listed StructureDefinitions. All ValueSets can be found here [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ValueSet here] and can be downloaded as a .zip in XML or JSON format.

===NamingSystems===
Relevant NamingSystems can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=NamingSystem here].

===Mappings===
A FHIR ConceptMap resource is provided when a FHIR value set is used instead of a HCIM value set. A ConceptMap maps the values between the two value sets. These ConceptMaps can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ConceptMap here].

All profiles include HCIM mappings. HCIM concepts are mapped to the corresponding FHIR elements using the HCIMs concept id. The top of the StructureDefinition contains meta information regarding the HCIM mapping, such as the name and uri of the HCIM. In the StructureDefinition elements, the corresponding HCIM ID is given including the mapping meta information id. This is illustrated in the following example.

<pre>
<StructureDefinition>
<id value="nl-core-patient" />
.....
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<uri value="https://zibs.nl/wiki/Patient-v3.1(2017EN)"/>
<name value="HCIM Patient-v3.1(2017EN)"/>
</mapping>
.....
<element id="Patient.name">
<path value="Patient.name" />
<short value="NameInformation" />
<alias value="Naamgegevens" />
<type>
<code value="HumanName" />
<profile value="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname" />
</type>
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<map value="NL-CM:0.1.6"/>
</mapping>
</element>
.....
</StructureDefinition>
</pre>

=Annex: Document history=
==Release notes==
Release notes can be found on the [[MedMij:V2019.01_OntwerpZelfmetingen#Release_notes|functional design page]].

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 21-06-2019
| style="background-color: white;"|
*Clarification FO with regard to glucose measurement. See [https://bits.nictiz.nl/browse/MM-333 MM-333] for more info.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
*Publication of changes in version 2019.01, conform release notes.
*Moved release notes to functional design page.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 14-01-2019
| style="background-color: white;"| Removed incorrect issuebox.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 12-11-2018
| style="background-color: white;"| Added section "Terminology, NamingSystems, Mappings".
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"| Added version in title, and document history.
|}

[[categorie:MedMij FHIR Use Cases]]

MedMij:Vprepub-2019.01 FHIR VitalSigns

2019-08-15T07:57:01Z

Tim Ruijters:

MedMij:V2019.01 OntwerpZelfmetingen

2019-08-15T07:56:06Z

Tim Ruijters:

{{#customtitle:Functioneel Ontwerp Zelfmetingen 1.2.2 }}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Self-Measuements_zonder_tekst.png |link=|links |85px|Zelfmetingen]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_VitalSigns|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot zelfmetingen van vitale functies die een patiënt kan verzamelen en delen door middel van een PGO. De vitale functies van de mens zijn de lichaamsfuncties die de persoon vitaal of ook wel in leven houden, voorbeelden zijn ademhaling en circulatie (hartslag en bloeddruk).

Momenteel bestaat er geen standaard voor zelfmeet gegevens van de vitale functies. Het doel van deze pagina is om verschillende uitwisseling scenario's van zelfmeet gegevens met de patiënt te beschrijven voor gebruik in MedMij.

Zoals [[MedMij:V2019.01_Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij zorginformatiebouwstenen (ZIB's) als leidraad voor de inhoud van informatie uitwisseling. Voor uitwisseling van zelfmeet gegevens gaat het om de volgende ZIB's:

*Patiënt
*Ademhaling
*Bloeddruk
*Glucose (gebaseerd op zib LaboratoriumUitslag)
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

PGO-leveranciers dienen de beschikbare zib's en/of FHIR profielen te gebruiken. Als er geen specifieke zib en/of FHIR profiel beschikbaar is, gebruik dan zib AlgemeneMeting of LaboratoriumUitslag.

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}
===Specifieke informatie over deze kwalificatie===

De kwalificatie richt zich vooralsnog op: bloeddruk, lichaamsgewicht en glucose. Deze dienen minimaal te worden ondersteund. De verwachting is dat leveranciers zoveel mogelijk zelfmetingen ondersteunen.

=Use Cases=
==Use case: Raadplegen metingen betreffende de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de vitale functie meetwaarden die over henzelf gaan.
===Domein===
Metingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de meetwaarden van vitale functies 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 die van toepassing zijn.

====Raadplegen meetwaarden ====
Informatie elementen in de vraag om meetwaarden van vitale functies.

* Patient identificatienummer
* Periode (startdatum - einddatum)
* Type (soort meetwaarden, bijvoorbeeld bloeddruk)

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om meetwaarden van de vitale functies.

====Beschikbaarstellen meetwaarden meetwaarden====
Informatie elementen in meetwaarden van vitale functies staan hieronder. Het betreffen de Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Glucose (gebaseerd op zib LaboratoriumUitslag)
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

PGO-leveranciers dienen de beschikbare zib's en/of FHIR profielen te gebruiken. Als er geen specifieke zib en/of FHIR profiel beschikbaar is, gebruik dan zib AlgemeneMeting of LaboratoriumUitslag.

=== 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 meetwaarden van vitale functies raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt meetwaarden van vitale functies beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_raadplegen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram Raadplegen meetwaarden vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier]. Hieronder een voor Thomas relevante situatie waarbij het raadplegen van meetwaarden betreffende de vitale functie een rol speelt.

<blockquote>Voordat Thomas zijn consult bij de internist heeft om de resultaten door te spreken worden er een aantal andere waarden getest. Zijn gewicht en zijn bloeddruk worden opgemeten. De laboratoriumwaarden zijn al bekend voordat de internist ze aan Thomas mee kan delen. Alhoewel Thomas zoals gezegd zo min mogelijk met zijn ziekte bezig wil zijn, vindt hij de jaarlijkse controle heel belangrijk. Hij vindt het dan ook heel erg handig om de resultaten van de onderzoeken een dag van tevoren al in te zien in zijn PGO. Hij kan zich zo goed voorbereiden en zal niet meer verrast zijn over de resultaten als zijn internist deze voorlegt.</blockquote>

===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 meetwaarden betreffende de vitale functie een 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 kan na haar opname haar vitale waarden gemeten in ziekenhuis raadplegen. Zo beschikt zij over deze informatie die ze als referentiewaarden kan gebruiken.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de gevraagde meetwaarden van de vitale functies 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 vitale functie meetwaarden tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de meetwaarden van de vitale functies inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden 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) stuurt meetwaarden van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt meetwaarden van de vitale functies op voor de patiënt.
*De zorgverlener gebruikt zijn systeem om de meetwaarden van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft de meetwaarden vitale functies geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* MeetwaardenVitaleFunctiesRaadplegend Systeem in FHIR [MM-1.2.2-MVR-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* MeetwaardenVitaleFunctiesBeschikbaarstellend Systeem in FHIR [MM-1.2.2-MVB-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_raadplegen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Meetwaarden Vitale Functies(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVR-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:V2019.01_FHIR_VitalSigns|Meetwaarden vitale functies in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVB-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_-_MVF_raadplegen.jpg|Use case diagram raadplegen meetwaarden vitale functies]]

'''Use case diagram

==Use case: Sturen zelfmetingen van de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door het kunnen delen van hun zelfmeet gegevens met de zorgverlener.
===Domein===
Zelfmetingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de zelfmeetwaarden van vitale functies vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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
====Sturen zelfmetingen====
Informatie elementen in zelfmetingen betreffende vitale functies staan hieronder. Het betreffen Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

====Ontvangen zelfmetingen====
Het ontvangende systeem stuurt een ontvangstbevestiging van de zelfmetingen.

=== 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 zelfmetingen van vitale functies sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt zelfmetingen van vitale functies
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_sturen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram sturen zelfmetingen vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 sturen van zelfmetingen betreffende de vitale functie een rol speelt.

<blockquote>Sinds een aantal maanden maakt Roos gebruik van een online persoonlijke gezondheidsomgeving. Daarin houdt ze onder andere haar bloedglucosewaarden bij. Daarnaast moet ze zich dagelijks wegen in verband met haar hartfalen. Bij hartfalen is de pompfunctie van het hart verminderd. Het hart pompt niet genoeg bloed rond, hierdoor kun je vocht vasthouden. Om dit te monitoren weegt Roos zich dagelijks, en houdt ze haar gewicht bij in haar persoonlijke gezondheidsomgeving. Wanneer haar gewicht toeneemt, dan krijgt ze een signaal vanuit haar PGO, omdat dit zou kunnen duiden op het vasthouden van vocht. Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke gezondheidsomgeving terug. De huisarts kan op zijn beurt de gegevens die Roos heeft ingevoerd bekijken, bijvoorbeeld met een handige grafiek die haar bloedsuikers over de afgelopen periode laat zien</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stelt zelfmetingen van de vitale functies beschikbaar aan het systeem van een zorgaanbieder (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 zelfmetingen van de vitale functies tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De zorgaanbieder wil de zelfmetingen van de vitale functies inzien en de patiënt stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden te sturen, 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) stuurt zelfmetingen van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt en verwerkt de zelfmetingen van de patiënt.
*De zorgaanbieder gebruikt de het XIS om de zelfmetingen van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft zelfmetingen gestuurd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* ZelfmetingenVitaleFunctiesSturend Systeem in FHIR [MM-1.2.2-ZVS-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* ZelfmetingenVitaleFunctiesOntvangend Systeem in FHIR [MM-1.2.2-ZVO-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_sturen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Zelfmetingen Vitale Functies(PUSH)
|style="background-color: white;vertical-align:top;"|Sturen zelfmetingen van vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVS-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;"|Ontvangen zelfmetingen vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVO-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_-_MVF_sturen.jpg|Use case diagram sturen zelfmetingen vitale functies]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=
==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:1500px; text-align:left;"|Omschrijving
|-
| rowspan = 6; style="background-color: white;"| 2019.01
| style="background-color: white;"| 1.2.1
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-185 MM-185]
| style="background-color: white;"| Verkeerde fixed value voor Observation.code.coding:postBreakfastGlucoseNhgtable45.code
|-
| rowspan = 5; style="background-color: white;"| 1.2.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-175 MM-175]
| style="background-color: white;"| Mapping concept Positie van Zib Lichaamslengte niet duidelijk.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-314 MM-314]
| style="background-color: white;"| Zelfmeting pijnscore FHIR.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-147 MM-147]
| style="background-color: white;"| Mappen PulseRegularity binnen PulseRate.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-141 MM-141]
| style="background-color: white;"| Vital Signs profielen inconsistent m.b.t. baseDefinition.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-95 MM-95]
| style="background-color: white;"| Added support for the lastn operation for retrieving the latest available measurement.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-87 MM-87]
| style="background-color: white;"| The links in the table for FHIR profiles have been updated. The BloodGlucose profile in the Retrieve Vital Signs use case and all profiles under the Send Vital Signs use case linked to a deprecated version.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-80 MM-80]
| style="background-color: white;"| The profile mapping for HCIM element NL-CM:12.6.2 TemperatuurType has been updated Observation.method from Observation.bodySite based on feedback received from the ZIB Centrum that even though the definition appears to point to a body site, that the focus of TemperatureType is a method that includes body site. The profile version was updated to 2.0.1
|-
| 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.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 21-06-2019
| style="background-color: white;"|
* Verduidelijking FO m.b.t. glucose meting. Zie [https://bits.nictiz.nl/browse/MM-333 MM-333] voor meer info.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 28-03-2019
| style="background-color: white;"|
* Plaatsen release notes behorende bij patch 1.
* Versienummer systeemrolcodes ophogen met 1 patch nummer.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| Pijnscore verwijderd uit lijst van toegepaste Zibs voor deze use case. Voor Pijnscore is nog geen FHIR documentatie beschikbaar.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing versienummer naar 1.1.0.
* Wijzigingen doorgevoerd betreffende BITS issue MM-80 en MM-87.
* Kwalificatieparagraaf aangevuld.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:Vprepub-2019.01 OntwerpZelfmetingen

2019-08-15T07:56:06Z

Tim Ruijters:

MedMij:V2019.01 FHIR VitalSigns

2019-06-21T11:06:53Z

Tim Ruijters:

{{#customtitle:MedMij FHIR Implementation Guide Vital Signs 1.2.2}}
{{MedMij:V2019.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:V2019.01_OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.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.

'''Technical note:'''

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:V2019.01_FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:V2019.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]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities CapabilityStatement: Client]
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities CapabilityStatement: Server]
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
{{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 RESTfull] 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?[parameters]{&_format=[mime-type]}
</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="3" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| category
| token
| The classification of the type of observation
|-
| code
| token
| The code of the observation type
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

'''Example searches'''

The PHR should be able to fetch all of a patient's vital signs by searching on:
# category (all vital signs),
# category and date,
# code (specific vital sign),
# code and date,
# code and Last N.

<pre>1. GET [base]/Observation?category=vital-signs
2. GET [base]/Observation?category=vital-signs&date=[date]{&date=[date]}
3. GET [base]/Observation?code[vital sign LOINC{,LOINC2,LOINC3,...}]
4. GET [base]/Observation?code=[vital sign LOINC{,LOINC2,LOINC3,...}]&date=[date]{&date=[date]}
5. GET [base]/Observation/$lastn?code[vital sign LOINC{,LOINC2,LOINC3,...}
</pre>
The following table lists vital signs that have a corresponding ZIB. The column 'LOINC code' shows the LOINC code that can be used in the search query. Other possible codes, including the codes mentioned here, can be found [http://hl7.org/fhir/STU3/observation-vitalsigns.html#vitals-table here].

{| class="wikitable"
|-style="font-weight: bold; "
||ZIB ||LOINC code
|-
|BloodPressure||85354-9
|-
| BodyWeight||29463-7
|-
| BodyHeight||8302-2
|-
| BodyTemperature||8310-5
|-
| Oxygenation, saturation, SpO2||59408-5
|-
| HeartRate||8867-4
|-
| Glucose|| 41604-0 (fasting) 14743-9 (general) 14760-3 (post-meal)
|}
=====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====
Based on the retrieve vital signs request message processing results, the XIS will either return an error or success. When the XIS needs to report an error, it shall use HTTP error response codes and shall include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not vital signs are found or generated, the HTTP status code shall be 200.

''Response Class:''
* Status 200: successful operation
* Status 400: invalid parameter
* Status 401/4xx: unauthorized request
* Status 403: insufficient scope

If the XIS is sending warnings, the Bundle resource shall also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/observation-vitalsigns.html Vital Signs Profile]
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/STU3/search.html Search]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome resource]

=====Message Resource content=====
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 ZIB's 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.]

All returned resources to the PHR SHALL include their related profile canonical URL in the meta.profile element in order to show compliance. The Observation resources in the response message SHALL be a valid instance of these profiles.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.1.x|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| Polsfrequentie||PulseRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate]
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|}

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

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#search Search]

===Operations===
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 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.

===Search parameters===
The following search parameter types and search result parameters need to be supported for this transaction.

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
* [http://hl7.org/fhir/STU3/search.html#date date]

=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] {?_format=[mime-type]}</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.

The resources in the response message SHALL be a valid instance of these profiles. All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.1.x|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable" width="1200px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|-
|}

=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code. If the XIS encounters any errors or if validation fails, the XIS shall return an error as documented in the Message Semantics of the response message.

===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.

When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error.

Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):

* 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules
* 404 Not Found - resource type not supported, or not a FHIR end-point
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail

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.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#create create]
* [http://hl7.org/fhir/STU3/http.html#transaction batch/transaction]

===Operations===
No operations are defined or needed for this transaction.

===Search parameters===
No search parameters are defined or needed for this transaction.

=Terminology, NamingSystems, Mappings=

===Terminology===
Relevant ValueSets can be found through the ValueSet bindings in the listed StructureDefinitions. All ValueSets can be found here [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ValueSet here] and can be downloaded as a .zip in XML or JSON format.

===NamingSystems===
Relevant NamingSystems can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=NamingSystem here].

===Mappings===
A FHIR ConceptMap resource is provided when a FHIR value set is used instead of a HCIM value set. A ConceptMap maps the values between the two value sets. These ConceptMaps can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ConceptMap here].

All profiles include HCIM mappings. HCIM concepts are mapped to the corresponding FHIR elements using the HCIMs concept id. The top of the StructureDefinition contains meta information regarding the HCIM mapping, such as the name and uri of the HCIM. In the StructureDefinition elements, the corresponding HCIM ID is given including the mapping meta information id. This is illustrated in the following example.

<pre>
<StructureDefinition>
<id value="nl-core-patient" />
.....
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<uri value="https://zibs.nl/wiki/Patient-v3.1(2017EN)"/>
<name value="HCIM Patient-v3.1(2017EN)"/>
</mapping>
.....
<element id="Patient.name">
<path value="Patient.name" />
<short value="NameInformation" />
<alias value="Naamgegevens" />
<type>
<code value="HumanName" />
<profile value="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname" />
</type>
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<map value="NL-CM:0.1.6"/>
</mapping>
</element>
.....
</StructureDefinition>
</pre>

=Annex: Document history=
==Release notes==
Release notes can be found on the [[MedMij:V2019.01_OntwerpZelfmetingen#Release_notes|functional design page]].

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 21-06-2019
| style="background-color: white;"|
*Clarification FO with regard to glucose measurement.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
*Publication of changes in version 2019.01, conform release notes.
*Moved release notes to functional design page.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 14-01-2019
| style="background-color: white;"| Removed incorrect issuebox.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 12-11-2018
| style="background-color: white;"| Added section "Terminology, NamingSystems, Mappings".
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"| Added version in title, and document history.
|}

[[categorie:MedMij FHIR Use Cases]]

MedMij:Vprepub-2019.01 FHIR VitalSigns

2019-06-21T11:06:53Z

Tim Ruijters:

{{#customtitle:MedMij FHIR Implementation Guide Vital Signs 1.2.2}}
{{MedMij:V2019.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:V2019.01_OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.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.

'''Technical note:'''

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:V2019.01_FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:V2019.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]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities CapabilityStatement: Client]
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities CapabilityStatement: Server]
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
{{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 RESTfull] 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?[parameters]{&_format=[mime-type]}
</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="3" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| category
| token
| The classification of the type of observation
|-
| code
| token
| The code of the observation type
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

'''Example searches'''

The PHR should be able to fetch all of a patient's vital signs by searching on:
# category (all vital signs),
# category and date,
# code (specific vital sign),
# code and date,
# code and Last N.

<pre>1. GET [base]/Observation?category=vital-signs
2. GET [base]/Observation?category=vital-signs&date=[date]{&date=[date]}
3. GET [base]/Observation?code[vital sign LOINC{,LOINC2,LOINC3,...}]
4. GET [base]/Observation?code=[vital sign LOINC{,LOINC2,LOINC3,...}]&date=[date]{&date=[date]}
5. GET [base]/Observation/$lastn?code[vital sign LOINC{,LOINC2,LOINC3,...}
</pre>
The following table lists vital signs that have a corresponding ZIB. The column 'LOINC code' shows the LOINC code that can be used in the search query. Other possible codes, including the codes mentioned here, can be found [http://hl7.org/fhir/STU3/observation-vitalsigns.html#vitals-table here].

{| class="wikitable"
|-style="font-weight: bold; "
||ZIB ||LOINC code
|-
|BloodPressure||85354-9
|-
| BodyWeight||29463-7
|-
| BodyHeight||8302-2
|-
| BodyTemperature||8310-5
|-
| Oxygenation, saturation, SpO2||59408-5
|-
| HeartRate||8867-4
|-
| Glucose|| 41604-0 (fasting) 14743-9 (general) 14760-3 (post-meal)
|}
=====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====
Based on the retrieve vital signs request message processing results, the XIS will either return an error or success. When the XIS needs to report an error, it shall use HTTP error response codes and shall include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not vital signs are found or generated, the HTTP status code shall be 200.

''Response Class:''
* Status 200: successful operation
* Status 400: invalid parameter
* Status 401/4xx: unauthorized request
* Status 403: insufficient scope

If the XIS is sending warnings, the Bundle resource shall also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/observation-vitalsigns.html Vital Signs Profile]
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/STU3/search.html Search]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome resource]

=====Message Resource content=====
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 ZIB's 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.]

All returned resources to the PHR SHALL include their related profile canonical URL in the meta.profile element in order to show compliance. The Observation resources in the response message SHALL be a valid instance of these profiles.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.1.x|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| Polsfrequentie||PulseRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate]
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|}

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

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#search Search]

===Operations===
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 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.

===Search parameters===
The following search parameter types and search result parameters need to be supported for this transaction.

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
* [http://hl7.org/fhir/STU3/search.html#date date]

=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] {?_format=[mime-type]}</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.

The resources in the response message SHALL be a valid instance of these profiles. All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.1.x|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable" width="1200px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|-
|}

=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code. If the XIS encounters any errors or if validation fails, the XIS shall return an error as documented in the Message Semantics of the response message.

===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.

When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error.

Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):

* 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules
* 404 Not Found - resource type not supported, or not a FHIR end-point
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail

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.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#create create]
* [http://hl7.org/fhir/STU3/http.html#transaction batch/transaction]

===Operations===
No operations are defined or needed for this transaction.

===Search parameters===
No search parameters are defined or needed for this transaction.

=Terminology, NamingSystems, Mappings=

===Terminology===
Relevant ValueSets can be found through the ValueSet bindings in the listed StructureDefinitions. All ValueSets can be found here [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ValueSet here] and can be downloaded as a .zip in XML or JSON format.

===NamingSystems===
Relevant NamingSystems can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=NamingSystem here].

===Mappings===
A FHIR ConceptMap resource is provided when a FHIR value set is used instead of a HCIM value set. A ConceptMap maps the values between the two value sets. These ConceptMaps can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ConceptMap here].

All profiles include HCIM mappings. HCIM concepts are mapped to the corresponding FHIR elements using the HCIMs concept id. The top of the StructureDefinition contains meta information regarding the HCIM mapping, such as the name and uri of the HCIM. In the StructureDefinition elements, the corresponding HCIM ID is given including the mapping meta information id. This is illustrated in the following example.

<pre>
<StructureDefinition>
<id value="nl-core-patient" />
.....
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<uri value="https://zibs.nl/wiki/Patient-v3.1(2017EN)"/>
<name value="HCIM Patient-v3.1(2017EN)"/>
</mapping>
.....
<element id="Patient.name">
<path value="Patient.name" />
<short value="NameInformation" />
<alias value="Naamgegevens" />
<type>
<code value="HumanName" />
<profile value="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname" />
</type>
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<map value="NL-CM:0.1.6"/>
</mapping>
</element>
.....
</StructureDefinition>
</pre>

=Annex: Document history=
==Release notes==
Release notes can be found on the [[MedMij:V2019.01_OntwerpZelfmetingen#Release_notes|functional design page]].

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 21-06-2019
| style="background-color: white;"|
*Clarification FO with regard to glucose measurement.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
*Publication of changes in version 2019.01, conform release notes.
*Moved release notes to functional design page.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 14-01-2019
| style="background-color: white;"| Removed incorrect issuebox.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 12-11-2018
| style="background-color: white;"| Added section "Terminology, NamingSystems, Mappings".
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"| Added version in title, and document history.
|}

[[categorie:MedMij FHIR Use Cases]]

MedMij:V2019.01 FHIR VitalSigns

2019-06-21T11:05:33Z

Tim Ruijters: /* Invocations */

{{#customtitle:MedMij FHIR Implementation Guide Vital Signs 1.2.2}}
{{MedMij:V2019.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:V2019.01_OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.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.

'''Technical note:'''

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:V2019.01_FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:V2019.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]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities CapabilityStatement: Client]
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities CapabilityStatement: Server]
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
{{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 RESTfull] 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?[parameters]{&_format=[mime-type]}
</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="3" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| category
| token
| The classification of the type of observation
|-
| code
| token
| The code of the observation type
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

'''Example searches'''

The PHR should be able to fetch all of a patient's vital signs by searching on:
# category (all vital signs),
# category and date,
# code (specific vital sign),
# code and date,
# code and Last N.

<pre>1. GET [base]/Observation?category=vital-signs
2. GET [base]/Observation?category=vital-signs&date=[date]{&date=[date]}
3. GET [base]/Observation?code[vital sign LOINC{,LOINC2,LOINC3,...}]
4. GET [base]/Observation?code=[vital sign LOINC{,LOINC2,LOINC3,...}]&date=[date]{&date=[date]}
5. GET [base]/Observation/$lastn?code[vital sign LOINC{,LOINC2,LOINC3,...}
</pre>
The following table lists vital signs that have a corresponding ZIB. The column 'LOINC code' shows the LOINC code that can be used in the search query. Other possible codes, including the codes mentioned here, can be found [http://hl7.org/fhir/STU3/observation-vitalsigns.html#vitals-table here].

{| class="wikitable"
|-style="font-weight: bold; "
||ZIB ||LOINC code
|-
|BloodPressure||85354-9
|-
| BodyWeight||29463-7
|-
| BodyHeight||8302-2
|-
| BodyTemperature||8310-5
|-
| Oxygenation, saturation, SpO2||59408-5
|-
| HeartRate||8867-4
|-
| Glucose|| 41604-0 (fasting) 14743-9 (general) 14760-3 (post-meal)
|}
=====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====
Based on the retrieve vital signs request message processing results, the XIS will either return an error or success. When the XIS needs to report an error, it shall use HTTP error response codes and shall include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not vital signs are found or generated, the HTTP status code shall be 200.

''Response Class:''
* Status 200: successful operation
* Status 400: invalid parameter
* Status 401/4xx: unauthorized request
* Status 403: insufficient scope

If the XIS is sending warnings, the Bundle resource shall also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/observation-vitalsigns.html Vital Signs Profile]
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/STU3/search.html Search]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome resource]

=====Message Resource content=====
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 ZIB's 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.]

All returned resources to the PHR SHALL include their related profile canonical URL in the meta.profile element in order to show compliance. The Observation resources in the response message SHALL be a valid instance of these profiles.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.1.x|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| Polsfrequentie||PulseRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate]
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|}

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

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#search Search]

===Operations===
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 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.

===Search parameters===
The following search parameter types and search result parameters need to be supported for this transaction.

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
* [http://hl7.org/fhir/STU3/search.html#date date]

=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] {?_format=[mime-type]}</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.

The resources in the response message SHALL be a valid instance of these profiles. All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.1.x|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable" width="1200px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|-
|}

=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code. If the XIS encounters any errors or if validation fails, the XIS shall return an error as documented in the Message Semantics of the response message.

===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.

When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error.

Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):

* 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules
* 404 Not Found - resource type not supported, or not a FHIR end-point
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail

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.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#create create]
* [http://hl7.org/fhir/STU3/http.html#transaction batch/transaction]

===Operations===
No operations are defined or needed for this transaction.

===Search parameters===
No search parameters are defined or needed for this transaction.

=Terminology, NamingSystems, Mappings=

===Terminology===
Relevant ValueSets can be found through the ValueSet bindings in the listed StructureDefinitions. All ValueSets can be found here [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ValueSet here] and can be downloaded as a .zip in XML or JSON format.

===NamingSystems===
Relevant NamingSystems can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=NamingSystem here].

===Mappings===
A FHIR ConceptMap resource is provided when a FHIR value set is used instead of a HCIM value set. A ConceptMap maps the values between the two value sets. These ConceptMaps can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ConceptMap here].

All profiles include HCIM mappings. HCIM concepts are mapped to the corresponding FHIR elements using the HCIMs concept id. The top of the StructureDefinition contains meta information regarding the HCIM mapping, such as the name and uri of the HCIM. In the StructureDefinition elements, the corresponding HCIM ID is given including the mapping meta information id. This is illustrated in the following example.

<pre>
<StructureDefinition>
<id value="nl-core-patient" />
.....
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<uri value="https://zibs.nl/wiki/Patient-v3.1(2017EN)"/>
<name value="HCIM Patient-v3.1(2017EN)"/>
</mapping>
.....
<element id="Patient.name">
<path value="Patient.name" />
<short value="NameInformation" />
<alias value="Naamgegevens" />
<type>
<code value="HumanName" />
<profile value="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname" />
</type>
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<map value="NL-CM:0.1.6"/>
</mapping>
</element>
.....
</StructureDefinition>
</pre>

=Annex: Document history=
==Release notes==
Release notes can be found on the [[MedMij:V2019.01_OntwerpZelfmetingen#Release_notes|functional design page]].

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
*Publication of changes in version 2019.01, conform release notes.
*Moved release notes to functional design page.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 14-01-2019
| style="background-color: white;"| Removed incorrect issuebox.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 12-11-2018
| style="background-color: white;"| Added section "Terminology, NamingSystems, Mappings".
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"| Added version in title, and document history.
|}

[[categorie:MedMij FHIR Use Cases]]

MedMij:Vprepub-2019.01 FHIR VitalSigns

2019-06-21T11:05:33Z

Tim Ruijters: /* Invocations */

{{#customtitle:MedMij FHIR Implementation Guide Vital Signs 1.2.2}}
{{MedMij:V2019.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:V2019.01_OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.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.

'''Technical note:'''

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:V2019.01_FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:V2019.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]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities CapabilityStatement: Client]
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities CapabilityStatement: Server]
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
{{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 RESTfull] 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?[parameters]{&_format=[mime-type]}
</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="3" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| category
| token
| The classification of the type of observation
|-
| code
| token
| The code of the observation type
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

'''Example searches'''

The PHR should be able to fetch all of a patient's vital signs by searching on:
# category (all vital signs),
# category and date,
# code (specific vital sign),
# code and date,
# code and Last N.

<pre>1. GET [base]/Observation?category=vital-signs
2. GET [base]/Observation?category=vital-signs&date=[date]{&date=[date]}
3. GET [base]/Observation?code[vital sign LOINC{,LOINC2,LOINC3,...}]
4. GET [base]/Observation?code=[vital sign LOINC{,LOINC2,LOINC3,...}]&date=[date]{&date=[date]}
5. GET [base]/Observation/$lastn?code[vital sign LOINC{,LOINC2,LOINC3,...}
</pre>
The following table lists vital signs that have a corresponding ZIB. The column 'LOINC code' shows the LOINC code that can be used in the search query. Other possible codes, including the codes mentioned here, can be found [http://hl7.org/fhir/STU3/observation-vitalsigns.html#vitals-table here].

{| class="wikitable"
|-style="font-weight: bold; "
||ZIB ||LOINC code
|-
|BloodPressure||85354-9
|-
| BodyWeight||29463-7
|-
| BodyHeight||8302-2
|-
| BodyTemperature||8310-5
|-
| Oxygenation, saturation, SpO2||59408-5
|-
| HeartRate||8867-4
|-
| Glucose|| 41604-0 (fasting) 14743-9 (general) 14760-3 (post-meal)
|}
=====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====
Based on the retrieve vital signs request message processing results, the XIS will either return an error or success. When the XIS needs to report an error, it shall use HTTP error response codes and shall include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not vital signs are found or generated, the HTTP status code shall be 200.

''Response Class:''
* Status 200: successful operation
* Status 400: invalid parameter
* Status 401/4xx: unauthorized request
* Status 403: insufficient scope

If the XIS is sending warnings, the Bundle resource shall also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/observation-vitalsigns.html Vital Signs Profile]
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/STU3/search.html Search]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome resource]

=====Message Resource content=====
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 ZIB's 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.]

All returned resources to the PHR SHALL include their related profile canonical URL in the meta.profile element in order to show compliance. The Observation resources in the response message SHALL be a valid instance of these profiles.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.1.x|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| Polsfrequentie||PulseRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate]
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|}

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

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#search Search]

===Operations===
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 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.

===Search parameters===
The following search parameter types and search result parameters need to be supported for this transaction.

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
* [http://hl7.org/fhir/STU3/search.html#date date]

=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] {?_format=[mime-type]}</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.

The resources in the response message SHALL be a valid instance of these profiles. All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.1.x|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable" width="1200px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|-
|}

=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code. If the XIS encounters any errors or if validation fails, the XIS shall return an error as documented in the Message Semantics of the response message.

===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.

When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error.

Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):

* 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules
* 404 Not Found - resource type not supported, or not a FHIR end-point
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail

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.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#create create]
* [http://hl7.org/fhir/STU3/http.html#transaction batch/transaction]

===Operations===
No operations are defined or needed for this transaction.

===Search parameters===
No search parameters are defined or needed for this transaction.

=Terminology, NamingSystems, Mappings=

===Terminology===
Relevant ValueSets can be found through the ValueSet bindings in the listed StructureDefinitions. All ValueSets can be found here [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ValueSet here] and can be downloaded as a .zip in XML or JSON format.

===NamingSystems===
Relevant NamingSystems can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=NamingSystem here].

===Mappings===
A FHIR ConceptMap resource is provided when a FHIR value set is used instead of a HCIM value set. A ConceptMap maps the values between the two value sets. These ConceptMaps can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ConceptMap here].

All profiles include HCIM mappings. HCIM concepts are mapped to the corresponding FHIR elements using the HCIMs concept id. The top of the StructureDefinition contains meta information regarding the HCIM mapping, such as the name and uri of the HCIM. In the StructureDefinition elements, the corresponding HCIM ID is given including the mapping meta information id. This is illustrated in the following example.

<pre>
<StructureDefinition>
<id value="nl-core-patient" />
.....
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<uri value="https://zibs.nl/wiki/Patient-v3.1(2017EN)"/>
<name value="HCIM Patient-v3.1(2017EN)"/>
</mapping>
.....
<element id="Patient.name">
<path value="Patient.name" />
<short value="NameInformation" />
<alias value="Naamgegevens" />
<type>
<code value="HumanName" />
<profile value="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname" />
</type>
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<map value="NL-CM:0.1.6"/>
</mapping>
</element>
.....
</StructureDefinition>
</pre>

=Annex: Document history=
==Release notes==
Release notes can be found on the [[MedMij:V2019.01_OntwerpZelfmetingen#Release_notes|functional design page]].

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
*Publication of changes in version 2019.01, conform release notes.
*Moved release notes to functional design page.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 14-01-2019
| style="background-color: white;"| Removed incorrect issuebox.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 12-11-2018
| style="background-color: white;"| Added section "Terminology, NamingSystems, Mappings".
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"| Added version in title, and document history.
|}

[[categorie:MedMij FHIR Use Cases]]

MedMij:V2019.01 FHIR VitalSigns

2019-06-21T11:02:31Z

Tim Ruijters: Clarification FO with regard to glucose measurement.

{{#customtitle:MedMij FHIR Implementation Guide Vital Signs 1.2.2}}
{{MedMij:V2019.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:V2019.01_OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.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.

'''Technical note:'''

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:V2019.01_FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:V2019.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]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities CapabilityStatement: Client]
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities CapabilityStatement: Server]
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
{{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 RESTfull] 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?[parameters]{&_format=[mime-type]}
</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="3" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| category
| token
| The classification of the type of observation
|-
| code
| token
| The code of the observation type
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

'''Example searches'''

The PHR should be able to fetch all of a patient's vital signs by searching on:
# category (all vital signs),
# category and date,
# code (specific vital sign),
# code and date,
# code and Last N.

<pre>1. GET [base]/Observation?category=vital-signs
2. GET [base]/Observation?category=vital-signs&date=[date]{&date=[date]}
3. GET [base]/Observation?code[vital sign LOINC{,LOINC2,LOINC3,...}]
4. GET [base]/Observation?code=[vital sign LOINC{,LOINC2,LOINC3,...}]&date=[date]{&date=[date]}
5. GET [base]/Observation/$lastn?code[vital sign LOINC{,LOINC2,LOINC3,...}
</pre>
The following table lists vital signs that have a corresponding ZIB. The column 'LOINC code' shows the LOINC code that can be used in the search query. Other possible codes, including the codes mentioned here, can be found [http://hl7.org/fhir/STU3/observation-vitalsigns.html#vitals-table here].

{| class="wikitable"
|-style="font-weight: bold; "
||ZIB ||LOINC code
|-
|BloodPressure||85354-9
|-
| BodyWeight||29463-7
|-
| BodyHeight||8302-2
|-
| BodyTemperature||8310-5
|-
| Oxygenation, saturation, SpO2||59408-5
|-
| HeartRate||8867-4
|-
| Glucose|| 41604-0 (fasting) 14743-9 (general) 14760-3 (post-meal)
|}
=====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====
Based on the retrieve vital signs request message processing results, the XIS will either return an error or success. When the XIS needs to report an error, it shall use HTTP error response codes and shall include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not vital signs are found or generated, the HTTP status code shall be 200.

''Response Class:''
* Status 200: successful operation
* Status 400: invalid parameter
* Status 401/4xx: unauthorized request
* Status 403: insufficient scope

If the XIS is sending warnings, the Bundle resource shall also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/observation-vitalsigns.html Vital Signs Profile]
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/STU3/search.html Search]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome resource]

=====Message Resource content=====
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 ZIB's 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.]

All returned resources to the PHR SHALL include their related profile canonical URL in the meta.profile element in order to show compliance. The Observation resources in the response message SHALL be a valid instance of these profiles.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.1.x|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| Polsfrequentie||PulseRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate]
|-
| -||-||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|}

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

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#search Search]

===Operations===
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 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.

===Search parameters===
The following search parameter types and search result parameters need to be supported for this transaction.

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
* [http://hl7.org/fhir/STU3/search.html#date date]

=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] {?_format=[mime-type]}</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.

The resources in the response message SHALL be a valid instance of these profiles. All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.1.x|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable" width="1200px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|-
|}

=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code. If the XIS encounters any errors or if validation fails, the XIS shall return an error as documented in the Message Semantics of the response message.

===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.

When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error.

Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):

* 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules
* 404 Not Found - resource type not supported, or not a FHIR end-point
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail

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.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#create create]
* [http://hl7.org/fhir/STU3/http.html#transaction batch/transaction]

===Operations===
No operations are defined or needed for this transaction.

===Search parameters===
No search parameters are defined or needed for this transaction.

=Terminology, NamingSystems, Mappings=

===Terminology===
Relevant ValueSets can be found through the ValueSet bindings in the listed StructureDefinitions. All ValueSets can be found here [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ValueSet here] and can be downloaded as a .zip in XML or JSON format.

===NamingSystems===
Relevant NamingSystems can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=NamingSystem here].

===Mappings===
A FHIR ConceptMap resource is provided when a FHIR value set is used instead of a HCIM value set. A ConceptMap maps the values between the two value sets. These ConceptMaps can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ConceptMap here].

All profiles include HCIM mappings. HCIM concepts are mapped to the corresponding FHIR elements using the HCIMs concept id. The top of the StructureDefinition contains meta information regarding the HCIM mapping, such as the name and uri of the HCIM. In the StructureDefinition elements, the corresponding HCIM ID is given including the mapping meta information id. This is illustrated in the following example.

<pre>
<StructureDefinition>
<id value="nl-core-patient" />
.....
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<uri value="https://zibs.nl/wiki/Patient-v3.1(2017EN)"/>
<name value="HCIM Patient-v3.1(2017EN)"/>
</mapping>
.....
<element id="Patient.name">
<path value="Patient.name" />
<short value="NameInformation" />
<alias value="Naamgegevens" />
<type>
<code value="HumanName" />
<profile value="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname" />
</type>
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<map value="NL-CM:0.1.6"/>
</mapping>
</element>
.....
</StructureDefinition>
</pre>

=Annex: Document history=
==Release notes==
Release notes can be found on the [[MedMij:V2019.01_OntwerpZelfmetingen#Release_notes|functional design page]].

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
*Publication of changes in version 2019.01, conform release notes.
*Moved release notes to functional design page.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 14-01-2019
| style="background-color: white;"| Removed incorrect issuebox.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 12-11-2018
| style="background-color: white;"| Added section "Terminology, NamingSystems, Mappings".
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"| Added version in title, and document history.
|}

[[categorie:MedMij FHIR Use Cases]]

MedMij:Vprepub-2019.01 FHIR VitalSigns

2019-06-21T11:02:31Z

Tim Ruijters: Clarification FO with regard to glucose measurement.

{{#customtitle:MedMij FHIR Implementation Guide Vital Signs 1.2.2}}
{{MedMij:V2019.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:V2019.01_OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.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.

'''Technical note:'''

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:V2019.01_FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:V2019.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]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities CapabilityStatement: Client]
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities CapabilityStatement: Server]
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
{{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 RESTfull] 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?[parameters]{&_format=[mime-type]}
</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="3" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| category
| token
| The classification of the type of observation
|-
| code
| token
| The code of the observation type
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

'''Example searches'''

The PHR should be able to fetch all of a patient's vital signs by searching on:
# category (all vital signs),
# category and date,
# code (specific vital sign),
# code and date,
# code and Last N.

<pre>1. GET [base]/Observation?category=vital-signs
2. GET [base]/Observation?category=vital-signs&date=[date]{&date=[date]}
3. GET [base]/Observation?code[vital sign LOINC{,LOINC2,LOINC3,...}]
4. GET [base]/Observation?code=[vital sign LOINC{,LOINC2,LOINC3,...}]&date=[date]{&date=[date]}
5. GET [base]/Observation/$lastn?code[vital sign LOINC{,LOINC2,LOINC3,...}
</pre>
The following table lists vital signs that have a corresponding ZIB. The column 'LOINC code' shows the LOINC code that can be used in the search query. Other possible codes, including the codes mentioned here, can be found [http://hl7.org/fhir/STU3/observation-vitalsigns.html#vitals-table here].

{| class="wikitable"
|-style="font-weight: bold; "
||ZIB ||LOINC code
|-
|BloodPressure||85354-9
|-
| BodyWeight||29463-7
|-
| BodyHeight||8302-2
|-
| BodyTemperature||8310-5
|-
| Oxygenation, saturation, SpO2||59408-5
|-
| HeartRate||8867-4
|-
| Glucose|| 41604-0 (fasting) 14743-9 (general) 14760-3 (post-meal)
|}
=====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====
Based on the retrieve vital signs request message processing results, the XIS will either return an error or success. When the XIS needs to report an error, it shall use HTTP error response codes and shall include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not vital signs are found or generated, the HTTP status code shall be 200.

''Response Class:''
* Status 200: successful operation
* Status 400: invalid parameter
* Status 401/4xx: unauthorized request
* Status 403: insufficient scope

If the XIS is sending warnings, the Bundle resource shall also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/observation-vitalsigns.html Vital Signs Profile]
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/STU3/search.html Search]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome resource]

=====Message Resource content=====
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 ZIB's 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.]

All returned resources to the PHR SHALL include their related profile canonical URL in the meta.profile element in order to show compliance. The Observation resources in the response message SHALL be a valid instance of these profiles.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.1.x|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| Polsfrequentie||PulseRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate]
|-
| -||-||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|}

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

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#search Search]

===Operations===
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 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.

===Search parameters===
The following search parameter types and search result parameters need to be supported for this transaction.

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
* [http://hl7.org/fhir/STU3/search.html#date date]

=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] {?_format=[mime-type]}</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.

The resources in the response message SHALL be a valid instance of these profiles. All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.1.x|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable" width="1200px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|-
|}

=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code. If the XIS encounters any errors or if validation fails, the XIS shall return an error as documented in the Message Semantics of the response message.

===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.

When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error.

Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):

* 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules
* 404 Not Found - resource type not supported, or not a FHIR end-point
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail

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.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#create create]
* [http://hl7.org/fhir/STU3/http.html#transaction batch/transaction]

===Operations===
No operations are defined or needed for this transaction.

===Search parameters===
No search parameters are defined or needed for this transaction.

=Terminology, NamingSystems, Mappings=

===Terminology===
Relevant ValueSets can be found through the ValueSet bindings in the listed StructureDefinitions. All ValueSets can be found here [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ValueSet here] and can be downloaded as a .zip in XML or JSON format.

===NamingSystems===
Relevant NamingSystems can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=NamingSystem here].

===Mappings===
A FHIR ConceptMap resource is provided when a FHIR value set is used instead of a HCIM value set. A ConceptMap maps the values between the two value sets. These ConceptMaps can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ConceptMap here].

All profiles include HCIM mappings. HCIM concepts are mapped to the corresponding FHIR elements using the HCIMs concept id. The top of the StructureDefinition contains meta information regarding the HCIM mapping, such as the name and uri of the HCIM. In the StructureDefinition elements, the corresponding HCIM ID is given including the mapping meta information id. This is illustrated in the following example.

<pre>
<StructureDefinition>
<id value="nl-core-patient" />
.....
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<uri value="https://zibs.nl/wiki/Patient-v3.1(2017EN)"/>
<name value="HCIM Patient-v3.1(2017EN)"/>
</mapping>
.....
<element id="Patient.name">
<path value="Patient.name" />
<short value="NameInformation" />
<alias value="Naamgegevens" />
<type>
<code value="HumanName" />
<profile value="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname" />
</type>
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<map value="NL-CM:0.1.6"/>
</mapping>
</element>
.....
</StructureDefinition>
</pre>

=Annex: Document history=
==Release notes==
Release notes can be found on the [[MedMij:V2019.01_OntwerpZelfmetingen#Release_notes|functional design page]].

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
*Publication of changes in version 2019.01, conform release notes.
*Moved release notes to functional design page.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 14-01-2019
| style="background-color: white;"| Removed incorrect issuebox.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 12-11-2018
| style="background-color: white;"| Added section "Terminology, NamingSystems, Mappings".
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"| Added version in title, and document history.
|}

[[categorie:MedMij FHIR Use Cases]]

MedMij:V2019.01 OntwerpZelfmetingen

2019-06-21T09:07:01Z

Tim Ruijters: /* Algemeen */

{{#customtitle:Functioneel Ontwerp Zelfmetingen 1.2.2 }}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Self-Measuements_zonder_tekst.png |link=|links |85px|Zelfmetingen]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_VitalSigns|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot zelfmetingen van vitale functies die een patiënt kan verzamelen en delen door middel van een PGO. De vitale functies van de mens zijn de lichaamsfuncties die de persoon vitaal of ook wel in leven houden, voorbeelden zijn ademhaling en circulatie (hartslag en bloeddruk).

Momenteel bestaat er geen standaard voor zelfmeet gegevens van de vitale functies. Het doel van deze pagina is om verschillende uitwisseling scenario's van zelfmeet gegevens met de patiënt te beschrijven voor gebruik in MedMij.

Zoals [[MedMij:V2019.01_Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij zorginformatiebouwstenen (ZIB's) als leidraad voor de inhoud van informatie uitwisseling. Voor uitwisseling van zelfmeet gegevens gaat het om de volgende ZIB's:

*Patiënt
*Ademhaling
*Bloeddruk
*Glucose (gebaseerd op zib LaboratoriumUitslag)
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

PGO-leveranciers dienen de beschikbare zib's en/of FHIR profielen te gebruiken. Als er geen specifieke zib en/of FHIR profiel beschikbaar is, gebruik dan zib AlgemeneMeting of LaboratoriumUitslag.

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}
===Specifieke informatie over deze kwalificatie===

De kwalificatie richt zich vooralsnog op: bloeddruk, lichaamsgewicht en glucose. Deze dienen minimaal te worden ondersteund. De verwachting is dat leveranciers zoveel mogelijk zelfmetingen ondersteunen.

=Use Cases=
==Use case: Raadplegen metingen betreffende de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de vitale functie meetwaarden die over henzelf gaan.
===Domein===
Metingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de meetwaarden van vitale functies 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 die van toepassing zijn.

====Raadplegen meetwaarden ====
Informatie elementen in de vraag om meetwaarden van vitale functies.

* Patient identificatienummer
* Periode (startdatum - einddatum)
* Type (soort meetwaarden, bijvoorbeeld bloeddruk)

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om meetwaarden van de vitale functies.

====Beschikbaarstellen meetwaarden meetwaarden====
Informatie elementen in meetwaarden van vitale functies staan hieronder. Het betreffen de Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Glucose (gebaseerd op zib LaboratoriumUitslag)
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

PGO-leveranciers dienen de beschikbare zib's en/of FHIR profielen te gebruiken. Als er geen specifieke zib en/of FHIR profiel beschikbaar is, gebruik dan zib AlgemeneMeting of LaboratoriumUitslag.

=== 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 meetwaarden van vitale functies raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt meetwaarden van vitale functies beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_raadplegen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram Raadplegen meetwaarden vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier]. Hieronder een voor Thomas relevante situatie waarbij het raadplegen van meetwaarden betreffende de vitale functie een rol speelt.

<blockquote>Voordat Thomas zijn consult bij de internist heeft om de resultaten door te spreken worden er een aantal andere waarden getest. Zijn gewicht en zijn bloeddruk worden opgemeten. De laboratoriumwaarden zijn al bekend voordat de internist ze aan Thomas mee kan delen. Alhoewel Thomas zoals gezegd zo min mogelijk met zijn ziekte bezig wil zijn, vindt hij de jaarlijkse controle heel belangrijk. Hij vindt het dan ook heel erg handig om de resultaten van de onderzoeken een dag van tevoren al in te zien in zijn PGO. Hij kan zich zo goed voorbereiden en zal niet meer verrast zijn over de resultaten als zijn internist deze voorlegt.</blockquote>

===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 meetwaarden betreffende de vitale functie een 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 kan na haar opname haar vitale waarden gemeten in ziekenhuis raadplegen. Zo beschikt zij over deze informatie die ze als referentiewaarden kan gebruiken.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de gevraagde meetwaarden van de vitale functies 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 vitale functie meetwaarden tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de meetwaarden van de vitale functies inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden 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) stuurt meetwaarden van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt meetwaarden van de vitale functies op voor de patiënt.
*De zorgverlener gebruikt zijn systeem om de meetwaarden van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft de meetwaarden vitale functies geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* MeetwaardenVitaleFunctiesRaadplegend Systeem in FHIR [MM-1.2.2-MVR-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* MeetwaardenVitaleFunctiesBeschikbaarstellend Systeem in FHIR [MM-1.2.2-MVB-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_raadplegen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Meetwaarden Vitale Functies(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVR-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:V2019.01_FHIR_VitalSigns|Meetwaarden vitale functies in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVB-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_-_MVF_raadplegen.jpg|Use case diagram raadplegen meetwaarden vitale functies]]

'''Use case diagram

==Use case: Sturen zelfmetingen van de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door het kunnen delen van hun zelfmeet gegevens met de zorgverlener.
===Domein===
Zelfmetingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de zelfmeetwaarden van vitale functies vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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
====Sturen zelfmetingen====
Informatie elementen in zelfmetingen betreffende vitale functies staan hieronder. Het betreffen Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

====Ontvangen zelfmetingen====
Het ontvangende systeem stuurt een ontvangstbevestiging van de zelfmetingen.

=== 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 zelfmetingen van vitale functies sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt zelfmetingen van vitale functies
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_sturen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram sturen zelfmetingen vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 sturen van zelfmetingen betreffende de vitale functie een rol speelt.

<blockquote>Sinds een aantal maanden maakt Roos gebruik van een online persoonlijke gezondheidsomgeving. Daarin houdt ze onder andere haar bloedglucosewaarden bij. Daarnaast moet ze zich dagelijks wegen in verband met haar hartfalen. Bij hartfalen is de pompfunctie van het hart verminderd. Het hart pompt niet genoeg bloed rond, hierdoor kun je vocht vasthouden. Om dit te monitoren weegt Roos zich dagelijks, en houdt ze haar gewicht bij in haar persoonlijke gezondheidsomgeving. Wanneer haar gewicht toeneemt, dan krijgt ze een signaal vanuit haar PGO, omdat dit zou kunnen duiden op het vasthouden van vocht. Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke gezondheidsomgeving terug. De huisarts kan op zijn beurt de gegevens die Roos heeft ingevoerd bekijken, bijvoorbeeld met een handige grafiek die haar bloedsuikers over de afgelopen periode laat zien</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stelt zelfmetingen van de vitale functies beschikbaar aan het systeem van een zorgaanbieder (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 zelfmetingen van de vitale functies tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De zorgaanbieder wil de zelfmetingen van de vitale functies inzien en de patiënt stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden te sturen, 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) stuurt zelfmetingen van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt en verwerkt de zelfmetingen van de patiënt.
*De zorgaanbieder gebruikt de het XIS om de zelfmetingen van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft zelfmetingen gestuurd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* ZelfmetingenVitaleFunctiesSturend Systeem in FHIR [MM-1.2.2-ZVS-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* ZelfmetingenVitaleFunctiesOntvangend Systeem in FHIR [MM-1.2.2-ZVO-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_sturen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Zelfmetingen Vitale Functies(PUSH)
|style="background-color: white;vertical-align:top;"|Sturen zelfmetingen van vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVS-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;"|Ontvangen zelfmetingen vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVO-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_-_MVF_sturen.jpg|Use case diagram sturen zelfmetingen vitale functies]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=
==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:1500px; text-align:left;"|Omschrijving
|-
| rowspan = 6; style="background-color: white;"| 2019.01
| style="background-color: white;"| 1.2.1
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-185 MM-185]
| style="background-color: white;"| Verkeerde fixed value voor Observation.code.coding:postBreakfastGlucoseNhgtable45.code
|-
| rowspan = 5; style="background-color: white;"| 1.2.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-175 MM-175]
| style="background-color: white;"| Mapping concept Positie van Zib Lichaamslengte niet duidelijk.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-314 MM-314]
| style="background-color: white;"| Zelfmeting pijnscore FHIR.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-147 MM-147]
| style="background-color: white;"| Mappen PulseRegularity binnen PulseRate.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-141 MM-141]
| style="background-color: white;"| Vital Signs profielen inconsistent m.b.t. baseDefinition.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-95 MM-95]
| style="background-color: white;"| Added support for the lastn operation for retrieving the latest available measurement.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-87 MM-87]
| style="background-color: white;"| The links in the table for FHIR profiles have been updated. The BloodGlucose profile in the Retrieve Vital Signs use case and all profiles under the Send Vital Signs use case linked to a deprecated version.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-80 MM-80]
| style="background-color: white;"| The profile mapping for HCIM element NL-CM:12.6.2 TemperatuurType has been updated Observation.method from Observation.bodySite based on feedback received from the ZIB Centrum that even though the definition appears to point to a body site, that the focus of TemperatureType is a method that includes body site. The profile version was updated to 2.0.1
|-
| 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.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 21-06-2019
| style="background-color: white;"|
* Verduidelijking FO m.b.t. glucose meting.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 28-03-2019
| style="background-color: white;"|
* Plaatsen release notes behorende bij patch 1.
* Versienummer systeemrolcodes ophogen met 1 patch nummer.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| Pijnscore verwijderd uit lijst van toegepaste Zibs voor deze use case. Voor Pijnscore is nog geen FHIR documentatie beschikbaar.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing versienummer naar 1.1.0.
* Wijzigingen doorgevoerd betreffende BITS issue MM-80 en MM-87.
* Kwalificatieparagraaf aangevuld.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:Vprepub-2019.01 OntwerpZelfmetingen

2019-06-21T09:07:01Z

Tim Ruijters: /* Algemeen */

{{#customtitle:Functioneel Ontwerp Zelfmetingen 1.2.2 }}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Self-Measuements_zonder_tekst.png |link=|links |85px|Zelfmetingen]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_VitalSigns|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot zelfmetingen van vitale functies die een patiënt kan verzamelen en delen door middel van een PGO. De vitale functies van de mens zijn de lichaamsfuncties die de persoon vitaal of ook wel in leven houden, voorbeelden zijn ademhaling en circulatie (hartslag en bloeddruk).

Momenteel bestaat er geen standaard voor zelfmeet gegevens van de vitale functies. Het doel van deze pagina is om verschillende uitwisseling scenario's van zelfmeet gegevens met de patiënt te beschrijven voor gebruik in MedMij.

Zoals [[MedMij:V2019.01_Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij zorginformatiebouwstenen (ZIB's) als leidraad voor de inhoud van informatie uitwisseling. Voor uitwisseling van zelfmeet gegevens gaat het om de volgende ZIB's:

*Patiënt
*Ademhaling
*Bloeddruk
*Glucose (gebaseerd op zib LaboratoriumUitslag)
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

PGO-leveranciers dienen de beschikbare zib's en/of FHIR profielen te gebruiken. Als er geen specifieke zib en/of FHIR profiel beschikbaar is, gebruik dan zib AlgemeneMeting of LaboratoriumUitslag.

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}
===Specifieke informatie over deze kwalificatie===

De kwalificatie richt zich vooralsnog op: bloeddruk, lichaamsgewicht en glucose. Deze dienen minimaal te worden ondersteund. De verwachting is dat leveranciers zoveel mogelijk zelfmetingen ondersteunen.

=Use Cases=
==Use case: Raadplegen metingen betreffende de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de vitale functie meetwaarden die over henzelf gaan.
===Domein===
Metingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de meetwaarden van vitale functies 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 die van toepassing zijn.

====Raadplegen meetwaarden ====
Informatie elementen in de vraag om meetwaarden van vitale functies.

* Patient identificatienummer
* Periode (startdatum - einddatum)
* Type (soort meetwaarden, bijvoorbeeld bloeddruk)

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om meetwaarden van de vitale functies.

====Beschikbaarstellen meetwaarden meetwaarden====
Informatie elementen in meetwaarden van vitale functies staan hieronder. Het betreffen de Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Glucose (gebaseerd op zib LaboratoriumUitslag)
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

PGO-leveranciers dienen de beschikbare zib's en/of FHIR profielen te gebruiken. Als er geen specifieke zib en/of FHIR profiel beschikbaar is, gebruik dan zib AlgemeneMeting of LaboratoriumUitslag.

=== 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 meetwaarden van vitale functies raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt meetwaarden van vitale functies beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_raadplegen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram Raadplegen meetwaarden vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier]. Hieronder een voor Thomas relevante situatie waarbij het raadplegen van meetwaarden betreffende de vitale functie een rol speelt.

<blockquote>Voordat Thomas zijn consult bij de internist heeft om de resultaten door te spreken worden er een aantal andere waarden getest. Zijn gewicht en zijn bloeddruk worden opgemeten. De laboratoriumwaarden zijn al bekend voordat de internist ze aan Thomas mee kan delen. Alhoewel Thomas zoals gezegd zo min mogelijk met zijn ziekte bezig wil zijn, vindt hij de jaarlijkse controle heel belangrijk. Hij vindt het dan ook heel erg handig om de resultaten van de onderzoeken een dag van tevoren al in te zien in zijn PGO. Hij kan zich zo goed voorbereiden en zal niet meer verrast zijn over de resultaten als zijn internist deze voorlegt.</blockquote>

===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 meetwaarden betreffende de vitale functie een 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 kan na haar opname haar vitale waarden gemeten in ziekenhuis raadplegen. Zo beschikt zij over deze informatie die ze als referentiewaarden kan gebruiken.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de gevraagde meetwaarden van de vitale functies 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 vitale functie meetwaarden tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de meetwaarden van de vitale functies inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden 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) stuurt meetwaarden van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt meetwaarden van de vitale functies op voor de patiënt.
*De zorgverlener gebruikt zijn systeem om de meetwaarden van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft de meetwaarden vitale functies geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* MeetwaardenVitaleFunctiesRaadplegend Systeem in FHIR [MM-1.2.2-MVR-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* MeetwaardenVitaleFunctiesBeschikbaarstellend Systeem in FHIR [MM-1.2.2-MVB-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_raadplegen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Meetwaarden Vitale Functies(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVR-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:V2019.01_FHIR_VitalSigns|Meetwaarden vitale functies in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVB-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_-_MVF_raadplegen.jpg|Use case diagram raadplegen meetwaarden vitale functies]]

'''Use case diagram

==Use case: Sturen zelfmetingen van de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door het kunnen delen van hun zelfmeet gegevens met de zorgverlener.
===Domein===
Zelfmetingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de zelfmeetwaarden van vitale functies vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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
====Sturen zelfmetingen====
Informatie elementen in zelfmetingen betreffende vitale functies staan hieronder. Het betreffen Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

====Ontvangen zelfmetingen====
Het ontvangende systeem stuurt een ontvangstbevestiging van de zelfmetingen.

=== 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 zelfmetingen van vitale functies sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt zelfmetingen van vitale functies
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_sturen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram sturen zelfmetingen vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 sturen van zelfmetingen betreffende de vitale functie een rol speelt.

<blockquote>Sinds een aantal maanden maakt Roos gebruik van een online persoonlijke gezondheidsomgeving. Daarin houdt ze onder andere haar bloedglucosewaarden bij. Daarnaast moet ze zich dagelijks wegen in verband met haar hartfalen. Bij hartfalen is de pompfunctie van het hart verminderd. Het hart pompt niet genoeg bloed rond, hierdoor kun je vocht vasthouden. Om dit te monitoren weegt Roos zich dagelijks, en houdt ze haar gewicht bij in haar persoonlijke gezondheidsomgeving. Wanneer haar gewicht toeneemt, dan krijgt ze een signaal vanuit haar PGO, omdat dit zou kunnen duiden op het vasthouden van vocht. Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke gezondheidsomgeving terug. De huisarts kan op zijn beurt de gegevens die Roos heeft ingevoerd bekijken, bijvoorbeeld met een handige grafiek die haar bloedsuikers over de afgelopen periode laat zien</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stelt zelfmetingen van de vitale functies beschikbaar aan het systeem van een zorgaanbieder (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 zelfmetingen van de vitale functies tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De zorgaanbieder wil de zelfmetingen van de vitale functies inzien en de patiënt stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden te sturen, 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) stuurt zelfmetingen van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt en verwerkt de zelfmetingen van de patiënt.
*De zorgaanbieder gebruikt de het XIS om de zelfmetingen van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft zelfmetingen gestuurd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* ZelfmetingenVitaleFunctiesSturend Systeem in FHIR [MM-1.2.2-ZVS-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* ZelfmetingenVitaleFunctiesOntvangend Systeem in FHIR [MM-1.2.2-ZVO-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_sturen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Zelfmetingen Vitale Functies(PUSH)
|style="background-color: white;vertical-align:top;"|Sturen zelfmetingen van vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVS-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;"|Ontvangen zelfmetingen vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVO-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_-_MVF_sturen.jpg|Use case diagram sturen zelfmetingen vitale functies]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=
==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:1500px; text-align:left;"|Omschrijving
|-
| rowspan = 6; style="background-color: white;"| 2019.01
| style="background-color: white;"| 1.2.1
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-185 MM-185]
| style="background-color: white;"| Verkeerde fixed value voor Observation.code.coding:postBreakfastGlucoseNhgtable45.code
|-
| rowspan = 5; style="background-color: white;"| 1.2.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-175 MM-175]
| style="background-color: white;"| Mapping concept Positie van Zib Lichaamslengte niet duidelijk.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-314 MM-314]
| style="background-color: white;"| Zelfmeting pijnscore FHIR.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-147 MM-147]
| style="background-color: white;"| Mappen PulseRegularity binnen PulseRate.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-141 MM-141]
| style="background-color: white;"| Vital Signs profielen inconsistent m.b.t. baseDefinition.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-95 MM-95]
| style="background-color: white;"| Added support for the lastn operation for retrieving the latest available measurement.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-87 MM-87]
| style="background-color: white;"| The links in the table for FHIR profiles have been updated. The BloodGlucose profile in the Retrieve Vital Signs use case and all profiles under the Send Vital Signs use case linked to a deprecated version.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-80 MM-80]
| style="background-color: white;"| The profile mapping for HCIM element NL-CM:12.6.2 TemperatuurType has been updated Observation.method from Observation.bodySite based on feedback received from the ZIB Centrum that even though the definition appears to point to a body site, that the focus of TemperatureType is a method that includes body site. The profile version was updated to 2.0.1
|-
| 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.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 21-06-2019
| style="background-color: white;"|
* Verduidelijking FO m.b.t. glucose meting.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 28-03-2019
| style="background-color: white;"|
* Plaatsen release notes behorende bij patch 1.
* Versienummer systeemrolcodes ophogen met 1 patch nummer.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| Pijnscore verwijderd uit lijst van toegepaste Zibs voor deze use case. Voor Pijnscore is nog geen FHIR documentatie beschikbaar.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing versienummer naar 1.1.0.
* Wijzigingen doorgevoerd betreffende BITS issue MM-80 en MM-87.
* Kwalificatieparagraaf aangevuld.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:V2019.01 OntwerpZelfmetingen

2019-06-21T09:05:59Z

Tim Ruijters: /* Algemeen */

{{#customtitle:Functioneel Ontwerp Zelfmetingen 1.2.2 }}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Self-Measuements_zonder_tekst.png |link=|links |85px|Zelfmetingen]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_VitalSigns|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot zelfmetingen van vitale functies die een patiënt kan verzamelen en delen door middel van een PGO. De vitale functies van de mens zijn de lichaamsfuncties die de persoon vitaal of ook wel in leven houden, voorbeelden zijn ademhaling en circulatie (hartslag en bloeddruk).

Momenteel bestaat er geen standaard voor zelfmeet gegevens van de vitale functies. Het doel van deze pagina is om verschillende uitwisseling scenario's van zelfmeet gegevens met de patiënt te beschrijven voor gebruik in MedMij.

Zoals [[MedMij:V2019.01_Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij zorginformatiebouwstenen (ZIB's) als leidraad voor de inhoud van informatie uitwisseling. Voor uitwisseling van zelfmeet gegevens gaat het om de volgende ZIB's:

*Patiënt
*Ademhaling
*Bloeddruk
*Glucose (gebaseerd op zib LaboratoriumUitslag)
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}
===Specifieke informatie over deze kwalificatie===

De kwalificatie richt zich vooralsnog op: bloeddruk, lichaamsgewicht en glucose. Deze dienen minimaal te worden ondersteund. De verwachting is dat leveranciers zoveel mogelijk zelfmetingen ondersteunen.

=Use Cases=
==Use case: Raadplegen metingen betreffende de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de vitale functie meetwaarden die over henzelf gaan.
===Domein===
Metingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de meetwaarden van vitale functies 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 die van toepassing zijn.

====Raadplegen meetwaarden ====
Informatie elementen in de vraag om meetwaarden van vitale functies.

* Patient identificatienummer
* Periode (startdatum - einddatum)
* Type (soort meetwaarden, bijvoorbeeld bloeddruk)

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om meetwaarden van de vitale functies.

====Beschikbaarstellen meetwaarden meetwaarden====
Informatie elementen in meetwaarden van vitale functies staan hieronder. Het betreffen de Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Glucose (gebaseerd op zib LaboratoriumUitslag)
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

PGO-leveranciers dienen de beschikbare zib's en/of FHIR profielen te gebruiken. Als er geen specifieke zib en/of FHIR profiel beschikbaar is, gebruik dan zib AlgemeneMeting of LaboratoriumUitslag.

=== 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 meetwaarden van vitale functies raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt meetwaarden van vitale functies beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_raadplegen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram Raadplegen meetwaarden vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier]. Hieronder een voor Thomas relevante situatie waarbij het raadplegen van meetwaarden betreffende de vitale functie een rol speelt.

<blockquote>Voordat Thomas zijn consult bij de internist heeft om de resultaten door te spreken worden er een aantal andere waarden getest. Zijn gewicht en zijn bloeddruk worden opgemeten. De laboratoriumwaarden zijn al bekend voordat de internist ze aan Thomas mee kan delen. Alhoewel Thomas zoals gezegd zo min mogelijk met zijn ziekte bezig wil zijn, vindt hij de jaarlijkse controle heel belangrijk. Hij vindt het dan ook heel erg handig om de resultaten van de onderzoeken een dag van tevoren al in te zien in zijn PGO. Hij kan zich zo goed voorbereiden en zal niet meer verrast zijn over de resultaten als zijn internist deze voorlegt.</blockquote>

===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 meetwaarden betreffende de vitale functie een 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 kan na haar opname haar vitale waarden gemeten in ziekenhuis raadplegen. Zo beschikt zij over deze informatie die ze als referentiewaarden kan gebruiken.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de gevraagde meetwaarden van de vitale functies 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 vitale functie meetwaarden tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de meetwaarden van de vitale functies inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden 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) stuurt meetwaarden van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt meetwaarden van de vitale functies op voor de patiënt.
*De zorgverlener gebruikt zijn systeem om de meetwaarden van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft de meetwaarden vitale functies geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* MeetwaardenVitaleFunctiesRaadplegend Systeem in FHIR [MM-1.2.2-MVR-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* MeetwaardenVitaleFunctiesBeschikbaarstellend Systeem in FHIR [MM-1.2.2-MVB-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_raadplegen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Meetwaarden Vitale Functies(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVR-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:V2019.01_FHIR_VitalSigns|Meetwaarden vitale functies in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVB-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_-_MVF_raadplegen.jpg|Use case diagram raadplegen meetwaarden vitale functies]]

'''Use case diagram

==Use case: Sturen zelfmetingen van de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door het kunnen delen van hun zelfmeet gegevens met de zorgverlener.
===Domein===
Zelfmetingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de zelfmeetwaarden van vitale functies vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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
====Sturen zelfmetingen====
Informatie elementen in zelfmetingen betreffende vitale functies staan hieronder. Het betreffen Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

====Ontvangen zelfmetingen====
Het ontvangende systeem stuurt een ontvangstbevestiging van de zelfmetingen.

=== 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 zelfmetingen van vitale functies sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt zelfmetingen van vitale functies
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_sturen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram sturen zelfmetingen vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 sturen van zelfmetingen betreffende de vitale functie een rol speelt.

<blockquote>Sinds een aantal maanden maakt Roos gebruik van een online persoonlijke gezondheidsomgeving. Daarin houdt ze onder andere haar bloedglucosewaarden bij. Daarnaast moet ze zich dagelijks wegen in verband met haar hartfalen. Bij hartfalen is de pompfunctie van het hart verminderd. Het hart pompt niet genoeg bloed rond, hierdoor kun je vocht vasthouden. Om dit te monitoren weegt Roos zich dagelijks, en houdt ze haar gewicht bij in haar persoonlijke gezondheidsomgeving. Wanneer haar gewicht toeneemt, dan krijgt ze een signaal vanuit haar PGO, omdat dit zou kunnen duiden op het vasthouden van vocht. Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke gezondheidsomgeving terug. De huisarts kan op zijn beurt de gegevens die Roos heeft ingevoerd bekijken, bijvoorbeeld met een handige grafiek die haar bloedsuikers over de afgelopen periode laat zien</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stelt zelfmetingen van de vitale functies beschikbaar aan het systeem van een zorgaanbieder (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 zelfmetingen van de vitale functies tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De zorgaanbieder wil de zelfmetingen van de vitale functies inzien en de patiënt stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden te sturen, 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) stuurt zelfmetingen van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt en verwerkt de zelfmetingen van de patiënt.
*De zorgaanbieder gebruikt de het XIS om de zelfmetingen van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft zelfmetingen gestuurd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* ZelfmetingenVitaleFunctiesSturend Systeem in FHIR [MM-1.2.2-ZVS-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* ZelfmetingenVitaleFunctiesOntvangend Systeem in FHIR [MM-1.2.2-ZVO-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_sturen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Zelfmetingen Vitale Functies(PUSH)
|style="background-color: white;vertical-align:top;"|Sturen zelfmetingen van vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVS-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;"|Ontvangen zelfmetingen vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVO-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_-_MVF_sturen.jpg|Use case diagram sturen zelfmetingen vitale functies]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=
==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:1500px; text-align:left;"|Omschrijving
|-
| rowspan = 6; style="background-color: white;"| 2019.01
| style="background-color: white;"| 1.2.1
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-185 MM-185]
| style="background-color: white;"| Verkeerde fixed value voor Observation.code.coding:postBreakfastGlucoseNhgtable45.code
|-
| rowspan = 5; style="background-color: white;"| 1.2.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-175 MM-175]
| style="background-color: white;"| Mapping concept Positie van Zib Lichaamslengte niet duidelijk.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-314 MM-314]
| style="background-color: white;"| Zelfmeting pijnscore FHIR.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-147 MM-147]
| style="background-color: white;"| Mappen PulseRegularity binnen PulseRate.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-141 MM-141]
| style="background-color: white;"| Vital Signs profielen inconsistent m.b.t. baseDefinition.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-95 MM-95]
| style="background-color: white;"| Added support for the lastn operation for retrieving the latest available measurement.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-87 MM-87]
| style="background-color: white;"| The links in the table for FHIR profiles have been updated. The BloodGlucose profile in the Retrieve Vital Signs use case and all profiles under the Send Vital Signs use case linked to a deprecated version.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-80 MM-80]
| style="background-color: white;"| The profile mapping for HCIM element NL-CM:12.6.2 TemperatuurType has been updated Observation.method from Observation.bodySite based on feedback received from the ZIB Centrum that even though the definition appears to point to a body site, that the focus of TemperatureType is a method that includes body site. The profile version was updated to 2.0.1
|-
| 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.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 21-06-2019
| style="background-color: white;"|
* Verduidelijking FO m.b.t. glucose meting.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 28-03-2019
| style="background-color: white;"|
* Plaatsen release notes behorende bij patch 1.
* Versienummer systeemrolcodes ophogen met 1 patch nummer.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| Pijnscore verwijderd uit lijst van toegepaste Zibs voor deze use case. Voor Pijnscore is nog geen FHIR documentatie beschikbaar.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing versienummer naar 1.1.0.
* Wijzigingen doorgevoerd betreffende BITS issue MM-80 en MM-87.
* Kwalificatieparagraaf aangevuld.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:Vprepub-2019.01 OntwerpZelfmetingen

2019-06-21T09:05:59Z

Tim Ruijters: /* Algemeen */

{{#customtitle:Functioneel Ontwerp Zelfmetingen 1.2.2 }}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Self-Measuements_zonder_tekst.png |link=|links |85px|Zelfmetingen]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_VitalSigns|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot zelfmetingen van vitale functies die een patiënt kan verzamelen en delen door middel van een PGO. De vitale functies van de mens zijn de lichaamsfuncties die de persoon vitaal of ook wel in leven houden, voorbeelden zijn ademhaling en circulatie (hartslag en bloeddruk).

Momenteel bestaat er geen standaard voor zelfmeet gegevens van de vitale functies. Het doel van deze pagina is om verschillende uitwisseling scenario's van zelfmeet gegevens met de patiënt te beschrijven voor gebruik in MedMij.

Zoals [[MedMij:V2019.01_Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij zorginformatiebouwstenen (ZIB's) als leidraad voor de inhoud van informatie uitwisseling. Voor uitwisseling van zelfmeet gegevens gaat het om de volgende ZIB's:

*Patiënt
*Ademhaling
*Bloeddruk
*Glucose (gebaseerd op zib LaboratoriumUitslag)
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}
===Specifieke informatie over deze kwalificatie===

De kwalificatie richt zich vooralsnog op: bloeddruk, lichaamsgewicht en glucose. Deze dienen minimaal te worden ondersteund. De verwachting is dat leveranciers zoveel mogelijk zelfmetingen ondersteunen.

=Use Cases=
==Use case: Raadplegen metingen betreffende de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de vitale functie meetwaarden die over henzelf gaan.
===Domein===
Metingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de meetwaarden van vitale functies 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 die van toepassing zijn.

====Raadplegen meetwaarden ====
Informatie elementen in de vraag om meetwaarden van vitale functies.

* Patient identificatienummer
* Periode (startdatum - einddatum)
* Type (soort meetwaarden, bijvoorbeeld bloeddruk)

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om meetwaarden van de vitale functies.

====Beschikbaarstellen meetwaarden meetwaarden====
Informatie elementen in meetwaarden van vitale functies staan hieronder. Het betreffen de Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Glucose (gebaseerd op zib LaboratoriumUitslag)
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

PGO-leveranciers dienen de beschikbare zib's en/of FHIR profielen te gebruiken. Als er geen specifieke zib en/of FHIR profiel beschikbaar is, gebruik dan zib AlgemeneMeting of LaboratoriumUitslag.

=== 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 meetwaarden van vitale functies raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt meetwaarden van vitale functies beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_raadplegen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram Raadplegen meetwaarden vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier]. Hieronder een voor Thomas relevante situatie waarbij het raadplegen van meetwaarden betreffende de vitale functie een rol speelt.

<blockquote>Voordat Thomas zijn consult bij de internist heeft om de resultaten door te spreken worden er een aantal andere waarden getest. Zijn gewicht en zijn bloeddruk worden opgemeten. De laboratoriumwaarden zijn al bekend voordat de internist ze aan Thomas mee kan delen. Alhoewel Thomas zoals gezegd zo min mogelijk met zijn ziekte bezig wil zijn, vindt hij de jaarlijkse controle heel belangrijk. Hij vindt het dan ook heel erg handig om de resultaten van de onderzoeken een dag van tevoren al in te zien in zijn PGO. Hij kan zich zo goed voorbereiden en zal niet meer verrast zijn over de resultaten als zijn internist deze voorlegt.</blockquote>

===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 meetwaarden betreffende de vitale functie een 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 kan na haar opname haar vitale waarden gemeten in ziekenhuis raadplegen. Zo beschikt zij over deze informatie die ze als referentiewaarden kan gebruiken.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de gevraagde meetwaarden van de vitale functies 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 vitale functie meetwaarden tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de meetwaarden van de vitale functies inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden 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) stuurt meetwaarden van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt meetwaarden van de vitale functies op voor de patiënt.
*De zorgverlener gebruikt zijn systeem om de meetwaarden van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft de meetwaarden vitale functies geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* MeetwaardenVitaleFunctiesRaadplegend Systeem in FHIR [MM-1.2.2-MVR-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* MeetwaardenVitaleFunctiesBeschikbaarstellend Systeem in FHIR [MM-1.2.2-MVB-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_raadplegen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Meetwaarden Vitale Functies(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVR-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:V2019.01_FHIR_VitalSigns|Meetwaarden vitale functies in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVB-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_-_MVF_raadplegen.jpg|Use case diagram raadplegen meetwaarden vitale functies]]

'''Use case diagram

==Use case: Sturen zelfmetingen van de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door het kunnen delen van hun zelfmeet gegevens met de zorgverlener.
===Domein===
Zelfmetingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de zelfmeetwaarden van vitale functies vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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
====Sturen zelfmetingen====
Informatie elementen in zelfmetingen betreffende vitale functies staan hieronder. Het betreffen Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

====Ontvangen zelfmetingen====
Het ontvangende systeem stuurt een ontvangstbevestiging van de zelfmetingen.

=== 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 zelfmetingen van vitale functies sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt zelfmetingen van vitale functies
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_sturen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram sturen zelfmetingen vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 sturen van zelfmetingen betreffende de vitale functie een rol speelt.

<blockquote>Sinds een aantal maanden maakt Roos gebruik van een online persoonlijke gezondheidsomgeving. Daarin houdt ze onder andere haar bloedglucosewaarden bij. Daarnaast moet ze zich dagelijks wegen in verband met haar hartfalen. Bij hartfalen is de pompfunctie van het hart verminderd. Het hart pompt niet genoeg bloed rond, hierdoor kun je vocht vasthouden. Om dit te monitoren weegt Roos zich dagelijks, en houdt ze haar gewicht bij in haar persoonlijke gezondheidsomgeving. Wanneer haar gewicht toeneemt, dan krijgt ze een signaal vanuit haar PGO, omdat dit zou kunnen duiden op het vasthouden van vocht. Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke gezondheidsomgeving terug. De huisarts kan op zijn beurt de gegevens die Roos heeft ingevoerd bekijken, bijvoorbeeld met een handige grafiek die haar bloedsuikers over de afgelopen periode laat zien</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stelt zelfmetingen van de vitale functies beschikbaar aan het systeem van een zorgaanbieder (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 zelfmetingen van de vitale functies tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De zorgaanbieder wil de zelfmetingen van de vitale functies inzien en de patiënt stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden te sturen, 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) stuurt zelfmetingen van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt en verwerkt de zelfmetingen van de patiënt.
*De zorgaanbieder gebruikt de het XIS om de zelfmetingen van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft zelfmetingen gestuurd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* ZelfmetingenVitaleFunctiesSturend Systeem in FHIR [MM-1.2.2-ZVS-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* ZelfmetingenVitaleFunctiesOntvangend Systeem in FHIR [MM-1.2.2-ZVO-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_sturen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Zelfmetingen Vitale Functies(PUSH)
|style="background-color: white;vertical-align:top;"|Sturen zelfmetingen van vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVS-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;"|Ontvangen zelfmetingen vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVO-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_-_MVF_sturen.jpg|Use case diagram sturen zelfmetingen vitale functies]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=
==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:1500px; text-align:left;"|Omschrijving
|-
| rowspan = 6; style="background-color: white;"| 2019.01
| style="background-color: white;"| 1.2.1
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-185 MM-185]
| style="background-color: white;"| Verkeerde fixed value voor Observation.code.coding:postBreakfastGlucoseNhgtable45.code
|-
| rowspan = 5; style="background-color: white;"| 1.2.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-175 MM-175]
| style="background-color: white;"| Mapping concept Positie van Zib Lichaamslengte niet duidelijk.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-314 MM-314]
| style="background-color: white;"| Zelfmeting pijnscore FHIR.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-147 MM-147]
| style="background-color: white;"| Mappen PulseRegularity binnen PulseRate.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-141 MM-141]
| style="background-color: white;"| Vital Signs profielen inconsistent m.b.t. baseDefinition.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-95 MM-95]
| style="background-color: white;"| Added support for the lastn operation for retrieving the latest available measurement.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-87 MM-87]
| style="background-color: white;"| The links in the table for FHIR profiles have been updated. The BloodGlucose profile in the Retrieve Vital Signs use case and all profiles under the Send Vital Signs use case linked to a deprecated version.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-80 MM-80]
| style="background-color: white;"| The profile mapping for HCIM element NL-CM:12.6.2 TemperatuurType has been updated Observation.method from Observation.bodySite based on feedback received from the ZIB Centrum that even though the definition appears to point to a body site, that the focus of TemperatureType is a method that includes body site. The profile version was updated to 2.0.1
|-
| 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.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 21-06-2019
| style="background-color: white;"|
* Verduidelijking FO m.b.t. glucose meting.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 28-03-2019
| style="background-color: white;"|
* Plaatsen release notes behorende bij patch 1.
* Versienummer systeemrolcodes ophogen met 1 patch nummer.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| Pijnscore verwijderd uit lijst van toegepaste Zibs voor deze use case. Voor Pijnscore is nog geen FHIR documentatie beschikbaar.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing versienummer naar 1.1.0.
* Wijzigingen doorgevoerd betreffende BITS issue MM-80 en MM-87.
* Kwalificatieparagraaf aangevuld.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:V2019.01 OntwerpZelfmetingen

2019-06-21T09:03:04Z

Tim Ruijters: Verduidelijking FO m.b.t. glucose meting.

{{#customtitle:Functioneel Ontwerp Zelfmetingen 1.2.2 }}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Self-Measuements_zonder_tekst.png |link=|links |85px|Zelfmetingen]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_VitalSigns|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot zelfmetingen van vitale functies die een patiënt kan verzamelen en delen door middel van een PGO. De vitale functies van de mens zijn de lichaamsfuncties die de persoon vitaal of ook wel in leven houden, voorbeelden zijn ademhaling en circulatie (hartslag en bloeddruk).

Momenteel bestaat er geen standaard voor zelfmeet gegevens van de vitale functies. Het doel van deze pagina is om verschillende uitwisseling scenario's van zelfmeet gegevens met de patiënt te beschrijven voor gebruik in MedMij.

Zoals [[MedMij:V2019.01_Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij zorginformatiebouwstenen (ZIB's) als leidraad voor de inhoud van informatie uitwisseling. Voor uitwisseling van zelfmeet gegevens gaat het om de volgende ZIB's:

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}
===Specifieke informatie over deze kwalificatie===

De kwalificatie richt zich vooralsnog op: bloeddruk, lichaamsgewicht en glucose. Deze dienen minimaal te worden ondersteund. De verwachting is dat leveranciers zoveel mogelijk zelfmetingen ondersteunen.

=Use Cases=
==Use case: Raadplegen metingen betreffende de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de vitale functie meetwaarden die over henzelf gaan.
===Domein===
Metingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de meetwaarden van vitale functies 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 die van toepassing zijn.

====Raadplegen meetwaarden ====
Informatie elementen in de vraag om meetwaarden van vitale functies.

* Patient identificatienummer
* Periode (startdatum - einddatum)
* Type (soort meetwaarden, bijvoorbeeld bloeddruk)

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om meetwaarden van de vitale functies.

====Beschikbaarstellen meetwaarden meetwaarden====
Informatie elementen in meetwaarden van vitale functies staan hieronder. Het betreffen de Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Glucose (gebaseerd op zib LaboratoriumUitslag)
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

PGO-leveranciers dienen de beschikbare zib's en/of FHIR profielen te gebruiken. Als er geen specifieke zib en/of FHIR profiel beschikbaar is, gebruik dan zib AlgemeneMeting of LaboratoriumUitslag.

=== 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 meetwaarden van vitale functies raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt meetwaarden van vitale functies beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_raadplegen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram Raadplegen meetwaarden vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier]. Hieronder een voor Thomas relevante situatie waarbij het raadplegen van meetwaarden betreffende de vitale functie een rol speelt.

<blockquote>Voordat Thomas zijn consult bij de internist heeft om de resultaten door te spreken worden er een aantal andere waarden getest. Zijn gewicht en zijn bloeddruk worden opgemeten. De laboratoriumwaarden zijn al bekend voordat de internist ze aan Thomas mee kan delen. Alhoewel Thomas zoals gezegd zo min mogelijk met zijn ziekte bezig wil zijn, vindt hij de jaarlijkse controle heel belangrijk. Hij vindt het dan ook heel erg handig om de resultaten van de onderzoeken een dag van tevoren al in te zien in zijn PGO. Hij kan zich zo goed voorbereiden en zal niet meer verrast zijn over de resultaten als zijn internist deze voorlegt.</blockquote>

===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 meetwaarden betreffende de vitale functie een 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 kan na haar opname haar vitale waarden gemeten in ziekenhuis raadplegen. Zo beschikt zij over deze informatie die ze als referentiewaarden kan gebruiken.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de gevraagde meetwaarden van de vitale functies 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 vitale functie meetwaarden tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de meetwaarden van de vitale functies inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden 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) stuurt meetwaarden van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt meetwaarden van de vitale functies op voor de patiënt.
*De zorgverlener gebruikt zijn systeem om de meetwaarden van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft de meetwaarden vitale functies geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* MeetwaardenVitaleFunctiesRaadplegend Systeem in FHIR [MM-1.2.2-MVR-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* MeetwaardenVitaleFunctiesBeschikbaarstellend Systeem in FHIR [MM-1.2.2-MVB-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_raadplegen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Meetwaarden Vitale Functies(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVR-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:V2019.01_FHIR_VitalSigns|Meetwaarden vitale functies in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVB-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_-_MVF_raadplegen.jpg|Use case diagram raadplegen meetwaarden vitale functies]]

'''Use case diagram

==Use case: Sturen zelfmetingen van de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door het kunnen delen van hun zelfmeet gegevens met de zorgverlener.
===Domein===
Zelfmetingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de zelfmeetwaarden van vitale functies vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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
====Sturen zelfmetingen====
Informatie elementen in zelfmetingen betreffende vitale functies staan hieronder. Het betreffen Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

====Ontvangen zelfmetingen====
Het ontvangende systeem stuurt een ontvangstbevestiging van de zelfmetingen.

=== 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 zelfmetingen van vitale functies sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt zelfmetingen van vitale functies
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_sturen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram sturen zelfmetingen vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 sturen van zelfmetingen betreffende de vitale functie een rol speelt.

<blockquote>Sinds een aantal maanden maakt Roos gebruik van een online persoonlijke gezondheidsomgeving. Daarin houdt ze onder andere haar bloedglucosewaarden bij. Daarnaast moet ze zich dagelijks wegen in verband met haar hartfalen. Bij hartfalen is de pompfunctie van het hart verminderd. Het hart pompt niet genoeg bloed rond, hierdoor kun je vocht vasthouden. Om dit te monitoren weegt Roos zich dagelijks, en houdt ze haar gewicht bij in haar persoonlijke gezondheidsomgeving. Wanneer haar gewicht toeneemt, dan krijgt ze een signaal vanuit haar PGO, omdat dit zou kunnen duiden op het vasthouden van vocht. Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke gezondheidsomgeving terug. De huisarts kan op zijn beurt de gegevens die Roos heeft ingevoerd bekijken, bijvoorbeeld met een handige grafiek die haar bloedsuikers over de afgelopen periode laat zien</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stelt zelfmetingen van de vitale functies beschikbaar aan het systeem van een zorgaanbieder (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 zelfmetingen van de vitale functies tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De zorgaanbieder wil de zelfmetingen van de vitale functies inzien en de patiënt stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden te sturen, 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) stuurt zelfmetingen van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt en verwerkt de zelfmetingen van de patiënt.
*De zorgaanbieder gebruikt de het XIS om de zelfmetingen van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft zelfmetingen gestuurd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* ZelfmetingenVitaleFunctiesSturend Systeem in FHIR [MM-1.2.2-ZVS-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* ZelfmetingenVitaleFunctiesOntvangend Systeem in FHIR [MM-1.2.2-ZVO-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_sturen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Zelfmetingen Vitale Functies(PUSH)
|style="background-color: white;vertical-align:top;"|Sturen zelfmetingen van vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVS-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;"|Ontvangen zelfmetingen vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVO-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_-_MVF_sturen.jpg|Use case diagram sturen zelfmetingen vitale functies]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=
==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:1500px; text-align:left;"|Omschrijving
|-
| rowspan = 6; style="background-color: white;"| 2019.01
| style="background-color: white;"| 1.2.1
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-185 MM-185]
| style="background-color: white;"| Verkeerde fixed value voor Observation.code.coding:postBreakfastGlucoseNhgtable45.code
|-
| rowspan = 5; style="background-color: white;"| 1.2.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-175 MM-175]
| style="background-color: white;"| Mapping concept Positie van Zib Lichaamslengte niet duidelijk.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-314 MM-314]
| style="background-color: white;"| Zelfmeting pijnscore FHIR.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-147 MM-147]
| style="background-color: white;"| Mappen PulseRegularity binnen PulseRate.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-141 MM-141]
| style="background-color: white;"| Vital Signs profielen inconsistent m.b.t. baseDefinition.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-95 MM-95]
| style="background-color: white;"| Added support for the lastn operation for retrieving the latest available measurement.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-87 MM-87]
| style="background-color: white;"| The links in the table for FHIR profiles have been updated. The BloodGlucose profile in the Retrieve Vital Signs use case and all profiles under the Send Vital Signs use case linked to a deprecated version.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-80 MM-80]
| style="background-color: white;"| The profile mapping for HCIM element NL-CM:12.6.2 TemperatuurType has been updated Observation.method from Observation.bodySite based on feedback received from the ZIB Centrum that even though the definition appears to point to a body site, that the focus of TemperatureType is a method that includes body site. The profile version was updated to 2.0.1
|-
| 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.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 21-06-2019
| style="background-color: white;"|
* Verduidelijking FO m.b.t. glucose meting.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 28-03-2019
| style="background-color: white;"|
* Plaatsen release notes behorende bij patch 1.
* Versienummer systeemrolcodes ophogen met 1 patch nummer.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| Pijnscore verwijderd uit lijst van toegepaste Zibs voor deze use case. Voor Pijnscore is nog geen FHIR documentatie beschikbaar.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing versienummer naar 1.1.0.
* Wijzigingen doorgevoerd betreffende BITS issue MM-80 en MM-87.
* Kwalificatieparagraaf aangevuld.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:Vprepub-2019.01 OntwerpZelfmetingen

2019-06-21T09:03:04Z

Tim Ruijters: Verduidelijking FO m.b.t. glucose meting.

{{#customtitle:Functioneel Ontwerp Zelfmetingen 1.2.2 }}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Self-Measuements_zonder_tekst.png |link=|links |85px|Zelfmetingen]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_VitalSigns|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot zelfmetingen van vitale functies die een patiënt kan verzamelen en delen door middel van een PGO. De vitale functies van de mens zijn de lichaamsfuncties die de persoon vitaal of ook wel in leven houden, voorbeelden zijn ademhaling en circulatie (hartslag en bloeddruk).

Momenteel bestaat er geen standaard voor zelfmeet gegevens van de vitale functies. Het doel van deze pagina is om verschillende uitwisseling scenario's van zelfmeet gegevens met de patiënt te beschrijven voor gebruik in MedMij.

Zoals [[MedMij:V2019.01_Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij zorginformatiebouwstenen (ZIB's) als leidraad voor de inhoud van informatie uitwisseling. Voor uitwisseling van zelfmeet gegevens gaat het om de volgende ZIB's:

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}
===Specifieke informatie over deze kwalificatie===

De kwalificatie richt zich vooralsnog op: bloeddruk, lichaamsgewicht en glucose. Deze dienen minimaal te worden ondersteund. De verwachting is dat leveranciers zoveel mogelijk zelfmetingen ondersteunen.

=Use Cases=
==Use case: Raadplegen metingen betreffende de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de vitale functie meetwaarden die over henzelf gaan.
===Domein===
Metingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de meetwaarden van vitale functies 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 die van toepassing zijn.

====Raadplegen meetwaarden ====
Informatie elementen in de vraag om meetwaarden van vitale functies.

* Patient identificatienummer
* Periode (startdatum - einddatum)
* Type (soort meetwaarden, bijvoorbeeld bloeddruk)

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om meetwaarden van de vitale functies.

====Beschikbaarstellen meetwaarden meetwaarden====
Informatie elementen in meetwaarden van vitale functies staan hieronder. Het betreffen de Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Glucose (gebaseerd op zib LaboratoriumUitslag)
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

PGO-leveranciers dienen de beschikbare zib's en/of FHIR profielen te gebruiken. Als er geen specifieke zib en/of FHIR profiel beschikbaar is, gebruik dan zib AlgemeneMeting of LaboratoriumUitslag.

=== 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 meetwaarden van vitale functies raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt meetwaarden van vitale functies beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_raadplegen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram Raadplegen meetwaarden vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier]. Hieronder een voor Thomas relevante situatie waarbij het raadplegen van meetwaarden betreffende de vitale functie een rol speelt.

<blockquote>Voordat Thomas zijn consult bij de internist heeft om de resultaten door te spreken worden er een aantal andere waarden getest. Zijn gewicht en zijn bloeddruk worden opgemeten. De laboratoriumwaarden zijn al bekend voordat de internist ze aan Thomas mee kan delen. Alhoewel Thomas zoals gezegd zo min mogelijk met zijn ziekte bezig wil zijn, vindt hij de jaarlijkse controle heel belangrijk. Hij vindt het dan ook heel erg handig om de resultaten van de onderzoeken een dag van tevoren al in te zien in zijn PGO. Hij kan zich zo goed voorbereiden en zal niet meer verrast zijn over de resultaten als zijn internist deze voorlegt.</blockquote>

===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 meetwaarden betreffende de vitale functie een 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 kan na haar opname haar vitale waarden gemeten in ziekenhuis raadplegen. Zo beschikt zij over deze informatie die ze als referentiewaarden kan gebruiken.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de gevraagde meetwaarden van de vitale functies 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 vitale functie meetwaarden tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de meetwaarden van de vitale functies inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden 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) stuurt meetwaarden van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt meetwaarden van de vitale functies op voor de patiënt.
*De zorgverlener gebruikt zijn systeem om de meetwaarden van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft de meetwaarden vitale functies geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* MeetwaardenVitaleFunctiesRaadplegend Systeem in FHIR [MM-1.2.2-MVR-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* MeetwaardenVitaleFunctiesBeschikbaarstellend Systeem in FHIR [MM-1.2.2-MVB-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_raadplegen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Meetwaarden Vitale Functies(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVR-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:V2019.01_FHIR_VitalSigns|Meetwaarden vitale functies in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVB-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_-_MVF_raadplegen.jpg|Use case diagram raadplegen meetwaarden vitale functies]]

'''Use case diagram

==Use case: Sturen zelfmetingen van de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door het kunnen delen van hun zelfmeet gegevens met de zorgverlener.
===Domein===
Zelfmetingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de zelfmeetwaarden van vitale functies vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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
====Sturen zelfmetingen====
Informatie elementen in zelfmetingen betreffende vitale functies staan hieronder. Het betreffen Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

====Ontvangen zelfmetingen====
Het ontvangende systeem stuurt een ontvangstbevestiging van de zelfmetingen.

=== 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 zelfmetingen van vitale functies sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt zelfmetingen van vitale functies
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_sturen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram sturen zelfmetingen vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 sturen van zelfmetingen betreffende de vitale functie een rol speelt.

<blockquote>Sinds een aantal maanden maakt Roos gebruik van een online persoonlijke gezondheidsomgeving. Daarin houdt ze onder andere haar bloedglucosewaarden bij. Daarnaast moet ze zich dagelijks wegen in verband met haar hartfalen. Bij hartfalen is de pompfunctie van het hart verminderd. Het hart pompt niet genoeg bloed rond, hierdoor kun je vocht vasthouden. Om dit te monitoren weegt Roos zich dagelijks, en houdt ze haar gewicht bij in haar persoonlijke gezondheidsomgeving. Wanneer haar gewicht toeneemt, dan krijgt ze een signaal vanuit haar PGO, omdat dit zou kunnen duiden op het vasthouden van vocht. Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke gezondheidsomgeving terug. De huisarts kan op zijn beurt de gegevens die Roos heeft ingevoerd bekijken, bijvoorbeeld met een handige grafiek die haar bloedsuikers over de afgelopen periode laat zien</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stelt zelfmetingen van de vitale functies beschikbaar aan het systeem van een zorgaanbieder (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 zelfmetingen van de vitale functies tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De zorgaanbieder wil de zelfmetingen van de vitale functies inzien en de patiënt stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden te sturen, 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) stuurt zelfmetingen van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt en verwerkt de zelfmetingen van de patiënt.
*De zorgaanbieder gebruikt de het XIS om de zelfmetingen van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft zelfmetingen gestuurd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* ZelfmetingenVitaleFunctiesSturend Systeem in FHIR [MM-1.2.2-ZVS-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* ZelfmetingenVitaleFunctiesOntvangend Systeem in FHIR [MM-1.2.2-ZVO-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_sturen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Zelfmetingen Vitale Functies(PUSH)
|style="background-color: white;vertical-align:top;"|Sturen zelfmetingen van vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVS-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;"|Ontvangen zelfmetingen vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVO-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_-_MVF_sturen.jpg|Use case diagram sturen zelfmetingen vitale functies]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=
==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:1500px; text-align:left;"|Omschrijving
|-
| rowspan = 6; style="background-color: white;"| 2019.01
| style="background-color: white;"| 1.2.1
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-185 MM-185]
| style="background-color: white;"| Verkeerde fixed value voor Observation.code.coding:postBreakfastGlucoseNhgtable45.code
|-
| rowspan = 5; style="background-color: white;"| 1.2.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-175 MM-175]
| style="background-color: white;"| Mapping concept Positie van Zib Lichaamslengte niet duidelijk.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-314 MM-314]
| style="background-color: white;"| Zelfmeting pijnscore FHIR.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-147 MM-147]
| style="background-color: white;"| Mappen PulseRegularity binnen PulseRate.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-141 MM-141]
| style="background-color: white;"| Vital Signs profielen inconsistent m.b.t. baseDefinition.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-95 MM-95]
| style="background-color: white;"| Added support for the lastn operation for retrieving the latest available measurement.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-87 MM-87]
| style="background-color: white;"| The links in the table for FHIR profiles have been updated. The BloodGlucose profile in the Retrieve Vital Signs use case and all profiles under the Send Vital Signs use case linked to a deprecated version.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-80 MM-80]
| style="background-color: white;"| The profile mapping for HCIM element NL-CM:12.6.2 TemperatuurType has been updated Observation.method from Observation.bodySite based on feedback received from the ZIB Centrum that even though the definition appears to point to a body site, that the focus of TemperatureType is a method that includes body site. The profile version was updated to 2.0.1
|-
| 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.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 21-06-2019
| style="background-color: white;"|
* Verduidelijking FO m.b.t. glucose meting.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 28-03-2019
| style="background-color: white;"|
* Plaatsen release notes behorende bij patch 1.
* Versienummer systeemrolcodes ophogen met 1 patch nummer.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| Pijnscore verwijderd uit lijst van toegepaste Zibs voor deze use case. Voor Pijnscore is nog geen FHIR documentatie beschikbaar.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing versienummer naar 1.1.0.
* Wijzigingen doorgevoerd betreffende BITS issue MM-80 en MM-87.
* Kwalificatieparagraaf aangevuld.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:V2019.01 OntwerpZelfmetingen

2019-06-21T08:44:46Z

Tim Ruijters: Verduidelijking FO m.b.t. glucosemeting

{{#customtitle:Functioneel Ontwerp Zelfmetingen 1.2.2 }}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Self-Measuements_zonder_tekst.png |link=|links |85px|Zelfmetingen]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_VitalSigns|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot zelfmetingen van vitale functies die een patiënt kan verzamelen en delen door middel van een PGO. De vitale functies van de mens zijn de lichaamsfuncties die de persoon vitaal of ook wel in leven houden, voorbeelden zijn ademhaling en circulatie (hartslag en bloeddruk).

Momenteel bestaat er geen standaard voor zelfmeet gegevens van de vitale functies. Het doel van deze pagina is om verschillende uitwisseling scenario's van zelfmeet gegevens met de patiënt te beschrijven voor gebruik in MedMij.

Zoals [[MedMij:V2019.01_Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij zorginformatiebouwstenen (ZIB's) als leidraad voor de inhoud van informatie uitwisseling. Voor uitwisseling van zelfmeet gegevens gaat het om de volgende ZIB's:

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case: Raadplegen metingen betreffende de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de vitale functie meetwaarden die over henzelf gaan.
===Domein===
Metingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de meetwaarden van vitale functies 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 die van toepassing zijn.

====Raadplegen meetwaarden ====
Informatie elementen in de vraag om meetwaarden van vitale functies.

* Patient identificatienummer
* Periode (startdatum - einddatum)
* Type (soort meetwaarden, bijvoorbeeld bloeddruk)

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om meetwaarden van de vitale functies.

====Beschikbaarstellen meetwaarden meetwaarden====
Informatie elementen in meetwaarden van vitale functies staan hieronder. Het betreffen de Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

=== 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 meetwaarden van vitale functies raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt meetwaarden van vitale functies beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_raadplegen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram Raadplegen meetwaarden vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier]. Hieronder een voor Thomas relevante situatie waarbij het raadplegen van meetwaarden betreffende de vitale functie een rol speelt.

<blockquote>Voordat Thomas zijn consult bij de internist heeft om de resultaten door te spreken worden er een aantal andere waarden getest. Zijn gewicht en zijn bloeddruk worden opgemeten. De laboratoriumwaarden zijn al bekend voordat de internist ze aan Thomas mee kan delen. Alhoewel Thomas zoals gezegd zo min mogelijk met zijn ziekte bezig wil zijn, vindt hij de jaarlijkse controle heel belangrijk. Hij vindt het dan ook heel erg handig om de resultaten van de onderzoeken een dag van tevoren al in te zien in zijn PGO. Hij kan zich zo goed voorbereiden en zal niet meer verrast zijn over de resultaten als zijn internist deze voorlegt.</blockquote>

===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 meetwaarden betreffende de vitale functie een 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 kan na haar opname haar vitale waarden gemeten in ziekenhuis raadplegen. Zo beschikt zij over deze informatie die ze als referentiewaarden kan gebruiken.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de gevraagde meetwaarden van de vitale functies 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 vitale functie meetwaarden tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de meetwaarden van de vitale functies inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden 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) stuurt meetwaarden van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt meetwaarden van de vitale functies op voor de patiënt.
*De zorgverlener gebruikt zijn systeem om de meetwaarden van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft de meetwaarden vitale functies geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* MeetwaardenVitaleFunctiesRaadplegend Systeem in FHIR [MM-1.2.2-MVR-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* MeetwaardenVitaleFunctiesBeschikbaarstellend Systeem in FHIR [MM-1.2.2-MVB-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_raadplegen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Meetwaarden Vitale Functies(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVR-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:V2019.01_FHIR_VitalSigns|Meetwaarden vitale functies in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVB-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_-_MVF_raadplegen.jpg|Use case diagram raadplegen meetwaarden vitale functies]]

'''Use case diagram

==Use case: Sturen zelfmetingen van de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door het kunnen delen van hun zelfmeet gegevens met de zorgverlener.
===Domein===
Zelfmetingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de zelfmeetwaarden van vitale functies vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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
====Sturen zelfmetingen====
Informatie elementen in zelfmetingen betreffende vitale functies staan hieronder. Het betreffen Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

====Ontvangen zelfmetingen====
Het ontvangende systeem stuurt een ontvangstbevestiging van de zelfmetingen.

=== 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 zelfmetingen van vitale functies sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt zelfmetingen van vitale functies
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_sturen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram sturen zelfmetingen vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 sturen van zelfmetingen betreffende de vitale functie een rol speelt.

<blockquote>Sinds een aantal maanden maakt Roos gebruik van een online persoonlijke gezondheidsomgeving. Daarin houdt ze onder andere haar bloedglucosewaarden bij. Daarnaast moet ze zich dagelijks wegen in verband met haar hartfalen. Bij hartfalen is de pompfunctie van het hart verminderd. Het hart pompt niet genoeg bloed rond, hierdoor kun je vocht vasthouden. Om dit te monitoren weegt Roos zich dagelijks, en houdt ze haar gewicht bij in haar persoonlijke gezondheidsomgeving. Wanneer haar gewicht toeneemt, dan krijgt ze een signaal vanuit haar PGO, omdat dit zou kunnen duiden op het vasthouden van vocht. Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke gezondheidsomgeving terug. De huisarts kan op zijn beurt de gegevens die Roos heeft ingevoerd bekijken, bijvoorbeeld met een handige grafiek die haar bloedsuikers over de afgelopen periode laat zien</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stelt zelfmetingen van de vitale functies beschikbaar aan het systeem van een zorgaanbieder (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 zelfmetingen van de vitale functies tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De zorgaanbieder wil de zelfmetingen van de vitale functies inzien en de patiënt stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden te sturen, 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) stuurt zelfmetingen van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt en verwerkt de zelfmetingen van de patiënt.
*De zorgaanbieder gebruikt de het XIS om de zelfmetingen van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft zelfmetingen gestuurd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* ZelfmetingenVitaleFunctiesSturend Systeem in FHIR [MM-1.2.2-ZVS-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* ZelfmetingenVitaleFunctiesOntvangend Systeem in FHIR [MM-1.2.2-ZVO-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_sturen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Zelfmetingen Vitale Functies(PUSH)
|style="background-color: white;vertical-align:top;"|Sturen zelfmetingen van vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVS-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;"|Ontvangen zelfmetingen vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVO-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_-_MVF_sturen.jpg|Use case diagram sturen zelfmetingen vitale functies]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=
==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:1500px; text-align:left;"|Omschrijving
|-
| rowspan = 6; style="background-color: white;"| 2019.01
| style="background-color: white;"| 1.2.1
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-185 MM-185]
| style="background-color: white;"| Verkeerde fixed value voor Observation.code.coding:postBreakfastGlucoseNhgtable45.code
|-
| rowspan = 5; style="background-color: white;"| 1.2.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-175 MM-175]
| style="background-color: white;"| Mapping concept Positie van Zib Lichaamslengte niet duidelijk.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-314 MM-314]
| style="background-color: white;"| Zelfmeting pijnscore FHIR.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-147 MM-147]
| style="background-color: white;"| Mappen PulseRegularity binnen PulseRate.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-141 MM-141]
| style="background-color: white;"| Vital Signs profielen inconsistent m.b.t. baseDefinition.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-95 MM-95]
| style="background-color: white;"| Added support for the lastn operation for retrieving the latest available measurement.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-87 MM-87]
| style="background-color: white;"| The links in the table for FHIR profiles have been updated. The BloodGlucose profile in the Retrieve Vital Signs use case and all profiles under the Send Vital Signs use case linked to a deprecated version.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-80 MM-80]
| style="background-color: white;"| The profile mapping for HCIM element NL-CM:12.6.2 TemperatuurType has been updated Observation.method from Observation.bodySite based on feedback received from the ZIB Centrum that even though the definition appears to point to a body site, that the focus of TemperatureType is a method that includes body site. The profile version was updated to 2.0.1
|-
| 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.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 21-06-2019
| style="background-color: white;"|
* Verduidelijking FO m.b.t. glucose meting.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 28-03-2019
| style="background-color: white;"|
* Plaatsen release notes behorende bij patch 1.
* Versienummer systeemrolcodes ophogen met 1 patch nummer.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| Pijnscore verwijderd uit lijst van toegepaste Zibs voor deze use case. Voor Pijnscore is nog geen FHIR documentatie beschikbaar.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing versienummer naar 1.1.0.
* Wijzigingen doorgevoerd betreffende BITS issue MM-80 en MM-87.
* Kwalificatieparagraaf aangevuld.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:Vprepub-2019.01 OntwerpZelfmetingen

2019-06-21T08:44:46Z

Tim Ruijters: Verduidelijking FO m.b.t. glucosemeting

{{#customtitle:Functioneel Ontwerp Zelfmetingen 1.2.2 }}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Self-Measuements_zonder_tekst.png |link=|links |85px|Zelfmetingen]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_VitalSigns|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot zelfmetingen van vitale functies die een patiënt kan verzamelen en delen door middel van een PGO. De vitale functies van de mens zijn de lichaamsfuncties die de persoon vitaal of ook wel in leven houden, voorbeelden zijn ademhaling en circulatie (hartslag en bloeddruk).

Momenteel bestaat er geen standaard voor zelfmeet gegevens van de vitale functies. Het doel van deze pagina is om verschillende uitwisseling scenario's van zelfmeet gegevens met de patiënt te beschrijven voor gebruik in MedMij.

Zoals [[MedMij:V2019.01_Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij zorginformatiebouwstenen (ZIB's) als leidraad voor de inhoud van informatie uitwisseling. Voor uitwisseling van zelfmeet gegevens gaat het om de volgende ZIB's:

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case: Raadplegen metingen betreffende de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de vitale functie meetwaarden die over henzelf gaan.
===Domein===
Metingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de meetwaarden van vitale functies 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 die van toepassing zijn.

====Raadplegen meetwaarden ====
Informatie elementen in de vraag om meetwaarden van vitale functies.

* Patient identificatienummer
* Periode (startdatum - einddatum)
* Type (soort meetwaarden, bijvoorbeeld bloeddruk)

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om meetwaarden van de vitale functies.

====Beschikbaarstellen meetwaarden meetwaarden====
Informatie elementen in meetwaarden van vitale functies staan hieronder. Het betreffen de Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

=== 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 meetwaarden van vitale functies raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt meetwaarden van vitale functies beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_raadplegen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram Raadplegen meetwaarden vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier]. Hieronder een voor Thomas relevante situatie waarbij het raadplegen van meetwaarden betreffende de vitale functie een rol speelt.

<blockquote>Voordat Thomas zijn consult bij de internist heeft om de resultaten door te spreken worden er een aantal andere waarden getest. Zijn gewicht en zijn bloeddruk worden opgemeten. De laboratoriumwaarden zijn al bekend voordat de internist ze aan Thomas mee kan delen. Alhoewel Thomas zoals gezegd zo min mogelijk met zijn ziekte bezig wil zijn, vindt hij de jaarlijkse controle heel belangrijk. Hij vindt het dan ook heel erg handig om de resultaten van de onderzoeken een dag van tevoren al in te zien in zijn PGO. Hij kan zich zo goed voorbereiden en zal niet meer verrast zijn over de resultaten als zijn internist deze voorlegt.</blockquote>

===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 meetwaarden betreffende de vitale functie een 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 kan na haar opname haar vitale waarden gemeten in ziekenhuis raadplegen. Zo beschikt zij over deze informatie die ze als referentiewaarden kan gebruiken.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de gevraagde meetwaarden van de vitale functies 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 vitale functie meetwaarden tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de meetwaarden van de vitale functies inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden 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) stuurt meetwaarden van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt meetwaarden van de vitale functies op voor de patiënt.
*De zorgverlener gebruikt zijn systeem om de meetwaarden van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft de meetwaarden vitale functies geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* MeetwaardenVitaleFunctiesRaadplegend Systeem in FHIR [MM-1.2.2-MVR-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* MeetwaardenVitaleFunctiesBeschikbaarstellend Systeem in FHIR [MM-1.2.2-MVB-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_raadplegen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Meetwaarden Vitale Functies(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVR-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:V2019.01_FHIR_VitalSigns|Meetwaarden vitale functies in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-MVB-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_-_MVF_raadplegen.jpg|Use case diagram raadplegen meetwaarden vitale functies]]

'''Use case diagram

==Use case: Sturen zelfmetingen van de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door het kunnen delen van hun zelfmeet gegevens met de zorgverlener.
===Domein===
Zelfmetingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de zelfmeetwaarden van vitale functies vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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
====Sturen zelfmetingen====
Informatie elementen in zelfmetingen betreffende vitale functies staan hieronder. Het betreffen Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

====Ontvangen zelfmetingen====
Het ontvangende systeem stuurt een ontvangstbevestiging van de zelfmetingen.

=== 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 zelfmetingen van vitale functies sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt zelfmetingen van vitale functies
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_sturen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram sturen zelfmetingen vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 sturen van zelfmetingen betreffende de vitale functie een rol speelt.

<blockquote>Sinds een aantal maanden maakt Roos gebruik van een online persoonlijke gezondheidsomgeving. Daarin houdt ze onder andere haar bloedglucosewaarden bij. Daarnaast moet ze zich dagelijks wegen in verband met haar hartfalen. Bij hartfalen is de pompfunctie van het hart verminderd. Het hart pompt niet genoeg bloed rond, hierdoor kun je vocht vasthouden. Om dit te monitoren weegt Roos zich dagelijks, en houdt ze haar gewicht bij in haar persoonlijke gezondheidsomgeving. Wanneer haar gewicht toeneemt, dan krijgt ze een signaal vanuit haar PGO, omdat dit zou kunnen duiden op het vasthouden van vocht. Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke gezondheidsomgeving terug. De huisarts kan op zijn beurt de gegevens die Roos heeft ingevoerd bekijken, bijvoorbeeld met een handige grafiek die haar bloedsuikers over de afgelopen periode laat zien</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stelt zelfmetingen van de vitale functies beschikbaar aan het systeem van een zorgaanbieder (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 zelfmetingen van de vitale functies tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De zorgaanbieder wil de zelfmetingen van de vitale functies inzien en de patiënt stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden te sturen, 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) stuurt zelfmetingen van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt en verwerkt de zelfmetingen van de patiënt.
*De zorgaanbieder gebruikt de het XIS om de zelfmetingen van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft zelfmetingen gestuurd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* ZelfmetingenVitaleFunctiesSturend Systeem in FHIR [MM-1.2.2-ZVS-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* ZelfmetingenVitaleFunctiesOntvangend Systeem in FHIR [MM-1.2.2-ZVO-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_sturen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Zelfmetingen Vitale Functies(PUSH)
|style="background-color: white;vertical-align:top;"|Sturen zelfmetingen van vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVS-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;"|Ontvangen zelfmetingen vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.2-ZVO-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_-_MVF_sturen.jpg|Use case diagram sturen zelfmetingen vitale functies]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=
==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:1500px; text-align:left;"|Omschrijving
|-
| rowspan = 6; style="background-color: white;"| 2019.01
| style="background-color: white;"| 1.2.1
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-185 MM-185]
| style="background-color: white;"| Verkeerde fixed value voor Observation.code.coding:postBreakfastGlucoseNhgtable45.code
|-
| rowspan = 5; style="background-color: white;"| 1.2.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-175 MM-175]
| style="background-color: white;"| Mapping concept Positie van Zib Lichaamslengte niet duidelijk.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-314 MM-314]
| style="background-color: white;"| Zelfmeting pijnscore FHIR.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-147 MM-147]
| style="background-color: white;"| Mappen PulseRegularity binnen PulseRate.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-141 MM-141]
| style="background-color: white;"| Vital Signs profielen inconsistent m.b.t. baseDefinition.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-95 MM-95]
| style="background-color: white;"| Added support for the lastn operation for retrieving the latest available measurement.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-87 MM-87]
| style="background-color: white;"| The links in the table for FHIR profiles have been updated. The BloodGlucose profile in the Retrieve Vital Signs use case and all profiles under the Send Vital Signs use case linked to a deprecated version.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-80 MM-80]
| style="background-color: white;"| The profile mapping for HCIM element NL-CM:12.6.2 TemperatuurType has been updated Observation.method from Observation.bodySite based on feedback received from the ZIB Centrum that even though the definition appears to point to a body site, that the focus of TemperatureType is a method that includes body site. The profile version was updated to 2.0.1
|-
| 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.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 21-06-2019
| style="background-color: white;"|
* Verduidelijking FO m.b.t. glucose meting.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 28-03-2019
| style="background-color: white;"|
* Plaatsen release notes behorende bij patch 1.
* Versienummer systeemrolcodes ophogen met 1 patch nummer.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| Pijnscore verwijderd uit lijst van toegepaste Zibs voor deze use case. Voor Pijnscore is nog geen FHIR documentatie beschikbaar.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing versienummer naar 1.1.0.
* Wijzigingen doorgevoerd betreffende BITS issue MM-80 en MM-87.
* Kwalificatieparagraaf aangevuld.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:V2019.01 OntwerpBeelden

2019-05-16T11:29:35Z

Tim Ruijters:

__NUMBEREDHEADINGS__
{{#customtitle:Functioneel Ontwerp Beelden 1.0.0}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_Images|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft het functioneel ontwerp voor de uitwisseling van beelden binnen MedMij. De algemene inleiding van de MedMij functionele ontwerpen kan [[MedMij:V2019.01_Ontwerpen| hier]] gevonden worden.

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case 1: Sturen beelden vanuit een PGO==
=== Doel en relevantie ===
*Het voor patiënten/ personen mogelijk maken regie op hun eigen gezondheid te nemen door beelden te sturen naar (verschillende) zorgaanbieders.
*Deze use case ondersteunt geen interactie met de patiënt middels het PGO. De zorgverlener kan niet online reageren op de gestuurde beelden. De zorgverlener dient buiten deze use case om de beelden te bespreken met de patiënt.

=== Domein ===
Beelden in het domein van zorgaanbieders en patiënten/ personen.

=== Context ===
Het gaat om het elektronisch en gestructureerd sturen van beelden vanuit een [[#persoonlijke-gezondheidsomgeving|persoonlijke gezondheidsomgeving]] (PGO) naar een 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 ===
Bij het sturen van beelden gaat het om de volgende informatie die uitgewisseld wordt: de beelden, bijbehorende meta-informatie per beeld en een mogelijk toelichting/ begeleidende tekst.

De informatie-elementen voor sturen en ontvangen van een beeld of collectie beelden staan in [http://decor.nictiz.nl/pub/beelden/bd-html-20190512T171559/tr-2.16.840.1.113883.2.4.3.11.60.54.4.2-2019-02-25T131649.html ART-DECOR Sturen Beelden].

==== Beeldformaat ====
*De ontvangende systemen dienen de volgende gegevensformaten te ondersteunen: JPEG, PNG, GIF en JP2. De PGO bepaalt zelf in welke van deze ondersteunende beeldformaten, de beelden worden verstuurd. De genoemde beeldformaten zijn ook de gegevensformaten, bestaande uit één frame, die door [[#DICOM-beeldformaten|DICOM standaard]] worden gespecificeerd voor gebruik bij DICOM web-services. Binnen deze use case zijn dit de enige gebruikte gegevensformaten voor beelden. Beeldformaat DICOM is niet in scope voor deze use case.
*Beelden mogen extra (meta)informatie bevatten in bijvoorbeeld de [[#Exif|Exif standaard]]. Een voorbeeld is het opslaan van patiëntgegevens binnen het beeldformaat JPEG. Hier wordt in deze use case echter geen gebruik van gemaakt.

==== Frequentie sturen beeld(en) ====
*Met het oog op bijvoorbeeld een ''denial of service attack'' is de overweging geweest om de frequentie waarmee de patiënt beelden kan versturen te beperken. Besloten is om voorlopig geen beperkingen op te nemen in de standaard.

==== Grootte van beeld(en) ====
De maximale grootte van een beeld is 20 MB (voordat het Base64 encoded is). Een PGO kan één tot maximaal 3 beelden tegelijk sturen. De maximale grootte van een collectie beelden is 60 MB. Base64 codering maakt het resultaat 37% groter.

==== Toelichting ====
De patiënt kan per beeld en/of per collectie beelden een begeleidende tekst meegeven. Dit gaat middels de 'toelichting' meta-informatie elementen.

==== Meta-informatie ====
Het beeld dient te worden voorzien van voldoende meta-informatie om door het ontvangende systeem goed te kunnen worden geïnterpreteerd. De specificatie van de meta-informatie wordt gegeven in de dataset en transactiebeschrijving. Daarnaast kent het FHIR profiel, verwezen vanuit het technisch ontwerp, nog een aantal verplichte concepten.
Deze use case houdt rekening met zelfstandige XIS-sen en met XIS-sen die zijn aangesloten op een XDS-netwerk door het bericht te voorzien van voldoende meta-informatie voor indexatie. Het correct indexeren van beelden in een XDS netwerk is de verantwoordelijkheid van het ontvangende XIS. Het technische ontwerp geeft een niet-normatieve implemenatierichtlijn middels een mapping van het FHIR bericht naar XDS concepten en het IHE MHD profiel.

=== 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="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 beelden sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Wil beelden ontvangen
|}
'''Bedrijfsrollen sturen beelden'''

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

[[Image:Activity_Diagram_-_Sturen_Beelden.png|Activiteitendiagram sturen beelden]]

'''Activiteitendiagram sturen beelden'''

=== Procesbeschrijving ===
==== Patient Journey – Thomas van Beek ====
Een voorbeeldsituatie die de meerwaarde van het sturen van beelden vanuit het PGO schetst is de patiënt journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf Thomas van Beek].
<blockquote>De afgelopen periode heeft Thomas wisselend last van eczeem. De vorige keer dat Thomas een dergelijke aanval had, waren de klachten al afgenomen op het moment dat de afspraak met de huisarts plaatsvond. Om de ernst van de klachten te kunnen inschatten heeft de huisarts gevraagd of Thomas in het vervolg een foto kan maken van de eczeem wanneer deze in alle ernst aanwezig zijn.
Vandaag is het weer zover. Bij het maken van de afspraak met de huisarts verzoekt de assistente of Thomas direct een foto kan maken en deze de huisarts wil toesturen. Thomas maakt foto's van onder andere zijn gezicht en upload deze naar zijn PGO. Een paar dagen na het versturen van de foto heeft hij een afspraak bij de huisarts. De foto's komen tijdens het consult ter sprake en een passende behandeling wordt gekozen.</blockquote>

==== Patient Journey – Kenneth van Someren ====
Een tweede voorbeeld waarbij de meerwaarde van het sturen van beelden vanuit het PGO geschetst kan worden is de patiënt journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Kenneth_van_Someren_MedMij.pdf Kenneth van Someren].

<blockquote>De grote antieke stoel in de woonkamer is het plekje waar Kenneth thuis graag te vinden is. De stoel begon echter de laatste tijd steeds minder lekker te zitten. De zuster adviseert regelmatig af te wisselen met de bank, maar de televisie is lang niet zo interessant als het dorpsplein aan de overkant van de straat. Het begon met enkel een klein rood plekje op zijn ruggengraat, maar inmiddels begon dit vormen aan te nemen die ook dochter Debby zorgen baarde. Na kort overleg met de thuiszorg besluit ze telefonisch contact op te nemen met de wondverpleegkundige van de organisatie. Deze vraagt om een duidelijke foto te maken en via het PGO te sturen voor beoordeling. De wondverpleegkundige ziet de foto en vind het ook zorgelijk. Daarom maak ze direct een afspraak met Kenneth om de plek zelf te beoordelen. De volgende ochtend lukt dat al en die middag komt de thuiszorg met de juiste kennis en materialen om de wond te behandelen.</blockquote>

==== Proces ====
Het stuk van het proces waar het in deze use case omgaat is:
* Patiënt en zorgverlener maken de afspraak dat de patient een beeld kan sturen aan de zorgverlener.
* Patiënt maakt, ontvangt of downloadt één of meerdere beelden en uploadt deze naar zijn PGO. De beelden kunnen gemaakt zijn door de patiënt, een zorgaanbieder of iemand anders.
* Patiënt heeft de mogelijkheid om een begeleidende tekst van maximaal 1 MB toe te voegen aan het beeld en/of beelden.
* Het PGO stuurt de beelden naar het systeem van de zorgaanbieder.
** Mogelijk moet of kan de patiënt metagegevens behorende bij de beelden aanvullen of invullen.
* De zorgaanbieder raadpleegt de beelden in zijn eigen dossier (XIS).
* De zorgverlener bespreekt het beeld buiten het PGO om met de patiënt. Deze use-case ondersteunt geen interactie met de patiënt middels het PGO.

Deze paragraaf vervolgt met een beschrijving van precondities, processtappen, en postcondities.

===== Preconditie =====
* De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van beelden tussen het eigen PGO en de betreffende XIS.
* De patiënt en zorgaanbieder hebben onderling afspraken gemaakt over het sturen van beelden.
* Het XIS van de zorgaanbieder is in staat afbeeldingen van de patient te ontvangen.
* De beelden bevinden zich in of zijn toegankelijk voor, het PGO

===== Processtappen =====
* Het systeem van de patiënt (PGO) stuurt de beelden naar het systeem van de zorgaanbieder (XIS).
* Het systeem van de zorgaanbieder (XIS) ontvangt de beelden van het PGO.

===== Postconditie =====
* Indien het systeem van de zorgaanbieder (XIS) gebruik maakt van een XDS-omgeving zal dit systeem de beelden op gepaste wijze in het netwerk registreren.
* De zorgaanbieder gebruikt het systeem (XIS) om de beelden te kunnen zien en/of beoordelen.

=== 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 beelden van de patiënt naar de zorgaanbieder.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Afkorting
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| Sturen van Beelden
| style="background-color: white;"| MM-1.0.0-BES-FHIR
| style="background-color: white;"| Sturen van beelden naar zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Ontvangen van Beelden
| style="background-color: white;"| MM-1.0.0-BEO-FHIR
| style="background-color: white;"| Ontvangen van beelden vanuit het PGO
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_Sturen_Beelden_(Totaal).png|Componenten diagram]]

'''Componenten diagram van systemen en 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 stuur- en ontvangstbericht). 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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|Beelden (PUSH)
|style="background-color: white;vertical-align:top;"|Sturen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BES-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:V2019.01_FHIR_Images |Beelden in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Ontvangen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BEO-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_-_Sturen_Beelden.png|Use case diagram Sturen Beelden]]

'''Use case diagram sturen beelden

=Functionaliteit=

== Eisen en wensen ==
*'''Afstemming vooraf''': Tijdens de ontwikkeling van de informatiestandaard is er nagedacht over het opnemen van een verplichte checkbox die de patiënt moet aanvinken om aan te geven dat er afstemming is geweest met de zorgverlener. Uiteindelijk is besloten om deze eis niet op te nemen in de standaard omdat in de praktijk patiënt en zorgverlener altijd een context hebben waarin het sturen van de beelden past. Daarnaast is het uitgangspunt om de patiënt zo min mogelijk te laten invullen bij het sturen van een beeld.

== Niet functionele eisen en wensen ==
Het technisch ontwerp bevat een aantal verplichte (technische) data elementen die niet zijn opgenomen in de functionele dataset. Een aantal van deze velden zijn verplicht gesteld om compatibiliteit met XDS-netwerken te ondersteunen. Het gaat om de volgende elementen:

* Indentificatie van het beeld en collectie beelden
* Een hash van de data van het beeld

=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;"| Persoonlijke Gezondheidsomgeving
| style="background-color: white;"|
| style="background-color: white;"| 06-12-2018
| style="background-color: white;"| https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/
| style="background-color: white;"| Patiëntenfederatie Nederland
|-
| style="background-color: white;"| -
| style="background-color: white;"| Rendered Media Types
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| http://dicom.nema.org/medical/dicom/2017d/output/html/part18.html#table_6.1.1-3
| style="background-color: white;"| NEMA (DICOM)
|-
| style="background-color: white;"| -
| style="background-color: white;"| Exif
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| https://en.wikipedia.org/wiki/Exif
| style="background-color: white;"| Wikipedia
|}

'''Referenties

=Bijlage: Documenthistorie=

==Release notes==

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

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

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 13-05-2019
| style="background-color: white;"|
* Versie 1.0.0 gepubliceerd.
|}

MedMij:Vprepub-2019.01 OntwerpBeelden

2019-05-16T11:29:35Z

Tim Ruijters:

MedMij:V2019.01 OntwerpBeelden

2019-05-15T11:52:25Z

Tim Ruijters:

__NUMBEREDHEADINGS__
{{#customtitle:Functioneel Ontwerp Beelden 1.0.0}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_Images|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft het functioneel ontwerp voor de uitwisseling van beelden binnen MedMij. De algemene inleiding van de MedMij functionele ontwerpen kan [[MedMij:V2019.01_Ontwerpen| hier]] gevonden worden.

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case 1: Sturen beelden vanuit een PGO==
=== Doel en relevantie ===
*Het voor patiënten/ personen mogelijk maken regie op hun eigen gezondheid te nemen door beelden te sturen naar (verschillende) zorgaanbieders.
*Deze use case ondersteunt geen interactie met de patiënt middels het PGO. De zorgverlener kan niet online reageren op de gestuurde beelden. De zorgverlener dient buiten deze use case om de beelden te bespreken met de patiënt.

=== Domein ===
Beelden in het domein van zorgaanbieders en patiënten/ personen.

=== Context ===
Het gaat om het elektronisch en gestructureerd sturen van beelden vanuit een [[#persoonlijke-gezondheidsomgeving|persoonlijke gezondheidsomgeving]] (PGO) naar een 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 ===
Bij het sturen van beelden gaat het om de volgende informatie die uitgewisseld wordt: de beelden, bijbehorende meta-informatie per beeld en een mogelijk toelichting/ begeleidende tekst.

De informatie-elementen voor sturen en ontvangen van een beeld of collectie beelden staan in [http://decor.nictiz.nl/pub/beelden/bd-html-20190512T171559/tr-2.16.840.1.113883.2.4.3.11.60.54.4.2-2019-02-25T131649.html ART-DECOR Sturen Beelden].

==== Beeldformaat ====
*De ontvangende systemen dienen de volgende gegevensformaten te ondersteunen: JPEG, PNG, GIF en JP2. De PGO bepaalt zelf in welke van deze ondersteunde standaarden, de beelden worden verstuurd. De genoemde beeldformaten zijn ook de gegevensformaten, bestaande uit één frame, die door [[#DICOM-beeldformaten|DICOM standaard]] worden gespecificeerd voor gebruik bij DICOM web-services. Binnen deze use case zijn dit de enige gebruikte gegevensformaten voor beelden. Beeldformaat DICOM is niet in scope voor deze use case.
*Beelden mogen extra (meta)informatie bevatten in bijvoorbeeld de [[#Exif|Exif standaard]]. Een voorbeeld is het opslaan van patiëntgegevens binnen het beeldformaat JPEG. Hier wordt in deze use case echter geen gebruik van gemaakt.

==== Frequentie sturen beeld(en) ====
*Met het oog op bijvoorbeeld een ''denial of service attack'' is de overweging geweest om de frequentie waarmee de patiënt beelden kan versturen te beperken. Besloten is om voorlopig geen beperkingen op te nemen in de standaard.

==== Grootte van beeld(en) ====
De maximale grootte van een beeld is 20 MB (voordat het Base64 encoded is). Een PGO kan één tot maximaal 3 beelden tegelijk sturen. De maximale grootte van een collectie beelden is 60 MB. Base64 codering maakt het resultaat 37% groter.

==== Toelichting ====
De patiënt kan per beeld en/of per collectie beelden een begeleidende tekst meegeven. Dit gaat middels de 'toelichting' meta-informatie elementen.

==== Meta-informatie ====
Het beeld dient te worden voorzien van voldoende meta-informatie om door het ontvangende systeem goed te kunnen worden geïnterpreteerd. De specificatie van de meta-informatie wordt gegeven in de dataset en transactiebeschrijving. Daarnaast kent het FHIR profiel, verwezen vanuit het technisch ontwerp, nog een aantal verplichte concepten.
Deze use case houdt rekening met zelfstandige XIS-sen en met XIS-sen die zijn aangesloten op een XDS-netwerk door het bericht te voorzien van voldoende meta-informatie voor indexatie. Het correct indexeren van beelden in een XDS netwerk is de verantwoordelijkheid van het ontvangende XIS. Het technische ontwerp geeft een niet-normatieve implemenatierichtlijn middels een mapping van het FHIR bericht naar XDS concepten en het IHE MHD profiel.

=== 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="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 beelden sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Wil beelden ontvangen
|}
'''Bedrijfsrollen sturen beelden'''

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

[[Image:Activity_Diagram_-_Sturen_Beelden.png|Activiteitendiagram sturen beelden]]

'''Activiteitendiagram sturen beelden'''

=== Procesbeschrijving ===
==== Patient Journey – Thomas van Beek ====
Een voorbeeldsituatie die de meerwaarde van het sturen van beelden vanuit het PGO schetst is de patiënt journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf Thomas van Beek].
<blockquote>De afgelopen periode heeft Thomas wisselend last van eczeem. De vorige keer dat Thomas een dergelijke aanval had, waren de klachten al afgenomen op het moment dat de afspraak met de huisarts plaatsvond. Om de ernst van de klachten te kunnen inschatten heeft de huisarts gevraagd of Thomas in het vervolg een foto kan maken van de eczeem wanneer deze in alle ernst aanwezig zijn.
Vandaag is het weer zover. Bij het maken van de afspraak met de huisarts verzoekt de assistente of Thomas direct een foto kan maken en deze de huisarts wil toesturen. Thomas maakt foto's van onder andere zijn gezicht en upload deze naar zijn PGO. Een paar dagen na het versturen van de foto heeft hij een afspraak bij de huisarts. De foto's komen tijdens het consult ter sprake en een passende behandeling wordt gekozen.</blockquote>

==== Patient Journey – Kenneth van Someren ====
Een tweede voorbeeld waarbij de meerwaarde van het sturen van beelden vanuit het PGO geschetst kan worden is de patiënt journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Kenneth_van_Someren_MedMij.pdf Kenneth van Someren].

<blockquote>De grote antieke stoel in de woonkamer is het plekje waar Kenneth thuis graag te vinden is. De stoel begon echter de laatste tijd steeds minder lekker te zitten. De zuster adviseert regelmatig af te wisselen met de bank, maar de televisie is lang niet zo interessant als het dorpsplein aan de overkant van de straat. Het begon met enkel een klein rood plekje op zijn ruggengraat, maar inmiddels begon dit vormen aan te nemen die ook dochter Debby zorgen baarde. Na kort overleg met de thuiszorg besluit ze telefonisch contact op te nemen met de wondverpleegkundige van de organisatie. Deze vraagt om een duidelijke foto te maken en via het PGO te sturen voor beoordeling. De wondverpleegkundige ziet de foto en vind het ook zorgelijk. Daarom maak ze direct een afspraak met Kenneth om de plek zelf te beoordelen. De volgende ochtend lukt dat al en die middag komt de thuiszorg met de juiste kennis en materialen om de wond te behandelen.</blockquote>

==== Proces ====
Het stuk van het proces waar het in deze use case omgaat is:
* Patiënt en zorgverlener maken de afspraak dat de patient een beeld kan sturen aan de zorgverlener.
* Patiënt maakt, ontvangt of downloadt één of meerdere beelden en uploadt deze naar zijn PGO. De beelden kunnen gemaakt zijn door de patiënt, een zorgaanbieder of iemand anders.
* Patiënt heeft de mogelijkheid om een begeleidende tekst van maximaal 1 MB toe te voegen aan het beeld en/of beelden.
* Het PGO stuurt de beelden naar het systeem van de zorgaanbieder.
** Mogelijk moet of kan de patiënt metagegevens behorende bij de beelden aanvullen of invullen.
* De zorgaanbieder raadpleegt de beelden in zijn eigen dossier (XIS).
* De zorgverlener bespreekt het beeld buiten het PGO om met de patiënt. Deze use-case ondersteunt geen interactie met de patiënt middels het PGO.

Deze paragraaf vervolgt met een beschrijving van precondities, processtappen, en postcondities.

===== Preconditie =====
* De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van beelden tussen het eigen PGO en de betreffende XIS.
* De patiënt en zorgaanbieder hebben onderling afspraken gemaakt over het sturen van beelden.
* Het XIS van de zorgaanbieder is in staat afbeeldingen van de patient te ontvangen.
* De beelden bevinden zich in of zijn toegankelijk voor, het PGO

===== Processtappen =====
* Het systeem van de patiënt (PGO) stuurt de beelden naar het systeem van de zorgaanbieder (XIS).
* Het systeem van de zorgaanbieder (XIS) ontvangt de beelden van het PGO.

===== Postconditie =====
* Indien het systeem van de zorgaanbieder (XIS) gebruik maakt van een XDS-omgeving zal dit systeem de beelden op gepaste wijze in het netwerk registreren.
* De zorgaanbieder gebruikt het systeem (XIS) om de beelden te kunnen zien en/of beoordelen.

=== 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 beelden van de patiënt naar de zorgaanbieder.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Afkorting
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| Sturen van Beelden
| style="background-color: white;"| MM-1.0.0-BES-FHIR
| style="background-color: white;"| Sturen van beelden naar zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Ontvangen van Beelden
| style="background-color: white;"| MM-1.0.0-BEO-FHIR
| style="background-color: white;"| Ontvangen van beelden vanuit het PGO
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_Sturen_Beelden_(Totaal).png|Componenten diagram]]

'''Componenten diagram van systemen en 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 stuur- en ontvangstbericht). 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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|Beelden (PUSH)
|style="background-color: white;vertical-align:top;"|Sturen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BES-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:V2019.01_FHIR_Images |Beelden in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Ontvangen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BEO-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_-_Sturen_Beelden.png|Use case diagram Sturen Beelden]]

'''Use case diagram sturen beelden

=Functionaliteit=

== Eisen en wensen ==
*'''Afstemming vooraf''': Tijdens de ontwikkeling van de informatiestandaard is er nagedacht over het opnemen van een verplichte checkbox die de patiënt moet aanvinken om aan te geven dat er afstemming is geweest met de zorgverlener. Uiteindelijk is besloten om deze eis niet op te nemen in de standaard omdat in de praktijk patiënt en zorgverlener altijd een context hebben waarin het sturen van de beelden past. Daarnaast is het uitgangspunt om de patiënt zo min mogelijk te laten invullen bij het sturen van een beeld.

== Niet functionele eisen en wensen ==
Het technisch ontwerp bevat een aantal verplichte (technische) data elementen die niet zijn opgenomen in de functionele dataset. Een aantal van deze velden zijn verplicht gesteld om compatibiliteit met XDS-netwerken te ondersteunen. Het gaat om de volgende elementen:

* Indentificatie van het beeld en collectie beelden
* Een hash van de data van het beeld

=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;"| Persoonlijke Gezondheidsomgeving
| style="background-color: white;"|
| style="background-color: white;"| 06-12-2018
| style="background-color: white;"| https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/
| style="background-color: white;"| Patiëntenfederatie Nederland
|-
| style="background-color: white;"| -
| style="background-color: white;"| Rendered Media Types
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| http://dicom.nema.org/medical/dicom/2017d/output/html/part18.html#table_6.1.1-3
| style="background-color: white;"| NEMA (DICOM)
|-
| style="background-color: white;"| -
| style="background-color: white;"| Exif
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| https://en.wikipedia.org/wiki/Exif
| style="background-color: white;"| Wikipedia
|}

'''Referenties

=Bijlage: Documenthistorie=

==Release notes==

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

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

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 13-05-2019
| style="background-color: white;"|
* Versie 1.0.0 gepubliceerd.
|}

MedMij:Vprepub-2019.01 OntwerpBeelden

2019-05-15T11:52:25Z

Tim Ruijters:

__NUMBEREDHEADINGS__
{{#customtitle:Functioneel Ontwerp Beelden 1.0.0}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_Images|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft het functioneel ontwerp voor de uitwisseling van beelden binnen MedMij. De algemene inleiding van de MedMij functionele ontwerpen kan [[MedMij:V2019.01_Ontwerpen| hier]] gevonden worden.

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case 1: Sturen beelden vanuit een PGO==
=== Doel en relevantie ===
*Het voor patiënten/ personen mogelijk maken regie op hun eigen gezondheid te nemen door beelden te sturen naar (verschillende) zorgaanbieders.
*Deze use case ondersteunt geen interactie met de patiënt middels het PGO. De zorgverlener kan niet online reageren op de gestuurde beelden. De zorgverlener dient buiten deze use case om de beelden te bespreken met de patiënt.

=== Domein ===
Beelden in het domein van zorgaanbieders en patiënten/ personen.

=== Context ===
Het gaat om het elektronisch en gestructureerd sturen van beelden vanuit een [[#persoonlijke-gezondheidsomgeving|persoonlijke gezondheidsomgeving]] (PGO) naar een 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 ===
Bij het sturen van beelden gaat het om de volgende informatie die uitgewisseld wordt: de beelden, bijbehorende meta-informatie per beeld en een mogelijk toelichting/ begeleidende tekst.

De informatie-elementen voor sturen en ontvangen van een beeld of collectie beelden staan in [http://decor.nictiz.nl/pub/beelden/bd-html-20190512T171559/tr-2.16.840.1.113883.2.4.3.11.60.54.4.2-2019-02-25T131649.html ART-DECOR Sturen Beelden].

==== Beeldformaat ====
*De ontvangende systemen dienen de volgende gegevensformaten te ondersteunen: JPEG, PNG, GIF en JP2. De PGO bepaalt zelf in welke van deze ondersteunde standaarden, de beelden worden verstuurd. De genoemde beeldformaten zijn ook de gegevensformaten, bestaande uit één frame, die door [[#DICOM-beeldformaten|DICOM standaard]] worden gespecificeerd voor gebruik bij DICOM web-services. Binnen deze use case zijn dit de enige gebruikte gegevensformaten voor beelden. Beeldformaat DICOM is niet in scope voor deze use case.
*Beelden mogen extra (meta)informatie bevatten in bijvoorbeeld de [[#Exif|Exif standaard]]. Een voorbeeld is het opslaan van patiëntgegevens binnen het beeldformaat JPEG. Hier wordt in deze use case echter geen gebruik van gemaakt.

==== Frequentie sturen beeld(en) ====
*Met het oog op bijvoorbeeld een ''denial of service attack'' is de overweging geweest om de frequentie waarmee de patiënt beelden kan versturen te beperken. Besloten is om voorlopig geen beperkingen op te nemen in de standaard.

==== Grootte van beeld(en) ====
De maximale grootte van een beeld is 20 MB (voordat het Base64 encoded is). Een PGO kan één tot maximaal 3 beelden tegelijk sturen. De maximale grootte van een collectie beelden is 60 MB. Base64 codering maakt het resultaat 37% groter.

==== Toelichting ====
De patiënt kan per beeld en/of per collectie beelden een begeleidende tekst meegeven. Dit gaat middels de 'toelichting' meta-informatie elementen.

==== Meta-informatie ====
Het beeld dient te worden voorzien van voldoende meta-informatie om door het ontvangende systeem goed te kunnen worden geïnterpreteerd. De specificatie van de meta-informatie wordt gegeven in de dataset en transactiebeschrijving. Daarnaast kent het FHIR profiel, verwezen vanuit het technisch ontwerp, nog een aantal verplichte concepten.
Deze use case houdt rekening met zelfstandige XIS-sen en met XIS-sen die zijn aangesloten op een XDS-netwerk door het bericht te voorzien van voldoende meta-informatie voor indexatie. Het correct indexeren van beelden in een XDS netwerk is de verantwoordelijkheid van het ontvangende XIS. Het technische ontwerp geeft een niet-normatieve implemenatierichtlijn middels een mapping van het FHIR bericht naar XDS concepten en het IHE MHD profiel.

=== 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="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 beelden sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Wil beelden ontvangen
|}
'''Bedrijfsrollen sturen beelden'''

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

[[Image:Activity_Diagram_-_Sturen_Beelden.png|Activiteitendiagram sturen beelden]]

'''Activiteitendiagram sturen beelden'''

=== Procesbeschrijving ===
==== Patient Journey – Thomas van Beek ====
Een voorbeeldsituatie die de meerwaarde van het sturen van beelden vanuit het PGO schetst is de patiënt journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf Thomas van Beek].
<blockquote>De afgelopen periode heeft Thomas wisselend last van eczeem. De vorige keer dat Thomas een dergelijke aanval had, waren de klachten al afgenomen op het moment dat de afspraak met de huisarts plaatsvond. Om de ernst van de klachten te kunnen inschatten heeft de huisarts gevraagd of Thomas in het vervolg een foto kan maken van de eczeem wanneer deze in alle ernst aanwezig zijn.
Vandaag is het weer zover. Bij het maken van de afspraak met de huisarts verzoekt de assistente of Thomas direct een foto kan maken en deze de huisarts wil toesturen. Thomas maakt foto's van onder andere zijn gezicht en upload deze naar zijn PGO. Een paar dagen na het versturen van de foto heeft hij een afspraak bij de huisarts. De foto's komen tijdens het consult ter sprake en een passende behandeling wordt gekozen.</blockquote>

==== Patient Journey – Kenneth van Someren ====
Een tweede voorbeeld waarbij de meerwaarde van het sturen van beelden vanuit het PGO geschetst kan worden is de patiënt journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Kenneth_van_Someren_MedMij.pdf Kenneth van Someren].

<blockquote>De grote antieke stoel in de woonkamer is het plekje waar Kenneth thuis graag te vinden is. De stoel begon echter de laatste tijd steeds minder lekker te zitten. De zuster adviseert regelmatig af te wisselen met de bank, maar de televisie is lang niet zo interessant als het dorpsplein aan de overkant van de straat. Het begon met enkel een klein rood plekje op zijn ruggengraat, maar inmiddels begon dit vormen aan te nemen die ook dochter Debby zorgen baarde. Na kort overleg met de thuiszorg besluit ze telefonisch contact op te nemen met de wondverpleegkundige van de organisatie. Deze vraagt om een duidelijke foto te maken en via het PGO te sturen voor beoordeling. De wondverpleegkundige ziet de foto en vind het ook zorgelijk. Daarom maak ze direct een afspraak met Kenneth om de plek zelf te beoordelen. De volgende ochtend lukt dat al en die middag komt de thuiszorg met de juiste kennis en materialen om de wond te behandelen.</blockquote>

==== Proces ====
Het stuk van het proces waar het in deze use case omgaat is:
* Patiënt en zorgverlener maken de afspraak dat de patient een beeld kan sturen aan de zorgverlener.
* Patiënt maakt, ontvangt of downloadt één of meerdere beelden en uploadt deze naar zijn PGO. De beelden kunnen gemaakt zijn door de patiënt, een zorgaanbieder of iemand anders.
* Patiënt heeft de mogelijkheid om een begeleidende tekst van maximaal 1 MB toe te voegen aan het beeld en/of beelden.
* Het PGO stuurt de beelden naar het systeem van de zorgaanbieder.
** Mogelijk moet of kan de patiënt metagegevens behorende bij de beelden aanvullen of invullen.
* De zorgaanbieder raadpleegt de beelden in zijn eigen dossier (XIS).
* De zorgverlener bespreekt het beeld buiten het PGO om met de patiënt. Deze use-case ondersteunt geen interactie met de patiënt middels het PGO.

Deze paragraaf vervolgt met een beschrijving van precondities, processtappen, en postcondities.

===== Preconditie =====
* De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van beelden tussen het eigen PGO en de betreffende XIS.
* De patiënt en zorgaanbieder hebben onderling afspraken gemaakt over het sturen van beelden.
* Het XIS van de zorgaanbieder is in staat afbeeldingen van de patient te ontvangen.
* De beelden bevinden zich in of zijn toegankelijk voor, het PGO

===== Processtappen =====
* Het systeem van de patiënt (PGO) stuurt de beelden naar het systeem van de zorgaanbieder (XIS).
* Het systeem van de zorgaanbieder (XIS) ontvangt de beelden van het PGO.

===== Postconditie =====
* Indien het systeem van de zorgaanbieder (XIS) gebruik maakt van een XDS-omgeving zal dit systeem de beelden op gepaste wijze in het netwerk registreren.
* De zorgaanbieder gebruikt het systeem (XIS) om de beelden te kunnen zien en/of beoordelen.

=== 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 beelden van de patiënt naar de zorgaanbieder.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Afkorting
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| Sturen van Beelden
| style="background-color: white;"| MM-1.0.0-BES-FHIR
| style="background-color: white;"| Sturen van beelden naar zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Ontvangen van Beelden
| style="background-color: white;"| MM-1.0.0-BEO-FHIR
| style="background-color: white;"| Ontvangen van beelden vanuit het PGO
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_Sturen_Beelden_(Totaal).png|Componenten diagram]]

'''Componenten diagram van systemen en 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 stuur- en ontvangstbericht). 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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|Beelden (PUSH)
|style="background-color: white;vertical-align:top;"|Sturen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BES-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:V2019.01_FHIR_Images |Beelden in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Ontvangen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BEO-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_-_Sturen_Beelden.png|Use case diagram Sturen Beelden]]

'''Use case diagram sturen beelden

=Functionaliteit=

== Eisen en wensen ==
*'''Afstemming vooraf''': Tijdens de ontwikkeling van de informatiestandaard is er nagedacht over het opnemen van een verplichte checkbox die de patiënt moet aanvinken om aan te geven dat er afstemming is geweest met de zorgverlener. Uiteindelijk is besloten om deze eis niet op te nemen in de standaard omdat in de praktijk patiënt en zorgverlener altijd een context hebben waarin het sturen van de beelden past. Daarnaast is het uitgangspunt om de patiënt zo min mogelijk te laten invullen bij het sturen van een beeld.

== Niet functionele eisen en wensen ==
Het technisch ontwerp bevat een aantal verplichte (technische) data elementen die niet zijn opgenomen in de functionele dataset. Een aantal van deze velden zijn verplicht gesteld om compatibiliteit met XDS-netwerken te ondersteunen. Het gaat om de volgende elementen:

* Indentificatie van het beeld en collectie beelden
* Een hash van de data van het beeld

=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;"| Persoonlijke Gezondheidsomgeving
| style="background-color: white;"|
| style="background-color: white;"| 06-12-2018
| style="background-color: white;"| https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/
| style="background-color: white;"| Patiëntenfederatie Nederland
|-
| style="background-color: white;"| -
| style="background-color: white;"| Rendered Media Types
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| http://dicom.nema.org/medical/dicom/2017d/output/html/part18.html#table_6.1.1-3
| style="background-color: white;"| NEMA (DICOM)
|-
| style="background-color: white;"| -
| style="background-color: white;"| Exif
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| https://en.wikipedia.org/wiki/Exif
| style="background-color: white;"| Wikipedia
|}

'''Referenties

=Bijlage: Documenthistorie=

==Release notes==

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

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

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 13-05-2019
| style="background-color: white;"|
* Versie 1.0.0 gepubliceerd.
|}

MedMij:V2019.01 FHIR Images

2019-03-15T11:03:42Z

Tim Ruijters: /* History */

{{#customtitle:MedMij FHIR Implementation Guide: Images}}

{{IssueBox|This information standard is in development. Feedback gathered during the public consultation from 10-01-2019 to 21-02-2019 is being processed.

If you have any feedback, please submit it at https://bits.nictiz.nl/projects/MSIOC/}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<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:V2019.01_OntwerpBeelden|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.01_Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This page describes the exchange of images within MedMij. In contrary to other described use cases for MedMij no existing information standard fits nor are there specific ZIB models applicable. To achieve exchange of images, MedMij adopts as much as possible from existing standards, such as the DICOM standard and the Mobile access to Health Documents (MHD) profile from Integrating the Healthcare Enterprise (IHE) that defines a RESTful/HTTP interface to an [http://wiki.ihe.net/index.php/Cross-Enterprise_Document_Sharing XDS] environment using HL7 FHIR STU3 resources.

The specification currently consists of one use case, that covers sending an image by a patient to a healthcare provider. Based on future research, a use case to retrieve images by the patient will be added. Most likely, this will be based on DICOMweb™, which is the DICOM standard for web-based medical imaging based on RESTful services.

'''Note''': this page is part of the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG MedMij FHIR Implementation Guide] and is a technical representation of the functional design published on this [[MedMij:V2019.01_Ontwerpen| wiki page]].

==IHE MHD specification==
Mobile access to Health Documents (MHD) profile defines a simple HTTP interface to an XDS like environment. The four described transactions leverage the document content and format agnostic metadata concepts from XDS but simplify them for access by constrained environments such as mobile devices, or other resource-constrained systems. The MHD profile does not replace XDS. It can be used to allow mobile devices, or other resource-constrained systems, access to an XDS health information exchange.[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)]

'''Wiki:'''
[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) Mobile acces to Health Document (MHD)]

'''Document:'''
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf MHD Supplement] (Rev 2.3 July 24, 2017)

'''Additional Supplement:'''
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_Appx-Z.pdf Appendix Z on HL7 FHIR]

=Actors and transactions involved=
Table 1 shows the relevant actors, systems and FHIR capability statements in a MedMij context. The capability statements demonstrate the minimum requirements to be conformant to the described use cases.

{| 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]] [https://simplifier.net/NictizSTU3-Zib2017/image-clientcapabilities CapabilityStatement: Client]
| Image FHIR Client requirements
|-
| Healthcare Provider
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/NictizSTU3-Zib2017/image-servercapabilities CapabilityStatement: Server]
| Image FHIR Server requirements
|}
'''Table 1. Actors, systems and FHIR capability statements'''

Table 2 shows the MHD actors and transactions in perspective of the systems used in a MedMij context.
{| class="wikitable"
! style="font-weight: bold; text-align:left;" | Person
! style="font-weight: bold; text-align:left;" | System
! style="font-weight: bold; text-align:left;" | Role
! style="font-weight: bold; text-align:left;" | MHD Actors - for XDS
! style="font-weight: bold; text-align:left;" | MHD Transactions - for XDS
|-
| Patient
| PHR
| Sends image to the XIS
| Document Source
| rowspan="2" |Provide Document Bundle
|-
| Healthcare provider
| XIS
| Receives image from the PHR
| Document Recipient
|}
'''Table 2. MHD actors and transactions in perspective of systems in a MedMij context'''

=Boundaries and Relationships=
The use case where an image is sent from a PHR to a XIS is influenced by the IHE MHD profile with regards to the PHR message semantics and mandatory elements. The specifications for this use case mainly deviates in the use of the FHIR Media resource instead of the DocumentReference resource. Although the DocumentResource is in line with the requirements of persisting content in a XDS network and the resource can handle images, the Media resource is more appropriate and specific for the exchange of images. The Media resource has additional, more specific, (medical related) elements compared to the DocumentReference. These are the Media's view, reasonCode, bodySite, device and to a lesser extent the height and width elements. In addition, the Media resource has a reference coming from the DiagnosticReport that may be of value for further development of the MedMij information standard for images.

A XIS can possibly act within a XDS network. The information standards in use by MedMij have the primary objective to enable standardized communication based on FHIR STU3. As a secondary objective, enabling exchange with XDS networks is taken into account. For this objective, the PHR will need to provide additional meta information to the Media resource. The additional meta information allows XIS actors to index an image properly within a XDS network. The XIS is responsible for converting the PHR message into a XDS DocumentEntry. A mapping from the Media resource to the mandatory metadata elements of the IHE MHD DocumentReference resource is provided. The IHE MHD and general IHE XDS profiles will provide the information needed to perform a successful DocumentEntry of an image.

=Use case: send image from a PHR to a XIS=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]

== Introduction ==
This use case describes the minimal required technical functionalities in order to exchange an image made by the patient to a healthcare provider. Typical process flow would be:
# Patients makes, downloads or receives an image and uploads it to his PHR.
# The PHR sends the image to the chosen XIS system.
## Potentially the patient needs to provide sufficient metadata concerning the image.
# A healthcare provider views the image in his XIS.
This use case presumes made agreements between the patient and healthcare provider. Besides a technical answer by the XIS of the healthcare provider, no answer to the patient is expected.

The following technical specifications will concern the process mentioned at point 2.

==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 Image Bundle (PUSH)
|style="background-color: white;vertical-align:top;"|Send image bundle request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends image to the XIS
|-
|style="background-color: white;vertical-align:top;"|Receive image bundle response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives image from PHR
|}

== Invocations ==
{{FHIR-IG-Afsprakenstelsel-Note}}

=== Client - PHR request===
When the patient (PHR) wants to send one or more images, it issues a send image bundle request message.

The PHR initiate a FHIR transaction using a create action by sending an HTTP POST request composed of a FHIR Bundle Resource containing one or more FHIR Media resources, zero or more Binary resources and one patient resource to the XIS Recipient. References to the FHIR specification for the required transaction and POST requests are given in the [[#Interactions.2C_operations.2C_search_parameters | interactions, operations and search parameters]] section below.

The PHR executes an HTTP POST against the XIS's base endpoint as shown below.

<pre>
POST [base] {?_format=[mime-type]}
</pre>

The PHR shall assure all FHIR resource elements are consistent with the requirements specified in the StructureDefinitions for List, Media, Device, Patient, Practitioner and Organization resources. References to these StructureDefinitions are provided in [[#List_of_StructureDefinitions | list of StructureDefinitions]].

==== Textual Requirements ====

* The Bundle.type shall be transaction.

* The Media.content.attachment.url points at the image content, which shall be in the Bundle as a Binary resource. See FHIR Resolving references in Bundles at the [http://hl7.org/fhir/STU3/bundle.html#references FHIR specification] and use within MedMij at the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG#Use_of_the_reference_datatype MedMij Use case overarching principles].

* All Media.subject values shall be References to Patient resources and shall be included in the Bundle.

* A List resource shall be used to group the images if a collection of images are sent.

* Accompanying text from the patient for the image and/or collection of images shall be placed in the Media.note and List.note respectively.

=== Examples ===
'''Message components'''
* [https://simplifier.net/nictizstu3-zib2017/media-example-eczema-comprehensive-data Media comprehensive data]
* [https://simplifier.net/nictizstu3-zib2017/media-example-eczema-minimum-data Media minimum data]
* [https://simplifier.net/nictizstu3-zib2017/binary-example Binary of image]
* [https://simplifier.net/nictizstu3-zib2017/images-list-media List of Media resources]
'''Transaction Bundle'''
* [https://simplifier.net/nictizstu3-zib2017/image-transaction-bundle Transaction Bundle containing one image]
* [https://simplifier.net/nictizstu3-zib2017/images-bundle-transaction-multiple-images Transaction Bundle containing multiple images]
* [http://hl7.org/fhir/bundle-response.xml.html Transaction Bundle response - example from the FHIR spec]

=== Server - XIS response ===
The XIS shall process the bundle atomically. If necessary for processing, the XIS shall retrieve resources referenced by absolute URLs in the FHIR Bundle Resource.

The XIS returns an HTTP Status code appropriate to the processing outcome, conforming to the transaction specification requirements as specified in the FHIR specification.

The XIS response message shall be sent when a success or error condition needs to be communicated. Success is only indicated once the image(s) is/are received and completely processed and persisted as appropriate to the XIS configuration.

To enable the PHR to know the outcome of processing the transaction, and the identities assigned to the resources by the XIS, the XIS shall return a Bundle, with type set to transaction-response, that contains one entry for each entry in the request, in the same order as received, with the Bundle.entry.response.outcome indicating the results of processing the entry. The XIS shall comply with FHIR [http://hl7.org/fhir/STU3/bundle.html#transaction-response Bundle transaction-response] and [http://hl7.org/fhir/STU3/http.html#transaction-response the HTTP transaction-response] specifications.

=== Server - XIS & XDS ===
If the receiving XIS is part of a XDS network, it will need to convert the PHR request message into a proper message for the IHE "Provide and Register Document Set-b [ITI-41]" transaction. The XIS shall create appropriate metadata from the resources in the FHIR Bundle. The PHR shall provide the minimally required metadata. A mapping is shown below to assist in the XDS entry. The FHIR Media resource is mapped to the mandatory elements in the IHE MHD Profile on "DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata". IHE MHD defined these elements as a minimum for a XDS DocumentEntry. The [https://simplifier.net/NictizSTU3-Zib2017/ImagesMedia/~mappings Media StructureDefinition] contains a mapping to this profile and to XDS DocumentEntry, the [https://simplifier.net/NictizSTU3-Zib2017/images-List/~mappings List StructureDefinition] contatins a mapping to the XDS 'Folder Metadata Attributes'. Some FHIR elements do not translate to XDS concepts; the handling of these elements is left to the implementer of the XIS.

Upon successful conversion of the FHIR Bundle to XDS metadata, the XIS shall execute the Provide and Register Document Set-b [ITI-41] transaction. The transaction result and any error or warning messages, shall be reported to the PHR. The XIS is responsible for translating the XDS response to the appropriate HTTP Status Code and FHIR OperationOutcome Resource in the Send Image Bundle Response Message.

==== Mapping Media to mandatory IHE MHD DocumentReference elements needed for XDS DocumentEntry ====

{| class="wikitable"
! style="font-weight:bold;" | IHE MHD Profile on DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata
! style="font-weight:bold;" | Media for images, used by the PHR
! style="font-weight:bold;" | Implementation notes for XIS & XDS
|-
| DocumentReference.masterIdentifier
| Media.identifier
|
|-
| DocumentReference.status
|
| Fixed value "current".
|-
| DocumentReference.type
| Media.type
| Fixed LOINC code: 72170-4 Photographic image Unspecified body region Document.
|-
| DocumentReference.class
| Media.reasonCode
| If no reasonCode is present, a fixed LOINC code 72170-4 Photographic image Unspecified body region Document can be used.
|-
| DocumentReference.subject
| Media.subject
|
|-
| DocumentReference.indexed
| Media.occurrenceDateTime
|
|-
| DocumentReference.securityLabel
| Media.meta.security
| If no value is present 'normal' should be used as default.
|-
| DocumentReference.content
| Media.content
|
|-
| DocumentReference.content.attachment
| Media.content.attachment
|
|-
| DocumentReference.content.attachment.contentType
| Media.content.attachment.contentType
| Possible media content types: JPEG, PNG, GIF, JP2.
|-
| DocumentReference.content.attachment.url
| Media.content.attachment.url
|
|-
| DocumentReference.content.attachment.size
| Media.content.attachment.size
|
|-
| DocumentReference.content.attachment.hash
| Media.content.attachment.hash
|
|-
| DocumentReference.content.format
|
| Fixed value "mimeType Sufficient".
|}

A number of fixed values can be used in indexing to a XDS network based on an image sent by a patient. These are status, type, security (if no value is given in the Media.meta.security element) and format. Below the technical representation of these fixed values is shown.

<pre>
<DocumentReference>
....
<status value="current" />
....
<type>
<coding>
<system value="http://loinc.org/" />
<code value="72170-4" />
<display value="Photographic image Unspecified body region Document" />
</coding>
</type>
....
<securityLabel>
<coding>
<system value="http://hl7.org/fhir/v3/Confidentiality" />
<code value="N" />
<display value="normal" />
</coding>
</securityLabel>
....
<format>
<system value="urn:oid:1.3.6.1.4.1.19376.1.2.3"/>
<code value="urn:ihe:iti:xds:2017:mimeTypeSufficient"/>
<display value="mimeType Sufficient"/>
</format>
....
</DocumentReference>
</pre>

{{IssueBox|'''Images.1''' Currently we mandate the PHR to provide identifiers for the Media and List, which should conform to the requirements of an identifier needed for a DocumentEntry. Should this be mandatory? Isn't this an element that a XIS should generate?}}
{{IssueBox|'''Images.2''' Media Status. A DocumentReference has a status while Media does not in STU3. Within IHE MHD only the status values 'current' and 'superseded' are used. This in combination with a relatesTo element to indicate which document is superseded. This use case does not specify how to handle superseded images. Current scope is to exchange images witouth a status indicator. Could this be a problem for XDS networks?}}
{{IssueBox|'''Images.3''' Is a 'normal' security code possible as default when no information is given by the patient?}}
{{IssueBox|'''Images.4''' Does Media.reasonCode map to DocumentReference.class / XDS classCode? Do we need the patient to mandatory provide information for this concept? Does the fixed code suggestion fits if the patient does not provide information?}}
{{IssueBox|'''Images.5''' The mapping table above only maps the mandatory elements from the DocumentReference profile. The StructureDefinitions Media en List contain all the mappings and is referenced above as well. However, should we expand this table here with additional and optional elements?}}

==Interactions, operations, search parameters==

===Interactions===
The following logical interactions are needed for this use case:
* [http://hl7.org/fhir/STU3/http.html#create Create]
* [http://hl7.org/fhir/STU3/http.html#transaction Transaction]

===Operations===
There are no defined operations for this use case.

===Search parameters===
There are no search parameters needed for this use case.

==List of StructureDefinitions==
===MedMij StructureDefinitions===

{{NoteBoxPackage|https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/1.0.0|1.0.0|MedMij:Vdraft_FHIR_IG}}

{| 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
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient]
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-practitioner http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner]
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization]
|-
| Beeld
| Image
| Media
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/structuredefinition/images-media http://nictiz.nl/fhir/StructureDefinition/images-Media]
|-
| CollectieBeelden
| CollectionImages
| List
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/StructureDefinition/images-List http://nictiz.nl/fhir/StructureDefinition/images-List]
|-
| MedischHulpmiddel.Product
| MedicalDevice.Product
| Device
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct]
|}

===IHE MHD StructureDefinitions===
IHE has defined StructureDefinitions and other Conformance resources applicable to this use case. The FHIR Implementation Guide on the '''[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide IHE MHD wiki]''' lists these StructureDefinitions.

* IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive]

* IHE MHD Profile on DocumentReference (DocumentEntry) when used in the Provide Transaction with Comprehensive (aka XDS-on-FHIR) Metadata
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference]

* IHE MHD Profile on List (Folder)
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.List http://ihe.net/fhir/StructureDefinition/IHE.MHD.List]

{{IssueBox|'''IHE.1''' Currently, we don't use or specify a profile that concerns the transaction request. (A profile like "IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata") Is such a profile nescessary? We don't use it in other MedMij use cases and the transaction bundle is described by the FHIR specification and textual in this use case.}}
{{IssueBox|'''IHE.2''' The main reason the "IHE MHD Profile on List (Folder)" is not used, is because it mandates the use of .title and .code which likely contains information a patient needs to enter manually. As we would like to keep the burden on patients as low as possible a custom profile of list is used without these mandatory elements. Additionally, one of the benefits is that we can use references to our own profiles. }}
{{IssueBox|'''IHE.3''' The IHE StructureDefinitions contain a number of errors, mentioned in this [https://chat.fhir.org/#narrow/stream/100-IHE-FHIR.20profiles/topic/IHE.20MHD.20profiles Zulip chat]. These issues will be solved in the R4 release of IHE MHD. We will likely make a pull request to address these issues for the STU3 release. .}}
{{IssueBox|'''IHE.4''' The IHE StructureDefinitions restrict the use of the .created element. This is a known issue and will be addressed in the R4 release of the profiles. This issue (CP-ITI-1100) can be found on the [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide IHE MHD wiki]. Therefore the indexed element is used to capture creation time.}}

=Annex: Document history=

==Release notes==
Release notes can be found on the [[MedMij:Vdraft_OntwerpBGZ_2017#Release_notes|functional design page]].

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| -
| style="background-color: white;"| 24-01-2019
| style="background-color: white;"|
* Added FHIR examples and StructureDefinitions (Transaction Bundle and List profile).
* Textual improvements.
* Added and improved open issues with issue boxes.
* Added an open public consultation issue box at the top of the page.
* Moved release notes to the functional design page.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 19-12-2018
| style="background-color: white;"|
* Added FHIR examples and StructureDefinitions.
* Textual improvements.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 13-12-2018
| style="background-color: white;"|
* Added Media - DocumentReference mapping.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 12-12-2018
| style="background-color: white;"|
* Added Boundaries and Relationships.
* Added Client - PHR request.
* Added Server - XIS response.
* Added Server - XIS & XDS.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 11-12-2018
| style="background-color: white;"|
* Added introduction text.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"|
* Added concept version.
|}

MedMij:Vprepub-2019.01 FHIR Images

2019-03-15T11:03:42Z

Tim Ruijters: /* History */

MedMij:V2019.01 FHIR Images

2019-03-15T10:57:40Z

Tim Ruijters:

{{#customtitle:MedMij FHIR Implementation Guide: Images}}

{{IssueBox|This information standard is in development. Feedback gathered during the public consultation from 10-01-2019 to 21-02-2019 is being processed.

If you have any feedback, please submit it at https://bits.nictiz.nl/projects/MSIOC/}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<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:V2019.01_OntwerpBeelden|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.01_Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This page describes the exchange of images within MedMij. In contrary to other described use cases for MedMij no existing information standard fits nor are there specific ZIB models applicable. To achieve exchange of images, MedMij adopts as much as possible from existing standards, such as the DICOM standard and the Mobile access to Health Documents (MHD) profile from Integrating the Healthcare Enterprise (IHE) that defines a RESTful/HTTP interface to an [http://wiki.ihe.net/index.php/Cross-Enterprise_Document_Sharing XDS] environment using HL7 FHIR STU3 resources.

The specification currently consists of one use case, that covers sending an image by a patient to a healthcare provider. Based on future research, a use case to retrieve images by the patient will be added. Most likely, this will be based on DICOMweb™, which is the DICOM standard for web-based medical imaging based on RESTful services.

'''Note''': this page is part of the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG MedMij FHIR Implementation Guide] and is a technical representation of the functional design published on this [[MedMij:V2019.01_Ontwerpen| wiki page]].

==IHE MHD specification==
Mobile access to Health Documents (MHD) profile defines a simple HTTP interface to an XDS like environment. The four described transactions leverage the document content and format agnostic metadata concepts from XDS but simplify them for access by constrained environments such as mobile devices, or other resource-constrained systems. The MHD profile does not replace XDS. It can be used to allow mobile devices, or other resource-constrained systems, access to an XDS health information exchange.[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)]

'''Wiki:'''
[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) Mobile acces to Health Document (MHD)]

'''Document:'''
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf MHD Supplement] (Rev 2.3 July 24, 2017)

'''Additional Supplement:'''
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_Appx-Z.pdf Appendix Z on HL7 FHIR]

=Actors and transactions involved=
Table 1 shows the relevant actors, systems and FHIR capability statements in a MedMij context. The capability statements demonstrate the minimum requirements to be conformant to the described use cases.

{| 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]] [https://simplifier.net/NictizSTU3-Zib2017/image-clientcapabilities CapabilityStatement: Client]
| Image FHIR Client requirements
|-
| Healthcare Provider
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/NictizSTU3-Zib2017/image-servercapabilities CapabilityStatement: Server]
| Image FHIR Server requirements
|}
'''Table 1. Actors, systems and FHIR capability statements'''

Table 2 shows the MHD actors and transactions in perspective of the systems used in a MedMij context.
{| class="wikitable"
! style="font-weight: bold; text-align:left;" | Person
! style="font-weight: bold; text-align:left;" | System
! style="font-weight: bold; text-align:left;" | Role
! style="font-weight: bold; text-align:left;" | MHD Actors - for XDS
! style="font-weight: bold; text-align:left;" | MHD Transactions - for XDS
|-
| Patient
| PHR
| Sends image to the XIS
| Document Source
| rowspan="2" |Provide Document Bundle
|-
| Healthcare provider
| XIS
| Receives image from the PHR
| Document Recipient
|}
'''Table 2. MHD actors and transactions in perspective of systems in a MedMij context'''

=Boundaries and Relationships=
The use case where an image is sent from a PHR to a XIS is influenced by the IHE MHD profile with regards to the PHR message semantics and mandatory elements. The specifications for this use case mainly deviates in the use of the FHIR Media resource instead of the DocumentReference resource. Although the DocumentResource is in line with the requirements of persisting content in a XDS network and the resource can handle images, the Media resource is more appropriate and specific for the exchange of images. The Media resource has additional, more specific, (medical related) elements compared to the DocumentReference. These are the Media's view, reasonCode, bodySite, device and to a lesser extent the height and width elements. In addition, the Media resource has a reference coming from the DiagnosticReport that may be of value for further development of the MedMij information standard for images.

A XIS can possibly act within a XDS network. The information standards in use by MedMij have the primary objective to enable standardized communication based on FHIR STU3. As a secondary objective, enabling exchange with XDS networks is taken into account. For this objective, the PHR will need to provide additional meta information to the Media resource. The additional meta information allows XIS actors to index an image properly within a XDS network. The XIS is responsible for converting the PHR message into a XDS DocumentEntry. A mapping from the Media resource to the mandatory metadata elements of the IHE MHD DocumentReference resource is provided. The IHE MHD and general IHE XDS profiles will provide the information needed to perform a successful DocumentEntry of an image.

=Use case: send image from a PHR to a XIS=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]

== Introduction ==
This use case describes the minimal required technical functionalities in order to exchange an image made by the patient to a healthcare provider. Typical process flow would be:
# Patients makes, downloads or receives an image and uploads it to his PHR.
# The PHR sends the image to the chosen XIS system.
## Potentially the patient needs to provide sufficient metadata concerning the image.
# A healthcare provider views the image in his XIS.
This use case presumes made agreements between the patient and healthcare provider. Besides a technical answer by the XIS of the healthcare provider, no answer to the patient is expected.

The following technical specifications will concern the process mentioned at point 2.

==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 Image Bundle (PUSH)
|style="background-color: white;vertical-align:top;"|Send image bundle request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends image to the XIS
|-
|style="background-color: white;vertical-align:top;"|Receive image bundle response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives image from PHR
|}

== Invocations ==
{{FHIR-IG-Afsprakenstelsel-Note}}

=== Client - PHR request===
When the patient (PHR) wants to send one or more images, it issues a send image bundle request message.

The PHR initiate a FHIR transaction using a create action by sending an HTTP POST request composed of a FHIR Bundle Resource containing one or more FHIR Media resources, zero or more Binary resources and one patient resource to the XIS Recipient. References to the FHIR specification for the required transaction and POST requests are given in the [[#Interactions.2C_operations.2C_search_parameters | interactions, operations and search parameters]] section below.

The PHR executes an HTTP POST against the XIS's base endpoint as shown below.

<pre>
POST [base] {?_format=[mime-type]}
</pre>

The PHR shall assure all FHIR resource elements are consistent with the requirements specified in the StructureDefinitions for List, Media, Device, Patient, Practitioner and Organization resources. References to these StructureDefinitions are provided in [[#List_of_StructureDefinitions | list of StructureDefinitions]].

==== Textual Requirements ====

* The Bundle.type shall be transaction.

* The Media.content.attachment.url points at the image content, which shall be in the Bundle as a Binary resource. See FHIR Resolving references in Bundles at the [http://hl7.org/fhir/STU3/bundle.html#references FHIR specification] and use within MedMij at the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG#Use_of_the_reference_datatype MedMij Use case overarching principles].

* All Media.subject values shall be References to Patient resources and shall be included in the Bundle.

* A List resource shall be used to group the images if a collection of images are sent.

* Accompanying text from the patient for the image and/or collection of images shall be placed in the Media.note and List.note respectively.

=== Examples ===
'''Message components'''
* [https://simplifier.net/nictizstu3-zib2017/media-example-eczema-comprehensive-data Media comprehensive data]
* [https://simplifier.net/nictizstu3-zib2017/media-example-eczema-minimum-data Media minimum data]
* [https://simplifier.net/nictizstu3-zib2017/binary-example Binary of image]
* [https://simplifier.net/nictizstu3-zib2017/images-list-media List of Media resources]
'''Transaction Bundle'''
* [https://simplifier.net/nictizstu3-zib2017/image-transaction-bundle Transaction Bundle containing one image]
* [https://simplifier.net/nictizstu3-zib2017/images-bundle-transaction-multiple-images Transaction Bundle containing multiple images]
* [http://hl7.org/fhir/bundle-response.xml.html Transaction Bundle response - example from the FHIR spec]

=== Server - XIS response ===
The XIS shall process the bundle atomically. If necessary for processing, the XIS shall retrieve resources referenced by absolute URLs in the FHIR Bundle Resource.

The XIS returns an HTTP Status code appropriate to the processing outcome, conforming to the transaction specification requirements as specified in the FHIR specification.

The XIS response message shall be sent when a success or error condition needs to be communicated. Success is only indicated once the image(s) is/are received and completely processed and persisted as appropriate to the XIS configuration.

To enable the PHR to know the outcome of processing the transaction, and the identities assigned to the resources by the XIS, the XIS shall return a Bundle, with type set to transaction-response, that contains one entry for each entry in the request, in the same order as received, with the Bundle.entry.response.outcome indicating the results of processing the entry. The XIS shall comply with FHIR [http://hl7.org/fhir/STU3/bundle.html#transaction-response Bundle transaction-response] and [http://hl7.org/fhir/STU3/http.html#transaction-response the HTTP transaction-response] specifications.

=== Server - XIS & XDS ===
If the receiving XIS is part of a XDS network, it will need to convert the PHR request message into a proper message for the IHE "Provide and Register Document Set-b [ITI-41]" transaction. The XIS shall create appropriate metadata from the resources in the FHIR Bundle. The PHR shall provide the minimally required metadata. A mapping is shown below to assist in the XDS entry. The FHIR Media resource is mapped to the mandatory elements in the IHE MHD Profile on "DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata". IHE MHD defined these elements as a minimum for a XDS DocumentEntry. The [https://simplifier.net/NictizSTU3-Zib2017/ImagesMedia/~mappings Media StructureDefinition] contains a mapping to this profile and to XDS DocumentEntry, the [https://simplifier.net/NictizSTU3-Zib2017/images-List/~mappings List StructureDefinition] contatins a mapping to the XDS 'Folder Metadata Attributes'. Some FHIR elements do not translate to XDS concepts; the handling of these elements is left to the implementer of the XIS.

Upon successful conversion of the FHIR Bundle to XDS metadata, the XIS shall execute the Provide and Register Document Set-b [ITI-41] transaction. The transaction result and any error or warning messages, shall be reported to the PHR. The XIS is responsible for translating the XDS response to the appropriate HTTP Status Code and FHIR OperationOutcome Resource in the Send Image Bundle Response Message.

==== Mapping Media to mandatory IHE MHD DocumentReference elements needed for XDS DocumentEntry ====

{| class="wikitable"
! style="font-weight:bold;" | IHE MHD Profile on DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata
! style="font-weight:bold;" | Media for images, used by the PHR
! style="font-weight:bold;" | Implementation notes for XIS & XDS
|-
| DocumentReference.masterIdentifier
| Media.identifier
|
|-
| DocumentReference.status
|
| Fixed value "current".
|-
| DocumentReference.type
| Media.type
| Fixed LOINC code: 72170-4 Photographic image Unspecified body region Document.
|-
| DocumentReference.class
| Media.reasonCode
| If no reasonCode is present, a fixed LOINC code 72170-4 Photographic image Unspecified body region Document can be used.
|-
| DocumentReference.subject
| Media.subject
|
|-
| DocumentReference.indexed
| Media.occurrenceDateTime
|
|-
| DocumentReference.securityLabel
| Media.meta.security
| If no value is present 'normal' should be used as default.
|-
| DocumentReference.content
| Media.content
|
|-
| DocumentReference.content.attachment
| Media.content.attachment
|
|-
| DocumentReference.content.attachment.contentType
| Media.content.attachment.contentType
| Possible media content types: JPEG, PNG, GIF, JP2.
|-
| DocumentReference.content.attachment.url
| Media.content.attachment.url
|
|-
| DocumentReference.content.attachment.size
| Media.content.attachment.size
|
|-
| DocumentReference.content.attachment.hash
| Media.content.attachment.hash
|
|-
| DocumentReference.content.format
|
| Fixed value "mimeType Sufficient".
|}

A number of fixed values can be used in indexing to a XDS network based on an image sent by a patient. These are status, type, security (if no value is given in the Media.meta.security element) and format. Below the technical representation of these fixed values is shown.

<pre>
<DocumentReference>
....
<status value="current" />
....
<type>
<coding>
<system value="http://loinc.org/" />
<code value="72170-4" />
<display value="Photographic image Unspecified body region Document" />
</coding>
</type>
....
<securityLabel>
<coding>
<system value="http://hl7.org/fhir/v3/Confidentiality" />
<code value="N" />
<display value="normal" />
</coding>
</securityLabel>
....
<format>
<system value="urn:oid:1.3.6.1.4.1.19376.1.2.3"/>
<code value="urn:ihe:iti:xds:2017:mimeTypeSufficient"/>
<display value="mimeType Sufficient"/>
</format>
....
</DocumentReference>
</pre>

{{IssueBox|'''Images.1''' Currently we mandate the PHR to provide identifiers for the Media and List, which should conform to the requirements of an identifier needed for a DocumentEntry. Should this be mandatory? Isn't this an element that a XIS should generate?}}
{{IssueBox|'''Images.2''' Media Status. A DocumentReference has a status while Media does not in STU3. Within IHE MHD only the status values 'current' and 'superseded' are used. This in combination with a relatesTo element to indicate which document is superseded. This use case does not specify how to handle superseded images. Current scope is to exchange images witouth a status indicator. Could this be a problem for XDS networks?}}
{{IssueBox|'''Images.3''' Is a 'normal' security code possible as default when no information is given by the patient?}}
{{IssueBox|'''Images.4''' Does Media.reasonCode map to DocumentReference.class / XDS classCode? Do we need the patient to mandatory provide information for this concept? Does the fixed code suggestion fits if the patient does not provide information?}}
{{IssueBox|'''Images.5''' The mapping table above only maps the mandatory elements from the DocumentReference profile. The StructureDefinitions Media en List contain all the mappings and is referenced above as well. However, should we expand this table here with additional and optional elements?}}

==Interactions, operations, search parameters==

===Interactions===
The following logical interactions are needed for this use case:
* [http://hl7.org/fhir/STU3/http.html#create Create]
* [http://hl7.org/fhir/STU3/http.html#transaction Transaction]

===Operations===
There are no defined operations for this use case.

===Search parameters===
There are no search parameters needed for this use case.

==List of StructureDefinitions==
===MedMij StructureDefinitions===

{{NoteBoxPackage|https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/1.0.0|1.0.0|MedMij:Vdraft_FHIR_IG}}

{| 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
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient]
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-practitioner http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner]
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization]
|-
| Beeld
| Image
| Media
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/structuredefinition/images-media http://nictiz.nl/fhir/StructureDefinition/images-Media]
|-
| CollectieBeelden
| CollectionImages
| List
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/StructureDefinition/images-List http://nictiz.nl/fhir/StructureDefinition/images-List]
|-
| MedischHulpmiddel.Product
| MedicalDevice.Product
| Device
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct]
|}

===IHE MHD StructureDefinitions===
IHE has defined StructureDefinitions and other Conformance resources applicable to this use case. The FHIR Implementation Guide on the '''[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide IHE MHD wiki]''' lists these StructureDefinitions.

* IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive]

* IHE MHD Profile on DocumentReference (DocumentEntry) when used in the Provide Transaction with Comprehensive (aka XDS-on-FHIR) Metadata
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference]

* IHE MHD Profile on List (Folder)
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.List http://ihe.net/fhir/StructureDefinition/IHE.MHD.List]

{{IssueBox|'''IHE.1''' Currently, we don't use or specify a profile that concerns the transaction request. (A profile like "IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata") Is such a profile nescessary? We don't use it in other MedMij use cases and the transaction bundle is described by the FHIR specification and textual in this use case.}}
{{IssueBox|'''IHE.2''' The main reason the "IHE MHD Profile on List (Folder)" is not used, is because it mandates the use of .title and .code which likely contains information a patient needs to enter manually. As we would like to keep the burden on patients as low as possible a custom profile of list is used without these mandatory elements. Additionally, one of the benefits is that we can use references to our own profiles. }}
{{IssueBox|'''IHE.3''' The IHE StructureDefinitions contain a number of errors, mentioned in this [https://chat.fhir.org/#narrow/stream/100-IHE-FHIR.20profiles/topic/IHE.20MHD.20profiles Zulip chat]. These issues will be solved in the R4 release of IHE MHD. We will likely make a pull request to address these issues for the STU3 release. .}}
{{IssueBox|'''IHE.4''' The IHE StructureDefinitions restrict the use of the .created element. This is a known issue and will be addressed in the R4 release of the profiles. This issue (CP-ITI-1100) can be found on the [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide IHE MHD wiki]. Therefore the indexed element is used to capture creation time.}}

=Annex: Document history=

==Release notes==
Release notes can be found on the [[MedMij:Vdraft_OntwerpBGZ_2017#Release_notes|functional design page]].

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 0.1.0
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"|
* Added concept version.
|-
| style="background-color: white;"| 0.2.0
| style="background-color: white;"| 11-12-2018
| style="background-color: white;"|
* Added introduction text.
|-
| style="background-color: white;"| 0.3.0
| style="background-color: white;"| 12-12-2018
| style="background-color: white;"|
* Added Boundaries and Relationships.
* Added Client - PHR request.
* Added Server - XIS response.
* Added Server - XIS & XDS.
|-
| style="background-color: white;"| 0.4.0
| style="background-color: white;"| 13-12-2018
| style="background-color: white;"|
* Added Media - DocumentReference mapping.
|-
| style="background-color: white;"| 0.5.0
| style="background-color: white;"| 19-12-2018
| style="background-color: white;"|
* Added FHIR examples and StructureDefinitions.
* Textual improvements.
|-
| style="background-color: white;"| 0.6.0
| style="background-color: white;"| 28-12-2018
| style="background-color: white;"|
* Added FHIR examples and StructureDefinitions (Transaction Bundle and List profile).
* Textual improvements.
* Added and improved open issues with issue boxes.
* Added an open public consultation issue box at the top of the page.
* Moved releas notes to the functional design main page.
|}

MedMij:Vprepub-2019.01 FHIR Images

2019-03-15T10:57:40Z

Tim Ruijters:

{{#customtitle:MedMij FHIR Implementation Guide: Images}}

{{IssueBox|This information standard is in development. Feedback gathered during the public consultation from 10-01-2019 to 21-02-2019 is being processed.

If you have any feedback, please submit it at https://bits.nictiz.nl/projects/MSIOC/}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<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:V2019.01_OntwerpBeelden|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.01_Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This page describes the exchange of images within MedMij. In contrary to other described use cases for MedMij no existing information standard fits nor are there specific ZIB models applicable. To achieve exchange of images, MedMij adopts as much as possible from existing standards, such as the DICOM standard and the Mobile access to Health Documents (MHD) profile from Integrating the Healthcare Enterprise (IHE) that defines a RESTful/HTTP interface to an [http://wiki.ihe.net/index.php/Cross-Enterprise_Document_Sharing XDS] environment using HL7 FHIR STU3 resources.

The specification currently consists of one use case, that covers sending an image by a patient to a healthcare provider. Based on future research, a use case to retrieve images by the patient will be added. Most likely, this will be based on DICOMweb™, which is the DICOM standard for web-based medical imaging based on RESTful services.

'''Note''': this page is part of the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG MedMij FHIR Implementation Guide] and is a technical representation of the functional design published on this [[MedMij:V2019.01_Ontwerpen| wiki page]].

==IHE MHD specification==
Mobile access to Health Documents (MHD) profile defines a simple HTTP interface to an XDS like environment. The four described transactions leverage the document content and format agnostic metadata concepts from XDS but simplify them for access by constrained environments such as mobile devices, or other resource-constrained systems. The MHD profile does not replace XDS. It can be used to allow mobile devices, or other resource-constrained systems, access to an XDS health information exchange.[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)]

'''Wiki:'''
[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) Mobile acces to Health Document (MHD)]

'''Document:'''
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf MHD Supplement] (Rev 2.3 July 24, 2017)

'''Additional Supplement:'''
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_Appx-Z.pdf Appendix Z on HL7 FHIR]

=Actors and transactions involved=
Table 1 shows the relevant actors, systems and FHIR capability statements in a MedMij context. The capability statements demonstrate the minimum requirements to be conformant to the described use cases.

{| 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]] [https://simplifier.net/NictizSTU3-Zib2017/image-clientcapabilities CapabilityStatement: Client]
| Image FHIR Client requirements
|-
| Healthcare Provider
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/NictizSTU3-Zib2017/image-servercapabilities CapabilityStatement: Server]
| Image FHIR Server requirements
|}
'''Table 1. Actors, systems and FHIR capability statements'''

Table 2 shows the MHD actors and transactions in perspective of the systems used in a MedMij context.
{| class="wikitable"
! style="font-weight: bold; text-align:left;" | Person
! style="font-weight: bold; text-align:left;" | System
! style="font-weight: bold; text-align:left;" | Role
! style="font-weight: bold; text-align:left;" | MHD Actors - for XDS
! style="font-weight: bold; text-align:left;" | MHD Transactions - for XDS
|-
| Patient
| PHR
| Sends image to the XIS
| Document Source
| rowspan="2" |Provide Document Bundle
|-
| Healthcare provider
| XIS
| Receives image from the PHR
| Document Recipient
|}
'''Table 2. MHD actors and transactions in perspective of systems in a MedMij context'''

=Boundaries and Relationships=
The use case where an image is sent from a PHR to a XIS is influenced by the IHE MHD profile with regards to the PHR message semantics and mandatory elements. The specifications for this use case mainly deviates in the use of the FHIR Media resource instead of the DocumentReference resource. Although the DocumentResource is in line with the requirements of persisting content in a XDS network and the resource can handle images, the Media resource is more appropriate and specific for the exchange of images. The Media resource has additional, more specific, (medical related) elements compared to the DocumentReference. These are the Media's view, reasonCode, bodySite, device and to a lesser extent the height and width elements. In addition, the Media resource has a reference coming from the DiagnosticReport that may be of value for further development of the MedMij information standard for images.

A XIS can possibly act within a XDS network. The information standards in use by MedMij have the primary objective to enable standardized communication based on FHIR STU3. As a secondary objective, enabling exchange with XDS networks is taken into account. For this objective, the PHR will need to provide additional meta information to the Media resource. The additional meta information allows XIS actors to index an image properly within a XDS network. The XIS is responsible for converting the PHR message into a XDS DocumentEntry. A mapping from the Media resource to the mandatory metadata elements of the IHE MHD DocumentReference resource is provided. The IHE MHD and general IHE XDS profiles will provide the information needed to perform a successful DocumentEntry of an image.

=Use case: send image from a PHR to a XIS=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]

== Introduction ==
This use case describes the minimal required technical functionalities in order to exchange an image made by the patient to a healthcare provider. Typical process flow would be:
# Patients makes, downloads or receives an image and uploads it to his PHR.
# The PHR sends the image to the chosen XIS system.
## Potentially the patient needs to provide sufficient metadata concerning the image.
# A healthcare provider views the image in his XIS.
This use case presumes made agreements between the patient and healthcare provider. Besides a technical answer by the XIS of the healthcare provider, no answer to the patient is expected.

The following technical specifications will concern the process mentioned at point 2.

==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 Image Bundle (PUSH)
|style="background-color: white;vertical-align:top;"|Send image bundle request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends image to the XIS
|-
|style="background-color: white;vertical-align:top;"|Receive image bundle response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives image from PHR
|}

== Invocations ==
{{FHIR-IG-Afsprakenstelsel-Note}}

=== Client - PHR request===
When the patient (PHR) wants to send one or more images, it issues a send image bundle request message.

The PHR initiate a FHIR transaction using a create action by sending an HTTP POST request composed of a FHIR Bundle Resource containing one or more FHIR Media resources, zero or more Binary resources and one patient resource to the XIS Recipient. References to the FHIR specification for the required transaction and POST requests are given in the [[#Interactions.2C_operations.2C_search_parameters | interactions, operations and search parameters]] section below.

The PHR executes an HTTP POST against the XIS's base endpoint as shown below.

<pre>
POST [base] {?_format=[mime-type]}
</pre>

The PHR shall assure all FHIR resource elements are consistent with the requirements specified in the StructureDefinitions for List, Media, Device, Patient, Practitioner and Organization resources. References to these StructureDefinitions are provided in [[#List_of_StructureDefinitions | list of StructureDefinitions]].

==== Textual Requirements ====

* The Bundle.type shall be transaction.

* The Media.content.attachment.url points at the image content, which shall be in the Bundle as a Binary resource. See FHIR Resolving references in Bundles at the [http://hl7.org/fhir/STU3/bundle.html#references FHIR specification] and use within MedMij at the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG#Use_of_the_reference_datatype MedMij Use case overarching principles].

* All Media.subject values shall be References to Patient resources and shall be included in the Bundle.

* A List resource shall be used to group the images if a collection of images are sent.

* Accompanying text from the patient for the image and/or collection of images shall be placed in the Media.note and List.note respectively.

=== Examples ===
'''Message components'''
* [https://simplifier.net/nictizstu3-zib2017/media-example-eczema-comprehensive-data Media comprehensive data]
* [https://simplifier.net/nictizstu3-zib2017/media-example-eczema-minimum-data Media minimum data]
* [https://simplifier.net/nictizstu3-zib2017/binary-example Binary of image]
* [https://simplifier.net/nictizstu3-zib2017/images-list-media List of Media resources]
'''Transaction Bundle'''
* [https://simplifier.net/nictizstu3-zib2017/image-transaction-bundle Transaction Bundle containing one image]
* [https://simplifier.net/nictizstu3-zib2017/images-bundle-transaction-multiple-images Transaction Bundle containing multiple images]
* [http://hl7.org/fhir/bundle-response.xml.html Transaction Bundle response - example from the FHIR spec]

=== Server - XIS response ===
The XIS shall process the bundle atomically. If necessary for processing, the XIS shall retrieve resources referenced by absolute URLs in the FHIR Bundle Resource.

The XIS returns an HTTP Status code appropriate to the processing outcome, conforming to the transaction specification requirements as specified in the FHIR specification.

The XIS response message shall be sent when a success or error condition needs to be communicated. Success is only indicated once the image(s) is/are received and completely processed and persisted as appropriate to the XIS configuration.

To enable the PHR to know the outcome of processing the transaction, and the identities assigned to the resources by the XIS, the XIS shall return a Bundle, with type set to transaction-response, that contains one entry for each entry in the request, in the same order as received, with the Bundle.entry.response.outcome indicating the results of processing the entry. The XIS shall comply with FHIR [http://hl7.org/fhir/STU3/bundle.html#transaction-response Bundle transaction-response] and [http://hl7.org/fhir/STU3/http.html#transaction-response the HTTP transaction-response] specifications.

=== Server - XIS & XDS ===
If the receiving XIS is part of a XDS network, it will need to convert the PHR request message into a proper message for the IHE "Provide and Register Document Set-b [ITI-41]" transaction. The XIS shall create appropriate metadata from the resources in the FHIR Bundle. The PHR shall provide the minimally required metadata. A mapping is shown below to assist in the XDS entry. The FHIR Media resource is mapped to the mandatory elements in the IHE MHD Profile on "DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata". IHE MHD defined these elements as a minimum for a XDS DocumentEntry. The [https://simplifier.net/NictizSTU3-Zib2017/ImagesMedia/~mappings Media StructureDefinition] contains a mapping to this profile and to XDS DocumentEntry, the [https://simplifier.net/NictizSTU3-Zib2017/images-List/~mappings List StructureDefinition] contatins a mapping to the XDS 'Folder Metadata Attributes'. Some FHIR elements do not translate to XDS concepts; the handling of these elements is left to the implementer of the XIS.

Upon successful conversion of the FHIR Bundle to XDS metadata, the XIS shall execute the Provide and Register Document Set-b [ITI-41] transaction. The transaction result and any error or warning messages, shall be reported to the PHR. The XIS is responsible for translating the XDS response to the appropriate HTTP Status Code and FHIR OperationOutcome Resource in the Send Image Bundle Response Message.

==== Mapping Media to mandatory IHE MHD DocumentReference elements needed for XDS DocumentEntry ====

{| class="wikitable"
! style="font-weight:bold;" | IHE MHD Profile on DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata
! style="font-weight:bold;" | Media for images, used by the PHR
! style="font-weight:bold;" | Implementation notes for XIS & XDS
|-
| DocumentReference.masterIdentifier
| Media.identifier
|
|-
| DocumentReference.status
|
| Fixed value "current".
|-
| DocumentReference.type
| Media.type
| Fixed LOINC code: 72170-4 Photographic image Unspecified body region Document.
|-
| DocumentReference.class
| Media.reasonCode
| If no reasonCode is present, a fixed LOINC code 72170-4 Photographic image Unspecified body region Document can be used.
|-
| DocumentReference.subject
| Media.subject
|
|-
| DocumentReference.indexed
| Media.occurrenceDateTime
|
|-
| DocumentReference.securityLabel
| Media.meta.security
| If no value is present 'normal' should be used as default.
|-
| DocumentReference.content
| Media.content
|
|-
| DocumentReference.content.attachment
| Media.content.attachment
|
|-
| DocumentReference.content.attachment.contentType
| Media.content.attachment.contentType
| Possible media content types: JPEG, PNG, GIF, JP2.
|-
| DocumentReference.content.attachment.url
| Media.content.attachment.url
|
|-
| DocumentReference.content.attachment.size
| Media.content.attachment.size
|
|-
| DocumentReference.content.attachment.hash
| Media.content.attachment.hash
|
|-
| DocumentReference.content.format
|
| Fixed value "mimeType Sufficient".
|}

A number of fixed values can be used in indexing to a XDS network based on an image sent by a patient. These are status, type, security (if no value is given in the Media.meta.security element) and format. Below the technical representation of these fixed values is shown.

<pre>
<DocumentReference>
....
<status value="current" />
....
<type>
<coding>
<system value="http://loinc.org/" />
<code value="72170-4" />
<display value="Photographic image Unspecified body region Document" />
</coding>
</type>
....
<securityLabel>
<coding>
<system value="http://hl7.org/fhir/v3/Confidentiality" />
<code value="N" />
<display value="normal" />
</coding>
</securityLabel>
....
<format>
<system value="urn:oid:1.3.6.1.4.1.19376.1.2.3"/>
<code value="urn:ihe:iti:xds:2017:mimeTypeSufficient"/>
<display value="mimeType Sufficient"/>
</format>
....
</DocumentReference>
</pre>

{{IssueBox|'''Images.1''' Currently we mandate the PHR to provide identifiers for the Media and List, which should conform to the requirements of an identifier needed for a DocumentEntry. Should this be mandatory? Isn't this an element that a XIS should generate?}}
{{IssueBox|'''Images.2''' Media Status. A DocumentReference has a status while Media does not in STU3. Within IHE MHD only the status values 'current' and 'superseded' are used. This in combination with a relatesTo element to indicate which document is superseded. This use case does not specify how to handle superseded images. Current scope is to exchange images witouth a status indicator. Could this be a problem for XDS networks?}}
{{IssueBox|'''Images.3''' Is a 'normal' security code possible as default when no information is given by the patient?}}
{{IssueBox|'''Images.4''' Does Media.reasonCode map to DocumentReference.class / XDS classCode? Do we need the patient to mandatory provide information for this concept? Does the fixed code suggestion fits if the patient does not provide information?}}
{{IssueBox|'''Images.5''' The mapping table above only maps the mandatory elements from the DocumentReference profile. The StructureDefinitions Media en List contain all the mappings and is referenced above as well. However, should we expand this table here with additional and optional elements?}}

==Interactions, operations, search parameters==

===Interactions===
The following logical interactions are needed for this use case:
* [http://hl7.org/fhir/STU3/http.html#create Create]
* [http://hl7.org/fhir/STU3/http.html#transaction Transaction]

===Operations===
There are no defined operations for this use case.

===Search parameters===
There are no search parameters needed for this use case.

==List of StructureDefinitions==
===MedMij StructureDefinitions===

{{NoteBoxPackage|https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/1.0.0|1.0.0|MedMij:Vdraft_FHIR_IG}}

{| 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
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient]
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-practitioner http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner]
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization]
|-
| Beeld
| Image
| Media
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/structuredefinition/images-media http://nictiz.nl/fhir/StructureDefinition/images-Media]
|-
| CollectieBeelden
| CollectionImages
| List
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/StructureDefinition/images-List http://nictiz.nl/fhir/StructureDefinition/images-List]
|-
| MedischHulpmiddel.Product
| MedicalDevice.Product
| Device
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct]
|}

===IHE MHD StructureDefinitions===
IHE has defined StructureDefinitions and other Conformance resources applicable to this use case. The FHIR Implementation Guide on the '''[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide IHE MHD wiki]''' lists these StructureDefinitions.

* IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive]

* IHE MHD Profile on DocumentReference (DocumentEntry) when used in the Provide Transaction with Comprehensive (aka XDS-on-FHIR) Metadata
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference]

* IHE MHD Profile on List (Folder)
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.List http://ihe.net/fhir/StructureDefinition/IHE.MHD.List]

{{IssueBox|'''IHE.1''' Currently, we don't use or specify a profile that concerns the transaction request. (A profile like "IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata") Is such a profile nescessary? We don't use it in other MedMij use cases and the transaction bundle is described by the FHIR specification and textual in this use case.}}
{{IssueBox|'''IHE.2''' The main reason the "IHE MHD Profile on List (Folder)" is not used, is because it mandates the use of .title and .code which likely contains information a patient needs to enter manually. As we would like to keep the burden on patients as low as possible a custom profile of list is used without these mandatory elements. Additionally, one of the benefits is that we can use references to our own profiles. }}
{{IssueBox|'''IHE.3''' The IHE StructureDefinitions contain a number of errors, mentioned in this [https://chat.fhir.org/#narrow/stream/100-IHE-FHIR.20profiles/topic/IHE.20MHD.20profiles Zulip chat]. These issues will be solved in the R4 release of IHE MHD. We will likely make a pull request to address these issues for the STU3 release. .}}
{{IssueBox|'''IHE.4''' The IHE StructureDefinitions restrict the use of the .created element. This is a known issue and will be addressed in the R4 release of the profiles. This issue (CP-ITI-1100) can be found on the [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide IHE MHD wiki]. Therefore the indexed element is used to capture creation time.}}

=Annex: Document history=

==Release notes==
Release notes can be found on the [[MedMij:Vdraft_OntwerpBGZ_2017#Release_notes|functional design page]].

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 0.1.0
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"|
* Added concept version.
|-
| style="background-color: white;"| 0.2.0
| style="background-color: white;"| 11-12-2018
| style="background-color: white;"|
* Added introduction text.
|-
| style="background-color: white;"| 0.3.0
| style="background-color: white;"| 12-12-2018
| style="background-color: white;"|
* Added Boundaries and Relationships.
* Added Client - PHR request.
* Added Server - XIS response.
* Added Server - XIS & XDS.
|-
| style="background-color: white;"| 0.4.0
| style="background-color: white;"| 13-12-2018
| style="background-color: white;"|
* Added Media - DocumentReference mapping.
|-
| style="background-color: white;"| 0.5.0
| style="background-color: white;"| 19-12-2018
| style="background-color: white;"|
* Added FHIR examples and StructureDefinitions.
* Textual improvements.
|-
| style="background-color: white;"| 0.6.0
| style="background-color: white;"| 28-12-2018
| style="background-color: white;"|
* Added FHIR examples and StructureDefinitions (Transaction Bundle and List profile).
* Textual improvements.
* Added and improved open issues with issue boxes.
* Added an open public consultation issue box at the top of the page.
* Moved releas notes to the functional design main page.
|}

MedMij:V2019.01 FHIR Images

2019-03-15T10:29:07Z

Tim Ruijters:

{{#customtitle:MedMij FHIR Implementation Guide: Images 1.0.0}}

{{IssueBox|This information standard is in development. Feedback gathered during the public consultation from 10-01-2019 to 21-02-2019 is being processed.

If you have any feedback, please submit it at https://bits.nictiz.nl/projects/MSIOC/}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<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:V2019.01_OntwerpBeelden|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.01_Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This page describes the exchange of images within MedMij. In contrary to other described use cases for MedMij no existing information standard fits nor are there specific ZIB models applicable. To achieve exchange of images, MedMij adopts as much as possible from existing standards, such as the DICOM standard and the Mobile access to Health Documents (MHD) profile from Integrating the Healthcare Enterprise (IHE) that defines a RESTful/HTTP interface to an [http://wiki.ihe.net/index.php/Cross-Enterprise_Document_Sharing XDS] environment using HL7 FHIR STU3 resources.

The specification currently consists of one use case, that covers sending an image by a patient to a healthcare provider. Based on future research, a use case to retrieve images by the patient will be added. Most likely, this will be based on DICOMweb™, which is the DICOM standard for web-based medical imaging based on RESTful services.

'''Note''': this page is part of the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG MedMij FHIR Implementation Guide] and is a technical representation of the functional design published on this [[MedMij:V2019.01_Ontwerpen| wiki page]].

==IHE MHD specification==
Mobile access to Health Documents (MHD) profile defines a simple HTTP interface to an XDS like environment. The four described transactions leverage the document content and format agnostic metadata concepts from XDS but simplify them for access by constrained environments such as mobile devices, or other resource-constrained systems. The MHD profile does not replace XDS. It can be used to allow mobile devices, or other resource-constrained systems, access to an XDS health information exchange.[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)]

'''Wiki:'''
[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) Mobile acces to Health Document (MHD)]

'''Document:'''
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf MHD Supplement] (Rev 2.3 July 24, 2017)

'''Additional Supplement:'''
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_Appx-Z.pdf Appendix Z on HL7 FHIR]

=Actors and transactions involved=
Table 1 shows the relevant actors, systems and FHIR capability statements in a MedMij context. The capability statements demonstrate the minimum requirements to be conformant to the described use cases.

{| 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]] [https://simplifier.net/NictizSTU3-Zib2017/image-clientcapabilities CapabilityStatement: Client]
| Image FHIR Client requirements
|-
| Healthcare Provider
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/NictizSTU3-Zib2017/image-servercapabilities CapabilityStatement: Server]
| Image FHIR Server requirements
|}
'''Table 1. Actors, systems and FHIR capability statements'''

Table 2 shows the MHD actors and transactions in perspective of the systems used in a MedMij context.
{| class="wikitable"
! style="font-weight: bold; text-align:left;" | Person
! style="font-weight: bold; text-align:left;" | System
! style="font-weight: bold; text-align:left;" | Role
! style="font-weight: bold; text-align:left;" | MHD Actors - for XDS
! style="font-weight: bold; text-align:left;" | MHD Transactions - for XDS
|-
| Patient
| PHR
| Sends image to the XIS
| Document Source
| rowspan="2" |Provide Document Bundle
|-
| Healthcare provider
| XIS
| Receives image from the PHR
| Document Recipient
|}
'''Table 2. MHD actors and transactions in perspective of systems in a MedMij context'''

=Boundaries and Relationships=
The use case where an image is sent from a PHR to a XIS is influenced by the IHE MHD profile with regards to the PHR message semantics and mandatory elements. The specifications for this use case mainly deviates in the use of the FHIR Media resource instead of the DocumentReference resource. Although the DocumentResource is in line with the requirements of persisting content in a XDS network and the resource can handle images, the Media resource is more appropriate and specific for the exchange of images. The Media resource has additional, more specific, (medical related) elements compared to the DocumentReference. These are the Media's view, reasonCode, bodySite, device and to a lesser extent the height and width elements. In addition, the Media resource has a reference coming from the DiagnosticReport that may be of value for further development of the MedMij information standard for images.

A XIS can possibly act within a XDS network. The information standards in use by MedMij have the primary objective to enable standardized communication based on FHIR STU3. As a secondary objective, enabling exchange with XDS networks is taken into account. For this objective, the PHR will need to provide additional meta information to the Media resource. The additional meta information allows XIS actors to index an image properly within a XDS network. The XIS is responsible for converting the PHR message into a XDS DocumentEntry. A mapping from the Media resource to the mandatory metadata elements of the IHE MHD DocumentReference resource is provided. The IHE MHD and general IHE XDS profiles will provide the information needed to perform a successful DocumentEntry of an image.

=Use case: send image from a PHR to a XIS=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]

== Introduction ==
This use case describes the minimal required technical functionalities in order to exchange an image made by the patient to a healthcare provider. Typical process flow would be:
# Patients makes, downloads or receives an image and uploads it to his PHR.
# The PHR sends the image to the chosen XIS system.
## Potentially the patient needs to provide sufficient metadata concerning the image.
# A healthcare provider views the image in his XIS.
This use case presumes made agreements between the patient and healthcare provider. Besides a technical answer by the XIS of the healthcare provider, no answer to the patient is expected.

The following technical specifications will concern the process mentioned at point 2.

==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 Image Bundle (PUSH)
|style="background-color: white;vertical-align:top;"|Send image bundle request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends image to the XIS
|-
|style="background-color: white;vertical-align:top;"|Receive image bundle response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives image from PHR
|}

== Invocations ==
{{FHIR-IG-Afsprakenstelsel-Note}}

=== Client - PHR request===
When the patient (PHR) wants to send one or more images, it issues a send image bundle request message.

The PHR initiate a FHIR transaction using a create action by sending an HTTP POST request composed of a FHIR Bundle Resource containing one or more FHIR Media resources, zero or more Binary resources and one patient resource to the XIS Recipient. References to the FHIR specification for the required transaction and POST requests are given in the [[#Interactions.2C_operations.2C_search_parameters | interactions, operations and search parameters]] section below.

The PHR executes an HTTP POST against the XIS's base endpoint as shown below.

<pre>
POST [base] {?_format=[mime-type]}
</pre>

The PHR shall assure all FHIR resource elements are consistent with the requirements specified in the StructureDefinitions for List, Media, Device, Patient, Practitioner and Organization resources. References to these StructureDefinitions are provided in [[#List_of_StructureDefinitions | list of StructureDefinitions]].

==== Textual Requirements ====

* The Bundle.type shall be transaction.

* The Media.content.attachment.url points at the image content, which shall be in the Bundle as a Binary resource. See FHIR Resolving references in Bundles at the [http://hl7.org/fhir/STU3/bundle.html#references FHIR specification] and use within MedMij at the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG#Use_of_the_reference_datatype MedMij Use case overarching principles].

* All Media.subject values shall be References to Patient resources and shall be included in the Bundle.

* A List resource shall be used to group the images if a collection of images are sent.

* Accompanying text from the patient for the image and/or collection of images shall be placed in the Media.note and List.note respectively.

=== Examples ===
'''Message components'''
* [https://simplifier.net/nictizstu3-zib2017/media-example-eczema-comprehensive-data Media comprehensive data]
* [https://simplifier.net/nictizstu3-zib2017/media-example-eczema-minimum-data Media minimum data]
* [https://simplifier.net/nictizstu3-zib2017/binary-example Binary of image]
* [https://simplifier.net/nictizstu3-zib2017/images-list-media List of Media resources]
'''Transaction Bundle'''
* [https://simplifier.net/nictizstu3-zib2017/image-transaction-bundle Transaction Bundle containing one image]
* [https://simplifier.net/nictizstu3-zib2017/images-bundle-transaction-multiple-images Transaction Bundle containing multiple images]
* [http://hl7.org/fhir/bundle-response.xml.html Transaction Bundle response - example from the FHIR spec]

=== Server - XIS response ===
The XIS shall process the bundle atomically. If necessary for processing, the XIS shall retrieve resources referenced by absolute URLs in the FHIR Bundle Resource.

The XIS returns an HTTP Status code appropriate to the processing outcome, conforming to the transaction specification requirements as specified in the FHIR specification.

The XIS response message shall be sent when a success or error condition needs to be communicated. Success is only indicated once the image(s) is/are received and completely processed and persisted as appropriate to the XIS configuration.

To enable the PHR to know the outcome of processing the transaction, and the identities assigned to the resources by the XIS, the XIS shall return a Bundle, with type set to transaction-response, that contains one entry for each entry in the request, in the same order as received, with the Bundle.entry.response.outcome indicating the results of processing the entry. The XIS shall comply with FHIR [http://hl7.org/fhir/STU3/bundle.html#transaction-response Bundle transaction-response] and [http://hl7.org/fhir/STU3/http.html#transaction-response the HTTP transaction-response] specifications.

=== Server - XIS & XDS ===
If the receiving XIS is part of a XDS network, it will need to convert the PHR request message into a proper message for the IHE "Provide and Register Document Set-b [ITI-41]" transaction. The XIS shall create appropriate metadata from the resources in the FHIR Bundle. The PHR shall provide the minimally required metadata. A mapping is shown below to assist in the XDS entry. The FHIR Media resource is mapped to the mandatory elements in the IHE MHD Profile on "DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata". IHE MHD defined these elements as a minimum for a XDS DocumentEntry. The [https://simplifier.net/NictizSTU3-Zib2017/ImagesMedia/~mappings Media StructureDefinition] contains a mapping to this profile and to XDS DocumentEntry, the [https://simplifier.net/NictizSTU3-Zib2017/images-List/~mappings List StructureDefinition] contatins a mapping to the XDS 'Folder Metadata Attributes'. Some FHIR elements do not translate to XDS concepts; the handling of these elements is left to the implementer of the XIS.

Upon successful conversion of the FHIR Bundle to XDS metadata, the XIS shall execute the Provide and Register Document Set-b [ITI-41] transaction. The transaction result and any error or warning messages, shall be reported to the PHR. The XIS is responsible for translating the XDS response to the appropriate HTTP Status Code and FHIR OperationOutcome Resource in the Send Image Bundle Response Message.

==== Mapping Media to mandatory IHE MHD DocumentReference elements needed for XDS DocumentEntry ====

{| class="wikitable"
! style="font-weight:bold;" | IHE MHD Profile on DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata
! style="font-weight:bold;" | Media for images, used by the PHR
! style="font-weight:bold;" | Implementation notes for XIS & XDS
|-
| DocumentReference.masterIdentifier
| Media.identifier
|
|-
| DocumentReference.status
|
| Fixed value "current".
|-
| DocumentReference.type
| Media.type
| Fixed LOINC code: 72170-4 Photographic image Unspecified body region Document.
|-
| DocumentReference.class
| Media.reasonCode
| If no reasonCode is present, a fixed LOINC code 72170-4 Photographic image Unspecified body region Document can be used.
|-
| DocumentReference.subject
| Media.subject
|
|-
| DocumentReference.indexed
| Media.occurrenceDateTime
|
|-
| DocumentReference.securityLabel
| Media.meta.security
| If no value is present 'normal' should be used as default.
|-
| DocumentReference.content
| Media.content
|
|-
| DocumentReference.content.attachment
| Media.content.attachment
|
|-
| DocumentReference.content.attachment.contentType
| Media.content.attachment.contentType
| Possible media content types: JPEG, PNG, GIF, JP2.
|-
| DocumentReference.content.attachment.url
| Media.content.attachment.url
|
|-
| DocumentReference.content.attachment.size
| Media.content.attachment.size
|
|-
| DocumentReference.content.attachment.hash
| Media.content.attachment.hash
|
|-
| DocumentReference.content.format
|
| Fixed value "mimeType Sufficient".
|}

A number of fixed values can be used in indexing to a XDS network based on an image sent by a patient. These are status, type, security (if no value is given in the Media.meta.security element) and format. Below the technical representation of these fixed values is shown.

<pre>
<DocumentReference>
....
<status value="current" />
....
<type>
<coding>
<system value="http://loinc.org/" />
<code value="72170-4" />
<display value="Photographic image Unspecified body region Document" />
</coding>
</type>
....
<securityLabel>
<coding>
<system value="http://hl7.org/fhir/v3/Confidentiality" />
<code value="N" />
<display value="normal" />
</coding>
</securityLabel>
....
<format>
<system value="urn:oid:1.3.6.1.4.1.19376.1.2.3"/>
<code value="urn:ihe:iti:xds:2017:mimeTypeSufficient"/>
<display value="mimeType Sufficient"/>
</format>
....
</DocumentReference>
</pre>

{{IssueBox|'''Images.1''' Currently we mandate the PHR to provide identifiers for the Media and List, which should conform to the requirements of an identifier needed for a DocumentEntry. Should this be mandatory? Isn't this an element that a XIS should generate?}}
{{IssueBox|'''Images.2''' Media Status. A DocumentReference has a status while Media does not in STU3. Within IHE MHD only the status values 'current' and 'superseded' are used. This in combination with a relatesTo element to indicate which document is superseded. This use case does not specify how to handle superseded images. Current scope is to exchange images witouth a status indicator. Could this be a problem for XDS networks?}}
{{IssueBox|'''Images.3''' Is a 'normal' security code possible as default when no information is given by the patient?}}
{{IssueBox|'''Images.4''' Does Media.reasonCode map to DocumentReference.class / XDS classCode? Do we need the patient to mandatory provide information for this concept? Does the fixed code suggestion fits if the patient does not provide information?}}
{{IssueBox|'''Images.5''' The mapping table above only maps the mandatory elements from the DocumentReference profile. The StructureDefinitions Media en List contain all the mappings and is referenced above as well. However, should we expand this table here with additional and optional elements?}}

==Interactions, operations, search parameters==

===Interactions===
The following logical interactions are needed for this use case:
* [http://hl7.org/fhir/STU3/http.html#create Create]
* [http://hl7.org/fhir/STU3/http.html#transaction Transaction]

===Operations===
There are no defined operations for this use case.

===Search parameters===
There are no search parameters needed for this use case.

==List of StructureDefinitions==
===MedMij StructureDefinitions===

{{NoteBoxPackage|https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/1.0.0|1.0.0|MedMij:Vdraft_FHIR_IG}}

{| 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
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient]
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-practitioner http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner]
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization]
|-
| Beeld
| Image
| Media
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/structuredefinition/images-media http://nictiz.nl/fhir/StructureDefinition/images-Media]
|-
| CollectieBeelden
| CollectionImages
| List
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/StructureDefinition/images-List http://nictiz.nl/fhir/StructureDefinition/images-List]
|-
| MedischHulpmiddel.Product
| MedicalDevice.Product
| Device
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct]
|}

===IHE MHD StructureDefinitions===
IHE has defined StructureDefinitions and other Conformance resources applicable to this use case. The FHIR Implementation Guide on the '''[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide IHE MHD wiki]''' lists these StructureDefinitions.

* IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive]

* IHE MHD Profile on DocumentReference (DocumentEntry) when used in the Provide Transaction with Comprehensive (aka XDS-on-FHIR) Metadata
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference]

* IHE MHD Profile on List (Folder)
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.List http://ihe.net/fhir/StructureDefinition/IHE.MHD.List]

{{IssueBox|'''IHE.1''' Currently, we don't use or specify a profile that concerns the transaction request. (A profile like "IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata") Is such a profile nescessary? We don't use it in other MedMij use cases and the transaction bundle is described by the FHIR specification and textual in this use case.}}
{{IssueBox|'''IHE.2''' The main reason the "IHE MHD Profile on List (Folder)" is not used, is because it mandates the use of .title and .code which likely contains information a patient needs to enter manually. As we would like to keep the burden on patients as low as possible a custom profile of list is used without these mandatory elements. Additionally, one of the benefits is that we can use references to our own profiles. }}
{{IssueBox|'''IHE.3''' The IHE StructureDefinitions contain a number of errors, mentioned in this [https://chat.fhir.org/#narrow/stream/100-IHE-FHIR.20profiles/topic/IHE.20MHD.20profiles Zulip chat]. These issues will be solved in the R4 release of IHE MHD. We will likely make a pull request to address these issues for the STU3 release. .}}
{{IssueBox|'''IHE.4''' The IHE StructureDefinitions restrict the use of the .created element. This is a known issue and will be addressed in the R4 release of the profiles. This issue (CP-ITI-1100) can be found on the [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide IHE MHD wiki]. Therefore the indexed element is used to capture creation time.}}

=Annex: Document history=

==Release notes==
Release notes can be found on the [[MedMij:Vdraft_OntwerpBGZ_2017#Release_notes|functional design page]].

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 0.1.0
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"|
* Added concept version.
|-
| style="background-color: white;"| 0.2.0
| style="background-color: white;"| 11-12-2018
| style="background-color: white;"|
* Added introduction text.
|-
| style="background-color: white;"| 0.3.0
| style="background-color: white;"| 12-12-2018
| style="background-color: white;"|
* Added Boundaries and Relationships.
* Added Client - PHR request.
* Added Server - XIS response.
* Added Server - XIS & XDS.
|-
| style="background-color: white;"| 0.4.0
| style="background-color: white;"| 13-12-2018
| style="background-color: white;"|
* Added Media - DocumentReference mapping.
|-
| style="background-color: white;"| 0.5.0
| style="background-color: white;"| 19-12-2018
| style="background-color: white;"|
* Added FHIR examples and StructureDefinitions.
* Textual improvements.
|-
| style="background-color: white;"| 0.6.0
| style="background-color: white;"| 28-12-2018
| style="background-color: white;"|
* Added FHIR examples and StructureDefinitions (Transaction Bundle and List profile).
* Textual improvements.
* Added and improved open issues with issue boxes.
* Added an open public consultation issue box at the top of the page.
* Moved releas notes to the functional design main page.
|}

MedMij:Vprepub-2019.01 FHIR Images

2019-03-15T10:29:07Z

Tim Ruijters:

MedMij:V2019.01 FHIR Images

2019-03-15T10:26:27Z

Tim Ruijters:

{{#customtitle:MedMij FHIR Implementation Guide: Images 1.0.0}}

{{IssueBox|This information standard is in development. Feedback gathered during the public consultation from 10-01-2019 to 21-02-2019 is being processed.

If you have any feedback, please submit it at https://bits.nictiz.nl/projects/MSIOC/}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<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:V2019.01_OntwerpBeelden|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.01_Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This page describes the exchange of images within MedMij. In contrary to other described use cases for MedMij no existing information standard fits nor are there specific ZIB models applicable. To achieve exchange of images, MedMij adopts as much as possible from existing standards, such as the DICOM standard and the Mobile access to Health Documents (MHD) profile from Integrating the Healthcare Enterprise (IHE) that defines a RESTful/HTTP interface to an [http://wiki.ihe.net/index.php/Cross-Enterprise_Document_Sharing XDS] environment using HL7 FHIR STU3 resources.

The specification currently consists of one use case, that covers sending an image by a patient to a healthcare provider. Based on future research, a use case to retrieve images by the patient will be added. Most likely, this will be based on DICOMweb™, which is the DICOM standard for web-based medical imaging based on RESTful services.

'''Note''': this page is part of the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG MedMij FHIR Implementation Guide] and is a technical representation of the functional design published on this [[MedMij:V2019.01_Ontwerpen| wiki page]].

==IHE MHD specification==
Mobile access to Health Documents (MHD) profile defines a simple HTTP interface to an XDS like environment. The four described transactions leverage the document content and format agnostic metadata concepts from XDS but simplify them for access by constrained environments such as mobile devices, or other resource-constrained systems. The MHD profile does not replace XDS. It can be used to allow mobile devices, or other resource-constrained systems, access to an XDS health information exchange.[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)]

'''Wiki:'''
[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) Mobile acces to Health Document (MHD)]

'''Document:'''
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf MHD Supplement] (Rev 2.3 July 24, 2017)

'''Additional Supplement:'''
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_Appx-Z.pdf Appendix Z on HL7 FHIR]

=Actors and transactions involved=
Table 1 shows the relevant actors, systems and FHIR capability statements in a MedMij context. The capability statements demonstrate the minimum requirements to be conformant to the described use cases.

{| 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]] [https://simplifier.net/NictizSTU3-Zib2017/image-clientcapabilities CapabilityStatement: Client]
| Image FHIR Client requirements
|-
| Healthcare Provider
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/NictizSTU3-Zib2017/image-servercapabilities CapabilityStatement: Server]
| Image FHIR Server requirements
|}
'''Table 1. Actors, systems and FHIR capability statements'''

Table 2 shows the MHD actors and transactions in perspective of the systems used in a MedMij context.
{| class="wikitable"
! style="font-weight: bold; text-align:left;" | Person
! style="font-weight: bold; text-align:left;" | System
! style="font-weight: bold; text-align:left;" | Role
! style="font-weight: bold; text-align:left;" | MHD Actors - for XDS
! style="font-weight: bold; text-align:left;" | MHD Transactions - for XDS
|-
| Patient
| PHR
| Sends image to the XIS
| Document Source
| rowspan="2" |Provide Document Bundle
|-
| Healthcare provider
| XIS
| Receives image from the PHR
| Document Recipient
|}
'''Table 2. MHD actors and transactions in perspective of systems in a MedMij context'''

=Boundaries and Relationships=
The use case where an image is sent from a PHR to a XIS is influenced by the IHE MHD profile with regards to the PHR message semantics and mandatory elements. The specifications for this use case mainly deviates in the use of the FHIR Media resource instead of the DocumentReference resource. Although the DocumentResource is in line with the requirements of persisting content in a XDS network and the resource can handle images, the Media resource is more appropriate and specific for the exchange of images. The Media resource has additional, more specific, (medical related) elements compared to the DocumentReference. These are the Media's view, reasonCode, bodySite, device and to a lesser extent the height and width elements. In addition, the Media resource has a reference coming from the DiagnosticReport that may be of value for further development of the MedMij information standard for images.

A XIS can possibly act within a XDS network. The information standards in use by MedMij have the primary objective to enable standardized communication based on FHIR STU3. As a secondary objective, enabling exchange with XDS networks is taken into account. For this objective, the PHR will need to provide additional meta information to the Media resource. The additional meta information allows XIS actors to index an image properly within a XDS network. The XIS is responsible for converting the PHR message into a XDS DocumentEntry. A mapping from the Media resource to the mandatory metadata elements of the IHE MHD DocumentReference resource is provided. The IHE MHD and general IHE XDS profiles will provide the information needed to perform a successful DocumentEntry of an image.

=Use case: send image from a PHR to a XIS=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]

== Introduction ==
This use case describes the minimal required technical functionalities in order to exchange an image made by the patient to a healthcare provider. Typical process flow would be:
# Patients makes, downloads or receives an image and uploads it to his PHR.
# The PHR sends the image to the chosen XIS system.
## Potentially the patient needs to provide sufficient metadata concerning the image.
# A healthcare provider views the image in his XIS.
This use case presumes made agreements between the patient and healthcare provider. Besides a technical answer by the XIS of the healthcare provider, no answer to the patient is expected.

The following technical specifications will concern the process mentioned at point 2.

==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 Image Bundle (PUSH)
|style="background-color: white;vertical-align:top;"|Send image bundle request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends image to the XIS
|-
|style="background-color: white;vertical-align:top;"|Receive image bundle response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives image from PHR
|}

== Invocations ==
{{FHIR-IG-Afsprakenstelsel-Note}}

=== Client - PHR request===
When the patient (PHR) wants to send one or more images, it issues a send image bundle request message.

The PHR initiate a FHIR transaction using a create action by sending an HTTP POST request composed of a FHIR Bundle Resource containing one or more FHIR Media resources, zero or more Binary resources and one patient resource to the XIS Recipient. References to the FHIR specification for the required transaction and POST requests are given in the [[#Interactions.2C_operations.2C_search_parameters | interactions, operations and search parameters]] section below.

The PHR executes an HTTP POST against the XIS's base endpoint as shown below.

<pre>
POST [base] {?_format=[mime-type]}
</pre>

The PHR shall assure all FHIR resource elements are consistent with the requirements specified in the StructureDefinitions for List, Media, Device, Patient, Practitioner and Organization resources. References to these StructureDefinitions are provided in [[#List_of_StructureDefinitions | list of StructureDefinitions]].

==== Textual Requirements ====

* The Bundle.type shall be transaction.

* The Media.content.attachment.url points at the image content, which shall be in the Bundle as a Binary resource. See FHIR Resolving references in Bundles at the [http://hl7.org/fhir/STU3/bundle.html#references FHIR specification] and use within MedMij at the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG#Use_of_the_reference_datatype MedMij Use case overarching principles].

* All Media.subject values shall be References to Patient resources and shall be included in the Bundle.

* A List resource shall be used to group the images if a collection of images are sent.

* Accompanying text from the patient for the image and/or collection of images shall be placed in the Media.note and List.note respectively.

=== Examples ===
'''Message components'''
* [https://simplifier.net/nictizstu3-zib2017/media-example-eczema-comprehensive-data Media comprehensive data]
* [https://simplifier.net/nictizstu3-zib2017/media-example-eczema-minimum-data Media minimum data]
* [https://simplifier.net/nictizstu3-zib2017/binary-example Binary of image]
* [https://simplifier.net/nictizstu3-zib2017/images-list-media List of Media resources]
'''Transaction Bundle'''
* [https://simplifier.net/nictizstu3-zib2017/image-transaction-bundle Transaction Bundle containing one image]
* [https://simplifier.net/nictizstu3-zib2017/images-bundle-transaction-multiple-images Transaction Bundle containing multiple images]
* [http://hl7.org/fhir/bundle-response.xml.html Transaction Bundle response - example from the FHIR spec]

=== Server - XIS response ===
The XIS shall process the bundle atomically. If necessary for processing, the XIS shall retrieve resources referenced by absolute URLs in the FHIR Bundle Resource.

The XIS returns an HTTP Status code appropriate to the processing outcome, conforming to the transaction specification requirements as specified in the FHIR specification.

The XIS response message shall be sent when a success or error condition needs to be communicated. Success is only indicated once the image(s) is/are received and completely processed and persisted as appropriate to the XIS configuration.

To enable the PHR to know the outcome of processing the transaction, and the identities assigned to the resources by the XIS, the XIS shall return a Bundle, with type set to transaction-response, that contains one entry for each entry in the request, in the same order as received, with the Bundle.entry.response.outcome indicating the results of processing the entry. The XIS shall comply with FHIR [http://hl7.org/fhir/STU3/bundle.html#transaction-response Bundle transaction-response] and [http://hl7.org/fhir/STU3/http.html#transaction-response the HTTP transaction-response] specifications.

=== Server - XIS & XDS ===
If the receiving XIS is part of a XDS network, it will need to convert the PHR request message into a proper message for the IHE "Provide and Register Document Set-b [ITI-41]" transaction. The XIS shall create appropriate metadata from the resources in the FHIR Bundle. The PHR shall provide the minimally required metadata. A mapping is shown below to assist in the XDS entry. The FHIR Media resource is mapped to the mandatory elements in the IHE MHD Profile on "DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata". IHE MHD defined these elements as a minimum for a XDS DocumentEntry. The [https://simplifier.net/NictizSTU3-Zib2017/ImagesMedia/~mappings Media StructureDefinition] contains a mapping to this profile and to XDS DocumentEntry, the [https://simplifier.net/NictizSTU3-Zib2017/images-List/~mappings List StructureDefinition] contatins a mapping to the XDS 'Folder Metadata Attributes'. Some FHIR elements do not translate to XDS concepts; the handling of these elements is left to the implementer of the XIS.

Upon successful conversion of the FHIR Bundle to XDS metadata, the XIS shall execute the Provide and Register Document Set-b [ITI-41] transaction. The transaction result and any error or warning messages, shall be reported to the PHR. The XIS is responsible for translating the XDS response to the appropriate HTTP Status Code and FHIR OperationOutcome Resource in the Send Image Bundle Response Message.

==== Mapping Media to mandatory IHE MHD DocumentReference elements needed for XDS DocumentEntry ====

{| class="wikitable"
! style="font-weight:bold;" | IHE MHD Profile on DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata
! style="font-weight:bold;" | Media for images, used by the PHR
! style="font-weight:bold;" | Implementation notes for XIS & XDS
|-
| DocumentReference.masterIdentifier
| Media.identifier
|
|-
| DocumentReference.status
|
| Fixed value "current".
|-
| DocumentReference.type
| Media.type
| Fixed LOINC code: 72170-4 Photographic image Unspecified body region Document.
|-
| DocumentReference.class
| Media.reasonCode
| If no reasonCode is present, a fixed LOINC code 72170-4 Photographic image Unspecified body region Document can be used.
|-
| DocumentReference.subject
| Media.subject
|
|-
| DocumentReference.indexed
| Media.occurrenceDateTime
|
|-
| DocumentReference.securityLabel
| Media.meta.security
| If no value is present 'normal' should be used as default.
|-
| DocumentReference.content
| Media.content
|
|-
| DocumentReference.content.attachment
| Media.content.attachment
|
|-
| DocumentReference.content.attachment.contentType
| Media.content.attachment.contentType
| Possible media content types: JPEG, PNG, GIF, JP2.
|-
| DocumentReference.content.attachment.url
| Media.content.attachment.url
|
|-
| DocumentReference.content.attachment.size
| Media.content.attachment.size
|
|-
| DocumentReference.content.attachment.hash
| Media.content.attachment.hash
|
|-
| DocumentReference.content.format
|
| Fixed value "mimeType Sufficient".
|}

A number of fixed values can be used in indexing to a XDS network based on an image sent by a patient. These are status, type, security (if no value is given in the Media.meta.security element) and format. Below the technical representation of these fixed values is shown.

<pre>
<DocumentReference>
....
<status value="current" />
....
<type>
<coding>
<system value="http://loinc.org/" />
<code value="72170-4" />
<display value="Photographic image Unspecified body region Document" />
</coding>
</type>
....
<securityLabel>
<coding>
<system value="http://hl7.org/fhir/v3/Confidentiality" />
<code value="N" />
<display value="normal" />
</coding>
</securityLabel>
....
<format>
<system value="urn:oid:1.3.6.1.4.1.19376.1.2.3"/>
<code value="urn:ihe:iti:xds:2017:mimeTypeSufficient"/>
<display value="mimeType Sufficient"/>
</format>
....
</DocumentReference>
</pre>

{{IssueBox|'''Images.1''' Currently we mandate the PHR to provide identifiers for the Media and List, which should conform to the requirements of an identifier needed for a DocumentEntry. Should this be mandatory? Isn't this an element that a XIS should generate?}}
{{IssueBox|'''Images.2''' Media Status. A DocumentReference has a status while Media does not in STU3. Within IHE MHD only the status values 'current' and 'superseded' are used. This in combination with a relatesTo element to indicate which document is superseded. This use case does not specify how to handle superseded images. Current scope is to exchange images witouth a status indicator. Could this be a problem for XDS networks?}}
{{IssueBox|'''Images.3''' Is a 'normal' security code possible as default when no information is given by the patient?}}
{{IssueBox|'''Images.4''' Does Media.reasonCode map to DocumentReference.class / XDS classCode? Do we need the patient to mandatory provide information for this concept? Does the fixed code suggestion fits if the patient does not provide information?}}
{{IssueBox|'''Images.5''' The mapping table above only maps the mandatory elements from the DocumentReference profile. The StructureDefinitions Media en List contain all the mappings and is referenced above as well. However, should we expand this table here with additional and optional elements?}}

==Interactions, operations, search parameters==

===Interactions===
The following logical interactions are needed for this use case:
* [http://hl7.org/fhir/STU3/http.html#create Create]
* [http://hl7.org/fhir/STU3/http.html#transaction Transaction]

===Operations===
There are no defined operations for this use case.

===Search parameters===
There are no search parameters needed for this use case.

==List of StructureDefinitions==
===MedMij StructureDefinitions===

{{NoteBoxPackage|https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/1.0.0|1.0.0|MedMij:Vdraft_FHIR_IG}}

{| 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
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient]
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-practitioner http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner]
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization]
|-
| Beeld
| Image
| Media
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/structuredefinition/images-media http://nictiz.nl/fhir/StructureDefinition/images-Media]
|-
| CollectieBeelden
| CollectionImages
| List
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/StructureDefinition/images-List http://nictiz.nl/fhir/StructureDefinition/images-List]
|-
| MedischHulpmiddel.Product
| MedicalDevice.Product
| Device
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct]
|}

===IHE MHD StructureDefinitions===
IHE has defined StructureDefinitions and other Conformance resources applicable to this use case. The FHIR Implementation Guide on the '''[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide IHE MHD wiki]''' lists these StructureDefinitions.

* IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive]

* IHE MHD Profile on DocumentReference (DocumentEntry) when used in the Provide Transaction with Comprehensive (aka XDS-on-FHIR) Metadata
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference]

* IHE MHD Profile on List (Folder)
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.List http://ihe.net/fhir/StructureDefinition/IHE.MHD.List]

{{IssueBox|'''IHE.1''' Currently, we don't use or specify a profile that concerns the transaction request. (A profile like "IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata") Is such a profile nescessary? We don't use it in other MedMij use cases and the transaction bundle is described by the FHIR specification and textual in this use case.}}
{{IssueBox|'''IHE.2''' The main reason the "IHE MHD Profile on List (Folder)" is not used, is because it mandates the use of .title and .code which likely contains information a patient needs to enter manually. As we would like to keep the burden on patients as low as possible a custom profile of list is used without these mandatory elements. Additionally, one of the benefits is that we can use references to our own profiles. }}
{{IssueBox|'''IHE.3''' The IHE StructureDefinitions contain a number of errors, mentioned in this [https://chat.fhir.org/#narrow/stream/100-IHE-FHIR.20profiles/topic/IHE.20MHD.20profiles Zulip chat]. These issues will be solved in the R4 release of IHE MHD. We will likely make a pull request to address these issues for the STU3 release. .}}
{{IssueBox|'''IHE.4''' The IHE StructureDefinitions restrict the use of the .created element. This is a known issue and will be addressed in the R4 release of the profiles. This issue (CP-ITI-1100) can be found on the [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide IHE MHD wiki]. Therefore the indexed element is used to capture creation time.}}

=Annex: Document history=

==Release notes==
Release notes can be found on the [[MedMij:V2019.01_Ontwerpen#Release_Notes| functional design main page]] of the MedMij information standards.

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 0.1.0
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"|
* Added concept version.
|-
| style="background-color: white;"| 0.2.0
| style="background-color: white;"| 11-12-2018
| style="background-color: white;"|
* Added introduction text.
|-
| style="background-color: white;"| 0.3.0
| style="background-color: white;"| 12-12-2018
| style="background-color: white;"|
* Added Boundaries and Relationships.
* Added Client - PHR request.
* Added Server - XIS response.
* Added Server - XIS & XDS.
|-
| style="background-color: white;"| 0.4.0
| style="background-color: white;"| 13-12-2018
| style="background-color: white;"|
* Added Media - DocumentReference mapping.
|-
| style="background-color: white;"| 0.5.0
| style="background-color: white;"| 19-12-2018
| style="background-color: white;"|
* Added FHIR examples and StructureDefinitions.
* Textual improvements.
|-
| style="background-color: white;"| 0.6.0
| style="background-color: white;"| 28-12-2018
| style="background-color: white;"|
* Added FHIR examples and StructureDefinitions (Transaction Bundle and List profile).
* Textual improvements.
* Added and improved open issues with issue boxes.
* Added an open public consultation issue box at the top of the page.
* Moved releas notes to the functional design main page.
|}

MedMij:Vprepub-2019.01 FHIR Images

2019-03-15T10:26:27Z

Tim Ruijters:

{{#customtitle:MedMij FHIR Implementation Guide: Images 1.0.0}}

{{IssueBox|This information standard is in development. Feedback gathered during the public consultation from 10-01-2019 to 21-02-2019 is being processed.

If you have any feedback, please submit it at https://bits.nictiz.nl/projects/MSIOC/}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<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:V2019.01_OntwerpBeelden|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.01_Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This page describes the exchange of images within MedMij. In contrary to other described use cases for MedMij no existing information standard fits nor are there specific ZIB models applicable. To achieve exchange of images, MedMij adopts as much as possible from existing standards, such as the DICOM standard and the Mobile access to Health Documents (MHD) profile from Integrating the Healthcare Enterprise (IHE) that defines a RESTful/HTTP interface to an [http://wiki.ihe.net/index.php/Cross-Enterprise_Document_Sharing XDS] environment using HL7 FHIR STU3 resources.

The specification currently consists of one use case, that covers sending an image by a patient to a healthcare provider. Based on future research, a use case to retrieve images by the patient will be added. Most likely, this will be based on DICOMweb™, which is the DICOM standard for web-based medical imaging based on RESTful services.

'''Note''': this page is part of the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG MedMij FHIR Implementation Guide] and is a technical representation of the functional design published on this [[MedMij:V2019.01_Ontwerpen| wiki page]].

==IHE MHD specification==
Mobile access to Health Documents (MHD) profile defines a simple HTTP interface to an XDS like environment. The four described transactions leverage the document content and format agnostic metadata concepts from XDS but simplify them for access by constrained environments such as mobile devices, or other resource-constrained systems. The MHD profile does not replace XDS. It can be used to allow mobile devices, or other resource-constrained systems, access to an XDS health information exchange.[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)]

'''Wiki:'''
[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) Mobile acces to Health Document (MHD)]

'''Document:'''
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf MHD Supplement] (Rev 2.3 July 24, 2017)

'''Additional Supplement:'''
[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_Appx-Z.pdf Appendix Z on HL7 FHIR]

=Actors and transactions involved=
Table 1 shows the relevant actors, systems and FHIR capability statements in a MedMij context. The capability statements demonstrate the minimum requirements to be conformant to the described use cases.

{| 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]] [https://simplifier.net/NictizSTU3-Zib2017/image-clientcapabilities CapabilityStatement: Client]
| Image FHIR Client requirements
|-
| Healthcare Provider
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/NictizSTU3-Zib2017/image-servercapabilities CapabilityStatement: Server]
| Image FHIR Server requirements
|}
'''Table 1. Actors, systems and FHIR capability statements'''

Table 2 shows the MHD actors and transactions in perspective of the systems used in a MedMij context.
{| class="wikitable"
! style="font-weight: bold; text-align:left;" | Person
! style="font-weight: bold; text-align:left;" | System
! style="font-weight: bold; text-align:left;" | Role
! style="font-weight: bold; text-align:left;" | MHD Actors - for XDS
! style="font-weight: bold; text-align:left;" | MHD Transactions - for XDS
|-
| Patient
| PHR
| Sends image to the XIS
| Document Source
| rowspan="2" |Provide Document Bundle
|-
| Healthcare provider
| XIS
| Receives image from the PHR
| Document Recipient
|}
'''Table 2. MHD actors and transactions in perspective of systems in a MedMij context'''

=Boundaries and Relationships=
The use case where an image is sent from a PHR to a XIS is influenced by the IHE MHD profile with regards to the PHR message semantics and mandatory elements. The specifications for this use case mainly deviates in the use of the FHIR Media resource instead of the DocumentReference resource. Although the DocumentResource is in line with the requirements of persisting content in a XDS network and the resource can handle images, the Media resource is more appropriate and specific for the exchange of images. The Media resource has additional, more specific, (medical related) elements compared to the DocumentReference. These are the Media's view, reasonCode, bodySite, device and to a lesser extent the height and width elements. In addition, the Media resource has a reference coming from the DiagnosticReport that may be of value for further development of the MedMij information standard for images.

A XIS can possibly act within a XDS network. The information standards in use by MedMij have the primary objective to enable standardized communication based on FHIR STU3. As a secondary objective, enabling exchange with XDS networks is taken into account. For this objective, the PHR will need to provide additional meta information to the Media resource. The additional meta information allows XIS actors to index an image properly within a XDS network. The XIS is responsible for converting the PHR message into a XDS DocumentEntry. A mapping from the Media resource to the mandatory metadata elements of the IHE MHD DocumentReference resource is provided. The IHE MHD and general IHE XDS profiles will provide the information needed to perform a successful DocumentEntry of an image.

=Use case: send image from a PHR to a XIS=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]

== Introduction ==
This use case describes the minimal required technical functionalities in order to exchange an image made by the patient to a healthcare provider. Typical process flow would be:
# Patients makes, downloads or receives an image and uploads it to his PHR.
# The PHR sends the image to the chosen XIS system.
## Potentially the patient needs to provide sufficient metadata concerning the image.
# A healthcare provider views the image in his XIS.
This use case presumes made agreements between the patient and healthcare provider. Besides a technical answer by the XIS of the healthcare provider, no answer to the patient is expected.

The following technical specifications will concern the process mentioned at point 2.

==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 Image Bundle (PUSH)
|style="background-color: white;vertical-align:top;"|Send image bundle request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends image to the XIS
|-
|style="background-color: white;vertical-align:top;"|Receive image bundle response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives image from PHR
|}

== Invocations ==
{{FHIR-IG-Afsprakenstelsel-Note}}

=== Client - PHR request===
When the patient (PHR) wants to send one or more images, it issues a send image bundle request message.

The PHR initiate a FHIR transaction using a create action by sending an HTTP POST request composed of a FHIR Bundle Resource containing one or more FHIR Media resources, zero or more Binary resources and one patient resource to the XIS Recipient. References to the FHIR specification for the required transaction and POST requests are given in the [[#Interactions.2C_operations.2C_search_parameters | interactions, operations and search parameters]] section below.

The PHR executes an HTTP POST against the XIS's base endpoint as shown below.

<pre>
POST [base] {?_format=[mime-type]}
</pre>

The PHR shall assure all FHIR resource elements are consistent with the requirements specified in the StructureDefinitions for List, Media, Device, Patient, Practitioner and Organization resources. References to these StructureDefinitions are provided in [[#List_of_StructureDefinitions | list of StructureDefinitions]].

==== Textual Requirements ====

* The Bundle.type shall be transaction.

* The Media.content.attachment.url points at the image content, which shall be in the Bundle as a Binary resource. See FHIR Resolving references in Bundles at the [http://hl7.org/fhir/STU3/bundle.html#references FHIR specification] and use within MedMij at the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_FHIR_IG#Use_of_the_reference_datatype MedMij Use case overarching principles].

* All Media.subject values shall be References to Patient resources and shall be included in the Bundle.

* A List resource shall be used to group the images if a collection of images are sent.

* Accompanying text from the patient for the image and/or collection of images shall be placed in the Media.note and List.note respectively.

=== Examples ===
'''Message components'''
* [https://simplifier.net/nictizstu3-zib2017/media-example-eczema-comprehensive-data Media comprehensive data]
* [https://simplifier.net/nictizstu3-zib2017/media-example-eczema-minimum-data Media minimum data]
* [https://simplifier.net/nictizstu3-zib2017/binary-example Binary of image]
* [https://simplifier.net/nictizstu3-zib2017/images-list-media List of Media resources]
'''Transaction Bundle'''
* [https://simplifier.net/nictizstu3-zib2017/image-transaction-bundle Transaction Bundle containing one image]
* [https://simplifier.net/nictizstu3-zib2017/images-bundle-transaction-multiple-images Transaction Bundle containing multiple images]
* [http://hl7.org/fhir/bundle-response.xml.html Transaction Bundle response - example from the FHIR spec]

=== Server - XIS response ===
The XIS shall process the bundle atomically. If necessary for processing, the XIS shall retrieve resources referenced by absolute URLs in the FHIR Bundle Resource.

The XIS returns an HTTP Status code appropriate to the processing outcome, conforming to the transaction specification requirements as specified in the FHIR specification.

The XIS response message shall be sent when a success or error condition needs to be communicated. Success is only indicated once the image(s) is/are received and completely processed and persisted as appropriate to the XIS configuration.

To enable the PHR to know the outcome of processing the transaction, and the identities assigned to the resources by the XIS, the XIS shall return a Bundle, with type set to transaction-response, that contains one entry for each entry in the request, in the same order as received, with the Bundle.entry.response.outcome indicating the results of processing the entry. The XIS shall comply with FHIR [http://hl7.org/fhir/STU3/bundle.html#transaction-response Bundle transaction-response] and [http://hl7.org/fhir/STU3/http.html#transaction-response the HTTP transaction-response] specifications.

=== Server - XIS & XDS ===
If the receiving XIS is part of a XDS network, it will need to convert the PHR request message into a proper message for the IHE "Provide and Register Document Set-b [ITI-41]" transaction. The XIS shall create appropriate metadata from the resources in the FHIR Bundle. The PHR shall provide the minimally required metadata. A mapping is shown below to assist in the XDS entry. The FHIR Media resource is mapped to the mandatory elements in the IHE MHD Profile on "DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata". IHE MHD defined these elements as a minimum for a XDS DocumentEntry. The [https://simplifier.net/NictizSTU3-Zib2017/ImagesMedia/~mappings Media StructureDefinition] contains a mapping to this profile and to XDS DocumentEntry, the [https://simplifier.net/NictizSTU3-Zib2017/images-List/~mappings List StructureDefinition] contatins a mapping to the XDS 'Folder Metadata Attributes'. Some FHIR elements do not translate to XDS concepts; the handling of these elements is left to the implementer of the XIS.

Upon successful conversion of the FHIR Bundle to XDS metadata, the XIS shall execute the Provide and Register Document Set-b [ITI-41] transaction. The transaction result and any error or warning messages, shall be reported to the PHR. The XIS is responsible for translating the XDS response to the appropriate HTTP Status Code and FHIR OperationOutcome Resource in the Send Image Bundle Response Message.

==== Mapping Media to mandatory IHE MHD DocumentReference elements needed for XDS DocumentEntry ====

{| class="wikitable"
! style="font-weight:bold;" | IHE MHD Profile on DocumentReference with Comprehensive (aka XDS-on-FHIR) Metadata
! style="font-weight:bold;" | Media for images, used by the PHR
! style="font-weight:bold;" | Implementation notes for XIS & XDS
|-
| DocumentReference.masterIdentifier
| Media.identifier
|
|-
| DocumentReference.status
|
| Fixed value "current".
|-
| DocumentReference.type
| Media.type
| Fixed LOINC code: 72170-4 Photographic image Unspecified body region Document.
|-
| DocumentReference.class
| Media.reasonCode
| If no reasonCode is present, a fixed LOINC code 72170-4 Photographic image Unspecified body region Document can be used.
|-
| DocumentReference.subject
| Media.subject
|
|-
| DocumentReference.indexed
| Media.occurrenceDateTime
|
|-
| DocumentReference.securityLabel
| Media.meta.security
| If no value is present 'normal' should be used as default.
|-
| DocumentReference.content
| Media.content
|
|-
| DocumentReference.content.attachment
| Media.content.attachment
|
|-
| DocumentReference.content.attachment.contentType
| Media.content.attachment.contentType
| Possible media content types: JPEG, PNG, GIF, JP2.
|-
| DocumentReference.content.attachment.url
| Media.content.attachment.url
|
|-
| DocumentReference.content.attachment.size
| Media.content.attachment.size
|
|-
| DocumentReference.content.attachment.hash
| Media.content.attachment.hash
|
|-
| DocumentReference.content.format
|
| Fixed value "mimeType Sufficient".
|}

A number of fixed values can be used in indexing to a XDS network based on an image sent by a patient. These are status, type, security (if no value is given in the Media.meta.security element) and format. Below the technical representation of these fixed values is shown.

<pre>
<DocumentReference>
....
<status value="current" />
....
<type>
<coding>
<system value="http://loinc.org/" />
<code value="72170-4" />
<display value="Photographic image Unspecified body region Document" />
</coding>
</type>
....
<securityLabel>
<coding>
<system value="http://hl7.org/fhir/v3/Confidentiality" />
<code value="N" />
<display value="normal" />
</coding>
</securityLabel>
....
<format>
<system value="urn:oid:1.3.6.1.4.1.19376.1.2.3"/>
<code value="urn:ihe:iti:xds:2017:mimeTypeSufficient"/>
<display value="mimeType Sufficient"/>
</format>
....
</DocumentReference>
</pre>

{{IssueBox|'''Images.1''' Currently we mandate the PHR to provide identifiers for the Media and List, which should conform to the requirements of an identifier needed for a DocumentEntry. Should this be mandatory? Isn't this an element that a XIS should generate?}}
{{IssueBox|'''Images.2''' Media Status. A DocumentReference has a status while Media does not in STU3. Within IHE MHD only the status values 'current' and 'superseded' are used. This in combination with a relatesTo element to indicate which document is superseded. This use case does not specify how to handle superseded images. Current scope is to exchange images witouth a status indicator. Could this be a problem for XDS networks?}}
{{IssueBox|'''Images.3''' Is a 'normal' security code possible as default when no information is given by the patient?}}
{{IssueBox|'''Images.4''' Does Media.reasonCode map to DocumentReference.class / XDS classCode? Do we need the patient to mandatory provide information for this concept? Does the fixed code suggestion fits if the patient does not provide information?}}
{{IssueBox|'''Images.5''' The mapping table above only maps the mandatory elements from the DocumentReference profile. The StructureDefinitions Media en List contain all the mappings and is referenced above as well. However, should we expand this table here with additional and optional elements?}}

==Interactions, operations, search parameters==

===Interactions===
The following logical interactions are needed for this use case:
* [http://hl7.org/fhir/STU3/http.html#create Create]
* [http://hl7.org/fhir/STU3/http.html#transaction Transaction]

===Operations===
There are no defined operations for this use case.

===Search parameters===
There are no search parameters needed for this use case.

==List of StructureDefinitions==
===MedMij StructureDefinitions===

{{NoteBoxPackage|https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/1.0.0|1.0.0|MedMij:Vdraft_FHIR_IG}}

{| 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
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient]
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-practitioner http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner]
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| [https://simplifier.net/NictizSTU3-zib2017/nl-core-organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization]
|-
| Beeld
| Image
| Media
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/structuredefinition/images-media http://nictiz.nl/fhir/StructureDefinition/images-Media]
|-
| CollectieBeelden
| CollectionImages
| List
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/StructureDefinition/images-List http://nictiz.nl/fhir/StructureDefinition/images-List]
|-
| MedischHulpmiddel.Product
| MedicalDevice.Product
| Device
| [https://simplifier.net/search?canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct]
|}

===IHE MHD StructureDefinitions===
IHE has defined StructureDefinitions and other Conformance resources applicable to this use case. The FHIR Implementation Guide on the '''[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide IHE MHD wiki]''' lists these StructureDefinitions.

* IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive]

* IHE MHD Profile on DocumentReference (DocumentEntry) when used in the Provide Transaction with Comprehensive (aka XDS-on-FHIR) Metadata
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference http://ihe.net/fhir/StructureDefinition/IHE.MHD.Provide.Comprehensive.DocumentReference]

* IHE MHD Profile on List (Folder)
** Canonical URL: [https://simplifier.net/resolve?canonical=http://ihe.net/fhir/StructureDefinition/IHE.MHD.List http://ihe.net/fhir/StructureDefinition/IHE.MHD.List]

{{IssueBox|'''IHE.1''' Currently, we don't use or specify a profile that concerns the transaction request. (A profile like "IHE MHD profile on Provide Document Bundle (ITI-65) transaction with Comprehensive Metadata") Is such a profile nescessary? We don't use it in other MedMij use cases and the transaction bundle is described by the FHIR specification and textual in this use case.}}
{{IssueBox|'''IHE.2''' The main reason the "IHE MHD Profile on List (Folder)" is not used, is because it mandates the use of .title and .code which likely contains information a patient needs to enter manually. As we would like to keep the burden on patients as low as possible a custom profile of list is used without these mandatory elements. Additionally, one of the benefits is that we can use references to our own profiles. }}
{{IssueBox|'''IHE.3''' The IHE StructureDefinitions contain a number of errors, mentioned in this [https://chat.fhir.org/#narrow/stream/100-IHE-FHIR.20profiles/topic/IHE.20MHD.20profiles Zulip chat]. These issues will be solved in the R4 release of IHE MHD. We will likely make a pull request to address these issues for the STU3 release. .}}
{{IssueBox|'''IHE.4''' The IHE StructureDefinitions restrict the use of the .created element. This is a known issue and will be addressed in the R4 release of the profiles. This issue (CP-ITI-1100) can be found on the [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide IHE MHD wiki]. Therefore the indexed element is used to capture creation time.}}

=Annex: Document history=

==Release notes==
Release notes can be found on the [[MedMij:V2019.01_Ontwerpen#Release_Notes| functional design main page]] of the MedMij information standards.

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 0.1.0
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"|
* Added concept version.
|-
| style="background-color: white;"| 0.2.0
| style="background-color: white;"| 11-12-2018
| style="background-color: white;"|
* Added introduction text.
|-
| style="background-color: white;"| 0.3.0
| style="background-color: white;"| 12-12-2018
| style="background-color: white;"|
* Added Boundaries and Relationships.
* Added Client - PHR request.
* Added Server - XIS response.
* Added Server - XIS & XDS.
|-
| style="background-color: white;"| 0.4.0
| style="background-color: white;"| 13-12-2018
| style="background-color: white;"|
* Added Media - DocumentReference mapping.
|-
| style="background-color: white;"| 0.5.0
| style="background-color: white;"| 19-12-2018
| style="background-color: white;"|
* Added FHIR examples and StructureDefinitions.
* Textual improvements.
|-
| style="background-color: white;"| 0.6.0
| style="background-color: white;"| 28-12-2018
| style="background-color: white;"|
* Added FHIR examples and StructureDefinitions (Transaction Bundle and List profile).
* Textual improvements.
* Added and improved open issues with issue boxes.
* Added an open public consultation issue box at the top of the page.
* Moved releas notes to the functional design main page.
|}

MedMij:V2019.01 OntwerpBeelden

2019-03-15T10:24:07Z

Tim Ruijters:

__NUMBEREDHEADINGS__
{{#customtitle:Functioneel Ontwerp Beelden}}
{{MedMij:V2019.01_Issuebox}}
{{IssueBox|Deze standaard is in ontwikkeling. Feedback van de openbare consultatie tussen 10-01-2019 en 21-02-2019 wordt nog doorgevoerd.}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_Images|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft het functioneel ontwerp voor de uitwisseling van beelden binnen MedMij. De algemene inleiding van de MedMij functionele ontwerpen kan [[MedMij:V2019.01_Ontwerpen| hier]] gevonden worden.

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case 1: Sturen beelden vanuit een PGO==
=== Doel en relevantie ===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door beelden te sturen naar (verschillende) zorgaanbieders.

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

=== Context ===
Het gaat om het elektronisch en gestructureerd sturen van beelden vanuit een [[#persoonlijke-gezondheidsomgeving|persoonlijke gezondheidsomgeving]] (PGO) naar een 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 ===
Bij het sturen van beelden gaat het om de volgende informatie die uitgewisseld wordt:
# de beelden
# bijbehorende meta-informatie per beeld
# mogelijk een begeleidende tekst

De beelden kunnen gemaakt zijn door de patiënt, een zorgaanbieder of iemand anders. Deze use case gaat ervan uit dat er reeds afspraken bestaan tussen de patiënt en zorgverlener betreffende het sturen van beelden. Daarbij ondersteunt deze use case geen interactie met de patiënt middels het PGO. De zorgverlener dient buiten deze use case om de beelden te bespreken met de patiënt.

==== 1. Beeld gegevensformaten en grootte====
De volgende gegevensformaten dienen te worden ondersteund: JPEG, PNG, GIF en JP2. Dit zijn ook de gegevensformaten, bestaande uit één frame, die door [[#DICOM-beeldformaten|DICOM standaard]] worden gespecificeerd voor gebruik bij DICOM web-services. Binnen deze use case zijn dit de enige gebruikte gegevensformaten voor beelden.

Beelden mogen extra (meta)informatie bevatten in bijvoorbeeld de [[#Exif|Exif standaard]]. Een voorbeeld is het opslaan van patiëntgegevens binnen het beeldformaat JPEG. Hier wordt in deze use case echter geen gebruik van gemaakt.

Een beeld is maximaal 10 MB, base 64 encoded. Effectief is een beeld niet groter dan 7.5 MB.

Een PGO kan één of meerdere beelden tegelijk sturen.

==== 2. Meta-informatie ====
Het beeld dient te worden voorzien van voldoende meta-informatie om door het ontvangende systeem goed te kunnen worden geïnterpreteerd én geïndexeerd in een XDS omgeving. Deze use case gaat uit van uitwisseling met zowel XISen aangesloten op een XDS netwerk alswel XISen die dat niet zijn. De essentie is dat een PGO altijd de minimale benodigde meta-informatie stuurt om met alle XISen te kunnen uitwisselen. Het correct indexeren van de beelden in een XDS netwerk is de verantwoordelijkheid van het ontvangende XIS. Het technische ontwerp geeft ondersteuning middels een mapping van het FHIR bericht naar XDS concepten en het IHE MHD profiel.

Veel van de benodigde meta-informatie kan geautomatiseerd/gegenereerd worden door het PGO (en XIS voor XDS indexatie). Vrijwel alle verplichte meta-informatie elementen zou een PGO voor de patiënt kunnen genereren in deze use case. Dit wordt weergegeven in de onderstaande twee tabellen.

In de tabellen wordt een overzicht gegeven van alle verplichte ''variabele'' informatie-elementen die een PGO dient te sturen behorend bij een beeld. Daarnaast worden ook optionele informatie-elementen weergeven. De eerste tabel beschrijft de meta-informatie elementen behorende bij een enkel beeld, de tweede tabel betreft de meta-informatie voor een collectie beelden. De vierde kolom geeft aan of de PGO of de Patiënt verantwoordelijk is voor het aanbieden van het betreffende informatie-element.

{| class="wikitable"
! Meta-informatie elementen voor één beeld
! Omschrijving
! Verplicht element
! Verantwoordelijk voor informatie
|-
| Patiënt
| Patiënt waar het beeld betrekking op heeft.
| Ja
| PGO
|-
| DatumTijd
| DatumTijd van het beeld. We willen niet dat de patiënt de datum en/of de tijd kan aanpassen. Soms komt het voor dat datum/tijd verkeerd is ingesteld op het apparaat. De zorgverlener kan dan navraag doen bij de patiënt. Eventueel kan de patiënt in veld toelichting aangeven op welk moment het beeld is gemaakt.
| Ja
| PGO
|-
| Beeldbestand/ mediabestand
| Het beeldbestand dat de patiënt wil sturen. In deze release spreken we over beeldbestand omdat in deze release enkel beelden verstuurd kunnen worden. zie beeldformaat voor meer info.
| Ja
| Patiënt
|-
| Beeldformaat
| Beeldformaat (JPEG / PNG / GIF / JP2). In de eerste release worden slechts een beperkt aantal beeldformaten ondersteund. Video wordt nog niet ondersteund. Het beeldformaat wordt in het bericht mee gestuurd, omdat een beeld als binary wordt verstuurd. De ontvangende partij weet op basis van het beeldformaat hoe de binary geopend moet worden.
| Ja
| PGO
|-
| Grootte
| Grootte van het beeld in bytes.
| Ja
| PGO
|-
| Toelichting
| Een toelichting op het beeld.
| Nee
| Patiënt
|-
| Reden
| De reden waarom de foto genomen is, gegeven middels een code of in vrije tekst.
| Nee
| Patiënt
|-
| AnatomischeLocatie
| De anatomische locatie waar het beeld betrekking op heeft bij de patiënt.
| Nee
| Patiënt
|-
| Auteur
| De persoon die het beeld gemaakt heeft.
| Nee
| Patiënt
|-
| Titel
| Omschrijvende naam van het beeld.
| Nee
| PGO - Patiënt indien er geen bestandsnaam beschikbaar is.
|}

{| class="wikitable"
! Meta-informatie elementen voor collectie beelden
! Omschrijving
! Verplicht element
! Verantwoorlijk voor informatie
|-
| Status
| Status van de collectie (huidig, verouderd, invoerfout).
| Ja
| PGO
|-
| Patiënt
| Patiënt waar de collectie beelden betrekking op heeft.
| Ja
| PGO
|-
| Toelichting
| Een toelichting op de collectie beelden.
| Nee
| Patiënt
|-
| DatumTijd
| DatumTijd van wanneer de collectie is samengesteld.
| Nee
| PGO
|-
| Titel
| Omschrijvende naam van de collectie beelden.
| Nee
| Patiënt
|}

==== 3. Begeleidende tekst ====
De Patiënt kan per beeld en/of per collectie beelden een begeleidende tekst meegeven. Dit gaat middels de 'toelichting' meta-informatie elementen.

=== 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="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 beelden sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Wil beelden ontvangen
|}
'''Bedrijfsrollen sturen beelden'''

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

[[Image:Activity_Diagram_-_Sturen_Beelden.png|Activiteitendiagram sturen beelden]]

'''Activiteitendiagram sturen beelden'''

=== Procesbeschrijving ===
==== Patient Journey – Thomas van Beek ====
Een voorbeeldsituatie die de meerwaarde van het sturen van beelden vanuit het PGO schetst is de patient journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf Thomas van Beek].
<blockquote>Voorafgaand aan de reguliere controle van diabetes type 1 vraagt de diabetesverpleegkundige structureel of Thomas een korte vragenlijst wil invullen over ervaren kwaliteit van leven en ziektelast. Thomas heeft echter exact dezelfde vragenlijst 1 week geleden al ingevuld bij de huisarts voor een ander consult en is er sindsdien niets veranderd. Via het patiënten portaal van de huisarts opent Thomas de vragenlijst en maakt er een foto van. Na het uploaden stuurt Thomas deze foto vanuit zijn PGO naar de diabetesverpleegkundige.</blockquote>

==== Patient Journey – Kenneth van Someren ====
Een tweede voorbeeld waarbij de meerwaarde van het sturen van beelden vanuit het PGO geschetst kan worden is de patient journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Kenneth_van_Someren_MedMij.pdf Kenneth van Someren].

<blockquote>De grote antieke stoel in de woonkamer is het plekje waar Kenneth thuis graag te vinden is. De stoel begon echter de laatste tijd steeds minder lekker te zitten. De zuster adviseert regelmatig af te wisselen met de bank, maar de televisie is lang niet zo interessant als het dorpsplein aan de overkant van de straat. Het begon met enkel een klein rood plekje op zijn ruggengraat, maar inmiddels begon dit vormen aan te nemen die ook dochter Debby zorgen baarde. Na kort overleg met de thuiszorg besluit ze telefonisch contact op te nemen met de wondverpleegkundige van de organisatie. Deze vraagt om een duidelijke foto te maken en via het PGO te sturen voor beoordeling. De volgende ochtend komt de thuiszorg met de juiste kennis en materialen om de wond te behandelen.</blockquote>

==== Proces ====
Het stuk van het proces waar het in deze use case omgaat is:
* Patiënt en zorgverlener maken de afspraak dat de patient een beeld kan sturen aan de zorgverlener.
* Patiënt maakt, ontvangt of downloadt één of meerdere beelden en uploadt deze naar zijn PGO.
* Patiënt heeft de mogelijkheid om een begeleidende tekst van maximaal 1 MB toe te voegen aan het beeld en/of beelden.
* Het PGO stuurt de beelden naar het systeem van de zorgaanbieder.
** Mogelijk moet of kan de patiënt metagegevens behorende bij de beelden aanvullen of invullen.
* De zorgaanbieder raadpleegt de beelden in zijn eigen dossier (XIS).
* De zorgverlener bespreekt het beeld buiten het PGO om met de patiënt. Deze use-case ondersteunt geen interactie met de patiënt middels het 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 beelden tussen het eigen PGO en de betreffende XIS.
* De patiënt en zorgaanbieder hebben onderling afspraken gemaakt over het sturen van beelden.
* Het XIS van de zorgaanbieder is in staat afbeeldingen van de patient te ontvangen.
* De beelden bevinden zich in het PGO.

===== Proces stappen =====
* Het systeem van de patiënt (PGO) stuurt de beelden naar het systeem van de zorgaanbieder (XIS).
* Het systeem van de zorgaanbieder (XIS) ontvangt de beelden van het PGO.

===== Post conditie =====
* Indien het systeem van de zorgaanbieder (XIS) gebruik maakt van een XDS omgeving zal dit systeem de beelden op gepaste wijze in het netwerk registreren.
* De zorgaanbieder gebruikt het systeem (XIS) om de beelden te kunnen zien en/of beoordelen.

=== 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 beelden van de persoon naar de zorgaanbieder.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Afkorting
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| Sturen van Beelden
| style="background-color: white;"| MM-1.0.0-BES-FHIR
| style="background-color: white;"| Sturen van beelden naar zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Ontvangen van Beelden
| style="background-color: white;"| MM-1.0.0-BEO-FHIR
| style="background-color: white;"| Ontvangen van beelden vanuit het PGO
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_Sturen_Beelden_(Totaal).png|Componenten diagram]]

'''Componenten diagram van systemen en 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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|Beelden (PUSH)
|style="background-color: white;vertical-align:top;"|Sturen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BES-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:V2019.01_FHIR_Images |Beelden in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Ontvangen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BEO-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_-_Sturen_Beelden.png|Use case diagram Sturen Beelden]]

'''Use case diagram sturen beelden

=Functionaliteit=

== Eisen en wensen ==
*Er zijn op dit moment geen functionele aanwijzingen/eisen voor de systemen geformuleerd.

== Niet functionele eisen en wensen ==
*'''Hash-functie in FHIR media resource'''
**De hash is een optioneel veld.
**sha-1, base64ed
**Zie voor meer uitleg hier: http://hl7.org/fhir/datatypes-definitions.html#Attachment.hash

=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;"| Persoonlijke Gezondheidsomgeving
| style="background-color: white;"|
| style="background-color: white;"| 06-12-2018
| style="background-color: white;"| https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/
| style="background-color: white;"| Patiëntenfederatie Nederland
|-
| style="background-color: white;"| -
| style="background-color: white;"| Rendered Media Types
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| http://dicom.nema.org/medical/dicom/2017d/output/html/part18.html#table_6.1.1-3
| style="background-color: white;"| NEMA (DICOM)
|-
| style="background-color: white;"| -
| style="background-color: white;"| Exif
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| https://en.wikipedia.org/wiki/Exif
| style="background-color: white;"| Wikipedia
|}

'''Referenties

=Bijlage: Documenthistorie=

==Release notes==

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

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

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| -
| style="background-color: white;"| 27-02-2019
| style="background-color: white;"| MSIOC-20 - Aanpassing patient journey.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 21-01-2019
| style="background-color: white;"|
* MSIOC-2 - Taal- en typfoutjes.
* MSIOC-3 - Preconditie ontbeert beelden.
* MSIOC-4 - Proces stappen bevat irrelevante punten.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 28-12-2018
| style="background-color: white;"|
* Aanpassing patient journey.
* Verplaatsing release notes naar functionele hoofdpagina.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 27-12-2018
| style="background-color: white;"|
* Aanpassing naamgeving van de informatiestandaard voor consistentie: van beeld naar beelden en van versturen naar sturen.
* Verwerking feedback.
* Herschreven en aanvulling van de paragraaf 'Informatie'.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| Toevoeging van specificaties bij de sectie 'Informatie' o.b.v. antwoorden uit de verkenning.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 06-12-2018
| style="background-color: white;"| Conceptversie, inclusief afbeeldingen, op wiki verwerkt.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 28-11-2018
| style="background-color: white;"| Eerste conceptversie.
|}

MedMij:Vprepub-2019.01 OntwerpBeelden

2019-03-15T10:24:07Z

Tim Ruijters:

MedMij:V2019.01 OntwerpBeelden

2019-03-15T10:23:33Z

Tim Ruijters:

__NUMBEREDHEADINGS__
{{#customtitle:Functioneel Ontwerp Beelden}}
{{MedMij:V2019.01_Issuebox}}
{{IssueBox|Deze standaard is in ontwikkeling. Feedback van de openbare consultatie tussen 10-01-2019 en 21-02-2019 wordt nog doorgevoerd.}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_Images|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft het functioneel ontwerp voor de uitwisseling van beelden binnen MedMij. De algemene inleiding van de MedMij functionele ontwerpen kan [[MedMij:V2019.01_Ontwerpen| hier]] gevonden worden.

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case 1: Sturen beelden vanuit een PGO==
=== Doel en relevantie ===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door beelden te sturen naar (verschillende) zorgaanbieders.

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

=== Context ===
Het gaat om het elektronisch en gestructureerd sturen van beelden vanuit een [[#persoonlijke-gezondheidsomgeving|persoonlijke gezondheidsomgeving]] (PGO) naar een 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 ===
Bij het sturen van beelden gaat het om de volgende informatie die uitgewisseld wordt:
# de beelden
# bijbehorende meta-informatie per beeld
# mogelijk een begeleidende tekst

De beelden kunnen gemaakt zijn door de patiënt, een zorgaanbieder of iemand anders. Deze use case gaat ervan uit dat er reeds afspraken bestaan tussen de patiënt en zorgverlener betreffende het sturen van beelden. Daarbij ondersteunt deze use case geen interactie met de patiënt middels het PGO. De zorgverlener dient buiten deze use case om de beelden te bespreken met de patiënt.

==== 1. Beeld gegevensformaten en grootte====
De volgende gegevensformaten dienen te worden ondersteund: JPEG, PNG, GIF en JP2. Dit zijn ook de gegevensformaten, bestaande uit één frame, die door [[#DICOM-beeldformaten|DICOM standaard]] worden gespecificeerd voor gebruik bij DICOM web-services. Binnen deze use case zijn dit de enige gebruikte gegevensformaten voor beelden.

Beelden mogen extra (meta)informatie bevatten in bijvoorbeeld de [[#Exif|Exif standaard]]. Een voorbeeld is het opslaan van patiëntgegevens binnen het beeldformaat JPEG. Hier wordt in deze use case echter geen gebruik van gemaakt.

Een beeld is maximaal 10 MB, base 64 encoded. Effectief is een beeld niet groter dan 7.5 MB.

Een PGO kan één of meerdere beelden tegelijk sturen.

==== 2. Meta-informatie ====
Het beeld dient te worden voorzien van voldoende meta-informatie om door het ontvangende systeem goed te kunnen worden geïnterpreteerd én geïndexeerd in een XDS omgeving. Deze use case gaat uit van uitwisseling met zowel XISen aangesloten op een XDS netwerk alswel XISen die dat niet zijn. De essentie is dat een PGO altijd de minimale benodigde meta-informatie stuurt om met alle XISen te kunnen uitwisselen. Het correct indexeren van de beelden in een XDS netwerk is de verantwoordelijkheid van het ontvangende XIS. Het technische ontwerp geeft ondersteuning middels een mapping van het FHIR bericht naar XDS concepten en het IHE MHD profiel.

Veel van de benodigde meta-informatie kan geautomatiseerd/gegenereerd worden door het PGO (en XIS voor XDS indexatie). Vrijwel alle verplichte meta-informatie elementen zou een PGO voor de patiënt kunnen genereren in deze use case. Dit wordt weergegeven in de onderstaande twee tabellen.

In de tabellen wordt een overzicht gegeven van alle verplichte ''variabele'' informatie-elementen die een PGO dient te sturen behorend bij een beeld. Daarnaast worden ook optionele informatie-elementen weergeven. De eerste tabel beschrijft de meta-informatie elementen behorende bij een enkel beeld, de tweede tabel betreft de meta-informatie voor een collectie beelden. De vierde kolom geeft aan of de PGO of de Patiënt verantwoordelijk is voor het aanbieden van het betreffende informatie-element.

{| class="wikitable"
! Meta-informatie elementen voor één beeld
! Omschrijving
! Verplicht element
! Verantwoordelijk voor informatie
|-
| Patiënt
| Patiënt waar het beeld betrekking op heeft.
| Ja
| PGO
|-
| DatumTijd
| DatumTijd van het beeld. We willen niet dat de patiënt de datum en/of de tijd kan aanpassen. Soms komt het voor dat datum/tijd verkeerd is ingesteld op het apparaat. De zorgverlener kan dan navraag doen bij de patiënt. Eventueel kan de patiënt in veld toelichting aangeven op welk moment het beeld is gemaakt.
| Ja
| PGO
|-
| Beeldbestand/ mediabestand
| Het beeldbestand dat de patiënt wil sturen. In deze release spreken we over beeldbestand omdat in deze release enkel beelden verstuurd kunnen worden. zie beeldformaat voor meer info.
| Ja
| Patiënt
|-
| Beeldformaat
| Beeldformaat (JPEG / PNG / GIF / JP2). In de eerste release worden slechts een beperkt aantal beeldformaten ondersteund. Video wordt nog niet ondersteund. Het beeldformaat wordt in het bericht mee gestuurd, omdat een beeld als binary wordt verstuurd. De ontvangende partij weet op basis van het beeldformaat hoe de binary geopend moet worden.
| Ja
| PGO
|-
| Grootte
| Grootte van het beeld in bytes.
| Ja
| PGO
|-
| Toelichting
| Een toelichting op het beeld.
| Nee
| Patiënt
|-
| Reden
| De reden waarom de foto genomen is, gegeven middels een code of in vrije tekst.
| Nee
| Patiënt
|-
| AnatomischeLocatie
| De anatomische locatie waar het beeld betrekking op heeft bij de patiënt.
| Nee
| Patiënt
|-
| Auteur
| De persoon die het beeld gemaakt heeft.
| Nee
| Patiënt
|-
| Titel
| Omschrijvende naam van het beeld.
| Nee
| PGO - Patiënt indien er geen bestandsnaam beschikbaar is.
|}

{| class="wikitable"
! Meta-informatie elementen voor collectie beelden
! Omschrijving
! Verplicht element
! Verantwoorlijk voor informatie
|-
| Status
| Status van de collectie (huidig, verouderd, invoerfout).
| Ja
| PGO
|-
| Patiënt
| Patiënt waar de collectie beelden betrekking op heeft.
| Ja
| PGO
|-
| Toelichting
| Een toelichting op de collectie beelden.
| Nee
| Patiënt
|-
| DatumTijd
| DatumTijd van wanneer de collectie is samengesteld.
| Nee
| PGO
|-
| Titel
| Omschrijvende naam van de collectie beelden.
| Nee
| Patiënt
|}

==== 3. Begeleidende tekst ====
De Patiënt kan per beeld en/of per collectie beelden een begeleidende tekst meegeven. Dit gaat middels de 'toelichting' meta-informatie elementen.

=== 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="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 beelden sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Wil beelden ontvangen
|}
'''Bedrijfsrollen sturen beelden'''

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

[[Image:Activity_Diagram_-_Sturen_Beelden.png|Activiteitendiagram sturen beelden]]

'''Activiteitendiagram sturen beelden'''

=== Procesbeschrijving ===
==== Patient Journey – Thomas van Beek ====
Een voorbeeldsituatie die de meerwaarde van het sturen van beelden vanuit het PGO schetst is de patient journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf Thomas van Beek].
<blockquote>Voorafgaand aan de reguliere controle van diabetes type 1 vraagt de diabetesverpleegkundige structureel of Thomas een korte vragenlijst wil invullen over ervaren kwaliteit van leven en ziektelast. Thomas heeft echter exact dezelfde vragenlijst 1 week geleden al ingevuld bij de huisarts voor een ander consult en is er sindsdien niets veranderd. Via het patiënten portaal van de huisarts opent Thomas de vragenlijst en maakt er een foto van. Na het uploaden stuurt Thomas deze foto vanuit zijn PGO naar de diabetesverpleegkundige.</blockquote>

==== Patient Journey – Kenneth van Someren ====
Een tweede voorbeeld waarbij de meerwaarde van het sturen van beelden vanuit het PGO geschetst kan worden is de patient journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Kenneth_van_Someren_MedMij.pdf Kenneth van Someren].

<blockquote>De grote antieke stoel in de woonkamer is het plekje waar Kenneth thuis graag te vinden is. De stoel begon echter de laatste tijd steeds minder lekker te zitten. De zuster adviseert regelmatig af te wisselen met de bank, maar de televisie is lang niet zo interessant als het dorpsplein aan de overkant van de straat. Het begon met enkel een klein rood plekje op zijn ruggengraat, maar inmiddels begon dit vormen aan te nemen die ook dochter Debby zorgen baarde. Na kort overleg met de thuiszorg besluit ze telefonisch contact op te nemen met de wondverpleegkundige van de organisatie. Deze vraagt om een duidelijke foto te maken en via het PGO te sturen voor beoordeling. De volgende ochtend komt de thuiszorg met de juiste kennis en materialen om de wond te behandelen.</blockquote>

==== Proces ====
Het stuk van het proces waar het in deze use case omgaat is:
* Patiënt en zorgverlener maken de afspraak dat de patient een beeld kan sturen aan de zorgverlener.
* Patiënt maakt, ontvangt of downloadt één of meerdere beelden en uploadt deze naar zijn PGO.
* Patiënt heeft de mogelijkheid om een begeleidende tekst van maximaal 1 MB toe te voegen aan het beeld en/of beelden.
* Het PGO stuurt de beelden naar het systeem van de zorgaanbieder.
** Mogelijk moet of kan de patiënt metagegevens behorende bij de beelden aanvullen of invullen.
* De zorgaanbieder raadpleegt de beelden in zijn eigen dossier (XIS).
* De zorgverlener bespreekt het beeld buiten het PGO om met de patiënt. Deze use-case ondersteunt geen interactie met de patiënt middels het 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 beelden tussen het eigen PGO en de betreffende XIS.
* De patiënt en zorgaanbieder hebben onderling afspraken gemaakt over het sturen van beelden.
* Het XIS van de zorgaanbieder is in staat afbeeldingen van de patient te ontvangen.
* De beelden bevinden zich in het PGO.

===== Proces stappen =====
* Het systeem van de patiënt (PGO) stuurt de beelden naar het systeem van de zorgaanbieder (XIS).
* Het systeem van de zorgaanbieder (XIS) ontvangt de beelden van het PGO.

===== Post conditie =====
* Indien het systeem van de zorgaanbieder (XIS) gebruik maakt van een XDS omgeving zal dit systeem de beelden op gepaste wijze in het netwerk registreren.
* De zorgaanbieder gebruikt het systeem (XIS) om de beelden te kunnen zien en/of beoordelen.

=== 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 beelden van de persoon naar de zorgaanbieder.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Afkorting
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| Sturen van Beelden
| style="background-color: white;"| MM-1.0.0-BES-FHIR
| style="background-color: white;"| Sturen van beelden naar zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Ontvangen van Beelden
| style="background-color: white;"| MM-1.0.0-BEO-FHIR
| style="background-color: white;"| Ontvangen van beelden vanuit het PGO
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_Sturen_Beelden_(Totaal).png|Componenten diagram]]

'''Componenten diagram van systemen en 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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|Beelden (PUSH)
|style="background-color: white;vertical-align:top;"|Sturen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BES-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:V2019.01_FHIR_Images |Beelden in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Ontvangen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BEO-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_-_Sturen_Beelden.png|Use case diagram Sturen Beelden]]

'''Use case diagram sturen beelden

=Functionaliteit=

== Eisen en wensen ==
*Er zijn op dit moment geen functionele aanwijzingen/eisen voor de systemen geformuleerd.

== Niet functionele eisen en wensen ==
*'''Hash-functie in FHIR media resource'''
**De hash is een optioneel veld.
**sha-1, base64ed
**Zie voor meer uitleg hier: http://hl7.org/fhir/datatypes-definitions.html#Attachment.hash

=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;"| Persoonlijke Gezondheidsomgeving
| style="background-color: white;"|
| style="background-color: white;"| 06-12-2018
| style="background-color: white;"| https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/
| style="background-color: white;"| Patiëntenfederatie Nederland
|-
| style="background-color: white;"| -
| style="background-color: white;"| Rendered Media Types
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| http://dicom.nema.org/medical/dicom/2017d/output/html/part18.html#table_6.1.1-3
| style="background-color: white;"| NEMA (DICOM)
|-
| style="background-color: white;"| -
| style="background-color: white;"| Exif
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| https://en.wikipedia.org/wiki/Exif
| style="background-color: white;"| Wikipedia
|}

'''Referenties

=Bijlage: Documenthistorie=

==Release notes==

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

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

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| -
| style="background-color: white;"| 27-02-2019
| style="background-color: white;"| MSIOC-20 - Aanpassing patient journey
|-
| style="background-color: white;"| -
| style="background-color: white;"| 21-01-2019
| style="background-color: white;"|
* MSIOC-2 - Taal- en typfoutjes
* MSIOC-3 - Preconditie ontbeert beelden
* MSIOC-4 - Proces stappen bevat irrelevante punten
|-
| style="background-color: white;"| -
| style="background-color: white;"| 28-12-2018
| style="background-color: white;"|
* Aanpassing patient journey.
* Verplaatsing release notes naar functionele hoofdpagina.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 27-12-2018
| style="background-color: white;"|
* Aanpassing naamgeving van de informatiestandaard voor consistentie: van beeld naar beelden en van versturen naar sturen.
* Verwerking feedback.
* Herschreven en aanvulling van de paragraaf 'Informatie'.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| Toevoeging van specificaties bij de sectie 'Informatie' o.b.v. antwoorden uit de verkenning.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 06-12-2018
| style="background-color: white;"| Conceptversie, inclusief afbeeldingen, op wiki verwerkt.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 28-11-2018
| style="background-color: white;"| Eerste conceptversie
|}

MedMij:Vprepub-2019.01 OntwerpBeelden

2019-03-15T10:23:33Z

Tim Ruijters:

__NUMBEREDHEADINGS__
{{#customtitle:Functioneel Ontwerp Beelden}}
{{MedMij:V2019.01_Issuebox}}
{{IssueBox|Deze standaard is in ontwikkeling. Feedback van de openbare consultatie tussen 10-01-2019 en 21-02-2019 wordt nog doorgevoerd.}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_Images|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft het functioneel ontwerp voor de uitwisseling van beelden binnen MedMij. De algemene inleiding van de MedMij functionele ontwerpen kan [[MedMij:V2019.01_Ontwerpen| hier]] gevonden worden.

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case 1: Sturen beelden vanuit een PGO==
=== Doel en relevantie ===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door beelden te sturen naar (verschillende) zorgaanbieders.

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

=== Context ===
Het gaat om het elektronisch en gestructureerd sturen van beelden vanuit een [[#persoonlijke-gezondheidsomgeving|persoonlijke gezondheidsomgeving]] (PGO) naar een 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 ===
Bij het sturen van beelden gaat het om de volgende informatie die uitgewisseld wordt:
# de beelden
# bijbehorende meta-informatie per beeld
# mogelijk een begeleidende tekst

De beelden kunnen gemaakt zijn door de patiënt, een zorgaanbieder of iemand anders. Deze use case gaat ervan uit dat er reeds afspraken bestaan tussen de patiënt en zorgverlener betreffende het sturen van beelden. Daarbij ondersteunt deze use case geen interactie met de patiënt middels het PGO. De zorgverlener dient buiten deze use case om de beelden te bespreken met de patiënt.

==== 1. Beeld gegevensformaten en grootte====
De volgende gegevensformaten dienen te worden ondersteund: JPEG, PNG, GIF en JP2. Dit zijn ook de gegevensformaten, bestaande uit één frame, die door [[#DICOM-beeldformaten|DICOM standaard]] worden gespecificeerd voor gebruik bij DICOM web-services. Binnen deze use case zijn dit de enige gebruikte gegevensformaten voor beelden.

Beelden mogen extra (meta)informatie bevatten in bijvoorbeeld de [[#Exif|Exif standaard]]. Een voorbeeld is het opslaan van patiëntgegevens binnen het beeldformaat JPEG. Hier wordt in deze use case echter geen gebruik van gemaakt.

Een beeld is maximaal 10 MB, base 64 encoded. Effectief is een beeld niet groter dan 7.5 MB.

Een PGO kan één of meerdere beelden tegelijk sturen.

==== 2. Meta-informatie ====
Het beeld dient te worden voorzien van voldoende meta-informatie om door het ontvangende systeem goed te kunnen worden geïnterpreteerd én geïndexeerd in een XDS omgeving. Deze use case gaat uit van uitwisseling met zowel XISen aangesloten op een XDS netwerk alswel XISen die dat niet zijn. De essentie is dat een PGO altijd de minimale benodigde meta-informatie stuurt om met alle XISen te kunnen uitwisselen. Het correct indexeren van de beelden in een XDS netwerk is de verantwoordelijkheid van het ontvangende XIS. Het technische ontwerp geeft ondersteuning middels een mapping van het FHIR bericht naar XDS concepten en het IHE MHD profiel.

Veel van de benodigde meta-informatie kan geautomatiseerd/gegenereerd worden door het PGO (en XIS voor XDS indexatie). Vrijwel alle verplichte meta-informatie elementen zou een PGO voor de patiënt kunnen genereren in deze use case. Dit wordt weergegeven in de onderstaande twee tabellen.

In de tabellen wordt een overzicht gegeven van alle verplichte ''variabele'' informatie-elementen die een PGO dient te sturen behorend bij een beeld. Daarnaast worden ook optionele informatie-elementen weergeven. De eerste tabel beschrijft de meta-informatie elementen behorende bij een enkel beeld, de tweede tabel betreft de meta-informatie voor een collectie beelden. De vierde kolom geeft aan of de PGO of de Patiënt verantwoordelijk is voor het aanbieden van het betreffende informatie-element.

{| class="wikitable"
! Meta-informatie elementen voor één beeld
! Omschrijving
! Verplicht element
! Verantwoordelijk voor informatie
|-
| Patiënt
| Patiënt waar het beeld betrekking op heeft.
| Ja
| PGO
|-
| DatumTijd
| DatumTijd van het beeld. We willen niet dat de patiënt de datum en/of de tijd kan aanpassen. Soms komt het voor dat datum/tijd verkeerd is ingesteld op het apparaat. De zorgverlener kan dan navraag doen bij de patiënt. Eventueel kan de patiënt in veld toelichting aangeven op welk moment het beeld is gemaakt.
| Ja
| PGO
|-
| Beeldbestand/ mediabestand
| Het beeldbestand dat de patiënt wil sturen. In deze release spreken we over beeldbestand omdat in deze release enkel beelden verstuurd kunnen worden. zie beeldformaat voor meer info.
| Ja
| Patiënt
|-
| Beeldformaat
| Beeldformaat (JPEG / PNG / GIF / JP2). In de eerste release worden slechts een beperkt aantal beeldformaten ondersteund. Video wordt nog niet ondersteund. Het beeldformaat wordt in het bericht mee gestuurd, omdat een beeld als binary wordt verstuurd. De ontvangende partij weet op basis van het beeldformaat hoe de binary geopend moet worden.
| Ja
| PGO
|-
| Grootte
| Grootte van het beeld in bytes.
| Ja
| PGO
|-
| Toelichting
| Een toelichting op het beeld.
| Nee
| Patiënt
|-
| Reden
| De reden waarom de foto genomen is, gegeven middels een code of in vrije tekst.
| Nee
| Patiënt
|-
| AnatomischeLocatie
| De anatomische locatie waar het beeld betrekking op heeft bij de patiënt.
| Nee
| Patiënt
|-
| Auteur
| De persoon die het beeld gemaakt heeft.
| Nee
| Patiënt
|-
| Titel
| Omschrijvende naam van het beeld.
| Nee
| PGO - Patiënt indien er geen bestandsnaam beschikbaar is.
|}

{| class="wikitable"
! Meta-informatie elementen voor collectie beelden
! Omschrijving
! Verplicht element
! Verantwoorlijk voor informatie
|-
| Status
| Status van de collectie (huidig, verouderd, invoerfout).
| Ja
| PGO
|-
| Patiënt
| Patiënt waar de collectie beelden betrekking op heeft.
| Ja
| PGO
|-
| Toelichting
| Een toelichting op de collectie beelden.
| Nee
| Patiënt
|-
| DatumTijd
| DatumTijd van wanneer de collectie is samengesteld.
| Nee
| PGO
|-
| Titel
| Omschrijvende naam van de collectie beelden.
| Nee
| Patiënt
|}

==== 3. Begeleidende tekst ====
De Patiënt kan per beeld en/of per collectie beelden een begeleidende tekst meegeven. Dit gaat middels de 'toelichting' meta-informatie elementen.

=== 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="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 beelden sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Wil beelden ontvangen
|}
'''Bedrijfsrollen sturen beelden'''

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

[[Image:Activity_Diagram_-_Sturen_Beelden.png|Activiteitendiagram sturen beelden]]

'''Activiteitendiagram sturen beelden'''

=== Procesbeschrijving ===
==== Patient Journey – Thomas van Beek ====
Een voorbeeldsituatie die de meerwaarde van het sturen van beelden vanuit het PGO schetst is de patient journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf Thomas van Beek].
<blockquote>Voorafgaand aan de reguliere controle van diabetes type 1 vraagt de diabetesverpleegkundige structureel of Thomas een korte vragenlijst wil invullen over ervaren kwaliteit van leven en ziektelast. Thomas heeft echter exact dezelfde vragenlijst 1 week geleden al ingevuld bij de huisarts voor een ander consult en is er sindsdien niets veranderd. Via het patiënten portaal van de huisarts opent Thomas de vragenlijst en maakt er een foto van. Na het uploaden stuurt Thomas deze foto vanuit zijn PGO naar de diabetesverpleegkundige.</blockquote>

==== Patient Journey – Kenneth van Someren ====
Een tweede voorbeeld waarbij de meerwaarde van het sturen van beelden vanuit het PGO geschetst kan worden is de patient journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Kenneth_van_Someren_MedMij.pdf Kenneth van Someren].

<blockquote>De grote antieke stoel in de woonkamer is het plekje waar Kenneth thuis graag te vinden is. De stoel begon echter de laatste tijd steeds minder lekker te zitten. De zuster adviseert regelmatig af te wisselen met de bank, maar de televisie is lang niet zo interessant als het dorpsplein aan de overkant van de straat. Het begon met enkel een klein rood plekje op zijn ruggengraat, maar inmiddels begon dit vormen aan te nemen die ook dochter Debby zorgen baarde. Na kort overleg met de thuiszorg besluit ze telefonisch contact op te nemen met de wondverpleegkundige van de organisatie. Deze vraagt om een duidelijke foto te maken en via het PGO te sturen voor beoordeling. De volgende ochtend komt de thuiszorg met de juiste kennis en materialen om de wond te behandelen.</blockquote>

==== Proces ====
Het stuk van het proces waar het in deze use case omgaat is:
* Patiënt en zorgverlener maken de afspraak dat de patient een beeld kan sturen aan de zorgverlener.
* Patiënt maakt, ontvangt of downloadt één of meerdere beelden en uploadt deze naar zijn PGO.
* Patiënt heeft de mogelijkheid om een begeleidende tekst van maximaal 1 MB toe te voegen aan het beeld en/of beelden.
* Het PGO stuurt de beelden naar het systeem van de zorgaanbieder.
** Mogelijk moet of kan de patiënt metagegevens behorende bij de beelden aanvullen of invullen.
* De zorgaanbieder raadpleegt de beelden in zijn eigen dossier (XIS).
* De zorgverlener bespreekt het beeld buiten het PGO om met de patiënt. Deze use-case ondersteunt geen interactie met de patiënt middels het 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 beelden tussen het eigen PGO en de betreffende XIS.
* De patiënt en zorgaanbieder hebben onderling afspraken gemaakt over het sturen van beelden.
* Het XIS van de zorgaanbieder is in staat afbeeldingen van de patient te ontvangen.
* De beelden bevinden zich in het PGO.

===== Proces stappen =====
* Het systeem van de patiënt (PGO) stuurt de beelden naar het systeem van de zorgaanbieder (XIS).
* Het systeem van de zorgaanbieder (XIS) ontvangt de beelden van het PGO.

===== Post conditie =====
* Indien het systeem van de zorgaanbieder (XIS) gebruik maakt van een XDS omgeving zal dit systeem de beelden op gepaste wijze in het netwerk registreren.
* De zorgaanbieder gebruikt het systeem (XIS) om de beelden te kunnen zien en/of beoordelen.

=== 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 beelden van de persoon naar de zorgaanbieder.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Afkorting
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| Sturen van Beelden
| style="background-color: white;"| MM-1.0.0-BES-FHIR
| style="background-color: white;"| Sturen van beelden naar zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Ontvangen van Beelden
| style="background-color: white;"| MM-1.0.0-BEO-FHIR
| style="background-color: white;"| Ontvangen van beelden vanuit het PGO
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_Sturen_Beelden_(Totaal).png|Componenten diagram]]

'''Componenten diagram van systemen en 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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|Beelden (PUSH)
|style="background-color: white;vertical-align:top;"|Sturen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BES-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:V2019.01_FHIR_Images |Beelden in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Ontvangen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BEO-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_-_Sturen_Beelden.png|Use case diagram Sturen Beelden]]

'''Use case diagram sturen beelden

=Functionaliteit=

== Eisen en wensen ==
*Er zijn op dit moment geen functionele aanwijzingen/eisen voor de systemen geformuleerd.

== Niet functionele eisen en wensen ==
*'''Hash-functie in FHIR media resource'''
**De hash is een optioneel veld.
**sha-1, base64ed
**Zie voor meer uitleg hier: http://hl7.org/fhir/datatypes-definitions.html#Attachment.hash

=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;"| Persoonlijke Gezondheidsomgeving
| style="background-color: white;"|
| style="background-color: white;"| 06-12-2018
| style="background-color: white;"| https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/
| style="background-color: white;"| Patiëntenfederatie Nederland
|-
| style="background-color: white;"| -
| style="background-color: white;"| Rendered Media Types
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| http://dicom.nema.org/medical/dicom/2017d/output/html/part18.html#table_6.1.1-3
| style="background-color: white;"| NEMA (DICOM)
|-
| style="background-color: white;"| -
| style="background-color: white;"| Exif
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| https://en.wikipedia.org/wiki/Exif
| style="background-color: white;"| Wikipedia
|}

'''Referenties

=Bijlage: Documenthistorie=

==Release notes==

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

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

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| -
| style="background-color: white;"| 27-02-2019
| style="background-color: white;"| MSIOC-20 - Aanpassing patient journey
|-
| style="background-color: white;"| -
| style="background-color: white;"| 21-01-2019
| style="background-color: white;"|
* MSIOC-2 - Taal- en typfoutjes
* MSIOC-3 - Preconditie ontbeert beelden
* MSIOC-4 - Proces stappen bevat irrelevante punten
|-
| style="background-color: white;"| -
| style="background-color: white;"| 28-12-2018
| style="background-color: white;"|
* Aanpassing patient journey.
* Verplaatsing release notes naar functionele hoofdpagina.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 27-12-2018
| style="background-color: white;"|
* Aanpassing naamgeving van de informatiestandaard voor consistentie: van beeld naar beelden en van versturen naar sturen.
* Verwerking feedback.
* Herschreven en aanvulling van de paragraaf 'Informatie'.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| Toevoeging van specificaties bij de sectie 'Informatie' o.b.v. antwoorden uit de verkenning.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 06-12-2018
| style="background-color: white;"| Conceptversie, inclusief afbeeldingen, op wiki verwerkt.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 28-11-2018
| style="background-color: white;"| Eerste conceptversie
|}

MedMij:V2019.01 OntwerpBeelden

2019-03-15T10:22:55Z

Tim Ruijters: /* Paginahistorie */

__NUMBEREDHEADINGS__
{{#customtitle:Functioneel Ontwerp Beelden}}
{{MedMij:V2019.01_Issuebox}}
{{IssueBox|Deze standaard is in ontwikkeling. Feedback van de openbare consultatie tussen 10-01-2019 en 21-02-2019 wordt nog doorgevoerd.}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_Images|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft het functioneel ontwerp voor de uitwisseling van beelden binnen MedMij. De algemene inleiding van de MedMij functionele ontwerpen kan [[MedMij:V2019.01_Ontwerpen| hier]] gevonden worden.

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case 1: Sturen beelden vanuit een PGO==
=== Doel en relevantie ===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door beelden te sturen naar (verschillende) zorgaanbieders.

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

=== Context ===
Het gaat om het elektronisch en gestructureerd sturen van beelden vanuit een [[#persoonlijke-gezondheidsomgeving|persoonlijke gezondheidsomgeving]] (PGO) naar een 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 ===
Bij het sturen van beelden gaat het om de volgende informatie die uitgewisseld wordt:
# de beelden
# bijbehorende meta-informatie per beeld
# mogelijk een begeleidende tekst

De beelden kunnen gemaakt zijn door de patiënt, een zorgaanbieder of iemand anders. Deze use case gaat ervan uit dat er reeds afspraken bestaan tussen de patiënt en zorgverlener betreffende het sturen van beelden. Daarbij ondersteunt deze use case geen interactie met de patiënt middels het PGO. De zorgverlener dient buiten deze use case om de beelden te bespreken met de patiënt.

==== 1. Beeld gegevensformaten en grootte====
De volgende gegevensformaten dienen te worden ondersteund: JPEG, PNG, GIF en JP2. Dit zijn ook de gegevensformaten, bestaande uit één frame, die door [[#DICOM-beeldformaten|DICOM standaard]] worden gespecificeerd voor gebruik bij DICOM web-services. Binnen deze use case zijn dit de enige gebruikte gegevensformaten voor beelden.

Beelden mogen extra (meta)informatie bevatten in bijvoorbeeld de [[#Exif|Exif standaard]]. Een voorbeeld is het opslaan van patiëntgegevens binnen het beeldformaat JPEG. Hier wordt in deze use case echter geen gebruik van gemaakt.

Een beeld is maximaal 10 MB, base 64 encoded. Effectief is een beeld niet groter dan 7.5 MB.

Een PGO kan één of meerdere beelden tegelijk sturen.

==== 2. Meta-informatie ====
Het beeld dient te worden voorzien van voldoende meta-informatie om door het ontvangende systeem goed te kunnen worden geïnterpreteerd én geïndexeerd in een XDS omgeving. Deze use case gaat uit van uitwisseling met zowel XISen aangesloten op een XDS netwerk alswel XISen die dat niet zijn. De essentie is dat een PGO altijd de minimale benodigde meta-informatie stuurt om met alle XISen te kunnen uitwisselen. Het correct indexeren van de beelden in een XDS netwerk is de verantwoordelijkheid van het ontvangende XIS. Het technische ontwerp geeft ondersteuning middels een mapping van het FHIR bericht naar XDS concepten en het IHE MHD profiel.

Veel van de benodigde meta-informatie kan geautomatiseerd/gegenereerd worden door het PGO (en XIS voor XDS indexatie). Vrijwel alle verplichte meta-informatie elementen zou een PGO voor de patiënt kunnen genereren in deze use case. Dit wordt weergegeven in de onderstaande twee tabellen.

In de tabellen wordt een overzicht gegeven van alle verplichte ''variabele'' informatie-elementen die een PGO dient te sturen behorend bij een beeld. Daarnaast worden ook optionele informatie-elementen weergeven. De eerste tabel beschrijft de meta-informatie elementen behorende bij een enkel beeld, de tweede tabel betreft de meta-informatie voor een collectie beelden. De vierde kolom geeft aan of de PGO of de Patiënt verantwoordelijk is voor het aanbieden van het betreffende informatie-element.

{| class="wikitable"
! Meta-informatie elementen voor één beeld
! Omschrijving
! Verplicht element
! Verantwoordelijk voor informatie
|-
| Patiënt
| Patiënt waar het beeld betrekking op heeft.
| Ja
| PGO
|-
| DatumTijd
| DatumTijd van het beeld. We willen niet dat de patiënt de datum en/of de tijd kan aanpassen. Soms komt het voor dat datum/tijd verkeerd is ingesteld op het apparaat. De zorgverlener kan dan navraag doen bij de patiënt. Eventueel kan de patiënt in veld toelichting aangeven op welk moment het beeld is gemaakt.
| Ja
| PGO
|-
| Beeldbestand/ mediabestand
| Het beeldbestand dat de patiënt wil sturen. In deze release spreken we over beeldbestand omdat in deze release enkel beelden verstuurd kunnen worden. zie beeldformaat voor meer info.
| Ja
| Patiënt
|-
| Beeldformaat
| Beeldformaat (JPEG / PNG / GIF / JP2). In de eerste release worden slechts een beperkt aantal beeldformaten ondersteund. Video wordt nog niet ondersteund. Het beeldformaat wordt in het bericht mee gestuurd, omdat een beeld als binary wordt verstuurd. De ontvangende partij weet op basis van het beeldformaat hoe de binary geopend moet worden.
| Ja
| PGO
|-
| Grootte
| Grootte van het beeld in bytes.
| Ja
| PGO
|-
| Toelichting
| Een toelichting op het beeld.
| Nee
| Patiënt
|-
| Reden
| De reden waarom de foto genomen is, gegeven middels een code of in vrije tekst.
| Nee
| Patiënt
|-
| AnatomischeLocatie
| De anatomische locatie waar het beeld betrekking op heeft bij de patiënt.
| Nee
| Patiënt
|-
| Auteur
| De persoon die het beeld gemaakt heeft.
| Nee
| Patiënt
|-
| Titel
| Omschrijvende naam van het beeld.
| Nee
| PGO - Patiënt indien er geen bestandsnaam beschikbaar is.
|}

{| class="wikitable"
! Meta-informatie elementen voor collectie beelden
! Omschrijving
! Verplicht element
! Verantwoorlijk voor informatie
|-
| Status
| Status van de collectie (huidig, verouderd, invoerfout).
| Ja
| PGO
|-
| Patiënt
| Patiënt waar de collectie beelden betrekking op heeft.
| Ja
| PGO
|-
| Toelichting
| Een toelichting op de collectie beelden.
| Nee
| Patiënt
|-
| DatumTijd
| DatumTijd van wanneer de collectie is samengesteld.
| Nee
| PGO
|-
| Titel
| Omschrijvende naam van de collectie beelden.
| Nee
| Patiënt
|}

==== 3. Begeleidende tekst ====
De Patiënt kan per beeld en/of per collectie beelden een begeleidende tekst meegeven. Dit gaat middels de 'toelichting' meta-informatie elementen.

=== 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="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 beelden sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Wil beelden ontvangen
|}
'''Bedrijfsrollen sturen beelden'''

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

[[Image:Activity_Diagram_-_Sturen_Beelden.png|Activiteitendiagram sturen beelden]]

'''Activiteitendiagram sturen beelden'''

=== Procesbeschrijving ===
==== Patient Journey – Thomas van Beek ====
Een voorbeeldsituatie die de meerwaarde van het sturen van beelden vanuit het PGO schetst is de patient journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf Thomas van Beek].
<blockquote>Voorafgaand aan de reguliere controle van diabetes type 1 vraagt de diabetesverpleegkundige structureel of Thomas een korte vragenlijst wil invullen over ervaren kwaliteit van leven en ziektelast. Thomas heeft echter exact dezelfde vragenlijst 1 week geleden al ingevuld bij de huisarts voor een ander consult en is er sindsdien niets veranderd. Via het patiënten portaal van de huisarts opent Thomas de vragenlijst en maakt er een foto van. Na het uploaden stuurt Thomas deze foto vanuit zijn PGO naar de diabetesverpleegkundige.</blockquote>

==== Patient Journey – Kenneth van Someren ====
Een tweede voorbeeld waarbij de meerwaarde van het sturen van beelden vanuit het PGO geschetst kan worden is de patient journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Kenneth_van_Someren_MedMij.pdf Kenneth van Someren].

<blockquote>De grote antieke stoel in de woonkamer is het plekje waar Kenneth thuis graag te vinden is. De stoel begon echter de laatste tijd steeds minder lekker te zitten. De zuster adviseert regelmatig af te wisselen met de bank, maar de televisie is lang niet zo interessant als het dorpsplein aan de overkant van de straat. Het begon met enkel een klein rood plekje op zijn ruggengraat, maar inmiddels begon dit vormen aan te nemen die ook dochter Debby zorgen baarde. Na kort overleg met de thuiszorg besluit ze telefonisch contact op te nemen met de wondverpleegkundige van de organisatie. Deze vraagt om een duidelijke foto te maken en via het PGO te sturen voor beoordeling. De volgende ochtend komt de thuiszorg met de juiste kennis en materialen om de wond te behandelen.</blockquote>

==== Proces ====
Het stuk van het proces waar het in deze use case omgaat is:
* Patiënt en zorgverlener maken de afspraak dat de patient een beeld kan sturen aan de zorgverlener.
* Patiënt maakt, ontvangt of downloadt één of meerdere beelden en uploadt deze naar zijn PGO.
* Patiënt heeft de mogelijkheid om een begeleidende tekst van maximaal 1 MB toe te voegen aan het beeld en/of beelden.
* Het PGO stuurt de beelden naar het systeem van de zorgaanbieder.
** Mogelijk moet of kan de patiënt metagegevens behorende bij de beelden aanvullen of invullen.
* De zorgaanbieder raadpleegt de beelden in zijn eigen dossier (XIS).
* De zorgverlener bespreekt het beeld buiten het PGO om met de patiënt. Deze use-case ondersteunt geen interactie met de patiënt middels het 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 beelden tussen het eigen PGO en de betreffende XIS.
* De patiënt en zorgaanbieder hebben onderling afspraken gemaakt over het sturen van beelden.
* Het XIS van de zorgaanbieder is in staat afbeeldingen van de patient te ontvangen.
* De beelden bevinden zich in het PGO.

===== Proces stappen =====
* Het systeem van de patiënt (PGO) stuurt de beelden naar het systeem van de zorgaanbieder (XIS).
* Het systeem van de zorgaanbieder (XIS) ontvangt de beelden van het PGO.

===== Post conditie =====
* Indien het systeem van de zorgaanbieder (XIS) gebruik maakt van een XDS omgeving zal dit systeem de beelden op gepaste wijze in het netwerk registreren.
* De zorgaanbieder gebruikt het systeem (XIS) om de beelden te kunnen zien en/of beoordelen.

=== 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 beelden van de persoon naar de zorgaanbieder.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Afkorting
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| Sturen van Beelden
| style="background-color: white;"| MM-1.0.0-BES-FHIR
| style="background-color: white;"| Sturen van beelden naar zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Ontvangen van Beelden
| style="background-color: white;"| MM-1.0.0-BEO-FHIR
| style="background-color: white;"| Ontvangen van beelden vanuit het PGO
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_Sturen_Beelden_(Totaal).png|Componenten diagram]]

'''Componenten diagram van systemen en 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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|Beelden (PUSH)
|style="background-color: white;vertical-align:top;"|Sturen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BES-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:V2019.01_FHIR_Images |Beelden in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Ontvangen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BEO-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_-_Sturen_Beelden.png|Use case diagram Sturen Beelden]]

'''Use case diagram sturen beelden

=Functionaliteit=

== Eisen en wensen ==
*Er zijn op dit moment geen functionele aanwijzingen/eisen voor de systemen geformuleerd.

== Niet functionele eisen en wensen ==
*'''Hash-functie in FHIR media resource'''
**De hash is een optioneel veld.
**sha-1, base64ed
**Zie voor meer uitleg hier: http://hl7.org/fhir/datatypes-definitions.html#Attachment.hash

=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;"| Persoonlijke Gezondheidsomgeving
| style="background-color: white;"|
| style="background-color: white;"| 06-12-2018
| style="background-color: white;"| https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/
| style="background-color: white;"| Patiëntenfederatie Nederland
|-
| style="background-color: white;"| -
| style="background-color: white;"| Rendered Media Types
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| http://dicom.nema.org/medical/dicom/2017d/output/html/part18.html#table_6.1.1-3
| style="background-color: white;"| NEMA (DICOM)
|-
| style="background-color: white;"| -
| style="background-color: white;"| Exif
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| https://en.wikipedia.org/wiki/Exif
| style="background-color: white;"| Wikipedia
|}

'''Referenties

=Bijlage: Documenthistorie=

==Release notes==

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

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

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Versie
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| -
| style="background-color: white;"| 27-02-2019
| style="background-color: white;"| MSIOC-20 - Aanpassing patient journey
|-
| style="background-color: white;"| -
| style="background-color: white;"| 21-01-2019
| style="background-color: white;"|
* MSIOC-2 - Taal- en typfoutjes
* MSIOC-3 - Preconditie ontbeert beelden
* MSIOC-4 - Proces stappen bevat irrelevante punten
|-
| style="background-color: white;"| -
| style="background-color: white;"| 28-12-2018
| style="background-color: white;"|
* Aanpassing patient journey.
* Verplaatsing release notes naar functionele hoofdpagina.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 27-12-2018
| style="background-color: white;"|
* Aanpassing naamgeving van de informatiestandaard voor consistentie: van beeld naar beelden en van versturen naar sturen.
* Verwerking feedback.
* Herschreven en aanvulling van de paragraaf 'Informatie'.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| Toevoeging van specificaties bij de sectie 'Informatie' o.b.v. antwoorden uit de verkenning.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 06-12-2018
| style="background-color: white;"| Conceptversie, inclusief afbeeldingen, op wiki verwerkt.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 28-11-2018
| style="background-color: white;"| Eerste conceptversie
|}

MedMij:Vprepub-2019.01 OntwerpBeelden

2019-03-15T10:22:55Z

Tim Ruijters: /* Paginahistorie */

__NUMBEREDHEADINGS__
{{#customtitle:Functioneel Ontwerp Beelden}}
{{MedMij:V2019.01_Issuebox}}
{{IssueBox|Deze standaard is in ontwikkeling. Feedback van de openbare consultatie tussen 10-01-2019 en 21-02-2019 wordt nog doorgevoerd.}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_Images|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft het functioneel ontwerp voor de uitwisseling van beelden binnen MedMij. De algemene inleiding van de MedMij functionele ontwerpen kan [[MedMij:V2019.01_Ontwerpen| hier]] gevonden worden.

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case 1: Sturen beelden vanuit een PGO==
=== Doel en relevantie ===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door beelden te sturen naar (verschillende) zorgaanbieders.

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

=== Context ===
Het gaat om het elektronisch en gestructureerd sturen van beelden vanuit een [[#persoonlijke-gezondheidsomgeving|persoonlijke gezondheidsomgeving]] (PGO) naar een 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 ===
Bij het sturen van beelden gaat het om de volgende informatie die uitgewisseld wordt:
# de beelden
# bijbehorende meta-informatie per beeld
# mogelijk een begeleidende tekst

De beelden kunnen gemaakt zijn door de patiënt, een zorgaanbieder of iemand anders. Deze use case gaat ervan uit dat er reeds afspraken bestaan tussen de patiënt en zorgverlener betreffende het sturen van beelden. Daarbij ondersteunt deze use case geen interactie met de patiënt middels het PGO. De zorgverlener dient buiten deze use case om de beelden te bespreken met de patiënt.

==== 1. Beeld gegevensformaten en grootte====
De volgende gegevensformaten dienen te worden ondersteund: JPEG, PNG, GIF en JP2. Dit zijn ook de gegevensformaten, bestaande uit één frame, die door [[#DICOM-beeldformaten|DICOM standaard]] worden gespecificeerd voor gebruik bij DICOM web-services. Binnen deze use case zijn dit de enige gebruikte gegevensformaten voor beelden.

Beelden mogen extra (meta)informatie bevatten in bijvoorbeeld de [[#Exif|Exif standaard]]. Een voorbeeld is het opslaan van patiëntgegevens binnen het beeldformaat JPEG. Hier wordt in deze use case echter geen gebruik van gemaakt.

Een beeld is maximaal 10 MB, base 64 encoded. Effectief is een beeld niet groter dan 7.5 MB.

Een PGO kan één of meerdere beelden tegelijk sturen.

==== 2. Meta-informatie ====
Het beeld dient te worden voorzien van voldoende meta-informatie om door het ontvangende systeem goed te kunnen worden geïnterpreteerd én geïndexeerd in een XDS omgeving. Deze use case gaat uit van uitwisseling met zowel XISen aangesloten op een XDS netwerk alswel XISen die dat niet zijn. De essentie is dat een PGO altijd de minimale benodigde meta-informatie stuurt om met alle XISen te kunnen uitwisselen. Het correct indexeren van de beelden in een XDS netwerk is de verantwoordelijkheid van het ontvangende XIS. Het technische ontwerp geeft ondersteuning middels een mapping van het FHIR bericht naar XDS concepten en het IHE MHD profiel.

Veel van de benodigde meta-informatie kan geautomatiseerd/gegenereerd worden door het PGO (en XIS voor XDS indexatie). Vrijwel alle verplichte meta-informatie elementen zou een PGO voor de patiënt kunnen genereren in deze use case. Dit wordt weergegeven in de onderstaande twee tabellen.

In de tabellen wordt een overzicht gegeven van alle verplichte ''variabele'' informatie-elementen die een PGO dient te sturen behorend bij een beeld. Daarnaast worden ook optionele informatie-elementen weergeven. De eerste tabel beschrijft de meta-informatie elementen behorende bij een enkel beeld, de tweede tabel betreft de meta-informatie voor een collectie beelden. De vierde kolom geeft aan of de PGO of de Patiënt verantwoordelijk is voor het aanbieden van het betreffende informatie-element.

{| class="wikitable"
! Meta-informatie elementen voor één beeld
! Omschrijving
! Verplicht element
! Verantwoordelijk voor informatie
|-
| Patiënt
| Patiënt waar het beeld betrekking op heeft.
| Ja
| PGO
|-
| DatumTijd
| DatumTijd van het beeld. We willen niet dat de patiënt de datum en/of de tijd kan aanpassen. Soms komt het voor dat datum/tijd verkeerd is ingesteld op het apparaat. De zorgverlener kan dan navraag doen bij de patiënt. Eventueel kan de patiënt in veld toelichting aangeven op welk moment het beeld is gemaakt.
| Ja
| PGO
|-
| Beeldbestand/ mediabestand
| Het beeldbestand dat de patiënt wil sturen. In deze release spreken we over beeldbestand omdat in deze release enkel beelden verstuurd kunnen worden. zie beeldformaat voor meer info.
| Ja
| Patiënt
|-
| Beeldformaat
| Beeldformaat (JPEG / PNG / GIF / JP2). In de eerste release worden slechts een beperkt aantal beeldformaten ondersteund. Video wordt nog niet ondersteund. Het beeldformaat wordt in het bericht mee gestuurd, omdat een beeld als binary wordt verstuurd. De ontvangende partij weet op basis van het beeldformaat hoe de binary geopend moet worden.
| Ja
| PGO
|-
| Grootte
| Grootte van het beeld in bytes.
| Ja
| PGO
|-
| Toelichting
| Een toelichting op het beeld.
| Nee
| Patiënt
|-
| Reden
| De reden waarom de foto genomen is, gegeven middels een code of in vrije tekst.
| Nee
| Patiënt
|-
| AnatomischeLocatie
| De anatomische locatie waar het beeld betrekking op heeft bij de patiënt.
| Nee
| Patiënt
|-
| Auteur
| De persoon die het beeld gemaakt heeft.
| Nee
| Patiënt
|-
| Titel
| Omschrijvende naam van het beeld.
| Nee
| PGO - Patiënt indien er geen bestandsnaam beschikbaar is.
|}

{| class="wikitable"
! Meta-informatie elementen voor collectie beelden
! Omschrijving
! Verplicht element
! Verantwoorlijk voor informatie
|-
| Status
| Status van de collectie (huidig, verouderd, invoerfout).
| Ja
| PGO
|-
| Patiënt
| Patiënt waar de collectie beelden betrekking op heeft.
| Ja
| PGO
|-
| Toelichting
| Een toelichting op de collectie beelden.
| Nee
| Patiënt
|-
| DatumTijd
| DatumTijd van wanneer de collectie is samengesteld.
| Nee
| PGO
|-
| Titel
| Omschrijvende naam van de collectie beelden.
| Nee
| Patiënt
|}

==== 3. Begeleidende tekst ====
De Patiënt kan per beeld en/of per collectie beelden een begeleidende tekst meegeven. Dit gaat middels de 'toelichting' meta-informatie elementen.

=== 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="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 beelden sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Wil beelden ontvangen
|}
'''Bedrijfsrollen sturen beelden'''

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

[[Image:Activity_Diagram_-_Sturen_Beelden.png|Activiteitendiagram sturen beelden]]

'''Activiteitendiagram sturen beelden'''

=== Procesbeschrijving ===
==== Patient Journey – Thomas van Beek ====
Een voorbeeldsituatie die de meerwaarde van het sturen van beelden vanuit het PGO schetst is de patient journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf Thomas van Beek].
<blockquote>Voorafgaand aan de reguliere controle van diabetes type 1 vraagt de diabetesverpleegkundige structureel of Thomas een korte vragenlijst wil invullen over ervaren kwaliteit van leven en ziektelast. Thomas heeft echter exact dezelfde vragenlijst 1 week geleden al ingevuld bij de huisarts voor een ander consult en is er sindsdien niets veranderd. Via het patiënten portaal van de huisarts opent Thomas de vragenlijst en maakt er een foto van. Na het uploaden stuurt Thomas deze foto vanuit zijn PGO naar de diabetesverpleegkundige.</blockquote>

==== Patient Journey – Kenneth van Someren ====
Een tweede voorbeeld waarbij de meerwaarde van het sturen van beelden vanuit het PGO geschetst kan worden is de patient journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Kenneth_van_Someren_MedMij.pdf Kenneth van Someren].

<blockquote>De grote antieke stoel in de woonkamer is het plekje waar Kenneth thuis graag te vinden is. De stoel begon echter de laatste tijd steeds minder lekker te zitten. De zuster adviseert regelmatig af te wisselen met de bank, maar de televisie is lang niet zo interessant als het dorpsplein aan de overkant van de straat. Het begon met enkel een klein rood plekje op zijn ruggengraat, maar inmiddels begon dit vormen aan te nemen die ook dochter Debby zorgen baarde. Na kort overleg met de thuiszorg besluit ze telefonisch contact op te nemen met de wondverpleegkundige van de organisatie. Deze vraagt om een duidelijke foto te maken en via het PGO te sturen voor beoordeling. De volgende ochtend komt de thuiszorg met de juiste kennis en materialen om de wond te behandelen.</blockquote>

==== Proces ====
Het stuk van het proces waar het in deze use case omgaat is:
* Patiënt en zorgverlener maken de afspraak dat de patient een beeld kan sturen aan de zorgverlener.
* Patiënt maakt, ontvangt of downloadt één of meerdere beelden en uploadt deze naar zijn PGO.
* Patiënt heeft de mogelijkheid om een begeleidende tekst van maximaal 1 MB toe te voegen aan het beeld en/of beelden.
* Het PGO stuurt de beelden naar het systeem van de zorgaanbieder.
** Mogelijk moet of kan de patiënt metagegevens behorende bij de beelden aanvullen of invullen.
* De zorgaanbieder raadpleegt de beelden in zijn eigen dossier (XIS).
* De zorgverlener bespreekt het beeld buiten het PGO om met de patiënt. Deze use-case ondersteunt geen interactie met de patiënt middels het 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 beelden tussen het eigen PGO en de betreffende XIS.
* De patiënt en zorgaanbieder hebben onderling afspraken gemaakt over het sturen van beelden.
* Het XIS van de zorgaanbieder is in staat afbeeldingen van de patient te ontvangen.
* De beelden bevinden zich in het PGO.

===== Proces stappen =====
* Het systeem van de patiënt (PGO) stuurt de beelden naar het systeem van de zorgaanbieder (XIS).
* Het systeem van de zorgaanbieder (XIS) ontvangt de beelden van het PGO.

===== Post conditie =====
* Indien het systeem van de zorgaanbieder (XIS) gebruik maakt van een XDS omgeving zal dit systeem de beelden op gepaste wijze in het netwerk registreren.
* De zorgaanbieder gebruikt het systeem (XIS) om de beelden te kunnen zien en/of beoordelen.

=== 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 beelden van de persoon naar de zorgaanbieder.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Afkorting
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| Sturen van Beelden
| style="background-color: white;"| MM-1.0.0-BES-FHIR
| style="background-color: white;"| Sturen van beelden naar zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Ontvangen van Beelden
| style="background-color: white;"| MM-1.0.0-BEO-FHIR
| style="background-color: white;"| Ontvangen van beelden vanuit het PGO
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_Sturen_Beelden_(Totaal).png|Componenten diagram]]

'''Componenten diagram van systemen en 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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|Beelden (PUSH)
|style="background-color: white;vertical-align:top;"|Sturen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BES-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:V2019.01_FHIR_Images |Beelden in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Ontvangen Beelden
|style="background-color: white;vertical-align:top;"|MM-1.0.0-BEO-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_-_Sturen_Beelden.png|Use case diagram Sturen Beelden]]

'''Use case diagram sturen beelden

=Functionaliteit=

== Eisen en wensen ==
*Er zijn op dit moment geen functionele aanwijzingen/eisen voor de systemen geformuleerd.

== Niet functionele eisen en wensen ==
*'''Hash-functie in FHIR media resource'''
**De hash is een optioneel veld.
**sha-1, base64ed
**Zie voor meer uitleg hier: http://hl7.org/fhir/datatypes-definitions.html#Attachment.hash

=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;"| Persoonlijke Gezondheidsomgeving
| style="background-color: white;"|
| style="background-color: white;"| 06-12-2018
| style="background-color: white;"| https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/
| style="background-color: white;"| Patiëntenfederatie Nederland
|-
| style="background-color: white;"| -
| style="background-color: white;"| Rendered Media Types
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| http://dicom.nema.org/medical/dicom/2017d/output/html/part18.html#table_6.1.1-3
| style="background-color: white;"| NEMA (DICOM)
|-
| style="background-color: white;"| -
| style="background-color: white;"| Exif
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| https://en.wikipedia.org/wiki/Exif
| style="background-color: white;"| Wikipedia
|}

'''Referenties

=Bijlage: Documenthistorie=

==Release notes==

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

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

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Versie
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| -
| style="background-color: white;"| 27-02-2019
| style="background-color: white;"| MSIOC-20 - Aanpassing patient journey
|-
| style="background-color: white;"| -
| style="background-color: white;"| 21-01-2019
| style="background-color: white;"|
* MSIOC-2 - Taal- en typfoutjes
* MSIOC-3 - Preconditie ontbeert beelden
* MSIOC-4 - Proces stappen bevat irrelevante punten
|-
| style="background-color: white;"| -
| style="background-color: white;"| 28-12-2018
| style="background-color: white;"|
* Aanpassing patient journey.
* Verplaatsing release notes naar functionele hoofdpagina.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 27-12-2018
| style="background-color: white;"|
* Aanpassing naamgeving van de informatiestandaard voor consistentie: van beeld naar beelden en van versturen naar sturen.
* Verwerking feedback.
* Herschreven en aanvulling van de paragraaf 'Informatie'.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| Toevoeging van specificaties bij de sectie 'Informatie' o.b.v. antwoorden uit de verkenning.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 06-12-2018
| style="background-color: white;"| Conceptversie, inclusief afbeeldingen, op wiki verwerkt.
|-
| style="background-color: white;"| -
| style="background-color: white;"| 28-11-2018
| style="background-color: white;"| Eerste conceptversie
|}

MedMij:V2019.01 FHIR VitalSigns

2019-03-15T10:20:12Z

Tim Ruijters: Correction of page history

{{#customtitle:MedMij FHIR Implementation Guide Vital Signs 1.2.0}}
{{MedMij:V2019.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:V2019.01_OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.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.

'''Technical note:'''

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:V2019.01_FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:V2019.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]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities CapabilityStatement: Client]
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities CapabilityStatement: Server]
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
{{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 RESTfull] 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?[parameters]{&_format=[mime-type]}
</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="3" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| category
| token
| The classification of the type of observation
|-
| code
| token
| The code of the observation type
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

'''Example searches'''

The PHR should be able to fetch all of a patient's vital signs by searching on:
# category (all vital signs),
# category and date,
# code (specific vital sign),
# code and date,
# code and Last N.

<pre>1. GET [base]/Observation?category=vital-signs
2. GET [base]/Observation?category=vital-signs&date=[date]{&date=[date]}
3. GET [base]/Observation?code[vital sign LOINC{,LOINC2,LOINC3,...}]
4. GET [base]/Observation?code=[vital sign LOINC{,LOINC2,LOINC3,...}]&date=[date]{&date=[date]}
5. GET [base]/Observation/$lastn?code[vital sign LOINC{,LOINC2,LOINC3,...}
</pre>
The following table lists vital signs that have a corresponding ZIB. The column 'LOINC code' shows the LOINC code that can be used in the search query. Other possible codes, including the codes mentioned here, can be found [http://hl7.org/fhir/STU3/observation-vitalsigns.html#vitals-table here].

{| class="wikitable"
|-style="font-weight: bold; "
||ZIB ||LOINC code
|-
|BloodPressure||85354-9
|-
| BodyWeight||29463-7
|-
| BodyHeight||8302-2
|-
| BodyTemperature||8310-5
|-
| Oxygenation, saturation, SpO2||59408-5
|-
| HeartRate||8867-4
|-
| Glucose|| 41604-0 (fasting) 14743-9 (general) 14760-3 (post-meal)
|}
=====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====
Based on the retrieve vital signs request message processing results, the XIS will either return an error or success. When the XIS needs to report an error, it shall use HTTP error response codes and shall include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not vital signs are found or generated, the HTTP status code shall be 200.

''Response Class:''
* Status 200: successful operation
* Status 400: invalid parameter
* Status 401/4xx: unauthorized request
* Status 403: insufficient scope

If the XIS is sending warnings, the Bundle resource shall also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/observation-vitalsigns.html Vital Signs Profile]
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/STU3/search.html Search]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome resource]

=====Message Resource content=====
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 ZIB's 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.]

All returned resources to the PHR SHALL include their related profile canonical URL in the meta.profile element in order to show compliance. The Observation resources in the response message SHALL be a valid instance of these profiles.

{{NoteBoxPackage|https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/1.1.0|1.1.0|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| Polsfrequentie||PulseRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate]
|-
| -||-||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|}

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

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#search Search]

===Operations===
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 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.

===Search parameters===
The following search parameter types and search result parameters need to be supported for this transaction.

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
* [http://hl7.org/fhir/STU3/search.html#date date]

=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] {?_format=[mime-type]}</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.

The resources in the response message SHALL be a valid instance of these profiles. All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.

{{NoteBoxPackage|https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/1.1.0|1.1.0|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable" width="1200px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|ZIB name NL||style="width:150px;"|ZIB name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht||BodyWeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte||BodyHeight||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| Lichaamstemperatuur||BodyTemperature||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature]
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation]
|-
| Hartfrequentie||HeartRate||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate]
|-
| ||||Observation||[https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose]
|-
|}

=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code. If the XIS encounters any errors or if validation fails, the XIS shall return an error as documented in the Message Semantics of the response message.

===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.

When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error.

Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):

* 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules
* 404 Not Found - resource type not supported, or not a FHIR end-point
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail

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.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#create create]
* [http://hl7.org/fhir/STU3/http.html#transaction batch/transaction]

===Operations===
No operations are defined or needed for this transaction.

===Search parameters===
No search parameters are defined or needed for this transaction.

=Terminology, NamingSystems, Mappings=

===Terminology===
Relevant ValueSets can be found through the ValueSet bindings in the listed StructureDefinitions. All ValueSets can be found here [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ValueSet here] and can be downloaded as a .zip in XML or JSON format.

===NamingSystems===
Relevant NamingSystems can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=NamingSystem here].

===Mappings===
A FHIR ConceptMap resource is provided when a FHIR value set is used instead of a HCIM value set. A ConceptMap maps the values between the two value sets. These ConceptMaps can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ConceptMap here].

All profiles include HCIM mappings. HCIM concepts are mapped to the corresponding FHIR elements using the HCIMs concept id. The top of the StructureDefinition contains meta information regarding the HCIM mapping, such as the name and uri of the HCIM. In the StructureDefinition elements, the corresponding HCIM ID is given including the mapping meta information id. This is illustrated in the following example.

<pre>
<StructureDefinition>
<id value="nl-core-patient" />
.....
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<uri value="https://zibs.nl/wiki/Patient-v3.1(2017EN)"/>
<name value="HCIM Patient-v3.1(2017EN)"/>
</mapping>
.....
<element id="Patient.name">
<path value="Patient.name" />
<short value="NameInformation" />
<alias value="Naamgegevens" />
<type>
<code value="HumanName" />
<profile value="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname" />
</type>
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<map value="NL-CM:0.1.6"/>
</mapping>
</element>
.....
</StructureDefinition>
</pre>

=Annex: Document history=
==Release notes==
Release notes can be found on the [[MedMij:V2019.01_OntwerpZelfmetingen#Release_notes|functional design page]].

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
*Publication of changes in version 2019.01, conform release notes.
*Moved release notes to functional design page.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 14-01-2019
| style="background-color: white;"| Removed incorrect issuebox.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 12-11-2018
| style="background-color: white;"| Added section "Terminology, NamingSystems, Mappings".
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"| Added version in title, and document history.
|}

[[categorie:MedMij FHIR Use Cases]]

MedMij:Vprepub-2019.01 FHIR VitalSigns

2019-03-15T10:20:12Z

Tim Ruijters: Correction of page history

MedMij:V2019.01 OntwerpZelfmetingen

2019-03-15T10:16:54Z

Tim Ruijters: Paginahistorie gecorrigeerd

{{#customtitle:Functioneel Ontwerp Zelfmetingen 1.2.0 }}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Self-Measuements_zonder_tekst.png |link=|links |85px|Zelfmetingen]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_VitalSigns|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot zelfmetingen van vitale functies die een patiënt kan verzamelen en delen door middel van een PGO. De vitale functies van de mens zijn de lichaamsfuncties die de persoon vitaal of ook wel in leven houden, voorbeelden zijn ademhaling en circulatie (hartslag en bloeddruk).

Momenteel bestaat er geen standaard voor zelfmeet gegevens van de vitale functies. Het doel van deze pagina is om verschillende uitwisseling scenario's van zelfmeet gegevens met de patiënt te beschrijven voor gebruik in MedMij.

Zoals [[MedMij:V2019.01_Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij zorginformatiebouwstenen (ZIB's) als leidraad voor de inhoud van informatie uitwisseling. Voor uitwisseling van zelfmeet gegevens gaat het om de volgende ZIB's:

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case: Raadplegen metingen betreffende de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de vitale functie meetwaarden die over henzelf gaan.
===Domein===
Metingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de meetwaarden van vitale functies 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 die van toepassing zijn.

====Raadplegen meetwaarden ====
Informatie elementen in de vraag om meetwaarden van vitale functies.

* Patient identificatienummer
* Periode (startdatum - einddatum)
* Type (soort meetwaarden, bijvoorbeeld bloeddruk)

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om meetwaarden van de vitale functies.

====Beschikbaarstellen meetwaarden meetwaarden====
Informatie elementen in meetwaarden van vitale functies staan hieronder. Het betreffen de Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

=== 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 meetwaarden van vitale functies raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt meetwaarden van vitale functies beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_raadplegen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram Raadplegen meetwaarden vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier]. Hieronder een voor Thomas relevante situatie waarbij het raadplegen van meetwaarden betreffende de vitale functie een rol speelt.

<blockquote>Voordat Thomas zijn consult bij de internist heeft om de resultaten door te spreken worden er een aantal andere waarden getest. Zijn gewicht en zijn bloeddruk worden opgemeten. De laboratoriumwaarden zijn al bekend voordat de internist ze aan Thomas mee kan delen. Alhoewel Thomas zoals gezegd zo min mogelijk met zijn ziekte bezig wil zijn, vindt hij de jaarlijkse controle heel belangrijk. Hij vindt het dan ook heel erg handig om de resultaten van de onderzoeken een dag van tevoren al in te zien in zijn PGO. Hij kan zich zo goed voorbereiden en zal niet meer verrast zijn over de resultaten als zijn internist deze voorlegt.</blockquote>

===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 meetwaarden betreffende de vitale functie een 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 kan na haar opname haar vitale waarden gemeten in ziekenhuis raadplegen. Zo beschikt zij over deze informatie die ze als referentiewaarden kan gebruiken.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de gevraagde meetwaarden van de vitale functies 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 vitale functie meetwaarden tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de meetwaarden van de vitale functies inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden 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) stuurt meetwaarden van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt meetwaarden van de vitale functies op voor de patiënt.
*De zorgverlener gebruikt zijn systeem om de meetwaarden van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft de meetwaarden vitale functies geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* MeetwaardenVitaleFunctiesRaadplegend Systeem in FHIR [MM-1.2.0-MVR-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* MeetwaardenVitaleFunctiesBeschikbaarstellend Systeem in FHIR [MM-1.2.0-MVB-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_raadplegen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Meetwaarden Vitale Functies(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-MVR-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:V2019.01_FHIR_VitalSigns|Meetwaarden vitale functies in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-MVB-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_-_MVF_raadplegen.jpg|Use case diagram raadplegen meetwaarden vitale functies]]

'''Use case diagram

==Use case: Sturen zelfmetingen van de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door het kunnen delen van hun zelfmeet gegevens met de zorgverlener.
===Domein===
Zelfmetingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de zelfmeetwaarden van vitale functies vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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
====Sturen zelfmetingen====
Informatie elementen in zelfmetingen betreffende vitale functies staan hieronder. Het betreffen Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

====Ontvangen zelfmetingen====
Het ontvangende systeem stuurt een ontvangstbevestiging van de zelfmetingen.

=== 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 zelfmetingen van vitale functies sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt zelfmetingen van vitale functies
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_sturen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram sturen zelfmetingen vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 sturen van zelfmetingen betreffende de vitale functie een rol speelt.

<blockquote>Sinds een aantal maanden maakt Roos gebruik van een online persoonlijke gezondheidsomgeving. Daarin houdt ze onder andere haar bloedglucosewaarden bij. Daarnaast moet ze zich dagelijks wegen in verband met haar hartfalen. Bij hartfalen is de pompfunctie van het hart verminderd. Het hart pompt niet genoeg bloed rond, hierdoor kun je vocht vasthouden. Om dit te monitoren weegt Roos zich dagelijks, en houdt ze haar gewicht bij in haar persoonlijke gezondheidsomgeving. Wanneer haar gewicht toeneemt, dan krijgt ze een signaal vanuit haar PGO, omdat dit zou kunnen duiden op het vasthouden van vocht. Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke gezondheidsomgeving terug. De huisarts kan op zijn beurt de gegevens die Roos heeft ingevoerd bekijken, bijvoorbeeld met een handige grafiek die haar bloedsuikers over de afgelopen periode laat zien</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stelt zelfmetingen van de vitale functies beschikbaar aan het systeem van een zorgaanbieder (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 zelfmetingen van de vitale functies tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De zorgaanbieder wil de zelfmetingen van de vitale functies inzien en de patiënt stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden te sturen, 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) stuurt zelfmetingen van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt en verwerkt de zelfmetingen van de patiënt.
*De zorgaanbieder gebruikt de het XIS om de zelfmetingen van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft zelfmetingen gestuurd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* ZelfmetingenVitaleFunctiesSturend Systeem in FHIR [MM-1.2.0-ZVS-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* ZelfmetingenVitaleFunctiesOntvangend Systeem in FHIR [MM-1.2.0-ZVO-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_sturen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Zelfmetingen Vitale Functies(PUSH)
|style="background-color: white;vertical-align:top;"|Sturen zelfmetingen van vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-ZVS-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;"|Ontvangen zelfmetingen vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-ZVO-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_-_MVF_sturen.jpg|Use case diagram sturen zelfmetingen vitale functies]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=
==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving
|-
| rowspan = 5; style="background-color: white;"| 2019.01
| rowspan = 5; style="background-color: white;"| 1.2.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-175 MM-175]
| style="background-color: white;"| Mapping concept Positie van Zib Lichaamslengte niet duidelijk.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-169 MM-169]
| style="background-color: white;"| Zelfmeting pijnscore FHIR.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-147 MM-147]
| style="background-color: white;"| Mappen PulseRegularity binnen PulseRate.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-141 MM-141]
| style="background-color: white;"| Vital Signs profielen inconsistent m.b.t. baseDefinition.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-95 MM-95]
| style="background-color: white;"| Added support for the lastn operation for retrieving the latest available measurement.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-87 MM-87]
| style="background-color: white;"| The links in the table for FHIR profiles have been updated. The BloodGlucose profile in the Retrieve Vital Signs use case and all profiles under the Send Vital Signs use case linked to a deprecated version.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-80 MM-80]
| style="background-color: white;"| The profile mapping for HCIM element NL-CM:12.6.2 TemperatuurType has been updated Observation.method from Observation.bodySite based on feedback received from the ZIB Centrum that even though the definition appears to point to a body site, that the focus of TemperatureType is a method that includes body site. The profile version was updated to 2.0.1
|-
| 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.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| Pijnscore verwijderd uit lijst van toegepaste Zibs voor deze use case. Voor Pijnscore is nog geen FHIR documentatie beschikbaar.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing versienummer naar 1.1.0.
* Wijzigingen doorgevoerd betreffende BITS issue MM-80 en MM-87.
* Kwalificatieparagraaf aangevuld.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:Vprepub-2019.01 OntwerpZelfmetingen

2019-03-15T10:16:54Z

Tim Ruijters: Paginahistorie gecorrigeerd

MedMij:V2019.01 OntwerpZelfmetingen

2019-03-15T10:14:29Z

Tim Ruijters: /* Paginahistorie */

{{#customtitle:Functioneel Ontwerp Zelfmetingen 1.2.0 }}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Self-Measuements_zonder_tekst.png |link=|links |85px|Zelfmetingen]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_VitalSigns|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot zelfmetingen van vitale functies die een patiënt kan verzamelen en delen door middel van een PGO. De vitale functies van de mens zijn de lichaamsfuncties die de persoon vitaal of ook wel in leven houden, voorbeelden zijn ademhaling en circulatie (hartslag en bloeddruk).

Momenteel bestaat er geen standaard voor zelfmeet gegevens van de vitale functies. Het doel van deze pagina is om verschillende uitwisseling scenario's van zelfmeet gegevens met de patiënt te beschrijven voor gebruik in MedMij.

Zoals [[MedMij:V2019.01_Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij zorginformatiebouwstenen (ZIB's) als leidraad voor de inhoud van informatie uitwisseling. Voor uitwisseling van zelfmeet gegevens gaat het om de volgende ZIB's:

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case: Raadplegen metingen betreffende de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de vitale functie meetwaarden die over henzelf gaan.
===Domein===
Metingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de meetwaarden van vitale functies 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 die van toepassing zijn.

====Raadplegen meetwaarden ====
Informatie elementen in de vraag om meetwaarden van vitale functies.

* Patient identificatienummer
* Periode (startdatum - einddatum)
* Type (soort meetwaarden, bijvoorbeeld bloeddruk)

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om meetwaarden van de vitale functies.

====Beschikbaarstellen meetwaarden meetwaarden====
Informatie elementen in meetwaarden van vitale functies staan hieronder. Het betreffen de Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

=== 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 meetwaarden van vitale functies raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt meetwaarden van vitale functies beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_raadplegen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram Raadplegen meetwaarden vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier]. Hieronder een voor Thomas relevante situatie waarbij het raadplegen van meetwaarden betreffende de vitale functie een rol speelt.

<blockquote>Voordat Thomas zijn consult bij de internist heeft om de resultaten door te spreken worden er een aantal andere waarden getest. Zijn gewicht en zijn bloeddruk worden opgemeten. De laboratoriumwaarden zijn al bekend voordat de internist ze aan Thomas mee kan delen. Alhoewel Thomas zoals gezegd zo min mogelijk met zijn ziekte bezig wil zijn, vindt hij de jaarlijkse controle heel belangrijk. Hij vindt het dan ook heel erg handig om de resultaten van de onderzoeken een dag van tevoren al in te zien in zijn PGO. Hij kan zich zo goed voorbereiden en zal niet meer verrast zijn over de resultaten als zijn internist deze voorlegt.</blockquote>

===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 meetwaarden betreffende de vitale functie een 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 kan na haar opname haar vitale waarden gemeten in ziekenhuis raadplegen. Zo beschikt zij over deze informatie die ze als referentiewaarden kan gebruiken.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de gevraagde meetwaarden van de vitale functies 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 vitale functie meetwaarden tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de meetwaarden van de vitale functies inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden 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) stuurt meetwaarden van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt meetwaarden van de vitale functies op voor de patiënt.
*De zorgverlener gebruikt zijn systeem om de meetwaarden van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft de meetwaarden vitale functies geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* MeetwaardenVitaleFunctiesRaadplegend Systeem in FHIR [MM-1.2.0-MVR-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* MeetwaardenVitaleFunctiesBeschikbaarstellend Systeem in FHIR [MM-1.2.0-MVB-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_raadplegen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Meetwaarden Vitale Functies(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-MVR-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:V2019.01_FHIR_VitalSigns|Meetwaarden vitale functies in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-MVB-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_-_MVF_raadplegen.jpg|Use case diagram raadplegen meetwaarden vitale functies]]

'''Use case diagram

==Use case: Sturen zelfmetingen van de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door het kunnen delen van hun zelfmeet gegevens met de zorgverlener.
===Domein===
Zelfmetingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de zelfmeetwaarden van vitale functies vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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
====Sturen zelfmetingen====
Informatie elementen in zelfmetingen betreffende vitale functies staan hieronder. Het betreffen Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

====Ontvangen zelfmetingen====
Het ontvangende systeem stuurt een ontvangstbevestiging van de zelfmetingen.

=== 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 zelfmetingen van vitale functies sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt zelfmetingen van vitale functies
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_sturen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram sturen zelfmetingen vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 sturen van zelfmetingen betreffende de vitale functie een rol speelt.

<blockquote>Sinds een aantal maanden maakt Roos gebruik van een online persoonlijke gezondheidsomgeving. Daarin houdt ze onder andere haar bloedglucosewaarden bij. Daarnaast moet ze zich dagelijks wegen in verband met haar hartfalen. Bij hartfalen is de pompfunctie van het hart verminderd. Het hart pompt niet genoeg bloed rond, hierdoor kun je vocht vasthouden. Om dit te monitoren weegt Roos zich dagelijks, en houdt ze haar gewicht bij in haar persoonlijke gezondheidsomgeving. Wanneer haar gewicht toeneemt, dan krijgt ze een signaal vanuit haar PGO, omdat dit zou kunnen duiden op het vasthouden van vocht. Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke gezondheidsomgeving terug. De huisarts kan op zijn beurt de gegevens die Roos heeft ingevoerd bekijken, bijvoorbeeld met een handige grafiek die haar bloedsuikers over de afgelopen periode laat zien</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stelt zelfmetingen van de vitale functies beschikbaar aan het systeem van een zorgaanbieder (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 zelfmetingen van de vitale functies tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De zorgaanbieder wil de zelfmetingen van de vitale functies inzien en de patiënt stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden te sturen, 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) stuurt zelfmetingen van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt en verwerkt de zelfmetingen van de patiënt.
*De zorgaanbieder gebruikt de het XIS om de zelfmetingen van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft zelfmetingen gestuurd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* ZelfmetingenVitaleFunctiesSturend Systeem in FHIR [MM-1.2.0-ZVS-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* ZelfmetingenVitaleFunctiesOntvangend Systeem in FHIR [MM-1.2.0-ZVO-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_sturen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Zelfmetingen Vitale Functies(PUSH)
|style="background-color: white;vertical-align:top;"|Sturen zelfmetingen van vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-ZVS-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;"|Ontvangen zelfmetingen vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-ZVO-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_-_MVF_sturen.jpg|Use case diagram sturen zelfmetingen vitale functies]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=
==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving
|-
| rowspan = 5; style="background-color: white;"| 2019.01
| rowspan = 5; style="background-color: white;"| 1.2.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-175 MM-175]
| style="background-color: white;"| Mapping concept Positie van Zib Lichaamslengte niet duidelijk.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-169 MM-169]
| style="background-color: white;"| Zelfmeting pijnscore FHIR.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-147 MM-147]
| style="background-color: white;"| Mappen PulseRegularity binnen PulseRate.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-141 MM-141]
| style="background-color: white;"| Vital Signs profielen inconsistent m.b.t. baseDefinition.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-95 MM-95]
| style="background-color: white;"| Added support for the lastn operation for retrieving the latest available measurement.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-87 MM-87]
| style="background-color: white;"| The links in the table for FHIR profiles have been updated. The BloodGlucose profile in the Retrieve Vital Signs use case and all profiles under the Send Vital Signs use case linked to a deprecated version.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-80 MM-80]
| style="background-color: white;"| The profile mapping for HCIM element NL-CM:12.6.2 TemperatuurType has been updated Observation.method from Observation.bodySite based on feedback received from the ZIB Centrum that even though the definition appears to point to a body site, that the focus of TemperatureType is a method that includes body site. The profile version was updated to 2.0.1
|-
| 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.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| Pijnscore verwijderd uit lijst van toegepaste Zibs voor deze use case. Voor Pijnscore is nog geen FHIR documentatie beschikbaar.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing versienummer naar 1.1.0.
* Kwalificatieparagraaf aangevuld.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 28-12-2018
| style="background-color: white;"| Verplaatsing release notes naar functionele hoofdpagina.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:Vprepub-2019.01 OntwerpZelfmetingen

2019-03-15T10:14:29Z

Tim Ruijters: /* Paginahistorie */

{{#customtitle:Functioneel Ontwerp Zelfmetingen 1.2.0 }}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Self-Measuements_zonder_tekst.png |link=|links |85px|Zelfmetingen]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_VitalSigns|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot zelfmetingen van vitale functies die een patiënt kan verzamelen en delen door middel van een PGO. De vitale functies van de mens zijn de lichaamsfuncties die de persoon vitaal of ook wel in leven houden, voorbeelden zijn ademhaling en circulatie (hartslag en bloeddruk).

Momenteel bestaat er geen standaard voor zelfmeet gegevens van de vitale functies. Het doel van deze pagina is om verschillende uitwisseling scenario's van zelfmeet gegevens met de patiënt te beschrijven voor gebruik in MedMij.

Zoals [[MedMij:V2019.01_Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij zorginformatiebouwstenen (ZIB's) als leidraad voor de inhoud van informatie uitwisseling. Voor uitwisseling van zelfmeet gegevens gaat het om de volgende ZIB's:

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case: Raadplegen metingen betreffende de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de vitale functie meetwaarden die over henzelf gaan.
===Domein===
Metingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de meetwaarden van vitale functies 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 die van toepassing zijn.

====Raadplegen meetwaarden ====
Informatie elementen in de vraag om meetwaarden van vitale functies.

* Patient identificatienummer
* Periode (startdatum - einddatum)
* Type (soort meetwaarden, bijvoorbeeld bloeddruk)

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om meetwaarden van de vitale functies.

====Beschikbaarstellen meetwaarden meetwaarden====
Informatie elementen in meetwaarden van vitale functies staan hieronder. Het betreffen de Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

=== 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 meetwaarden van vitale functies raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt meetwaarden van vitale functies beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_raadplegen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram Raadplegen meetwaarden vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier]. Hieronder een voor Thomas relevante situatie waarbij het raadplegen van meetwaarden betreffende de vitale functie een rol speelt.

<blockquote>Voordat Thomas zijn consult bij de internist heeft om de resultaten door te spreken worden er een aantal andere waarden getest. Zijn gewicht en zijn bloeddruk worden opgemeten. De laboratoriumwaarden zijn al bekend voordat de internist ze aan Thomas mee kan delen. Alhoewel Thomas zoals gezegd zo min mogelijk met zijn ziekte bezig wil zijn, vindt hij de jaarlijkse controle heel belangrijk. Hij vindt het dan ook heel erg handig om de resultaten van de onderzoeken een dag van tevoren al in te zien in zijn PGO. Hij kan zich zo goed voorbereiden en zal niet meer verrast zijn over de resultaten als zijn internist deze voorlegt.</blockquote>

===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 meetwaarden betreffende de vitale functie een 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 kan na haar opname haar vitale waarden gemeten in ziekenhuis raadplegen. Zo beschikt zij over deze informatie die ze als referentiewaarden kan gebruiken.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de gevraagde meetwaarden van de vitale functies 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 vitale functie meetwaarden tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de meetwaarden van de vitale functies inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden 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) stuurt meetwaarden van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt meetwaarden van de vitale functies op voor de patiënt.
*De zorgverlener gebruikt zijn systeem om de meetwaarden van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft de meetwaarden vitale functies geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* MeetwaardenVitaleFunctiesRaadplegend Systeem in FHIR [MM-1.2.0-MVR-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* MeetwaardenVitaleFunctiesBeschikbaarstellend Systeem in FHIR [MM-1.2.0-MVB-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_raadplegen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Meetwaarden Vitale Functies(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-MVR-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:V2019.01_FHIR_VitalSigns|Meetwaarden vitale functies in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-MVB-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_-_MVF_raadplegen.jpg|Use case diagram raadplegen meetwaarden vitale functies]]

'''Use case diagram

==Use case: Sturen zelfmetingen van de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door het kunnen delen van hun zelfmeet gegevens met de zorgverlener.
===Domein===
Zelfmetingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de zelfmeetwaarden van vitale functies vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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
====Sturen zelfmetingen====
Informatie elementen in zelfmetingen betreffende vitale functies staan hieronder. Het betreffen Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

====Ontvangen zelfmetingen====
Het ontvangende systeem stuurt een ontvangstbevestiging van de zelfmetingen.

=== 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 zelfmetingen van vitale functies sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt zelfmetingen van vitale functies
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_sturen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram sturen zelfmetingen vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 sturen van zelfmetingen betreffende de vitale functie een rol speelt.

<blockquote>Sinds een aantal maanden maakt Roos gebruik van een online persoonlijke gezondheidsomgeving. Daarin houdt ze onder andere haar bloedglucosewaarden bij. Daarnaast moet ze zich dagelijks wegen in verband met haar hartfalen. Bij hartfalen is de pompfunctie van het hart verminderd. Het hart pompt niet genoeg bloed rond, hierdoor kun je vocht vasthouden. Om dit te monitoren weegt Roos zich dagelijks, en houdt ze haar gewicht bij in haar persoonlijke gezondheidsomgeving. Wanneer haar gewicht toeneemt, dan krijgt ze een signaal vanuit haar PGO, omdat dit zou kunnen duiden op het vasthouden van vocht. Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke gezondheidsomgeving terug. De huisarts kan op zijn beurt de gegevens die Roos heeft ingevoerd bekijken, bijvoorbeeld met een handige grafiek die haar bloedsuikers over de afgelopen periode laat zien</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stelt zelfmetingen van de vitale functies beschikbaar aan het systeem van een zorgaanbieder (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 zelfmetingen van de vitale functies tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De zorgaanbieder wil de zelfmetingen van de vitale functies inzien en de patiënt stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden te sturen, 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) stuurt zelfmetingen van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt en verwerkt de zelfmetingen van de patiënt.
*De zorgaanbieder gebruikt de het XIS om de zelfmetingen van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft zelfmetingen gestuurd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* ZelfmetingenVitaleFunctiesSturend Systeem in FHIR [MM-1.2.0-ZVS-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* ZelfmetingenVitaleFunctiesOntvangend Systeem in FHIR [MM-1.2.0-ZVO-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_sturen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Zelfmetingen Vitale Functies(PUSH)
|style="background-color: white;vertical-align:top;"|Sturen zelfmetingen van vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-ZVS-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;"|Ontvangen zelfmetingen vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-ZVO-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_-_MVF_sturen.jpg|Use case diagram sturen zelfmetingen vitale functies]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=
==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving
|-
| rowspan = 5; style="background-color: white;"| 2019.01
| rowspan = 5; style="background-color: white;"| 1.2.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-175 MM-175]
| style="background-color: white;"| Mapping concept Positie van Zib Lichaamslengte niet duidelijk.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-169 MM-169]
| style="background-color: white;"| Zelfmeting pijnscore FHIR.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-147 MM-147]
| style="background-color: white;"| Mappen PulseRegularity binnen PulseRate.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-141 MM-141]
| style="background-color: white;"| Vital Signs profielen inconsistent m.b.t. baseDefinition.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-95 MM-95]
| style="background-color: white;"| Added support for the lastn operation for retrieving the latest available measurement.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-87 MM-87]
| style="background-color: white;"| The links in the table for FHIR profiles have been updated. The BloodGlucose profile in the Retrieve Vital Signs use case and all profiles under the Send Vital Signs use case linked to a deprecated version.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-80 MM-80]
| style="background-color: white;"| The profile mapping for HCIM element NL-CM:12.6.2 TemperatuurType has been updated Observation.method from Observation.bodySite based on feedback received from the ZIB Centrum that even though the definition appears to point to a body site, that the focus of TemperatureType is a method that includes body site. The profile version was updated to 2.0.1
|-
| 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.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| Pijnscore verwijderd uit lijst van toegepaste Zibs voor deze use case. Voor Pijnscore is nog geen FHIR documentatie beschikbaar.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing versienummer naar 1.1.0.
* Kwalificatieparagraaf aangevuld.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 28-12-2018
| style="background-color: white;"| Verplaatsing release notes naar functionele hoofdpagina.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:V2019.01 OntwerpZelfmetingen

2019-03-15T10:10:57Z

Tim Ruijters:

{{#customtitle:Functioneel Ontwerp Zelfmetingen 1.2.0 }}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Self-Measuements_zonder_tekst.png |link=|links |85px|Zelfmetingen]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_VitalSigns|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot zelfmetingen van vitale functies die een patiënt kan verzamelen en delen door middel van een PGO. De vitale functies van de mens zijn de lichaamsfuncties die de persoon vitaal of ook wel in leven houden, voorbeelden zijn ademhaling en circulatie (hartslag en bloeddruk).

Momenteel bestaat er geen standaard voor zelfmeet gegevens van de vitale functies. Het doel van deze pagina is om verschillende uitwisseling scenario's van zelfmeet gegevens met de patiënt te beschrijven voor gebruik in MedMij.

Zoals [[MedMij:V2019.01_Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij zorginformatiebouwstenen (ZIB's) als leidraad voor de inhoud van informatie uitwisseling. Voor uitwisseling van zelfmeet gegevens gaat het om de volgende ZIB's:

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case: Raadplegen metingen betreffende de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de vitale functie meetwaarden die over henzelf gaan.
===Domein===
Metingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de meetwaarden van vitale functies 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 die van toepassing zijn.

====Raadplegen meetwaarden ====
Informatie elementen in de vraag om meetwaarden van vitale functies.

* Patient identificatienummer
* Periode (startdatum - einddatum)
* Type (soort meetwaarden, bijvoorbeeld bloeddruk)

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om meetwaarden van de vitale functies.

====Beschikbaarstellen meetwaarden meetwaarden====
Informatie elementen in meetwaarden van vitale functies staan hieronder. Het betreffen de Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

=== 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 meetwaarden van vitale functies raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt meetwaarden van vitale functies beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_raadplegen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram Raadplegen meetwaarden vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier]. Hieronder een voor Thomas relevante situatie waarbij het raadplegen van meetwaarden betreffende de vitale functie een rol speelt.

<blockquote>Voordat Thomas zijn consult bij de internist heeft om de resultaten door te spreken worden er een aantal andere waarden getest. Zijn gewicht en zijn bloeddruk worden opgemeten. De laboratoriumwaarden zijn al bekend voordat de internist ze aan Thomas mee kan delen. Alhoewel Thomas zoals gezegd zo min mogelijk met zijn ziekte bezig wil zijn, vindt hij de jaarlijkse controle heel belangrijk. Hij vindt het dan ook heel erg handig om de resultaten van de onderzoeken een dag van tevoren al in te zien in zijn PGO. Hij kan zich zo goed voorbereiden en zal niet meer verrast zijn over de resultaten als zijn internist deze voorlegt.</blockquote>

===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 meetwaarden betreffende de vitale functie een 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 kan na haar opname haar vitale waarden gemeten in ziekenhuis raadplegen. Zo beschikt zij over deze informatie die ze als referentiewaarden kan gebruiken.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de gevraagde meetwaarden van de vitale functies 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 vitale functie meetwaarden tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de meetwaarden van de vitale functies inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden 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) stuurt meetwaarden van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt meetwaarden van de vitale functies op voor de patiënt.
*De zorgverlener gebruikt zijn systeem om de meetwaarden van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft de meetwaarden vitale functies geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* MeetwaardenVitaleFunctiesRaadplegend Systeem in FHIR [MM-1.2.0-MVR-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* MeetwaardenVitaleFunctiesBeschikbaarstellend Systeem in FHIR [MM-1.2.0-MVB-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_raadplegen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Meetwaarden Vitale Functies(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-MVR-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:V2019.01_FHIR_VitalSigns|Meetwaarden vitale functies in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-MVB-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_-_MVF_raadplegen.jpg|Use case diagram raadplegen meetwaarden vitale functies]]

'''Use case diagram

==Use case: Sturen zelfmetingen van de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door het kunnen delen van hun zelfmeet gegevens met de zorgverlener.
===Domein===
Zelfmetingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de zelfmeetwaarden van vitale functies vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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
====Sturen zelfmetingen====
Informatie elementen in zelfmetingen betreffende vitale functies staan hieronder. Het betreffen Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

====Ontvangen zelfmetingen====
Het ontvangende systeem stuurt een ontvangstbevestiging van de zelfmetingen.

=== 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 zelfmetingen van vitale functies sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt zelfmetingen van vitale functies
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_sturen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram sturen zelfmetingen vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 sturen van zelfmetingen betreffende de vitale functie een rol speelt.

<blockquote>Sinds een aantal maanden maakt Roos gebruik van een online persoonlijke gezondheidsomgeving. Daarin houdt ze onder andere haar bloedglucosewaarden bij. Daarnaast moet ze zich dagelijks wegen in verband met haar hartfalen. Bij hartfalen is de pompfunctie van het hart verminderd. Het hart pompt niet genoeg bloed rond, hierdoor kun je vocht vasthouden. Om dit te monitoren weegt Roos zich dagelijks, en houdt ze haar gewicht bij in haar persoonlijke gezondheidsomgeving. Wanneer haar gewicht toeneemt, dan krijgt ze een signaal vanuit haar PGO, omdat dit zou kunnen duiden op het vasthouden van vocht. Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke gezondheidsomgeving terug. De huisarts kan op zijn beurt de gegevens die Roos heeft ingevoerd bekijken, bijvoorbeeld met een handige grafiek die haar bloedsuikers over de afgelopen periode laat zien</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stelt zelfmetingen van de vitale functies beschikbaar aan het systeem van een zorgaanbieder (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 zelfmetingen van de vitale functies tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De zorgaanbieder wil de zelfmetingen van de vitale functies inzien en de patiënt stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden te sturen, 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) stuurt zelfmetingen van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt en verwerkt de zelfmetingen van de patiënt.
*De zorgaanbieder gebruikt de het XIS om de zelfmetingen van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft zelfmetingen gestuurd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* ZelfmetingenVitaleFunctiesSturend Systeem in FHIR [MM-1.2.0-ZVS-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* ZelfmetingenVitaleFunctiesOntvangend Systeem in FHIR [MM-1.2.0-ZVO-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_sturen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Zelfmetingen Vitale Functies(PUSH)
|style="background-color: white;vertical-align:top;"|Sturen zelfmetingen van vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-ZVS-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;"|Ontvangen zelfmetingen vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-ZVO-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_-_MVF_sturen.jpg|Use case diagram sturen zelfmetingen vitale functies]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=
==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving
|-
| rowspan = 5; style="background-color: white;"| 2019.01
| rowspan = 5; style="background-color: white;"| 1.2.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-175 MM-175]
| style="background-color: white;"| Mapping concept Positie van Zib Lichaamslengte niet duidelijk.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-169 MM-169]
| style="background-color: white;"| Zelfmeting pijnscore FHIR.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-147 MM-147]
| style="background-color: white;"| Mappen PulseRegularity binnen PulseRate.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-141 MM-141]
| style="background-color: white;"| Vital Signs profielen inconsistent m.b.t. baseDefinition.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-95 MM-95]
| style="background-color: white;"| Added support for the lastn operation for retrieving the latest available measurement.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-87 MM-87]
| style="background-color: white;"| The links in the table for FHIR profiles have been updated. The BloodGlucose profile in the Retrieve Vital Signs use case and all profiles under the Send Vital Signs use case linked to a deprecated version.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-80 MM-80]
| style="background-color: white;"| The profile mapping for HCIM element NL-CM:12.6.2 TemperatuurType has been updated Observation.method from Observation.bodySite based on feedback received from the ZIB Centrum that even though the definition appears to point to a body site, that the focus of TemperatureType is a method that includes body site. The profile version was updated to 2.0.1
|-
| 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.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| Pijnscore verwijderd uit lijst van toegepaste Zibs voor deze use case. Voor Pijnscore is nog geen FHIR documentatie beschikbaar.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing versienummer naar 1.1.0
* Kwalificatieparagraaf aangevuld
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 28-12-2018
| style="background-color: white;"| Verplaatsing release notes naar functionele hoofdpagina.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:Vprepub-2019.01 OntwerpZelfmetingen

2019-03-15T10:10:57Z

Tim Ruijters:

{{#customtitle:Functioneel Ontwerp Zelfmetingen 1.2.0 }}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Self-Measuements_zonder_tekst.png |link=|links |85px|Zelfmetingen]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_VitalSigns|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot zelfmetingen van vitale functies die een patiënt kan verzamelen en delen door middel van een PGO. De vitale functies van de mens zijn de lichaamsfuncties die de persoon vitaal of ook wel in leven houden, voorbeelden zijn ademhaling en circulatie (hartslag en bloeddruk).

Momenteel bestaat er geen standaard voor zelfmeet gegevens van de vitale functies. Het doel van deze pagina is om verschillende uitwisseling scenario's van zelfmeet gegevens met de patiënt te beschrijven voor gebruik in MedMij.

Zoals [[MedMij:V2019.01_Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij zorginformatiebouwstenen (ZIB's) als leidraad voor de inhoud van informatie uitwisseling. Voor uitwisseling van zelfmeet gegevens gaat het om de volgende ZIB's:

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case: Raadplegen metingen betreffende de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de vitale functie meetwaarden die over henzelf gaan.
===Domein===
Metingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de meetwaarden van vitale functies 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 die van toepassing zijn.

====Raadplegen meetwaarden ====
Informatie elementen in de vraag om meetwaarden van vitale functies.

* Patient identificatienummer
* Periode (startdatum - einddatum)
* Type (soort meetwaarden, bijvoorbeeld bloeddruk)

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om meetwaarden van de vitale functies.

====Beschikbaarstellen meetwaarden meetwaarden====
Informatie elementen in meetwaarden van vitale functies staan hieronder. Het betreffen de Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

=== 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 meetwaarden van vitale functies raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt meetwaarden van vitale functies beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_raadplegen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram Raadplegen meetwaarden vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier]. Hieronder een voor Thomas relevante situatie waarbij het raadplegen van meetwaarden betreffende de vitale functie een rol speelt.

<blockquote>Voordat Thomas zijn consult bij de internist heeft om de resultaten door te spreken worden er een aantal andere waarden getest. Zijn gewicht en zijn bloeddruk worden opgemeten. De laboratoriumwaarden zijn al bekend voordat de internist ze aan Thomas mee kan delen. Alhoewel Thomas zoals gezegd zo min mogelijk met zijn ziekte bezig wil zijn, vindt hij de jaarlijkse controle heel belangrijk. Hij vindt het dan ook heel erg handig om de resultaten van de onderzoeken een dag van tevoren al in te zien in zijn PGO. Hij kan zich zo goed voorbereiden en zal niet meer verrast zijn over de resultaten als zijn internist deze voorlegt.</blockquote>

===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 meetwaarden betreffende de vitale functie een 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 kan na haar opname haar vitale waarden gemeten in ziekenhuis raadplegen. Zo beschikt zij over deze informatie die ze als referentiewaarden kan gebruiken.

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de gevraagde meetwaarden van de vitale functies 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 vitale functie meetwaarden tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil de meetwaarden van de vitale functies inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden 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) stuurt meetwaarden van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt meetwaarden van de vitale functies op voor de patiënt.
*De zorgverlener gebruikt zijn systeem om de meetwaarden van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft de meetwaarden vitale functies geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* MeetwaardenVitaleFunctiesRaadplegend Systeem in FHIR [MM-1.2.0-MVR-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* MeetwaardenVitaleFunctiesBeschikbaarstellend Systeem in FHIR [MM-1.2.0-MVB-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_raadplegen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Meetwaarden Vitale Functies(PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-MVR-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:V2019.01_FHIR_VitalSigns|Meetwaarden vitale functies in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen meetwaarden vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-MVB-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_-_MVF_raadplegen.jpg|Use case diagram raadplegen meetwaarden vitale functies]]

'''Use case diagram

==Use case: Sturen zelfmetingen van de vitale functies door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door het kunnen delen van hun zelfmeet gegevens met de zorgverlener.
===Domein===
Zelfmetingen betreffende vitale functies in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de zelfmeetwaarden van vitale functies vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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
====Sturen zelfmetingen====
Informatie elementen in zelfmetingen betreffende vitale functies staan hieronder. Het betreffen Zorginformatiebouwstenen die te vinden zijn op https://zibs.nl/wiki/ZIB_Hoofdpagina.

*Patiënt
*Ademhaling
*Bloeddruk
*Hartfrequentie
*Lichaamsgewicht
*Lichaamslengte
*Lichaamstemperatuur
*O2Saturatie
*Polsfrequentie

====Ontvangen zelfmetingen====
Het ontvangende systeem stuurt een ontvangstbevestiging van de zelfmetingen.

=== 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 zelfmetingen van vitale functies sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Ontvangt zelfmetingen van vitale functies
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity_Diagram_-_MVF_sturen.jpg|Activiteitendiagram Raadplegen Meetwaarden vitale functies]]

'''Activiteitendiagram sturen zelfmetingen vitale functies'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 sturen van zelfmetingen betreffende de vitale functie een rol speelt.

<blockquote>Sinds een aantal maanden maakt Roos gebruik van een online persoonlijke gezondheidsomgeving. Daarin houdt ze onder andere haar bloedglucosewaarden bij. Daarnaast moet ze zich dagelijks wegen in verband met haar hartfalen. Bij hartfalen is de pompfunctie van het hart verminderd. Het hart pompt niet genoeg bloed rond, hierdoor kun je vocht vasthouden. Om dit te monitoren weegt Roos zich dagelijks, en houdt ze haar gewicht bij in haar persoonlijke gezondheidsomgeving. Wanneer haar gewicht toeneemt, dan krijgt ze een signaal vanuit haar PGO, omdat dit zou kunnen duiden op het vasthouden van vocht. Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke gezondheidsomgeving terug. De huisarts kan op zijn beurt de gegevens die Roos heeft ingevoerd bekijken, bijvoorbeeld met een handige grafiek die haar bloedsuikers over de afgelopen periode laat zien</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een patiënt (PGO) stelt zelfmetingen van de vitale functies beschikbaar aan het systeem van een zorgaanbieder (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 zelfmetingen van de vitale functies tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De zorgaanbieder wil de zelfmetingen van de vitale functies inzien en de patiënt stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om de meetwaarden te sturen, 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) stuurt zelfmetingen van de vitale functies naar een XIS.
*Het systeem van de zorgaanbieder (XIS) ontvangt en verwerkt de zelfmetingen van de patiënt.
*De zorgaanbieder gebruikt de het XIS om de zelfmetingen van de vitale functies in te zien.

=====Post conditie=====
De patiënt heeft zelfmetingen gestuurd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een PGO vervult de volgende systeemrol:
* ZelfmetingenVitaleFunctiesSturend Systeem in FHIR [MM-1.2.0-ZVS-FHIR].

Een XIS vervult in deze use case de volgende systeemrol:
* ZelfmetingenVitaleFunctiesOntvangend Systeem in FHIR [MM-1.2.0-ZVO-FHIR]

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_MVF_sturen_(Totaal).jpg|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Zelfmetingen Vitale Functies(PUSH)
|style="background-color: white;vertical-align:top;"|Sturen zelfmetingen van vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-ZVS-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;"|Ontvangen zelfmetingen vitale functies
|style="background-color: white;vertical-align:top;"|MM-1.2.0-ZVO-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_-_MVF_sturen.jpg|Use case diagram sturen zelfmetingen vitale functies]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=
==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving
|-
| rowspan = 5; style="background-color: white;"| 2019.01
| rowspan = 5; style="background-color: white;"| 1.2.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-175 MM-175]
| style="background-color: white;"| Mapping concept Positie van Zib Lichaamslengte niet duidelijk.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-169 MM-169]
| style="background-color: white;"| Zelfmeting pijnscore FHIR.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-147 MM-147]
| style="background-color: white;"| Mappen PulseRegularity binnen PulseRate.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-141 MM-141]
| style="background-color: white;"| Vital Signs profielen inconsistent m.b.t. baseDefinition.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-95 MM-95]
| style="background-color: white;"| Added support for the lastn operation for retrieving the latest available measurement.
|-
| rowspan = 4; style="background-color: white;"| 2018.06
| rowspan = 4; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-87 MM-87]
| style="background-color: white;"| The links in the table for FHIR profiles have been updated. The BloodGlucose profile in the Retrieve Vital Signs use case and all profiles under the Send Vital Signs use case linked to a deprecated version.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/projects/MM/issues/MM-80 MM-80]
| style="background-color: white;"| The profile mapping for HCIM element NL-CM:12.6.2 TemperatuurType has been updated Observation.method from Observation.bodySite based on feedback received from the ZIB Centrum that even though the definition appears to point to a body site, that the focus of TemperatureType is a method that includes body site. The profile version was updated to 2.0.1
|-
| 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.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| Pijnscore verwijderd uit lijst van toegepaste Zibs voor deze use case. Voor Pijnscore is nog geen FHIR documentatie beschikbaar.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing versienummer naar 1.1.0
* Kwalificatieparagraaf aangevuld
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 28-12-2018
| style="background-color: white;"| Verplaatsing release notes naar functionele hoofdpagina.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:V2019.01 OntwerpMedicatie

2019-03-15T09:53:00Z

Tim Ruijters:

{{#customtitle:Functioneel Ontwerp Medicatieproces 9.0.7}}
{{MedMij:V2019.01_Issuebox}}

[[Bestand:Medicatie_proces_Icoon.png |link=|links |85px|Medicatie Proces]]
[[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:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_MedicationProcess|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot de [https://www.nictiz.nl/Paginas/Medicatieproces.aspx informatiestandaard Medicatieproces] (MP). Deze use cases zijn gebaseerd op versie 9.x van deze standaard. Deze standaard beschrijft de uitwisseling met de patiënt nog niet expliciet. Het doel van deze pagina is om de verschillende uitwisselingsscenario's van medicatiegegevens met de patiënt toe te voegen.

Het is het streven van het MedMij-programma om deze beschrijvingen toe te voegen aan de bestaande standaard voor Medicatieproces.

Zoals [[MedMij:V1.0 Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij voor medicatiegegevens de bouwstenen uit de informatiestandaard Medicatieproces versie 9.x als leidraad voor de uitwisseling van informatie. Voor uitwisseling van medicatiegegevens gaat het om de volgende ZIB's:

*Patiënt;
*Zorgaanbieder;
*Zorgverlener;
*Medicatieafspraak;
*Verstrekkingsverzoek;
*Toedieningsafspraak;
*Verstrekking;
*Medicatiegebruik;
*Toediening.

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=

==Use case: Raadplegen medicatieoverzicht door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in medicatiegegevens die over henzelf gaan.
===Domein===
Medicatiegegevens in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van een medicatieoverzicht 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 die van toepassing zijn, zijn gedefinieerd in ART-DECOR.
====Raadplegen medicatieoverzicht====
Informatie elementen in de vraag om medicatieoverzicht staan hieronder. Om deze informatie in een nieuwe tab te openen, klik [https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.147-2016-11-08T103441.html hier].

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om medicatieoverzicht.

<html>
<iframe width="100%" height="500" src=https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.147-2016-11-08T103441.html frameborder="0" align="middle"></iframe>
</html>

====Beschikbaarstellen medicatieoverzicht====
Informatie elementen in medicatieoverzicht staan hieronder. Om deze informatie in een nieuwe tab te openen, klik [https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.148-2016-11-08T103441.html hier].

Dit betreft de inhoud van het medicatieoverzicht.

<html>
<iframe width="100%" height="500" src=https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.148-2016-11-08T103441.html frameborder="0" align="middle"></iframe>
</html>

=== 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 medicatieoverzicht raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt medicatieoverzicht beschikbaar
|}
'''Bedrijfsrollen Medicatieoverzicht'''

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

[[Bestand:Activity Diagram - Medicatieoverzicht.png|Activiteitendiagram Raadplegen Medicatieoverzicht]]

'''Activiteitendiagram Raadplegen Medicatieoverzicht'''

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

Hieronder een aantal voor Roos relevante situaties waarbij het raadplegen van een medicatieoverzicht een rol speelt.

<blockquote>De afgelopen weken is Roos aan het tobben met haar gezondheid, ze houdt vocht vast achter haar longen en voelt zich niet goed. Haar gewicht begint toe te nemen en haar bloedsuikers zijn niet meer stabiel, en ze maakt een afspraak bij haar huisarts, dokter Jacobs, op 16 juli. Deze verhoogt na onderzoek haar vochtafdrijvende medicatie iets, en geeft haar een nieuw schema waarin staat hoeveel insuline zij extra moet spuiten als de bloedglucosewaarden boven een bepaalde waarde komen. Deze medicatiewijzigingen worden ook zichtbaar in een vernieuwd medicatieoverzicht van huisartsenpraktijk Jacobs/Kroonen, die de situatie op 16 juli weergeeft. Dit medicatieoverzicht kan zij inzien in haar persoonlijke gezondheidsomgeving. Dit geeft haar grip op haar situatie, ze weet waar zij aan toe is.</blockquote>

<blockquote>Het gaat slechter met Roos en op een nacht wordt ze erg benauwd wakker, daarnaast is ze duizelig. Ondanks aanpassingen van de medicatie neemt de benauwdheid niet af, het wordt eerder erger. Joost, haar man, neemt daarom contact op met de huisartsenpost en na overleg wordt besloten dat Roos naar het ziekenhuis moet komen. Een ambulance haalt haar op. Diezelfde nacht nog wordt ze opgenomen op de afdeling cardiologie van het Epidaurus ziekenhuis. Roos blijft een aantal weken onder behandeling en langzaam verbetert haar situatie. Roos wordt op 23 augustus ontslagen uit het Epidaurus ziekenhuis. Haar medicatie is gedurende haar opname verschillende keren aangepast. Bij ontslag maakt de ziekenhuisapotheker een op dat moment actueel medicatieoverzicht voor Roos. Dit medicatieoverzicht maakt het apothekerssysteem beschikbaar voor de persoonlijke gezonheidsomgeving van Roos. Roos kan nu via haar PGO dit medicatieoverzicht van 23 augustus van het Epidaurus ziekenhuis bekijken. Dit geeft haar meer grip op haar gezondheidssituatie.</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt een medicatieoverzicht 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 medicatieoverzichten tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil het medicatieoverzicht inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om een medicatieoverzicht 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 een medicatieoverzicht bij een XIS.
*Het systeem van de zorgaanbieder (XIS) levert een medicatieoverzicht op voor de patiënt.
*Patiënt gebruikt de persoonlijke gezondheidsomgeving om het medicatieoverzicht in te zien.

=====Post conditie=====
De patiënt heeft het medicatieoverzicht geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt.

Een XIS vervult in deze use case de volgende systeemrol:
* MedicatieoverzichtBeschikbaarstellend Systeem in FHIR [MP-9.0.7-MOB-FHIR].

Een PGO vervult de volgende systeemrol:
* MedicatieoverzichtRaadplegend Systeem in FHIR [MP-9.0.7-MOR-FHIR].

Zie ook onderstaande afbeelding.

[[Bestand:Component Diagram - Medicatieoverzicht (Totaal).png|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Medicatieoverzicht (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen medicatieoverzicht
|style="background-color: white;vertical-align:top;"|MP-9.0.7-MOR-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:V2019.01_FHIR_MedicationProcess|Medicatieoverzicht in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen medicatieoverzicht
|style="background-color: white;vertical-align:top;"|MP-9.0.7-MOB-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 - Medicatieoverzicht.png|Use case diagram raadplegen Medicatiegegevens]]

'''Use case diagram

==Use case: Raadplegen medicatiegegevens door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in medicatiegegevens die over henzelf gaan.
===Domein===
Medicatiegegevens in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van een medicatiegegevens 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 die van toepassing zijn, zijn gedefinieerd in de informatiestandaard voor Medicatieproces.
====Raadplegen medicatiegegevens====
Informatie elementen in de vraag om medicatiegegevens staan hieronder. Om deze informatie in een nieuwe tab te openen, klik [https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.136-2016-07-12T133747.html hier].

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om medicatiegegevens.

<html>
<iframe width="100%" height="500" src=https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.136-2016-07-12T133747.html frameborder="0" align="middle"></iframe>
</html>

====Beschikbaarstellen medicatiegegevens====
Informatie elementen in medicatiegegevens staan hieronder. Om deze informatie in een nieuwe tab te openen, klik [https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.102-2016-03-23T163243.html hier].

Dit betreft de inhoud van de transactie met medicatiegegevens.

<html>
<iframe width="100%" height="500" src=https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.102-2016-03-23T163243.html frameborder="0" align="middle"></iframe>
</html>

=== 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 medicatiegegevens raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt medicatiegegevens beschikbaar
|}
'''Bedrijfsrollen Medicatiegegevens'''

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

[[Bestand:Activity Diagram - Medicatiegegevens.png|Activiteitendiagram Raadplegen Medicatiegegevens]]

'''Activiteitendiagram Raadplegen Medicatiegegevens'''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 medicatiegegevens een rol speelt.

<blockquote>Roos heeft de afgelopen tijd in verband met haar hartfalen en diabetes diverse wijzigingen in haar medicatie gehad. Dit is soms gedaan door de specialist en soms door de huisarts. De apotheker paste dan daarna ook soms de doseerinstructies aan, omdat er een ander product geleverd moest worden dan voorgeschreven was. Eigenlijk is Roos het overzicht een beetje kwijtgeraakt. Gelukkig heeft haar PGO wel de mogelijkheid om bij al haar zorgverleners medicatiegegevens op te vragen. Haar PGO kan dit aan haar presenteren in een overzichtelijk geheel. Roos kan nu controleren of ze al haar medicatie inneemt conform de laatste afspraken die hierover zijn gemaakt. Dit is voor Roos heel geruststellend.</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt een medicatiegegevens 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 medicatiegegevens tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil medicatiegegevens inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om een medicatiegegevens 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 medicatiegegevens bij een XIS.
*Het systeem van de zorgaanbieder (XIS) levert medicatiegegevens op voor de patiënt.
*Patiënt gebruikt de persoonlijke gezondheidsomgeving om medicatiegegevens in te zien.

=====Post conditie=====
De patiënt kan medicatiegegevens inzien via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatiegegevensen van zorgaanbieder naar patiënt.

Een XIS vervult in deze use case de volgende systeemrol:
* Medicatiegegevenseschikbaarstellend Systeem in FHIR [MP-9.0.7-MGB-FHIR]

Een PGO vervult de volgende systeemrol:
* MedicatiegegevensRaadplegend Systeem [MP-9.0.7-MGR-FHIR].

Zie ook onderstaande afbeelding.

[[Bestand:Component Diagram - Medicatiegegevens (Totaal).png|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! 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"|Medicatiegegevens (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen medicatiegegevens
|style="background-color: white;vertical-align:top;"|MP-9.0.7-MGR-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:V2019.01_FHIR_MedicationProcess|Medicatiegegevens in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen medicatiegegevens
|style="background-color: white;vertical-align:top;"|MP-9.0.7-MGB-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 - Medicatiegegevens.png|Use case diagram raadplegen Medicatieoverzicht]]

'''Use case diagram

==Use case: Raadplegen verstrekkingenvertaling (medicatieverstrekkingen van het LSP) door patiënt==
Dit is een tijdelijke use case om de periode te overbruggen dat zorgaanbieders Medicatieproces 9.0 nog niet ondersteunen.
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in medicatiegegevens die over henzelf gaan. Deze use case gaat specifiek over het raadplegen van verstrekkingen zoals die op het [https://www.vzvz.nl/over-het-lsp Landelijk Schakelpunt] (LSP) worden uitgewisseld. Deze verstrekkingen zijn op het LSP in Medicatieproces versie 6.12 en dat betreft een HL7v3-messaging standaard. In deze use case worden deze gegevens voor het PGO geconverteerd naar FHIR-resources.

===Domein===
Medicatieverstrekkingen vanuit het LSP.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van een medicatiegegevens vanuit een zorgaanbiederssysteem (XIS), via het LSP - met behulp van een vertaling naar FHIR - naar een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO): we noemen dit verstrekkingenvertaling.
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, zijn gedefinieerd in de informatiestandaard voor Medicatieproces 6.12 en de [[MedMij:V1.0_VerstrekkingenvertalingTransactie|bijbehorende vertaling]] naar het MP-9 datamodel. MP-6.12 verstrekkingen vertalen naar de MP-9 bouwstenen: toedieningsafspraak en verstrekking.

====Raadplegen verstrekkingenvertaling====
Informatie elementen in verstrekkingenvertaling staan hieronder. Om deze informatie in een nieuwe tab te openen, klik [https://decor.nictiz.nl/medicatieproces/mp-html-20181220T121121/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.161-2018-11-29T135611.html hier].

Dit betreft de inhoud van de transactie met verstrekkingenvertaling.

<html>
<iframe width="100%" height="500" src=https://decor.nictiz.nl/medicatieproces/mp-html-20181220T121121/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.161-2018-11-29T135611.html frameborder="0" align="middle"></iframe>
</html>

====Beschikbaarstellen verstrekkingenvertaling====
Informatie elementen in verstrekkingenvertaling staan hieronder. Om deze informatie in een nieuwe tab te openen, klik [https://decor.nictiz.nl/medicatieproces/mp-html-20181220T121121/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.162-2018-11-29T135611.html hier].

Dit betreft de inhoud van de transactie met verstrekkingenvertaling.

<html>
<iframe width="100%" height="500" src=https://decor.nictiz.nl/medicatieproces/mp-html-20181220T121121/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.162-2018-11-29T135611.html frameborder="0" align="middle"></iframe>
</html>

=== 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 verstrekkingenvertaling raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt verstrekkingenvertaling beschikbaar
|}
'''Bedrijfsrollen Verstrekkingenvertaling '''

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

[[Bestand:Activity Diagram - Verstrekkingenvertaling.png|Activiteitendiagram Raadplegen Verstrekkingenvertaling]]

'''Activiteitendiagram Raadplegen Verstrekkingenvertaling '''

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra 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 verstrekkingenvertaling een rol speelt.

<blockquote>Roos heeft de afgelopen tijd in verband met haar hartfalen en diabetes diverse wijzigingen in haar medicatie gehad. Dit is soms gedaan door de specialist en soms door de huisarts. De apotheker paste dan daarna ook soms de doseerinstructies aan, omdat er een ander product geleverd moest worden dan voorgeschreven was. Eigenlijk is Roos het overzicht een beetje kwijtgeraakt. Gelukkig heeft haar PGO wel de mogelijkheid om bij haar zorgverleners verstrekkingenvertaling op te vragen. Haar PGO kan dit aan haar presenteren in een overzichtelijk geheel. Roos kan nu controleren of ze al haar medicatie inneemt conform de laatste afspraken die hierover zijn gemaakt. Dit is voor Roos heel geruststellend.</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt verstrekkingenvertaling 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 medicatiegegevens tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil medicatiegegevens en/of verstrekkingenvertaling inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om een 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 verstrekkingenvertaling bij een XIS.
*Het systeem van de zorgaanbieder (XIS) levert verstrekkingenvertaling op voor de patiënt.
*Patiënt gebruikt de persoonlijke gezondheidsomgeving om verstrekkingenvertaling in te zien.

=====Post conditie=====
De patiënt kan verstrekkingenvertaling inzien via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om verstrekkingenvertaling van zorgaanbieder naar patiënt.

Een XIS vervult in deze use case de volgende systeemrol:
* Verstrekkingenvertalingbeschikbaarstellend Systeem in FHIR [MP-9.A.0-MGB-FHIR]

Een PGO vervult de volgende systeemrol:
* VerstrekkingenvertalingRaadplegend Systeem [MP-9.A.0-MGR-FHIR].

Zie ook onderstaande afbeelding.

[[Bestand:Component Diagram - Verstrekkingenvertaling (Totaal).png|Componenten diagram]]

'''Componenten diagram'''

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;"| '''Systeemrol'''
! 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"|Verstrekkingenvertaling (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen verstrekkingenvertaling
|style="background-color: white;vertical-align:top;"|MP-9.A.0-MGR-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:V2019.01_FHIR_MedicationProcess|Verstrekkingenvertaling in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen verstrekkingenvertaling
|style="background-color: white;vertical-align:top;"|MP-9.A.0-MGB-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 - Verstrekkingenvertaling.png|Use case diagram raadplegen Verstrekkingenvertaling]]

'''Use case diagram

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=

==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving
|-
| rowspan = 13; style="background-color: white;"| 2019.01
| rowspan = 13; style="background-color: white;"| 9.0.7
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-164 MM-164]
| style="background-color: white;"| Medicatietoediening - toegediende hoeveelheid - cardinality mismatch
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-162 MM-162]
| style="background-color: white;"| Update naar medicatieproces versie 9.0.7.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-134 MM-134]
| style="background-color: white;"| MedicationUse StopType found values do not correspond with MedicationUseStopTypeCodeList values.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-127 MM-127]
| style="background-color: white;"| TimeOfDay in InstructionsForUse and the Hapi Enumerators.
|-
| 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-106 MM-106]
| style="background-color: white;"| Het Bundle-MedicationOverview profiel en de technische wiki pagina beschrijven nu hoe de bundle.total bepaald wordt in de MedicationOverview response.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-102 MM-102]
| style="background-color: white;"| Bundle type 'collection' is vervangen door 'searchset' in de use case voor het raadplegen van het medicatieoverzicht.
|-
| 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-98 MM-98]
| style="background-color: white;"| InstructionsForUse zib informatie model komt niet overeen met simplifier.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-71 MM-71]
| style="background-color: white;"| reden wijzigen/stoppen gebruik onterecht gemapt op reasonNotTaken.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-48 MM-48]
| style="background-color: white;"| Medicatiegebruik/informant is zorgverlener: moet ook practitionerrole mogelijk maken.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-42 MM-42]
| style="background-color: white;"| medicatiegebruik - auteur - zorgverlener: kan niet alle info kwijt.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-41 MM-41]
| style="background-color: white;"| voorschrijver/zorgverlener/zorgaanbieder past niet in medicationUse.
|-
| rowspan = 3; style="background-color: white;"| 2018.06
| rowspan = 3; style="background-color: white;"| 9.0.6
| 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-105 MM-105]
| style="background-color: white;"| Raadplegen 6.12 medicatieverstrekkingen (bij apothekers).
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-23 MM-23]
| style="background-color: white;"| Commentaar bij dagdeel codelijst verwijst naar dode URL.
|}

==Paginahistorie==

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:Vprepub-2019.01 OntwerpMedicatie

2019-03-15T09:53:00Z

Tim Ruijters:

MedMij:V2019.01 FHIR MedicationProcess

2019-03-15T09:51:44Z

Tim Ruijters: /* History */

{{#customtitle:MedMij FHIR Implementation Guide Medication Process 9.0.7}}
{{MedMij:V2019.01_Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Medication_Icoon.png|link=|85px|links|Use case Medication|Medication process]]
<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:V2019.01_OntwerpMedicatie|Functional]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Tecnical]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:V2019.01_Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This page describes patient's use cases, in a personal health record (PHR) context, in relation to the information standard [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medication Process] (MP). These use cases are based on version 9.x of this standard. Functional specification of these use cases are described in the [[MedMij:V2019.01_Ontwerpen| functional design wiki page]]. The technical specification is described here. HL7 FHIR STU3 is used for this purpose.

The Medication Process information building blocks are adopted by 'Registratie aan de Bron' and converted to Health and Care Information models (HCIM), also called ZIB's. In order to exchange medication information between systems, FHIR representations of these HCIMs are made and used in the transactions described on this page.

Use cases:
* [[MedMij:V2019.01_FHIR_MedicationProcess#Use_case:_retrieve_medication_overview|Retrieve a medication overview]]
* [[MedMij:V2019.01_FHIR_MedicationProcess#Use_case:_retrieve_medication_information|Retrieve medication information]]
* [[MedMij:V2019.01_FHIR_MedicationProcess#Use_case:_retrieve_Dispense612ToFHIRConversion_from_the_LSP|Retrieve Dispense612ToFHIRConversion]]

=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 enviorment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/medication-clientcapabilities CapabilityStatement: Client]
| Medication process client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/medication-servercapabilities CapabilityStatement: Server]
| Medication process server requirements
|}

=Use case: retrieve medication overview=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve medication overview transaction is used by the PHR to retrieve a medication overview 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 Medication Overview(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve medication overview request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request medication overview from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve medication overview response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves medication overview to the PHR
|}

==Invocations==
===PHR: request message===
This message uses an extended operation on the RESTful API to obtain a medication overview from a XIS. This operation is used because the XIS needs to play an active role in formulating the content of the response.

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

====Message Semantics====
The PHR executes a medication-overview operation with HTTP POST against the XIS's base endpoint as shown below.

<pre>
POST [base]/$medication-overview
</pre>

=====Expected Actions=====
The XIS shall process the operation to find or generate and return the current medication overview.

===XIS: response message===
The XIS returns a HTTP Status code appropriate to the processing of the operation as well as a Bundle of type 'searchset', containing one List and one Patient resource along with other resources that represent the Medication Overview.

====Trigger Events====
The XIS completed processing of the retrieve medication overview request message.

====Message Semantics====
Based on the medication-overview operation processing results, the XIS will either return an error or success. When the XIS needs to report an error, it shall use HTTP error response codes and shall include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not a Medication Overview is found or generated, the HTTP status code shall be 200.

The body of the response message shall be a Bundle resource of type "searchset". The following section will elaborate on the content included.

If the XIS is sending warnings, the Bundle resource shall also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/operations.html Operations]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/operationoutcome.html OperationOutcome resource]

=====Message content=====
The outcome of the [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/OperationDefinition/Medication-Overview medication-overview operation] is the body of the medication overview request message. Successful processing of this operation should result in a Bundle recourse, containing one List and one Patient resource as entries along with all the resources that represent the current medication overview. These resources SHALL be referenced from the List resource. The clinical content of the medication overview is defined in the [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicatieoverzicht_en_afleidingsregels Medication Process specification]. The functional dataset of the medication overview can be found on [http://decor.nictiz.nl/medicatieproces/mp-html-20170829T141253/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.148-2016-11-08T103441.html decor.nictiz.nl].

<html>
<iframe width="750" frameborder="1" height="400" src=https://www.simplifier.net/embed/render?id=NictizSTU3-Zib2017/Medication-Overview frameborder="0" align="middle"></iframe>
</html>

The content in the response message SHALL be a valid instance of the following profiles. Clicking on the link will open the formal definition on Simplifier.net.

* '''Bundle profile:''' [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/Bundle-MedicationOverview http://nictiz.nl/fhir/StructureDefinition/Bundle-MedicationOverview]
* '''List profile:''' [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/MedicationOverview http://nictiz.nl/fhir/StructureDefinition/MedicationOverview]

The Bundle profile represents the structure of the retrieve medication overview response message. The List profile represents the actual medication overview. The List contains the medication overview metadata and references to all resources that constitute the medication overview. These resources are included in the Bundle as entries. The Bundle.total value contains the number of matching HCIMs: MedicationUse, AdministrationAgreement and MedicationAgreement. Other included resources, such as Medication resources, are not included in the total. The returned Bundle has at least one List and one Patient resource.

All returned resources to the PHR, including the Bundle and List, SHALL include their related profile canonical URL in the ''meta.profile'' element in order to show compliance. The resources in the response message SHALL be a valid instance of these profiles. In the table below, the HCIMs that constitute the clinical content of the Medication Overview and their respective profiles are listed.

'''Note''' that the medication building blocks are grouped per 'medication treatment' conform the [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling Medication Process specification]. Grouping SHALL be done by use of a 'medication treatment' identifier. This identifier shall be the same across different related medication resources that constitute a medication treatment. The [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-Medication-MedicationTreatment zib-Medication-MedicationTreatment extension] is added to all medication profiles and can be used for this grouping purpose.

{{NoteBoxPackage|https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/1.1.0|1.1.0|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|HCIM name NL||HCIM name EN||FHIR Resource||FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patient
| #HCIM Patient|Patient
| Patient
| [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient]
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner]
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization]
|-
| Medicatiegebruik||MedicationUse||MedicationStatement|| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse]
|-
| Toedieningsafspraak||AdministrationAgreement||MedicationDispense|| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement]
|-
| Medicatieafspraak||MedicationAgreement||MedicationRequest|| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement]
|-
| Product||Product||Medication|| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-Product http://nictiz.nl/fhir/StructureDefinition/zib-Product]
|-
| GebruiksInstructie||InstructionsForUse||Dosage (datatype)|| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse]
|-
|}

====Expected Actions====
The PHR processes the results according to application-defined rules. The PHR should be robust as the response may contain medication information resources as mentioned in the former section.

==Interactions, operations, search parameters==
===Interactions===
No interactions are needed for the retrieve medication overview transaction.

===Operations===
The retrieve medication overview medication operation is used for this transaction. The formal definition can be found here:
* [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/MedicationOverview Medication Overview]

===Search parameters===
The following search parameter type needs to be supported for this transaction.

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]

=Use case: retrieve medication information=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The Retrieve Medication Information transaction is used by the PHR to retrieve medication information from the XIS. The PHR can use this transaction to retrieve the desired information by searching on specific medication building blocks.

==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 Medication Information(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve medication information request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request medication information from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve medication information response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves medication information to the PHR
|}

==Invocations==
===PHR: request message===
This message uses the HTTP GET method parameterized query to obtain medication information from a XIS. Multiple different HTTP GET request messages may be needed to retrieve all medication information.

====Trigger Events====
When the patient (PHR) wants to obtain medication information matching various parameters, it issues a retrieve medication information request message.

====Message Semantics====
The PHR executes an HTTP GET against the XIS's medication FHIR endpoints. These endpoints can be one of the following:
* MedicationRequest
* MedicationAdministration
* MedicationDispense
* MedicationStatement

The search interaction is performed by an HTTP GET conform the [http://hl7.org/fhir/STU3/search.html FHIR search specification], as shown below. This URL is configurable by the PHR by configuring the query search parameters and search control parameters to modify the behaviour of the XIS such as response format, or pagination.

<pre>
GET [base]/[type]{?[parameters]{&_format=[mime-type]}}
</pre>

=====Search on category code=====
To distinguish the medication HCIMs between each other and between general medication resources, a fixed category coding has been added to the medication HCIM profiles (listed below in the Message content section). The fixed category code is solely used for indexing and retrieval of the HCIM building blocks.

=====Including other resources in searchresults=====
The PHR may request that the XIS return resources related to the search results, in order to reduce the overall network delay of repeated retrievals of related resources. This is useful when the PHR is searching on a clinical resource, but for every such resource returned, the client will also need the subject (Patient resource) or prescriber (Practitioner resource) or medication that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. Example search:

<pre>
GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication
</pre>

This search interaction finds all MedicationRequest that represent the HCIM MedicationAgreement and if present includes the referenced Medication resource.

====Query Search Parameters====
The PHR may supply, and the XIS SHALL be capable of processing, all query parameters listed in the table below. The XIS may choose to support additional query parameters beyond the subset listed below. Any additional query parameters supported shall be supported according to the core FHIR specification. Such additional parameters are considered out of scope for this transaction.

{| class="wikitable"
! style="font-weight: bold;text-align:left;" | MP9 search parameters
! style="font-weight: bold;text-align:left;" | Description
! style="font-weight: bold;text-align:left;" | FHIR search parameter
! style="font-weight: bold;text-align:left;" | FHIR resource
|-
| Identification
| Search on identifier.
| identifier
| MedicationRequest, MedicationDispense, MedicationAdministration, MedicationStatement
|-
| Type
| Search on type of medication building block (HCIM).
| category '''*''' / '''**'''
| MedicationRequest, MedicationAdministration, MedicationDispense, MedicationStatement
|-
| ProductCode
| Search on medication code.
| code
| MedicationRequest, MedicationAdministration, MedicationDispense, MedicationStatement, Medication
|-
| UsePeriod
| Search on medication use in the past, present or future within the specified time period.
| periodofuse '''**'''
| MedicationDispense, MedicationRequest
|-
| DispensePeriod
| Returns all medication dispenses within the specific period.
| whenhandedover
| MedicationDispense
|-
| MedicationTreatment
| Search on the medication treatment identifier
| medicationtreatment '''**'''
| MedicationRequest, MedicationAdministration, MedicationDispense, MedicationStatement, System Wide
|}

'''*''' The FHIR profiles that represent the medication building blocks contain fixed code values in the ''.category'' elements to allow searching on specific medication building blocks. FHIR resources MedicationAdministration and MedicationDispense do not contain a 'category' search parameter in the FHIR specification. Custom search parameters are provided.

'''**''' The search parameter consists of a custom created FHIR search parameter not represented in the FHIR specification.

=====Custom Search Parameters=====

The following custom search parameters are defined for this use case:

* [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/SearchParameter/Medications-category http://nictiz.nl/fhir/SearchParameter/Medications-category]
* [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/SearchParameter/Medications-periodofuse http://nictiz.nl/fhir/SearchParameter/Medications-periodofuse]
* [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/SearchParameter/Medications-medicationtreatment http://nictiz.nl/fhir/SearchParameter/Medications-medicationtreatment]

====Example Searches====

'''Identifier'''
<pre>1. [base]/MedicationRequest?identifier=http://example.nl/fhir/NamingSystem/MedicationRequest|999922448 </pre>
# Retrieves a MedicationRequest resource with the identifier 999922448.

'''Type'''
<pre>1. [base]/MedicationRequest
2. [base]/MedicationRequest?category=http://snomed.info/sct|16076005</pre>
# Retrieves all MedicationRequest resources.
# Retrieves all MedicationRequest resources that represent a HCIM MedicationAgreement.

'''ProductCode'''
<pre>1. [base]/MedicationRequest?medication.code=urn:oid:2.16.840.1.113883.2.4.4.8|13610554
2. [base]/MedicationRequest?medication.code=urn:oid:2.16.840.1.113883.2.4.4.8|13610554&_include=MedicationRequest:medication
3. [base]/MedicationRequest?category=http://snomed.info/sct|16076005&medication.code=urn:oid:2.16.840.1.113883.2.4.4.8|13610554</pre>
# Retrieves all MedicationRequest resources that have Carbasalaatcalcium Sandoz 600 30 as medication.
# Retrieves all MedicationRequest resources that have Carbasalaatcalcium Sandoz 600 30 as medication and includes the Medication resource in the search results.
# Retrieves all MedicationRequest resources that represent a HCIM MedicationAgreement and have Carbasalaatcalcium Sandoz 600 30 as medication

'''UsePeriod'''
<pre>1. [base]/MedicationRequest?periodofuse=ge2010-01-01
2. [base]/MedicationDispense?periodofuse=ge2010-01-01&periodofuse=le2011-12-31
3. [base]/MedicationRequest?category=http://snomed.info/sct|16076005&periodofuse=ge2010-01-01</pre>
# Retrieves all MedicationRequest resources that were in effect after 01-01-2010.
# Retrieves all MedicationDispense resources that were in effect within a 2 year period.
# Retrieves all MedicationRequest resources that represent a HCIM MedicationAgreement and were in effect after 01-01-2010.

'''DispensePeriod'''
<pre>1. [base]/MedicationDispense?whenhandedover=ge2010-01-01
2. [base]/MedicationDispense?whenhandedover=ge2010-01-01&whenhandedover=le2011-12-31
3. [base]/MedicationDispense?whenhandedover=ge2010-01-01&category=http://snomed.info/sct|373784005
</pre>
# Retrieves all MedicationDispense resources that were handed over after 01-01-2010.
# Retrieves all MedicationDispense resources that were handed over within a 2 year period.
# Retrieves all MedicationDispense resources that represent a HCIM Dispense and were handed over after 01-01-2010.

'''MedicationTreatment'''
<pre>1. [base]/MedicationRequest?medicationtreatment=http://example.nl/fhir/NamingSystem/medicationtreatment|1247848
2. [base]/?medicationtreatment=http://example.nl/fhir/NamingSystem/medicationtreatment|1247848 </pre>
# Retrieves all MedicationRequest resources that are part of the medication treatment 1247848.
# Retrieves all MedicationRequest, MedicationDispense, MedicationAdministration, MedicationStatement resources that are part of the the medication treatment 1247848

=====Expected Actions=====
The XIS shall process the query to discover the medication information that match the search parameters given.

===XIS: response message===
The XIS returns a HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching medication information.

====Trigger Events====
The XIS completed processing of the Retrieve medication information request message.

====Message Semantics====
Based on the query results, the XIS will either return an error or success. When the XIS needs to report an error, it SHALL use HTTP error response codes and SHOULD include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not any medication resources are found, the HTTP status code SHALL be 200.

The response message SHALL be a Bundle resource of type "searchset" containing zero or more FHIR resources as entries. If the XIS is sending warnings, the Bundle resource SHALL also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/STU3/search.html#errors Search errors]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR SHALL conform to the medication HCIMs profiles. The table below lists the medication HCIMs and their respective FHIR profiles. The resources in the response message SHALL be a valid instance of these profiles. All resources SHALL include their related profile canonical URL in the ''meta.profile'' element in order to show compliance.

'''Note''' that the medication building blocks are grouped per 'medication treatment' conform the [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling Medication Process specification]. Grouping SHALL be done by use of a 'medication treatment' identifier. This identifier shall be the same across different related medication resources that constitute a medication treatment. The [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-Medication-MedicationTreatment zib-Medication-MedicationTreatment extension] is added to all medication profiles and can be used for this grouping purpose.

{{NoteBoxPackage|https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/1.1.0|1.1.0|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable" width="1400px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|HCIM name NL||HCIM name EN||FHIR Resource||FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patient
| #ZIB Patient|Patient
| Patient
| [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient]
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner]
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization]
|-
| Medicatiegebruik||MedicationUse||MedicationStatement|| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse]
|-
| Medicatietoediening||MedicationAdministration||MedicationAdministration|| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAdministration http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAdministration]
|-
| Toedieningsafspraak||AdministrationAgreement||MedicationDispense|| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement]
|-
| Medicatieafspraak||MedicationAgreement||MedicationRequest|| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement]
|-
| Verstrekking||Dispense||MedicationDispense|| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-Dispense http://nictiz.nl/fhir/StructureDefinition/zib-Dispense]
|-
| Verstrekkingsverzoek||DispenseRequest||MedicationRequest|| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-DispenseRequest http://nictiz.nl/fhir/StructureDefinition/zib-DispenseRequest]
|-
| Product||Product||Medication|| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-Product http://nictiz.nl/fhir/StructureDefinition/zib-Product]
|-
| GebruiksInstructie||InstructionsForUse||Dosage (datatype)|| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse]
|-
|}

====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain medication information resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#search Search]

===Operations===
No operations are defined or needed for this transaction.

===Search parameters===
The following search parameter types and search result parameters need to be supported for this transaction.

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
* [http://hl7.org/fhir/STU3/search.html#date date]

Search result parameters:
* [http://hl7.org/fhir/STU3/search.html#include _include]

=Use case: retrieve Dispense612ToFHIRConversion from the LSP=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
This use case concerns the retrieval of medication dispenses and related medication information that is exchanged between healthcare providers on the 'Landelijk Schakelpunt' (LSP). Over the LSP, these medication dispenses are exchanged based on the information standard MedicationProces version 6.12 in HL7v3-messaging format. In this use case, the requested information by a PHR is converted to FHIR-resources by 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 Dispense612ToFHIRConversion(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve Dispense612ToFHIRConversion request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request Dispense612ToFHIRConversion from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve Dispense612ToFHIRConversion response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves Dispense612ToFHIRConversion to the PHR
|}

==Invocations==
===PHR: request message===
This message uses the HTTP GET method parameterized query to obtain medication information from a XIS.

====Trigger Events====
When the patient (PHR) wants to obtain Medication process Dispense 6.12 information matching various parameters, it issues a retrieve Dispense612ToFHIRConversion request message.

====Message Semantics====
The PHR executes an HTTP GET against the XIS's MedicationDispense FHIR endpoint. This URL is configurable by the PHR by configuring the query search parameters and search control parameters to modify the behaviour of the XIS such as response format, or pagination. The search interaction is performed by an HTTP GET conform the [http://hl7.org/fhir/STU3/search.html FHIR search specification] as shown:

<pre>
GET [base]/MedicationDispense{?[parameters]{&_format=[mime-type]}}
</pre>

=====Explict search on MedicationDispense and AdministrationAgreement=====
To distinguish the medication-related HCIMs between each other and between general medication resources, a fixed category coding has been added to the medication-related HCIM profiles (listed below in the Message content section). The fixed category code is solely used for indexing and retrieval of the HCIM building blocks.

For this use case, HCIMs MedicationDispense and AdministrationAgreement are requested from the XIS. Both HCIMs are represented by a MedicationDispense resource, however, the PHR makes an explicit request by searching on the category code for both HCIM's.

=====Including the Patient and Medication resources in searchresults=====
The PHR requests the XIS to return resources related to the MedicationDispense, namely the Patient and Medication resources. The _include parameter is used for this purpose. The request URL syntax is shown here:

<pre>
GET [base]/MedicationDispense?category=http://snomed.info/sct|373784005,422037009&_include=MedicationDispense:medication&_include=MedicationDispense:patient{&[parameters]{&_format=[mime-type]}}
</pre>

This search interaction Retrieves MedicationDispense resources that represent a MedicationDispense or AdministrationAgreement and includes the related Patient and Medication resources in the result.

====Query Search Parameters====
The PHR may supply, and the XIS SHALL be capable of processing, all query parameters listed in the table below.

{| class="wikitable"
! style="font-weight: bold;text-align:left;" | MP9 search parameters
! style="font-weight: bold;text-align:left;" | Description
! style="font-weight: bold;text-align:left;" | FHIR search parameter
|-
| UsePeriod
| Search on medication use in the past, present or future within the specified time period.
| periodofuse
|-
| DispensePeriod
| Returns all medication dispenses within the specific period.
| whenhandedover
|}

'''UsePeriod'''
<pre>
GET [base]/MedicationDispense?category=http://snomed.info/sct|373784005,422037009&_include=MedicationRequest:medication&_include=MedicationDispense:patient&periodofuse=ge2010-01-01&periodofuse=le2011-12-31
</pre>
Retrieves MedicationDispense resources that represent a HCIM MedicationDispense or AdministrationAgreement, were in effect within a 2 year period and includes related Medication and Patient resources in the result.

'''DispensePeriod'''
<pre>
GET [base]/MedicationDispense?category=http://snomed.info/sct|373784005,422037009&_include=MedicationRequest:medication&_include=MedicationDispense:patient&whenhandedover=ge2010-01-01
</pre>
Retrieves MedicationDispense resources that represent a HCIM MedicationDispense or AdministrationAgreement, that were handed over after 01-01-2010 and includes related Medication and Patient resources in the result.

=====Custom Search Parameters=====
The following custom search parameters are defined for this use case:

* [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/SearchParameter/Medications-category http://nictiz.nl/fhir/SearchParameter/Medications-category]
* [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/SearchParameter/Medications-periodofuse http://nictiz.nl/fhir/SearchParameter/Medications-periodofuse]

===XIS: response message===
The XIS returns a HTTP Status code appropriate to the processing of the request as well as a Bundle of type searchset.

====Trigger Events====
The XIS completed processing of the retrieve medication overview request message.

====Message Semantics====
Based on the retrieve Dispense612ToFHIRConversion request processing results, the XIS will either return an error or success. When the XIS needs to report an error, it shall use HTTP error response codes and shall include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not MedicationDispense resources are found or generated, the HTTP status code shall be 200.

The body of the response message shall be a Bundle resource of type "searchset". The following section will elaborate on the content included.

If the XIS is sending warnings, the Bundle resource shall also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR SHALL conform to the profiles listed in the table below. The resources in the response message SHALL be a valid instance of these profiles. All resources SHALL include their respective profile canonical URL in the ''meta.profile'' element to show compliance.

These profiles are derived from the HCIM profiles. This use case has a very specific and stable underlying dataset. Therefore, the profiles contain many mandatory elements. Within the Medication Process dataset, there is a difference between the concept cardinalities '1..* Required' and '1..* Mandatory'.: The first means the element is required to be present, if the system possesses the information and the latter means the element should always be present. Both are mapped to a mandatory cardinality in the FHIR profiles. If the XIS is not able to provide the required information for a mandatory element, it shall use a nullFlavor extension (http://hl7.org/fhir/STU3/extension-iso21090-nullflavor) to indicate that and why the information is not present. The PHR should be able to process nullFlavor extensions and values.

{{NoteBoxPackage|https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/1.1.0|1.1.0|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable" width="1400px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|HCIM name NL||HCIM name EN||FHIR Resource||FHIR Profile url
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patient
| Patient
| Patient
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-Patient http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-Patient]
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-Organization http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-Organization]
|-
| Toedieningsafspraak
| AdministrationAgreement
| MedicationDispense
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-AdministrationAgreement http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-AdministrationAgreement]
|-
| Verstrekking
| Dispense
| MedicationDispense
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-Dispense http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-Dispense]
|-
| Product
| Product
| Medication
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-Product http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-Product]
|-
|}

====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain medication information resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#search Search]

===Operations===
No operations are defined or needed for this transaction.

===Search parameters===
The following search parameter types and search result parameters need to be supported for this transaction.

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
* [http://hl7.org/fhir/STU3/search.html#date date]

Search result parameters:
* [http://hl7.org/fhir/STU3/search.html#include _include]

=Terminology, NamingSystems, Mappings=

===Terminology===
Relevant ValueSets can be found through the ValueSet bindings in the listed StructureDefinitions. All ValueSets can be found here [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ValueSet here] and can be downloaded as a .zip in XML or JSON format.

===NamingSystems===
Relevant NamingSystems can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=NamingSystem here].

===Mappings===
A FHIR ConceptMap resource is provided when a FHIR value set is used instead of a HCIM value set. A ConceptMap maps the values between the two value sets. ConceptMaps can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ConceptMap here].

All profiles include HCIM mappings and are redered on Simplifier.net under the 'Mapping' tab of a profile. HCIM concepts are mapped to the corresponding FHIR elements using the HCIMs concept id. The top of the StructureDefinition contains meta information regarding the HCIM mapping, such as the name and uri of the HCIM or dataset. In the StructureDefinition elements, the corresponding HCIM concept or functional dataset concept ID is given including the mapping meta information id. This is illustrated in the following example.

<pre>
<StructureDefinition>
<id value="nl-core-patient" />
.....
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<uri value="https://zibs.nl/wiki/Patient-v3.1(2017EN)"/>
<name value="HCIM Patient-v3.1(2017EN)"/>
</mapping>
.....
<element id="Patient.name">
<path value="Patient.name" />
<short value="NameInformation" />
<alias value="Naamgegevens" />
<type>
<code value="HumanName" />
<profile value="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname" />
</type>
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<map value="NL-CM:0.1.6"/>
</mapping>
</element>
.....
</StructureDefinition>
</pre>

=Examples=

# Medicatieproces has a wiki page that contains [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0_Voorbeelden_doseringen examples in FHIR and CDA for dosage instructions].
# Every profile or resource on Simplifier has a reference tab. The reference tab shows all references from and to the selected resource. So the listed profiles in these use cases have a reference tab on Simplifier where examples are listed that declare conformance to the specific profile.
# Examples are accessible through the Simplifier project by going to the resources tab of the project. It is possible to filter on examples and underlying FHIR resource. This is clarified with the following URL, which lists all medication examples available in the NictizSTU3-zib2017 project: https://simplifier.net/NictizSTU3-Zib2017/~resources?category=Example&exampletype=MedicationDispense|MedicationStatement|MedicationRequest|Medication|MedicationAdministration&fhirVersion=STU3&sortBy=DisplayName

=Annex: Document history=
==Release notes==
Release notes can be found on the [[MedMij:V2019.01_OntwerpMedicatie#Release_notes| functional design page]].

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
*Publication of changes in version 2019.01, conform release notes.
*Moved release notes to functional design page.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* finished use case Dispense612ToFHIRConversion.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* MM-106 - Bundle.total verduidelijkt bij MedicationOverview use case.
* replaced HCIM name MedicationUsage to MedicationUse.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Moved release notes to the functional design page.
* Replaced ZIB with HCIM.
* Textual improved the PHR request message section of the Medication Information use case.
* Added draft of use case retrieve Dispense612ToFHIRConversion from the LSP.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 12-12-2018
| style="background-color: white;"| Replaced "https://vonk.test-nictiz.nl" with [base]
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 12-11-2018
| style="background-color: white;"| Added Terminology, NamingSystems, Mappings section
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"| Added version in title, and document history
|}

[[categorie:MedMij FHIR Use Cases]]

MedMij:Vprepub-2019.01 FHIR MedicationProcess

2019-03-15T09:51:44Z

Tim Ruijters: /* History */

MedMij:V2019.01 OntwerpeAfspraak

2019-03-15T09:34:58Z

Tim Ruijters:

__NUMBEREDHEADINGS__
{{#customtitle:Functioneel Ontwerp eAfspraak 1.1.0}}
{{MedMij:V2019.01_Issuebox}}

[[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 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:V2019.01_Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_eAfspraak|Tecnical]]
desc none
</imagemap>

<div class="toclimit-{{{2|{{{limit|3}}}}}}">__TOC__</div>

=Inleiding=

==Algemeen==
Deze pagina beschrijft use cases waarbij een patiënt afspraken kan raadplegen, maken, annuleren of wijzigen met behulp van een persoonlijke gezondheidsomgeving. Algemene informatie betreffende deze use cases kan gevonden worden op deze [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_Ontwerpen wiki pagina].

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

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

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

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

==Kwalificatie==
{{#lst:MedMij:V2019.01_Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
Deze sectie vervolgt met de volgende use cases:
*[[#Use_case:_Afspraak_raadplegen_door_pati.C3.ABnt|Afspraak raadplegen]]
*[[#Use_case:_Afspraak_maken_door_pati.C3.ABnt|Afspraak maken]]
*[[#Use_case:_Afspraak_annuleren_door_pati.C3.ABnt|Afspraak annuleren]]
*[[#Use_case:_Afspraak_wijzigen_door_pati.C3.ABnt|Afspraak wijzigen]]

Buiten scope van deze use cases vallen:
*Abonnementsservice
*Notificaties

==Use case: Afspraak raadplegen door patiënt==
===Doel en relevantie===
Inzicht in afspraken biedt patiënten overzicht en gebruiksgemak. Dit draagt bij aan meer grip op de eigen gezondheidsgegevens en daarmee ook meer regie over de eigen gezondheid.

===Domein===
Afspraken met zorggebruikers (patiënten / cliënten) in het domein van de zorg.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van afspraken 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 afspraak ====
Het raadplegen van een afspraak gaat van een specifieke patiënt naar een specifieke organisatie in de zorg (bijvoorbeeld een zorgaanbieder).

Verdere informatie-elementen in de vraag om afspraken zijn:
*periode (startdatum - einddatum) waarin de afspraak plaats heeft gehad / heeft / zal hebben
Dit betreft dus de filtermogelijkheden (query parameters) in de vraag om afspraken.

====Beschikbaarstellen afspraak ====
De informatie-elementen voor beschikbaarstellen afspraak staan in [https://decor.nictiz.nl/art-decor/decor-scenarios--eafspraken-?id=2.16.840.1.113883.2.4.3.11.60.61.4.3&effectiveDate=2017-10-10T14%3A19%3A43&datasetId=2.16.840.1.113883.2.4.3.11.60.61.1.1&datasetEffectiveDate=2017-08-01T14%3A56%3A38&conceptId=2.16.840.1.113883.2.4.3.11.60.61.2.1&conceptEffectiveDate=2017-08-01T14%3A56%3A38&language=nl-NL&scenariotree=true ART-DECOR eAfspraak]

=== 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 afspraken raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt afspraken beschikbaar
|}
'''Bedrijfsrollen afspraak inzien'''

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

[[Bestand:Activity Diagram - Afspraak raadplegen.png|Activiteitendiagram afspraak raadplegen]]

'''Activiteitendiagram afspraak raadplegen'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier].

Hieronder een aantal voor Thomas relevante situaties waarbij het raadplegen van afspraken een rol speelt.

<blockquote>Thomas heeft iedere drie maanden een controle in het ziekenhuis in verband met zijn Diabetes aandoening. De eerstkomende afspraak is op vrijdag 6 oktober 2017 om 10:30u met internist Janssen bij het Antonius Ziekenhuis in Rotterdam en duurt een uur. Het ziekenhuisinformatiesysteem heeft deze afspraak beschikbaar gemaakt voor de persoonlijke gezondheidsomgeving van Thomas. Thomas kan deze afspraak dan ook inzien via zijn persoonlijke gezondheidsomgeving.
----
Op 6 september belt de afdelingssecretaresse van het ziekenhuis. Zij heeft het verzoek aan Thomas of de afspraak verzet kan worden naar dinsdag 3 oktober om 16:00 uur. Dat komt hem prima uit, dus hij gaat akkoord. Het ziekenhuisinformatiesysteem maakt deze nieuwe afspraakinformatie beschikbaar voor de persoonlijke gezondheidsomgeving. Wanneer Thomas later die dag kijkt, ziet hij ook de bijgewerkte afspraakinformatie in zijn persoonlijke gezondheidsomgeving. Wel zo makkelijk, want hij was het eerder die dag vergeten op te schrijven.
</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt de afspraak 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 afspraken tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil afspraken inzien en de zorgaanbieder stelt dit ook beschikbaar.
Een patiënt neemt steeds zelf het initiatief om zijn afspraken te raadplegen.

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

=====Post conditie=====
De patiënt heeft afspraken geraadpleegd via de persoonlijke gezondheidsomgeving.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om afspraken van zorgaanbieder naar patiënt. De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Syteem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Afkorting
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| AfspraakRaadplegend
| style="background-color: white;"| EA-1.1.0-AFR-FHIR
| style="background-color: white;"| Raadplegen afspraak bij zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| AfspraakBeschikbaarstellend
| style="background-color: white;"| EA-1.1.0-AFB-FHIR
| style="background-color: white;"| Beschikbaarstellen afspraak aan de patiënt
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component Diagram - Afspraak raadplegen (Totaal).png |Componenten diagram afspraak raadplegen]]

'''Componenten diagram afspraak raadplegen'''

=== 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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Afspraken (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen afspraak
|style="background-color: white;vertical-align:top;"|EA-1.1.0-AFR-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:V2019.01_FHIR_eAfspraak|eAfspraak in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen afspraak
|style="background-color: white;vertical-align:top;"|EA-1.1.0-AFB-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 - Afspraak raadplegen.png|Use case diagram afspraak raadplegen]]

'''Use case diagram afspraak raadplegen

==Use case: Afspraak maken door patiënt==
===Doel en relevantie===
Het maken van afspraken via een persoonlijke gezondheidsomgeving biedt patiënten gebruiksgemak. Dit draagt bij aan meer grip op de eigen gezondheidsgegevens en daarmee ook meer regie over de eigen gezondheid.

===Domein===
Afspraken met zorggebruikers (patiënten / cliënten) in het domein van de zorg.

===Context===
Het gaat om het elektronisch en gestructureerd afspraken kunnen maken vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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, zijn vastgelegd in [https://decor.nictiz.nl/art-decor/decor-scenarios--eafspraken-?id=2.16.840.1.113883.2.4.3.11.60.61.4.3&effectiveDate=2017-10-10T14%3A19%3A43&datasetId=2.16.840.1.113883.2.4.3.11.60.61.1.1&datasetEffectiveDate=2017-08-01T14%3A56%3A38&conceptId=2.16.840.1.113883.2.4.3.11.60.61.2.1&conceptEffectiveDate=2017-08-01T14%3A56%3A38&language=nl-NL&scenariotree=true ART-DECOR eAfspraak].

=== 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;"|Raadplegen afspraak slots

Sturen afspraakverzoek
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen afspraak slots

Ontvangen afspraak verzoek
|}
'''Bedrijfsrollen Afspraak inzien'''

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

[[Bestand:Activity Diagram - Afspraak maken.png|Activiteitendiagram afspraak maken]]

'''Activiteitendiagram maken afspraak'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier].

Hieronder een voor Thomas relevante situatie waarbij het maken van afspraken een rol speelt.

<blockquote>De persoonlijke gezondheidsomgeving van Thomas en het ziekenhuisinformatiesysteem (ZIS) van het Noorderziekenhuis in Groningen zijn verbonden vanwege een eerder bezoek van Thomas in het ziekenhuis.

Thomas wil een afspraak maken voor de driemaandelijkse controle met een diabetesverpleegkundige. Hij wil dit ergens in de tweede week van januari. Zijn persoonlijke gezondheidsomgeving haalt de beschikbare tijden voor deze afspraak op uit het Groningse ziekenhuisinformatiesysteem. Thomas kiest voor woensdag 10 januari van 14:00 – 15:00 uur. Dit verzoek gaat via zijn persoonlijke gezondheidsomgeving naar het ziekenhuisinformatiesysteem, dat de ontvangst van dit verzoek bevestigt. De afspraak is door Thomas te raadplegen via zijn persoonlijke gezondheidsomgeving.
</blockquote>

====Proces====
Het deel van het proces waar het hier om gaat betreft:
*Een persoonlijke gezondheidsomgeving kan voor een bepaalde periode én een bepaald type afspraak de beschikbare tijden ophalen uit het XIS. Dit betreft het raadplegen van beschikbare afspraak slots. Een XIS stelt deze beschikbaar.
*Een persoonlijke gezondheidsomgeving kan - op basis van beschikbare slots - een verzoek tot het maken van een concrete afspraak doen aan het XIS. Een XIS kan een dergelijk afspraakverzoek wel/niet in behandeling nemen en stuurt daarvan een bevestiging.

=====Preconditie=====
De patiënt heeft toestemming gegeven voor het elektronisch maken van afspraken tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.
De patiënt wil bepaalde typen afspraken maken en de zorgaanbieder ondersteunt het maken van deze afspraken.

=====Proces stappen=====
*Het systeem van de zorgaanbieder (XIS) levert de beschikbare afspraak slots op basis van de filter criteria uit de persoonlijke gezondheidsomgeving.
*Het systeem van de patiënt (PGO) stuurt een verzoek om een bepaald type afspraak te maken in een bepaalde slot.
*Het systeem van de zorgaanbieder (XIS) ontvangt het afspraakverzoek en geeft een technisch antwoord. Het antwoord geeft aan of het verzoek wel of niet in behandeling genomen kan worden.

Indien een verzoek in behandeling genomen kan worden door XIS, dan kan verwerking enige tijd vergen. Het verzoek wordt niet altijd direct afgehandeld.

Bij een eventueel negatief antwoord van het XIS kan een patiënt ervoor kiezen het opnieuw proberen, bijvoorbeeld met een ander (opnieuw opgevraagd) slot.

=====Post conditie=====
Een persoonlijke gezondheidsomgeving heeft antwoord ontvangen van een XIS over een afspraakverzoek.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt. De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Syteem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Afkorting
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;vertical-align:top;" rowspan="2"| PGO
| style="background-color: white;"| AfspraakSlotsRaadplegend
| style="background-color: white;"| EA-1.1.0-ASR-FHIR
| style="background-color: white;"| Raadplegen afspraak slots bij de zorgaanbieder
|-
| style="background-color: white;"| AfspraakverzoekSturend
| style="background-color: white;"| EA-1.1.0-AVS-FHIR
| style="background-color: white;"| Sturen afspraakverzoek naar zorgaanbieder
|-
| style="background-color: white;vertical-align:top;" rowspan="2"| XIS
| style="background-color: white;"| AfspraakSlotsBeschikbaarstellend
| style="background-color: white;"| EA-1.1.0-ASB-FHIR
| style="background-color: white;"| Beschikbaarstellen afspraak slots
|-
| style="background-color: white;"| AfspraakverzoekOntvangend
| style="background-color: white;"| EA-1.1.0-AVO-FHIR
| style="background-color: white;"| Ontvangen afspraakverzoek van de patient
|-
|}
Zie ook onderstaande afbeelding.

[[Bestand:Component Diagram - Afspraak maken (Totaal).png|Componenten diagram afspraak maken]]

'''Componenten diagram afspraak maken'''

=== 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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|AfspraakSlots (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen afspraak slots
|style="background-color: white;vertical-align:top;"|EA-1.1.0-ASR-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="6"|[[MedMij:V2019.01_FHIR_eAfspraak|eAfspraak in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen afspraak slots
|style="background-color: white;vertical-align:top;"|EA-1.1.0-ASB-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"|AfspraakVerzoek (PUSH)
|style="background-color: white;vertical-align:top;"|Sturen afspraakverzoek
|style="background-color: white;vertical-align:top;"|EA-1.1.0-AVS-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;"|Ontvangen afspraakverzoek
|style="background-color: white;vertical-align:top;"|EA-1.1.0-AVO-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 - Afspraak maken.png|Use case diagram afspraak maken]]

'''Use case diagram afspraak maken

==Use case: Afspraak annuleren door patiënt==
===Doel en relevantie===
Inzicht in afspraken biedt patiënten overzicht en gebruiksgemak. Dat is een functionaliteit die voorwaardelijk is voor deze use case: 'annuleren van afspraken'. Een patiënt is verder geholpen door ook afspraken te kunnen annuleren vanuit een persoonlijke gezondheidsomgeving. Dit draagt bij aan meer grip op de eigen gezondheidsgegevens en daarmee ook meer regie over de eigen gezondheid.

===Domein===
Afspraken met zorggebruikers (patiënten / cliënten) in het domein van de zorg.

===Context===
Het gaat om het kunnen annuleren van een afspraak vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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, zijn gedefinieerd in [https://decor.nictiz.nl/art-decor/decor-scenarios--eafspraken-?id=2.16.840.1.113883.2.4.3.11.60.61.4.3&effectiveDate=2017-10-10T14%3A19%3A43&datasetId=2.16.840.1.113883.2.4.3.11.60.61.1.1&datasetEffectiveDate=2017-08-01T14%3A56%3A38&conceptId=2.16.840.1.113883.2.4.3.11.60.61.2.1&conceptEffectiveDate=2017-08-01T14%3A56%3A38&language=nl-NL&scenariotree=true ART-DECOR eAfspraak].

=== 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;"|Raadplegen afspraak
Sturen afspraak annulering
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen afspraak
Ontvangen afspraak annulering
|}
'''Bedrijfsrollen afspraken inzien'''

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

[[Bestand:Activity Diagram - Afspraak annuleren.png|Activiteitendiagram afspraak annuleren]]

'''Activiteitendiagram afspraak annuleren'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier].

Hieronder een voor Thomas relevante situatie waarbij het annuleren van afspraken een rol speelt.

<blockquote>Thomas verhuist halverwege oktober 2017 voor zijn afstuderen naar Groningen. De afspraak voor de driemaandelijkse controle was al gemaakt in Rotterdam voor vrijdag 5 januari 2018. Thomas wil nu die afspraak afzeggen omdat hij die dag bezet is vanwege zijn afstudeerstage. Een nieuwe afspraak maakt hij liever in Groningen, dat is voor hem nu veel handiger.
Hij gebruikt zijn PGO om een verzoek te doen de afspraak in Rotterdam te annuleren. Een aantal uren later bevestigt de medisch secretaresse deze annulering. Thomas kan de afspraken weer raadplegen via zijn PGO.
</blockquote>

====Proces====
Het deel van het proces waar het hier om gaat betreft:
*Een persoonlijke gezondheidsomgeving kan achterhalen welk afspraken het verbonden XIS heeft voor de patiënt. Dit betreft het raadplegen van afspraken. Een XIS stelt deze beschikbaar.
*Een persoonlijke gezondheidsomgeving kan voor een bestaande afspraak een verzoek doen tot annulering. Een XIS ontvangt, behandelt en beantwoordt een dergelijk verzoek.

Een PGO heeft afspraken geraadpleegd en opvolging verzoek beoordeeld. Mocht het verzoek niet verwerkt zijn, kan een patiënt ervoor kiezen het opnieuw te proberen, of op een andere manier de zorgaanbieder te benaderen. Indien het verzoek verwerkt is, stelt XIS bij raadpleging door PGO de afspraak met status ‘geannuleerd’ beschikbaar.

=====Preconditie=====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van informatie over afspraken tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.
De patiënt wil bepaalde afspraken kunnen annuleren en de zorgaanbieder ondersteunt dit.

=====Proces stappen=====
*Het systeem van de patiënt (PGO) raadpleegt de beschikbare afspraken bij een XIS.
*Het systeem van de zorgaanbieder (XIS) levert de afspraken op voor de patiënt.
*Het systeem van de patiënt (PGO) stuurt een verzoek om de bestaande afspraak te annuleren.
*Het systeem van de zorgaanbieder (XIS) ontvangt de annulering en geeft een technisch antwoord. Het antwoord kan positief of negatief zijn voor het doorvoeren van de annulering.
*Het systeem van de patiënt (PGO) raadpleegt de beschikbare afspraken bij een XIS.
*Het systeem van de zorgaanbieder (XIS) levert de afspraken (waaronder de geannuleerde afspraak met status 'geannuleerd') op voor de patiënt.

Indien het verzoek verwerkt kan worden, stelt XIS de afspraak met status 'geannuleerd' beschikbaar, na raadpleging door patiënt vanuit zijn PGO.

=====Post conditie=====
Een persoonlijke gezondheidsomgeving heeft antwoord ontvangen van een XIS over een verzoek tot annulering van een afspraak.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. Hier gaat het om medicatieoverzichten van zorgaanbieder naar patiënt. De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Syteem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Afkorting
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;" rowspan="2"| PGO
| style="background-color: white;"| AfsprakenRaadplegend
| style="background-color: white;"| EA-1.1.0-AFR-FHIR
| style="background-color: white;"| Raadplegen afspraken bij de zorgaanbieder
|-
| style="background-color: white;"| AfspraakAnnuleringSturend
| style="background-color: white;"| EA-1.1.0-AAS-FHIR
| style="background-color: white;"| Sturen afspraak annulering naar de zorgaanbieder
|-
| style="background-color: white;" rowspan="2"| XIS
| style="background-color: white;"| AfsprakenBeschikbaarstellend
| style="background-color: white;"| EA-1.1.0-AFB-FHIR
| style="background-color: white;"| Beschikbaarstellen afspraken aan de patiënt
|-
| style="background-color: white;"| AfspraakAnnuleringOntvangend
| style="background-color: white;"| EA-1.1.0-AAO-FHIR
| style="background-color: white;"| Ontvangen afspraak annulering van de patiënt
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component Diagram - Afspraak annuleren (Totaal).png |Componenten diagram afspraak annuleren]]

'''Componenten diagram afspraak annuleren'''

=== 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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Afspraken (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen afspraak
|style="background-color: white;vertical-align:top;"|EA-1.1.0-AFR-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:V2019.01_FHIR_eAfspraak|eAfspraak in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen afspraak
|style="background-color: white;vertical-align:top;"|EA-1.1.0-AFB-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"|AfspraakAnnulering (PUSH)
|style="background-color: white;vertical-align:top;"|Sturen afspraak annulering
|style="background-color: white;vertical-align:top;"|EA-1.1.0-AAS-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;"|Ontvangen afspraak annulering
|style="background-color: white;vertical-align:top;"|EA-1.1.0-AAO-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 - Afspraak annuleren.png |Use case diagram afspraak annuleren]]

'''Use case diagram afspraak annuleren

==Use case: Afspraak wijzigen door patiënt==
===Doel en relevantie===
Inzicht in en het maken van afspraken biedt patiënten overzicht en gebruiksgemak. Dat zijn functionaliteiten die voorwaardelijk zijn voor deze use case: 'wijzigen van afspraken'. Een patiënt is verder geholpen door ook afspraken te kunnen wijzigen vanuit een persoonlijke gezondheidsomgeving. Een wijziging kan ook een annulering betreffen. Dit draagt verder bij aan meer grip op de eigen gezondheidsgegevens en daarmee ook meer regie over de eigen gezondheid.

===Domein===
Afspraken met zorggebruikers (patiënten / cliënten) in het domein van de zorg.

===Context===
Het gaat om het kunnen wijzigen van een afspraak vanuit een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO) naar een 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, zijn gedefinieerd in [https://decor.nictiz.nl/art-decor/decor-scenarios--eafspraken-?id=2.16.840.1.113883.2.4.3.11.60.61.4.3&effectiveDate=2017-10-10T14%3A19%3A43&datasetId=2.16.840.1.113883.2.4.3.11.60.61.1.1&datasetEffectiveDate=2017-08-01T14%3A56%3A38&conceptId=2.16.840.1.113883.2.4.3.11.60.61.2.1&conceptEffectiveDate=2017-08-01T14%3A56%3A38&language=nl-NL&scenariotree=true ART-DECOR eAfspraak].

=== 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;"|Raadplegen afspraak

Raadplegen afspraak slots

Sturen afspraak wijzigingsverzoek
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen afspraak

Beschikbaarstellen afspraak slots

Ontvangen afspraak wijzigingsverzoek
|}
'''Bedrijfsrollen afspraken inzien'''

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

[[Bestand:Activity Diagram - Afspraak wijzigen.png|Activiteitendiagram afspraak wijzigen]]

'''Activiteitendiagram afspraak wijzigen'''

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier].

Hieronder een voor Thomas relevante situatie waarbij het wijzigen van afspraken een rol speelt.

<blockquote>In de loop van december krijgt Thomas een buitenkansje. Een aantal van zijn vrienden gaan met skivakantie van zaterdag 5 t/m 12 januari en er is een plekje vrijgekomen. Voor een zacht prijsje kan hij mee. Daar heeft hij veel zin in!

Thomas zet de skivakantie ‘s avonds laat in zijn agenda en ziet dat dit conflicteert met zijn controle-afspraak in het Noorderziekenhuis op 10 januari. Hij moet die afspraak gaan verzetten. Het is 23:15 en dus te laat om het ziekenhuis hiervoor direct te bellen.

Via zijn PGO kijkt hij daarom naar beschikbare tijden in de derde week van januari. Er blijkt gelukkig nog een gaatje te zijn op vrijdag 19 januari om 11:30 – 12:30. Het verzoek om te wijzigen gaat via zijn PGO naar het ZIS, dat de ontvangst van het verzoek bevestigt. Bij raadpleging van de afspraken vanuit PGO, stelt XIS de nieuwe afspraak beschikbaar, alsmede de oorspronkelijke afspraak met status ‘ geannuleerd’.
</blockquote>

====Proces====
Het deel van het proces waar het hier om gaat betreft:
*Het systeem van een zorgaanbieder (XIS) stelt afspraken beschikbaar aan het systeem van een patiënt (PGO).
*Een persoonlijke gezondheidsomgeving kan voor een bepaalde periode én een bepaald type afspraak de beschikbare tijden ophalen uit het XIS. Dit betreft het raadplegen van beschikbare afspraak slots. Een XIS stelt deze beschikbaar.
*Een persoonlijke gezondheidsomgeving kan - op basis van beschikbare slots - een verzoek tot het wijzigen van een concrete afspraak doen aan het XIS. Een XIS kan een dergelijk afspraak wijzigingsverzoek behandelen en ontvangst van het verzoek bevestigen.

=====Preconditie=====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van informatie over afspraken tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.
De patiënt wil een afspraak wijzigen en de zorgaanbieder ondersteunt het wijzigen van afspraken.

=====Proces stappen=====
*Het systeem van de patiënt (PGO) vraagt om beschikbare afspraken bij een XIS.
*Het systeem van de zorgaanbieder (XIS) levert de afspraken op voor de patiënt.
*Patiënt gebruikt de persoonlijke gezondheidsomgeving om afspraken in te zien en er één te selecteren die hij wil wijzigen.
*Het systeem van de patiënt (PGO) vraagt om beschikbare slots voor een bepaald type afspraak in een bepaalde tijdsperiode bij een XIS.
*Het systeem van de zorgaanbieder (XIS) levert de beschikbare afspraak slots op basis van de filter criteria uit de persoonlijke gezondheidsomgeving.
*Patiënt gebruikt de persoonlijke gezondheidsomgeving om beschikbare slots in te zien en er één te selecteren.
*Het systeem van de patiënt (PGO) stuurt een verzoek om de bestaande afspraak te wijzigen.
*Het systeem van de zorgaanbieder (XIS) ontvangt het afspraak wijzigingsverzoek en geeft een technisch antwoord. Het antwoord kan positief of negatief zijn voor de wijziging.

Patiënt raadpleegt opnieuw de afspraken vanuit zijn PGO + XIS stelt de nieuwe afspraak beschikbaar, alsmede de oorspronkelijke afspraak met status ‘geannuleerd’.

=====Post conditie=====
Een persoonlijke gezondheidsomgeving heeft antwoord ontvangen van een XIS over een afspraak wijzigingsverzoek.

Bij een eventueel negatief antwoord van het XIS kan een patiënt ervoor kiezen het opnieuw proberen, bijvoorbeeld met een ander (opnieuw opgevraagd) slot.
Bij een positief antwoord is de afspraak gewijzigd en inzichtelijk in zowel XIS als PGO.

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

Deze systemen hebben één of meer systeemrollen. Een systeemrol maakt het uitwisselen van bepaalde gegevens mogelijk. De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Syteem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Afkorting
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;" rowspan="3"| PGO
| style="background-color: white;"| AfspraakRaadplegend
| style="background-color: white;"| EA-1.1.0-AFO-FHIR
| style="background-color: white;"| Raadplegen afspraak bij zorgaanbieder
|-
| style="background-color: white;"| AfspraakSlotsRaadplegend
| style="background-color: white;"| EA-1.1.0-ASR-FHIR
| style="background-color: white;"| Raadplegen afspraak slots bij de zorgaanbieder
|-
| style="background-color: white;"| AfspraakWijzigingsverzoekSturend
| style="background-color: white;"| EA-1.1.0-AWS-FHIR
| style="background-color: white;"| Sturen afspraak wijzigingsverzoek
|-
| style="background-color: white;" rowspan="3"| XIS
| style="background-color: white;"| AfspraakBeschikbaarstellend
| style="background-color: white;"| EA-1.1.0-AFB-FHIR
| style="background-color: white;"| Beschikbaarstellen afspraak aan de patiënt
|-
| style="background-color: white;"| AfspraakSlotsBeschikbaarstellend
| style="background-color: white;"| EA-1.1.0-ASB-FHIR
| style="background-color: white;"| Beschikbaarstellen afspraak slots
|-
| style="background-color: white;"| AfspraakWijzigingsverzoekOntvangend
| style="background-color: white;"| EA-1.1.0-AWO-FHIR
| style="background-color: white;"| Ontvangen afspraak wijzigingsverzoek van de patiënt.
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component Diagram - Afspraak wijzigen (Totaal).png|Componenten diagram afspraak wijzigen]]

'''Componenten diagram afspraak wijzigen'''

=== 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;"| '''Systeemrol'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Afspraken (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen afspraak
|style="background-color: white;vertical-align:top;"|EA-1.1.0-AFR-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="8"|[[MedMij:V2019.01_FHIR_eAfspraak|eAfspraak in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen afspraak
|style="background-color: white;vertical-align:top;"|EA-1.1.0-AFB-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"|AfspraakSlots (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen afspraak slots
|style="background-color: white;vertical-align:top;"|EA-1.1.0-ASR-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;"|Beschikbaarstellen afspraak slots
|style="background-color: white;vertical-align:top;"|EA-1.1.0-ASB-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"|AfspraakWijziging (PUSH)
|style="background-color: white;vertical-align:top;"|Sturen afspraak wijzigingsverzoek
|style="background-color: white;vertical-align:top;"|EA-1.1.0-AWS-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;"|Ontvangen afspraak wijzigingsverzoek
|style="background-color: white;vertical-align:top;"|EA-1.1.0-AWO-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 - Afspraak wijzigen.png|Use case diagram afspraak wijzigen]]

'''Use case diagram afspraak wijzigen

=Functionaliteit=
-

=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;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
'''Referenties

=Bijlage: Documenthistorie=

==Release notes==

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

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-104 MM-104]
| style="background-color: white;"| XIS kan wijzigingen en annuleringen niet naar PGO pushen. Scope van informatiestandaard aangepast.
|}

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
* Wijzigingen gepubliceerd in versie 2019.01, zie release notes.
* Verplaatsing release notes naar functionele pagina.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 10-01-2019
| style="background-color: white;"|
* Aanpassing kwalificatieparagraaf
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"|
* Aanpassing versienummer in titel.
* Toevoeging documenthistorie.
|}

MedMij:Vprepub-2019.01 OntwerpeAfspraak

2019-03-15T09:34:58Z

Tim Ruijters: