Stream: implementers
Topic: Patient Reference Remediation
Dale Brown (Jan 14 2021 at 16:29):
Hello,
I was wondering what the community at-large might be doing in order to resolve the potential issue wherein the subject.identifier.value or subject.reference element changes within a resource, such as the case where a master patient ID that was used as the logical ID for the referenced Patient resource was split or reassigned.
An example would be if we had an Observation resource assigned to a Patient resource with the logical ID '1' that is made available via our FHIR interface that is then later pulled by a different, potentially external, application. Later, we update the Observation resource to point to a Patient resource with the logical ID '2' because the Observation was assigned to the wrong family member and the disclosure was reported.
Is there any way within the existing FHIR standard where we could track and represent these changes such that the application would be aware that the Observation no longer belonged to the patient with the logical ID of '1'?
I've seen some discussions regarding using Provenance resources, but those specific use-cases are not defined within the implementation guides associated with the CMS Interoperability Mandate. Likewise, I do not think that necessarily solves the requirement for feedback to the application because it would have to be aware of the Provenance resource's existence.
Jon Conley (Jan 14 2021 at 18:06):
@Dale Brown in our FHIR Clinical Repo, we keep a history of the versions of all FHIR resources. So it could at least be determined that for the Observation resource you mention for example that a previous version pointed to the "non-surviving Patient" (i.e. in the case of a Merge event). That doesn't help to track "why" the event happened.. we usually have to dig back into the HL7 and other log statements. I've never done anything with the Provenance resource though.
Dale Brown (Jan 14 2021 at 18:23):
@Jon Conley I'm not so interested in displaying the "why" per say, but rather whether or not there's a way to tell a third-party application, for example, that they need to delete the data that was disassociated from Patient ID 1. I imagine that the application would pick it up for Patient ID 2 as part of the regular incremental update data pull (based off of meta.lastUpdated or otherwise).
I'm not sure how this could be accomplished at the moment outside of a differential historical data pull.
We have situations where both Patient IDs "survive" and are considered active, but some of the original patient's experience is moved from one ID to the other. So, basically, a partial merge.
Jon Conley (Jan 14 2021 at 19:45):
@Dale Brown yeah I'm not sure of a way per the FHIR spec, and the main consumers of FHIR data that we are ingesting into our system are internal applications, so for that we are using Kafka to generate events. The applications subscribe to those events and if they see something like a "Patient merge", it indicates which resource was merged and the application goes and re-fetches the resource(s) from the repo
Lloyd McKenzie (Jan 14 2021 at 21:10):
If a system queries data, it's pretty much impossible to tell them "please query again" unless they've set up a Subscription to monitor the resource in question. If the data was pushed originally (via a message, create, update, etc.), then presumably you could push the change via the same mechanism. In theory, you might have an audit log of all systems that had queried the record and, if you had a business relationship with the owners of those systems, you could communicate out-of-band that there was a change that needed to propagate, but no FHIR-based mechanism.
Jenni Syed (Jan 14 2021 at 21:22):
I believe PA @Brian Postlethwaite has a guide around detecting merge and unmerge, which may help out here
Jenni Syed (Jan 14 2021 at 21:24):
It may be more broad than this, but knowing how a "merge" is represented would allow someone to monitor/detect. Just detecting at each resource level is likely not enough
Brian Postlethwaite (Jan 14 2021 at 21:50):
Current documentation is here:
https://confluence.hl7.org/display/PA/Merge+Operation
Dale Brown (Jan 15 2021 at 04:15):
@Brian Postlethwaite @Jenni Syed That is helpful, thanks. Unfortunately, it doesn't appear that cases for splits or partial merges have been discussed there yet. I did find some posts on this board from last year discussing using the link mechanism for the Patient resource, which works for full merges wherein the Patient ID is sufficiently granular, but when there's a case where both IDs survive, that's not sufficient because it's only some of the attached resources that are being moved.
So, if Patient ID 1 has Observations A, B, and C, and we split off a Patient ID 2 who is the true owner of Observation B, for example.
The desired result would be Patient ID 1 with Observations A and C and Patient ID 2 with Observation B. Patient ID 2 may or may not already exist.
John Achoukian (Feb 26 2021 at 21:45):
@Lloyd McKenzie Our proprietary data structure feeding our FHIR server stores versions of patient profile data based on PCP changes, demographics changes, and plan changes.
The IG documentation suggests that we do not have to support versioning as part of FHIR API data, at least not yet.
Do we need to populate our FHIR repository with all the old versions of our patient data even though versioning isn't required?
We also have future eligibility data around renewal time. Hence, the latest eligibility period data may be in the future.
Lloyd McKenzie (Feb 26 2021 at 22:04):
There are roughly three levels of version support possible:
- full support (i.e. know when data has changed and can expose any desired version)
- version-aware, no history (know when something's changed, but can only show current version)
- none - have no idea when/if anything has changed (which makes avoiding update collisions challenging)
In practice, you could have other situations (e.g. can retrieve versions for the last 6 months but nothing earlier, etc.
In some cases, an IG may mandate a certain level of version support, but the base specification doesn't impose any particular expectations.
John Achoukian (Mar 04 2021 at 21:19):
Thanks @Lloyd McKenzie Does the CARIN IG specify a level of version support or does it vary by resource profile?
John Achoukian (Mar 04 2021 at 23:13):
Another Alliance member previously asked similar questions about history, but I did not see a response. Can we get a clarification on the following?
Payers have to make Patient account history available from Jan 1st 2016 for a members as long as they are continued to be covered by that payer, and after membership termination of coverage payer has to keep the data available for 5 more years. (Please Validate)
Can you please provide an approach or guidance for the following scenarios? Are we overthinking this?
1) What if a previously registered member disenrolled over a year ago, will the health plan still be required to support login?
2) What if a never registered member disenrolled over a year ago, will the health plan still be required to facilitate a registration and login?
3) What if a member obtained coverage with the same payer before end of 5 years, they left and came back, (and Payer maintains same account internally), will both sets of data history (e.g. Coverage and EOB) be available to the member or only the most recent?
4) What if patient, provider or organization demographics change during the course of a members coverage? Will the historical data pertaining to patient, provider or organization data be required to reflect claims or encounters at the time of the historical events?
Michele Mottini (Mar 05 2021 at 00:18):
No specific level of version support is required by CARIN BB - no versioning at all is fine
Michele Mottini (Mar 05 2021 at 00:19):
If / how to support data for previous members and such is not really a technical question and it is not related to FHIR versioning, it is policy.
Daniel Venton (Mar 05 2021 at 13:25):
@John Achoukian Your questions would probably be better directed towards CMS or the authors of the Patient Access API as they are the ones requiring member/patient access. The way I read them: All current AND former members shall have access to retrieve their data back to 2016-01-01. The way my company reads them: All current members.
Last updated: Apr 12 2022 at 19:14 UTC
