Stream: patient administration WG
Topic: Mother's maiden name as RelatedPerson
Craig Newman (Feb 03 2022 at 16:35):
What does this group think about the idea of storing the mother's maiden name as a RelatedPerson resources (fixing the relationship to mother, and the name type to maiden) rather than using the existing string-based extension? If it's important to capture more than just the mother's maiden last name, having the ability to use the HumanName data type would be helpful. This is coming up in a v2-to-FHIR discussion where PID-6 can contain more than just the last name (https://v2plus.hl7.org/2021Jan/data-type/XPN.html) and we don't want to lose information by either just transforming the last name to the extension or stringing together other name components into a string value in the extension.
René Spronk (Feb 03 2022 at 16:41):
That's not within the scope/usage of RelatedPerson ..
Brian Postlethwaite (Feb 06 2022 at 23:02):
@Cooper Thompson - this doesn't feel right to me, anyone else?
Richard Townley-O'Neill (Feb 06 2022 at 23:34):
To me it looks like if the mother's maiden name is part of identifying the person, it belongs in Patient as an extension. RelatedPerson is for for people relevant to care.
Cooper Thompson (Feb 07 2022 at 15:19):
In many cases, I think mother's maiden name is really more of a knowledge-based authentication question/answer than a real demographic property of the mother. If you are needing to track KBA properties (like mother maiden name, first car, favorite sports team, etc.) it seems like putting those in either a common extension or maybe Observation makes the most sense. Scattering the KBA properties across RelatedPerson and other resources seems undesirable, as an app trying to do KBA would need to 1) know where all the KBA answers are and 2) requests scopes for all those resources.
Hans Buitendijk (Feb 07 2022 at 18:37):
While that perspective is clear from the RelatedPerson's first sentence "Information about a person that is involved in the care for a patient, .......", when looking at the Scope and Usage it would seem that the mother's maiden name would fit "RelatedPersons typically have a personal or non-healthcare-specific professional relationship to the patient. A RelatedPerson resource is primarily used for attribution of information, since RelatedPersons are often a source of information about the patient. " the person need not be active in providing care and it is about attribution. If the intent is for mother's maiden name to only be the patient's attribute for whom you need to collect that AND that RelatedPerson is really for those involved in the care, the Scope and Usage statements would have to be refined as that goes beyond those providing care.
Somewhat related, but more context, for a mother-baby use case there would be two Patient resource instances and one RelatedPerson resource to link the two? Other?
Brian Postlethwaite (Feb 08 2022 at 01:54):
That mother baby example isn't the mothers maiden name value unless I've misunderstood the data.
Hans Buitendijk (Feb 08 2022 at 14:05):
Correct, just separate, but related so we can get the full picture of baby, baby's mother's maiden name, relationship to mother and then mother's mother's maiden name.
Frank Oemig (Feb 10 2022 at 11:57):
The mother is a different person, and mother is the role the person plays. Storing data of a different person in the patient instance seems to be weird. So, using extensions for KBA seems to be a convenient workaround only, esp. because this is a typical US feature.
John Moehrke (Feb 10 2022 at 14:04):
KBA is also not unique to healthcare processing, would tend to be managed in general identity methods. As we recommend for User management.
Last updated: Apr 12 2022 at 19:14 UTC
