MedMij FHIR Implementation Guide LaboratoryResults 2.0.39
MedMij:Vprepub/Issuebox FHIR IG
Inhoud
1 Introduction
This page describes patient's use cases for the retrieval of laboratory results, in a personal health environment (PHR) context. Functional specifications are described at the functional design wiki page. The technical specification is described here. HL7 FHIR STU3 is used for this purpose.
Note: This implementation guide builds on the general guidelines described in the use case overarching principles.
Many laboratory result observations have important relationships to other observations and need to be grouped together. The FHIR specification defines three structures to do this: DiagnosticReport and DiagnosticReport.result, Observation and Observation.component, and Observation and Observation.related. For the transactions of laboratory results retrieval, the following two grouping structures are relevant.
1.1 Observation
Individual laboratory results are represented by Observation resources, such as one blood glucose value. The Observation resource can also be used as a structure for a panel or battery observation. Observation.related is used for any supporting result that can be interpreted and used on its own and has one or more different values for method, observation, performer, device, time, and/or error conditions. The top-level observation specifies the grouping code in Observation.code, but typically does not have its own Observation.value, and the set of member observations are listed in the Observation.related element.
1.2 DiagnosticReport
In contrast to the Observation resource, the DiagnosticReport resource typically includes additional clinical context and some mix of atomic results, images, imaging reports, textual and coded interpretation, and formatted representations. Report conclusions can be expressed as a simple text blob, structured coded data or as an attached fully formatted report such as a PDF. The DiagnosticReport.code names the panel and serves as the grouping element, which is traditionally referred to as a "panel" or "battery" by laboratories. The DiagnosticReport.result element references the individual observations.
Both structures may exist in a XIS. Therefore, two transactions are defined to retrieve a patient's laboratory results. The transaction content either consists of a single and related laboratory results structure or a complete diagnostic report that adds more clinical meaning to the single and related laboratory results. The transactions:
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
|
LaboratoryResults process client requirements |
| Healthcare professional | The user of a XIS | XIS | Healthcare information system | CapabilityStatement: Server
|
LaboratoryResults server requirements |
3 Use case: retrieve laboratory results
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 laboratory results transaction is used by the PHR to retrieve laboratory results from a XIS.
3.2 Actors
| Transaction group | Transaction | Actor | Role |
|---|---|---|---|
| Retrieve Laboratory Results(PULL) | Retrieve laboratory results request | Patient (using a PHR) | Request laboratory results from the XIS |
| Retrieve laboratory results response | Healthcare professional (using a XIS) | Serves laboratory results 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 laboratory results, it issues a retrieve laboratory results request message.
3.3.1.2 Message Semantics
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?category=http://snomed.info/sct|49581000146104{&[parameters]}
The PHR may use, and the XIS shall be capable of processing, the following parameters to configure the search query:
| Name | Description | Examples |
|---|---|---|
| date | Obtained date/time for the result. If the result was obtained over a period, this parameter should be interpreted as a date that falls in this period. | Retrieve all zib LaboratoryTestResults Observation resources that have an effective date greater than 01-01-2010:
GET [base]/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01 Retrieve all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period: GET [base]/Observation?_include=Observation:specimen&category=http://snomed.info/sct|49581000146104date=ge2010-01-01&date=le2011-12-31 |
| category | The classification of the type of observation. | Retrieve all zib LaboratoryTestResults Observation resources:
GET [base]/Observation?category=http://snomed.info/sct|49581000146104 |
| _include | The PHR may request that the XIS returns resources related to the search results, in order to reduce the overall network delay of repeated retrievals of related resources. | Retrieve all zib LaboratoryTestResults Observation resources and include Specimen information in the search results:
GET [base]/Observation?_include=Observation:specimen&category=http://snomed.info/sct|49581000146104 |
3.3.1.2.1 Expected Actions
The XIS shall process the query to discover Observation resources that match the search parameters given.
3.3.2 XIS: response message
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching observation information.
3.3.2.1 Trigger Events
The XIS completed processing of the retrieve laboratory results request message.
3.3.2.2 Message Semantics
The returned data to the PHR should conform to the HCIMs and their associated 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 related profile canonical URL in the meta.profile element in order to show compliance.
|
|
MedMij uses the FHIR Packaging mechanism. This conveniently bundles all examples, profiles 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: any other version with the same major.minor version is compatible. See Semantic Versioning for more information. |
| Zib name NL | Zib name EN | FHIR Resource | |
| Patient | Patient | Patient | http://fhir.nl/fhir/StructureDefinition/nl-core-patient |
| Zorgverlener | HealthProfessional | Practitioner | http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner |
| Zorgaanbieder | HealthcareProvider | Organization | http://fhir.nl/fhir/StructureDefinition/nl-core-organization |
| LaboratoriumUitslag | LaboratoryTestResult | Observation | http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation |
Example instances of FHIR resources can be found on Simplifier. Please note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of any information standard.
3.3.2.3 Expected Actions
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain observation and specimen resources that match the query parameters.
3.3.3 Examples
Example instances of FHIR resources can be found on Simplifier. Please note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of any information standard.
4 Use case: retrieve laboratory results DiagnosticReport
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.
4.1 Introduction
The retrieve laboratory diagnostic report transaction is used by the PHR to retrieve laboratory results from a XIS.
4.2 Actors
| Transaction group | Transaction | Actor | Role |
|---|---|---|---|
| Retrieve Laboratory Results(PULL) | Retrieve laboratory diagnostic report request | Patient (using a PHR) | Request laboratory diagnostic report from the XIS |
| Retrieve laboratory diagnostic report response | Healthcare professional (using a XIS) | Serves laboratory diagnostic report to the PHR |
4.3 Invocations
4.3.1 PHR: request message
The request message represents an HTTP GET parameterized query from the PHR to the XIS.
4.3.1.1 Trigger Events
When the patient(PHR) wants to obtain laboratory diagnostic report, it issues a retrieve laboratory diagnostic report request message.
4.3.1.2 Message Semantics
The PHR executes an HTTP GET conform to the FHIR RESTfull and search specification against the XIS's DiagnosticReport endpoint. This search query URL is configurable by the PHR and has the following format.
GET [base]/DiagnosticReport?category=http://snomed.info/sct|4241000179101{&[parameters]}
The PHR may use, and the XIS shall be capable of processing, the following parameters to configure the search query:
| Name | Description | Example(s) |
|---|---|---|
| date | The clinically relevant time of the report. | Retrieve all zib LaboratoryTestResult DiagnosticReport resources that have an effective date greater than 01-01-2010.
GET [base]/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01 Retrieve all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period. GET [base]/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01&date=le2011-12-31 |
| category | Which diagnostic discipline/department created the report. | |
| _include | The PHR may request that the XIS returns resources related to the search results, in order to reduce the overall net | Retrieves all zib LaboratoryTestResult DiagnosticReport resources and include the referenced Observation resources in the search results.
GET [base]/DiagnosticReport?category=http://snomed.info/sct|4241000179101&include=DiagnosticReport:result&date=ge2010-01-01&date=le2011-12-31 |
4.3.1.2.1 Expected Actions
The XIS shall process the query to discover DiagnosticReport resources that match the search parameters given.
4.3.2 XIS: response message
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching laboratory diagnostic report information.
4.3.2.1 Trigger Events
The XIS completed processing of the retrieve laboratory diagnostic report request message.
4.3.2.2 Message Semantics
The returned data to the PHR should conform to the HCIMS and their associate 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 related profile canonical URL in the meta.profile element in order to show compliance.
|
|
MedMij uses the FHIR Packaging mechanism. This conveniently bundles all examples, profiles 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: any other version with the same major.minor version is compatible. See Semantic Versioning for more information. |
| Zib name NL | Zib name EN | FHIR Resource | |
| Patient | Patient | Patient | http://fhir.nl/fhir/StructureDefinition/nl-core-patient |
| Zorgverlener | HealthProfessional | Practitioner | http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner |
| Zorgaanbieder | HealthcareProvider | Organization | http://fhir.nl/fhir/StructureDefinition/nl-core-organization |
| LaboratoriumUitslag | LaboratoryTestResult | DiagnosticReport | http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-DiagnosticReport |
| Observation | http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation |
Example instances of FHIR resources can be found on Simplifier. Please note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of any information standard.
4.3.2.3 Expected Actions
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain DiagnosticReport, Observation and Specimen resources that match the query parameters.
5 Terminology, NamingSystems, Mappings
5.1 Terminology
Relevant ValueSets can be found through the ValueSet bindings in the listed StructureDefinitions. All ValueSets can be found here here and can be downloaded as a .zip in XML or JSON format.
5.2 NamingSystems
Relevant NamingSystems can be found here.
5.3 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 here.
An explanation about mappings can be found at Mapping of coded concepts.
6 Release notes
Release notes can be found on the functional design page.
