Ebola in the United States: EHRs as a Public Health Tool at the Point of Care

Oct21

screenshot of PDF

What if, in the midst of a crisis, the CDC could distribute a SMART app to emergency departments as easily as a software developer submits an app to the Apple App Store?

JAMA Article (free)

RFP Language for Buying SMART-Compatible HIT

Oct06

SMART Platform (www.smartplatforms.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.

This document is intended as a resource for providers and health systems as they draft Request for Proposals (RFPs) and negotiate with their HIS vendors for added functionality. It has multiple authors from across the SMART team and its advisors.  Feedback is welcome.

SMART on FHIR Starter Set

The vendor must support the SMART on FHIR platform, a vendor agnostic API that allows third-party developers to build external apps and services that integrate with the vended product.

At a minimum, the vendor product should include the following components in order to support SMART on FHIR and SMART-enabled applications:

Data Access

  • Provide automated, standards-based, read-only access to:
    • a well-defined set of real-time discrete data (represented in FHIR, with appropriate profiles and vocabularies)
    • automated bulk export of standards-based data

Data Manipulation

  • Write structured data from third-party apps back to the organization’s EHR and where relevant, a data warehouse, using the FHIR REST API to communicate data including:
    • free-text clinical notes

Standards-Based App Authorization

  • Protect data and identity endpoints with standards-based authorization mechanisms (OAuth2)

Identity Management

  • Act as as standards-based Identity Provider using OpenID Connect. This ensures that users can authenticate to plug-in apps using single-sign-in via their existing EHR credentials.
  • Act as a standards-based relying party to a customer-selected Identity Provider using OpenID Connect. This ensures that users can sign into the EHR using an external, hospital-supplied single-sign-on account.

Workflow

  • Support standards-based embedding of external application UI (HTML5). This ensures that app developers can build Web apps, and these apps can run directly inside of the EHR.
  • Support the launch of external applications in the clinician’s workflow (this is not limited to the EHR, and should include non-EHR integrated tools such as smart phones and tablets). For example, a clinician that has opted to use a third-party-developed native iPad app to visualize a patient’s BMI over time can seamlessly use the application alongside the EHR via single-sign-on.
  • Support notifications to and from running applications. For example, an embedded app can notify the EHR when the user is “done” with it.

Add-On Functionality

The provider organization may also want to consider the following additions to its RFP depending on the types of applications it wishes to develop and run in the future.

Data Access

  • Provide automated access to bulk export of vendor-specific data (complete representation of all data).

Data Manipulation

  • Write structured data from third-party apps back to the organization’s EHR and where relevant, a data warehouse, using the FHIR REST API to communicate data including:
    • medication prescriptions
    • lab and diagnostic imaging orders
  • Support the dependent transactions necessary to ensure that actions completed by third-party applications using the API are valid in the EHR and data warehouse.

Standards-based App Registration

  • Support Auth Dynamic Registration (with access controlled by the customer) so that third party apps can perform automated, standards-based registration.

Context-Specific Service Hooks

  • Support the ability to call an external standards-based service in specific workflow steps, such as:
    • new prescriptions
    • new lab orders
    • new imaging studies

Intellectual Property

The IP of any app integrated through the SMART on FHIR API belongs to the author and not the vendor.

Custom SMART on FHIR Extension to a Proprietary API

Should a vendor neglect to provide SMART on FHIR natively, the client has the right to provide a custom extension to the vendor’s API. The ownership of the IP for the custom extension is negotiable between the client and the vendor, but the ownership of the app using the custom extension belongs to its author.

C-CDAs — What are they good for?

Sep16

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.
Read more

Certification/MU tweaks to support patient subscriptions

Sep15

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).

Read more

Health App Privacy Policies Still Wild Frontier

Aug29

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.

Improving patient access: small steps and patch-ups

Aug26

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:
Read more

SMART Advice on JASON (and PCAST)

Aug11

As architect for SMART Platforms and community lead for the Blue Button REST API, I’m defining open APIs for health data that spark innovation in patient care, consumer empowerment, clinical research. So I was very pleased last month at an invitation to join a newly-formed Federal Advisory Committee called the JASON Task Force, helping ONC respond to the JASON Report (“A Robust Health Data Infrastructure”).

We’re charged with making recommendations to ONC about how to proceed toward building practical, broad-reaching interoperability in Meaningful Use Stage 3 and beyond. Our committee is still meeting and forming recommendations throughout the summer and into the fall, but I wanted to share my initial thoughts on the scope of the problem; where we are today; and how we can make real progress as we move forward.

Read more

It’s About Time: Open APIs Finally Burst onto Healthcare’s Sluggish Scene

Jun09


Nuviun Blog, June 9, 2014 — Sue Montgomery
In the midst of the struggles that we face with interoperability, efforts that support open API use may well hold the keys to the HIT Kingdom…
READ MORE >

Advisory Committee Kickoff a Success

Jun09

The SMART Advisory Committee had a high-energy kickoff meeting on May 15. Below are some scenes from the day, which featured presentations by Joshua Mandel and Clayton Christensen as well as demonstrations of apps to be deployed in the near future.
Read more

Forbes Adds to Advisory Committee News Coverage

May29

Today Forbes published Who’s Who Of Health Care Join Forces For SMART Technology, the latest in recent news coverage of the SMART Advisory Committee launch.

AC-inthenews_5

Other pieces include:
Read more

Sidebar