Stream: implementers
Topic: Mother/Child record
Grahame Grieve (Feb 02 2018 at 19:40):
An outcome of today's clinicians on FHIR is a series of questions about clinical records in FHIR around mother and child, both during and after pregnancy. How should these things be represented in FHIR:
- the child was exposed to a medication administered to the mother before birth
- the child has [condition] because of a procedure performed on the mother
- the fetal heartbeat for fetus B is Xbpm
- the womb length is Xcm and the Baby height is Ycm
I have my own ideas about how those things might be represented in the clinical resources, but the first question is, how do vendors around the world handle these interlinked records - are the records interlinked? When do newborns get ids assigned or records created? How would you do attribution across the records?
I suspect that the answers to these questions will vary widely between institutions, vendors, and jurisdictions. But we need at least some consistency in the FHIR representation. The proposal is that I write a section about this on http://build.fhir.org/clinicalsummary-module.html.
Thoughts? (particularly @Jenni Syed @Danielle Friend @Malcolm Pradhan @Abigail Watson )
Kevin Olbrich (Feb 02 2018 at 21:30):
Maybe you can do a contained Patient for the child? :)
Brian Postlethwaite (Feb 02 2018 at 21:54):
(Still trying to decide if that was a joke that the Baby resource was contained in the Mother resource or not ;)
There are sample resources that PA put in for a mother, and child (with appropriate RelatedPerson too) that you could use in your examples
http://build.fhir.org/patient-example-mom.xml.html
http://build.fhir.org/patient-example-newborn.xml.html
http://build.fhir.org/relatedperson-example-newborn-mom.xml.html
Kevin Olbrich (Feb 02 2018 at 22:04):
Yeah, it was a joke.
Abbie Watson (Feb 03 2018 at 14:26):
We'll probably be leveraging JSON as much as possible to model things as biological processes. This gets back to my question of flattening nested FHIR resources into one large JSON file vs sending over bundles or lists of separate resources (we do a lot of the former internally in the Javascript community; it's super convenient and useful).
Internally, we would use both... during pregnancy, the records are all kept in the maternal record; and at birth, the child subobject is used to create a new account; either as a template or simply copied/moved over. Keep things simple. Model the data just like the real world.
I'm very keen on the idea of the Provenance resource, and have some ideas on how to use it throughout our entire app to indicate data quality... this data in your aggregated continuity of care timeline is from a hospital; this data is from your medical devices; these data points are from social media; these are self-reported. We're probably going to display them with different colors or icons; that type of thing. And in keeping with that approach... adding 'this data was derived from the mother's records' would fit perfectly.
So, we'll probably keep a maternal MRN associated with the child (possibly/probably paternal also), and have provenance lookup functionality; and the parental records on hand as available. Probably some sort of extension to reference the parents on a Patient resource. Then, when Observations that are generated via a lookup on that parent reference, attach a Provenance resource to each new Observation describing that this was indirectly observed data.
Would definitely be interested in hearing how others are implementing this.
Lloyd McKenzie (Feb 03 2018 at 14:49):
Glad to see Provenance with a place of provenance in an EHR :) Something else I'm interested in is that linking child to parent records is a very natural thing for newborns/infants, but starts to raise potential privacy issues as the child ages and particularly once they reach the point of legal self-determination. Does anyone have thoughts on a need to "unlink" parent and child records at a particular point (or at least more strictly control how that linkage is used)?
Lloyd McKenzie (Feb 03 2018 at 14:51):
In terms of flattening, you can do whatever you like internally, but for it to be "exchangeable", we'd have to address it in all of the syntaxes, we'd have to make it work with the schema representations of the different syntaxes and we'd have to ensure consistency of how it was done - and I suspect the way data would be flattened would typically be context-specific, making consistency difficult.
John Silva (Feb 03 2018 at 19:03):
That also brings up the use case of the adoptive mother and the birth mother (e.g. for surrogates); how would that be handled?
Peter Jordan (Feb 04 2018 at 01:31):
Those born in NZ hospitals have National Health Index (NHI) identifiers assigned to them as soon as birth delivery details are entered on the hospital system. My kids' NHIs were on the Mother & Baby Discharge Summaries issued only a few hours after the birth events. The link to the mother is via her NHI number but, at present, the information from the hospital system isn't passed back to primary care (very few GPs in NZ now provide ante-natal care and the first 6 weeks of post-natal care is done by an agency called Plunket) - although the GP systems do pick up the NHI number, via the Patient Identity Service, when a baby is first enrolled at a general practice.
Cooper Thompson (Feb 05 2018 at 20:20):
@Grahame Grieve We have the concept of a fetal chart where meds, fetal surgery, lab orders, etc. can be documented. It is linked to the mother. We have a special patient-to-patient link for mother/baby, which is not really a RelatedPerson, though maybe we could represent it that way, though given the special biological connection pre-birth I don't know that RelatedPerson is there right answer. We do allow un/re-linking (for correction workflows). I think we apply all the normal rules for institutional MRN assignment, but I can double check that. We do have special rules for national ID assignment in some realms (i.e. we don't trigger a request to the national ID assigner for fetal charts).
Grahame Grieve (Feb 06 2018 at 00:46):
so you have a general record level link? - no cross linking at a finer granularity?
Cooper Thompson (Feb 06 2018 at 15:25):
We have a special "mother's record link" on the baby.
Grahame Grieve (Feb 06 2018 at 20:28):
thanks
Jenni Syed (Feb 06 2018 at 20:41):
We're still looking into it :)
Malcolm Pradhan (Feb 07 2018 at 01:57):
Similar approach - we have a fetal/neonatal resource, also used to calculate gestational age and corrected age for prems.
BTW is there a preferred way to represent a condition secondary to a procedure (as in Grahame's example)? Condition.evidence doesn't seem to be quite right.
Grahame Grieve (Feb 07 2018 at 01:58):
what else does it contain?
Malcolm Pradhan (Feb 07 2018 at 02:44):
Very similar to the clinical summary, which we will upgrade to at some point. We only generate Patient & Encounter resources when triggered through the PAS, so we use the fetal/neonate resource to track observations, tasks, notes, etc. until we get confirmation of the child's MRN/NHI. It has grown a bit to also handle some basic neonatal information before the child is entered into the PAS. E.g. neonatal screening tasks, baby location (so they don't forget where they left it...)
The problem we have is that most PAS systems we have encountered don't explicitly link the baby to the mother.
Bob Dolin (Feb 07 2018 at 22:49):
Grahame, for the mother-fetus scenario, we have a somewhat similar scenario where we need to take repeated measurements of one or more masses seen on imaging. We want to say for instance "mass 1 is 3cm diameter today, and was 2.5cm last month". Neither observation.subject nor observation.specimen seem just right. Perhaps there is a need to broaden the notion of observation.subject to other types of things?
Grahame Grieve (Feb 07 2018 at 22:51):
OO has defined http://build.fhir.org/extension-observation-focal-subject.html for this use case, I believe
Bob Dolin (Feb 07 2018 at 23:00):
Thanks. I see how that can meet the mother/fetus case, but not the repeated measurements of lesions seen on imaging. In the latter case, the focal-subject is a diagnostic imaging finding.
Grahame Grieve (Feb 07 2018 at 23:02):
http://build.fhir.org/extension-body-structure.html ? @Eric Haas @Rob Hausam any further comments?
Lloyd McKenzie (Feb 07 2018 at 23:07):
@Bob Dolin Also look at the BodySite resource. That allows you to document multiple observations and procedures over time that all apply to the same lesion/tumor/fetus/etc.
Bob Dolin (Feb 07 2018 at 23:20):
Would it make sense to add bodyStructure or bodySite into the list of things that can be referenced by focal-subject?
Bob Dolin (Feb 07 2018 at 23:25):
or allow observation.bodySite to be a bodySite reference OR a codeable concept?
Lloyd McKenzie (Feb 07 2018 at 23:43):
Sorry, forgot it had been renamed BodyStructure. There's actually an extension that allows it to be referenced from various resources. It might make more sense as a focal subject, but in theory you could have all three - mother, fetus, body feature within fetus.
Bob Dolin (Feb 07 2018 at 23:50):
very helpful. Thank you guys
Rob Hausam (Feb 08 2018 at 17:33):
Something does seem to be missing here (but maybe it's just me that's missing it). Obviously I should have been paying more attention. Though we don't need it for the mother/fetus case, I was thinking that we had the ability to specify locations relative to anatomical landmarks (or other coordinates), but I'm not finding that in the resources or extensions. Would like to get @Eric Haas's thoughts.
Eric Haas (Feb 08 2018 at 20:17):
Specimen and bodysite are always a kind of focal subjects for Observations. Use the Bodystructure extension as Lloyd points out if you want to track the bodysite.
Michelle (Moseman) Miller (Feb 08 2018 at 23:32):
We recommend documenting against one or more babies within the mother’s chart prior to delivery. We offer ways to distinguish baby A versus baby B observations. Once delivered, the baby is registered and the baby's record is created. We provide the ability to copy observations and documents from mom's record to baby's record. Medications, for example, typically stay on the maternal chart. The maternal and baby charts are related, so users can gather any additional maternal information that has not copied to the baby’s chart. It’s then up to the practitioner caring for the newborn to begin the newborn’s own history information based on information gathered in the maternal chart.
CC: @Jenni Syed
Grahame Grieve (Feb 09 2018 at 01:14):
so I think that we should 2 things:
- add a page to the specification describing how all this is represented in resources
- define a new resource "BirthRecord" with contents something like:
BirthRecord
- baby[x] int | Reference(Patient) 0..1
- mother : Reference(Patient) 1..1
- father : reference(RelatedPerson) 0..1
- LMP : date 0..1
- expected/plannedDoB 0..1
- dateOfBirth 0..1
- timeOfBirth 0..1
- consultation : Reference(Encounter|Composition) 0..*
- birth : Reference(Procedure) 0..1
- birthDetails : Reference(Observation | Condition) 0..*
Lloyd McKenzie (Feb 09 2018 at 01:52):
I'm not really a fan of this. LMP is an observation - and could be captured multiple times and may not always get the same answer. expected/plannedDoB is also an observation and has associated with it a method and there will typically be many predications over the course of a pregnancy (hopefully with increasing accuracy). dateOfBirth/timeOfBirth replicate information from both the procedure and the Patient. Linking everything in a pregnancy together (all of the measurements of the mother, heart rates, etc.) is intended to be managed under EpisodeOfCare which already has the ability to link all of these things.
Lloyd McKenzie (Feb 09 2018 at 01:53):
The notion of a "birth record" is similar to occupational health and all sorts of other instruments where you gather a bunch of information (observations, meds, encounters, etc.) and present them in a particular way. We do NOT want to introduce a resource for every single one of these - we'll end up with hundreds.
Richard Townley-O'Neill (Feb 09 2018 at 01:56):
Is a birth record a composition?
Richard Townley-O'Neill (Feb 09 2018 at 01:57):
A section?
Grahame Grieve (Feb 09 2018 at 01:59):
LMP is decision, based on an observation
Grahame Grieve (Feb 09 2018 at 02:00):
Some of it may be better in EpisodeOfCare, yes.
Lloyd McKenzie (Feb 09 2018 at 02:12):
Composition is about presentation for human review. The information certainly could be packaged into a document, but it should never need to be.
Lloyd McKenzie (Feb 09 2018 at 02:13):
Don't really get the distinction of "decision" vs. "observation" @Grahame Grieve
Grahame Grieve (Feb 09 2018 at 02:22):
I observe an LMP
I decide that for this pregnancy, we will estimate an LMP of X (sometimes it's not an observation)
Lloyd McKenzie (Feb 09 2018 at 02:45):
To me, an estimate is still an observation. In v2, it'd be an OBX. In v3 it'd be an ObservationEvent. In FHIR, we have nothing to capture it other than Observation and the elements of Observation all apply.
John Silva (Feb 09 2018 at 14:12):
The mother/father properties do not seem to handle the situation where there is a surrogate mother and a birth mother. (I suppose the father might not be known directly if from 'sperm bank' though the cardinality of 0 handles that; unless there is a need to know about preexisting genetic issues with the father.)
Abbie Watson (Feb 09 2018 at 16:43):
EpisodeOfCare has a certain assumption of the role of a care provider being centrally involved (and hence payment), whereas BirthRecord may better accommodates at-home births.
Lloyd McKenzie (Feb 09 2018 at 20:04):
I don't think there's anything about Episode that is necessarily provider-centric. It's more condition-centric. It would integrate encounters, conditions, Observations, etc. from a variety of practitioners (and the patient themselves) that all pertain to a particular pregnancy or fetus.
Tim Blake (Feb 12 2018 at 00:16):
@Grahame Grieve The NHS BirthRecord (albeit a draft based on DSTU 2) is modelled as a Bundle: https://nhsconnect.github.io/Digital-Child-Health/Generated/Profile.BirthDetails/dch-bundle-1.html Thoughts on this verses a resource?
Vassil Peytchev (Feb 12 2018 at 02:39):
In the NHS case, is BirthRecord representative of a legal document, or another standalone artefact? If so, a composition might be something to consider (based on Richard's comment)...
Lloyd McKenzie (Feb 12 2018 at 02:42):
Composition can wrap anything. But it's not a primary representation of anything.
Tim Blake (Feb 12 2018 at 05:03):
In Australia the birth record isn't a legal document, but it is a somewhat standardised record (with state to state variations) that gets written into a paper child personal health record.
Tim Blake (Feb 12 2018 at 05:04):
I think there is a good case to be made for making BirthRecord a resource
Grahame Grieve (Feb 12 2018 at 19:34):
I expect that a full birth record will be a set of resources, that may be wrapped in a Bundle, potentially with a Composition. But the actual birth details have to be somewhere, and we don't have anything for that right now. Hence, I propose a BirthRecord resource
Lloyd McKenzie (Feb 12 2018 at 21:48):
I don't see anything in your list that isn't already covered by other resources. Expected birth date and LMP are both Observations too.
Tim Blake (Feb 13 2018 at 02:33):
Perhaps then the resource could be BirthDetails, with a birth record being the larger bundle / composition...
Lloyd McKenzie (Feb 13 2018 at 03:56):
I don't see a need for a resource at all. All of the other information can be captured using existing resources. So all that's really needed is a profile on Bundle or Composition to group things together.
Grahame Grieve (Feb 13 2018 at 09:21):
most of the information can be captured, but what links together as a coherent whole? As for the information:
BirthRecord
- baby[x] int | Reference(Patient) 0..1 - - where is this prior to birth?
- mother : Reference(Patient) 1..1 - where is this?
- father : reference(RelatedPerson) 0..1- where is this?
- LMP : date 0..1 - which observation is the right one?
- expected/plannedDoB 0..1 - what is this? how do you find it
- dateOfBirth 0..1
- timeOfBirth 0..1
- consultation : Reference(Encounter|Composition) 0..* - how do you find these?
- birth : Reference(Procedure) 0..1
- birthDetails : Reference(Observation | Condition) 0..* - how do you find these?
Lloyd McKenzie (Feb 13 2018 at 18:10):
1. I'd expect there to be a pregnancy EpisodeOfCare. I'd also expect there to be a BodySite for each fetus to track things over time. We should have an extension that links the BodySite to the eventual Patient resource.
2. We've talked about having an extension that allows linking "baby" Patient to "mother" Patient
3. This could be RelatedPerson or could be "baby" Patient.contact. Given it tends to be capture for administrative purposes, I'd lean towards the latter.
4. The right LMP is the one that's linked to the Episode. If there are multiple linked to the episode for some reason, it's the most recent
5. ExpectedDoB is an Observation (with derivedFrom links to a LMP observation and/or an ultrasound image. PlannedDoB for a scheduled caesarean would be in appointment
6/7 date/timeOfBirth are on the "baby" Patient and on the delivery Procedure
8. You find the encounters because they're tied to the EpisodeOfCare
10. The birth details would also be tied to the EpisodeOfCare - and possibly the birth Procedure
Lloyd McKenzie (Feb 13 2018 at 18:10):
I agree that we'd want a "view" that shows the relevant information - but we're going to have 100s of views for different purposes and we absolutely don't want to create a resource for each of them.
Peter Jordan (Feb 13 2018 at 19:52):
As many are aware, I've been arguing for a dedicated 'Maternity' resource for several years. While I fully understand Lloyd's arguments against this, I think that it is clearly the exception that breaks the rule precluding one resource per specialty. I've worked on 3 major maternity system implementations during my career and, as things currently stand, would find it very hard to recommend, or use, FHIR as a means of exchanging, modeling, processing or persisting maternity data. It requires an 'anchoring' resource because of the sheer size and complexity of the data model (the NZ version is a door-stopper) and number of associated events. Furthermore it is the start of the patient journey/record - where it all starts for 100% of us (no kidding).
Grahame Grieve (Feb 15 2018 at 01:42):
@Peter Jordan do you or anyone else have a good example data set for us to iterate on as an example?
Peter Jordan (Feb 15 2018 at 03:01):
Don't have any sets of test data left from my time at National Womens' Hospital, but have emailed you copies of the NZ Maternity Data Dictionary and CDA Template 'standard'.
Jason Walonoski (Feb 15 2018 at 14:20):
I'd be interested in generating these in Synthea, if I had some good examples to work from.
Ive Kohnenkamp (Jun 07 2018 at 20:07):
Has there been any further discussion on the Mother/Child record issue? With respect to simply identifying a patient as pregnant, the prefered resource is observation o condition? In the documentation pregnancy is mentioned in both.
Grahame Grieve (Jun 07 2018 at 20:08):
Condition for being pregnant. Observation for LMP
Marc de Graauw (Mar 26 2019 at 15:38):
@Lloyd McKenzie You write:
I don't think there's anything about Episode that is necessarily provider-centric. It's more condition-centric. It would integrate encounters, conditions, Observations, etc. from a variety of practitioners (and the patient themselves) that all pertain to a particular pregnancy or fetus
I like that approach, but EpisodeOfCare seems to forbid it:
Many organizations can be involved in an EpisodeOfCare, however each organization will have their own EpisodeOfCare
So I'd probably need a Condition (being a pregnancy) with multiple Episodes, one for each involved provider. That does not seem to capture the reality of maternal care, which does involve multiple parties around a single pregnancy, not sequentially but in parallel. So is one Episode which aggregates data from multiple providers OK or not? (Sorry, old thread, but working on this now.)
Lloyd McKenzie (Mar 26 2019 at 15:42):
I think there should be a 'typically' in there. The wording reflects typical practice, not an absolute rule. (We try hard to not dictate business rules in resources.) Feel free to submit a change request to improve the wording. And certainly don't feel bound by that wording in your use of the resource now.
Marc de Graauw (Mar 26 2019 at 16:03):
Thanks, just submitted #20612
Marc de Graauw (Mar 27 2019 at 16:50):
Pregnancy records have a lot of data: gravida, parida, amniocity, subfertility treatment and so on. These can be modelled as (a battery of) Observations. Of course, since a woman can have multiple 'pregnancy' Episodes, the Observations need to be associated with the proper Episode. I see some possibilities:
- EoC does not have a reference to Observation (nor a Reference(Any)). There is a workflow extension, which might be the thing to use, but there's not a lot of guidance in the extension on intended use.
- EoC can link to condition, which can link to Observation, but only in condition.stage and condition.evidence which seems far-fetched.
- I could use some grouping mechanism as Composition and DocumentReference, but that doesn't seem to grasp the relatedness between the Episode and the Observations.
- Observation can reference Encounter (used to be Episode | Encounter, but that didn't make it to normative), which can reference EpisodeOfCare. However, typically the exact Encounter where an Observation which pertains to the entire pregancy isn't recorded (here in the Netherlands anyway). So the Encounter for blood pressure (which changes) is known, for gravida (which does not change during this pregnacy, isn't). So to do this I'd need an almost empty un-dated Encounter to gather those data
Anybody any ideas which is the best approach (of another, which I've overseen)?
Lloyd McKenzie (Mar 27 2019 at 16:57):
The expectation is that stuff that's relevant to the episode points to the episode with the extension. (It's an extension because we don't feel most systems support linking to episodes).
Marc de Graauw (Mar 27 2019 at 17:01):
Fair enough. Thx.
Javier Espina (May 05 2019 at 16:37):
The Patient resource explains how to deal with mother and newborn https://www.hl7.org/fhir/patient.html#maternity. It says that to link the mother and baby encounters the encounter.partof element should be used. I wonder whether this recommendation is a correct use of the element, since it is not really part of but rather a very much related encounter. The issue I bumped into is that encounter.partof has a maximum cardinality of 1 and I am already using it in some profiling for establishing relationships between encounters at institution and health system level (the first would refer to the latter in encounter.partof).
Last updated: Apr 12 2022 at 19:14 UTC
