Information Blocking–Gropper & Peel Weigh in

By ADRIAN GROPPER & DEBORAH PEEL

Today is the last day for public comments on the proposed CMS regulations regarding Medicare hospital inpatient prospective payment systems (IPPS). While there are several changes proposed, the one that’s raised lots of attention has been the idea that access to Medicare may be denied to those providers guilty of information blocking. Here are the comments submitted by Gropper & Peel from Patients Privacy Rights— Matthew Holt

Executive Summary of PPR Comments on Information Blocking

Information blocking is a multi-faceted problem that has proved resistant to over a decade of regulatory and market-based intervention. As Dr. Rucker said on June 19, “Health care providers and technology developers may have powerful economic incentives not to share electronic health information and to slow progress towards greater data liquidity.” Because it involves technology standards controlled by industry incumbents, solving this problem cannot be done by regulation alone. It will require the coordinated application of the “power of the purse” held by CMS, VA, and NIH.

PPR believes that the 21st Century Cures Act and HIPAA provide sufficient authority to solve interoperability on a meaningful scale as long as we avoid framing the problem in ways that have already been shown to fail such as “patient matching” and “trust federations”. These wicked problems are an institutional framing of the interoperability issue. The new, patient-centered framing is now being championed by CMS Administrator Verma and ONC Coordinator Rucker is a welcome path forward and a foundation to build upon.

To help understand the detailed comments below, consider the Application Programming Interface (API) policy and technology options according to two dimensions:

API Content and Security	Institution is Accountable	Patient is Accountable
API Security and Privacy	Broad, prior consent Patient matching Institutional federation Provider-directed interop Compliance mindset	Directed authorization Known to the practice Individual credentials Patient-directed interop Privacy mindset
API Content / Data Model	Designated record set FHIR Patient-restricted data De-identified data Bulk (multi-patient) data	Designated record set FHIR Sensitive data Social determinants Wearables and monitors

This table highlights the features and benefits of interoperability based on institutional or individual accountability. This is not an either-or choice. The main point of our comments is that a patient-centered vision by HHS must put patient accountability on an equal footing with institutional accountability and ensure that Open APIs are accessible to patient-directed interoperability “without special effort” first, even as we continue to struggle with wicked problems of national-scale patient matching and national-scale trust federations.

Here are our detailed comments inline with the CMS questions in bold:

Additionally, we specifically invite stakeholder feedback on the following questions regarding possible new or revised Conditions of Participation (CoPs) and Conditions for Coverage (CfCs) for interoperability and electronic exchange of health information:

• If CMS were to propose a new CoP/CfC standard to require electronic exchange of medically necessary information, would this help to reduce information blocking as defined in section 4004 of the 21st Century Cures Act?

Yes it would. The most significant help would be to require patient-directed exchange as the minimum and as a safe-harbor from sanction for information blocking. Patient-directed exchange is well established and common when the medium is paper via postal service or fax. This mode is accessible to all patients and all practitioners with patient consent. Patient-directed exchange also poses no patient-matching problem as has been proven over decades. Patient-directed information sharing spans diverse sources of information, including sensitive data and social determinants of health, and diverse uses of information, including research and public health. Applying the principles and policies of postal / fax release of information to the health records’ API would preserve all of these benefits and eliminate the problems such as delay, cost, and difficulty in machine processing. It’s time to make technology that eases burdens on patents and ensures they can move their data to the right place, at the right time.

Patient-directed information sharing is arguably the only foundation for practical reduction in information blocking. This foundation provides the privacy/consent mechanisms and inherent patient-matching capability onto which more sophisticated functionality such as alerts to subscribed providers upon patient admission can be built.

After 15 years of industry data-blocking, it’s abundantly clear that ONLY patients will assure their health data is used for treatment. The ‘covered entities’ treat patient health data as a corporate asset.

• Should CMS propose new CoPs/CfCs for hospitals and other participating providers and suppliers to ensure a patient’s (or his or her caregiver’s or representative’s) right and ability to electronically access his or her health information without undue burden? Would existing portals or other electronic means currently in use by many hospitals satisfy such a requirement regarding patient access as well as interoperability?

Yes, but simple access is not enough. Patient access must be defined to include patient-directed sharing without any restriction in order to create an efficient market for consented use of the patient data. Patients need the right to direct their information to any end user in order to avoid loss of provenance, authenticity, delay, and cost. They also know best which diagnoses, medications, and treatments are correct and effective; so they can prevent the propagation of erroneous data and diagnoses. It is especially important because physicians can no longer be counted on to assume responsibility for reconciling wrong and/or out-of-date diagnoses, medications, and data. Recipients of patient-directed information must have the assurance that the information was not tampered-with that can only come from getting it directly from the source. This was/is characteristic of postal/fax access, for example for Social Security Disability determination, where the need for direct transfer of records to avoid tampering seems obvious. This feature of patient-directed sharing must be preserved. As we introduce electronic APIs, it’s not enough to put personal health records in the middle, because these can be tampered-with. We need the APIs to enable direct transfer from source to destination as directed by the patient.

Existing portals play an important role in eliminating undue burden from electronic interoperability but they need to be enhanced to provide the same functionality that patients have when presenting a Release of Information form in-person but without the inconvenience of in-person. In other words, the patient portal must allow the authenticated patient to fill out a Release of Information form and specify the scope and destination of external records access that is equivalent to what’s available in-person today. Policy around this was developed by the 2016 ONC API Task Force and accepted by the relevant committee. Technology standards such as Kantara User managed Access (UMA) that build upon the existing FHIR / OAuth security standards are also available that can be linked into the patient portal enhancement for patient-directed access without undue effort.

It’s finally time to develop health technology systems that serve patients, and make it convenient for them to use, benefit from, allow research queries of their records instead of disclosures, and understand their own health data.

• Are new or revised CMS CoPs/CfCs for interoperability and electronic exchange of health information necessary to ensure patients and other treating providers routinely receive relevant electronic health information from hospitals on a timely basis or will this be achieved in the next few years through existing Medicare and Medicaid policies, Health Insurance Portability and Accountability Act of 1996 (HIPAA), and implementation of relevant policies in the 21st Century Cures Act?

Even though HIPAA and the 21st Century Cures Act provide the legal basis for routine reception of relevant information, new CMS CoPs/CfCs may be required because interpretation of the applicable regulations leaves too much latitude for information-blocking through censorship of destinations, arbitrary limits to access, delay in access, lack of consent, lack of transparency and accountability, arbitrary transaction obstacles, charging for patient access, and inadequate patient matching.

New CMS CoPs/CfCs should follow the lead of the API Task Force to eliminate the excuses that hospitals use to delay or censor competitive uses and make patient-directed access by patient and other treating providers the rule.

• What would be a reasonable implementation timeframe for compliance with new or revised CMS CoPs/CfCs for interoperability and electronic exchange of health information if CMS were to propose and finalize such requirements? Should these requirements have delayed implementation dates for specific participating providers and suppliers, or types of participating providers and suppliers (for example, participating providers and suppliers that are not eligible for the Medicare and Medicaid EHR Incentive Programs)?

A reasonable timeframe for compliance with new or revised CMS CoPs/CfCs for interoperability and electronic exchange of health information is the same timeframe that any API access is deployed for provider-to-provider, provider-government, provider-research electronic exchange.

Health records vendors and hospitals have a strong incentive to provide APIs to their selected suppliers through controlled “app stores” and other vendor-controlled tollgates, while blocking information by services they do not approve or that enable competing providers as part of the care team. This natural information blocking tendency is only amplified by compensation mechanisms such as ACOs and narrow networks that seek to limit competition to treat a particular patient. Large provider networks use control over the patient information as a way to get larger at the expense of independent practices and practice innovators, limiting competition and preventing out-of -network physicians from having data for treatment. Large networks are helped by policies such as Stark Law exemptions for health IT. The result has been continued price increase and difficulty in value-based payment innovation.

By linking the timetables for patient-directed access to internal app store access, we ensure that information blocking is not supported through standards manipulation and regulatory capture.

• Do stakeholders believe that new or revised CMS CoPs/CfCs for interoperability and electronic exchange of health information would help improve routine electronic transfer of health information as well as overall patient care and safety?

As patients and physicians wanting to represent the interest of our patients, we insist on the option for unblocked access to patient information when the patient directs that access. Patient-directed sharing needs to be the first kind of sharing, and accessible to all patients. A physician should not have the power to block patient access and say, “I’m afraid I can’t do that.” (to quote HAL in the movie 2001 A Space Odyssey).

Once this capability is in place a market for innovative services to support treatment and patient safety will be created that is accessible to patients and to physicians. Right now, this market does not exist because patients and physicians have no market power in the face of institutional control over the information technology, ie, because of data-blocking.

• Under new or revised CoPs/CfCs, should non-electronic forms of sharing medically necessary information (for example, printed copies of patient discharge/transfer summaries shared directly with the patient or with the receiving provider or supplier, either directly transferred with the patient or by mail or fax to the receiving provider or supplier) be permitted to continue if the receiving provider, supplier, or patient cannot receive the information electronically?

Yes. As stated above, patient portals can remove the undue costs, loss of time, missing work, and other burdens of in-person visits patients must bear before initiating non-electronic forms of sharing. Patient portals should serve the equivalent function of in-person authentication and consent regardless of whether the actual transmission medium is mail or fax.

• Are there any other operational or legal considerations (for example, HIPAA), obstacles, or barriers that hospitals and other providers and suppliers would face in implementing changes to meet new or revised interoperability and health information exchange requirements under new or revised CMS CoPs/CfCs if they are proposed and finalized in the future?

No. As mentioned above, hospitals and other providers have an incentive to enhance their internal systems through APIs for app stores that they control. The management of consent and patient matching remain unsolved problems even after almost a decade of HITECH regulations. At this point, we must conclude that interoperability and health information exchange is only possible and scalable with a patient-directed approach.

• What types of exceptions, if any, to meeting new or revised interoperability and health information exchange requirements, should be allowed under new or revised CMS CoPs/CfCs if they are proposed and finalized in the future? Should exceptions under the Quality Payment Program including Certified Electronic Health Record Technology hardship or small practices be extended to new requirements? Would extending such exceptions impact the effectiveness of these requirements?

The API Task Force addressed this issue by concluding that restrictions to patient-directed exchange should be allowed only in cases where a patient-directed system could impact the access rights of others using the same API. For example, API access can be denied to a system that makes so many requests in a period of time that it slows the information system as seen for access to other patients.

By leading with patient-directed exchange without significant exceptions an institution is effectively given a safe harbor against liability for privacy or information-blocking. Security is a reason for exception only when the security of other patients is affected. The safe harbor provisions of patient-directed exchange protect the CMS CoPs/CfCs hospital from any security breaches related to a specific patient-directed data use or data processor.

We would also like to directly address the issue of communication between hospitals (as well as the other providers and suppliers across the continuum of patient care) and their patients and caregivers. MyHealthEData is a government-wide initiative aimed at breaking down barriers that contribute to preventing patients from being able to access and control their medical records. Privacy and security of patient data will be at the center of all our efforts in this area. CMS must protect the confidentiality of patient data, and CMS is completely aligned with the Veterans Affairs, the National Institutes of Health, ONC, and the rest of the federal government, on this objective. While some Medicare beneficiaries have had, for quite some time, the ability to download their Medicare claims information, in pdf or Excel formats, through the CMS Blue Button platform, the information was provided without any context or other information that would help beneficiaries understand what the data was really telling them. For beneficiaries, their claims information is useless if it is either too hard to obtain or, as was the case with the information provided through previous versions of Blue Button, hard to understand. In an effort to fully contribute to the federal government’s MyHealthEData initiative, CMS developed and launched the new Blue Button 2.0, which represents a major step toward giving patients meaningful control of their health information in an easy-to-access and understandable way. Blue Button 2.0 is a developer-friendly, standards-based API that enables Medicare beneficiaries to connect their claims data to secure applications, services, and research programs they trust. The possibilities for better care through Blue Button 2.0 data are exciting, and might include enabling the creation of health dashboards for Medicare beneficiaries to view their health information in a single portal, or allowing beneficiaries to share complete medication lists with their doctors to prevent dangerous drug interactions.

To fully understand all of these health IT interoperability issues, initiatives, and innovations through the lens of its regulatory authority, we invite members of the public to submit their ideas on how best to accomplish the goal of fully interoperable health IT and EHR systems for Medicare- and Medicaid-participating providers and suppliers, as well as how best to further contribute to and advance the MyHealthEData initiative for patients. We are particularly interested in identifying fundamental barriers to interoperability and health information exchange, including those specific barriers that prevent patients from being able to access and control their medical records. We also welcome the public’s ideas and innovative thoughts on addressing these barriers and ultimately removing or reducing them in an effective way, specifically through revisions to the current CMS CoPs or CfCs for hospitals and other participating providers and suppliers. We have received stakeholder input through recent CMS Listening Sessions on the need to address health IT adoption and interoperability among providers that were not eligible for the Medicare and Medicaid EHR Incentives program, including long-term and post-acute care providers, behavioral health providers, clinical laboratories and social service providers, and we would also welcome specific input on how to encourage adoption of certified health IT and interoperability among these types of providers and suppliers as well.

PPR welcomes the intent of the MyHealthEData and initiative but, as currently announced, the CMS Blue Button 2.0 API is not developer friendly and poses tremendous burdens to patients that simply want to direct access to their own data. As proposed, the CMS API is incompatible with open source software because it assumes that the entity connected to the patient’s data is a corporation rather than a community. There is no obvious reason to block access to non-commercial technology because the access is still secured by the patient’s credentials. No matter how bad the technology is, be it corporate or community code, the patient’s trust and right of access must not be second-guessed by CMS. The process is also burdensome by including 1-2 week delay and a costly interview. If these restrictions on the patient’s intent as directed through the Medicare patient portal are not an “undue burden”, what is? We hope that CMS Blue Button 2.0 will reduce the burden on patients and reduce administrative costs, by adopting established dynamic client registration standards immediately and by offering a FHIR API that supports User Managed Access (UMA) standard alongside the FHIR/OAuth standard of the current version. UMA is much more patient-friendly because it allows the patient to manage their CMS, VA, All of Us, and private-sector consents without having to routinely access separate patient portals for each system.

MyHealthEData policies, including those that are implemented in CMS Blue Button 2.0, in the VA systems, and in the National Institutes of Health All of Us initiative must be aligned with the 2016 API Task Force recommendations and any restrictions or burdens on patient-directed access to the patient’s own information must be justified by evidence of actual harm or security risk rather than the current practice of making these policies out of the public eye.

Expanding access to patient data beyond Covered Entities without meaningful transparency, accountability, and informed consent will clearly cause even greater, potentially crippling mistrust in physicians and the entire US healthcare system. As of Jan 2016, the lack of trust in US health technology and in health professionals who use it led 89% of 12,090 patients surveyed to withhold data from providers.

Granting thousands or millions of entities such as “suppliers, hidden access to patient data, could cause 100% of patients to withhold data and/or refuse treatment.

The data being accessed under the flag of “analytics” and “research” is more often used to increase patient cost and further discrimination than it is used to advance the public good. Huge corporations inside and outside the US healthcare system spend billions buying massive health databases full of bad data to build proprietary analytics, isolated learning health systems, and black-box AI. Examples; IBM, Palantir, Google, etc.

But can AI and analytics be accurate if the data are bad and the biases hidden? Predictive AI and analytics are misapplied in prison industry; it predicts that the same inmates who are/were incarcerated will be re-incarcerated.

The lack of trust in health IT interferes with making correct diagnoses, and leads to prescribing inappropriate medications and treatment. Lack of trust in health IT interferes with quality and value-based payment initiatives because sensitive social determinants of health are not available or reliable.  The result of this massive deficit of trust is: US EHRs are filled with bad data, omissions and errors. Not only should more hidden entities NOT be given access to patient data, but those with hidden access, the Covered Entities, must earn the public’s trust back. Congress and industry must restore patient control over data via meaningful, transparency, accountability, and informed consent.

Adrian Gropper is CTO and Deborah Peel is President of Patient Privacy Rights

 

from THCB https://ift.tt/2tIfDkL