Stream: implementers
Topic: Vet / related person / person
Grahame Grieve (Apr 26 2016 at 05:27):
http://stackoverflow.com/questions/36854693/hl7-fhir-implementation-of-animal-owners
Grahame Grieve (Apr 26 2016 at 05:28):
it seems to me that person is for reconcilation records of a single individual.
Grahame Grieve (Apr 26 2016 at 05:28):
there's really nothing for managing the relationships between individuals - and the question at the heart the stack overflow is about tracking relationships
Paul Knapp (Apr 26 2016 at 05:38):
Currently in several resources where there are two 'person' elements which need to be related a code is used to capture the relationship and the codes used have the granularity required at the point of use.
Grahame Grieve (Apr 26 2016 at 10:31):
you mean patient, then? but th patient.contact is strictly observational/relative - there's no way to set up a formal web of relationships between identified parties
Paul Knapp (Apr 26 2016 at 13:21):
Usually they use Patient for the 'person' but they may use a choice of Patient or RelatedPerson. You are correct there is no independent 'relationship' resource - the only way to work our the 'web of relations' would be to analyse the codes and they aren't designed to support that level of discovery. For example, you could discover that a child is the dependant of four people but have no idea which is the Birth Father and Birth Mother.
Paul Knapp (Apr 26 2016 at 13:23):
Is this an observation on your part or a desire/need to actually map the relationships?
Grahame Grieve (Apr 26 2016 at 13:46):
an observation on my part, but the idea that the relationships should be represented formally arises as an FAQ
Michelle (Moseman) Miller (Apr 26 2016 at 14:38):
Doesn't this same scenario happen for humans as well as animals? For example, patients (e.g. two siblings) can have the same relative (e.g. mother) - in which case there would need to be 2 RelatedPersons for the relationship between mom and each child -- meaning that a Person would need to be used to link the 2 RelatedPersons for the single person (mother). It does feel awkward to me that the RelatedPerson resource is named as if it represents a person whereas the elements imply it is actually more like a relationship. Thus, the Person.link.target (of type RelatedPerson) is actually linking relationships.
Grahame Grieve (Apr 26 2016 at 15:16):
Michelle, I made the same mistake in regard to RelatedPerson - that's not what it does
Lloyd McKenzie (Apr 26 2016 at 16:25):
RelatedPerson is part of the Patient's record. My leaning on this question is that Owner, if you want to search on it, is a potential actor (information recipient, informer, performer, etc.) so RelatedPerson is appropriate. You would link all the animal-specific RelatedPerson instances to Person if you wanted to show that they're the same human being. Where this gets more dicey is that some animals aren't owned by people. They're owned by organizations. And we don't support that at all right now.
Grahame Grieve (Apr 26 2016 at 16:28):
a related person is specific toa a patient. If I'm involved in my families care, there'll be a related person for me for each person in my family
Grahame Grieve (Apr 26 2016 at 16:28):
there's no link between the different RelatedPerson records for me
Lloyd McKenzie (Apr 26 2016 at 16:29):
Person allows linking multiple RelatedPerson instances
Grahame Grieve (Apr 26 2016 at 16:30):
it's a little indirect...
Lloyd McKenzie (Apr 26 2016 at 17:43):
It is. But it's also nice and tidy. It keeps records nicely separated except for the resource whose explicit purpose is linking. If we introduce something else, that gives us two different ways of saying the same thing and I'm not sure we could provide sufficient guidance to minimize the likelihood of people having to support both approaches.
Paul Knapp (Apr 28 2016 at 10:33):
Wouldn't this be dramtically simplified by having on the focal resource a subclass of related where the content was:
related 0..* Related parties
related.party 1..1 reference(patient|organization)
related.relationship 1..1 coding (detailed relationship codeset/valueset)
maybe additional elements...
This way:
A) you would have organizations and animals as well as people;
B) the relationship: birthmother; caregiver; owner, guardian, frend, etc. could be explicit; and,
C) none of: the relatedPerson; its duplications; and, the Person to gather the duplicates back up would be required.
Be really nice if we renamed Person to PersonLink and Patient to Person (or Party or Subject). It would be less surprising for people who use FHIR, and as for animals - well if we won't give them their own resource then they are people (Person) too.
Paul Knapp (Apr 28 2016 at 11:08):
OR, have a Relationship resource designed to relate resource X with relatedparties Y, Z etc. - but make it a relationship recording resource not a pseudo person resource.
Lloyd McKenzie (Apr 28 2016 at 12:05):
It would mean that you have to create a Patient relationship for every friend, guardian, etc. - which would create a very high (and misleading) set of Patients. Patient and RelatedPerson have very distinct purposes. A Patient is a Person/Animal who is (or is at least a potential) recipient of care. A RelatedPerson is a Person/Animal who is associated with a Patient who can act (or be acted upon) as a result of the personal relationship with the Patient. The notion of having a single record for a Person that links multiple Patient or RelatedPerson or Practitioner records is more advanced functionality. I think it's fine that things are more complicated when you want to do that.
Paul Knapp (Apr 28 2016 at 12:16):
Lloyd: I don't think you understood what I'd suggested. It would not create more things - it would eliminate the duplication within RelatedPerson and eliminate duplications between Patient and Related Person; and remove the need for Person to mop up the duplicates. It would reduce complexity as you would have few or one place to look for the relationships depending upon whether the relationship was recorded within or outside (as a resource) of the focal resources, and it would mean there was one model not two for people (and animals).
Patient is a role and I think it would be less surprizing to have resources be the things and the elements be in the roles. If everyone doesn't want that then fine, but having one resource which represents people and a different resource which represents the relationships between people is IMHO a better, less redundant and more robust design.
Lloyd McKenzie (Apr 28 2016 at 13:30):
Hi @Paul Knapp - What I understood you to say is that you'd use Patient for related persons instead of a RelatedPerson. And I'm saying that's problematic. We need to reflect how existing systems work, and very few systems would want "patient's mother" to show up as a Patient record - nor would they support knowing that "Patient's mother" is the same person as "Patient's wife". There's a whole lot of sophistication involved in managing that sort of linkage, including handling the privacy aspects. Our existing approach only feels unnatural in the veterinary space, both because the privacy impact doesn't generally manifest with animals and because the notion of "owner" is often quite important
Lloyd McKenzie (Apr 28 2016 at 13:30):
Redundancy is actually common in actual implementations, so we need to support and reflect that.
Eric Haas (Apr 28 2016 at 23:35):
Yes veterinary practice management is centered around the client and the animal patients are linked to the client.
Paul Knapp (Apr 29 2016 at 09:19):
That would suggest that someone with multiple pets would be modelled as one Client and multiple patients, not the multiple patients (Patient) with multiple Clients (RelatedPerson) espoused above.
Lloyd McKenzie (Apr 30 2016 at 00:53):
Yes, we have a challenge in the veterinary space. This is one place where the requirements don't line up terribly well between human and veterinary medicine. The question is whether the human-centric solution is sufficiently painful in the veterinary space that we'd need to introduce a new "owner" resource specifically for them.
Brian Postlethwaite (Apr 30 2016 at 01:11):
This issue also comes up in mental health and disability where there is a lot of software that deals with the carer, especially with funding. In these cases the RelatedPerson is the focus of much of the system, as it is supporting them (to care for the Patient)
Grahame Grieve (Apr 30 2016 at 01:12):
Brian, perhaps PA should discuss this in Montreal?
Brian Postlethwaite (Apr 30 2016 at 01:14):
Could add to the list.
Brian Postlethwaite (Apr 30 2016 at 01:14):
(Is now on my list of topics)
Grahame Grieve (Apr 30 2016 at 02:49):
thx
Eric Haas (May 01 2016 at 21:02):
I would strongly prefer a "Client" resource. I would be happy to discuss if we are talking vet med. In addition all the practice management gurus tell us dentistry is closest to veterinary practice. A a large chunk of their business is typically client pay as well. I have never set eyes upon a dentistry system so I don't know if that applies to this situation.
Lloyd McKenzie (May 02 2016 at 00:38):
Well, for human dentistry, client = patient. (And I really don't like the name "client" because it's a common alias for Patient, so it's going to trigger lots of confusion.)
Paul Knapp (May 03 2016 at 09:35):
Dentistry, unless accident related, usually doesn't get paid much under public or social programs, to in that regard it is mostly Patient paid, and most of that patient payment comes from private insurance.
But that doesn't change that there is an account, for a single person or family unit, where there are patients and coverages with subscribers (the policy owner for the coverage).
The profound similarity between Vet and Dental practise is the completeness of the practise - both professions are like islands of healthcare where the practioner does it all: imaging, diagnostics, surgery, pharmaceuticals etc. You both tend to have significant technology and machinery to deliver the whole service. The skills required are very broad and extend beyond the purely medical into mechanics, prosthetics, forensics, materials science, other levels of problem solving etc.. You provide for yourself many of the support services which are external services and knowledge for others.
Kenneth Chapple (May 03 2016 at 18:11):
We have an issue where we need to represent primary patients and their dependents. I think what I'm going to do is use an extension to Patient to identify the patient's "parent" Patient resource, if any, and any meta data along with that relationship. Make sense?
Lloyd McKenzie (May 04 2016 at 01:15):
Primary as in for insurance coverage? Would think that would be a link from Coverage.
Kenneth Chapple (May 04 2016 at 13:33):
Thanks @Lloyd McKenzie I'll look into Coverage resource.
Eric Haas (May 06 2016 at 05:42):
@Brian Postlethwaite When is this topic being discussed in Montreal?
Paul Knapp (May 07 2016 at 12:16):
@Lloyd McKenzie: I don't know what you mean by 'Primary Patient' in relation to Insurance, but I do know what is meant by 'Primary Insurance' for a Patient. The Coverage has two people of interest: the party who is the beneficiary and the party who owns the Coverage. The relationship is expressed there at the level of granularity which is approprriate for that purpose but probably/possibly not at the level required by Kenneth.
@Kenneth: Are you trying to describe the familial or responsibility or other relations between Patients (Mother, Father, sibling, child, etc.)? If this isn't specifically insurance related otherwise you shouldn't rely on Coverage at all.
Lloyd McKenzie (May 07 2016 at 14:26):
@Paul Knapp It wasn't my term, but I'm interpreting it to mean what used to be "Head of Household" in Alberta - I.e. the primary person associated with coverage that may apply to multiple covered parties. I'll let @Kenneth Chapple clarify whether that's actually his meaning or not
Brian Postlethwaite (May 12 2016 at 23:06):
Sorry this didn't get handled in Montreal. Can someone log the issue in a tracker item?
Last updated: Apr 12 2022 at 19:14 UTC
