MedMij:V2020.01/FHIR BGLZ: verschil tussen versies
(MM-972: added documentation for lastn operation) |
(MM-1118 + MM-437: Remove duplicated documentation on error handling and searching) |
||
| Regel 173: | Regel 173: | ||
===XIS: response message=== | ===XIS: response message=== | ||
| − | + | The returned data to the PHR should conform to the profiles listed in [[#List_of_StructureDefinitions]]. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Interactions, operations, search parameters== | ==Interactions, operations, search parameters== | ||
Versie van 29 jul 2020 om 15:48
MedMij:Vprepub/Issuebox FHIR IG
Inhoud
1 Introduction
This page provides the technical specification of the exchange of long-term healthcare information (Dutch: Basisgegevens Langdurige Zorg or BgLZ) based on a selection of Dutch Health Care Information Models. The specification is based on this functional design.
2 Actors involved
| Actors | Systems | FHIR Capability Statements | |||
|---|---|---|---|---|---|
| Name | Description | Name | Description | Name | Description |
| Patient | The user of a personal healthcare enviorment. | PHR | Personal health record |  Client@ http://nictiz.nl/fhir/CapabilityStatement/bglz-clientcapabilities
|
FHIR Client requirements |
| Healthcare professional | The user of a XIS | XIS | Healthcare information system | Server@ http://nictiz.nl/fhir/CapabilityStatement/bglz-servercapabilities
|
FHIR Server requirements |
3 Boundaries and Relationships
The BgLZ has similarities with the Basisgegevensset Zorg (BgZ) and Basisgegevens GGZ (GGZ) but is definitely different. These information standards use much of the same HCIM based FHIR profiles for exchanging information. Wherever possible every attempt is made to re-use profiles. The BgLZ use case also has unique profiles compared to the aforementioned use cases, such as OutcomeOfCare. In addition, it uses a CareTeam profile without an underlying HCIM. A second thing to note is that also the selection of requested information per HCIM may differentiate. For example, only a subset of LaboratoryResults or AllergyIntolerance is expected to be returned by a XIS. This page, which belongs to the BgLZ functional design, and related transactions provide details on the information that is expected to be exchanged.
Medication information is part of a good overview of patients in long-term healthcare. Retrieving medication information by a PHR is however out of scope for this information standard. A separate information standard, MedicationProcess, is intended to serve this purpose.
4 Use case: Retrieve BgLZ information
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 BgLZ transaction is used by the PHR to retrieve long-term healthcare information from a XIS.
4.2 Actors
| Transaction group | Transaction | Actor | Role |
|---|---|---|---|
| Retrieve BgLZ (PULL) | Retrieve BgLZ request | Patient (using a PHR) | Request long-term healthcare information from a XIS |
| Retrieve BgLZ response | Healthcare professional (using a XIS) | Serves long-term healthcare information to a PHR |
4.3 Invocations
4.3.1 PHR: request message
The PHR system requests the BgLZ using individual search interactions. The BgLZ consists of multiple FHIR resources with certain constraints. To obtain the patient's BgLZ, the client can use multiple individual search operations based on specified search queries. The interactions are performed by an HTTP GET as shown:
GET [base]/[type]/{?[parameters]{&_format=[mime-type]}}
The table below shows in the first four columns the BgLZ sections, the HCIMs that constitute those sections and the specific content of the BgLZ. The last column shows the FHIR search queries to obtain the BgLZ information. These queries and expected responses are based on StructureDefinitions listed in this section.
| # | BgLZ Section | HCIM EN | Content | Search URL |
|---|---|---|---|---|
| 1 | Patient information | Patient | Identification, birthdate, gender, deceasedindicator, contact details, marital status, and general practitioner (practitioner or organization) | GET [base]/Patient?_include=Patient:general-practitioner |
| 2 | Treatment Directives | TreatmentDirective | Known treatment directives | GET [base]/Consent?category=http://snomed.info/sct|11291000146105 |
| AdvanceDirective | Known advance directives | GET [base]/Consent?category=http://snomed.info/sct|11341000146107 | ||
| 3 | Contactperson | ContactPerson | First relation/contact | see Patient in Patient.contact |
| 4 | Problems | Problem | All known problems including diagnoses; no verification status | GET [base]/Condition |
| 5 | Allergies | AllergyIntolerance | A selection of information from all known allergies and intolerances. The ART-DECOR transaction specification describes the selection. | GET [base]/AllergyIntolerance |
| 6 | Results | LaboratoryTestResult | A selection of infromation from the last known clinical laboratory results per type. The ART-DECOR transaction specification describes the selection. | GET [base]/Observation/$lastn?category=http://snomed.info/sct|275711006&_include=Observation:related-target&_include=Observation:specimen |
| 7 | Procedures | Procedure | All procedures | GET [base]/Procedure |
| 8 | Goals and interventions
* see the NoteBox above |
NursingIntervention | NursingInterventions beloning to active problems | GET [base]/CarePlan?_include=CarePlan:activity-goal:Goal &_include=CarePlan:activity-outcomereference:Observation &_include=CarePlan:activity-medicaldevice:DeviceUseStatement &_include:recurse=DeviceUseStatement:device:Device |
| TreatmentObjective | All treatment objectives beloning to NursingInterventions | |||
| MedicalDevice | All MedicalDevices belonging to NursingInterventions; only product type and anatomical location | |||
| OutcomeOfCare | Known treatment outcomes | |||
| 9 | Caresetting / CareTeam | HealthProfessional |
|
GET [base]/CareTeam?_include=CareTeam:participant |
| HealthcareProvider |
4.3.2 XIS: response message
The returned data to the PHR should conform to the profiles listed in #List_of_StructureDefinitions.
4.4 Interactions, operations, search parameters
4.4.1 Interactions
The following logical interactions are needed for the BgLZ use case:
4.4.2 Operations
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.4.3 Search parameters
The following search parameter types and search result parameters need to be supported for this use case.
Search parameter types:
Search result parameters:
- _include
- Including modifier 'recurse'
The following custom search parameters are defined for this use case:
- http://nictiz.nl/fhir/SearchParameter/careplan-activity-goal
- http://nictiz.nl/fhir/SearchParameter/careplan-activity-outcomereference
- http://nictiz.nl/fhir/SearchParameter/careplan-medicaldevice
4.5 List of StructureDefinitions
The profiles represent their entire respective HCIM, to make them applicable in a broader context than the exchange of BgLZ or a MedMij context.
|
|
MedMij uses the FHIR Packaging mechanism. This conveniently bundles all examples, profiles and other conformance resources you need into a single download. For more background information see the the FHIR implementation guide. This version of the information standard depends on Nictiz package 1.3.x. Please note that the direct links to the various conformance resources below will take you to the latest version, which might not match the package version. At time of writing, there is no way to render the conformance resource as found in the package. This is on the roadmap for Simplifier. |
* The 2018 release of the HCIM NursingIntervention is used because the 2017 release is not suitable. The functional design page provides more information. In addition, the CarePlan resource is used to transfer the HCIM NursingIntervention. The BgLZ does not use the Procedure resource for HCIM NursingIntervention.
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.6 Terminology, NamingSystems, Mappings
4.6.1 Terminology
Relevant value sets can be found using the ValueSet category.
4.6.2 NamingSystems
Relevant NamingSystems can be found using the NamingSystem category.
4.6.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.
5 Release notes
Release notes can be found on the functional design page.
