MedMij FHIR Implementation Guide: BgLZ

Uit informatiestandaarden
Ga naar: navigatie, zoeken

Patient Summary (BgZ)

1 Introduction

Go to functional design

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.

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

2 Actors involved

Actors Systems FHIR Capability Statements
Name Description Name Description Name Description
Patient The user of a personal healthcare environment. PHR Personal health record Verwijzing.png CapabilityStatement: Client FHIR Client requirements
Healthcare professional The user of a XIS XIS Healthcare information system Verwijzing.png CapabilityStatement: Server 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.

Go to Afsprakenstelsel

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]}

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]
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=|11291000146105
AdvanceDirective Known advance directives
GET [base]/Consent?category=|11341000146107
3 Contactperson ContactPerson First relation/contact
see Patient in
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=|275711006&_include=Observation:related-target&_include=Observation:specimen
7 Procedures Procedure All procedures
GET [base]/Procedure
8 Goals and interventions (see the notes below on HCIM NursingIntervention and the CarePlan resource) NursingIntervention NursingInterventions beloning to active problems
GET [base]/CarePlan?_include=CarePlan:activity-goal:Goal
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
  • General practitioner of the patient (see Patient.generalPractitioner)
  • Primary practitioner - information of the primary care giver, no ID, adress/contact information
  • Other practitioners - information of all practitioners given care to the patient, no ID, adress/contact information
  • Healthcare provider - organization where care is given
GET [base]/CareTeam?_include=CareTeam:participant
  1. See Search URLs and search parameters for the interpretation of these search URLs

4.3.2 XIS: response message

The returned data to the PHR should conform to the profiles listed in #List_of_StructureDefinitions.

4.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.3.4 Custom search parameters

The following custom search parameters are defined for this use case:

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

Zib NL HCIM EN FHIR Resource FHIR Profile
Patiënt Patient Patient
BehandelAanwijzing TreatmentDirective Consent
Wilsverklaring AdvanceDirective Consent
Probleem Problem Condition
AllergieIntolerantie AllergyIntolerance AllergyIntolerance
LaboratoriumUitslag LaboratoryTestResult Observation
Verrichting Procedure Procedure
VerpleegkundigeInterventie NursingIntervention CarePlan (see the notes below on HCIM NursingIntervention and the CarePlan resource)
Behandeldoel TreatmentObjective
MedischHulpmiddel MedicalDevice
UitkomstVanZorg OutcomeOfCare
Zorgverlener HealthProfessional Practitioner
Zorgaanbieder HealthcareProvider Organization
- - CareTeam

4.4.1 Note: HCIM NursingIntervention

For HCIM NursingIntervention, the 2018 release is used because the 2017 release is not suitable. The functional design page provides more information.

In addition, HCIM NursingIntervention is transferred as part of the CarePlan resource in the BgLZ, rather than the dedicated zib-NursingIntervention profile on Procedure.

4.4.2 Note: the CarePlan resource

The CarePlan is comprised of several HCIMs, each of which has an expected structure. Not all systems in longterm care are structured accordingly (yet). This is why CarePlan may be sent either in a structured way based on the HCIMs, or unstructured, matching the system that created it. The CarePlan SHALL be either:

  • fully structured with clinically relevant text as xhtml in CarePlan.text with .text.status = extensions, or
  • fully unstructured with clinically relevant text as xhtml in CarePlan.text with .text.status = additional
    • Required other elements are CarePlan.status, CarePlan.intent, CarePlan.subject
    • Other elements MAY be populated

The CarePlan.text (Resource.text) is explained in more detail in the FHIR IG. The status additional generically signals receivers that the contents of the narrative may contain additional information not found in the structured data which means the CarePlan.text SHALL NOT be ignored. In an unstructured CarePlan the CarePlan.text is expected to be meaningful to the human receiver without further inspection of any structured data that may or may not be present in the Careplan as well.

5 Release notes

Release notes can be found on the functional design page.

6 Support

For questions and change requests regarding the information on this page, please create a ticket in BITS