Stream: Patient Care WG
Topic: FamilyMemberHistory
John Moehrke (Jan 25 2022 at 16:46):
I am doing some work that is using a CDC prototype as input https://phgkb.cdc.gov/FHH/html/index.html
In this prototype, they prompt for some things that don't seem to be present in the FamilyMemberHistory
- if the family member is a multi-birth (they ask about twin, but we want to be more expansive)
- if the family member was adopted
- What ethnicity the family member is
- What race the family member is
I think that analysis of this CDC prototype have questioned these four things. I am looking for further evidence for or against them. If they are needed, then they likely would fall into a category where an extension(s) would be appropriate rather than core elements, right?
Michelle (Moseman) Miller (Jan 26 2022 at 18:36):
This may warrant a PC discussion, but in the meantime have you considered the following?
- http://build.fhir.org/extension-family-member-history-genetics-observation.html -- for race and ethnicity
- http://build.fhir.org/extension-family-member-history-genetics-sibling.html -- for twins (inner-pedigree-tree relationships)
John Moehrke (Jan 27 2022 at 15:50):
maybe I didn't understand those extensions. They seemed to be intended for where there is genetics evidence.
John Moehrke (Jan 27 2022 at 15:50):
and it was also not clear how to use them
John Moehrke (Jan 27 2022 at 15:50):
but, if that is the intent; and someone can educate me.. I might find them exactly what I need.
Lloyd McKenzie (Jan 27 2022 at 16:32):
I don't think they need to be specific to genetic analysis. Though it may be the extensions should be re-named
John Moehrke (Jan 27 2022 at 16:38):
is there an example where these extensions were used?
Lloyd McKenzie (Jan 27 2022 at 17:52):
There's a "genetic" example in the core spec
John Moehrke (Jan 27 2022 at 18:01):
oh, again genetic threw me
Lloyd McKenzie (Jan 27 2022 at 18:12):
Genetic here just means "we know more about the relationships between your relatives with each other" rather than just "relatives with you".
Russell Leftwich (Jan 28 2022 at 12:11):
@Jose Costa Teixeira @Rob Hausam @Jay Lyle @Michelle (Moseman) Miller The concept of the allergy list evolved 60 years ago when we did not understand the mechanism of an classical allergy reaction like anaphylaxis from penicillin and many of the drugs that now cause reactions that are mistaken for the same type of reaction did not exist. We have tried to differentiate that type of allergy (immediate hypersensitivity) form other reactions that individuals have by distinguishing two types of reaction and appropriating the term intolerance for those that someone believes are not an allergy. But every individual, patient or clinician, has their own definition of allergy which they work from. Jose's proposal to call the other reactions "non-allergic hypersensitivity" is at least mutually exclusive, which intolerance is not, since an allergic reaction however you define it is a form of intolerance. Non-allergic hypersensitivity is a term found in allergy texts and journals. But when allergy specialists (I am board certified in allergy and immunology) say "type of reaction" they are referring to the reaction at a cellular level, the mechanism of the reaction. They are consultants making a diagnosis, not creating an entry for an allergy list in a patient's record. When clinicians who are not specialists refer to the type of reaction, they are talking about the observation of the patient who is having a reaction. The morphology of the reaction. And they may refer to the reaction by a single prominent feature like rash, or wheezing, or giant swelling which does not distinguish between allergy and non-allergic. But it is all grouped under the category of allergy in the patient record and all that may be recorded is "rash". Elaine Ayres reported a few years ago that in the EHR of the NIH Clinical Center 29% of the allergy list entries said only "rash". Nothing else. I think an extension that captures known details about the reaction type (by anyones definition) would be a significant step in the right direction. The allergy list (Allergy/Intolerance Resource) is one of the greatest patient safety issues in clinical documentation that exists. Several recent studies by allergy researchers have shown that when patients with penicillin on their allergy list (the most common single entry) are tested and challenged with penicillin, they have NO reaction whatsoever. Yet CPOE systems are prohibiting them from being prescribed penicillin and other antibiotics that it is presumed to cross react with. And I will state the obvious: you can't cross react with something you don't react to. Fixing this problem starts with fixing the way we record the information.
John Moehrke (Jan 28 2022 at 13:28):
@Russell Leftwich I think you intended to post this to new stream about AllergyIntolerance. This stream is about FamilyMemberHistory for which it is highly unlikely that a patient knows this level of scientific detail about their parents, siblings, and others. The FamilyMemberHistory really should be very basic. The FamilyMemberHistory would not be used in the way you describe. I think you are describing legitimate concerns for AllergyIntolerance , as we discussed yesterday on the PC call. right?
John Moehrke (Feb 09 2022 at 15:21):
Michelle (Moseman) Miller said:
This may warrant a PC discussion, but in the meantime have you considered the following?
- http://build.fhir.org/extension-family-member-history-genetics-observation.html -- for race and ethnicity
- http://build.fhir.org/extension-family-member-history-genetics-sibling.html -- for twins (inner-pedigree-tree relationships)
working with these... they are hard to work with as they require that the family member is known as a Patient in the system. The family member may not even be in the same country. That family member has not agreed to have a medical record. Or that family member linkage to the Patient may not be allowed, may be dangerous for a member. This is further difficult when the family member is deceased for which their records may have been archived/purged. I understand that I can make all this detail contained in the FamilyMemberHistory, but that seems very expensive way to record simple family member details.
Lloyd McKenzie (Feb 09 2022 at 17:36):
The first doesn't require a Patient. You can have an Observation with no subject or a 'contained' subject. In fact the Observation itself might be contained in the FamilyMemberHistory
For the second, the patient on both FamilyMemberHistory instances would be the same. It's just linking two FamilyMemberHistory instances.
John Moehrke (Feb 09 2022 at 18:55):
understood... just way too cumbersome for the value given.
Lloyd McKenzie (Feb 09 2022 at 19:31):
How else would you do it? Observation is for a wide variety of things. Yes, could break out 'race' and 'ethnicity' as special-case extensions, but not obvious as to why. And sibling is about as simple as it can get...
John Moehrke (Feb 09 2022 at 19:36):
I think sibling is more complex than it needs to be. The FamilyMemberHistory already supports explaining siblings. What was needed was to point out THE siblings that were part of a multiple birth. The sibling extension has a codeableConcept that has no valueSet. I agree that it is not problematic to point at THE sibling FamilyMemberHistory.. except that one must have created all the sibling instances first, then link them with the extension. The references are bidirectional as well. This presents a workflow complexity
John Moehrke (Feb 09 2022 at 19:36):
on race and ethnicity. I have asked us-core to just allow their extension be used in FamilyHealthHistory.. that seems reasonable request.
John Moehrke (Feb 09 2022 at 19:38):
I don't mind extensions here. Just seem so combersome for the given value
Lloyd McKenzie (Feb 09 2022 at 20:00):
FamilyMemberHistory allows you to say "this person was a brother". It doesn't allow you to say "this particular brother and sister were twins". To do that, you need to be able to tie the two FamilyMemberHistory records together.
Lloyd McKenzie (Feb 09 2022 at 20:01):
Note that the us-core extensions might well be moving toward using Observations instead...
Last updated: Apr 12 2022 at 19:14 UTC
