Stream: patient empowerment
Topic: Patient Data Writeback IG
Abbie Watson (Apr 02 2020 at 18:04):
Hello,
Does anybody know if there are any drafts for an Implementation Guide related to Patient Data Writeback to EHRs?
This would be the use case related to a PHR or 3rd party Patient Portal or 3rd party App that collects data, and then it's sent back to an EHR (via FHIR) with provenance, and patient matching, and some sort of quality control review.
The PHR-S guide was sort of in the general ballpark, and had touched on some of the topics nearly 5 years ago. I suspect this topic has been discussed before, but the last round of work may have been years ago, or was is sitting in some sort of draft status.
Dave deBronkart (Apr 24 2020 at 15:21):
I'm bumping this up because it got no response, my spidey-sense says this will be important someday.
Abigail Watson said:
Hello,
Does anybody know if there are any drafts for an Implementation Guide related to Patient Data Writeback to EHRs?This would be the use case related to a PHR or 3rd party Patient Portal or 3rd party App that collects data, and then it's sent back to an EHR (via FHIR) with provenance, and patient matching, and some sort of quality control review.
The PHR-S guide was sort of in the general ballpark, and had touched on some of the topics nearly 5 years ago. I suspect this topic has been discussed before, but the last round of work may have been years ago, or was is sitting in some sort of draft status.
John Moehrke (Apr 24 2020 at 15:55):
you should tie this to the fact mentioned elsewhere that this is picked as a priority project for patient empowerment.
Dave deBronkart (Apr 24 2020 at 15:56):
Interesting point, John. Are you talking about the Patient Corrections priority? @Abigail Watson did you intend something more than corrections?
John Moehrke (Apr 24 2020 at 16:01):
no the Patient-Contributed Data: @Jan Oldenburg @Maria D Moen
John Moehrke (Apr 24 2020 at 16:03):
corrections are a specific workflow where a case is made that the data is wrong, that correction request needs to be mitigated by review and impact of a correction on past uses of the data, and tracking of that impact of the correction when approved.
John Moehrke (Apr 24 2020 at 16:04):
writeback is a problematic word... I read it in a more liberal way, that is to allow patient generated data to be usable with little friction in EHR workflows. This might be by pushing the data into the EHR, might be by the EHR reaching out to the PHR, might be by a portal staging data, might be by an HIE exchanging data (Direct, Query, etc).
Bart Carlson (Apr 24 2020 at 20:25):
I have not been involved in an HL7 group that has defined/written a draft for a system that collects clinical data at the direction of a patient from an EHR, and also sends it back at the patients request to an EHR (via FHIR) with provenance, and patient matching, and some sort of quality control review.
However, my company Azuba has recently completed development and testing of a backend enterprise system with patient control via a smartphone that does what you describe and considerably more.
John Moehrke (Apr 27 2020 at 12:13):
we are not saying it isn't possible today. What we are doing is writing an IG that would standardize the interoperability mechanics so as to help drive for this to be possible more than it is happening today. With the potential that once we have this, ONC might recommend or mandate it. There are also some companion IG that have the patient as an active contributor (CarePlan). So, none of this is undiscovered, but it certainly is not universally understood or implemented.
Dave deBronkart (Apr 27 2020 at 19:25):
John Moehrke said:
writeback is a problematic word... I read it in a more liberal way, that is to allow patient generated data to be usable with little friction in EHR workflows. ...
@Abigail Watson we need your involvement here, since you started this thread. :-) I can see John's point that "writeback" sounds like trouble. (I personally know people who are mentally stable but so NUTS in their beliefs that the last thing I'd want them doing is writing ANYTHING into ANY record that other humans use.) So - whatcha got in mind?
Abbie Watson (Apr 27 2020 at 20:17):
Hi there,
Apologies. Have been working on an SBIR grant deliverable over the weekend.
Yeah... so, I posted this nearly a month ago - before we had finalized the priorities last week - because I'm involved in a U18 grant writing effort with a department at Laurie's Children's Hospital, and the grant could fund development and prototyping of an IG for the patient contributed data piece. Like... I have clients who want to implement the patient generated data component, and working to get funds in place to sponsor it. Laurie's isn't the only one.
I agree with John's notions around the term 'contributed data' vs 'writeback'. But honestly, I was just casting a net to see what the waters are like. The PHR-S IG, for instance, was surprisingly fleshed out. And I was just wondering if there was anything along those lines for patient-generated data, writeback, etc.
I would be curious to look at any companion IGs that John can recommend. That's what this thread was about. Trying to identify and find them.
Tom Jones (Apr 28 2020 at 04:44):
Ahh - that's a potentially large set of applications, not sure which ones you might be interested in. NIST announced the start of a telehealth (1900) effort. The most interesting question is the provenance of the data uploaded. Is it machine generated or just a user report? Will make a big difference. https://content.govdelivery.com/accounts/USNIST/bulletins/288a3f5
Brendan Keeler (Apr 28 2020 at 05:57):
Most EHRs already have a reconciliation process for meds, allergies, problems and vaccinations for those that come in via CDA exchange, Surescripts med history, vaccination registries, or other sources. It would make sense to funnel patient additions into that existing holding tank / reconciliation process.
Dave deBronkart (Apr 28 2020 at 11:08):
Brendan Keeler said:
Most EHRs already have a reconciliation process for meds, allergies, problems and vaccinations for those that come in via CDA exchange, Surescripts med history, vaccination registries, or other sources. It would make sense to funnel patient additions into that existing holding tank / reconciliation process.
@Jan Oldenburg @Maria D Moen as co-leaders of the PE WG's Patient-Contributed Data project, you will surely want to be aware (if you're not already) of the thoughts in this thread, which @Abigail started some time ago but which has now ripened squarely into your/our spotlight.
@Brendan Keeler I'm not sure of the best way to ensure that your work on this and your HL7 chops are engaged and harvested in wherever this goes but it sounds like we're in a similar space and should be aligned. Do you know of any work on this that's scheduled (or should be) for the Virtual Connectathon in 2 weeks?
John Moehrke (Apr 28 2020 at 13:46):
We need to define the overall need in a implementation idependent way. This is to say that the overall need should be independent of push vs pull models, messaging vs document vs REST, portals vs clients vs apps vs cloud, etc...
John Moehrke (Apr 28 2020 at 13:48):
Brendan Keeler said:
Most EHRs already have a reconciliation process for meds, allergies, problems and vaccinations for those that come in via CDA exchange, Surescripts med history, vaccination registries, or other sources. It would make sense to funnel patient additions into that existing holding tank / reconciliation process.
I agree. I would note that this mediation should be defined independent of implementation details, and in a way that enables it to be automated. That is to say that the worst case is that a human checks everything with conversations and independent verification measurements; but also that a system that makes the data available in the clinical treatment flow with proper attribution (Provenance) and automated checks.
John Moehrke (Apr 28 2020 at 13:50):
This is not to say we can't get more detailed on one or two ways to do this with one or two specific implementations... but we should start with a clear use-case that speaks to the overall patient experience (poor and future), what does the patient get out of it, what does the healthcare clinician get out of it, what does the healthcare organization get out of it, what does the health insurance get out of it, what impact to medical records, what impact to malpractice, what impact to safety, what impact to malicious intent, etc.
Lloyd McKenzie (Apr 28 2020 at 13:51):
@Danielle Friend @Michelle (Moseman) Miller @Jeffrey Danford - As you start looking at consuming information from external data sources that aren't necessarily trusted/authoritative, how do you want to receive that information? Is it simplest if the data is wrapped in a 'document' because that allows you to use your existing processes to allow a user to pick and choose what they want to copy across? Do you differentiate in any way between documents where that's the intention (copy some/all into the official record) vs. those that are intended to just sit in document space and perhaps get browsed occasionally?
John Moehrke (Apr 28 2020 at 13:52):
I am an advocate for documents for all the good principles that document have, including provenance, authenticity, authorship, completeness, setting context, timeframe, etc...
John Moehrke (Apr 28 2020 at 13:53):
but documents are not always the best mechanism, such as when a measuring device is streaming measurement data (aka fitbit, scale, BP cuff, etc)
Michelle (Moseman) Miller (Apr 28 2020 at 14:00):
We can receive data from external sources as either documents or discrete resources (e.g. allergy, condition, procedure etc). We will use Provenance to assess trust. If not trusted, then a human being needs to decide whether each piece of data (resource) should be written into the patient's chart. There is a distinction between whether the data has been written to the patient's chart versus waiting to be reviewed (that isn't unique to documents and applies to all discrete resources)
CC @Jenni Syed
Jenni Syed (Apr 28 2020 at 14:24):
I would actually prefer it in discrete pieces, but I know traditionally it comes in CCDA form.
Jenni Syed (Apr 28 2020 at 14:26):
EG: requiring something like a standalone app that patients use to understand how to create a CCDA or complex document just to send down updates to the meds they take seems like overkill. If they were updating a lot of data, that may be convenient for them, but it would be nice if they could choose.
Brendan Keeler (Apr 28 2020 at 14:53):
<whisper> a CCDA is discrete </whisper>
Brendan Keeler (Apr 28 2020 at 14:53):
;)
Brendan Keeler (Apr 28 2020 at 14:54):
But yeah, no need to spin up a heavy document in this day and age
Lloyd McKenzie (Apr 28 2020 at 15:45):
What is the boundary between writes of discrete resources that actually directly update the patient's chart vs. those that just update the 'holding area' (where stuff might or might not be migrated into the patient's chart)? Do all writes from external systems go exclusively to the 'holding area'?
Jenni Syed (Apr 28 2020 at 16:21):
In our system, we base it on who is authenticated and trust/provenance
Jenni Syed (Apr 28 2020 at 16:22):
IE: it flexes. So if a patient was authenticated and requesting updates, we would likely take the request like a "normal" update but it would route to a staging area (and would be indicated in the response as not being part of the legal record)
Lloyd McKenzie (Apr 28 2020 at 16:39):
How does that work in terms of eTags, queries, etc. I.e. If I query your system before submitting an update, will I see data from the official record, the staging area or both? How are 'updates' handled in terms of passing back eTags if they get route to the staging area instead?
Jenni Syed (Apr 28 2020 at 16:58):
It will be indicated in a security tag, and yes, you may be able to see that when you query the data.
Jenni Syed (Apr 28 2020 at 16:59):
You would see both the unreliable data and the reliable/official record
Jenni Syed (Apr 28 2020 at 17:00):
To be clear: we haven't played around a lot yet with modifies of legal record views. Most of what we have done today is for external systems but the concepts have been discussed to apply to future patient contribution. This is something we would want to talk through with this group :)
Jenni Syed (Apr 28 2020 at 17:01):
What we did today was based on some previous discussion with security, connectathons, WG meetings.
Lloyd McKenzie (Apr 28 2020 at 17:26):
Understand that things may not be fully developed/designed, but I'll keep asking questions anyhow :) If an 'untrusted' source submits a PUT (or even a PATCH) to a trusted record, would that result in the system behaving as though you'd submitted a POST resulting in the creation of a new un-trusted equivalent record? How would the two records be tied together?
Jenni Syed (Apr 28 2020 at 17:33):
I believe we've discussed that you would see 2 resources, one that is the legal record, one that is the untrusted version. I'll dig a bit :)
Jenni Syed (Apr 28 2020 at 17:35):
And not everyone can see the "proposed" change. People that have to accept it to the record can, some systems that help negotiate the reconciliation process can, and the person/system that proposed the modify can (at a minimum).
Lloyd McKenzie (Apr 28 2020 at 17:40):
What I'm really intrigued by is the notion that a request for an update can result in a create - not sure the current spec allows for that, though technically I think it could work - it would mean the 'location' that comes back on an update would specify a different id than the original PUT/PATCH.
Lloyd McKenzie (Apr 28 2020 at 17:41):
I'm certainly much happier with a pure REST approach than needing to wrap stuff in documents
John Moehrke (Apr 28 2020 at 20:21):
The Delete in CRUD - with regards to patient data contribution that has been accepted (automated or manual) into the EHR: I presume, like with typical lifecycle of data within an EHR, patient generated data is not allowed to be fully deleted but rather marked as not active? In this case I am speaking of truly patient authored. Distinct from when a patient provides a clinician authored data, where the patient is just conveying data with clear clinical provenance. Is there a difference between data that has been accepted into the EHR but not yet used, vs data that has been accepted into the EHR and used in some workflow?
John Moehrke (Apr 28 2020 at 20:22):
the Update in CRUD -- with regards to patient data contribution that has been accepted (automated or manual) into the EHR --- similar to delete -- but is this data allowed to be Updated? If so, is this only true of systems that have some kind of version tracking of data lifecycle?
Maria D Moen (Apr 29 2020 at 14:25):
Here is a use case to consider, as you mentally massage the concept into place: I have created my advance directive, in view of the unknowns that exist in a COVID world. In it, I've stated what my goals, preferences and priorities for care are if I am unable to express them myself due to a health crisis or emergency. Those are MY statements, and intended for use by treating clinicians to inform the care I will receive. Whether I've had them notarized or witnessed, they are authentic statements of how I want my medical treatment to proceed. There are LOINC codes that allow the questions asked to be wrapped in a CCDA structure and moved from me/my computer/my doctor's EHR who also has a copy of them. The responses are unstructured text, but the questions are tied to a standardized vocabulary that renders them interoperable. Whether or not to accept them into the EHR because they were patient-originated and not clinician-originated is a why question, not a how question. I see HL7 as answering the how question, although why questions will naturally arise. Is what I want as a patient somehow less valid/trusted than what a clinician types into their EHR? I certainly hope not, hence my presence on the Patient Empowerment work group and work on the patient-generated data workstream therein. Food for thought...
Debi Willis (Apr 29 2020 at 14:55):
Thanks Maria. This is exactly why we need the patient voice. Use cases like this will hopefully get some brainstorming on the best ways to make these important patient contributed data available to providers when they need to make clinical decisions about our care. As patients, we really want to know that our providers have the most up-to-date information about us...including information we contribute. It is also important that when my provider shares information with other providers outside of their organization that my patient contributed data is also sent to them. Everyone caring for me or my loved one needs to know all the information. I'm not a physician, but my hunch is they also want all the information to help them recommend the best options.
Lloyd McKenzie (Apr 29 2020 at 15:01):
Whether the statements are yours are not is only part of what makes then 'trusted' - the other consideration is whether the statements are encoded in a way that meets the rules of the EHR they're being stored on. As well, the healthcare organization may have rules around accepting the content - perhaps they need a paper signed copy or something before they can accept the electronic version because "lawyers". So yes, it's possible that there could still be limits on patients updating data even when the patients are the authoritative source of the record being updated. However, that's not actually any different for external practitioners - an external physician may have limitations on their ability to update the status on a prescription they wrote in the pharmacy system of the pharmacy that's filling the prescription. Whenever data comes from 'outside', a system needs to be cautious because the potential for breaking things is always real.
John Moehrke (Apr 29 2020 at 16:29):
I think that Maria also points out a use-case that is on the edge of the space that is within the Legal Medical Record. There are documents, such as a Automobile Title that are very important, but are not part of the Legal Medical Record. There are potentially many things that a patient might submit that are inappropriate to be in the EHR (Legal Medical Record).
Some organizations may choose to file Advanced Directives in a different system than the Legal Medical Record. They might call the combination the EHR, but they might well not call anything but the Legal Medical Record the EHR.
Tom Jones (Apr 30 2020 at 00:35):
how about this statement -- No data should ever be posted in the patient health information that is not from a source with an IAL2, AAL2 signin cred
Lloyd McKenzie (Apr 30 2020 at 02:02):
For one, that sounds pretty U.S.-centric. Second, I think that'd be pretty hard to get most patients and care-givers set up to have one of those.
John Moehrke (Apr 30 2020 at 12:43):
and third... it is policy statement that is outside the scope of HL7 organization... It is a fine recommendation, but the best way to encourage that recommendation is to explain rational and not just declare some policy. There are good rational, but there are also huge problems with IAL2 and AAL2. Like it is a huge economic burden that many citizens can't achieve; thus it is rather improper.
Tom Jones (Apr 30 2020 at 22:41):
It's a statement taken more or less directly from tefca - is that not sufficient? At least its measurable.
Lloyd McKenzie (Apr 30 2020 at 23:02):
It's more than is reasonably achievable - and wouldn't necessarily make sense outside the U.S. and our scope is global
Brendan Keeler (May 01 2020 at 05:53):
Brendan Keeler (May 01 2020 at 05:53):
I don't know Lloyd. I found this map and somewhat have to agree with Tom
Lloyd McKenzie (May 01 2020 at 14:04):
There are some projects at HL7 that are U.S.-centric, so it's not an unreasonable presumption for people to make. However, in this case, I'm hoping we can define something with global applicability
Tom Jones (May 01 2020 at 17:28):
I am not sure i understand the problem - perhaps it is just verbalism. Most EU countries use eIDs, the BC government is focused on DIDs. All of these have strong requirements for identity and authentication proofing. The NIST 800-63-3 is adapted by many in banking world wide, the ISO std is based on an earlier version of the NIST standards. Looking at interop - my guess is that if a US citizen is in a foreign country and wants their EHR transmitted there that the TEFCA rules will apply. That will probably apply in the other direction as well. So -- is it just the codes that i used or is there some issue with the concept of strong assurance? Or would you just like me to quote the ISO std and language?
Lloyd McKenzie (May 01 2020 at 17:52):
If it's an ISO standard, that's different. The bigger issue is the infrastructure required.
Tom Jones (May 01 2020 at 18:03):
Well let's not conflate the two concepts then. It will be hard to talk about ux w/o understanding the need for strong assurance of IDs. I will start a separate thread to be sure that we make the ideas distinct.
Abbie Watson (May 05 2020 at 16:53):
What happens when the incoming data is using a different value set? I am sort of assuming that part of the reconciliation process involves mapping between value sets. Our jurisdiction models race/ethnicity/sex/gender/genetics this way, but your jurisdiction models it this other way. Should we update the value sets before the PUT/PATCH? Or after? Should patient systems try to make a best-guess at what the receiving EHR expects? Or does the EHR reviewer want to evaluate the before/after?
John Moehrke (May 05 2020 at 16:55):
that is supported by concept maps
Abbie Watson (May 05 2020 at 16:55):
Are FHIR concept maps supported by the EHRs?
John Moehrke (May 05 2020 at 16:56):
the valueset used to author can be recorded, but typically isn't under the presumption that a code means exactly what that code means in all cases. But valuesets do tend to limit the choices and thus a vocabulary value can be chosen as the best-fit... which is what you describe around gender example
John Moehrke (May 05 2020 at 16:57):
even the profile used to constrain the output (e.g. US-Core) is not required to be recorded... yet, that does limit the data richness
John Moehrke (May 05 2020 at 16:57):
both can be recorded... but typically are not (often because the author is often an automatic process that doesn't know better)
Abbie Watson (May 05 2020 at 16:59):
And if things are mapped correctly, and the sending system can align value sets and other parameters correctly, is there a path here to automating the input? Is/should that be a goal of an IG?
In the RIS/PACS world, we had a similar quality control process of incoming DICOM data, that was flagged for review and patient matching in an inbound quality control queue; but if the equipment was of the correct type, and the medical record numbers were aligned and a few other parameters, it was possible to turn on automatch/autoimport. It was a widely appreciated feature when we were able to implement it. So my inclination is to have a reconciliation process that increases towards automation if various conditions are set. But I'm not sure if that's what other people are expecting out of this IG.
John Moehrke (May 05 2020 at 17:04):
in abstract terms, yes there should be a speedbump... in reality policy and procedure will adjust as necessary. Without a speedbump in the abstract model, these policy determinations can't be done, and the abstract model will be ignored.
Abbie Watson (May 15 2020 at 18:48):
Someone dug up the Patient Report Outcomes IG, which I think qualifies as a bit of prior art. I'm surprised that the PRO IG only concerns itself with Questionnaire. How do we determine which working group produced this? I'd like to approach them, and ask what their opinions/thoughts are on non-Questionnaire resources.
http://hl7.org/fhir/us/patient-reported-outcomes/2018Sep/guidance.html
Lloyd McKenzie (May 15 2020 at 18:51):
PRO is owned by FHIR Infrastructure
Lloyd McKenzie (May 15 2020 at 18:52):
The scope of the project was pretty constrained based on a funded research project. It wasn't intended to cover all patient-reported outcomes
Jan Oldenburg (Sep 03 2020 at 02:31):
I think one of the key questions, in the long run, is whether the EHR is the proper repository for some patient-contributed data. It may be hugely relevant to caring for a person, but it is possible that the EHR isn't the right repository for it. Still, I'm sort of shocked, reading this thread, that there may not be any provision for patients to contribute information to their medical record.
John Moehrke (Sep 03 2020 at 11:50):
I agree. Patient Contributed Data should be a requirement at the healthcare organization level, not specifically the EHR. The requirement should require authorized access by the patients GP, controlled by the patient. The mechanics behind this do not need to be defined as it is an internal matter (I expect most now days would build it with FHIR anyway). This internal mechanics could a direct link to the EHR, a staging pool, or a standalone PHR.
Dave deBronkart (Sep 03 2020 at 13:15):
Jan Oldenburg said:
I think one of the key questions, in the long run, is whether the EHR is the proper repository for some patient-contributed data.
Heck yes - and I'm hoping your/our white paper will expound on that.
Last updated: Apr 12 2022 at 19:14 UTC
