UC1-send-LaboratoryTestResults-FHIR-transaction
WARNING This page should be considered draft and as a proposal for sending LaboratoryTestResults using FHIR conformant interactions. This is currently not supported by Healthdata.be.
Implementer feedback is welcome on in the Simplifier issue tracker.
Introduction
This page describes the minimal required technical functionalities for: Use case 1: send LaboratoryTestResults
Capability Statements
- CapabilityStatement that defines the minimal expected capabilities of a Provider
- CapabilityStatement that defines the minimal expected capabilities of a Consumer
Invocations
Provider: LaboratoryTestResults request
Because LaboratorTestResults data consists of several building blocks along with supporting resources, a transaction interaction is used.
A transaction interaction allows for sending a Bundle with a set of resources in a single interaction and makes it possible to include referenced secondary resources. The interaction is performed by an HTTP POST command as shown:
POST [fhir base url]
The body of the POST submission is a Bundle with Bundle.type = transaction. Each entry carries request details (Bundle.entry.request) that provides the HTTP method of the action to be executed. Usually, this will be POST, even for informative 'secondary' resources.
At least Patient information and one or more LaboratoryTestResult resources are expected. The LaboratoryTestResult-Bundle profile shows the Bundle structure.
The Provider SHALL guarantee consistency of all FHIR resource elements with the requirements specified in the #FHIR profiles.
FHIR profiles
| FHIR profile | FHIR Resource | Cardinality | Based on CBB |
|---|---|---|---|
| LaboratoryTestResult-Bundle | Bundle | 1..1 | - |
| LaboratoryTestResult | Observation | 1..* | LaboratoryTestResult |
| LaboratoryTestResult.Specimen | Specimen | 0..* | ^ |
| LaboratoryTestResult.Specimen.Source | Specimen | 0..* | ^ |
| LaboratoryTestResult.Requester | ServiceRequest | 0..* | ^ |
| Patient | Patient | 1..1 | Patient |
| HealthProfessional-Practitioner | Practitioner | 0..* | HealthProfessional |
| HealthProfessional-PractitionerRole | PractitionerRole | 0..* | ^ |
| HealthcareOrganization | Location | 0..* | HealthcareOrganization |
| HealthcareOrganization-Organization | Organization | 0..* | ^ |
Grouping of observations using Observation resources
The CBB LaboratoryTestResult captures both singular laboratory tests and panels/clusters of multiple related tests requested together (e.g., blood gases and EBV serology). The LaboratoryTestResult profile provide guidance on how to populate the Observation resource. All Observation resources of panels/clusters SHALL be included in the LaboratoryTestResult Bundle.
Resource references
The Provider system SHALL produce a complete Bundle containing not only the resources listed directly in the LaboratoryTestResult resources, but all the indirectly referenced resources as well. This should prevent the receiving system to resolve references at the sending system. The CBB implementation guide provides additional guidance on the use of reference datatype.
Identification
Resources SHALL have a stable identifier in the .identifier element for all resources if such an identifier exists in the underlying data. Not all data, like individual results, are currently known to have identifiers in all source systems, but when they exist they are essential and where they do not exist yet they SHOULD be considered. Having stable identification is essential in detection of duplicates and potential clinical decision making issues deriving from duplicates. For more information on dealing with identifiers, see the CBB implementation guide.
Examples
LaboratoryTestResult Bundle examples that contain a single and fictive LaboratoryTestResult. The second and third examples have the same information but demonstrate two different approaches to populating .fullUrl, resource.id and references.
Examples from HL7 BE Laboratory Implementation Guide that are adjusted to align with the CBBs profiles by, for example, removing not defined resources such as the DiagnosticReport. More information can be found in the Boundaries and Relationships page. Below are LaboratoryTestResult Bundle examples of:
Consumer: LaboratoryTestResults response
The Consumer returns an HTTP Status code appropriate to the processing outcome. Success is only indicated once the Bundle and accompanying resources are received and completely processed and persisted as appropriate to the Consumer configuration.
If the transaction is successful, the server returns a Bundle with Bundle.type = transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. If the transaction fails, the Consumer returns an OperationOutcome with one or multiple .issue elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.