FHIR Implementation Guide BirthCare 4.0.0-beta.1
|
This FHIR IG is a beta version and still in development (BirthCare4.0.0-beta.1). |
Inhoud
1 Introduction
This page details the HL7 FHIR requirements for exchanging birthcare data.
The FHIR Implementation Guide for birthcare is based on dataset PWD 3.2 published for Geboortezorg 4.0.0-beta.1. The functional view for Birthcare is described in the functional design wiki pages.
Note: This implementation guide builds on the general guidelines for FHIR specifications described in the use case overarching principles.
FHIR resources and structure definitions described in this Implementation Guide (IG) can be found in the Simplifier Geboortezorg 4.0.0-beta.1 STU3 package. This IG provides links to the required resources and structure definitions for each use case.
2 Actors involved
The table shows the relevant actors, systems and FHIR CapabilityStatements. The CapabilityStatements demonstrate the minimum conformance requirements for the described use cases.
| Actors | Systems | FHIR CapabilityStatements | |||
|---|---|---|---|---|---|
| Name | Description | Name | Description | Name | Description |
| Patient | The user of a personal healthcare environment | PHR | Personal health record | CapabilityStatement:Receive | FHIR client requirements |
| Healthcare provider | The user of a XIS | XIS | Healthcare information system | CapabilityStatement:Send | FHIR server requirements |
3 Boundaries and relationships
The birthcare information standard includes use cases for the exchange of birthcare data between health care providers (XIS) and patients (e.g. in a PGO setting).
This FHIR implementation guide assumes that the PHR system is able to make a connection with the XIS and create resources. It does not provide information on finding the right XIS nor does it provide information about security. These infrastructure and interface specifications are described in the 'MedMij Afsprakenstelsel' for PGO use cases.
The birthcare information standard has overlap with other standards such as the BgZ (basisgegevensset zorg), Medication Process, Vital Signs and Lab Results. Birthcare uses the same HCIM based FHIR profiles for exchanging information as used in other standards extended with additional birthcare specific profiles. Most of these birthcare specific profiles are derived from the base HCIM FHIR profiles. For example, the bc-Woman is in fact a nl-core-patient with additional specifications for relating the pregnant woman to the (unborn) child.
3.1 A high level overview
4 FHIR Resources and StructureDefinitions
4.1 Types of resources and relations between them
4.1.1 Pregnancy and maternal record
A pregnancy (Condition) starts with a pregnant woman (Patient). Her data is registered in a maternal record (EpisodeOfCare). The maternal record contains references to the pregnant woman (subject), the pregnancy (condition), the care manager (careManager:Practitioner) and managing organization (managingOrganization:Organization).
4.1.2 Birth and Delivery
If all goes well a pregnancy ends with a delivery (Procedure). A delivery is related to the mother (subject). It has 3 stages: 1. dilation, 2. birth of one or more children and 3. afterbirth. There are no separate resource for the first and third stages of delivery, but the second stage of delivery is another Procedure, which is related to the child (subject). The Birth Procedure is part of the Delivery Procedure and in case of a multiple pregnancy, multiple Birth Procedures can be part of the same Delivery Procedure.
4.1.3 Obstetric procedures
Obstetric procedures are procedures related to pregnancy, birth and delivery. These procedures can be part of (partOf) a Birth Procedure (in case of child-related procedures, like a c-section) or a Delivery Procedure (in case of maternal procedures, like a blood transfusion). The partOf element can also be left blank when the procedure is linked to the pregnancy (record), but not to birth and delivery.
4.1.4 Relations between pregnancy, birth and delivery
A pregnancy (Condition), birth (Procedure) and delivery (Procedure) are all related to a maternal record (EpisodeOfCare) through their context element, either with a direct reference to the EpisodeOfCare or an indirect reference to an Encounter which in itself is linked to the maternal record (EpisodeOfCare). In addition, the Birth and Delivery Procedures both include a reference to the pregnancy (reasonReference).
4.1.5 Patterns
Several birth care concepts are represented by FHIR resources that have the same structure but differ in their clinical meaning. This applies in particular to Observations and Conditions. To avoid defining and implementing the same structure repeatedly, these resources are based on reusable patterns. A pattern defines the common FHIR structure and the rules that apply to a group of clinically related concepts. The individual concepts are distinguished by their terminology, such as the code used in Observation.code or Condition.code, and where applicable by additional constraints. For implementers, this means that resources that use the same pattern can be handled in a consistent way. An implementation does not need separate processing logic for every individual clinical concept, provided that it supports the FHIR profile representing the pattern and the terminology associated with the individual concepts. Each pattern is represented by a FHIR StructureDefinition. The pattern therefore does not replace a FHIR profile; it is itself expressed as a profile containing the structural requirements shared by the resources that use that pattern.
The following sections describe the patterns used for Observations and Conditions and specify how individual concepts are represented within these patterns. Pattern tables can be found on individual pattern pages, see links below.
4.1.6 Observation patterns
Observations follow patterns based on their subject (either the child or the mother patient) and their focal subject (either the pregnancy, birth or delivery), see table below. The use of focus extensions is a pre-adopt of FHIR R4, where it is part of Observation: "What the observation is about, when it is not about the subject of record." Focus is required for all Observations which do not pertain to the Patient. In R4, use of focus permits "reverse include" queries (give me all Observations with focus element X). In STU3, this could be a custom search.
| Pattern | Subject | Focus |
| Patient-related Observations | Mother patient | x |
| Pregnancy-related Observations | Mother patient | Pregnancy |
| Delivery-related Observations | Mother patient | Delivery |
| Birth-related Observations | Mother patient | Birth |
| Child-related Observations | Child patient | x |
| Fetus-related Observations | Mother patient | Fetus |
| Donor-related Observations | Mother patient | Donor |
| Procedure-related Observations | Mother patient | Procedure |
4.1.7 Condition patterns
Conditions follow patterns based on their category (disorders related to either pregnancy, labor and delivery, postpartum or child disorders). Pregnancy, birth and delivery related disorders use partOf to link to these concepts, see table below.
| Pattern | Subject | Category | PartOf |
| Pregnancy-related disorder | Mother patient | 173300003 | Pregnancy |
| Delivery-and-birth-related disorder | Mother patient | 362972006 | Delivery |
| Postpartum disorder | Mother patient | 362973001 | Delivery |
| Child-related disorder | Child patient | 414025005 | x |
4.1.8 Procedure pattern
A generic profile describing obstetric procedures. Obstetric procedures are procedures related to pregnancy, birth and delivery, such as vacuum delivery.
| Pattern | Subject |
| Pregnancy-birth-and-delivery-related procedures | Mother patient |
4.2 Guiding principles for resource use
1. Pregnancy identification
Determining whether data published from different sources belong to the same pregnancy can be done using the definitive term date. If this is not (yet) available, the estimated term date can be used.
Because in practice there can be some variation in the registered term date, a bandwidth of 4 weeks can be used. If the term date from source X differs by 4 weeks or less from the term date from source Y, it can be safely assumed that it is the same pregnancy of a woman.
For applications that can only publish the BgZ, the term date from a different source can be used to calculate a pregnancy period. This runs from term date – 40 weeks to term date + 6 weeks. Based on this, the BgZ data can be classified into the correct pregnancy(ies).
2. Practitioner.telecom and PractitionerRole.telecom
Practitioner and PractitionerRole instances should not contain telecom elements to prevent the exchange of personal information of care professionals like private phone numbers and email. The Organization resource contains the appropriate contact information for other professionals within the network.
3. Context level
Context element of resources should reference the lowest level of granularity available. Therefor, they should reference Encounters when they can and only Episode of care if they must.
4. Encounters
All moments of contact with the client should be published as Encounters including an Observation "Zwangerschapsduur" (PregnancyDuration, see next point).
5. Zwangerschapsduur (PregnancyDuration)
If one of the following resources is published it must be accompanied by an Observation "Zwangerschapsduur" (PregnancyDuration):
- Encounter
- Probleem (Zwangerschap) (DisorderOfPregnancy)
- Verrichting (Zwangerschap) (ObstetricProcedure)
- Bevalling (DeliveryProcedure)
- Probleem (Maternaal) (Problem, DisorderOfLaborAndDelivery, DisorderPostPartum)
- Verrichting (Maternaal) (ObstetricProcedure)
