This is a quick description of the minimum requirements to turn patient-mediated “transmit” into a usable system for feeding clinical data to a patient’s preferred endpoints. In my blog post last month, I described a small, incremental “trust tweak” asking ONC and CMS to converge on the Blue Button Patient Trust Bundle, so that any patient anywhere has the capability to send data to any app in the bundle.
This proposal builds on that initial tweak. I should be clear that the ideas here aren’t novel: they borrow very clearly from the Blue Button+ Direct implementation guide (which is not part of certification or MU — but aspects of it ought to be).
Problem: patients can’t establish a persistent data feed to apps
MU 2014 certification criteria allow patients to (attempt to) trigger the transmission of a Direct message message to a patient-selected endpoint. Even if the trust issues are worked out, there is a substantial usability problem: patients can only send one document at a time. There’s no way to transfer a historical backlog of encounter summaries, and no way to prospectively create a “feed” or “subscription” of future data.
The solution: enable patients to define “subscriptions” to their data
This proposal ensures that patients can establish a subscription to their data, rather than having to sign in to a portal (as is typical today) and manually select and send one document at a time. Here’s what it would take.
For ONC’s side
ONC should define new “VDT” certification criteria requiring EHRs to implement the following functionality:
- The EHR associates a set of “subscription endpoints” with each patient record. These endpoints are just Direct email addresses listening for patient-specfic data.
- The EHR supports an operation called “add subscription endpoint to a patient record”. This operation has two inputs, at minimum: the Direct address of the endpoint, and a boolean flag called “transmit all historical data now”. When the “now” flag is set, an initial message is automatically sent to the new subscription endpoint including all historical documents as attachments.
- The EHR provides an operation called “remove a subscription endpoint from a patient record”. This operation just removes a Direct address from the set of endpoints associated with a patient’s record.
- The EHR exposes a provider-facing UI for clinical staff to manually perform the “add” and “remove” operations upon a patient-authorized request (e.g. in-person or fax request). This allows third-parties to ask patients for limited-purpose permissions (for example, by signing a paper release form) and then “just take care of things” — all without asking patients to share a username and password.
- The EHR provides a patient-facing UI to perform the “add” and “remove” operations, so patients can choose to manage their subscriptions themselves.
- Any time a new document becomes available for patient “view and download”, a copy of that document is automatically transmitted to each subscription endpoint associated with the patient’s record. This functionality builds naturally on existing “view, download” capabilities by tying into today’s workflows. It exposes encounter summaries, discharge summaries, and referral summaries (at a minimum).
For CMS’s side
- CMS should ask all Eligible Hospitals and Providers to attest that they are making the updated “VDT” functionality available to all patients, including the “add” and “remove” subscription operations.
Call to action!
This proposal builds incrementally on existing 2014 EHR Certification and MU2 attestation criteria. It involves a bit of software engineering, of course — but it’s exactly the kind of rules-based message routing behavior that EHRs and interface engines are already very good at.
As a community, we can make these changes and demonstrate success long before ONC and CMS action. Please contact me (joshua.mandel at childrens dot harvard dot edu, or @JoshCMandel on Twitter) if you would like to participate in our “coalition of the willing”!