FHIR Implementation Guide BirthCare v1.0
- 1 Introduction
- 2 FHIR Resources and StructureDefinitions
- 3 Terminology, NamingSystems, Mappings
- 4 BabyConnect Afsprakenstelsel
- 5 Actors
- 6 Invocations
- 7 Use cases
This page details the HL7 FHIR requirements for exchanging the BirthCare (Geboortezorg) data.
The functional view for BirthCare (Geboortezorg) 2.3 is described in Functioneel. Functional specifications for other datasets will follow.
The FHIR Implementation Guide for BirthCare is independent of the functional specifications. We expect the FHIR BirthCare IG to be compliant with datasets 2.3, 3.1 and 3.2. We do expect backwards compatible additions to the FHIR BirthCare IG for the latter datasets. The FHIR BirthCare IG does contain version-specific mappings to the various datasets, for now only 2.3 mappings.
Technical details of the FHIR resources and structure definitions described in this Implementation Guide (IG) can be found in the Simplifier Geboortezorg STU3 project. This IG provides links to the required resources and structure definitions for each use case.
A high level overview:
FHIR Resources and StructureDefinitions
Types of resources and relations between them
For Observations, which are often very similar, we follow patterns: an implementer will only need to implement the pattern and an associated table with codes, and be able to support all Observations. So for Observations pertaining to a particular pregnancy (not to the woman - she may have multiple pregnancies on record, neither to the delivery) all Observations will link to the Pregnancy Condition. So instead of having to inspect StructureDefinitions separately for each pregnancy observations, following a single pattern will do. The pattern has it's own StructureDefinition, so the FHIR profile is still complete. Likewise Observations for the mother, delivery and child follow patterns. See links below.
|Woman (Vrouw)||Patient||The core of each pregnancy is the pregnant woman, a FHIR Patient.|
|Maternal Observation (Bevinding vrouw)||Observation||Observations and findings related to the woman, before, during or after pregnancy childbirth. Examples are risk status or maternal ultrasound observations.|
|Partner||RelatedPerson||The partner of the pregnant woman (not necessarily the biological father).|
|Generic resources||Practitioner, PractitionerRole, Organization||Those are not used differently than in other Dutch projects.|
|Referral details||ReferralRequest||Referral details (such as type of referral, reason code, referrer and target of the referral) are described in ReferralRequest. The pregnant woman is the subject, the context is the pregnancy file (EpisodeOfCare).|
|Involvement pediatrician||CareTeam||A CareTeam describes the involvement of different care providers, such as a pediatrician.
|Pregnancy, Maternity Record||Condition, EpisodeOfCare||Each pregnancy is a Condition. It is also represented as an EpisodeOfCare for each involved Organization. The pregnancy includes references to an Organization and responsible Practitioner. (Practitioners responsible for the actual data may be included there, i.e. in Procedures, Observations.)
|Patient-related Observations||Observation||Observations such as blood type pertain to the Patient.
|Pregnancy-related Observations||Observation||Observations such as gravidity and parity do not (only) pertain to the Patient but to a particular pregnancy.
|Pregnancy-related disorder||Condition||Conditions such as cholestasis and hypertension do not (only) pertain to the Patient but to a particular pregnancy.
|Childbirth Assistance||Encounter||Childbirth Assistance is modeled as an Encounter. The woman Patient is subject of the Encounter.
|Delivery (Bevalling)||Procedure||Delivery is modeled with Procedure (even for uncomplicated natural births for consistency). A pregnancy can lead to one DeliveryProcedure even in multiple birth. The Patient is the subject.
|Delivery-related Observations||Observation||Observations such as onset of labor or blood loss pertain to a delivery Procedure.
|Disorder of labor and delivery||Condition||Disorders occuring during or after delivery are related to either the Delivery (if pertaining to the mother) or to the Birth (if pertaining to (one of) the children).
|Post partum disorder||Condition|
|Birth||Procedure||This groups findings and procedures related to a particular child in a delivery - important in multiple births. A Birth has:
|Birth-related Observations||Observation||Observations such as parturition type pertain to a birth. They are also about the mother, which still is the subject.
|Child||Patient||Child is a separate Patient.
|Child-related Observations||Observation||Observations such as Apgar score and birthweight pertain to the child Patient, which is the subject of these Observations.
|Child disorders||Condition||Child disorders such as chromosomal and congenital abnormalities or other problems are conditions. The child is the subject.
|Diagnostic Reports (Onderzoeksverslagen)|
|Combined test||DiagnosticReport||Combined test (combinatietest) verslag. The woman Patient is the subject of the report.
|Digital vaginal examination||DiagnosticReport||The digital vaginal examination DiagnosticReport groups Observations related to the digital vaginal examination. The woman Patient is the subject of the report.
|Ultrasound (Echoverslag)||DiagnosticReport||The ultrasound groups Observations. The woman Patient is the subject of the report.
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.
The use of context is encouraged for all resources which have a context element. It is a reference to an EpisodeOfCare or an Encounter. Context should point to an Encounter when appropriate (scheduled maternity checks etc.) and to the EpisodeOfCare in all other cases. Possibly it will be absent in Observations where the source is not birth care, so readers should not rely on it's presence.
Observations should include a performer if known.
Pattern tables can be found on individual pattern pages and on Gebz:V2.3_FHIR_mapping_addendum.
The mapping is also available as an XML file: fhirmapping.xml
Terminology, NamingSystems, Mappings
Relevant value sets can be found here. All resources can be downloaded in a .zip in XML or JSON format. In the .zip, the value sets are stored in the directory 'value sets'.
The BabyConnect Afsprakenstelsel describes the BabyConnect architecture, which defines the following modules and transactions.
|A||Healthcare information system (XIS)||Send transaction to module B|
|B1||Convertor||Translates ADA transaction to FHIR transaction Bundle which is sent to module B2|
|B2||FHIR server||Receives and stores FHIR data|
|C||Index||Indexes and retrieves FHIR data from module B2|
|D1||Query builder||Translates user query to a FHIR query which is sent to module C|
|D2||Translator||Translates FHIR data retrieved from module C back to ADA format|
|E||Viewer||Collects the data and presents it to the end user|
Module B and D are added to make it easier for XIS and viewer vendors to connect to BabyConnect. XIS and viewer vendors are however encouraged to implement their own FHIR API as module B and D will phase out eventually.
BabyConnect defines the following transactions:
|Publish transaction (PUSH)||Publish transaction||Healthcare professional (using a XIS)||Sends transaction to registry|
|Retrieve transaction (PULL)||Retrieve transaction||Healthcare professional (using a XIS and/or viewer software)||Retrieves transaction from registry|
Module A and E can either directly interact with the FHIR server (which they are encouraged to do) or use the convertor and translator software of module B and D.
Publishing XIS: request message
The publishing XIS or convertor executes a HTTP POST request of a Bundle with Bundle.type = transaction to the target's base endpoint. The first Bundle.entry contains a Composition resource, and each subsequent entry contains a resource that is referenced from the Composition resource.
As a result, all FHIR resources included in the Bundle will be stored individually in the FHIR server.
To persist a Document Bundle at the FHIR server (e.g. to preserve the clinical context), the publishing XIS or convertor should execute a HTTP GET request to the Composition endpoint of the FHIR server, handling the createDocumentOperation with persist=true. The response is a FHIR Document Bundle, which is generated from the Composition resource and stored to the FHIR server's Bundle endpoint.
Retrieving XIS: request message
When persisted at the FHIR server, FHIR Document Bundles can be retrieved by a HTTP GET request to the FHIR server's Bundle endpoint. Note that FHIR Document Bundles are immutable and its entries refer to a time-related version of a resource which is not necessarily its latest version.
Individual resources can be retrieved by HTTP GET requests to specific resource endpoints, see the Search section and list of StructureDefinitions below.
Example FHIR resources can be found here: 
Example search URLs can be found in the list of StructureDefinitions in each use case section. Some searches require the implementation of custom search parameters. These parameters can be found here: https://simplifier.net/geboortezorg-stu3/~resources?category=SearchParameter