FHIR is laying a framework for digital disruption to occur. A big part of FHIR’s popularity is that it’s vendor-neutral and free to use, which allows innovators to do things that couldn’t easily be done before. […] The SMART on FHIR app platform and app gallery are great examples. Think of SMART on FHIR like the app store on a smartphone. Some of the apps are designed for physicians to use, such as the Growth Chart app developed by Boston’s Children’s Hospital. The app plots a child’s height and weight against growth charts published by the World Health Organization and U.S. Centers for Disease Control and Prevention (CDC) so that physicians can track a child’s growth over time and communicate this to the child’s caregivers.
Other apps in the SMART on FHIR gallery are patient-facing, such as the ClinDat application, which makes it easier for rheumatoid arthritis patients to document which joints are normal, tender, or swollen. These data are captured electronically and sent back to the medical record in real-time to support the clinical care patients receive. The beauty of SMART on FHIR is the apps are vendor neutral and can be ‘plugged-in’ to EHRs and other tools used on multiple devices (particularly mobile devices) that are already integrated into clinicians’ workflows.
I’m deeply excited about the Precision Medicine Initiative. With Cohort Program grant deadlines approaching in a matter of hours, I thought it might be time for a brief distraction with this blank verse reflection on the funding opportunity announcements:
Precision Medicine Initiative:
a blank verse summary and overview.
Recruit a million volunteers across
the country, spanning age, geography,
ethnicity and race, the ill and well,
a cohort of participants engaged
as partners for a long-term effort to
transform our understanding of the links
that bind genetics, our environment,
disease and health: a cohort big enough
for wide association studies of
diverse and non-prespecified effects.
We’ll weave a network joining scientists
from academia and industry,
and someone’s loft or basement or garage
to generate hypotheses, compare
results and methodology, and share
interpretations with participants.
We’ll gather physical exam reports
from EHRs and clinics, collate SNPs
and genomes, track activity from phones
and wearables, and questionnaires to learn
as much as each participant will share.
And how to organize a study with
The cast of characters includes at least
* Enrollment Centers (seven) to recruit
one hundred thousand people each, and build
a pipeline for transmitting data to…
* Coordinating Center (one) composed
of interlocking Cores for Data (with
facilities to scale analysis),
Research Support (including phenotype
selection algorithms, software tools,
and science help desk), plus a centralized
Administrative Core to oversee
the project and collaborations with…
* Participant Technologies, to build
a suite of mobile applications that
engage participants through questionnaires,
acquire sensor data (GPS
and wearables) and share research results.
* A central Biobank for specimens
collected from the cohort, offering
facilities to handle, process, store,
prepare, and ship to labs upon request.
A cohort of one million volunteers
will chart a course across the next five years.
Jump in and grab the helm — but science steers:
discoveries ho! Let’s sail to new frontiers.
We’re in a Meaningful Use Stage 3 comment period!
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.
Last weekend I got an email asking whether OAuth 2.0 is ready to deploy for healthcare. Given SMART’s use on OAuth 2.0, I think so! Here’s the exchange…
I realize that the big news is the NPRMs being released, but one thing that I have been interested in is the big push for using OAuth 2.0 with newer standards (primarily FHIR related), and the known vulnerabilities in OAuth2.0.
I realize that HL7’s security Workgroup has experts and the other organizations consult experts (and I’m certainly not questioning the work they have done in this area) , but considering we are talking about healthcare data – it seems that it might have raised at least a few eyebrows and would have been addressed more openly.
Below are just a few links that explain. I do not know how many – if any – of these vulnerabilities have been resolved since these were printed.
I just thought this was interesting…
SMART Platform (www.smarthealthit.org) is a project that lays the groundwork for a more flexible approach to sourcing health information technology tools. Like Apple and Android’s app stores, SMART creates the means for developers to create and for health systems and providers to easily deploy third-party applications in tandem with their existing electronic health record, data warehouse, or health information exchange platforms.
To deploy SMART-enabled applications, health systems must ensure that their existing health information technology infrastructure supports the SMART on FHIR API. The SMART on FHIR starter set detailed below lists the minimum requirements for supporting the API and SMART-enabled applications. You may wish to augment this list of minimum requirements with suggestions from the Add-On Functionality listed depending on the types of applications your organization wishes to deploy.
Continue reading “RFP Language for Buying SMART-Compatible HIT”
David Kreda, SMART Translation Advisor
Joshua Mandel, SMART Lead Architect
Some readers of our JAMIA paper “Are Meaningful Use Stage 2 certified EHRs ready for Interoperability?” have wondered if we were insinuating that C-CDAs are all but useless because of their heterogeneity and other defects.
We did not say that.
Continue reading “C-CDAs — What are they good for?”
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).
Apple may have just tightened privacy requirements for developers who build apps on its HealthKit platform. But a broad assessment of the industry, published online last week in JAMIA, found that the iTunes and Google Play stores have a long way to go before such policies are readily discoverable and digestible to app users.
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.
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”