Stream: implementers
Topic: client responsibilities on reading merged patients
Simone Heckmann (Aug 09 2016 at 07:50):
I'm not sure if this has been discussed before... (.. if so, please point me to it..)
After reading up on the proposed procedure for merging a patient (by setting a "replace" link from the inactive to the active patient), I realized that this means that all responsibilities for displaying the correct patient information to the user, lies on the client implementation.
Meaning whenever a client reads a Patient resource, it SHOULD check if there is a replace link (at least if the read patient is inactive) and either display the active patient instead or at least show a warning to the user, indicating that this patient has been merged.
Is that correct? If so, I'm afraid the specification as is does not sufficently inform client implementers of this responsibility...
Grahame Grieve (Aug 09 2016 at 08:02):
what do you think would be sufficiently informing?
Grahame Grieve (Aug 09 2016 at 08:02):
I have just added a note about this to the implementer's safety checklist
Simone Heckmann (Aug 09 2016 at 08:05):
...maybe a sentence containing the verb "should" in this chapter: https://www.hl7.org/fhir/patient.html#links
But safety notes are presumeably a better place to give client implementer a heads up about this.
Grahame Grieve (Aug 09 2016 at 08:06):
well I think the section is clear, but it may not be pointed enough...
Grahame Grieve (Aug 09 2016 at 08:08):
you could create a task to this effect. The note in the safety check list mightn't go for enough either
Grahame Grieve (Aug 09 2016 at 08:09):
"My system ensures checks for patient links (and/or merges) and handles data that is linked to patients accordingly"
Simone Heckmann (Aug 09 2016 at 08:10):
Maybe the place where it's most likely to get the reader's attention would be here:
pasted image
By adding a Cave to the active flag that says: "whenever you read an inactive patient: pay attention to the patient.link - it may have been replaced!"
?
Grahame Grieve (Aug 09 2016 at 08:20):
I think that would be a good task to create
Grahame Grieve (Aug 09 2016 at 08:21):
though I think that this is something that comes naturally to an experienced healthcare app developer, and there's almost nothing we could say that would make any difference to a novice
Grahame Grieve (Aug 09 2016 at 08:21):
my experience is that eyes glaze over when you try to explain this
Simone Heckmann (Aug 09 2016 at 08:48):
Simone Heckmann (Aug 10 2016 at 19:14):
Concering this issue with GET/SEARCH on merged records: http://wiki.hl7.org/index.php?title=FHIR_Specification_Feedback_(DSTU_2)
I was thinking about how to implement the V2 merge event as a FHIR transaction and came up with this:
Whenever I receive a V2 merge message, I update the merged Patient A by setting it inactive and adding the replace link to the master Patient B.
But I'd also add the master Patient's identifier to the merged Patient's identifier list.
This way a client may miss the information still linked to A when performing a search as /Observation?patient=B
But when searching by identifier (e.g. Observation?patient.identifier=12345) it will always be able to retrieve a complete list.
The downside would be that a search for /Patient?identifier=12345 would return two Resources, even though identifiers would be expected to be unique, however only one of there resources would be set to "active".
Does that make sense?
Simone Heckmann (Aug 10 2016 at 19:17):
@René Spronk : You wrote the above mentioned comment on the issue with search/get... what do you think?
Brian Postlethwaite (Aug 10 2016 at 20:06):
i would have thought in that uery you would have also selected to only retrieve the active patients, which would filter that one out
Grahame Grieve (Aug 10 2016 at 20:19):
Agree with Brian, but the overall pattern makes sense
Simone Heckmann (Aug 11 2016 at 07:02):
@Brian Postlethwaite my thoughts exacly (otherwise my beloved conditional PUT/POST/references would blow up in my face)
Simone Heckmann (Aug 11 2016 at 13:21):
aaaand... they do blow up after all!
At least for the ORU-Message scenario, when I try to link an Observation to a Patient by adding a conditional POST on the Patient to the transaction.
If the if-none-exist-condition is Patient?identifier=1234, the transaction fails on the active Patient, because the criteria returns 2 results.
If I set the condition to Patient?identifier=1234&active=true, it'll work for the active Patient.
However, if the ORU message delivers an Observation for the inactive merged Patient (that happens, unfortunately),
the condition Patient?identifier=1234&active=true will return no results and the conditional POST would subsequently create a new Patient with the identifier 1234. So all subsequent ADT updates on this Patient would fail because now there are two active Patients with the same identifier.
This scenario only works, if the Observations are linked using conditional References with Observation.subject=Patient?identifier=1234&active=true, because these don't create new resources in case of a no-match.
In this case the Transaction would succeed linking the Observation to an active Patient and fail if the targeted Patient was inactive/merged. (Which I guess is ok in most use cases. Most EHR systems I know reject messages for merged patients...
Peter Bernhardt (Aug 11 2016 at 15:39):
@Simone Heckmann this is why it is important to resolve links within the patient itself.
Peter Bernhardt (Aug 11 2016 at 15:40):
consider a mature system where you have a lot of clinical data referencing a particular patient record that is then merged into another patient record. if a system cannot resolve the link from the original patient to the survivor, your only other option is to update all references. and that won't scale.
Simone Heckmann (Aug 11 2016 at 15:45):
True. But what if the client queries for all Observations for Patient/123 (assuming there's another Patient/456 that has been merged and linked to Patient/123) How does the Client know that Patient/456's clinical data has to be retrieved as well? There is no link from Patient/123 pointing at Patient/456! Only vice versa.
Simone Heckmann (Aug 11 2016 at 15:48):
If the Client "enters" through the wrong Patient/456, it will find the Patient inactive and a reference to the current Patient resource.
But Clients entering through the correct Patient imho have no reason to suspect that ther's another Patient Resource holding significant information for this Patient.
Peter Bernhardt (Aug 11 2016 at 15:51):
Right .... as a part of a merge transaction, you could add a "seealso" link from Patient/123 to Patient/456. That's why I feel creating and resolving links are the responsibility of a server.
Peter Bernhardt (Aug 11 2016 at 15:52):
In that same merge transaction, the server woud also create a "replace" link from Patient/456 back to Patient/123.
Peter Bernhardt (Aug 11 2016 at 15:53):
And it thus becomes the responsibility of the server responding to queries to interrogate those links when gathering referenced clinical resources.
Simone Heckmann (Aug 11 2016 at 15:53):
Yes, but it is nowhere specified that a merge should also create a "see also" link from Patient/123 to Patient/456, or does it?
Peter Bernhardt (Aug 11 2016 at 15:54):
Maybe it should. ;)
Peter Bernhardt (Aug 11 2016 at 15:54):
Brian will weigh in, I hope, when Oz wakes up.
Simone Heckmann (Aug 11 2016 at 15:55):
The link type description for "see also" states that
This link does not indicate any relative importance of the resources concerned,
and both should be regarded as equally valid.
which does not apply to a merge
Peter Bernhardt (Aug 11 2016 at 15:56):
k ... how about "refer", that might be better.
Simone Heckmann (Aug 11 2016 at 15:57):
Nope. Wrong direction.
Peter Bernhardt (Aug 11 2016 at 15:57):
also, the spec does say that how merges or linking is handled is still not set and implementer feedback is welcome.
Simone Heckmann (Aug 11 2016 at 15:57):
...and that's what we're doing right here :D
Peter Bernhardt (Aug 11 2016 at 15:57):
you're confusing me with facts. ok ...
Peter Bernhardt (Aug 11 2016 at 15:58):
maybe we need a new item here that satisfies this use case.
Peter Bernhardt (Aug 11 2016 at 15:58):
a link type that sez "replaced"
Peter Bernhardt (Aug 11 2016 at 15:58):
or "replacedBy"
Simone Heckmann (Aug 11 2016 at 16:01):
..or maybe just slightly adapt the "see also" description..
Peter Bernhardt (Aug 11 2016 at 16:02):
that's better ... "seealso" should work here.
Peter Bernhardt (Aug 11 2016 at 16:03):
It could work for the surviving record. As you say, maybe just updating the description a bit to indicate this is how it might be used in a classic merge scenario.
Simone Heckmann (Aug 11 2016 at 16:08):
But then it should be emphasized even more that clients ALWAYS need to look at the links, not only if the Patient is inactive!
And I still wonder whether to (additionally) stick to my idea of adding the current business identifier to the merged patient's identifier list, otherwise there is no way a client can get the Patient's complete record in one query.
Peter Bernhardt (Aug 11 2016 at 17:57):
If you were implementing this with strict adherence to REST, I could see a server responding with a redirect for a patient that has been merged - a 301 response with a link to the surviving patient resource in the Location header. not sure this point has gotten much discussion.
Simone Heckmann (Aug 11 2016 at 18:02):
Nice. But still only half of the solution.
Peter Bernhardt (Aug 11 2016 at 18:21):
(deleted)
Peter Bernhardt (Aug 11 2016 at 18:25):
(deleted)
Peter Bernhardt (Aug 11 2016 at 20:32):
Ok, after client dereferences that 301 location and submits a new request the server would find relationship back to inactive merged patient record and gather all the data referenced from both patient records. Maybe an outcome message would help as explanation that response includes “linked” data?
Brian Postlethwaite (Aug 11 2016 at 22:08):
Yes, this is the part that we are looking for implementer feedback on.
I agree that this is highly likely that we would want to make this a server responsibility.
Using the redirect approach, the implication on the observations that reference the old patient need to be considered.
(Should they be re-written as art of the return?)
However there is another situation where the link references a record in a distributed system, but that's a story for another time.
Grahame Grieve (Aug 11 2016 at 23:26):
I would like more proscription on this matter in the spec, but getting agreement around this area is *very hard work*
Grahame Grieve (Aug 12 2016 at 21:20):
I do think that there's grounds for a $merge and/or $link operation to ask a server to do all the merging server side. This is particularly appropriate given that a client may not have access to all the data linked to a patient even though they have the right to merge the patient. I think we should make a task asking PA to define one. But it's certainly a challenge to figure out how it would work
Peter Bernhardt (Aug 12 2016 at 22:47):
@Brian Postlethwaite I would leave the patient references as they were in the response. And if a client requested that "old" patient record, well, the same server logic would result in the surviving patient record being returned via a 301 redirect.
Brian Postlethwaite (Aug 13 2016 at 00:26):
Would be interesting to implement the $unmerge as a rollback looking through the history via an auditevent that touched all the things.
Not something that could have been done without these other bits. Just a thought.
Peter Bernhardt (Aug 18 2016 at 15:57):
@Brian Postlethwaite $unmerge makes sense, but I would argue that it would only remove the links between the originally "merged” Patient records. Leaving the original references to clinical data as they are during merge makes this simple to revert the "merge". I know from hard experience that merging related data is prohibitively difficult to untangle.
Grahame Grieve (Aug 18 2016 at 18:56):
yep. it's not too hard to unmerge after a merge until any new changes are made after the merge. After that, it's just a mess, and humans can't usually figure it out. My recommendation when people ask is not to try for unmerge. When you get to that point, you should just build new records afresh. Not that easy either. all options are bad
Last updated: Apr 12 2022 at 19:14 UTC
