Stream: subscriptions
Topic: combine/uncombine
Jenni Syed (Sep 14 2019 at 17:44):
Alright my FHIIR query/FHIRPath gurus... How would you do the prev and next or FHIRPath criteria to detect a patient combine or uncombine?
Jenni Syed (Sep 14 2019 at 17:45):
In R4, the Patient.link set of data would change, but you only care if links of type replaces or replaced-by
Jenni Syed (Sep 14 2019 at 17:45):
link is a query param...
Jenni Syed (Sep 14 2019 at 17:46):
but it's the reference it's defined against
Josh Mandel (Sep 14 2019 at 18:04):
Can you give an example of before-and-after data?
Brian Postlethwaite (Sep 14 2019 at 18:06):
The below is at the bottom of the Patient resource in the after, and not there in the before.
<link>
<other>
<reference value="Paitent/01" />
<display value="Mary Lincoln" />
</other>
<type value="replaces" />
</link>
Grahame Grieve (Sep 14 2019 at 18:06):
so we assume %current and %previous are available? and we're looking for anything different? Not quite sure what the parameters are
Brian Postlethwaite (Sep 14 2019 at 18:07):
There are some example patient resources on this page Josh
https://confluence.hl7.org/display/PA/Connectathon+Sept+2019+at+WGM+%28Atlanta%29+Patient+%24Merge
Jenni Syed (Sep 14 2019 at 18:25):
After a merge, the merged to patient will have a new Patient.link of type "replaces", the merged away patient will have a new Patient.link of type "replaced-by"
Jenni Syed (Sep 14 2019 at 18:26):
After an unmerge, the unmerged from patient will have a Patient.link of type "replaces" removed, the unmerged to patient will have a Patient.link of type "replaced-by" removed.
Jenni Syed (Sep 14 2019 at 18:26):
I think :)
Grahame Grieve (Sep 14 2019 at 18:28):
%this.link.where(type = 'replaced-by').count() != %previous.link.where(type = 'replaced-by').count()
Grahame Grieve (Sep 14 2019 at 18:29):
but... that's loose. what exact events do you want? can you have more than replace-by? no? but you could have more than replaces, yes?
Josh Mandel (Sep 14 2019 at 18:32):
There's also a question of listening for an operation call directly. Today we have defined Topic.resourceTrigger, but when we want to trigger on operation invocations, we may want an operationTrigger (i.e., rather than looking for the result of the operation as it plays out in the affected resources, we may want to learn about the operation invocation itself).
Josh Mandel (Sep 14 2019 at 18:32):
But for operations that do impact resources, like Patient $merge, listening for telltale changes on Patient with a filter like Grahame defined above seems pretty reasonable.
Jenni Syed (Sep 14 2019 at 18:33):
Right, I think you would want to handle both. In our server, very few will likely come through the actual FHIR operation (for quite a while). But that wouldn't be true for native FHIR servers.
Jenni Syed (Sep 14 2019 at 18:35):
Trying to figure out how to make it actually computable
Josh Mandel (Sep 14 2019 at 18:36):
Yeah. I think Grahame's solution is a good start. Are there any cases it misses? Or where it triggers unnecessarily?
Grahame Grieve (Sep 14 2019 at 18:36):
it's tricky. I can write FHIRpath statements but exactly you are looking for depends on what you're doing
Cooper Thompson (Sep 14 2019 at 18:39):
In the patient merge track we are increasingly distinguishing between merge and link. We're leaning toward suggesting (but not requiring) that the $merge operation not actually do anything with Patient.link
Brian Postlethwaite (Sep 14 2019 at 18:39):
@Cooper Thompson this one.
Cooper Thompson (Sep 14 2019 at 18:40):
In a merge, the source record could be deleted, and the new (target) record may either 1) have no changes or 2) have some normal demographic changes (e.g. address) if the source patient demographics were carried over. In both cases the link property on the target patient would not be touched.
Jenni Syed (Sep 14 2019 at 18:42):
Our system would do everything based on link/we update the relationships under the covers for legal reasons.
Jenni Syed (Sep 14 2019 at 18:42):
which should work if a system can trigger off of an operation
Jenni Syed (Sep 14 2019 at 18:42):
so as long as I can still do that...
Jenni Syed (Sep 14 2019 at 18:42):
Also, this gets back to the discussion about logical subscription vs. trying to compute
Jenni Syed (Sep 14 2019 at 18:43):
EG: ADT - it doesn't matter if a system is running the exact query under the covers, as long as it meets the functional need/description of the trigger
Jenni Syed (Sep 14 2019 at 18:44):
Which is why it's ok if systems run it off their older ADT systems for admission, discharge, and transfer subscriptions
Jenni Syed (Sep 14 2019 at 18:44):
But we should make sure it works for both types of use cases
Cooper Thompson (Sep 14 2019 at 18:47):
Even though you link under the covers, would you "pretend" that the source patient was deleted when represented via the FHIR patient.search API? Or would you return the source patient in your search results, just marked as inactive?
Grahame Grieve (Sep 14 2019 at 18:48):
the $merge operation not actually do anything with Patient.link
+1
Jenni Syed (Sep 14 2019 at 18:49):
@Cooper Thompson it's treated as inactive, and isn't returned if you're just searching
Jenni Syed (Sep 14 2019 at 18:49):
You can read it by id, and we redact all the demographic info, and then have patient.link that tells you where to go look
Jenni Syed (Sep 14 2019 at 18:50):
Eg: https://fhir.cerner.com/millennium/dstu2/individuals/patient/#patient-combines-example
Jenni Syed (Sep 14 2019 at 18:51):
In DSTU 2, you couldn't link both directions, so for R4 I would like to take advantage of that so that you can see that data has gone nuts under the covers regardless of which patient your system uses
Jenni Syed (Sep 14 2019 at 19:05):
Also, if data comes in to that old patient, our system records it on the new and records in the system that the old id was used (for unmerge). This is usually something that is limited to the time that it takes to do the actual merge.
Jenni Syed (Sep 14 2019 at 19:06):
And not something we would expect to keep happening after the merge is completed (since no one could load the old patient anymore)
Cooper Thompson (Sep 14 2019 at 19:13):
But back to the subscription use case, if the merge track is leaning toward not requiring a patient link, then monitoring patient.link for subscriptions won't be reliable.
Jenni Syed (Sep 14 2019 at 19:13):
Which goes back to being able to monitor a combination of things. EG: our server may not support the merge operation, but that doesn't mean we won't be merging under the covers...
Pascal Pfiffner (Sep 14 2019 at 19:28):
@Cooper Thompson I haven't followed the merge track, and out of curiosity – what's the reason for leaning to not requiring Patient.link?
Brian Postlethwaite (Sep 14 2019 at 19:43):
This would be for cases where the source patient resource (that was merged into a target patient resource) gets deleted, and no longer accessible from the API, and hence the resource Id that would be in the link is now a dead link.
Cooper Thompson (Sep 14 2019 at 20:00):
1. If the source patient is deleted (not just inactive) as it is in some implementations, then it doesn't exist to be linked to
2. We've been thinking about link representing more of a cross-domain patient association, while a merge represents an intra-domain process that combines data. e.g. with merge, all references in all resources need to be fixed up to point to the resulting patient, but in link, they don't. All that to say that the meaning of link is shifting a bit.
Grahame Grieve (Sep 14 2019 at 20:02):
I believe that we need to support link/unlink in internal records as well as full merge.
Grahame Grieve (Sep 14 2019 at 20:02):
I'm not opposed to supporting cross-domain association as well
Cooper Thompson (Sep 14 2019 at 20:07):
As semantically the same as merge? Or different? I.e. if you link two patients, does that mean to get a full picture of their allergies you need to do two searches? Or would all the allergies be returned by a single AllergyIntolerance?patient=2?
Grahame Grieve (Sep 14 2019 at 20:18):
search on both patients.
Grahame Grieve (Sep 14 2019 at 20:18):
that's not the same as 1 or 2 searches
Cooper Thompson (Sep 14 2019 at 20:22):
It depends on the SMART scopes you have. If you only got access to one patient, you would need to re-auth to get access to all the other linked patients (maybe).
And if there are 3-4 links that get added over time, then the flow always becomes: 1) do a SMART launch, get the patient ID in context. 2) query that patient get all the links 3) hope your SMART scope lets you see all of them and 4) query for all the linked IDs. You'd also need to hope that all of the (say 4) patients are cross linked, so you don't have to follow links to each patient, and then follow those links, etc. to get a full view.
And if we support both link and merge, then every client will need to support that workflow as well as the simple single-patient search workflow depending on the system they talk to.
Grahame Grieve (Sep 14 2019 at 20:26):
yes all those things!
Jenni Syed (Sep 14 2019 at 20:30):
I'm curious why a replaces or replaced by would leave data out on the old patient?
Jenni Syed (Sep 14 2019 at 20:30):
By definition "The patient resource containing this link must no longer be used. The link points forward to another patient resource that must be used in lieu of the patient resource that contains this link."
Jenni Syed (Sep 14 2019 at 20:31):
and "The patient resource containing this link is the current active patient record. The link points back to an inactive patient resource that has been merged into this resource, and should be consulted to retrieve additional referenced information."
Cooper Thompson (Sep 14 2019 at 20:31):
If we move all the data from the old patient, what is the value of having the replaced by link? As opposed to a redirec or something like that?
Jenni Syed (Sep 14 2019 at 20:32):
I would think that for the workflows you all are referring to, it would be invalid to use those link types?
Jenni Syed (Sep 14 2019 at 20:32):
See also and refer would be more appropriate?
Jenni Syed (Sep 14 2019 at 20:32):
It depends on how the system is integrating
Jenni Syed (Sep 14 2019 at 20:32):
If it has its own set of data, it may have its own logic to merge
Jenni Syed (Sep 14 2019 at 20:32):
and need the new one
Jenni Syed (Sep 14 2019 at 20:34):
zulip seems to be reorganizing the order of this conversation for me... weirdness
Jenni Syed (Sep 14 2019 at 20:34):
We're too quick for it
Pascal Pfiffner (Sep 14 2019 at 20:35):
The value in having at least the old Patient resource available is that clients that have refresh tokens can still retrieve that resource and infer from its links that something has happened to which the client needs to take action. Even if this just means throw away the tokens and have the user sign in again (and invalidate all the locally stored resources).
Cooper Thompson (Sep 14 2019 at 20:36):
Yeah - we were considering what to do about token expiration. Specifically for patient-authorized representatives. We were leaning toward adding guidance to expire all tokens, since you might want to review who should have access to the new merged chart. Input on that point would be nice.
Cooper Thompson (Sep 14 2019 at 20:37):
For patient-self access, maybe we don't expire those?
Michael Donnelly (Sep 14 2019 at 20:37):
My gut says yeah, don't expire.
Michael Donnelly (Sep 14 2019 at 20:37):
It isn't like the patient did something to make that happen.
Pascal Pfiffner (Sep 14 2019 at 20:37):
My gut says the same!
Michael Donnelly (Sep 14 2019 at 20:37):
And our direction in general has been away from expiring patient tokens unless there's a really good reason.
Jenni Syed (Sep 14 2019 at 20:39):
The problem, in our system, is that there's nothing anymore that lets us figure out who the patient is from their sign on
Cooper Thompson (Sep 14 2019 at 20:39):
Are you both saying don't expire for patient self-access only? Or patient-authorized representative access as well?
Jenni Syed (Sep 14 2019 at 20:39):
(if you were the loser in the merge operation)
Michael Donnelly (Sep 14 2019 at 20:39):
I was only talking about self-access.
Michael Donnelly (Sep 14 2019 at 20:40):
I agree with your "input would be nice" on the proxy access case.
Michael Donnelly (Sep 14 2019 at 20:40):
(So I guess I agree with you on both cases.)
Cooper Thompson (Sep 14 2019 at 20:41):
Even with self-access though, before the merge you have two different user accounts (with two different passwords maybe). After the merge, I'm not really sure if both accounts should be able to access the resulting patient or what. I need to investigate what we (Epic ) do there.
Michael Donnelly (Sep 14 2019 at 20:42):
AH,
Michael Donnelly (Sep 14 2019 at 20:42):
Yes, of course.
Michael Donnelly (Sep 14 2019 at 20:42):
I was talking about the target patient's token.
Jenni Syed (Sep 14 2019 at 20:42):
Target patient for us is still good, keeps moving on with life
Michael Donnelly (Sep 14 2019 at 20:42):
Likewise
Jenni Syed (Sep 14 2019 at 20:42):
just has new magic data back in the past
Michael Donnelly (Sep 14 2019 at 20:42):
Yep.
Pascal Pfiffner (Sep 14 2019 at 20:43):
The problem I have with expiring tokens is that this makes me prompt the user to sign-in again (which we also do in other scenarios, e.g. refresh token revoked). That alone doesn't tell me that I should or should not delete all the data I have. And then, upon re-login, I get a different patient ID back – which again could happen in this merge scenario but also because the user selected the wrong patient from the picker or used different credentials. And I as a client again don't know what to do with the old data that I have.
Michael Donnelly (Sep 14 2019 at 20:43):
Which (as @Pascal Pfiffner and @Ricky Bloomfield and I discussed earlier) is easy for everyone involved. "Oh nice," says the client, "more data!" (Talking about the target patient, since things get out of order in chat)
Cooper Thompson (Sep 14 2019 at 20:44):
This might be a little bit of a stretch, but we do grant different access based on criteria like age. So if the target patient is an adult, and has full access, and the source patient is a minor and has limited access... what permissions do the accounts have to the resultant patient (depending on which birth day was identified as being correct).
Michael Donnelly (Sep 14 2019 at 20:44):
Ugh
Charles Ye (Sep 14 2019 at 21:38):
Good point. The issue is about differences between Patient Identifier domain and Patient Portal Security domain from a solution perspective. Can we assume that the patient registry and patient security directory are two distinct instances ( I think that most cases are)? If they are different instances, merging two patients in the patient identifier domain(s) triggers a task to consolidate patient security credentials of two patients in the security domain(s).
Brian Postlethwaite (Sep 14 2019 at 22:08):
I would have thought that with the Patient resource ID in the token, you wouldn't be able to get at any data anymore... (if you were the loser as @Jenni Syed so nicely points out)
Jenni Syed (Sep 14 2019 at 22:18):
yes, that's exactly why ours kills the session :)
Last updated: Apr 12 2022 at 19:14 UTC
