Uncle Sam to Healthcare IT: Voluntary Guidelines for Open APIs Not Quite So Voluntary

Governments around the world often encourage healthcare software vendors to make use of international data standards for electronic health records so that patient healthcare data can be easily moved between various proprietary systems. Until recently, the US Federal Government has interpreted this imperative into strongly-worded encouragement that healthcare IT vendors provide APIs to ensure that electronic records can interoperate between healthcare providers. But recent moves by the Department of Health and Human Services and its agencies now suggest that this compliance has become mandatory, at least for those healthcare software providers who want their products to be used in federally funded Medicare/Medicaid programs. The gotcha is that few if any healthcare IT vendors can afford to exclude themselves from the Medicare/Medicaid ecosystem which in turns means that what was once billed as a voluntary program is now essentially an industry-wide regulation. 

Speaking with ProgrammableWeb, Director, Office of Standards and Technology in the Office of the National Coordinator for Health Information Steve Posnack confirmed that for health software providers to be certified under the 2015 Edition requirements (which come into force in 2018), they must document and publish an open API that can enable patients to pull their data from one health records system and provide it to any app or other software service that they want. Funded Medicare/Medicaid programs are required to only use providers that have been certified under the requirements, which amounts to making APIs a mandatory requirement for all health software used in U.S. Government-funded healthcare.  

While there has been some resistance in the past to making APIs mandatory and enforceable in federal health legislation, Posnack argues that 2018 is a reasonable timeline to expect software providers to meet the requirement. The move comes as health funding systems around the world are changing toward a more collaborative approach to healthcare and as citizen literacy around their right to their own health data grows. 

“There is a convergence of policy interest and industry maturity factors,” said Posnack. He pointed to the recent work of the Health IT Joint Committee Collaboration’s API Task Force, which submitted their final report on July 8 this year. The Taskforce’s report came about after the U.S. National Coordinator for Health Information, Dr Karen Salvo, called for greater patient access to their health information, identifying APIs as a key enabler to make that happen. Posnack says this policy preparedness was occurring in tandem with a technical maturity, as seen in the progress of the Fast Healthcare Interoperability Services (FIHR) standard.

Last year, several health IT leaders, including John Halamka, CIO at Beth Israel Deaconess Medical Center, called for a slowing down of mandatory API requirements, arguing that health professionals were having a hard time entering all the necessary data required in Meaningful Use provisions. These requirements stipulate a minimum dataset that must be collected for patient health records and that these must be entered into the patient’s electronic health record. The latest regulations are suggesting that penalties be introduced for non-compliance.

With the move towards this system — referred to as Stage 3 Meaningful Use — and with the introduction of the requirement for health software to provide patients with access to their data via API as part of the 2015 Edition of Health IT Certification, Dr Salvo created the API Task Force to review issues including security risks, privacy concerns and to make recommendations so that citizens could best access their health data via API.

Summary of Findings from the API Task Force

The API Taskforce’s 52-page report was prepared by a committee that included hospital medical schools, Health Departments, the Office for Civil Rights, and private health tech providers specializing in prescription services, mobile health and identity management. The Task Force held hearings with five panels, covering technology, healthcare delivery, IT and consumer advocacy. (ProgrammableWeb’s Editor in Chief, David Berlind, participated in the technology panel.)

The Task Force focused on read-only access to a patient’s healthcare records, but did note the need in future to also look into APIs that could write and update a healthcare record, or that could aggregate data of populations of patients. Overall, the Task Force “did not identify any ‘show-stopping’ barriers that would prevent the deployment of APIs within the timelines”, that is by 2018, when the 2015 Edition of the Certified IT systems comes into effect. 

Key recommendations included:

  • The need for an oversight Framework so that software providers, API developers and patients could stay up to date, register complaints, and be informed of best practices
  • There is some further clarification needed on how opening health data by API complies with HIPAA standards
  • Wherever possible, whenever anyone requests that an app be given access to their health records, this should be done via a dynamic registration process using something like the OAuth 2.0 Dynamic Client Registration Protocol so that apps and software can immediately access the patient’s health care data. The concern is that if there is a manual registration process that this could be used to slow down the sharing of data.
  • The Office of the National Coordinator should encourage a market in app endorsements and a secondary market in consumer reviews and experiences of apps and of sharing their data, creating greater community awareness and participation in how their health data is managed and used.
  • That a Model Privacy Notice and voluntary Code of Conduct be created for app developers that spells out responsibilities and encourages a greater “privacy literacy”
  • That the industry work towards a set of standards on the usability of health apps for individual citizens, using the Web Content Accessibility Guidelines as a model in the interim
  • That the industry create a model authorization form so that citizens are fully aware of what data they are authorizing to share
  • API providers may be able to set security-related restrictions such as Rate Limiting and expiration of access tokens, but shouldn’t be involved in deciding what the data is to be used for: if the citizen gives their consent to an app to use their health record data, the API provider does not need to be involved in how the app recipient is using the data (because the citizen has authorized it)
  • There should be a few categories for what data citizens can agree to share (“course grain” categories of health data rather than an ‘all or nothing’ option)
  • The Office of the National Coordinator should make the certification process include the right for the ONC to audit all access logs of an API
  • Citizens should be able to see through a Portal what apps they have authorized to have access to their health data at any given time.

The Emergence of a Healthcare Ecosystem

Posnack said that his office is now looking to implement the Task Force recommendations, and is already actively encouraging a new health startup ecosystem to bloom. This ecosystem will provide new apps for patients that make use of their health data, connected via API, in novel ways. “Our role is to ensure that there are innovative approaches going on in the market,” he said.

Be sure to read the next Health article: ProgrammableWeb's Most Interesting APIs in 2016: Health and Environment