MedMij FHIR Implementation Guide Vital Signs 2.0.25
|
|
Work in progress - See official publication here. |
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 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 |
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:
|
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. Other vital signs profiles, without a corresponding zib, are can be found in the HL7 FHIR specification.
|
|
MedMij uses the FHIR Packaging mechanism. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
Note: packages use Semantic Versioning. Other versions can be used at will as long as they have the same major.minor number or a minor number higher than the stated version. |
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.
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 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 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/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:
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: 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:
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.
|
|
MedMij uses the FHIR Packaging mechanism. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
Note: packages use Semantic Versioning. Other versions can be used at will as long as they have the same major.minor number or a minor number higher than the stated version. |
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.
5 Release notes
Release notes can be found on the functional design page.