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:
- 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
- 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:
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.
- 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.
- 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.
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)
- 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
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.
In an evaluation developed in partnership with SMART and funded by the Office of the National Coordinator for Health Information Technology (ONC), KLAS Research spoke with clinical leaders at nearly 50 healthcare organizations about how they select and use clinical apps today, what they would like to see in the future, and the concerns they have around adopting apps.
- Around half of the healthcare organizations interviewed use apps at the point-of-care.
- Looking forward, many providers are interested in purchasing or developing apps around patient engagement, followed by EHR data visualization, diagnostic tools and decision support tools.
- Usability is the most important factor healthcare organizations consider when purchasing an app, followed by cost, clinical impact and integration with existing systems.
- Pilot programs and demos represent providers preferred way to evaluate apps, with peer recommendations, web content and video demonstrations also being popular.
- Privacy and security is by far the biggest concern around adopting apps, although app credibility, concerns regarding ongoing maintenance, and the need for integration with existing systems are also high on the list.
The role of apps in healthcare is growing, with many organizations looking to third-party vendors to supply niche solutions that improve patient care and organizational efficiency.
Increasing adoption of the SMART and FHIR application programming interfaces (APIs) by EHR vendors and health systems is streamlining the process of connecting these apps to clinical systems, and strong regulatory support requiring APIs in certified health IT is expected to continue driving this trend. With app discovery tools, such as the SMART App Gallery, making it easier for healthcare providers to find and evaluate apps, there is a bright future for connected apps in healthcare.
View the full report, “Connected Apps in Healthcare 2017: A Look at Trends and Provider Attitudes in a Growing Market”
One aim of the 21st Century Cures Act recently passed by Congress is to make digital health data more accessible, emphasizing the use of APIs in healthcare to increase EHR interoperability and improve patient records matching. Aligning closely with the SMART Health IT focus on creating a app ecosystem for healthcare, the act states that a year from now, open APIs will be necessary for EHR system certification.
“… that the entity has in place data sharing programs or capabilities based on common data elements through such mechanisms as application programming interfaces without the requirement for vendor-specific interfaces;
[…] publish application programming interfaces and associated documentation, with respect to health information within such records, for search and indexing, semantic harmonization and vocabulary translation, and user interface applications; and
[…] demonstrate to the satisfaction of the Secretary that health information from such records are able to be exchanged, accessed, and used through the use of application programming interfaces without special effort, as authorized under applicable law.”
Read the full document at 21st Century Cures Act
About the Initiative
Guided by an 18-member steering committee, the National Academy of Medicine (NAM) has called on more than 100 leading researchers, scientists, and policy makers from across the United States to provide expert guidance on 19 priority focus areas for U.S. health policy. The resulting collection of discussion papers is organized around three overarching goals for the United States: better health and well-being; high-value health care; and strong science and technology.
“As the country orients toward alternative payment models, measuring individual health outcomes and disparities among vulnerable populations is crucial for driving innovation toward outcomes that matter most to individual lives.”
“Simply building APIs into EHR products so that data can be called by external applications will improve the current state. But the most important goal is that—as in an “app store”—an app written once will be able to run anywhere in the health care system and that a decision support service will be able to be created once and be called from any care point in the system. “
Read the Discussion Paper On Information Technology Interoperability and Use for Better Care and Evidence
President Obama’s Cancer Panel defines connected health as “the use of technology to facilitate the efficient and effective collection, flow, and use of health information.” In their 2016 report to the President, the panel highlights the benefits of using the SMART On FHIR open-access API for development of health applications.
“The Precision Cancer Medicine (PCM) app was designed to present patients’ genomic test results to oncologists in real time as a component of clinical practice, as well as provide links to external knowledge bases that otherwise would be unavailable through the native EHR system. PCM was piloted at Vanderbilt University and integrated into that institution’s EHR system. However, because the app was developed based on an open-access API (Substitutable Medical Applications and Reusable Technology, or SMART) and uses the emerging HL7 Fast Healthcare Interoperability Resources standard, it could easily be deployed for other compatible EHR systems.”
“The Panel urges all stakeholders—health IT developers, healthcare organizations, healthcare providers, researchers, government agencies, and individuals—to collaborate in using connected health to reduce the burden of cancer through prevention and improve the experience of cancer care for patients and providers.”
Improving Cancer-Related Outcomes with Connected Health: A Report to the President of the United States from the President’s Cancer Panel. Bethesda (MD): President’s Cancer Panel; 2016.
A web-based version of this report is available at: https://PresCancerPanel.cancer.gov/report/connectedhealth
As part of a broader survey of 1,300 physicians covering digital health tools, the SMART Health IT Project and the American Medical Association collaborated on a set of questions to better understand how providers wish to discover, evaluate and purchase apps that connect with their EHR system.
One important finding for app creators is that 81% of physicians ranked integration with their EHR as a very important or important requirement for digital health tools. Additionally, more than half of the physicians indicated that they are extremely likely or very likely to purchase apps that extend their EHR system’s capabilities and securely integrate into the EHR workflow.
Download the full report at: https://www.ama-assn.org/sites/default/files/media-browser/specialty%20group/washington/ama-digital-health-report923.pdf
We’re looking for a senior developer to work full time on the open source SMART on FHIR project!
The Boston Children’s Hospital Computational Health Informatics Program (http://www.chip.org), a Harvard Medical School affiliate, is seeking an experienced full stack web developer to join the SMART Health IT team.
The platform is REST-based, incorporates OAuth2 and related technologies on the security layer and can use JSON and XML serialization formats. The team you will be joining writes services, applications and frameworks for web and mobile platforms in various programming languages and likes to give the latest and greatest technology a try.
The ideal candidate:
- Has a Bachelors or Masters in Computer Science or equivalent industry experience, plus at least 3 years of experience in real-world software development
- Lives and breathes full stack web development using open-source development and tools, can discuss the pros and cons of various web application toolkits
- Writes quality code: source control, testing, and clear documentation are all musts
- Has experience with at least one web framework
- Is comfortable doing basic system administration in a Linux environment
Bonus points if:
- You have experience with Python or the JVM
- You’re familiar with both statically and dynamically typed languages
- You can share a link to your work on GitHub
Please submit a cover letter describing your background, a resume and a code sample that represents your best work to: email@example.com
Today is the last day of the comment period for CMS’s MACRA and MIPS proposed rules. Below, we share a comment we submitted promoting the use of APIs for patient and provider access alike.
CMS states that priorities for “Advancing care information” are patient engagement, electronic access, and information exchange:
> These measures have a focus on patient engagement, electronic
> access and information exchange, which promote healthy behaviors
> by patients and lay the ground-work for interoperability.
… but nothing in CMS’s proposed MIPS measurement strategy in fact places an emphasis on these goals. Consider patient API access through third-party apps, which falls squarely in the intersection of these focus areas. Under the proposed scoring rubrics, a provider can earn 100% full marks on “advancing care information” while making API access available only to a single patient!
CMS should take actions to ensure that the “priority goals” are in fact met. One clear way to fix this issue would be to define a scoring function where patient API access is a hard line. For example, MIPS could require providers to offer API access to all patients in order to be eligible for the “base score”. This special-priority treatment is already given to one objective (“Protect Patient Health Information”); it should be extended to other priority items including patient API access. Otherwise, these “priorities” can, in fact, be entirely ignored by MIPS EPs, given the elaborate structure of bonus points and the “ceiling effect” of earning just 100 points out of a possible 131 points.
CMS should also add an explicit requirement for APIs that be used by healthcare providers as well as patients. Current meaningful use requirements focus on patient API access; MACRA should expand access to clinicians as well. To be concrete in advancing interoperability, MIPS could award points for clinicians who run at least one third party application against their EHR data (for example, see the SMART on FHIR open app platform specifications at http://docs.smarthealthit.org/) and at least one third party decision support service (for example, see the SMART CDS Hooks specifications at http://cds-hooks.org/).
Following a competitive process, the U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology has awarded SMART Health IT, a project of Boston Children’s Hospital Computational Health Informatics Program and the Harvard Medical School Department of Biomedical Informatics, the “Discovery Infrastructure for Clinical Health IT Apps” funding opportunity.
Under this agreement, SMART Health IT will study the healthcare app ecosystem, enhance the SMART App Gallery (https://gallery.smarthealthit.org) with additional functionality, and expand the sample data available to users and developers through the SMART Sandbox. To achieve these goals, SMART Health IT has partnered with organizations that include FHIR.org, HL7, the American Medical Association, American Nursing Association, as well as consultants from world-class market research firms and design companies.