Stream: argonaut
Topic: US Core R4 Breakout
Michael Donnelly (Sep 14 2019 at 18:12):
What's the link to the Google Doc with topics for this session? @Eric Haas @Brett Marquard
Brett Marquard (Sep 14 2019 at 18:17):
Here is a link
Eric Haas (Sep 14 2019 at 18:18):
on the connectathon track too.
Michele Mottini (Sep 15 2019 at 11:33):
For the merge / unmerge issue I came up with https://github.com/CareEvolution/Public/blob/master/IsDataValid.md
Michele Mottini (Sep 15 2019 at 11:33):
@Ricky Bloomfield @Pascal Pfiffner ^
Jenni Syed (Sep 15 2019 at 13:33):
Concerns with using the Patient.link field? Or a redirect if it's gone?
Jenni Syed (Sep 15 2019 at 13:34):
Though for DSTU 2, we would need an extension for the bidirectional link between two
Jenni Syed (Sep 15 2019 at 13:34):
Though I actually would like to get this to subscription eventually
Jenni Syed (Sep 15 2019 at 13:35):
See also: https://chat.fhir.org/#narrow/stream/179229-subscriptions/topic/combine.2Funcombine
Pascal Pfiffner (Sep 15 2019 at 13:46):
Thanks Michele – an operation could do the job but ideally we can do without. I like the Patient.link properties to detect these changes. We could either _then_ run an operation like Michele suggests or just blow away the data we have and do a re-pull.
Michele Mottini (Sep 15 2019 at 13:48):
In our server link would not change
Grahame Grieve (Sep 15 2019 at 13:49):
link doesn't change with merge/unmerge
Michele Mottini (Sep 15 2019 at 13:49):
Also: there could be other things beside merge / unmerge that cause those kind of changes: permissions changes for example, or actual physical data deletion
Grahame Grieve (Sep 15 2019 at 13:53):
there could be
Pascal Pfiffner (Sep 15 2019 at 13:53):
I think what we're saying is that Patient.link should change. There are the "replaces" and "replaced-by" codes that seem suitable on merge/unmerge.
Cooper Thompson (Sep 15 2019 at 14:03):
There are several challenges with Patient.link though. Adding a link makes the patient resource include data for multiple patients. Even if they are merged and conceptually the same, they are different records, and a client that has SMART scopes only for a single patient might not be allowed to see the content in Patient.link.
Jenni Syed (Sep 15 2019 at 14:13):
Let's walk through 2 scenarios:
Jenni Syed (Sep 15 2019 at 14:14):
(from the perspective of how our server works, please add/comment/etc where yours is different)
Jenni Syed (Sep 15 2019 at 14:14):
You are Patient A
Jenni Syed (Sep 15 2019 at 14:14):
Scenario 1: Patient A is merged to Patient B
Jenni Syed (Sep 15 2019 at 14:15):
In our system, no data is on Patient A anymore, PatientA.link= replaced-by -> Patient B
Jenni Syed (Sep 15 2019 at 14:15):
You also can no longer get refresh tokens for Patient A
Jenni Syed (Sep 15 2019 at 14:15):
So an app will see a refresh failure, and will be required to log in again
Jenni Syed (Sep 15 2019 at 14:15):
at which point, they'll either not be able to log in, or (if the merge was done correctly), they'll now be Patient B
Jenni Syed (Sep 15 2019 at 14:16):
This essentially "forces" a clean up
Jenni Syed (Sep 15 2019 at 14:16):
but it would be nice if Patient B.link = replaces -> Patient A for sanity on those apps. IE: did you log in as a completely different person? Or did a merge occur?
Jenni Syed (Sep 15 2019 at 14:16):
Scenario 2: Patient B is merged into Patient A
Jenni Syed (Sep 15 2019 at 14:17):
All data is moved to Patient A (which is who you are logged in as)
Jenni Syed (Sep 15 2019 at 14:17):
PatientA.link now = replaces -> Patient B
Jenni Syed (Sep 15 2019 at 14:17):
App should force-refresh whole record because data has now "magically" appeared in the past
Grahame Grieve (Sep 15 2019 at 14:18):
for me, if I merge patient B into Patient A, then Patient B goes away; it no longer exists anywhere, and it's not longer referenced anywhere. So GET /Patient/B fails. And so there's no link either
Cooper Thompson (Sep 15 2019 at 14:18):
Scenario A: A difference for our server is that instead of PatientA.link.replaced-by -> Patient B, we delete patient A and return a 301 to patient B when attempting to access patient A.
Jenni Syed (Sep 15 2019 at 14:18):
At no point are there multiple patient ids in the system on the same set of data, and I think if there were that wouldn't qualify as a replaces or replaced-by link based on the definition
Jenni Syed (Sep 15 2019 at 14:19):
How do you know to 301 it?
Grahame Grieve (Sep 15 2019 at 14:19):
me? it's not there anymore.
Jenni Syed (Sep 15 2019 at 14:19):
but how do you know where to redirect to?
Grahame Grieve (Sep 15 2019 at 14:19):
I don't redirect. Since apps don't check. Patient B is a 404
Jenni Syed (Sep 15 2019 at 14:19):
(also @Cooper Thompson )
Grahame Grieve (Sep 15 2019 at 14:20):
and if the patient is the context, this will be sorted out by killing their session and making them log in again, when the id is sorted out again
Jenni Syed (Sep 15 2019 at 14:20):
How about when their patient suddenly gets data?
Jenni Syed (Sep 15 2019 at 14:21):
how would they know to refresh the record? (if they were the merged to patient)
Grahame Grieve (Sep 15 2019 at 14:21):
because they are looking at Patient A?
Grahame Grieve (Sep 15 2019 at 14:21):
the app gets it as new data following whatever approach it uses.
Grahame Grieve (Sep 15 2019 at 14:21):
though I do like Michele's approach to get a 'refresh everything' for some reason or other
Cooper Thompson (Sep 15 2019 at 14:22):
For us, we do a full copy of both patient records before the merge (so we can unmerge). So we use indexes on those copy records to determine that the requested ID is merged. So we do have database concepts for the "deleted" patient, but they aren't patient records.
Jenni Syed (Sep 15 2019 at 14:22):
The refresh everything trigger is why I'm trying to figure out how to do it as subscription, though that won't be there for a while in the standard
Grahame Grieve (Sep 15 2019 at 14:22):
Cooper, what do you do with newly added inforamtion between the merge and the unmerge?
Cooper Thompson (Sep 15 2019 at 14:23):
It needs manual review. You can only automatically unmerge if no new data was added.
Jenni Syed (Sep 15 2019 at 14:25):
To me, unmerge is actually the most troubling one. You need to get the bad data off of the patient that existed the whole time.
Jenni Syed (Sep 15 2019 at 14:25):
As soon as you can
Cooper Thompson (Sep 15 2019 at 14:26):
Yeah, but unmerge seems like just a special case of co-mingled data.
Jenni Syed (Sep 15 2019 at 14:26):
but both scenarios (missing data and having extra data) can cause issues
Grahame Grieve (Sep 15 2019 at 14:29):
at the least we can all agree that this is a mess. That's way I like falling back to 'start again'
Pascal Pfiffner (Sep 15 2019 at 14:30):
For an API consumer, the ideal outcome would be for the loser patient (B) to still be available, so I can see that it's been replaced. I'd prefer that to a 301 (but that is workable). A 404 or the patient just going away is not ideal. The issue is if I can't actually get an access token for patient B anymore, ideally that would still be possible.
Pascal Pfiffner (Sep 15 2019 at 14:31):
(and I'm trying to talk like I was a naïve REST API consumer – which is only half lying ;) )
Grahame Grieve (Sep 15 2019 at 14:32):
I really dislike 301 as unsafe because we know that people let their stack handle that automatically, and they won't know that they've shifted patients without specifically checking.
Michele Mottini (Sep 15 2019 at 14:32):
You all seem to be assuming that a merge is a 'merge into' - with a patient going away - that's not the case in our system - and I think in all HIE systems
Cooper Thompson (Sep 15 2019 at 14:32):
In the scenarios Jenni listed, you were logged in as patient A. So you wouldn't have had access to patient b to begin with.
Grahame Grieve (Sep 15 2019 at 14:33):
of course, I wrote in IPA that clients SHALL check that, but I'm not sure that'll stick
Grahame Grieve (Sep 15 2019 at 14:33):
@Michele Mottini what's a merge if it's not a merge?
Michele Mottini (Sep 15 2019 at 14:35):
We have a 'record group' = all patients that have been linked together. Merge or split are move a patient from one record group to another (and remove the record group if it is empty)
Pascal Pfiffner (Sep 15 2019 at 14:36):
@Cooper Thompson You could be logged in to either, right? If you're logged into A it's a smaller problem – you just get more data.
Grahame Grieve (Sep 15 2019 at 14:36):
Person sort of could function like that
Pascal Pfiffner (Sep 15 2019 at 14:36):
But Michele, that still means you move resources from one patient to another. So you could still add the link.
Cooper Thompson (Sep 15 2019 at 14:37):
@Pascal Pfiffner I think the issue is more about which user accounts are still active after the merge, not which patients. If we determine that the patient B account and tokens can remain active, then it can just pull patient A data.
Michele Mottini (Sep 15 2019 at 14:38):
@Pascal Pfiffner Depends on our FHIR server is configured - the recommended way is FHIR patient = our record group, so there is literally nothing to put in link
Pascal Pfiffner (Sep 15 2019 at 14:39):
Sure, but that is an issue I cannot comment on because it's implementation details on the server side. All I know is "I have a token for B" and "I can read resources for patient B". A redirect to patient A is an anomaly because it no longer matches a) what my token is saying and b) what I had. Therefore, if all I can access anymore is patient B as inactive with a reference to patient A, my world is still in order and I can act.
Pascal Pfiffner (Sep 15 2019 at 14:39):
^^ @Cooper Thompson
Michele Mottini (Sep 15 2019 at 14:40):
but I was referring to 'after a merge patient B goes away and so cannot login' - this might not be true
Pascal Pfiffner (Sep 15 2019 at 14:40):
I consider "Patient B goes away after a merge and/or can no longer login" an issue.
Cooper Thompson (Sep 15 2019 at 14:50):
@Pascal Pfiffner the "no longer login" is complicated (for us). There are several cases here:
1. Neither of the two Patient records has a User record associated with it. (N/A for you, since the user won't be able to authorize Apple)
2. Only the source Patient record has a User record associated with it.
3. Only the destination Patient record has a User record associated with it.
4. Both the source and destination Patient records have User records associated with them.
In cases 2 and 3, the User record will automatically get access to the resultant patient.
In case 2, the FHIR ID will change.
In case 3, the FHIR ID will remain the same.
In case 4, we have several options for how and if to auto-merge user accounts, so your mileage may vary.
Cooper Thompson (Sep 15 2019 at 14:52):
So the "no longer able to login" issue is really related to #4, which is really about User account merging more than patient merging.
Pascal Pfiffner (Sep 15 2019 at 14:52):
@Cooper Thompson Yes, I recognize this is complicated. I'm trying to think how a "vanilla" solution could work, thinking I know only what I know, which is what SMART specifies (token bound to Patient) and what Argonaut exposes.
John Moehrke (Sep 15 2019 at 15:15):
this discussion mirrors the discussion the Merge track at fhir connectathon had. see the output on the #patient administration WG
Jenni Syed (Sep 15 2019 at 15:42):
So far my conclusion is: We're going to have to build an IG around the subscription for combine and uncombine. Allow for many different ways of qualifying that will work for most systems
Jenni Syed (Sep 15 2019 at 15:43):
The url for the topic will point to the IG, which is how an app knows "This is the subscription you want"
Jenni Syed (Sep 15 2019 at 15:43):
But each system will/may define criteria so that it works for the underlying implementation
Jenni Syed (Sep 15 2019 at 15:44):
What we really need to do then (if that is an accurate conclusion) is make sure the Topic can handle the scenarios
Jenni Syed (Sep 15 2019 at 15:44):
One gap we've identified is the lack of ability to trigger on Operation success (failure??). I assume the outcome of the operation would have to come into play here
Jenni Syed (Sep 15 2019 at 15:45):
This only deals with the notify part of the merge/unmerge, not the logistics of how to trigger a merge
Jenni Syed (Sep 15 2019 at 15:46):
OTOH, without subscription (eg: for DSTU 2 servers that are in the wild today), we need to figure out something as well
Jenni Syed (Sep 15 2019 at 15:52):
@Cooper Thompson for this statement: "There are several challenges with Patient.link though. Adding a link makes the patient resource include data for multiple patients. Even if they are merged and conceptually the same, they are different records, and a client that has SMART scopes only for a single patient might not be allowed to see the content in Patient.link."
Jenni Syed (Sep 15 2019 at 15:53):
For us, the link only exists while the system thinks they're conceptually the same. I am curious how RelatedPerson works if the primary concern is the relationship to another record in your system (or was this just a general concern)?
Cooper Thompson (Sep 15 2019 at 16:02):
Actually, let me retract my comment about Patient.link in this case. I was focused on what we currently do, and some internals for how we represent stuff. I think we could support Patient.link[replaces]. I'm still not liking the Patient.link[replaced-by] though. I'm open to being convinced though.
Pascal Pfiffner (Sep 15 2019 at 16:23):
Patient.link[replaced-by] would be neat to detect that you were logged in to patient B (the merge loser in our previous exchanges) and would clearly state to me as a client what happened (merged away) and what I need to do (quarantaine the data, ask the user to log in again, which will give dem new tokens for the new patient ID, which I could even validate – to check that they didn't pick somebody else entirely). Of course this is only useful if I can actually access that Patient resource, i.e. the refresh tokens stay alive.
Eric Haas (Sep 15 2019 at 17:14):
to more fun topics for today's breakout
hidden server values - redux
diagnosticreport profile search conformance by profile
summary of outcomes
Here is a link
Last updated: Apr 12 2022 at 19:14 UTC
