Gebz:V1.1 FHIR IG

Introduction

This page details the HL7 FHIR requirements for exchanging the BirthCare (Geboortezorg) data.

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 and 3.2 mappings.

The functional view for BirthCare (Geboortezorg) 3.2 is described in Functioneel. The functional view for BirthCare (Geboortezorg) 2.3 is described in Functioneel. Functional specifications for other datasets will follow.

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.

Profile	Pattern	FHIR resource	Description
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).
Practitioner, PractitionerRole, Organization		Practitioner, PractitionerRole, Organization	Generic resources. 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. These care providers are included as participants in the CareTeam using the CareTeam.participant.member element. Participants may either be Practitioners or Organizations. Their role and period of involvement are described at the participant level (that is CareTeam.participant.role and CareTeam.participant.period). The reason of involvement is described in CareTeam.reasonCode
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.) Condition points to the EpisodeOfCare through a EpisodeOfCare.context.reference element. (Note: different providers may each have their own Condition resource.) EpisodeOfCare points to the Condition through a EpisodeOfCare.diagnosis.condition element. Condition points to the Patient with Condition.subject.reference Condition.status must be 'active' for ongoing pregnancies and 'inactive' for past ones.
Patient-related Observations	Patient-related Observations	Observation	Observations such as blood type pertain to the Patient. Observations can refer to an EpisodeOfCare with Observation.context.reference
PregnancyObservation	Pregnancy-related Observations	Observation	Observations such as gravidity and parity do not (only) pertain to the Patient but to a particular pregnancy. Pregnancy-related Observations use focus extension to point to Condition they're about. Without this, all gravidities would only be Observations about a Patient. Pregnancy-related Observations refer to the EpisodeOfCare with Observation.context.reference
Pregnancy-related disorder	Pregnancy-related disorder	Condition	Conditions such as cholestasis and hypertension do not (only) pertain to the Patient but to a particular pregnancy. Pregnancy-related Observations use partOf extension to point to Condition they're about. In some cases the partOf Condition may not be available. The BGZ for instance does not relate Conditions to particular pregnancies. Pregnancy-related Conditions refer to the EpisodeOfCare with Observation.context.reference
Childbirth Assistance		Encounter	Childbirth Assistance is modeled as an Encounter. The woman Patient is subject of the Encounter. The place of birth is described in Encounter.class using a ConceptMap to map values to available FHIR codes The Encounter.diagnosis element refers to the Pregnancy (Condition) The Encounter.participant element containts a list of care providers that were present during delivery. Family members and even the woman Patient could also be included in this list. Additional details can be defined at participant level, such as participant type and time of arrival. The latter uses an extension at participant level with a coded list of time of arrival. Childbirth Assistance refers to the EpisodeOfCare with Encounter.EpisodeOfCare.reference
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 refers to the EpisodeOfCare with Procedure.context.reference Delivery refers to the Pregnancy with Procedure.reasonReference.reference
Delivery-related Observations	Delivery-related Observations	Observation	Observations such as onset of labor or blood loss pertain to a delivery Procedure. Delivery-related Observations use focus extension to point to the delivery Procedure they're about. Delivery-related Observations refer to the EpisodeOfCare with Observation.context.reference
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). A partOf extension is used to point to the Delivery of the Birth. context is the Maternal Record or an Encounter.
Obstetric Procedure		Procedure
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: a partOf extension, pointing to the Delivery subject is the Child context is the Maternal Record EpisodeOfCare
Birth-related Observations	Birth-related Observations	Observation	Observations such as parturition type pertain to a birth. They are also about the mother, which still is the subject. Birth-related Observations use focus extension to point to a birth. Birth-related Observations refer to the EpisodeOfCare with Observation.context.reference
Child		Patient	Child is a separate Patient. Procedure-related Observations use focus extension to point to the child Patient they're about.
Child-related Observations	Child-related Observations	Observation	Observations such as Apgar score and birthweight pertain to the child Patient, which is the subject of these Observations. Child observations refer to the EpisodeOfCare with Observation.context.reference
Child disorders		Condition	Child disorders such as chromosomal and congenital abnormalities or other problems are conditions. The child is the subject. Child disorders can refer to the EpisodeOfCare with Condition.context.reference A ConceptMap is available to map verification status to accepted FHIR codes
Diagnostic Reports (Onderzoeksverslagen)
Combined test		DiagnosticReport	Combined test (combinatietest) verslag. The woman Patient is the subject of the report. This report refers to the EpisodeOfCare with DiagnosticReport.context.reference
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. This report refers to the EpisodeOfCare with DiagnosticReport.context.reference
Ultrasound (Echoverslag)		DiagnosticReport	The ultrasound groups Observations. The woman Patient is the subject of the report. This report refers to the EpisodeOfCare with DiagnosticReport.context.reference

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 for 2.3 mappings and Gebz:V3.2_FHIR_mapping_addendum for 3.2 mappings.

The mapping is also available as an XML file: fhirmapping.xml for 2.3 mappings and fhirmapping-3-2.xml for 3.2 mappings.

Terminology, NamingSystems, Mappings

Terminology

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

BabyConnect Afsprakenstelsel

The BabyConnect Afsprakenstelsel describes the BabyConnect architecture, which defines the following modules and transactions.

Modules

Module	Name	Role
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.

Transactions

BabyConnect defines the following transactions:

• Publish
• Retrieve
• Authorize
• Share
• Collect

Actors

Transaction group	Transaction	Actor	Role
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.

Invocations

Publishing XIS: request message

Message Semantics

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.

POST [base]{&_format=[mime-type]}

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.

GET [base]/Composition/[id]/$document?persist=true{&_format=[mime-type]}

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.

GET [base]/Bundle/[id]{&_format=[mime-type]}

Individual resources can be retrieved by HTTP GET requests to specific resource endpoints, see the Search section and list of StructureDefinitions below.

Examples

Example FHIR resources can be found here: Simplifier.net/geboortezorg-stu3/~resources?category=Example

Search

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

Use cases

Use cases dataset 2.3

Use cases 2.3

Use cases dataset 3.2

Use cases 3.2