Expert questions privacy, safety protections of API plan
While reviews of draft recommendations from a federal task force are generally positive, an industry watcher is concerned that liability issues were not fully addressed.
Application programming interfaces, a key technology component expected to give consumers access to healthcare information from electronic health records, also could carry some privacy and health or safety risks, especially in the early stages of use of the technology.
A recent series of draft recommendations by a task force of a federal advisory committee is receiving some criticism because it does not address liability protection for vendors and should provide more guidance to consumers about their rights and responsibilities in data access.
However, the recommendations, by a Health IT Policy Committee task force, has received generally positive reviews, after the group completed a review of the potential privacy and security vulnerabilities of the technology,
The work by the committee is important because application programming interfaces (APIs) could be the impetus for the development of a series of third-party health data apps for patients, which could give them far better access to their healthcare information contained in electronic records. APIs allow a software program to access the services provided by another software program.
The use of APIs were included in the final Meaningful Use Stage 3 rule, which would require certified EHR technology to provide an easy-to-use interface through which patient information can be viewed, downloaded and transmitted to a third party. In addition, APIs are included in the 2015 Edition of Health IT Certification Criteria, which requires certified EHRs to demonstrate the ability to use an API to provide an patient’s app to access the Common Clinical Data Set.
Within the framework of 2015 Edition and MU Stage 3, patient data must be “available for the patient (or patient-¬authorized representative) to access using any application of their choice that is configured to meet the technical specifications of the API in the provider’s [certified EHR technology].”
The HIT Policy Committee’s API task force, co-chaired by Harvard Medical School research faculty member Josh Mandel, MD, and Cerner’s Director of Health Policy Meg Marshall, recently released draft recommendations designed to help enable patients to leverage APIs to access their data, while ensuring an appropriate level of privacy and security protection.
Specifically, the task force recommendations “focus on read-¬only access to a single patient’s record for disclosure to an app selected by that patient, and used to access data elements defined in the Common Clinical Data Set.” To come up with its recommendations, the panel held virtual hearing sessions with stakeholders and reviewed written testimonies and public comment.
Overall, the API task force’s draft recommendations have been well received by both providers and vendors.
“The recommendations are thoughtful and timely,” says John Halamka, MD, CIO of Boston’s Beth Israel Deaconess Medical Center, a teaching hospital of Harvard Medical School. “Josh Mandel works closely with all of us in real-world settings, so the suggestions in the report are likely to be widely deployed and tested among Harvard hospitals.”
For its part, EHR vendor Cerner in a written statement said it “supports the task force and the process by which it’s developing recommendations, and we look forward to the final recommendations this month.”
Micky Tripathi, CEO of the Massachusetts eHealth Collaborative, believes that the task force’s report is extremely thorough and well-written. However, he is concerned that some patients will unwittingly use API-based apps in ways that may have negative effects, especially in the early stages of adoption when the app ecosystem is immature. Problems may arise with either privacy-related or reputational vulnerabilities or with some health or safety-related issues, he contends. As a result, in those circumstances, Tripathi is convinced that some of those patients will want to sue their provider or vendor for whatever harm they may have incurred.
“I think that the report should address the question of whether providers and vendors should be given some type of liability protection, and should recommend that ONC provide clear communications and guidance to patients regarding their personal responsibilities in app validation and the restrictions being placed on providers and vendors to validate such apps for patients,” he argues.
Tripathi points out that the task force states in many places that ONC needs to remind API providers, specifically healthcare providers and vendors, that they are not responsible for validating the apps that patients bring to them, and they are not allowed to block access regardless of any concerns they might have about the integrity, security or safety of such apps. “Well, they might not be responsible for it, but many providers and vendors will consider that part of their duty to their patients,” he asserts.
On that issue, Mandel told an April 19 joint Health IT Policy-Standards Committee meeting that the task force “heard very frequently from hospitals and healthcare provider organizations is that they would feel more comfortable living in a world where they knew which app existed and which app they should trust ahead of time.” Nonetheless, he said the panel concluded that this kind of “perfect assurance” regarding the security and safety of apps was not realistic.
Mandel added that providers should not be focused on those considerations, which “are really a decision between the patient and the app” and “API providers are not obligated to protect patients by identifying suspicious apps.”
Likewise, in terms of the task force’s scope, Marshall told the federal advisory committees at the same meeting that API “terms of use, licensing requirements, business policy formation, fee structures, certifying authorities, formulation of standards, electronic documentation of consents and issues unique to writing APIs” were all considered “out of scope” in the mandate of the panel.
However, Tripathi contends that the task force report doesn’t cover all of the issues that are going to be critical to widespread API adoption.
“Some of the items that are out-of-scope, such as terms of use and licensing, are key elements in the kind of rich ecosystem that’s going to be needed to support an API-driven world,” he says. “That’s not a criticism of the report, just a reminder that there are other important issues besides the ones that they address.”
At the same time, Tripathi finds it curious that the task force recommended that ONC “should analyze the feasibility of a single, simple, comprehensive oversight framework mechanism that would address the needs of the patient-¬directed API ecosystem,” saying that while congressional authority may be needed, such steps may be necessary to “harmonize conflicting, redundant and confusing laws that govern access to health IT.”
Tripathi believes that that the meaning of this recommendation remains ambiguous. “If it means that ONC should consider having some kind of additional regulatory oversight over the patient-directed API ecosystem, then that seems like a bad idea,” he says. “If it means that ONC should identify, clarify and align the various existing laws, regulations and agency activities that currently cover such APIs, I’m all for it.”
The 30-page draft report on APIs can be found here. The task force will present its final recommendations to a May 17 joint Health IT Policy-Standards Committee meeting.
A recent series of draft recommendations by a task force of a federal advisory committee is receiving some criticism because it does not address liability protection for vendors and should provide more guidance to consumers about their rights and responsibilities in data access.
However, the recommendations, by a Health IT Policy Committee task force, has received generally positive reviews, after the group completed a review of the potential privacy and security vulnerabilities of the technology,
The work by the committee is important because application programming interfaces (APIs) could be the impetus for the development of a series of third-party health data apps for patients, which could give them far better access to their healthcare information contained in electronic records. APIs allow a software program to access the services provided by another software program.The use of APIs were included in the final Meaningful Use Stage 3 rule, which would require certified EHR technology to provide an easy-to-use interface through which patient information can be viewed, downloaded and transmitted to a third party. In addition, APIs are included in the 2015 Edition of Health IT Certification Criteria, which requires certified EHRs to demonstrate the ability to use an API to provide an patient’s app to access the Common Clinical Data Set.
Within the framework of 2015 Edition and MU Stage 3, patient data must be “available for the patient (or patient-¬authorized representative) to access using any application of their choice that is configured to meet the technical specifications of the API in the provider’s [certified EHR technology].”
The HIT Policy Committee’s API task force, co-chaired by Harvard Medical School research faculty member Josh Mandel, MD, and Cerner’s Director of Health Policy Meg Marshall, recently released draft recommendations designed to help enable patients to leverage APIs to access their data, while ensuring an appropriate level of privacy and security protection.
Specifically, the task force recommendations “focus on read-¬only access to a single patient’s record for disclosure to an app selected by that patient, and used to access data elements defined in the Common Clinical Data Set.” To come up with its recommendations, the panel held virtual hearing sessions with stakeholders and reviewed written testimonies and public comment.
Overall, the API task force’s draft recommendations have been well received by both providers and vendors.
“The recommendations are thoughtful and timely,” says John Halamka, MD, CIO of Boston’s Beth Israel Deaconess Medical Center, a teaching hospital of Harvard Medical School. “Josh Mandel works closely with all of us in real-world settings, so the suggestions in the report are likely to be widely deployed and tested among Harvard hospitals.”
For its part, EHR vendor Cerner in a written statement said it “supports the task force and the process by which it’s developing recommendations, and we look forward to the final recommendations this month.”
Micky Tripathi, CEO of the Massachusetts eHealth Collaborative, believes that the task force’s report is extremely thorough and well-written. However, he is concerned that some patients will unwittingly use API-based apps in ways that may have negative effects, especially in the early stages of adoption when the app ecosystem is immature. Problems may arise with either privacy-related or reputational vulnerabilities or with some health or safety-related issues, he contends. As a result, in those circumstances, Tripathi is convinced that some of those patients will want to sue their provider or vendor for whatever harm they may have incurred.
“I think that the report should address the question of whether providers and vendors should be given some type of liability protection, and should recommend that ONC provide clear communications and guidance to patients regarding their personal responsibilities in app validation and the restrictions being placed on providers and vendors to validate such apps for patients,” he argues.
Tripathi points out that the task force states in many places that ONC needs to remind API providers, specifically healthcare providers and vendors, that they are not responsible for validating the apps that patients bring to them, and they are not allowed to block access regardless of any concerns they might have about the integrity, security or safety of such apps. “Well, they might not be responsible for it, but many providers and vendors will consider that part of their duty to their patients,” he asserts.
On that issue, Mandel told an April 19 joint Health IT Policy-Standards Committee meeting that the task force “heard very frequently from hospitals and healthcare provider organizations is that they would feel more comfortable living in a world where they knew which app existed and which app they should trust ahead of time.” Nonetheless, he said the panel concluded that this kind of “perfect assurance” regarding the security and safety of apps was not realistic.
Mandel added that providers should not be focused on those considerations, which “are really a decision between the patient and the app” and “API providers are not obligated to protect patients by identifying suspicious apps.”
Likewise, in terms of the task force’s scope, Marshall told the federal advisory committees at the same meeting that API “terms of use, licensing requirements, business policy formation, fee structures, certifying authorities, formulation of standards, electronic documentation of consents and issues unique to writing APIs” were all considered “out of scope” in the mandate of the panel.
However, Tripathi contends that the task force report doesn’t cover all of the issues that are going to be critical to widespread API adoption.
“Some of the items that are out-of-scope, such as terms of use and licensing, are key elements in the kind of rich ecosystem that’s going to be needed to support an API-driven world,” he says. “That’s not a criticism of the report, just a reminder that there are other important issues besides the ones that they address.”
At the same time, Tripathi finds it curious that the task force recommended that ONC “should analyze the feasibility of a single, simple, comprehensive oversight framework mechanism that would address the needs of the patient-¬directed API ecosystem,” saying that while congressional authority may be needed, such steps may be necessary to “harmonize conflicting, redundant and confusing laws that govern access to health IT.”
Tripathi believes that that the meaning of this recommendation remains ambiguous. “If it means that ONC should consider having some kind of additional regulatory oversight over the patient-directed API ecosystem, then that seems like a bad idea,” he says. “If it means that ONC should identify, clarify and align the various existing laws, regulations and agency activities that currently cover such APIs, I’m all for it.”
The 30-page draft report on APIs can be found here. The task force will present its final recommendations to a May 17 joint Health IT Policy-Standards Committee meeting.
More for you
Loading data for hdm_tax_topic #better-outcomes...