College of Healthcare Information Management Executives Issues Public Comment on Centers for Medicare & Medicaid Services Proposed Rule

WASHINGTON, Dec. 25 -- Russell P. Branzell, president and CEO, and John Kravitz, board chair, of the College of Healthcare Information Management Executives, Ann Arbor, Michigan, have issued a public comment on the Centers for Medicare and Medicaid Services proposed rule entitled "Medicaid Program: Patient Protection and Affordable Care Act; Reducing Provider and Patient Burden by Improving Prior Authorization Processes, etc.". The comment was written and posted on Dec. 23, 2020:

* * *

The College of Healthcare Information Management Executives (CHIME) welcomes the opportunity to respond to CMS' proposed rule titled Medicaid Program; Patient Protection and Affordable Care Act; Reducing Provider and Patient Burden by Improving Prior Authorization Processes, and Promoting Patients' Electronic Access to Health Information for Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, and Issuers of Qualified Health Plans on the Federally-facilitated Exchanges; Health Information Technology Standards and Implementation Specifications released on CMS.gov on December 10, 2020.

CHIME is an executive organization dedicated to serving chief information officers (CIOs), chief medical information officers (CMIOs), chief nursing information officers (CNIOs) and other senior healthcare IT leaders. With over 5,000 members, CHIME provides a highly interactive, trusted environment enabling senior professional and industry leaders to collaborate; exchange best practices; address professional development needs; and advocate for the effective use of information management to improve the health and healthcare in the communities they serve.

The continued evolution of healthcare as it moves deeper into the post information blocking and application programming interface (API) world will see the continued need for data to flow to fill gaps in patient records and improve the continuity of care. This proposed rule from the U.S. Department of Health and Human Services (HHS) Centers for Medicare & Medicaid Services (CMS) brings into focus a roadmap for how the agency plans to continue to implement the requirements outlined in the 21st Century Cures Act (Cures Act). While many provisions from the Cures Act were implemented as part of the CMS and Office of the National Coordinator for Health Information Technology (ONC) interoperability and information blocking final rules, published in the spring of 2020, this rule continues to bring clarity and expand those requirements to better improve a patient's experience with the health system.

In addition to responding to the API changes and expansions outlined in the rule, CHIME welcomes the opportunity to provide guidance to HHS and CMS as it relates to the requests for information (RFIs) included within the proposed rule. We have worked with our membership to shape our response to the RFIs, as well as the proposed API requirements, but do acknowledge that the shorter than standard response time for this rule impacts our ability to provide as robust comments as we would normally.

We urge CMS to solicit additional feedback from stakeholders regarding all of the provisions and RFIs contained within this proposed rule in order to give stakeholders additional time to speak with those effected and respond. An additional opportunity to discuss the impact of this important proposed rule will give CMS a better understanding of industry readiness to meet the requirements and help to ensure CMS achieves a successful implementation of these and future requirements.

Our comments within this letter are divided into two sections, with the first responding directly to the proposed API, prior authorization and implementation specification requirements. The second section will respond to the RFIs summarizing the experiences of CHIME members. Throughout our comments you will see the following themes, including:

* Developing a robust unique patient identification and patient matching solution to ensure the success of these APIs and protect patients;

* Ensuring additional API requirements don't place unintended burden on providers;

* Ensuring vendors of electronic health record (EHR) technology are included in all development and deadline setting to ensure these APIs are ready and usable by the deadlines outlined by CMS;

* Without wider payer requirements to implement the described APIs, providers may be slow to adopt and utilize the APIs; and

* Greater flexibility is required to assist providers in meeting the information blocking requirements while also protecting specific pieces of patient data.

Response to API, Prior Authorization and ONC Implementation Specification

The CMS proposed rule creates additional requirements and furthers the implementation of already drafted requirements with a main focus on payer APIs. With that in mind, CMS outlines within the rule how providers will be able to utilize these APIs in order to fill gaps in patient records and retrieve prior authorization decisions for covered and denied services. CHIME supports CMS' efforts to increase the exchange of patient data broadly and urges CMS to continue advancing these initiatives. It is also important to remember that without private payer and Medicare Advantage (MA) plans being subject to these requirements adoption and utilization will most likely remain low with providers as many of their patient populations fall into those two payer categories. Additionally, while provider participation in the mandates included within these proposed rules remains voluntary, a significant burden would be placed on providers if they were to become mandatory given that, in many instances, each payer has the option to choose how to meet requirements, such as providing a patient list to a provider. By allowing each payer the option to choose their own process, providers that accept multiple different payers could face a scenario where retrieving a patient list could include as many as 10, if not more, different processes. Understanding the long-term ramifications of these policies is important and CHIME urges CMS to ensure payers do not inadvertently pass down burden through the implementation of these APIs.

Patient Access and Payer-to-Payer APIs

CHIME supports CMS' efforts to bring standardization to the Patient Access API and believe the more payers are eligible and required to participate in a payer-to-payer API will only increase the flow of patient data. With that in mind, we urge CMS and the participating payers to prioritize cybersecurity and privacy in order to protect the patients who are involved in the payer-to-payer data exchange from health data breaches.

Additionally, CHIME encourages CMS to ensure the reporting metrics payers are required to report to the agency are not duplicative. CHIME has maintained a focus on ensuring reporting burden within the health sector is lessened and that duplicative reporting requirements are reduced and eliminated throughout the federal regulatory process.

Finally, CHIME recommends CMS and payers work with the vendors of EHR technology and other provider utilized technology to ensure that access to the Patient Access API for providers does not require additional costly deployments of updated EHR technology for providers. It's important to ensure the technology is structured and ready to participate in the API, and that the burden of implementation is placed on the vendors and payers, not the providers. Without this collaboration a scenario may present itself where payers are encouraging providers to utilize an API that they are not able to access or utilize in a care setting.

Provider Directory API

CHIME supports the development of a provider directory API. We urge both CMS and payers to ensure that the burden for collecting and verifying the data contained within the provider directory API remains the payer's responsibility and is not a burden that is shifted to the provider organization.

Provider Access API

CHIME is supportive of the provisions within the proposed rule to create a provider access API. We do note however, that provider utilization of this API should remain voluntary, especially given the lack of applicability across the full payer spectrum. Without requirements for MA and private payers to utilize these APIs, there remains limited applicability for providers to utilize this API, as it would not impact a significant portion of their patient population.

Additionally, until wider applicability is reached, it is crucial for developers of EHR technology, and other technology that would connect with these APIs from the provider side, be engaged in the API's development throughout the process. Similar to the Patient Access API, without the ability to connect on the provider side, this API has the potential to be inaccessible to providers, thus limiting its ability to have any meaningful impact at the point of care.

CHIME does agree with CMS that there needs to be multiple efforts underway in how providers are able to access this patient data. Based on the clinical need, there are scenarios where providers may be looking for information on one single patient to help support an immediate need. That said, it would decrease the burden on providers - and potentially payers - if providers would have the ability to regularly pull and update data on their patients in bulk, such as what is proposed in the rule with the utilization of a bulk FHIR API.

While developing these APIs, CHIME encourages CMS and payers to create a solution to uniquely identify patients and ensure the right patient is being matched to the correct record. It is always crucial to patient safety to ensure that the right patient is being matched to the right record, but it becomes even more imperative when matching is being used as a way to update multiple records at the same time. If the API is not able to identify records and patients at a 99.9% matching accuracy rate, then trust in the API will be jeopardized and utility will be limited.

Finally, it is crucial that these APIs are standardized. As previously discussed above, if each payer creates its own specification for how providers should access their respective API, then a scenario exists where a provider needs to maintain a multitude of specifications to connect to each individual API. With each connection implementation different, providers would inherit a significant burden of having to work through potentially 10 or more different APIs and connection specifications. With provider participation in these APIs voluntary, exponentially increasing burden to retrieve the information has the potential to discourage participation and utilization of the provider access API.

Prior Authorization Support API (PAS API)

CHIME supports efforts to increase the speed and utilization of prior authorization in the care setting. Giving providers as much information as possible at the point of care helps them better communicate with patients and plan for care that is affordable and accessible to the patient. Despite the benefits of a prior authorization support API (PAS API) and the hunger for better price transparency in the provider community, utilization of this API has the potential to be minimal given participation is voluntary for providers and that MA and other private payers are not required to implement the APIs. As stated above, without MA and private payer development and utilization, a majority of a provider's patient population is excluded from this API and would thus offers little to providers when it comes to communicating prior authorization decision to patients.

As stated above, CHIME urges CMS and payers to work with EHR technology and other provider technology developers to ensure that these APIs are accessible by providers. This ensures the information is accessible and usable at the point of care. Without ensuring providers have access to these APIs, utilization could be minimal if the burden of connecting is placed on the provider.

Additionally, CMS states that prior authorization decisions should also be available to providers via the provider access API when requested by a provider. CHIME urges CMS to make the PAS API a part of the provider access API for payers, as opposed to making a separate API requirement. If the technology exists to transmit prior authorization decisions across the provider access API, then CMS should limit the burden on both providers and payers by eliminating an unnecessary API and enhancing the provider access API to ensure it is more efficient. Requiring payers to submit these decisions across two APIs could create confusion for providers and would then require providers to implement another full set of APIs to receive prior authorization decisions. If CMS wants to encourage and increase adoption of prior authorization APIs, it would be in CMS' best interests to combine these two requirements into one.

CHIME continues to advocate for a reduction in duplicative federal requirements in order to limit burden across the health sector and combining the PAS API and provider access API is just one way to limit duplicity.

It should be noted that many providers already have a functional prior authorization process in place that operates as intended and with moderate levels of satisfaction. EHR vendors currently have limited ability to display prior authorization decisions at the point of care and developing those for use at the point of care would be a costly endeavor for payers, given that they are the ones charged for their development. This would also put a significant cost burden on providers who would now have systems that they have implemented in their business office that would no longer be useful. There would be significant upgrades and training needed from providers in order for these APIs to ultimately be deployed at the point of care. While CHIME supports the development of these types of APIs, CMS needs to ensure that by developing them they do not cause harm to actors within the health continuum in the process.

Finally, CHIME urges CMS to reconsider allowing a non-response to serve as a denial of a prior authorization request. By allowing a lack of response within the timeframes to serve as a denial of prior authorization, the burden of attaining prior authorization then shifts to providers as they are forced to appeal the decision. A payer could then exploit these rules to further limit the ability for providers to attain prior authorization by creating policies of non-response to electronic requests to limit patient access to certain procedures or covered services. While CHIME supports "gold carding" some procedures and services, this would not rectify a potential culture of non-response and appeal.

Providers want to provide the best care for their patients at the most attainable cost/ Ensuring timely response to prior authorization is therefore critical in allowing them to do just that. Allowing payers to essentially "pocket deny" claims by failing to respond limits a provider's ability to care for a patient in a timely and cost-effective manner.

Implementation Specifications

CHIME supports the creation of an implementation specification and the adoption of specified implementation guides to support the implementation of proposed APIs. Bringing further standardization to this space will only ease the burden and requirements placed on those developing these APIs and ease the implementation of APIs as a whole over time. With that in-mind, we encourage ONC and CMS to use this as a floor with the understanding that there would need to be an evolution of specifications overtime that may diverge from what is originally proposed here.

Requests for Information

As stated above, CHIME welcomes the opportunity to respond to the RFIs in the proposed rule. With that in mind, CHIME encourages CMS in future rulemaking to allow for additional time for comment, in line with the traditional 60-to-90 days for comments to be submitted. By limiting the time allowed for comment, CHIME is significantly hindered in its ability to speak with its members and gather information needed to provide complete answers. This is especially true given the allotted comment period is less than 30-days and falls over the December religious holidays and the New Year.

Allowances for patients and/or providers to dictate which data elements from a medical record are shared when and with whom

In the post information blocking world, it will be crucial for patients and providers to have the ability to split and separate data elements from patient records when they are shared. As technology stands today, record sharing is limited to all or nothing with patients and providers having no ability to segment the data contained within the record. With respect to the previously mentioned information blocking requirements, actors - defined as providers, health information exchanges, health information networks and developers - were allotted a set of eight exceptions allowing them to withhold data if requested from a patient or third party. Many of those exceptions are straight forward with why a data exchange cannot take place, such as when a provider does not possess the technological capability. Others though, such as privacy and security, are less straight forward and may only pertain to certain portions of a patient's record. Creating requirements allowing providers and patients to withhold certain specified information, within reason, would assist in clarifying these requirements and would enable a better flow of information.

With this in mind, CHIME recommends CMS and ONC work together to modify the certification requirements for health IT to include the ability for patients and providers to select individual pieces of data to include or exclude from a data transfer given current limitations of EHRs as it pertains to data segmentation.

Below are two real-world scenarios from members indicating when having the ability to withhold individual data elements would assist them in unlocking patient data, while also protecting sensitive information.

* A CHIME member at a children's hospital in California indicated difficulty navigating the information blocking privacy requirements given California's protection of sensitive health data for minors law./1

As it was explained to CHIME, in California minors of any age may consent to medical services such as sexual assault and rape services without a parent or guardian At age 12 they may do so for services such as infectious disease treatment or diagnosis and at age 15 may consent to general medical care. At each age gated stage, the provider is not allowed to release information regarding a minor to a parent or guardian without the consent of the patient.

Given how the patient portal at this member's facility functions, from a major vendor, they only have the ability to give a parent complete access to a minor's record or no access to it. For instance, a minor may inform their provider that they are sexually active, but do not want this disclosed to their parent. Currently, a provider in California would not be able to give the parent access to any piece of the minor's record because there is no way to exclude sexual activity status from the patient's record when shared. Mandating the ability for a provider to claim the privacy exception on the select data element, in this case indicating the patient is sexually active, would allow the parent to have access to other vital information in the record, while also maintaining the privacy of the patient. Currently, there is no ability to do so in the technology, forcing the provider's hand to withhold all information from the parent.

* A second CHIME member outlined a scenario in which a patient is being treated for the mental health condition multiple personality disorder. A crucial part of that treatment is withholding the information from the patient that they have multiple personality disorder. Disclosure of this information endangers the patient's physical safety and mental health treatment. If that patient is treated for their disorder at a multi-specialty provider group, there is the possibility they could have that information inadvertently exposed to them if they were to go to another subspeciality.

For instance, if that patient had a joint problem and went to an orthopedic specialist and asked for a copy of their record, there is no way for the orthopedic provider to know that the portion of the record containing the multiple personality disorder diagnosis should be withheld. Allowing for the mental health provider to mark that data element as "preventing harm exception" in the record would prevent the other specialist from inadvertently placing the patient in harm. Currently, there is not technology in place to allow for this.

As these two anecdotes from our members highlight, it is crucial for CMS and ONC to work together to allow data to be segmented.

Leveraging APIs (or other solutions) to facilitate electronic data exchange between and with behavioral health care providers, and also community based organizations, who have lagged behind other provider types in adoption of EHRs

CHIME supports all efforts to increase the transmission of patient data via electronic means. APIs are a powerful tool in unlocking access to data and disrupting a technology space. With that in mind, CMS must also recognize that many behavioral health providers may be single provider operation and thus may not possess the technology baseline to harness an API. Without a certified EHR tailored specifically to behavioral health available to many of these providers, and without mandates for implementation once one is developed, an API may help move some data more freely, but not make as wide an impact on behavioral health as it would in other medical specialties.

It is crucial for CMS to work with the behavioral health community and the associations that support them to determine the best avenue to support behavior health providers with technology. It will require a joint effort to solve the problem of locked behavioral health data and find a solution that makes sense for both patients and providers that doesn't put a strain on an already stretched thin subset of medicine.

Barriers to Prior Authorization Utilization and MIPS

CHIME urges CMS to consider other options as it relates to encouraging the use of electronic prior authorization other than creating an improvement activity under the Merit-based Incentive Payment System (MIPS). Providers experience significant administrative burden from the requirements they are already required to adhere to and have additional requirements on the horizon in the form of information blocking and other Cures Act provisions. CHIME recommends CMS work with the provider and payer communities, as well as the vendor community, to find a solution that is the right fit for the respective parties. As stated above, without a wider swath of payers required to use the PAS API there is limited incentive for providers to utilize the API. In order to encourage an uptick in the use of the PAS API, CHIME recommends CMS find a solution within the APIs previously mandated by the Cures Act, so as to limit the burden on all members of the healthcare continuum. It's also important to ensure the APIs themselves function prior to mandating any type of participation.

Limiting the Use of Fax Machines

CHIME and its members support all initiatives to move the healthcare community beyond the fax machine. We have long stood in support of the interoperability regulations and proposals put forward by HHS to eliminate the use of the fax machine and increase the utilization of other electronic means of data exchange. With that in mind, CHIME encourages CMS to work with the Federal Communications Commission (FCC) and other key stakeholders to increase the nation's access to high-speed internet and the looming implementation of 5G technology. The biggest challenge to digital adoption remains access to reliable and high-speed broadband internet, especially in rural and underserved areas. By increasing access to broadband, CHIME believes we can move the nation even further down the interoperability road leaving paper-based means of communication in the past.

Barriers to Standards Adoption

CHIME supports all efforts to increase the use of social risk data in health technology. A key piece to the puzzle of further developing standards is finding consensus on the standards framework and harmonizing those standards across the health IT community. CHIME recommends CMS engage with the National Institute of Standards and Technology (NIST) to determine the best way to implement social risk data standards and then propose that roadmap to the Health IT Advisory Committee (HITAC) to determine the best path to implementation.

CHIME and its members again thank CMS for the work it is doing to further the health data and interoperability future outlined in the 21st Century Cures Act. CMS and its HHS partners, including ONC, have been instrumental in driving the adoption of new post information blocking policies and the development of key policies that put patients in control of their data. We hope our responses to your proposals and your RFIs above will assist in your future work. If you would like to discuss our letter further or meet with our members to understand firsthand their successes and struggles, please feel free to reach out to Andrew Tomlinson, our Director of Federal Affairs, at [email protected].

Sincerely,

Russell P. Branzell, CHCIO, LCHIME, President and CEO CHIME

John Kravitz, Chair, CHIME Board of Trustees, CIO, Geisinger

* * *

Footnote:

1/ http://www.publichealth.lacounty.gov/dhsp/Providers/toolkit2.pdf

* * *

The proposed rule can be viewed at: https://www.regulations.gov/document?D=CMS-2020-0157-0007

TARGETED NEWS SERVICE (founded 2004) features non-partisan 'edited journalism' news briefs and information for news organizations, public policy groups and individuals; as well as 'gathered' public policy information, including news releases, reports, speeches. For more information contact MYRON STRUCK, editor, [email protected], Springfield, Virginia; 703/304-1897; https://targetednews.com