/>iOn March 4, 2019, the Centers for Medicare & Medicaid Services (“CMS”) published a wide-ranging proposed rule (“Proposed Rule”)[1] with the intent to “move the health care ecosystem in the direction of interoperability” in alignment with the objectives set out in the 21st Century Cures Act (“Cures Act”)[2] and Executive Order 13813.[3] According to CMS, this Proposed Rule is a key step in putting patients at the center of their health care and ensuring that they have access to their health information – attempting to solve the problem of accessing complete health information from different providers and payors. CMS believes patients should have the “ability to move from health plan to health plan, provider to provider, and have both their clinical and administrative information travel with them throughout their journey.”[4] A twin goal is that health IT should not “detract from the clinician-patient relationship… or from the quality of work life for physicians, nurses, and other health care professionals.”[5]
Section 4003 of Cures Act defines interoperability as health information technology that:
-
enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user;
-
allows for complete access, exchange, and use of all electronically accessible health information for authorized use applicable state and federal law; and
-
does not constitute information blocking.
The Proposed Rule would impact Medicare Advantage (“MA”) Organizations, state Medicaid fee-for-service (“FFS”) programs, Medicaid managed care plans, CHIP FFS programs, CHIP managed care entities and Qualified Health Plan (“QHPs”) issuers in Federally-facilitated Exchanges (“FFEs”) (excluding issuers of Stand Alone Dental Plans) by requiring them to implement, test, and monitor an openly-published application programming interface (“API”), “maintain a process to coordinate care between plans by exchanging at a minimum, the U.S. Core Data for Interoperability (“USCDI”),[6] and to participate in trust networks in order to improve interoperability in these programs.
APIs are a main focus of the Proposed Rule. According to the Office of the National Coordinator for Health Information Technology (“ONC”), APIs “are messengers or translators that work behind the scenes to help software programs communicate with one another.”[7] APIs describe a specific set of technical instructions that allow “one piece of software to interact with anther piece of software.” In 2018, CMS launched the Blue Button 2.0 API in Medicare FFS that allows beneficiaries to access their health claims information electronically via an application of their choosing. According to CMS, there are over 1500 application developers building tools with this API.[8] CMS is interested in providing individuals with access to their health information similar to their approach with Blue Button 2.0.[9]
Lastly, the Proposed Rule addresses increasing the frequency of state/federal data exchange for Dual Eligible Beneficiaries, as well as hospitals with certified electronic health records technology (“CEHRT”) sending electronic admit, discharge, or transfer (“ADT”) notifications to another healthcare facility or community provider with an established care relationship with the patient.
Interoperability and APIs
The Department of Health and Human Services (“HHS”) has been tackling interoperability since 2004, when the ONC was formed via Executive Order 13335. The purpose of ONC is to promote a national health IT infrastructure and oversee its development.
In 2009, the Health Information Technology for Economic and Clinical Health Act (“HITECH”) addressed interoperability by authorizing CMS to make incentive payments to eligible professionals, hospitals, critical access hospitals and MA organizations to promote the adoption and meaningful use of CEHRT. Since 2010, ONC has maintained standards, implementation specifications, and certification criteria under which health IT developers can obtain certification. In 2015, Congress passed the Medicare Access and CHIP Reauthorization Act (“MACRA”), which declared it a national objective to achieve widespread exchange of information through interoperable CEHRT nationwide. Also in 2015, ONC released its ten (10) year plan for advancing interoperability laid out in the document “Connecting Health and Care for the Nation: A Shared Nationwide Interoperability Roadmap Version 1.0”[10]
ONC’s roadmap states that “in order for interoperability to function on a wide scale, the APIs (which represent the points of contact, or boundaries, between disparate systems) need to be consistent and standardized as much as possible.” While it may take time to achieve, ONC’s goal is a “learning health system” that converges “on a limited set of standard APIs to support a core set of services that enable electronic health information to flow when and where it is needed.”
CMS has proposed to require a variety of data be made accessible to MA enrollees, Medicaid beneficiaries, CHIP enrollees and enrollees in QHPs in FFEs by requiring the adoption and implementation of APIs. CMS believes the following attributes of APIs are key to achieve the goal of convenient access to electronic health information, including: (1) the API technologies are standardized; (2) the APIs are technically transparent; and (3) the APIs are implemented in a pro-competitive manner.
Taking each of these attributes in turn:
-
Standardized Technologies. The Proposed Rule requires that API technologies deployed by payors use modern computing standards and present the requested information using widely recognized content standards where applicable, which is needed in order to scale API-enabled interoperability and to reduce development costs. MA organizations, State Medicaid agencies, Medicaid managed care plans, State CHIP agencies, CHIP managed care entities and QHPs would be required to provide current and former enrollees with certain claims and encounter data and certain specific clinical information, in addition to provider directory and plan coverage information. CMS is proposing that these entities comply with ONC’s Cures Act proposed regulations[11] regarding content and vocabulary standards for representing e-health information and technical standards for an API by which the e-health information must be available. ONC’s proposed regulations include API interoperability standards proposed for HHS adoption.
-
Transparency. CMS is seeking to require MA organizations, State Medicaid agencies, Medicaid managed care plans, State CHIP agencies, CHIP managed care entities and QHPs to “make freely and publicly accessible the specific business and technical documentation necessary” to interact with APIs. CMS is proposing to require that API-documentation be publicly accessible – meaning any individual using commonly available technology to browse the internet could access the information without any preconditions or additional steps beyond downloading and using a third-party application.[12]
-
Pro-Competitive Implementation. CMS defines pro-competitive practices as those practices that promote the “efficient access to, exchange of, and use of electronic health information to support a competitive marketplace that enhances consumer value and choice of direct-to-consumer technology, health coverage and care.”[13] CMS called out the use of security and privacy concerns as an opportunity to engage in anti-competitive practices.
Under the Proposed Rule, the scope and volume of the information to be provided or made accessible through the open API would include:
-
Adjudicated claims (including cost)
-
Encounters with capitated providers
-
Provider remittances
-
Enrollee cost-sharing
-
Clinical data, including laboratory results.[14]
The Proposed Rule includes timeframe requirements for making these categories of data available through the open API. For example, MA plans would be required to have open API access to all claims activity pertaining to adjudicated claims and encounter benefits no later than one (1) business day after a claim is adjudicated or the encounter data is received by the plan.[15] CMS believes this proposed timeframe would ensure that data provided through the API would be the most current data available, which is important if the information is used by the enrollee’s provider to make clinical determination.
CMS is also proposing that the API make available provider directory data. For example, MA organizations would be required to make available the names of providers, addresses, phone numbers and specialty type. This is the same information that MA organizations are required to disclose to their enrollees under 42 CFR 422.111(b)(3) and make available online under 42 CFR 422.111(h)(2)(ii).[16]
Health Information Exchange and Care Coordination Across Payors
The Proposed Rule would require MA plans, Medicaid managed care plans, CHIP managed care entities, and QHPs in the FFEs to coordinate care between plans by sending the standardized set of health data classes and constituent data elements contained in the USCDI. The USCDI initiative from the ONC seeks to develop a minimum set of data that all electronic health record systems should be able to share. At the request of an enrollee, the payor must:
-
Receive the USCDI data from any other health care plan that has provided coverage to the enrollee within the preceding 5 years;
-
At any time an enrollee is currently enrolled in the plan and up to 5 years after disenrollment, send such data to any other health care plan that currently covers the enrollee; and
-
At any time the enrollee is currently enrolled in the plan and up to 5 years after disenrollment, send such data to a recipient designated by the enrollee.[17]
At this time, CMS is not specifying the means of exchanging USCDI data – recognizing that it anticipates that payors may opt to use APIs.
CMS is also proposing that MA plans, Medicaid managed care plans, CHIP managed care entities and QHPs in the FFEs to participate in trust networks in order to improve interoperability in these programs.[18] The trust exchange framework would need to meet the following criteria:
-
The trusted exchange network must be able to exchange protected health information, as defined under HIPAA;
-
The network must be capable of connecting inpatient EHRs and ambulatory EHRs; and
-
The network must support secure messaging or electronic querying by and between patients, providers and payers.
Dually Eligible Beneficiaries – Frequency of Federal-State Data Exchanges
Provisions in the Proposed Rule address improving the accuracy of data on dual eligibility status by increasing the frequency of federal-state data exchanges. CMS believes this is a “strong first step in improving how these systems work together.”[19] CMS is proposing that states that participate in the state buy-in (payment of Medicare premiums on behalf of certain individuals) exchange buy-in data with CMS on a greater frequency – states must exchange data with CMS on a daily basis. Additionally, CMS is proposing that states send information on dual eligibility status (termed the MMA file) on a daily basis.
Proposal for Hospitals
CMS is also proposing to revise the Conditions of Participation (“COPs”) for Medicare and Medicaid participating hospitals at 42 C.F.R. 482.24 by adding a new standard titled “Electronic Notifications.”[20] This standard would require hospitals to send electronic patient event notifications of a patient’s inpatient admission, discharge, and/or transfer to another health care facility or to another community provider. At a minimum, hospitals would need to demonstrate that the system sends notifications directly, or through an intermediary that facilitates exchange of health information, and at the time of the patient’s admission to the hospital, to licensed and qualified practitioners, other patient care team members, and post-acute care services providers and suppliers
[1] 84 Federal Register 7610, March 4, 2019 (https://www.govinfo.gov/content/pkg/FR-2019-03-04/pdf/2019-02200.pdf)
[2] https://www.congress.gov/114/bills/hr34/BILLS-114hr34enr.pdf.
[4] 84 Federal Register 7610, 7611.
[5] Id.
[6] 84 Federal Register 7610, 7640.
[7] https://www.healthit.gov/api-education-module/story_content/external_files/hhs_transcript_module.pdf.
[11] https://www.govinfo.gov/content/pkg/FR-2019-03-04/pdf/2019-02224.pdf.
[12] 84 Federal Register 7610, 7634.
[13] 84 Federal Register 7610, 7620.
[14] 84 Federal Register 7610, 7628.
[15] 84 Federal Register 7610, 7632.
[16] 84 Federal Register 7610, 7633.
[17] 84 Federal Register 7610,
[18] 84 Federal Register 7610, 7642.
[19] 84 Federal Register 7610, 7643.
[20] 84 Federal Register 7610, 7650.
