[{"innerBlocks":[],"name":"core\/freeform","postId":4562,"blockType":{"name":"core\/freeform","keywords":[],"attributes":{"content":{"type":"string","source":"raw"},"lock":{"type":"object"}},"providesContext":[],"usesContext":[],"selectors":[],"supports":{"className":false,"customClassName":false,"reusable":false},"styles":[],"variations":[],"apiVersion":3,"title":"Classic","description":"Use the classic WordPress editor.","category":"text"},"originalContent":"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\u2019s app to access the Common Clinical Data Set.

Within the framework of 2015 Edition and MU Stage 3, patient data must be \u201cavailable for the patient (or patient-\u00acauthorized representative) to access using any application of their choice that is configured to meet the technical specifications of the API in the provider\u2019s [certified EHR technology].\u201d

The HIT Policy Committee\u2019s API task force, co-chaired by Harvard Medical School research faculty member Josh Mandel, MD, and Cerner\u2019s 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 \u201cfocus on read-\u00aconly access to a single patient\u2019s record for disclosure to an app selected by that patient, and used to access data elements defined in the Common Clinical Data Set.\u201d 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\u2019s draft recommendations have been well received by both providers and vendors.

\u201cThe recommendations are thoughtful and timely,\u201d says John Halamka, MD, CIO of Boston\u2019s Beth Israel Deaconess Medical Center, a teaching hospital of Harvard Medical School. \u201cJosh 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.\u201d

For its part, EHR vendor Cerner in a written statement said it \u201csupports the task force and the process by which it\u2019s developing recommendations, and we look forward to the final recommendations this month.\u201d

Micky Tripathi, CEO of the Massachusetts eHealth Collaborative, believes that the task force\u2019s 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.

\u201cI 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,\u201d 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. \u201cWell, they might not be responsible for it, but many providers and vendors will consider that part of their duty to their patients,\u201d he asserts.

On that issue, Mandel told an April 19 joint Health IT Policy-Standards Committee meeting that the task force \u201cheard 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.\u201d Nonetheless, he said the panel concluded that this kind of \u201cperfect assurance\u201d regarding the security and safety of apps was not realistic.

Mandel added that providers should not be focused on those considerations, which \u201care really a decision between the patient and the app\u201d and \u201cAPI providers are not obligated to protect patients by identifying suspicious apps.\u201d

Likewise, in terms of the task force\u2019s scope, Marshall told the federal advisory committees at the same meeting that API \u201cterms of use, licensing requirements, business policy formation, fee structures, certifying authorities, formulation of standards, electronic documentation of consents and issues unique to writing APIs\u201d were all considered \u201cout of scope\u201d in the mandate of the panel.

However, Tripathi contends that the task force report doesn\u2019t cover all of the issues that are going to be critical to widespread API adoption.

\u201cSome 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\u2019s going to be needed to support an API-driven world,\u201d he says. \u201cThat\u2019s not a criticism of the report, just a reminder that there are other important issues besides the ones that they address.\u201d

At the same time, Tripathi finds it curious that the task force recommended that ONC \u201cshould analyze the feasibility of a single, simple, comprehensive oversight framework mechanism that would address the needs of the patient-\u00acdirected API ecosystem,\u201d saying that while congressional authority may be needed, such steps may be necessary to \u201charmonize conflicting, redundant and confusing laws that govern access to health IT.\u201d

Tripathi believes that that the meaning of this recommendation remains ambiguous. \u201cIf 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,\u201d he says. \u201cIf it means that ONC should identify, clarify and align the various existing laws, regulations and agency activities that currently cover such APIs, I\u2019m all for it.\u201d

The 30-page draft report on APIs can be found here<\/a>. The task force will present its final recommendations to a May 17 joint Health IT Policy-Standards Committee meeting.","saveContent":"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\u2019s app to access the Common Clinical Data Set.

Within the framework of 2015 Edition and MU Stage 3, patient data must be \u201cavailable for the patient (or patient-\u00acauthorized representative) to access using any application of their choice that is configured to meet the technical specifications of the API in the provider\u2019s [certified EHR technology].\u201d

The HIT Policy Committee\u2019s API task force, co-chaired by Harvard Medical School research faculty member Josh Mandel, MD, and Cerner\u2019s 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 \u201cfocus on read-\u00aconly access to a single patient\u2019s record for disclosure to an app selected by that patient, and used to access data elements defined in the Common Clinical Data Set.\u201d 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\u2019s draft recommendations have been well received by both providers and vendors.

\u201cThe recommendations are thoughtful and timely,\u201d says John Halamka, MD, CIO of Boston\u2019s Beth Israel Deaconess Medical Center, a teaching hospital of Harvard Medical School. \u201cJosh 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.\u201d

For its part, EHR vendor Cerner in a written statement said it \u201csupports the task force and the process by which it\u2019s developing recommendations, and we look forward to the final recommendations this month.\u201d

Micky Tripathi, CEO of the Massachusetts eHealth Collaborative, believes that the task force\u2019s 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.

\u201cI 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,\u201d 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. \u201cWell, they might not be responsible for it, but many providers and vendors will consider that part of their duty to their patients,\u201d he asserts.

On that issue, Mandel told an April 19 joint Health IT Policy-Standards Committee meeting that the task force \u201cheard 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.\u201d Nonetheless, he said the panel concluded that this kind of \u201cperfect assurance\u201d regarding the security and safety of apps was not realistic.

Mandel added that providers should not be focused on those considerations, which \u201care really a decision between the patient and the app\u201d and \u201cAPI providers are not obligated to protect patients by identifying suspicious apps.\u201d

Likewise, in terms of the task force\u2019s scope, Marshall told the federal advisory committees at the same meeting that API \u201cterms of use, licensing requirements, business policy formation, fee structures, certifying authorities, formulation of standards, electronic documentation of consents and issues unique to writing APIs\u201d were all considered \u201cout of scope\u201d in the mandate of the panel.

However, Tripathi contends that the task force report doesn\u2019t cover all of the issues that are going to be critical to widespread API adoption.

\u201cSome 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\u2019s going to be needed to support an API-driven world,\u201d he says. \u201cThat\u2019s not a criticism of the report, just a reminder that there are other important issues besides the ones that they address.\u201d

At the same time, Tripathi finds it curious that the task force recommended that ONC \u201cshould analyze the feasibility of a single, simple, comprehensive oversight framework mechanism that would address the needs of the patient-\u00acdirected API ecosystem,\u201d saying that while congressional authority may be needed, such steps may be necessary to \u201charmonize conflicting, redundant and confusing laws that govern access to health IT.\u201d

Tripathi believes that that the meaning of this recommendation remains ambiguous. \u201cIf 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,\u201d he says. \u201cIf it means that ONC should identify, clarify and align the various existing laws, regulations and agency activities that currently cover such APIs, I\u2019m all for it.\u201d

The 30-page draft report on APIs can be found here<\/a>. The task force will present its final recommendations to a May 17 joint Health IT Policy-Standards Committee meeting.","order":0,"get_parent":{},"attributes":[],"attributesType":{"content":{"type":"string","source":"raw"},"lock":{"type":"object"}},"dynamicContent":""}]

Expert questions privacy, safety protections of API plan

More for you