Stream: implementers
Topic: Parent/child patient links
James Agnew (Nov 08 2018 at 15:34):
I feel like this is the most basic of things and I'm surprised I can't find anything...Is there any generally accepted way of linking two Patient resources as relating to a parent and a child? RelatedPerson seems like it ought to be it, except that you can actually point to two resources with it.
Joel Schneider (Nov 08 2018 at 16:39):
The FamilyMemberHistory resource has a FamilyMemberHistory-Genetic profile and family-member-history-genetics-parent extension which may fit your purpose.
http://build.fhir.org/familymemberhistory-profiles.html
Yunwei Wang (Nov 08 2018 at 16:46):
What I can think about is create two RelatedPerson. One for self and one for child. Then add both RelatedPerson into a Group
Lloyd McKenzie (Nov 08 2018 at 16:55):
Adding them into a Group is a bit odd - because you're going to do the same things to both?
Lloyd McKenzie (Nov 08 2018 at 16:56):
RelatedPerson has an extension that lets you link who the Patient is for that RelatedPerson
Kevin Power (Nov 08 2018 at 17:08):
Is there any guidance on either resource as to when to use FamilyMemberHistory versus RelatedPerson? I did a quick look but didn't see anything.
Lloyd McKenzie (Nov 08 2018 at 17:24):
RelatedPerson defines an "actor" - someone who can do something, receive information, inform decisions, etc. FamilyMemberHistory is to support tracking family history as relevant to a patient's health risks
Kevin Power (Nov 08 2018 at 17:32):
In reading the details of each, that all makes sense. I still wonder if it isn't worth making some sort of reference to that sort of distinction on each of the resources. Perhaps not necessary as it might fall under the "well duh" category?
Lloyd McKenzie (Nov 08 2018 at 17:46):
Not bad to differentiate. Feel free to submit a change request :)
Lloyd McKenzie (Nov 08 2018 at 17:47):
One other difference is that RelatedPerson can be friend, neighbor, co-worker, etc. - someone who acts based on their personal, but not necessarily familial, relationship with the patient.
Yunwei Wang (Nov 08 2018 at 17:47):
@Lloyd McKenzie Do you mean this extension http://build.fhir.org/extension-patient-relatedperson.html? I don't think it can be used to create patient-child relationship.
Lloyd McKenzie (Nov 08 2018 at 17:48):
I was confusing myself. I was thinking about FamilyMemberHistory.
Lloyd McKenzie (Nov 08 2018 at 17:50):
The guidance at the moment seems to be through linking the encounters: http://build.fhir.org/patient.html#maternity
Lloyd McKenzie (Nov 08 2018 at 17:50):
(On the grounds that the mother's record isn't permanently linked to the baby's record - just during the birth encounter and perhaps some post-partum encounters)
René Spronk (Nov 08 2018 at 17:53):
Some countries have parent(particularly:mother) child relationships in their national citizen/person registries. The purpose of these links is administrative and not clinical, I've seen extensions on Patient to deal with this.
James Agnew (Nov 12 2018 at 15:43):
Yeah, the use case I'm looking at is definitely in that "administrative" bucket. It'd probably make sense to have a standard extension for this, I'll file a change request.
Brett Esler (Nov 14 2018 at 00:15):
hl7 au has a project on child health and have a draft (work in progress) version of a proposal using RelatedPerson http://build.fhir.org/ig/hl7au/au-fhir-childhealth/StructureDefinition-mother-relatedperson.html to link a mother RelatedPerson to a child - then a Mother patient that refers to themselves as a RelatedPerson http://build.fhir.org/ig/hl7au/au-fhir-childhealth/StructureDefinition-mother-patient.html
Brett Esler (Nov 14 2018 at 00:18):
so think you can use the link.type = refer to refer to the equivalent mother RelatedPerson then use RelatedPerson to link the mother (parent) to the child
Thomas Tveit Rosenlund (Jan 30 2019 at 12:16):
I think the RelatedPerson resource is flawed, I don't think it makes sense to model a RelatedPerson as a separate resource when we already have Person, Practitioner and Patient resources.
I think the RelatedPerson should really be modeled like a PractitionerRole resource to express some kind of relationship assosiation of two individuals. The Relation resource can point to the Person/Patient/Practitioner resources involved and express what kind of relationship one wants to express.
An even better model would be to include reference to Relation in Person/Patient/Practitioner so that the Relation resource could only reference the target Individual resource of the relation. That scheme might be difficult to implement as the Patient Resource is already normative. It's may not be considered a breaking change to include an optional reference to a new resource type however.
Lloyd McKenzie (Jan 30 2019 at 15:46):
Person can't be used except to link resources together. All references to other resources must be to a person in the context of the role they're acting under - as an actual/potential recipient of care (Patient), as a person acting in the capacity of their personal relationship with a patient (RelatedPerson) or as someone acting in their professional capacity (Practitioner). As well, RelatedPerson is nominally a part of the patient record of the patient they're associated with - and there are significant privacy impacts to separating them from being part of the record. (Person is an advanced function for those systems that are comfortable with the possibility of cross-record links.
Can you explain what the current modeling approach prevents you from saying or how it diverges from common implementation practice?
Thomas Tveit Rosenlund (Jan 31 2019 at 15:01):
I think it is unwise to model RelatedPerson in a totally different way than the Practitioner/PractitionerRole resouces. Furthermore I don't think Person is an advanced function in a lot of systems.
In Norway we will know the identity of the person, most of the time. Furthermore all our systems can retrieve updated information about that person from our centralized repository of all Norwegian citizens. We have a lot of use-cases where the person's identity is not known naturally, but I am quite shure that is in the 20% realm, aka special cases that need profiling/extensions in FHIR.
When Person is a known entity, and all systems have access to basic information about that Person and can use that information to update their patient record, it seems counterintuitive and counter productive to make up a lot of Individual resource instances to represent different relationships regarding the same Person. It is not that it is not possible to do so, but it's certainly not the best way to solve the problem of representing information about persons and relationships.
Lloyd McKenzie (Jan 31 2019 at 15:13):
The centralized repository of citizens would typically be a Patient registry rather than a Person registry (unless it's used to maintain demongraphics for both Patients and Practitioenrs. RelatedPerson is "owned" by a Patient, but that's the only way it's different. Person represents a significant security consideration as it allows you to know that a patient and a practitioner are the same individual - or that a Patient and a RelatedPerson are the same individual. Systems that choose to support Person need to manage that carefully.
Thomas Tveit Rosenlund (Feb 05 2019 at 07:37):
In Norway this is the case. Our centralized repository of citizens will contain all citizens regardless of role. This is a more general model of person and roles/relations than what is modeled in the current Person/Patient/RelatedPerson resources at the moment.
Lloyd McKenzie (Feb 05 2019 at 15:52):
That centralized repository wouldn't map well to Person unless the centralized registry has links to the various role-specific representations in different systems. In FHIR, Person can't ever be an actor. They can't be an author, performer, subject, informant or anything else. Any action is always tied to a specific role (Patient, PractitionerRole/Practitioner, RelatedPerson). Person is just used for shared demographics and linking across roles for the limited set of systems that actually perform such linking. This behavior is driven by a few things. 1. It's the way most systems in the healthcare space work; 2. It allows appropriate protection of patient privacy and management of permissions/privileges.
Thomas Tveit Rosenlund (Feb 19 2019 at 13:26):
What you describe is how HL7 FHIR works today @Lloyd McKenzie .I Do understand this, but I think the explanation misses the point of why this model is superior to other ways of representing this information. It is not clear how this way of implementing Patient/Person/Relationships actually solves any problems concerning patient privacy and management of persmissions/privileges. A more general model of Persons/Patient/Pracittioners and their relationships would be a better way of managing this problem, in my opinion.
In the cases where a common citizen repository exists, the systems usually have no problem incorporating information about Person in the EHR systems, and because of this I want to suggest that RelatedPerson can reference either a Person resource or a Patient resource, because this is the way things work in a lot of cases.
John Moehrke (Feb 19 2019 at 14:50):
I think both of you have good points. The difference is in the clarity of what the purpose of the "Registry" is. If this registry is just a person registry without regard to healthcare, specifically patient or practitioner; then I would say that using FHIR is inappropriate. Use a more generic IT standard for more generic use-cases; FHIR is designed to support healthcare. Once we focus on the use-cases that are healthcare, then as Lloyd has pointed out, there is a need to understand the role the person has in the healthcare stage. The Person resource may seem generic, but it is specifically designed to aid with a linkage that has very specific Privacy, Business, and Security ramifications. Thus it may seem generic, but it is potentially problematic. The exception would be where Person is used and where Person.link is forbidden. In that case then Person is rather devoid of healthcare specifics. The issue, that Lloyd is trying to express, is that the Person.link is considered fundamental to the reason the Person resource exists.
Brian Postlethwaite (Feb 20 2019 at 02:15):
you can also use the person without using the link property, and instead perform logical linking through the identifiers in the person/patient to match them up. Such as a registry based internal identifier that can also be applied to the patient/practitioner/releatedperson...
http://hl7.org/fhir/person.html#pmi
Thereby quite effectively skipping the privacy issues that the link references expose.
Brian Postlethwaite (Feb 20 2019 at 02:17):
And at the same time permitting systems to have different values for properties, if that's the desired patient/person's preference.
They might have several aliases and prefer to be known as different ones in the different systems/organizations/contexts, which normalizing down to the same record for all data doesn't permit.
Thomas Tveit Rosenlund (Feb 28 2019 at 09:49):
Thank you all for the feedback.
I do agree that HL7 FHIR is not the preferred interface of a Person Master Index to serve all organizations accessing such an index. In Norway we have identified the need to serve information about citizens using a Person Master Index for healthcare, and in that use-case we are going to use HL7 FHIR to define the interfaces to this Registry. In time some healthcare specific information will be added to this registry to solve use-cases that are not of interest to organizations outside healthcare here in Norway. A lot of other information will exist on the platform, including information concerning healthcare organizations, healthcare services, and a central index of approved Practitioner, the plan is to make all this information awailable through a FHIR interface. Most of the person data will however be information from the central registry of norwegian citizens, served through a FHIR interface, we will need profiles and extensions to incorporate some of the data that exist in the common Person Master Index.
I think the note describing the Person resource used in a PMI describes our thinking quite clearly: "Note: This style of system may use the Person resource without any FHIR references to Patient or Practitioner resources. In these environments the Master Index is likely to have a master identifier that performs this logical linking."
I still think the RelatedPerson resouce really needs a Person reference in addition to the Patient reference, and I don't think it should be an extension.
Jens Villadsen (Feb 28 2019 at 09:50):
@Thor Schliemann this might have your interest
Lloyd McKenzie (Feb 28 2019 at 15:40):
The RelatedPerson is "owned" by one and only one Patient. Person is defined as a linking resource and is intended to point to the things it links. As a result, there are no links on the resources it points to. We try hard to avoid bidirectional linking in FHIR because it causes issues with RESTful updates. As well, only a small percentage of systems make use of Person, so if we were to add a reverse link, it would need to be an extension.
Thomas Tveit Rosenlund (Mar 01 2019 at 11:24):
@Lloyd McKenzie We do not propose to add any reference to the Person resource.
I think any bidirectional linking is also present in the relationship Patient/RelatedPerson so there should be no difference here. We do not propose to add any new use-cases to the Person resource. The use-case we want supported is already documented in the Person resource description, aka Master Person Index. One key use-case of any master person index is to express what relationships a person has to other Persons in the index. The current FHIR model makes this harder to implement. I would suggest that no extensions should be necessarry to implement the most basic use cases of a Person master index using the Person/RelatedPerson resources.
Lloyd McKenzie (Mar 01 2019 at 15:40):
If you want to convey relationships between persons, that would have to be done with an extension to Person. You can't use RelatedPerson because any association to RelatedPerson must mean "An individual who is acting on behalf of a (single) patient by nature of their personal relationship with that patient".
Lloyd McKenzie (Mar 01 2019 at 18:02):
There is no bidirectional linking with Patient/RelatedPerson. RelatedPerson points to the Patient the RelatedPerson is "owned" by and on whose behalf the RelatedPerson is always acting. Patient never points to RelatedPerson
Last updated: Apr 12 2022 at 19:14 UTC
