FHIR Chat · Recording Mothers and Fathers · implementers

Stream: implementers

Topic: Recording Mothers and Fathers


view this post on Zulip Craig Newman (Jan 28 2020 at 20:17):

As part of a birth defects reporting problem, we're looking to capture information about the patient's mother and father. For the most part, RelatedPerson works but there are a few things I'm not sure how to handle:
1) If we need to make observations about the parent (education level, alcohol/drug use, chemical exposures, etc) what is the best way to do that? Observation isn't allowed to point to a RelatedPerson. Should we create extensions for RelatedPerson or should the parents themselves also be Patient resources (even if they may not actually be a patient)?
2) If the parent is represented using RelatedPerson but they are deceased (we still want to capture information on them), does that violate the spirit of RelatedPerson as someone "that is involved in the care for a patient"?

view this post on Zulip Grahame Grieve (Jan 28 2020 at 20:24):

where does RelatedPerson enter the picture? Only when the parents do something ?

view this post on Zulip Grahame Grieve (Jan 28 2020 at 20:25):

Observation - Observation.subject is the baby. Focus is the Parent (which answers my question above... duh... that would be RelatedPerson. You should make a task to clarify the definition of RelatedPerson for this use case

view this post on Zulip Craig Newman (Jan 28 2020 at 20:56):

Just to make sure I have it clear, the Observation should have a subject on the baby even though the Observation is about the mother herself (her education level, alcohol use, etc) or is subject not populated at all, just focus?

view this post on Zulip Grahame Grieve (Jan 28 2020 at 21:00):

the observation is about the subject, but made on the mother. So

subject = baby
focus = mother

populate both

view this post on Zulip Craig Newman (Jan 28 2020 at 21:38):

And when you say "You should make a task to clarify the definition of RelatedPerson for this use case", does that mean a JIRA ticket to update the description of RelatedPerson to account for the fact that may still be important even if they aren't involved in patient care or decision making?

view this post on Zulip Grahame Grieve (Jan 28 2020 at 21:39):

yes

view this post on Zulip Craig Newman (Jan 29 2020 at 13:07):

done - https://jira.hl7.org/browse/FHIR-25727

view this post on Zulip Frank Oemig (Feb 01 2020 at 09:25):

Sorry, I am confused. The question is about an observation about father or mother.

Patient = baby
Observation.subject = father
??

view this post on Zulip Grahame Grieve (Feb 01 2020 at 09:42):

it's subject and focus not patient and subject - that's what OO have said.

view this post on Zulip René Spronk (Feb 03 2020 at 07:35):

patient = in which persons record this will be stored, relevant for the treatment of that specific person (in the older Hl7v3 standard this was called recordTarget)
subject = clinical subject of the observation

view this post on Zulip Frank Oemig (Feb 03 2020 at 09:13):

@Grahame Grieve Ok, understood.

So the subject is not the clinical object.
But in this case focus is on mother we have to use a modifier-extension that focus is not on the subject in order to distinguish it from 'normal' observations.

view this post on Zulip Grahame Grieve (Feb 03 2020 at 12:49):

no I don't understand that. Focus is a modifier element that says that

view this post on Zulip Sarah Gaunt (Mar 18 2021 at 19:45):

How would the Observation.subject = baby and Observation.focus = parent work for multiple pregancies (twin, triplets, etc)?
In the case of say Mother's Education, you'd need to have one Mother's Education Observation for each baby in the pregnancy?

view this post on Zulip Lloyd McKenzie (Mar 18 2021 at 20:16):

Pretty much - because each baby would have its own patient record.

view this post on Zulip Sarah Gaunt (Mar 18 2021 at 20:49):

Right - thanks...

view this post on Zulip Eric Prud'hommeaux (Mar 23 2021 at 13:21):

vaguely related, is there any place to convey responsible proxies?
for children, that's likely to include parents, foster parents, gov't employees/roles in the case of a ward of the state

view this post on Zulip David Pyke (Mar 23 2021 at 13:21):

THat's normally done via RelatedPerson

view this post on Zulip Eric Prud'hommeaux (Mar 23 2021 at 13:50):

tx. are there valuesets like https://www.hl7.org/fhir/valueset-parent-relationship-codes.html that apply to legal cases like the proxies listed above?

view this post on Zulip Cooper Thompson (May 12 2021 at 19:58):

@Craig Newman - did you end up going with Observation.focus pointing to a RelatedPerson? We are looking at FHIR#25727 and are curious what you ended up doing.

view this post on Zulip Craig Newman (May 14 2021 at 16:32):

We're still tentatively going that way (work on that FHIR IG has hit a bit of a lull, so we haven't got much implementation feedback yet). Some of the profiles we were going to create have been consumed by a more general Public Health profile library but we had the same questions.
@Sarah Gaunt - the PH profiles are still using Observation.focus for RelatedPerson observations (eg Father's education) right?

view this post on Zulip Sarah Gaunt (May 14 2021 at 20:28):

Yes, that's correct - subject is baby and focus is parent.

view this post on Zulip Martin Grundberg (May 17 2021 at 14:33):

We are looking into this use case as well and have come to a few conclusions:

As stated already above

  • Observation.subject --> the patient to who's record the Observation belongs
  • Obseravtion.focus --> the relative (e.g. mother/father)

Additionally

  • Observation.code --> should not pre-coordinate the fact that this is someone else's Observation, ie use a concept for Body Height as opposed to Mother's Body Height. Reason for this is that otherwise there is a room for ambiguity with how to use focus (is it needed? if used, could it be the grandmother/fathers height) as well as scalability issues with precoordinating such concepts.

Additional discussions/thoughts

  • Why is there an explicit FamilyMemberHistory to use for certain family member information? Why not just use Condition with a focus element (or use the focus pattern on any more "fundamental" resource to which there could be another focus than the subject, feels like it scales better)?
  • Even if we stick with FamilyMemberHistory, why not use the same naming conventions as in Observation to make this use case easier for implementers. Ie, use FamilyMemberHistory.focus as opposed to FamilyMemberHistory.???
  • There also seems to be some overlap between FamilyMemberHistory and RelatedPerson, why not reference a related person in the FamilyMemberHistory instead of explicitly specifiying several elements that exist on RelatedPerson?

This is a common use case in healthcare, and it is difficult for implementers to know how to support these use cases. Hence a pattern for how to do this type of thing would be nice.

view this post on Zulip Lloyd McKenzie (May 17 2021 at 18:19):

@Hans Buitendijk @Eric Haas

view this post on Zulip Eric Haas (May 18 2021 at 00:34):

From my reading of @Martin Grundberg comments, he is asking why all the other events resources don't use the subject/focus pattern to which I will not comment. As far as for Observation, I agree with assessment, although I don't have a lot of 1st or 2nd hand experience with use that element in use cases. ( it is, after all still DSTU) I do agree that their is a choice of using code "mom's height" vs using focus = "mom" and code = height. And a tracker to clarify this should be made.

view this post on Zulip Lloyd McKenzie (May 18 2021 at 00:57):

I think because capturing drug administrations or procedures for a mother/father/etc. is exceptionally rare.

view this post on Zulip Marc de Graauw (May 18 2021 at 12:09):

For those interested, there's a subgroup in Patient Care where modelling of child/birthCare in various jurisdictions (Aus, UK, NL, others joining) is discussed: https://confluence.hl7.org/pages/viewpage.action?pageId=86973863 Feel free to join.


Last updated: Apr 12 2022 at 19:14 UTC