Introduction
In the previous blog, we began discussing key provisions of the interoperability rules that impact health plans. We detailed which health plans and other payers (e.g., State Medicaid agencies) are impacted by the rules and the new requirements for health plans to develop two application programming interfaces (APIs). Plans must make patient claims and encounter information available through a Patient Access API and health plan provider directory information through a Provider Directory API. These APIs are a cornerstone of the interoperability rules, which have the aim 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 this blog, we describe additional key provisions in the interoperability rules that impact health plans; including: new requirements related to managing access to the APIs, payer-to-payer data exchange, and educating patients on API privacy and security issues. These provisions are largely intended to help ensure that the two APIs actualize their potential. We also describe the expected costs to health plans associated with operationalizing the interoperability requirements.
Managing Access to the APIs
Health plans and other payers must allow third-party apps to access their APIs. That is, at the direction of a patient, third-party apps must be able to access the APIs through common consumer technologies like laptops, tablets, and smart phones and be able to request, use, and approve the transfer of data “without special effort” (words from the CMS final rule). Plans must ensure that APIs function properly by conducting routine testing and monitoring and ensuring appropriate privacy and security features. While CMS does not specify the testing required, it is providing information on best practices for testing and monitoring.
APIs must be publicly accessible on a payer’s website and accompanied by documentation on technical aspects (such as API syntax and software needed for the API to function). Payers cannot require a reader to pay a fee to access documents, receive a copy via email, or agree to receive promotional communications before making the documentation available.
Health plans and other payers also cannot require a business agreement or additional security audits with third-party app developers. However, payers can deny or discontinue a third party’s connection to their API if it determines (using objective, verifiable and HIPAA-consistent criteria) that the connection poses an unacceptable security risk of its protected health information. Payers can also request that third-party apps attest to having certain privacy and security provisions in their privacy policy before the payer provides access to its API. For example, payers could request that a third-party app has a publicly available privacy policy that has been affirmatively shared with the patient a priori. If an app fails such attestations, the payer can inform the patient and allow the patient to cancel their request. If the patient does not cancel (or respond), the payer must still honor the patient’s request and share their data with the third-party app.
The APIs must comply with technical standards for content and authentication laid out in the ONC portion of the interoperability rules. Health plans and other payers can use alternative standards for additional or optional data made available through the API. Because the data on the provider directory API utilizes publicly accessible information, the provider data API does not have to meet certain authentication and authorization standards laid out in the ONC rule.
Data Exchange Between Payers
By January 1, 2022, all payers (except state Medicaid and CHIP agencies) must implement a process enabling electronic health data to be exchanged between payers. Payers may use different means to exchange data. For example, plans may use APIs similar to the patient access API to conduct direct plan-to-plan exchanges. Regional health information exchanges could also be used for areas where one exists.
At a minimum, health plans and other payers must be able to electronically exchange data classes and elements outlined in the ONC rule, which are based on version one of the United States Core Data for Interoperability (USCDI) standards. Payers must exchange data only when requested and approved by an enrollee or their representative and need only send data from 2016 onwards. Payers that receive electronic health data from other payers must incorporate that data into their record for the enrollee and maintain it even after the enrollee leaves the payer’s plan. If an enrollee requests it, a payer must receive data from an enrollee’s prior health plan from the past five years, and be able to send data to other payers for up to five years. Payers do not have to update, validate, or correct data from another payer. The data from another payer can be shared in the format that it was received. Payers can also choose to identify the data as received from a prior payer so that questions about the integrity of the data can be directed to that entity.
Addressing Privacy and Security Concerns
Both the ONC and CMS interoperability rules include extensive discussion on privacy and security concerns of requirements that payers and other entities must meet. Of particularly note is that health plans and other payers are not responsible for determining whether a particular app selected by a patient includes appropriate safeguards. Under prior guidance from the Department of Health and Human Services (HHS) Office for Civil Rights, payers are not responsible for the security of protected health information once it has been received by a third-party app. The interoperability rules also recognize that the direct-to-consumer apps are not subject to many current laws that protect the privacy and security of electronic health information, such as the Health Insurance Portability and Accountability Act (HIPAA). Rather, third-party app developers, as non-covered entities, would be regulated by relevant state laws and by the Federal Trade Commission (FTC), which regulates unfair or deceptive trade practices and enforces the Health Breach Notification Rule.
As discussed above, health plans and other payers cannot deny access to a third-party app selected by a patient unless the app presents an unacceptable security risk to the payer’s own system. However, it is expected that payers educate patients and give advice about concerns regarding a specific app. In fact, the CMS interoperability rule requires health plans to provide educational resources to help enrollees become more informed about how to protect their information, factors to consider in selecting an app, a discussion of potential secondary uses of data by third-party apps, and where to submit a complaint if their data has been exposed or misused.
The educational information must be in an easy-to-use and -understandable format and be available through various mechanisms used to communicate with current and former enrollees (that are separate from the APIs), such as on the health plan’s website, as well as customer portals and help desks. To help alleviate the burden to health plans, CMS is making suggested content available that plans can adapt for their members (e.g., for the different languages spoken and other factors relevant to the populations they serve).
API Implementation Costs
In the CMS interoperability rule, CMS estimates first-year implementation to require roughly 17,000 hours of work and cost $1.6 million per health plan parent organization (these figures are based on the mid-range or “primary” CMS estimates). CMS thus estimates initial API development to cost 345 parent organizations well over $500 million, followed by over $50 million in annual maintenance costs. Even at these levels, CMS believes these costs are relatively minimal relative to payers’ overall budgets.
CMS also notes that it is likely that much of the cost of API development and maintenance will be passed on to consumers, states and the federal government in the form of higher premiums, program funding, and tax subsidies. CMS believes that the benefits to patients will exceed any increased premium costs.
Medicare Advantage (MA) plans must reflect the cost of compliance in their bids. States must include the costs of developing the API in Medicaid managed care capitated rates that are eligible for federal matching funds.
CMS also expects that the costs associated with data exchange between payers will qualify as “quality improvement activities” for purposes of an insurer’s medical loss ratio (MLR). According to MLR regulations created by the Affordable Care Act, health plans in the individual and small group markets must spend a minimum of 80 percent of premium revenue on medical claims and quality improvement activities; this ratio is 85 percent in the large group market. The remainder of premium revenue can go towards profit and administrative costs (e.g., broker fees and marketing). Thus, if the API expenses are counted as quality improvement activities, it would be counted against an insurer’s requirement to spend 80 or 85 percent of premium revenue on claims and quality improvement. This standing is in alignment with the belief that such data sharing will help improve the care coordination of patients, but may be an issue that gets revisited in future rule-making.
Conclusion
By the middle of 2021, key interoperability provisions for health plans, including the patient access and provider directory APIs will begin to be available for consumer use. Given the investments expected of health plans to effectively implement the requirements, there is incentive to maximize such efforts.
Greater interoperability brings exciting opportunities for health plans, providers and patients to work together in improving the health care that is delivered. The improved technology standards can allow plans to improve their capacity to facilitate effective patient care coordination while also leading to more efficient plan operations. The opportunities and investments will only mount as additional interoperability requirements go into effect in 2022 and beyond. CMS and ONC are expected to provide additional detail for certain interoperability provisions in future rule-making, while also updating requirements based on early results and best practices.