The Importance of Interoperability Rules Compliance For Payers, Providers

Fewer errors, improved safety, lower costs, better productivity: These are the promises of interoperability in any industry. Interoperability generally refers to setting up two or more systems to exchange data—and in healthcare, there are an incredible number of systems in play.

Patients receive medical care from physician practice offices, outpatient clinics, ambulatory surgery centers, and hospitals. Within those entities’ systems lies information about a patient’s medical history—past symptoms, procedures, lab results, medications, allergies, and complications—all of it essential for care coordination and payer reimbursement of provider services. 

Without interoperability rules, it’s impossible to share medical information to ensure the provision of safe, coordinated care because health data is stored in different formats, systems, and locations within and among healthcare organizations. 

When health data flows freely yet securely among patients, providers, and payers, the results are better coordinated care, improved health outcomes, and reduced costs. 

To help remedy the disconnects among healthcare technologies, the Centers for Medicare and Medicaid Services (CMS) has instituted interoperability rules. The rules aid in the exchange, interpretation, and use of health information to ultimately enhance healthcare delivery. Seamless data exchange provides a holistic view of patients’ health information, improving care coordination and efficiency by eliminating repetitive procedures (e.g., repeated diagnostic tests) and administrative tasks such as data entry.

Here’s what CMS-regulated payers need to know about the interoperability rules.

Policies and technology for interoperability rules

Application programming interfaces (APIs) improve the electronic exchange of healthcare data by sharing health information with patients or exchanging information between a payer and provider or between two payers. APIs connect software systems such as electronic health records (EHRs), practice management systems, payer claims platforms, and patient mobile apps for seamless information exchange.

APIs support fast healthcare interoperability resources (FHIR)—a standard for exchanging healthcare information electronically. FHIR allows clinicians and organizations to represent and share patient health information in a standard way regardless of the different ways local EHRs and other software systems represent or store the data.

Two CMS interoperability rules—one final (the Interoperability and Patient Access Final Rule) and one proposed (the Interoperability and Prior Authorization Proposed Rule)—require or encourage CMS-regulated payers to implement APIs.

The Interoperability and Patient Access Final Rule 

This CMS’ final rule is designed to put patients first, giving them access to their health information when they need it most and in a way they can best use it. CMS-regulated payers must implement and maintain two secure, standards-based Health Level 7 (HL7) FHIR Release 4.0.1 APIs. They must also exchange data with other payers at the patient’s request.

This rule applies to payers including:

• Medicare Advantage organizations
• Medicaid Fee-for-Service (FFS) programs
• Medicaid managed care plans
• Children’s Health Insurance Program (CHIP) FFS programs
• CHIP-managed care entities
• Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs) (must follow some but not all policies)

CMS requires payers to implement and maintain the following:

1. Patient Access API: This API allows patients to easily access their claims and encounter information, including cost (specifically, provider remittances and enrollee cost-sharing), as well as a defined subset of their clinical information through third-party applications of their choice. Claims data, used in conjunction with clinical data, provide information about an individual’s interactions with the healthcare system, leading to better decision making and better health outcomes. 
2. Provider directory API: This API makes complete, accurate, and current provider directory information available via a public-facing digital endpoint on the payer’s web site. The provider directory, which includes current contact information, helps patients find the right providers who are in-network and accepting new patients. Clinicians use the directory to find other in-network providers for referrals and care coordination.
3. Payer-to-payer data exchange: CMS-regulated payers are also required to exchange certain patient clinical data—specifically the U.S. Core Data for Interoperability (USCDI) version 1 data set—at the patient’s request, allowing the patient to take their information with them as they move between health plans over time. This data exchange (incorporating data within the past five years) facilitates the creation of a cumulative health record with the patient’s current payer. Having a patient’s health information in one place enables informed decision-making and efficient care, ultimately leading to better health outcomes.

Medicaid agencies, Medicaid managed care plans, CHIP agencies, and CHIP managed care entities should also refer to CMS’ letter to state officials, describing how states should implement the Interoperability and Patient Access Final Rule.

Finally, by April 1, 2022, state Medicaid agencies must exchange certain data with CMS daily on beneficiaries who are dually eligible for Medicaid and Medicare. Currently, many states and CMS exchange this data as infrequently as monthly, delaying coverage status changes and leading to inaccuracies, recoupments, and poor customer experiences. Improving the accuracy and timeliness of dual eligibility status data will improve how these systems work together for beneficiaries, providers, and payers.

The Interoperability and Prior Authorization Proposed Rule

This proposed rule, which builds on the Interoperability and Patient Access Final Rule, is designed to improve the electronic exchange of healthcare data and streamline prior authorization processes. It would place new requirements on the following payers:

• Medicaid managed care plans
• CHIP-managed care plans
• State Medicaid FFS programs
• CHIP FFS programs
• QHP issuers on the FFEs

The Interoperability and Prior Authorization Proposed Rule includes five sets of proposed policies:

1. Patient access API additions. Beginning January 1, 2023, payers would be required to provide information about patients’ pending and active prior authorization decisions. This information would help patients better understand the prior authorization process and its impact on their care. Payers would be required to submit quarterly reports about patient use of the patient access API so CMS can evaluate the impact of the API on patients. Payers would also need to establish a process for third-party application developers to attest to privacy policy provisions, allowing users to be sure their health information is secure before they retrieve it via the API.

2. Provider access API. Beginning January 1, 2023, payers would be required to develop and maintain a provider access API for payer-to-provider sharing of claims and encounter data (excluding cost data), a subset of clinical data (defined by the USCDI version 1), and prior authorization data. This information sharing would improve care coordination and support a move to value-based care.

• Document requirement lookup service (DRLS) API. Payers would be required to build and maintain an FHIR-enabled API—that could be integrated with the EHR—to allow providers to easily locate prior authorization requirements for each payer.
• Prior authorization support (PAS) API. Payers would need to build and maintain an FHIR-enabled API that allows providers to easily send prior authorization requests and receive responses electronically [while complying with the Health Insurance Portability and Accountability Act (HIPAA) transaction standards].
• Denial reason. Payers would need to include a specific reason for denying a prior authorization request (however the decision was sent), to improve communication and understanding between the provider and payer.
• Shorter prior authorization time frames. Payers (excluding QHP issuers on the FFEs) would be required to send prior authorization decisions within 72 hours for urgent requests and within seven calendar days for standard requests.
• Prior authorization metrics. Payers would need to report data about their prior authorization process, such as the percent of prior authorization requests approved, denied, and ultimately approved after appeal, and average time between submission and determination, to increase transparency and patient understanding of the process. The initial reports would be due by March 31, 2023.

• Payer-to-payer API additions. Payers would be required to exchange information with other payers via a FHIR-based payer-to-payer API. An FHIR-based API is currently recommended but not required. In addition to sharing clinical data, payers would also be required to exchange claims and encounter data (excluding cost data) and prior authorization decision data at a patient’s request.
• Payer-to-payer data exchange at enrollment. Payers would be required to share claims and encounter data (excluding cost data), a subset of clinical data as defined in the USCDI version 1, and prior authorization information at enrollment, for payers that have a specific annual open enrollment period, or during the first calendar quarter of each year. This would allow patients to take their health information with them as they move to a new payer.
• Prior authorization decisions. New payers would be encouraged to consider prior authorization decisions from previous payers when making new determinations. This would prevent patients and providers from repeating the prior authorization process with the new payer.

5. Adoption of health IT standards and implementation specifications. The Office of the National Coordinator for Health IT (ONC) is proposing to adopt the API Standards and Implementation Specifications as standards and implementation specifications for healthcare operations. Adopting the specified implementation guides to support implementation of the proposed APIs would ensure full interoperability of the APIs and reduce implementation burden.

Technical standards

The U.S. Department of Health and Human Services (HHS) has finalized three technical standards and one content/vocabulary standard to help payers and developers comply with the Interoperability and Patient Access Rule.

HL7 FHIR Standard

Ensuring the privacy and security of patient information is a top priority for CMS. Identifying the right standards can help data flow securely and efficiently. CMS, in partnership with the ONC, has identified HL7 FHIR Release 4.0.1 as the foundational standard to support secure, private data exchange via secure APIs.

The interoperability rules require that developers use FHIR version 4.0.1 as the technical standard underpinning the APIs that healthcare apps use to exchange data with other apps and information systems. The HL7 FHIR standard defines how healthcare information can be exchanged between different computer systems regardless of how it is stored in those systems. It allows healthcare information, including clinical and administrative data, to be available securely to those who need—and have the right—to access that information for the benefit of patients receiving care.

Health plans must use the FHIR standard to make these five types of data available: 1) adjudicated claims; 2) encounters with capitated providers; 3) provider remittances; 4) enrollee cost-sharing; and 5) clinical data, including laboratory results.

HHS officials expect that many payers and health systems will use smartphone apps to provide health information to patients. Thus, FHIR enables apps to plug directly into EHR systems or claims databases to obtain patient health data.

SMART App Launch/OAuth 2.0 Standard

The SMART App Launch framework connects third-party applications to EHR data, allowing apps to launch from inside or outside the user interface of an EHR system. The framework supports apps for use by clinicians, patients, and others via a personal health record (PHR), patient portal, or any FHIR system where a user can give permission to launch an app. It also supports patient apps that launch standalone or from a portal, as well as provider apps that launch standalone or from a portal.

SMART on FHIR provides reliable, secure authorization for a variety of app architectures with the OAuth 2.0 standard, including apps that run on an end-user’s device as well as apps that run on a secure server. This profile is intended to be used by app developers who need to access FHIR resources by requesting access tokens from OAuth 2.0 compliant authorization servers. The profile defines a method through which an app requests authorization to access a FHIR resource, and then uses that authorization to retrieve the resource.

OpenID Connect Standard

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables clients to verify the identity of an end-user based on the authentication that an authorization server performs, and obtains basic profile information about the end-user in an interoperable and REpresentational State Transfer (RESTful) manner. This specification defines the core OpenID Connect functionality—authentication built on top of OAuth 2.0 and the use of claims to communicate information about the end-user. It also describes the security and privacy considerations for using OpenID Connect.

U.S. Core Data for Interoperability (USCDI) Content Standard

CMS requires that payers share the USCDI data they maintain with patients via the patient access API, and with other payers via the payer-to-payer data exchange. The USCDI is a standardized set of health data classes and component data elements for nationwide, interoperable health information exchange. A data class is an aggregation of various data elements by a common theme or use case, such as patient demographics, vital signs, allergies and intolerances, assessment and plan of treatment, encounter information, clinical notes, clinical tests, laboratory tests, and medications. A data element is the most granular level at which a piece of data is exchanged (i.e., the unit of exchange), such as date of birth, heart rate, substance (medication), SDOH assessment, encounter diagnosis, discharge summary note, clinical test result, laboratory test result, and specific medication.

Patient privacy and security resources

The Interoperability and Patient Access Final Rule requires CMS-regulated payers to provide patient educational resources in an easily accessible location on their public web sites or through other channels used for regular patient communication. These patient resource documents must be written in non-technical, simple, and easy-to-understand language that explains, at a minimum, the following:

• General information on steps the individual may consider taking to help protect the privacy and security of their health information, including factors to consider in selecting an application (e.g. secondary uses of data). The document should emphasize the importance of understanding the security and privacy practices of any application to which they will entrust their health information.
• An overview of which types of organizations or individuals are, and are not, likely to be HIPAA-covered entities; the oversight responsibilities of the Office for Civil Rights (OCR) and the Federal Trade Commission (FTC); and how to submit a complaint to OCR and the FTC.

The CMS Interoperability and Patient Access final rule also encourages affected payers to ask third-party app developers to attest to having certain provisions in their privacy policy. Payers that ask for this attestation should share with patients (as part of their educational resources) a clear explanation of what the attestation is asking and how the process will work. It is important for payers to ensure that patients understand that if an app developer is asked to attest and does not respond to this request or attests negatively, the patient will have an opportunity to change their mind about sharing their data. But, if the patient does not actively respond to the payer within the period of time clearly communicated to them by the payer, the patient’s data will be shared as they originally requested.

Efficient data management is the foundation of interoperability. symplr Payer automates credentialing, provider relations, and contracting workflows while acting as a single source of truth for provider data management. Our software enhances your health plan or managed care organization’s compliance and efficiency, enabling you to provide adequate and competent care for member populations.