My team operates within the Veterinary space and is experimenting with FHIR to model and standardize our services. In our space, animals are consider “Patients”, and their owners “Persons”.
The question I pose is related to mapping the two resources. Patients do not provide References to any meaningful object. Both Patient.link and Person.link want references to the same object.
What does the community suggest in regards to this? Should FHIR support this mapping, or should we provide an extension to our purpose?
The animal would map to Patient and the owner would map to RelatedPerson (which is currently a patient-specific resource). If you want to establish that multiple RelatedPerson records all correspond to the same human being, you’d use the Person relationship. The purpose of Person is to link other resources, it’s never an actor or a target itself.
Agreed. In our space, animal owners/caretakers are our Persons, and the animals are Patients. What we find difficult in the FHIR spec is mapping this relationship both ways (A Person may have multiple Patient references [pets], and a Patient may have multiple Person references [owners]).
I do not find a viable inverse, which is to provide a reference from a Patient to a Person (ie, viewing a Patient record should provide reference to its Person(s)). As you note:
We’ve made accommodations thus far (population of Patient.contact), but we’re continuing to struggle between opting for extension and finding a more appropriate, FHIR-compatible use.
If the Patient resource provided a 0…* list of references to Person resources (or a RelatedPerson had the ability to reference a Person), this question would be moot. It does not, so I’m seeking opinions on best practice/recommendation.
In FHIR, we try very hard to not assert inverse relationships. Instead, we support traversing uni-directional relationships both ways. So, in your case, you probably wouldn’t want to link Patient to Person. You’re not trying to assert that multiple animals are the same Animal (which is what Person would allow you to do.) Instead, you’d have a Person who represented an owner and multiple RelatedPersons who represented the linkage of that owner to a specific animal (Patient). If you have the animal and want the owner, you’d search for RelatedPersons with that animal as the Patient and do a _revinclude to grab the Person associated with that animal/owner relationship.
Though convoluted, I understand what you’re suggesting here and how it will work during READ ops. Where I don’t see this working is with single CREATE/UPDATE operation requests. That is, unless you are suggesting that the relationship assertion may only exist by submitting the Person to create the Patient.
Creating the animal and the owner would be two separate creates (Patient + RelatedPerson). If you want to establish a linkage from one “animal owner” record to others, then you’d need an additional create/update on Person.
Note that it’s possible we could re-structure things to make RelatedPerson support linkage to multiple Patients, though we’d have to think long and hard about the ramifications of that. Part of the challenge is that the “authority” to act comes from the RelatedPerson’s relationship with the patient. If they have multiple linkages, it might be difficult to figure out in what authority they were acting. Person’s sole purpose in FHIR is permitting the linkage of resources. Person is never tied to any resource as the actor or the subject of an action - if a human does something it’s always as Patient, Practitioner or RelatedPerson and I don’t think we’d want to change that part of FHIR design.
What you’re highlighting is the complications with FHIR in the vet space. Humans are rarely the actors in our domain outside of general record keeping. However, they are at the core at a many of our relational maps.
Our challenge is how to represent the non-acting human as a resource owning multiple Patients, and expressing that relationship in reverse when necessary (some systems even have multiple humans with shared ownership percentages).
Understandably, our data models are sufficiently different from the human space. We can certainly leverage extensions to FHIR resources to accomplish our goals.
From our perspective, having something akin to RelatedPatient and RelatedPerson as viable objects containable within a list . This would allow us to have Person.relatedPatient[] & Patient.relatedPerson[] and operate in all HTTP spaces with clarity. This does seem to breech your intent for uni-direction.
At this point, I’m not sure if there’s no better way for us than to extend Patient to contain a list of Person references.
“Actor” simply means someone you want to identify as the author, recipient, informer or some similar relationship. Capturing ownership percentage could be handled by an extension on RelatedPerson. “Person” isn’t really what you want, though it might be the term you use. Person exists only as a linking resource. (In fact, think of it as if it had been named PersonLink.) It can’t be referenced anywhere - you can’t say that a Person signed a consent or authorized a procedure or has been informed about a lab result. You can only do those things with a RelatedPerson - the action has to be done in the context of their relationship to some patient. One possibility would be to say that RelatedPerson could be tied to a Group. That way you could say that the RelatedPerson is tied to a particular herd or other collection of animals. The animals would be members of the group. We could also have an extension that allows Patient to point to RelatedPerson (which points to Group), but that would get somewhat circular.
The uni-directional referencing piece is just a feature of FHIR and it comes from the RESTful foundation - bi-directional references cause pain in REST.