We’re in a Meaningful Use Stage 3 comment period!
The Meaningful Use Stage 3 final rule was published on October 16th, and came with a 60-day open comment period. Anyone can submit a comment here.
Patient API access is a critically important MU3 guarantee
I want to share a comment I’ve submitted that deals with a critically important (and strongly worded) guarantee that MU3 provides: a patient’s right to access data through an API, using “any application of their choice”. This is a critical issue because this guarantee would open up data access in a very wide, very real way — but it also comes with a host of security and privacy concerns (as well as business concerns) that will cause provider organizations to push back against it.
Below is my comment, verbatim. I’d love to hear your thoughts @JoshCMandel.
Josh’s Comment on Patient API Access
The following language pertaining to patient access must be be clarified to ensure it retains its intended potency:
The provider ensures the patient’s health information is available for the patient (or patient-authorized representative) to access using any application of their choice that is configured to meet the technical specifications of the API in the provider’s CEHRT.
The key question here is: which parties need to agree that an app is (so to speak) “okay to use”?
The regulatory intent appears to support the idea that patients make this decision, choosing among all apps that have been configured to work with the provider’s EHR. But what does it take for an app developer to configure an app to work with the provider’s EHR? Beyond technical details, is it okay for a provider to tell an app developer something like:
1. “Sorry, your app sounds good and useful, but we don’t choose to make it available to our patients.”
2. “Sorry, your app might be useful but it’s duplicitive: we already offer a similar functionality to our patients through another app, or through our own portal.”
3. “Sorry, your app is designed to help patients move away from our practice by seeking a second opinion, and that’s against our business interest.”
4. “Sorry, your app offers what we consider to be questionable clinical advice.”
5. “Sorry, we don’t believe your app will do an adequate job of protecting patient data.”
CMS should clarify that providers may not use these excuses to prohibit apps from becoming available to patients. If a provider can reject apps for policy reasons like the ones described above, this will lead to an environment that fails to provide patients a right to access their data in a useful way.
But of course some of the concerns above are important, especially as they begin to touch on clinical utility and data protection. CMS should clarify that protection comes, ultimately, from allowing patients to make informed decisions about which apps to use. It is reasonable for providers to share warnings, or endorsements, or to ask questions like “Are you sure?” with specific confirmations, or to assign apps to different levels of trust or approval — but a provider must not prohibit a patient from using a specific app (just as they must not refuse to fax a patient’s data to a patient-specified phone number).
One important step in ensuring this kind of access will be clarification about who is responsible for a data breach in the case where a patient has approved an app to access EHR data. The Office for Civil Rights should issue a clear statement that providers are not responsible for what happens downstream, after healthcare data are shared with a patient-selected and patient-authorized app. By analogy, we expect providers to share healthcare information by fax to any phone number that a patient identifies, as long as the patient has authorized the transmission; we should look at sharing data with apps the same way. This kind of clear statement from OCR will be a necessary step to ensure that providers do not perceive conflicting obligations.