We’re updating our model RFP language to reflect the changes in the health IT landscape over the past few years, and drafted the version below for community input. Our goal is to finalize this in September – please review and post any suggestions or feedback to the SMART discussion group at https://groups.google.com/forum/#!forum/smart-on-fhir .

RFP Language for Purchasing Extensible HIT

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.

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

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 through the FHIR API and FHIR data models (resources) to:
  • a well-defined set of real-time discrete data (including support for the API parameters and resources described in the Argonaut Implementation Guide)
  • free-text clinical notes

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 (including the OAuth2 profiles described in the Argonaut Implementation Guide).
• Provide access to data endpoints with an approach that does not require user intervention subsequent to the initial setup such as the method described in the draft SMART Backend Services Profile (http://docs.smarthealthit.org/authorization/backend-services/) Provide capability to restrict this access to a specified set of patients (roster).
• Enable Health System to connect any any third‐party app of their choice that is conformant with the API without pre‐registering the app with HIT Vendor.
• Enable patients to connect any third‐party app of their choice that is conformant with the API without pre‐registering the app with HIT Vendor through the OAuth Dynamic Registration protocol.
• Provide OAuth refresh tokens with a duration of one year to patient and provider facing apps that support the SMART Client Secret profile.

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 or patient portal 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 or patient portal 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.

Bulk Data Export

• Provide automated access to bulk export of data (complete representation of all data in the MU Common Clinical data set as well as free text notes) using a method like the SMART Flat FHIR draft proposal (http://docs.smarthealthit.org/flat-fhir)

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.

Context-Specific Service Hooks

• Support the ability to call an external standards-based service in specific workflow steps, through the CDS Hooks specification, including:
  • opening a patient record
  • 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.