Ensuring that the 21st Century Cures Act Health IT Provisions Promote Interoperability and Data Exchange

Kenneth D. Mandl, MD, MPH,1,2 Dan Gottlieb, MPA,2 Josh Mandel, MD,1,2,3

1. Computational Health Informatics Program, Boston Children’s Hospital, Boston, MA

2. Department of Biomedical Informatics, Harvard Medical School, Boston, MA

3. Microsoft Healthcare, Redmond, WA

The opportunity has never been greater to, at long last, develop a flourishing health information economy based on apps which have full access to health system data–for both patients and populations–and liquid data that travels to where it is needed for care, management and population and public health. A provision in the 21st Century Cures Act could transform how patients and providers use health information technology. The 2016 law requires that certified health information technology products have an application programming interface (API) that allows health information to be accessed, exchanged, and used “without special effort” and that provides “access to all data elements of a patient’s electronic health record to the extent permissible under applicable privacy laws.”

After nearly two years of regulatory work, an important rule on this issue is now pending at the Office of Management and Budget (OMB), typically a late stop before a proposed rule is issued for public comment. It is our hope that this rule will contain provisions to create capabilities for patients to obtain complete copies of their EHR data and for providers and patients to easily integrate apps (web, iOS and Android) with EHRs and other clinical systems.

Modern software systems use APIs to interact with each other and exchange data. APIs are fundamental to software made familiar to all consumers by Google, Apple, Microsoft, Facebook, and Amazon. APIs could also offer turnkey access to population health data in a standard format, and interoperable approaches to exchange and aggregate data across sites of care.

The Office of the National Coordinator of Health IT (ONC)-funded SMART on FHIR API specification enables apps to connect with EHRs in a standards-based way, giving users a frictionless way to choose their favorite apps. This property of substitutability defines a new form of interoperability. SMART leverages the Health Level Seven (HL7) Fast Health Interoperability Resources (FHIR) standard and has been implemented by the major EHR products. The SMART app gallery, and EHR-specific app stores such as Epic’s App Orchard and Cerner’s code App gallery host scores of app that connect to EHRs.

Two particularly intriguing uses of SMART are (1) Apple’s use of the API to connect its health app to hundreds of health systems enabling users to download copies of their health records to their smartphones; and (2) the Centers for Medicare and Medicaid’s implementation of “Blue Button 2.0”, enabling beneficiaries to connect apps to their healthcare financial data.

Because the specifics of the final rule matter greatly, we strongly encourage policy makers to attend carefully to a few key requirements which derive from the phrases “without special effort” and “all data elements.”

Expanded data access. ONC has proposed a set of standardized clinical data that will grow over time from the 2015-era “Common Clinical Data Set” to a forward-looking “US Core Data for Interoperability”. This kind of consistent, standards-based data set holds tremendous promise for the ecosystem. At the same time, standards can lag behind clinical practice and cutting-edge technology development, so the Cures Act goal of “all data elements” would be challenging to achieve through detailed clinical modeling standards alone. We should not allow the perfect to be the enemy of the good. We propose a three-pronged approach to meeting the Cures provisions for “all data elements”:

  1. Use standards that exist today. For example, FHIR “US Core” profiles cover the 2015 era Common Clinical Data Set, providing a common basis for communicating patient demographics, medidcations, conditions, lab results, vital signs, and more. These core data should be made available through APIs to provider- and patient-facing apps.
  2. Continue developing these standards over time. For example, efforts like HL7’s Argonaut Project are driving common support for new data types like clinical notes as a fast-moving 2018 roadmap. We should start building a community-maintained “profile backlog” to articulate and prioritize the most valuable data that haven’t yet been standardized.
  3. Enable flexible approaches to cover the gap between our well-standardized-and-growing “core data” definitions and the long tail implied by the Cures provision for “all data elements.” As one example to illustrate how EHR vendors could ensure that innovators have programmatic access to all of the clinical data accessible in the system: similar to the way vendors publicly document a subset of APIs today, they might expand this documentation to include database schema, tables, columns, and enumerations used to store complete clinical records.

This approach (use standards, develop standards, and cover the gap) would empower early adopters to develop cutting edge clinical integrations ahead of the standardization process, building experience to guide the standards process that follows.

Standard and ubiquitous APIs for patient facing apps, provider facing apps and population analytics. Our vision is that an app written once should run anywhere in the healthcare system. The availability of standardized APIs, ubiquitously implemented across care settings, is essential to driving down the “special effort” that is still typically required to create, distribute and use health apps.

  1. Standardize APIs for apps. The SMART Health IT (a.k.a. SMART on FHIR) specification is sufficiently mature to be considered as an industry standard for launching and authorizing apps in an EHR or patient portal. It is in widespread use in clinical settings, has achieved consensus through the Argonaut process, is implemented in EHR products, and its core elements are being incorporated into the next release of the FHIR standard.

While the SMART-based app integration focuses on one‐patent‐at‐a‐time access to health system data, population level data export is critical for value‐based care, postmarket surveillance, quality improvement, and clinical research. The API should enable a user or an app to specify export of all EHR data or EHR data on defined cohorts at the discretion of the data owner. Under ONC funding, a standard for bulk data export in a FHIR‐formatted flat file has been proposed and the Argonaut implementation group is working to pilot it in 2018.

  1. Allow multiple pathways to register apps for connection to EHRs and other HIT. As more EHR vendors build support for standards-based apps, developers are discovering that they need to independently register each new app with each vendor and complete a set of on-boarding, review, or “vetting” steps before users are able to install the app and authorize a data connection. The app registration and vetting landscape is evolving quickly as vendors create developer programs, launch partnerships, and build out their own app marketplaces. App vetting procedures review and assess critical aspects of integration including security, usability, and business/privacy practices and offer value to end-users, who expect a clean, safe, experience of choosing, installing, and running apps.

Nonetheless, we have observed that these vetting practices can cause friction for some use cases and believe it is too early to define a “one size fits all” standardized app vetting process.  As such, we propose an “escape hatch” in the form of an at your own risk principle, by which provider organizations and individual patients should be able to accept the risk of connecting an un-vetted app to their own data without vendor review. While many apps will follow a conventional path of registration and vetting, this option provides a route to ensure that all apps, even small-scale apps (e.g., one-offs produced by individual tinkerers, open-source developers, research efforts) can reach visibility and commercial viability within the real-world clinical landscape, and that providers have the opportunity to select any apps of their choice.

  1. Ownership terms. App developers should have the option of retaining all intellectual property related to the app, regardless of how the app connects to the EHR and which underlying EHR APIs the app consumes.
  2. Maintain free registration of apps for patients. As required now under Meaningful Use Stage 3, patients should always be able to connect apps of their choice, without cost.
  3. App connections should be long lasting, when desired. In other words, the user should not need to reauthorize the app to the system each time data is accessed. This property will enable apps to perform functions on behalf of patients and providers, without special effort (for example, checking periodically for new lab results).

Summary. We are so pleased that ONC has and the OMB have gotten to the is stage in which a proposed rule is pending at OMB. We are on the precipice of creating a national-scale apps model for health, based on an API that promotes interoperability and data exchange via substitutable apps. The simple imperatives we enumerate above, could reshape the health IT industry by providing a channel for innovators to distribute and/or sell their software applications by enabling customers to select and integrate EHR-connected apps as easily as they do for smartphones. As the final proposed language implementing the 21st Century Cures Act API provisions is reviewed and prepared for release is decided, we encourage policy-makers to keep all eyes on this prize.

This blog has been cross posted at The Health Care Blog.

Push Button Population Health Data: Extending the HL7 FHIR Standard to Support Bulk Data Export

Activities such as managing population health, delivering value-based care, and conducting discovery science require access to large population data sets. The existing FHIR and SMART APIs work well for accessing small amounts of data, but large exports perform poorly, requiring an impractical number of API requests to be issued serially. By adding asynchronous primitives to FHIR and defining an export operation, the Bulk Data API enables secure integration of third-party, externally-hosted applications into diverse EHR and data warehouse environments.

On behalf of the ONC, The Boston Children’s Hospital Computational Health Informatics Program and SMART hosted a meeting in December 2017 to discuss standardizing bulk data exports from EHR systems and data warehouse environments. This meeting brought together key stakeholders from across health care, including the Director of the Office of the National Coordinator for Health Information Technology (ONC) and other members of the ONC staff, as well as representatives from payers, health systems, EHR vendors, and other health technology innovators.

A summary report is now available:

Also, get involved in the ongoing, early stage, FHIR Bulk Data API Project by reviewing the draft specification and joining the discussion group!

SMART at HIMSS 2018!

All times are PST. Session schedule may change – check back for updates.

  • Tuesday (3/6)

    • FHIR for Bulk Data
      Dan Gottlieb, Senior Technical Lead, SMART Health IT Project
      Learn about an exciting new effort by SMART and HL7 to bring the FHIR standard to bear on the challenges of bulk-data export.
      1:00 – 1:30pm | HL7 – Booth 5623
    • Sync for Science and the CMS Blue Button on FHIR API: Claims Data for Research
      Josh Mandel, Health IT Ecosystem Lead, Verily; David Kreda, Healthcare IT Designer and Consultant; Carly Medosch, Program Analyst, CMS
      2:00 – 3:00pm | CMS Booth #10110
    • SMART on FHIR: Building apps that integrate with clinical systems through open standards
      Dan Gottlieb, Senior Technical Lead, SMART Health IT Project; Josh Mandel, Health IT Ecosystem Lead, Verily
      Learn how SMART Health IT’s open source, standards-based technology platform enables innovators to create apps that run seamlessly and securely across the healthcare ecosystem.
      3:30 – 4:15pm | HIMSS Developer Innovation Lab (Hall G, Booth 9900-DL)
  • Wednesday (3/7)

    • Sync For Science Scientific Session
      Josh Mandel, Health IT Ecosystem Lead, Verily; David Kreda, Healthcare IT Designer and Consultant; Teresa Zayas Caban, Chief Scientist, ONC
      In this session, the Sync for Science team will sit down with the research community to talk through use cases, challenges, wish lists, and pragmatics of working with EHR data.
      10:00 – 10:45am | The Venetian, Room Zeno 4601
    • Argonaut Project Town Hall Meeting
      Micky Tripathi, President & CEO, MAeHC; Aneesh Chopra, President, CareJourney; Ryan Howells, Principal, Leavitt Partners; Josh Mandel, Health IT Ecosystem Lead, Verily; Dan Gottlieb, Senior Technical Lead, SMART Health IT Project
      The town hall will cover 1) Argonaut Project 2017 deliverables and 2018 work plan, 2) CARIN Alliance consumer directed exchange trust framework updates and TEFCA alignment, 3) SMART and ONC efforts to accelerate bulk data access via FHIR APIs.
      5:30pm – 6:30pm | Hall G, Booth 11955ET | RSVP Here
  • Thursday (3/8)

    • Sync For Science Demonstration
      Josh Mandel, Health IT Ecosystem Lead, Verily; David Kreda, Healthcare IT Designer and Consultant; Teresa Zayas Caban, Chief Scientist, ONC
      In this session we’ll review the consumer workflow, the underlying technologies and the regulatory environment that support Sync for Science, and describe upcoming extensions to support new data types.
      10:00 – 10:45am | The Venetian, Room Zeno 4601
    • CDS Hooks: Integrating decision support at the point of care
      Josh Mandel, Health IT Ecosystem Lead, Verily; David McCallie, Senior Vice President for Medical Informatics, Cerner
      We’ll review the technology, clinical use cases, standards development, and real-world implementation experience for the emerging CDS Hooks specification.
      11:40am – 12:10pm | HL7 – Booth 5623
    • FHIR for Bulk Data
      Dan Gottlieb, Senior Technical Lead, SMART Health IT Project
      Learn about an exciting new effort by SMART and HL7 to bring the FHIR standard to bear on the challenges of bulk-data export.
      1:00 – 1:30pm | Hall G, Booth 9900-DL

Response to ONC’s proposed Trusted Exchange Framework and Common Agreement

Next week is the final opportunity for public comment on the ONC’s proposed Trusted Exchange Framework and Common Agreement. I’ve prepared a set of comments and recommendations that focus on the scope and mechanics of individual access, including technical standards, security requirements, identity proofing, authentication, and authorization.

Given the importance of health data exchange to the SMART Health IT community, I’m sharing the full letter and 15 recommendations here in PDF.

Can Apple Take Healthcare Beyond the Fax Machine?

(A version of this blog was published by CNBC)

January 30, 2018

Ken Mandl (Twitter @mandl)

Despite spectacular advances in diagnostic imaging, non-invasive surgery, and gene editing, healthcare still faces a lackluster problem: many patients can only get health records from their doctor if the fax machine is working. Even when records are stored electronically, different chunks of every patient’s health information sit in the non-interoperable, inaccessible electronic record systems in different doctor’s offices.  

Anyone who needs her medical files gets them either printed or faxed, or has to log on into separate portals for each doctor and hospital, and even then getting view-only access. View-only apps can’t access data to help patients share information with family and healthcare providers, make decisions, monitor disease, stay on course with medications, or just stay well.

On the positive side, this is changing, sort of. Using the iPhone Health app, patients will soon be able to download and view health records on their phones. On the one hand, don’t get too excited–it will initially only work for patients at a handful of institutions, Android users are still out in the cold, and the data available will be limited. And, some dismiss the impact of Apple’s move because of others’ failures to give patients control of their records.

However, Apple’s move is a decisive and consequential advance in patients’ struggle to get a copy of their own health data. Apple wisely chose to use open, non-proprietary approaches that will float all boats–even for Android users.  

Every patient deserves a ‘bank account’ of her health data, under her control, with deposits made after every healthcare encounter. After my colleagues and I demonstrated an open, free version of a “bank account” to companies in 2006, Google and Microsoft launched similar personally controlled health records — GoogleHealth and Microsoft Healthvault. Walmart and other employers offered our version, Indivo, as an employee benefit. Unfortunately, even these industry giants couldn’t shake loose data from the proprietary computer systems in doctors’ offices, or make the case to patients that curating the data was worth the effort.

But 12 years later, Apple’s product enters healthcare under different circumstances.  A lot more patient data is electronic after a $48 billion federal investment in promoting the adoption of information technology to providers. But those products, mostly older software and purchased at enormous expense, still don’t promote record sharing with doctors or patients.

Recognizing this unacceptable limitation and having received a generous grant comprising a tiny fraction of that federal investment, our team created SMART on FHIR. SMART is an interface to make doctors’ electronic health records work like iPhones do. Apps can be added or deleted easily. The major electronic health record brands have built this interface into their products.

Apple uses SMART to connect the Health app to hospitals and doctors offices. The good news for patients, doctors, and innovators is that Apple chose a standardized, open connection over a proprietary, closed one. This approach lets any other app, whether running on the web,  iPhone, or Android, use that very same interface to connect.

So Apple will compete on value and customer satisfaction, rather than on an exclusive lock on the data. Does Apple’s approach help Americans trying to stay well or manage their conditions? Yes. But only with follow-through by Apple, health systems, technology companies, patient groups, policy makers, and government regulators. The emerging ecosystem’s nuances must be appreciated.

First of all, the floodgates for patient information are at least a crack open and will be very hard to close. As patients gain access to their data, they will recognize it is incomplete and feel frustrated it’s not available everywhere. But, patients in need will drive demand for data access in their role as health consumers.

Secondly, the government is effectively using law and regulations to compel an open interface. By selecting SMART on FHIR, Apple and its healthcare launch partners mark the importance of standardization. A uniform approach is critical for scale. Imagine if every electrical product required a differently shaped 120V outlet. Understanding this, Google, Quest Diagnostics, Eli Lily, Optum, and many other companies are using the same interface to plug into healthcare.

Thirdly, Apple’s first version of health records brings data onto the phone, but from there, like the portals many patients are already familiar with, the data are still “view-only.”  In 2009, I had the chance to meet with Apple’s rockstar Bud Tribble and talk about how the iPhone could serve healthcare. We concluded that crucial data–like the medication list–had to be as easy for iOS developers to use in their apps as contacts and location are now.  I would not be at all surprised if this is the next step in Apple’s journey–making the health records available to iPhone app developers. Here too is an opportunity to chose open interfaces, and to allow patients to export the data to another device.

Lastly, competition in healthcare IT is hot. Amazon, Google, Apple and Facebook all have healthcare divisions.  Apple’s extraordinary hardware, including sensors in the phone and watch, will monitor patients at home.  Google’s artificial intelligence will lead doctors and patients to diagnoses and decisions.  Amazon is rumored to be eying pharmacy management. Facebook has sifted through posts to detect and possibly intervene when users may be suicidal.

There are so many opportunities to compete. Locking up a patient’s data should never be one of them.  

Ken Mandl, MD, MPH directs the Boston Children’s Hospital Computational Health Informatics Program and is the Harvard Medical School Donald A.B. Lindberg Professor of Pediatrics and Biomedical Informatics.

Draft Model RFP Language for Purchasing Extensible Health IT

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.


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

New Report On Connected Apps in Healthcare

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.

Findings include:

  • 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”

We’ll Be At HIMSS!



  • Monday, February 20th
    • 1:00pm – 2:00pm / Quest Diagnostics Panel (room 203C)
    • 1:40pm – 2:10pm  / Introduction to SMART on FHIR at HL7 booth (#943)
    • 3:00pm – 3:30pm / SMART App Gallery 2.0 Beta Launch at Federal Health IT Pavilion (booth #230)
  • Tuesday, February 21st
    • 11:00am – 11:45am / HSPC Interoperability Showcase Demonstration (booth #9000)
    • 2:30pm – 4:30pm / Argonaut Roundtable (room 240ABC)
    • 4:20pm – 4:50pm / Introduction to SMART on FHIR at HL7 booth (#943)
  • Wednesday, February 22nd
    • 11:40am – 12:10pm / Introduction to SMART on FHIR at HL7 booth (#943)

21st Century Cures Act makes APIs in EHRs the law


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

Vital Directions for Health and Health Care


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