Huidige versie van 22 nov 2022 om 13:35

1 Introduction

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 HL7 Vital Signs profiles. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

Note: This implementation guide builds on the general guidelines described in the use case overarching principles.

Because the base vital signs profile constrains the .code and the .component.code to the datatype quantity it is not possible to add additional zib concepts. A GForge 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:

2 Actors involved

Persons		Systems		FHIR Capability Statements
Name	Description	Name	Description	Name	Description
Patient	The user of a personal healthcare environment.	PHR	Personal health record	CapabilityStatement: Client	Vital Signs client requirements
Healthcare professional	The user of a XIS	XIS	Healthcare information system	CapabilityStatement: Server	Vital Signs server requirements

3 Use case: Retrieve Vital Signs

This FHIR implementation guide assumes that the PHR system is able to make a connection to the right XIS that contains the patient's information. It does not provide information on finding the right XIS nor does it provide information about security. Moreover, each transaction is performed in the context of a specific authenticated patient, for whose context (token) has been established using the authentication mechanisms described in the 'Afsprakenstelsel'. Each XIS Gateway is required to perform filtering based on the patient associated with the context for the request, so only the records associated with the authenticated patient are returned. For this reason, search parameters should not be included for patient identification.

3.1 Introduction

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

3.2 Actors

Transaction group	Transaction	Actor	Role
Retrieve Vital Signs(PULL)	Retrieve vital signs request	Patient (using a PHR)	Request vital signs from the XIS
Retrieve Vital Signs(PULL)	Retrieve vital signs response	Healthcare professional (using a XIS)	Serves vital signs to the PHR

3.3 Invocations

3.3.1 PHR: request message

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

3.3.1.1 Trigger Events

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

3.3.1.2 Message Semantics

Search

The PHR executes an HTTP GET conform to the FHIR RESTful and search specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

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

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

Observation
Name	Type	Description	Example
`category`	token	The classification of the type of observation. Within this context this will be vital-signs (from code system `http://hl7.org/fhir/observation-category`)	Retrieve all Observation resources that are considered a vital sign observation: GET [base]/Observation?category=vital-signs
`code`	token	The code of the observation type. The different types of measurements are specified using the following LOINC codes: Respiration: 9279-1 BloodPressure: 85354-9 BodyWeight: 29463-7 BodyHeight: 8302-2 BodyTemperature: 8310-5 Oxygenation, saturation, SpO2: 59408-5 HeartRate: 8867-4 PulseRate: 8889-8 BloodGlucose fasting: 14770-2 general: 14743-9 post-meal: 14760-3	Retrieve all Observation resources that are a blood pressure observation: GET [base]/Observation?code=http://loinc.org\|85354-9 Retrieve the most recent body height and the most recent body weight observation: GET [base]/Observation/$lastn?code=http://loinc.org\|8302-2&code=http://loinc.org\|29463-7
`date`	date	Obtained date/time. If the obtained element is a period, a date that falls in the period	Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010: GET [base]/Observation?code=http://loinc.org\|85354-9&date=ge2010-01-01&date=le2011-01-01 Retrieve at most four temperature observations that have an effective date greater than 01-06-2012: GET [base]/Observation/$lastn?max=4&code=http://loinc.org\|8310-5&date=ge2012-06-01

3.3.1.2.1 Expected Actions

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

3.3.2 XIS: response message

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

3.3.2.1 Trigger Events

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

3.3.2.2 Message Semantics

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

In the table below, the vital sign zibs and their respective profiles are listed. Zibs that MUST be supported are marked with (M). Other vital signs profiles, without a corresponding zib, are can be found in the HL7 FHIR specification.

Zib NL	HCIM EN	FHIR Resource	FHIR Profile
Patiënt (M)	Patient	Patient	http://fhir.nl/fhir/StructureDefinition/nl-core-patient
Zorgverlener (M)	HealthProfessional	Practitioner	http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner
Ademhaling	Respiration	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-Respiration
Bloeddruk (M)	BloodPressure *	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure
LichaamsGewicht (M)	BodyWeight*	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight
LichaamsLengte	BodyHeight*	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight
Lichaamstemperatuur	BodyTemperature*	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature
O2Saturatie	oxygenation, saturation, SpO2*	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation
Hartfrequentie (M)	HeartRate*	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate
Polsfrequentie	PulseRate*	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate
LaboratoriumUitslag (based on) (M)	LaboratoryTestResult (based on)	Observation	http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose

3.3.2.3 Expected Actions

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

3.3.3 The `$lastn` operation

The following operation is needed for this use case.

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.

The $lastn FHIR STU3 specification is vague regarding the sorting mechanism of $lastn. In FHIR R4 however, this has been clarified and can be read as follows: when using $lastn, the effective[x] element is used for sorting of Observations, sorted from most recent to the oldest.

4 Use case: Send Vital Signs

4.1 Introduction

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

4.2 Actors

Transaction group	Transaction	Actor	Role
Send Vital Signs(PUSH)	Send vital signs request	Patient (using a PHR)	Sends vital signs to the XIS
Send Vital Signs(PUSH)	Send vital signs response	Healthcare professional (using a XIS)	Receives vital signs from the PHR

4.3 Invocations

4.3.1 PHR: request message

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

4.3.1.1 Trigger Events

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

4.3.1.2 Message Semantics

Because sending vital signs will most likely consist of multiple Observations, a batch operation is used. This allows for creating a set of resources in a single interaction and makes it possible to include referenced secondary resources if needed.

A batch interaction is performed by an HTTP POST command as shown:

POST [base]

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: .request is optional, but SHALL be present, even for the resources which aren't Observations. See the overarching principles for more information.)

Identification:

Sending systems are strongly encouraged to assign a stable identifier to the .identifier element when sending vital signs, this helps receiving systems with detecting duplicates and re-identification of Observation resources. For more information on dealing with identifiers, see the general MedMij FHIR IG.

Links:

batch
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 FHIR specification can be used. Other vital sign concepts are currently out of scope for this use case.

Zib NL	HCIM EN	FHIR Resource	FHIR Profile
Patiënt (M)	Patient	Patient	http://fhir.nl/fhir/StructureDefinition/nl-core-patient
Zorgverlener (M)	HealthProfessional	Practitioner	http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner
Ademhaling	Respiration	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-Respiration
Bloeddruk (M)	BloodPressure*	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure
LichaamsGewicht (M)	BodyWeight*	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight
LichaamsLengte	BodyHeight*	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight
Lichaamstemperatuur	BodyTemperature*	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature
O2Saturatie	oxygenation, saturation, SpO2*	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation
Hartfrequentie (M)	HeartRate*	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate
Polsfrequentie	PulseRate*	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate
LaboratoriumUitslag (based on) (M)	LaboratoryTestResult (based on)	Observation	http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose

4.3.1.2.1 Expected Actions

On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

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

4.3.2.1 Trigger Events

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

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

4.3.2.3 Expected Actions

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

4.3.2.4 Handling Errors

The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the Handling Errors section in the MedMij FHIR IG for more information.

5 Release notes

Release notes can be found on the functional design page.

MedMij:V2020.01/FHIR VitalSigns: verschil tussen versies

Huidige versie van 22 nov 2022 om 13:35

Inhoud

1 Introduction

2 Actors involved

3 Use case: Retrieve Vital Signs

3.1 Introduction

3.2 Actors

3.3 Invocations

3.3.1 PHR: request message

3.3.1.1 Trigger Events

3.3.1.2 Message Semantics

3.3.1.2.1 Expected Actions

3.3.2 XIS: response message

3.3.2.1 Trigger Events

3.3.2.2 Message Semantics

3.3.2.3 Expected Actions

3.3.3 The `$lastn` operation

4 Use case: Send Vital Signs

4.1 Introduction

4.2 Actors

4.3 Invocations

4.3.1 PHR: request message

4.3.1.1 Trigger Events

4.3.1.2 Message Semantics

4.3.1.2.1 Expected Actions

4.3.2 XIS: response message

4.3.2.1 Trigger Events

4.3.2.2 Message Semantics

4.3.2.3 Expected Actions

4.3.2.4 Handling Errors

5 Release notes

Navigatiemenu

Zoeken

@@ Regel 1: / Regel 1: @@
 __NUMBEREDHEADINGS__
 {{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
-{{MedMij:Vprepub/Issuebox_FHIR_IG}}
+{{MedMij:V2020.01/Issuebox_FHIR_IG}}
 [[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
@@ Regel 7: / Regel 7: @@
 <imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
 circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
-circle 1013 224 212 [[MedMij:Vprepub/OntwerpZelfmetingen|Functioneel]]
+circle 1013 224 212 [[MedMij:V2020.01/OntwerpZelfmetingen|Functioneel]]
-circle 1787 230 212 [[MedMij:Vprepub/FHIR_IG|Technisch]]
+circle 1787 230 212 [[MedMij:V2020.01/FHIR_IG|Technisch]]
 desc none
 </imagemap>
@@ Regel 15: / Regel 15: @@
 =Introduction=
-[[Bestand:Functioneel-02.png|link=MedMij:Vprepub/Ontwerpen |100px|rechts|Functional design|Go to functional design]]
+[[Bestand:Functioneel-02.png|link=MedMij:V2020.01/Ontwerpen |100px|rechts|Functional design|Go to functional design]]
 This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.
-'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub/FHIR_IG#Use case overarching principles|use case overarching principles]].
+'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:V2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].
 Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.
 Use cases:
-* [[MedMij:Vprepub/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
+* [[MedMij:V2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
-* [[MedMij:Vprepub/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]
+* [[MedMij:V2020.01/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]
 =Actors involved=
@@ Regel 92: / Regel 92: @@
 <pre>
-GET [base]/Observation{?[parameters]}
+GET [base]/Observation{/$lastn}{?[parameters]}
 </pre>
@@ Regel 109: / Regel 109: @@
 | [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
 | token
-| The classification of the type of observation
+| The classification of the type of observation.
+Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
 |
-Retrieve all Observation resources that are considerd a vital sign observation.
+Retrieve all Observation resources that are considered a vital sign observation:
 <pre>GET [base]/Observation?category=vital-signs</pre>
 |-
 | [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
 | token
-| The code of the observation type
+| The code of the observation type.
+The different types of measurements are specified using the following LOINC codes:
+* Respiration: 9279-1
+* BloodPressure: 85354-9
+* BodyWeight: 29463-7
+* BodyHeight: 8302-2
+* BodyTemperature: 8310-5
+* Oxygenation, saturation, SpO2: 59408-5
+* HeartRate: 8867-4
+* PulseRate: 8889-8
+* BloodGlucose
+** fasting: 14770-2
+** general: 14743-9
+** post-meal: 14760-3
 |
-Retrieve all Observation resources that are a blood pressure observation.
+Retrieve all Observation resources that are a blood pressure observation:
 <pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
+Retrieve the most recent body height and the most recent body weight observation:
+<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
 |-
 | [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
@@ Regel 125: / Regel 143: @@
 | Obtained date/time. If the obtained element is a period, a date that falls in the period
 |
-Retrieve all Observation resources that are a blood pressure observation and have an effective date greater than 01-01-2010.
+Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
-<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01</pre>
+<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
-|}
+Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
+<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
-'''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
-. GET [base]/Observation?category=vital-signs&date=[date]{&date=[date]}
-. GET [base]/Observation?code[vital sign LOINC{,LOINC2,LOINC3,...}]
-. GET [base]/Observation?code=[vital sign LOINC{,LOINC2,LOINC3,...}]&date=[date]{&date=[date]}
-. 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
-|-
-| PulseRate||8889-8
-|-
-| BloodGlucose|| 14770-2 (fasting) <br/> 14743-9 (general) <br/> 14760-3 (post-meal)
 |}
@@ Regel 179: / Regel 161: @@
 The body of the response message shall be a Bundle of type "''searchset''" containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type "''searchset''" shall be returned without any Observation as entries.
-In the table below, the vital sign zibs and their respective profiles are listed. Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]
+In the table below, the vital sign zibs and their respective profiles are listed. Zibs that MUST be supported are marked with (M). Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]
-{{MedMij:NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}
+{{MedMij:V2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}
 {| class="wikitable"
 |-style="background-color: #1F497D; color: white; font-weight: bold; "
-|style="width:150px;"|Zib name NL||style="width:150px;"|Zib name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR profile
+|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
 |-style="vertical-align:top; background-color: #E3E3E3;
+|-
+| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| Bloeddruk||BloodPressure||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
+| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| LichaamsGewicht||BodyWeight||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
+| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| LichaamsLengte||BodyHeight||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
+| Bloeddruk (M)||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| Lichaamstemperatuur||BodyTemperature||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
+| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| O2Saturatie||oxygenation, saturation, SpO2||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
+| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| Hartfrequentie||HeartRate||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
+| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| Polsfrequentie||PulseRate||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
+| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
+| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
+|-
+| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
+|-
+| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
 |}
-{{Sjabloon:Voorbeelden}}
+<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}
 ====Expected Actions====
 The PHR processes the results according to application-defined rules.
-===The <code>lastn</code> operation===
+===The {{fhir|$lastn}} operation===
 The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
 * [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]
-The <code>lastn</code> query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.
+The {{fhir|$lastn}} query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.
-The [http://hl7.org/fhir/STU3/observation-operations.html#lastn FHIR STU3] specification is vague regarding the sorting mechanism of lastn. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using lastn, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.
+The [http://hl7.org/fhir/STU3/observation-operations.html#{{fhir|$lastn}} FHIR STU3] specification is vague regarding the sorting mechanism of {{fhir|$lastn}}. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using {{fhir|$lastn}}, the {{fhir|effective[x]}} element is used for sorting of Observations, sorted from most recent to the oldest.
+{{NoteBox|The {{fhir|$lastn}} operation applies differently to the blood glucose measurements, as it may return up to three Observation resources instead of just one. This is due to the fact that blood glucose measurements have three different categories (fasting, general and post-meal), resulting in three possible values for {{fhir|Observation.code}}. To query on blood glucose, the {{fhir|$lastn}} query on blood glucose Observations should include all these three values, but this will result in the latest Observation for ''each'' of these values.}}
 =Use case: Send Vital Signs=
@@ Regel 248: / Regel 238: @@
 ====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.
+Because sending vital signs will most likely consist of multiple Observations, a {{fhir|batch}} operation is used. This allows for creating a set of resources in a single interaction and makes it possible to [[MedMij:V2020.01/FHIR_IG#Referring other resources when sending information|include referenced secondary resources]] if needed.
-A batch interaction is performed by an HTTP POST command as shown:
+A {{fhir|batch}} interaction is performed by an HTTP POST command as shown:
 <pre>POST [base]</pre>
-The body of the post submission is a Bundle with 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.
+The body of the post submission is a Bundle with {{fhir|Bundle.type}}={{term|batch}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry. (Note: {{fhir|.request}} is optional, but SHALL be present, even for the resources which aren't Observations. See [[MedMij:V2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]] for more information.)
+{{NoteBox|Sending systems are expected to use an internal reference to the Patient resource included in the request Bundle if they cannot refer to the subject in any other way (see [[MedMij:V2020.01/FHIR_IG#Referring other resources when sending information|the overarching principles]]). This contradicts the FHIR specification, which states that internal references cannot be used for {{fhir|batch}} operations. This is a known issue which will be addressed in the future versions of this information standard. See [https://bits.nictiz.nl/browse/MM-1620 MM-1620] for more information.}}
+'''Identification:'''
+Sending systems are strongly encouraged to assign a stable identifier to the {{fhir|.identifier}} element when sending vital signs, this helps receiving systems with detecting duplicates and re-identification of Observation resources. For more information on dealing with identifiers, see the [[MedMij:V2020.01/FHIR_IG#When_is_.identifier_expected.3F|general MedMij FHIR IG]].
 '''Links:'''
@@ Regel 263: / Regel 259: @@
 The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.
-{{MedMij:NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}
+{{MedMij:V2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}
-{| class="wikitable" width="1200px"
+{| 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="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
 |-style="vertical-align:top; background-color: #E3E3E3;
 |-
-| Bloeddruk||BloodPressure||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
+| Patiënt (M)||Patient||Patient||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| LichaamsGewicht||BodyWeight||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
+| Zorgverlener (M)||HealthProfessional||Practitioner||{{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| LichaamsLengte||BodyHeight||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
+| Ademhaling||Respiration||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Respiration|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| Lichaamstemperatuur||BodyTemperature||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
+| Bloeddruk (M)||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| O2Saturatie||oxygenation, saturation, SpO2||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
+| LichaamsGewicht (M)||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| Hartfrequentie||HeartRate||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
+| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| Polsfrequentie||PulseRate||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
+| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
 |-
-| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
+| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
 |-
+| Hartfrequentie (M)||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
+|-
+| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
+|-
+| LaboratoriumUitslag (based on) (M)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
 |}
-{{Sjabloon:Voorbeelden}}
 =====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.
+On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.
 ===XIS: response message===
@@ Regel 301: / Regel 301: @@
 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:
@@ Regel 317: / Regel 309: @@
 The PHR processes the results according to application-defined rules.
-=Terminology, NamingSystems, Mappings=
+====Handling Errors====
+The server may be unable to accept a Bundle due to errors or because of business rules (e.g. because of an unsupported code value in an Observation resource). Refer to the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_IG#Handling_errors Handling Errors section] in the MedMij FHIR IG for more information.
-===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].
-An explanation about mappings can be found at [[MedMij:Vprepub/FHIR_IG#Mapping_of_coded_concepts|Mapping of coded concepts]].
 =Release notes=
-Release notes can be found on the [[MedMij:Vprepub/OntwerpZelfmetingen#Release_notes|functional design page]].
+Release notes can be found on the [[MedMij:V2020.01/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:V2020.01/FHIR VitalSigns: verschil tussen versies

Huidige versie van 22 nov 2022 om 13:35

1 Introduction

2 Actors involved

3 Use case: Retrieve Vital Signs

3.1 Introduction

3.2 Actors

3.3 Invocations

3.3.1 PHR: request message

3.3.1.1 Trigger Events

3.3.1.2 Message Semantics

3.3.1.2.1 Expected Actions

3.3.2 XIS: response message

3.3.2.1 Trigger Events

3.3.2.2 Message Semantics

3.3.2.3 Expected Actions

3.3.3 The $lastn operation

4 Use case: Send Vital Signs

4.1 Introduction

4.2 Actors

4.3 Invocations

4.3.1 PHR: request message

4.3.1.1 Trigger Events

4.3.1.2 Message Semantics

4.3.1.2.1 Expected Actions

4.3.2 XIS: response message

4.3.2.1 Trigger Events

4.3.2.2 Message Semantics

4.3.2.3 Expected Actions

4.3.2.4 Handling Errors

5 Release notes

Navigatiemenu

Zoeken

3.3.3 The `$lastn` operation