Stream: implementers
Topic: Distinguishing Patient Record "types" within Patient.link
Brian Forbis (Jul 28 2020 at 17:27):
I'm currently working on finding a way to map multiple patient records for the same person together. In our system, a clinic/hospital is divided into different orgs that deal with either billing vs clinical data. If we were to have one patient record just for clinical data and another just for billing data, what would be the best way to denote that within the patient resource itself? Looking at Patient.link, not much information is really present in a link of type "seealso". I feel like there is a missing "intent" field that could be useful for patient links to help describe the purpose of that record.
So rather than expecting a developer to retrieve a patient resource, then follow all of the links, then get clinical data for each linked patient, some of which are guaranteed to not have clinical data, would it make sense to have a patient link extension code on the link element to describe whether it's a billing patient or a clinical patient record?
Michele Mottini (Jul 28 2020 at 18:00):
We have a similar situation in our system and we used Patient.link, but now we are actually merging the records: a FHIR Patient should correspond one to one to a person for things to work as expected from a client perspective
Brian Forbis (Jul 28 2020 at 18:29):
Unfortunately, merging patient records is easier said than done. I agree that in the ideal case, a FHIR patient corresponds 1-1 to a person. It certainly would make me life easier, but it also seems that tends to not usually be the case based on how organizations are setup and restrict data sharing between orgs/departments based on the purpose of those orgs.
Though this billing/clinical split opens up some awkwardness when dealing with referenced resources. For instance, a Claim may reference Patient/1 (billing) and Encounter/1 for that claim. But since that Encounter is considered clinical info, that actually links to a different patient Patient/2.
This is touched upon in the patient documentation http://hl7.org/fhir/R4/patient.html#distributed. But I didn't really see any guidance on how client apps are expected to use patient links. Is the use case of crawling patient links common, or is it more common to always do your clinical searches on something like an MRN patient identifier and skipping the links all together?
Brian Forbis (Jul 28 2020 at 19:02):
Also, does distributed patient record separation make standalone patient launches not work? I'm not actually clear if the domain restriction for a standalone patient launched app is supposed to be restricted to a specific patient record (eg: Patient/1) or if it would allow access to linked patient records as well (eg: "seealso" => Patient/2). Is there a SMART solution for the distributed patient record?
Michele Mottini (Jul 28 2020 at 20:28):
does distributed patient record separation make standalone patient launches not work
Mostly. Only a single patient ID is supported, and clients would expect that /Observation?patient=[id] returns all Observation for that patient (etc), they would not navigate through the links. Before we did the actual merge we worked around that problem returning the data for all the patients in response to a query like that - but that has a host of other problems obviously
merging patient records is easier said than done
I do know.
Last updated: Apr 12 2022 at 19:14 UTC
