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).
Continue reading “Certification/MU tweaks to support patient subscriptions”
In a blog post earlier this month, I advocated for ONC and CMS to adopt a grand scheme to improve patient data access through the SMART on FHIR API. Here, I’ll advocate for a very small scheme that ignores some of the big issues, but aims to patch up one of the most broken aspects of today’s system.
The problem: patient-facing “transmit” is broken
Not to mince words: ONC’s certification program and CMS’s attestation program are out of sync on patient access. As a result, patient portals don’t offer reliable “transmit” capabilities.
2014-certified EHR systems must demonstrate support for portal-based Direct message transmission, but providers don’t need to make these capabilities available for patients in real life. Today, two loopholes prevent patient access:
Continue reading “Improving patient access: small steps and patch-ups”
What’s a “Whitelist”?
As a follow-on to the last post about Direct messaging, I want to distinguish the Mass Medical Society’s vision of a “whitelist” from another concept that confusingly shares the “whitelist” moniker. Below, I’ll introduce two distinct terms and try to clarify the distinction:
“OR-gate whitelists” expand the communication pool
Mass Medical Society envisions a kind of per-physician “whitelist” that I’ll call an OR-gate whitelist. The basic premise of an OR-gate whitelist is that a physician can add any Direct address to her OR-gate whitelist via a UI in her EHR or HISP. By doing so, she’d be able to send secure e-mail to that address — regardless of CAs, trust bundles, or pre-existing local policy. An OR-gate whitelist acts like a logical “OR gate,” meaning that a message will be sent if institutional policy allows it, or if a physician’s personal OR-gate whitelist allows it. With OR-gate whitelists, physicians can send to any Direct endpoint in the world, full stop.
“AND-gate whitelists” restrict the communication pool
The current Massachusetts HIWay has a deployed a different kind of “whitelist” functionality that I’ll call an AND-gate whitelist. Mass HIWay maintains a state-wide AND-gate whitelist of acceptable Direct addresses to which HIWay users are allowed to send Direct messages. An AND-gate whitelist acts like a logical “AND gate,” meaning that a message will be sent only if institutional trust bundles allow it (i.e. the recipient’s cert is signed by a CA that the organization trusts) and the institution’s AND-gate whitelist allows it. So Mass HIWay’s state-wide AND-gate whitelist is a way to avoid allowing, say, “all eClinicalWorks users across the whole country” into the pool at once. Instead, access can be restricted to the intersection of two sets: “All eClinicalWorks users across the whole country” and “Users on the Mass HIWay AND-gate whitelist.”
MU2 is here, and with it: secure e-mail
As Meaningful Use 2014 EHRs come online this winter, clinicians across the country gain access the host of new features included in the MU 2014 Certification Requirements. In this post, we’ll dig into one of these features: EHR-based secure e-mail capabilities that operate using the “Direct Project” specification. (If you’re new to this world: when you hear “Direct Project,” you should think “secure e-mail for healthcare.”)
Continue reading “Direct Project: Secure e-mail in MU2”