- Health IT integration will reach a significant threshold when, as specified under 2015 Edition criteria, electronic health records systems and related tools must provide consumer-facing access to the Common Clinical Data Set via an application programming interface (API).
Hard at work deciphering how consumers could leverage API technology to access patient data is the Joint API Privacy and Security Task Force. The group will issue recommendations to the Office of the National Coordinator for Health IT (ONC) by the end of April, taking into account appropriate levels of privacy and security protection.
The task force held virtual hearings at the end of January, during which more than 20 panelists representing consumer technology, healthcare delivery, health IT vendors and consumer advocates shared viewpoints on potential barriers to widespread adoption of open APIs.
A follow-up meeting held Feb. 9 sorted through common themes captured during the expert panel discussions. Josh Mandel, a biomedical informatics researcher at Harvard Medical School and co-chair of the API task force, led most of the session.
Panelists indicated general support for API adoption, noted Mandel. “There are risks to deploying APIs, but there are also risks to exposing healthcare data without APIs, and sometimes APIs can give you more effective tools for mitigating those risks. Benefits are seen to widely outweigh the risks,” he explained.
Nonetheless, the task force will likely need to advise ONC on the varying levels of permission and data scope associated with APIs. A particular use might explicitly approve data access, for example, or it could be based on automated decisions, such as who is accessing the data and for what purpose.
“When it comes to these fine-grained scopes, there is no question in the certification criteria that we need to support access to everything in the Common Clinical Data Set. That is a given,” Mandel explained. “The question becomes: Would it also be good for the API to allow the patient to impose limitations on what any particular API could seek? If that would be good, should it be required? Or is it good enough here in 2016 to get some data flowing, even if the only decision the patient has is all-or-nothing?”
Task force member Aaron Seib, representing the National Association for Trusted Exchange, encouraged early-stage pilots “at a broader scale than we’ve seen in the demonstrations to date.” In regard to segregating data according to fine-grained scopes, Seib commented, “I worry about pushing that burden on the provider.”
Mandel, who is the lead architect for the SMART on FHIR project at Harvard, said that segregating data — such as sensitive versus non-sensitive lab results — is a judgment call. “We don’t think that provider organizations are going to be able to make judgment calls, but they should be able to segregate resource types to be able to respond to API requests like ‘get medications’ or ‘get problems,’” he added.
Another area set up for further discussion is the need to know that apps accessing APIs are reliable and secure — perhaps through some form of certification. Opinions from the expert panelists varied along the following lines:
- Develop some form of approval seal from a third-party certifier.
- Make publicly available documentation for API use to test and affirm technical security.
- Strictly vet or internally certify apps that interact with an organization’s systems.
Task force member Leslie Kelly Hall, senior vice president for policy at Healthwise, noted the extremes among those options. “The idea of a ‘Good Housekeeping Seal’ is used when you can’t trust the industry or business. People often regard [that type of approval] as the provider telling them to trust it.” In contrast, she explained, “A single-practice provider is not going to vet anything. He’ll choose sources that say ‘I know this won’t break me.’ I’m not sure how we recommend something that addresses [both areas].”
“Maybe the best recommendation we can make is to provide a consistent or standard way that organizations can endorse the same apps,” responded Mandel. “Then we can have different viewpoints that are overlaid on top of each other. If a healthcare organization needs to make a decision, they can choose the voices or viewpoints that they trust the most in that crowd and that align with their needs.”
The API Task Force will reconvene on Feb. 22, with time allocated to the Office of Civil Rights to clarify issues of data ownership, patient access rights and HIPAA Business Associate Agreements.
The group also plans to drill down on key drivers for enabling API success, including: industry collaboration to develop standards-based open APIs; increased emphasis on development and innovation; and financial incentives related to value-based care and a shift toward more prevalent consumer-driven technologies.