Introduction
Last year, the Centers for Medicare & Medicaid Services (CMS) and Office of the National Coordinator for Health Information Technology (ONC) each finalized federal rules pertaining to the use, storage and exchange of electronic health information. Together these rules are known as the interoperability rules. In prior blogs, we provided an overview of what is in the rules and some of the anticipated implementation challenges. In this blog, we take a closer look at requirements in the rules that are the responsibility of health plans and other payers. Most of these requirements are in the CMS rule.
Given the large scope of requirements, in this blog we detail which plans are impacted by the rules, as well as the requirement to develop two application programming interfaces (APIs). These APIs are a cornerstone of the interoperability initiatives intended to ease and modernize access to patient data in order to optimize the value of such data for care coordination, risk management, and—ultimately— patient outcomes. In a Part II to this blog, we will describe new requirements related to managing access to the APIs, payer-to-payer data exchange, and educated patients on API privacy and security issues, as well as expected costs to health plans.
Which Health Plans are Impacted?
The CMS final rule applies to most public payer entities across Medicare, Medicaid, and Children’s Health Insurance Plans (CHIP). Thus, Medicare Advantage (MA) plans (including Medicare Advantage D-SNPs), and Medicaid and CHIP managed care plans (including state Medicaid and CHIP agencies that offer fee-for-service programs) must all comply with the new regulations. Certain public payer entities that are excluded include Medicare cost plans, stand-alone prescription drug plans, and Program of All-Inclusive Care for the Elderly (PACE) organizations.
On the commercial side, the rule applies to qualified health plans (QHPs) through the federal marketplace. QHPs offered through state-based marketplaces on the federal platform are excluded, as they are technically not federal marketplaces (even though they are on HealthCare.gov). However, state-based marketplaces are encouraged to consider adopting similar requirements. Also, many health plans have a parent organization that offers products more broadly in the commercial market. Because of this, CMS notes the possibility that parent organizations will extend the rule’s interoperability benefits to enrollees in plan products outside of QHPs sold through the federal marketplace.
The final rule does include a potential exception for QHPs that are covered. That is, if a QHP insurer does not believe it can meet the rule’s requirements, the federal marketplace can grant an exception if it determines that the QHP, even without the interoperability requirements, is in the interests of potential enrollees. CMS expects an exception to be granted in limited circumstances such as when a health plan is a new market entrant and demonstrates that deploying standards-based API technology consistent with the required interoperability standards would pose a significant barrier to the plan’s ability to provide coverage.
Employer-sponsored health insurance plans are exempted. In addition, plans offered through Small Business Health Options Program (SHOP) exchanges and stand-alone dental plans are exempted.
In total, CMS estimates that about 110 million enrollees covered by payers in the individual market, Medicaid, CHIP, and MA programs will be impacted.
Development of Two APIs
The interoperability rules lay out a vision where a patient’s health information can move seamlessly between health plans and providers and where every patient can see and use electronic health information through common technologies such as smart phones and laptops. Patients would be able to access their full claims history and encounter data, even if they received care by multiple health care providers, each using different electronic health record systems. To help make this vision a reality, the rules require the development of two application programming interfaces (APIs); one for patient claims and encounter information known as the Patient Access API and another for health plan provider directory information known as the Provider Directory API.
APIs are applications and interfaces that permit information to be exchanged between multiple and disparate platforms securely and efficiently. APIs can connect to third-party software applications, enabling developers and tech companies to create new apps that allow individuals to use the data. CMS lacks the authority to require payers to use APIs to promote interoperability and data access, but the rule does require payers to make data accessible through secure, standards-based APIs. Below is an overview of what is required by plans for the Patient Access and Provider Directory APIs.
Patient Access API
By July 2021, payers must implement a standards-based API that allows third-party apps (with approval from the patient) to easily retrieve approved and denied claims data, encounter data from capitated providers, and clinical data that is maintained by the payer (including lab results). Claims and encounter data must include enrollee identifiers, dates of service, payment information, and enrollee cost-sharing.
MA plans that offer prescription drug plans must include claims data for covered Part D drugs and formulary data (e.g., tiered formulary structure and utilization management procedures). Medicaid and CHIP entities must similarly include information about covered outpatient drugs and updates to preferred drug list information. In addition, Medicaid or CHIP entities must include information on all covered services, including long-term services and supports, in-home care, and transportation services. Future rule-making will consider the possible inclusion of additional services, such as prior authorization decisions and drug pricing.
Claims, encounter, and clinical data must be available through the patient access API no later than one business day after a claim is processed or the data is received by the payer. Payers must include any data in the API that they have with a date of service on or after January 1, 2016. CMS notes that a look-back period to 2016, as opposed to a shorter timeframe, helps ensure value to the patient. CMS also considered burden to payers when implementing a limit to the look-back period and also noted that not all patient data (such as an x-ray image) may be transferable through the API.
In general, apps can only access the API at the direction of, and with approval from, a patient. However, there may be instances when patients ask a payer to send health information to a provider’s third-party app on a one-off or as-needed basis. Thus, HIPAA-covered entities may be able to obtain an individual’s health information from an app—for treatment, payment, or other health care operations purposes—without needing the patient’s authorization, so long as doing so is consistent with HIPAA privacy rules.
Provider Directory API
Also by July 2021, payers must implement a public-facing API for provider directory information, which would be separate from the patient access API. CMS did not require the provider directory information to be included in the patient access API in part to avoid confusion. QHP insurers are excluded from this requirement as they are already required to make a provider directory accessible in a machine-readable format.
This provider directory API data must include, at a minimum, provider names, addresses, phone numbers, and specialties. MA plans that offer Part D plans must also provide pharmacy directory data (e.g., pharmacy name, address, phone number, and the type of pharmacy). Although not required, payers are also encouraged to include additional information, such as practice group, health system name, and the plans and tiers that a provider participates in.
Changes to a plan’s provider directory data must be updated for the API within 30 business days in order to help ensure accuracy of the information. CMS will audit a random sample of payer websites for publicly accessible APIs in order to evaluate compliance.
Conclusion
The rules originally required the APIs to be operational by January 1, 2021. In recognition of pressing priorities due to the pandemic, CMS delayed the start date by six months. This is still a tight timeframe for implementation. Decisions will need to be made quickly by health plans. In order to help, CMS has made best practices available for everything from privacy notices to API testing tools.
In Part II of this blog, we will describe additional requirements on health plans related to managing access to the APIs, payer-to-payer data exchange, and educated patients on API privacy and security issues, as well as expected costs of implementation.