On September 17, 2020, the Office of Management and Budget received an Interim Final Rule for review from the Office of the National Coordinator for Health IT (ONC) entitled “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency.” While the title suggests that health care providers and other regulated actors may have more time to come into compliance with ONC’s May 2020 information blocking final rule, details about potential delays remain scarce and health care providers would be well served to continue apace with compliance efforts, even if the original November 2, 2020 information blocking compliance date ultimately shifts.

This is particularly true for hospitals and health systems that might also function in the capacity of a health information technology (IT) developer of certified health IT (Certified Health IT Developer) or health information network or health information exchange (HIN/HIE), because Certified Health IT Developers and HIN/HIEs face potential civil monetary penalties (CMPs) from the HHS Office of Inspector General (OIG)—as opposed to the yet undefined “appropriate disincentives” health care providers face. OIG is currently engaged in its own rulemaking to finalize regulations implementing its information blocking CMP authorities. In its proposed rule, OIG stated that it would not enforce CMPs for violations of the information blocking regulations that occur after November 2, 2020, but before OIG finalizes the CMPs. It is not clear how, if at all, any change to the ONC’s information blocking compliance date would impact the timing of OIG’s final rule (which is not yet at OMB for review) and, ultimately, timing of enforcement actions. Given such uncertainty, continued effort to identify and address areas of potential non-compliance with ONC’s final rule is advisable, particularly for actors that face potential CMPs of up to $1M per violation. For more information on the OIG proposed rule, see our On the Subject.

To help health care providers that might also function as Certified Health IT Developers or HIN/HIEs identify potential areas of consideration and focus, we have developed the below resources. Please reach out to your McDermott lawyer or one of the contacts listed here to discuss your information blocking preparations.

Additional Resources

October 13 Webinar with The Chartis Group | APIs and Information Blocking: What Providers Need to Know
REGISTER

Visit McDermott’s Regulatory Sprint to Coordinated Care Resource page and subscribe for additional insights.

The Office of the National Coordinator for Health Information Technology recently released a final rule under the 21st Century Cures Act to promote interoperability of health IT and advance access, exchange or use of electronic health information (EHI). The final rule has significant implications for how health IT developers, health care providers and other stakeholders price access to application programming interfaces (APIs) and other technology used to access, exchange or use EHI. This On the Subject discusses the framework for determining whether license fees and other charges for use of such technology would comply with the final rule’s exceptions to the Cures Act’s information blocking prohibition and condition of certification for certified APIs.

On March 9, 2020, the Office of the National Coordinator for Health Information Technology (ONC) released its final rule under the 21st Century Cures Act to implement various policies to promote interoperability of health information technology (IT) and advance access, exchange or use of electronic health information (EHI) for continuity of care and other appropriate purposes. The final rule amends the certification requirements under the ONC Health IT Certification Program and identifies health IT pricing practices that do not fall under the Cures Act’s information blocking prohibition.

These final policies have significant implications for how certified health IT developers, health care providers, health information networks (HINs) and health information exchanges (HIEs) (collectively, actors) license and charge for technology to enable access, exchange or use of EHI with patients and other technology and service providers, health care providers and health plans.

Subject to limited exceptions, EHI covered by the information blocking prohibition includes electronic protected health information under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) regulations (EPHI) to the extent that the EPHI is part of a patient’s electronic medical record or another designated record set under HIPAA, regardless of whether the records are used or maintained by or for a HIPAA covered entity. However, until the date 24 months after the publication of the final rule in the Federal Register, EHI is limited to the data elements represented in the US Core Data for Interoperability (USCDI) standard adopted under the health IT certification provisions of the final rule.

This On the Subject discusses the analytical framework for determining whether license fees and other charges for use of application programing interfaces (APIs) and other technology used to access, exchange or use EHI comply with the final rule’s information blocking exceptions and condition of certification for certified APIs. It also recommends practical next steps for implementing the final rule’s fee restrictions.

For more information about the final rule, including provisions that are not directly related to fees and other charges, see McDermott’s prior Special Report comprehensively covering the information blocking provisions of the final rule.

Does the information blocking prohibition restrict charges for health IT used to access, exchange and use EHI?

The final rule generally defines information blocking to mean a practice by an actor that is likely to interfere with, prevent or materially discourage access, exchange or use of EHI unless the practice is required by law or covered by an exception in the final rule. Because of this broad definition, any fees or other charges that an actor charges patients, health care providers, health plans, technology or service providers or other third parties for access, exchange or use of EHI or technology to enable such access, exchange or use, potentially implicate the information blocking prohibition. Consequently, those fees and charges, unless required by law, would need to fit within an information blocking exception to protect the actor from potential information blocking liability.

What information blocking exceptions protect licensee fees and other charges for use of health IT used to access, exchange and use EHI?

The final rule includes the following three exceptions for license fees and other charges for interoperability elements and other fees for use of technology that may interfere with EHI access, exchange or use. A fee or other charge that meets the definition of information blocking must satisfy at least one of these exceptions:

• Content and Manner Exception
• Fees Exception
• Licensing Exception

Content and Manner Exception

The Content and Manner Exception allows an actor and a party that requests EHI to negotiate mutually agreeable terms (including fees) for access, exchange and use of EHI. To be protected under the Content and Manner Exception, the actor must respond to a request for EHI with the subset of EHI identified by the USCDI data elements until the date 24 months after the publication of the final rule in the Federal Register. After that date, actors must respond with all EHI in a designated record set as discussed above.

In terms of the manner of response, an actor must fulfill a request for access, exchange or use of the required content in the manner requested, unless (1) the actor cannot technically fulfill the request, or (2) the actor and requestor are unable to reach mutually agreeable terms. If an actor fulfills a request in the manner requested, the limitations in the Fee Exception and Licensing Exception would not apply. Thus, the actor would have the opportunity to negotiate mutually agreeable fees and other terms with requestors.

If the actor does not fulfill a request in the requested manner, then the actor must fulfill the request in one of three alternative manners specified in the exception without unnecessary delay. When an actor fulfills a request in an alternative manner, the fees charged would have to meet the Fees Exception or the Licensing Exception.

Fees Exception

The Fees Exception allows an actor to charge fees, including those that result in a reasonable profit margin, for accessing, exchanging or using EHI, provided that the fee is:

• Based on objective and verifiable criteria, uniformly applied for similarly situated people/requests;
• Reasonably related to the actor’s costs;
• Reasonably allocated among all similarly situated people; and
• Based on costs not already recovered for the same instance of the service to a provider or third party.

In addition, the fee must not be based on:

• Competitive considerations;
• Sales, profit, revenue or other value that the requestor or other party may derive from the access, exchange or use of the EHI;
• Costs that an actor incurs because it designed or implemented health IT in non-standard ways (unless the requestor agreed to the fee associated with such implementation);
• Costs associated with intangible assets other than actual development and acquisition costs;
• Opportunity costs unrelated to the access, exchange or use of EHI; or
• Any costs leading to the creation of intellectual property if the actor charges a royalty for that intellectual property under the Licensing Exception and the royalty includes development costs of creating that intellectual property.

Additionally, an actor may not charge any of the following fees under the Fees Exception:

• Fees prohibited under the HIPAA Privacy Rule for individuals’ requests for access to their protected health information;
• Fees based in any way on the electronic access of an individual’s EHI by the individual, the individual’s personal representatives or others designated by the individual (The final rule defines “electronic access” as “an internet-based method that makes EHI available at the time the EHI is requested and where no manual effort is required to fulfill the request.” So whenever fulfilling individuals’ requests to send EHI to themselves or their personal representatives or others they designate, if the process requires manual effort, such as collating or assembling electronic health records from multiple systems, then the definition of electronic access would not be met and the actor could charge a fee and meet the Fees Exception.);
• Fees to export EHI to switch health IT or provide EHI to patients, if done through a capability certified to the final rule’s EHI export health IT certification criterion at 45 CFR § 170.315(b)(10) (Certified EHI Export Capability); and
• Fees to export or convert data from an EHR system, unless the parties agreed to the fee in writing at the time the EHR system was acquired.

In addition, this exception requires health IT developers that create certified API technology (certified API developers) to comply with the new condition of certification for certified APIs as a condition of meeting the Fees Exception.

Licensing Exception

Under the Licensing Exception, an actor’s terms (including those related to fees) for licensing an interoperability element for EHI to be accessed, exchanged or used is not prohibited information blocking when the practice meets all of the conditions discussed below. The final rule defines the term “interoperability element” to mean “hardware, software, integrated technologies or related licenses, technical information, privileges, rights, intellectual property, upgrades, or services that (1) may be necessary to access, exchange or use EHI and (2) are controlled by the actor. Such control includes the ability to confer all rights and authorizations necessary to use the element to enable the access, exchange or use of EHI.”

Upon receiving a request to license an interoperability element for the access, exchange or use of EHI, the actor must begin license negotiations with the requestor within 10 business days from receipt of the request and negotiate a license with the requestor, subject to the licensing conditions below (and other requirements of the Licensing Exception), within 30 business days from receipt of the request. The license for the interoperability element must meet the following conditions:

• Scope of Rights. The license must provide all rights necessary to: enable the access, exchange or use of EHI and to achieve the intended access, exchange or use of EHI via the interoperability element.
• Reasonable Royalty. If the actor charges a royalty for the use of the interoperability element, the royalty must be reasonable and comply with the following requirements:
  • The royalty must be non-discriminatory, consistent with the non-discriminatory terms requirement below.
  • The royalty must be based solely on the independent value of the actor’s technology to the licensee’s products, not on any strategic value stemming from the actor’s control over essential means of accessing, exchanging or using EHI.
  • If the actor has licensed the interoperability element through a standards developing organization in accordance with its policies regarding the licensing of standards-essential technologies on terms consistent with the licensing exception, the actor may charge a royalty that is consistent with such policies.
  • An actor may not charge a royalty for intellectual property if the actor recovered any development costs pursuant to the Fees Exception that led to the creation of the intellectual property.

In the final rule preamble, ONC notes that whether a royalty is reasonable for purposes of the Licensing Exception requirement depends on the particular facts and circumstances. ONC also identifies the following non-exclusive list of potential factors for evaluating reasonableness:

• The royalties received by the actor for the licensing of proprietary elements in other circumstances comparable to reasonable and non-discriminatory licensing circumstances.
• The rates paid by the licensee for the use of other comparable proprietary elements.
• The nature and scope of the license.
• The effect of the proprietary elements in promoting sales of other products of the licensee and the licensor, taking into account only the contribution of the elements themselves and not of the enhanced interoperability that they enable.
• The utility and advantages of the actor’s interoperability element over the existing technology, if any, that had been used to achieve a similar level of access, exchange or use of EHI.
• The elements’ contribution to the technical capabilities of the licensee’s products, taking into account only the value of the elements themselves and not the enhanced interoperability that they enable
• The portion of the profit or selling price that may be customary in the particular business or in comparable businesses to allow for the use of the proprietary elements or analogous elements that are also covered by reasonable and non-discriminatory terms commitments.
• The portion of the realizable profit that should be credited to the proprietary elements as distinguished from non-proprietary elements; the manufacturing process; business risks; significant features or improvements added by the licensee; or the strategic value resulting from the network effects, switching costs, or other effects of the adoption of the actor’s technology.
• The opinion testimony of qualified experts.
• The amount that a licensor and a licensee would have agreed upon (at the time the licensee began using the elements) if both were considering the reasonable and non-discriminatory terms obligation under the Licensing Exception and its purposes, and had been reasonably and voluntarily trying to reach an agreement.
• Non-Discriminatory Terms. The royalty and other terms on which the actor licenses and otherwise provides the interoperability element must be non-discriminatory and comply with the following requirements:
  • The terms must be based on objective and verifiable criteria that are uniformly applied for all similarly situated classes of persons and requests.
  • The terms must not be based in any part on:
    • Whether the requestor or other person is a competitor or potential competitor, or will be using EHI obtained via the interoperability elements in a way that facilitates competition with the actor; or
    • The revenue or other value the requestor may derive from access, exchange or use of EHI obtained via the interoperability elements.

Accordingly, the royalty or other compensation terms in the license agreement for the interoperability element may not be a revenue share based on the revenue that the licensee generates from EHI transferred through the interoperability element.

How does the condition of certification for APIs affect license fees and other charges?

ONC finalized a condition of certification for certified APIs that includes, among other requirements, restrictions on the pricing practices of certified API developers. The requirements directly applicable to the fee restrictions are as follows:

• Permitted Fees Generally. The condition of certification permits certified API developers to charge three categories of permitted fees and expressly allows the permitted fees to include a reasonable profit margin otherwise in accordance with the Fees Exception. All other fees related to certified API technology are prohibited. A certified API developer must ensure that:
  • All permitted fees are based on objective and verifiable criteria that are uniformly applied to all similarly situated hospitals, physician practices and other organizations that deploy certified API technology (API information sources), and persons or entities that create or use software applications that interact with the certified API technology (API users).
  • Permitted fees imposed on API information sources are reasonably related to the certified API developer’s costs to supply certified API technology to, and if applicable, support certified API technology for, API information sources.
  • Permitted fees to supply and support certified API technology are reasonably allocated among all similarly situated API information sources.
  • Fees are not based on whether API information sources or API users are competitors or potential competitors, or will use the API in a way that facilitates competition with the certified API developer.
• Three Categories of Permitted Fees. The condition of certification permits the following categories of fees for certified API technology:
  • Permitted Fee: Development, Deployment and Upgrades. A certified API developer may charge fees to an API information source to recover the costs reasonably incurred by the certified API developer to develop, deploy and upgrade certified API technology.
  • Permitted Fee: Recovering API Usage Costs. A certified API developer may charge fees to an API information source related to the use of certified API technology, provided that the fees are limited to the recovery of incremental costs reasonably incurred by the certified API developer when it hosts certified API technology for the health care provider or other API information source.
  • Permitted Fee: Value-Added Services. A certified API developer may charge fees to an API user for value-added services related to certified API technology, as long as the services are not necessary to efficiently and effectively develop and deploy production-ready software that interacts with the certified API technology.
• Prohibited Fees. Consistent with the Fees Exception, the condition of certification prohibits a certified API developer from charging a fee for:
  • Costs associated with intangible assets other than actual development or acquisition costs of such assets;
  • Opportunity costs unrelated to the access, exchange or use of EHI; and
  • Any costs that led to the creation of intellectual property if the actor charged a royalty for that intellectual property pursuant to the Licensing Exception and the royalty included the development costs for the creation of the intellectual property.
• Non-Discrimination. A certified API developer must meet the following non-discrimination requirements when setting fees and other terms with respect to certified API technology:
  • Provide the certified API technology to an API information source on terms that are no less favorable than the certified API developer provides to itself and its own customers, suppliers, partners and other persons with whom it has a business relationship;
  • Base the terms for the provision of certified API technology on objective and verifiable criteria that are uniformly applied to all substantially similar or similarly situated classes of persons and requests;
  • Not offer different terms or services based on whether a competitive relationship exists or would be created; and
  • Not offer different terms or services based on the revenue or other value that another party may receive from using the API technology.
• Description of API Fees. The certified API developer must describe all fees that it charges for the use of its certified API technology in detailed, plain language. The description must include all material information, including the persons or classes of persons to whom the fee applies; the circumstances in which the fee applies; and the amount of the fee, which for variable fees must include the specific variables and methodologies used to calculate the fee.
• Record-Keeping Requirements. A certified API developer must keep detailed records of any fees charged with respect to the certified API technology, the methodologies used to calculate the fees and the specific costs to which such fees are attributed. In the final rule preamble, the ONC states it expects that “the accounting practices already used by health IT developers will largely support the health IT developer to meet this requirement. Examples of these practices by health IT developers include the methods used to track their own investments, determine how to bill and issue invoices to their customers, document receipt of payment, and to maintain overall accurate financial records of business transactions.”

What is the analytical framework for determining whether charges for health IT comply with an information blocking exception under the final rule and, if applicable, the condition of certification for APIs?

If an entity desires to impose a fee or other charge for an interoperability element or EHI access, exchange or use, to the extent the information blocking prohibition applies, the entity must design the fee to meet an exception to the information blocking prohibition and any applicable conditions of certification for certified health IT, such as the restrictions on fees for certified APIs. Accordingly, the entity should consider the following questions:

• Covered Actor. Is the entity seeking to charge the license fees or other charges for use of APIs and other technology to access, exchange or use EHI an actor subject to the final rule (i.e., a health care provider, certified health IT developer, or an HIN or HIE)?
• EHI. Does the proposed fee or other charge relate to EHI, as opposed to HIPAA de-identified health information or other information outside the definition of EHI, such as (for the 24 months after the publication of the final rule in the Federal Register), information that is not included in the USCDI data set?
• Interoperability Element or Access, Exchange or Use. Is the proposed fee or other charge for (1) a license or other right to use an interoperability element or (2) providing access, exchange or use of EHI? For example, is the fee in exchange for a license for an API that enables access to EHI stored in an EHR system? Is the fee for a license to elements of EHR software or other health IT that only stores EHI rather than providing access, exchange or use of EHI? Alternatively, is the fee for participation in an HIN or HIE?
• Information Blocking Exception. Does the proposed fee or other charge meet the Content and Manner Exception, Fees Exception or Licensing Exception? The Content and Manner Exception provides the greatest flexibility for actors relative to pricing and terms and may, therefore, be the most advantageous exception for actors to consider first. Between the Licensing Exception and the Fees Exception, the Licensing Exception is typically more attractive if the applicable costs are low, so it may be advantageous to consider that exception before the Fees Exception.
• Additional Requirements for Certified API Technology. If the proposed fee or other charge relates to a certified API, does the proposed pricing practice meet the additional requirements of the condition of certification for APIs?

What are the key next steps for a certified health IT developer to ensure fees and other charges comply with the final rule’s information blocking prohibition and condition of certification for certified APIs?

A certified health IT developer should consider at least the following key steps to implement compliance.

• Step 1: Identify all executed and template contracts and other arrangements under which the developer provides technology that includes any capability or service that enables access, exchange or use of EHI to third parties rather than merely storing EHI.
• Step 2: Develop a business strategy and process for amending non-compliant arrangements with current customers and other counter-parties within the six-month period before the final rule’s compliance date for its information blocking provisions and for negotiating market terms with prospective counter-parties under the arrangements identified in Step 1 in accordance with the Content and Manner Exception.
• Step 3: Revise any template pricing terms that do not meet the restrictions of the Fees Exception or Licensing Exception in order to be prepared for the failure of negotiations of market terms in accordance with the Content and Manner Exception.
• Step 4: Develop a business process for responding to third-party requests to license an interoperability element, including its deadlines for beginning license negotiations and completing negotiations of a license agreement.
• Step 5: Ensure that any template license or other agreement with a new customer for an EHR system specifies any fees to export or convert data from the EHR system in order to avoid the prohibition on export and conversion fees that are not agreed to in writing at the time the EHR system is acquired.
• Step 6: Determine how to reasonably allocate certified API supply and support costs among similarly situated API information sources, including determining reasonably likely costs and forecasting the number of API information sources deploying the certified API.
• Step 7: Determine whether existing accounting practices maintain detailed records of fees charged with respect to the certified API and other technology, the methodologies used to calculate the fees and the specific costs to which such fees are attributed. If existing practices do not maintain detailed records of these items, establish a practical business process to attribute fees to costs and a record keeping system to track required information.

What are the key next steps for a health care provider (that is not a certified health IT developer) to ensure that its contracts and other arrangements comply with the fee restrictions in the final rule’s exceptions to the information blocking prohibition?

A hospital, physician practice or other health care provider actor should consider the following steps to implement compliance with the information blocking prohibition:

• Step 1: Identify all contracts and other arrangements under which the health care provider licenses or otherwise obtains an interoperability element or service from a certified health IT developer or other actor that enables access, exchange or use of EHI rather than merely storing EHI.
• Step 2: Evaluate the arrangements identified under Step 1 to determine whether any fees may fail to meet the limitations imposed under the applicable final rule exception, and if so, consider requesting modified pricing terms for non-compliant arrangements.
• Step 3: Develop a business strategy and process for responding to requests from physician practices and other health care provider requestors that have common patients with the health care provider receiving the request, for access, exchange or use of EHI maintained by the receiving health care provider. For example, a community physician practice may request that a hospital with common patients establish a custom interface to enable seamless access to EHI about common patients maintained by the hospital.

Summary Chart*

Our summary chart, available here, identifies all of the restrictions directly applicable to fees charged by an actor under the final rule. The first column of the chart identifies a restriction affecting fees. The second column indicates whether the fee restriction in the first column is an element of the Licensing Exception. The third column indicates whether the restriction in the first column is an element of the Fees Exception. The fourth column indicates whether the restriction applies to developers of certified APIs.

*For more information about elements of the exceptions that are not directly related to fees charged by an actor, please see McDermott’s prior Special Report comprehensively covering the information blocking provisions of the final rule.

Please do not hesitate to contact your regular McDermott lawyer or any one of the authors of this On the Subject if you have questions or need assistance with understanding the fee restrictions under the final rule.

For an in-depth discussion of the final rules and their impact on your organization, view the recordings of our March 2020 webinar series.

The Centers for Medicare & Medicaid Services (CMS) published its highly anticipated final rule aimed at enhancing interoperability and increasing patient access to health information. CMS’s final rule will require hospitals and payors to make significant investments in their health information technology to comply with the new requirements, effective six months following publication of the final rule in the Federal Register for hospitals, and January 1, 2021, for payors. In this On the Subject, we analyze the final rule requirements, which include a new requirement that CMS-regulated payors offer application programming interfaces, and a new Medicare condition of participation that requires hospitals with electronic health record systems to send electronic patient event notifications to communicate transitions of care.

On March 9, 2020, the US Department of Health and Human Services (HHS) Centers for Medicare & Medicaid Services (CMS) announced a final rule aimed at enhancing interoperability and increasing patient access to health information. The final rule requires CMS-regulated payors and agencies (Covered Plans and Agencies) to implement application programming interfaces (APIs) that allow patient information to be shared more readily between patients, healthcare providers, payors and third-party applications selected by patients. APIs could improve patients’ ability to gain access to their health information and share key medical history information with other providers and payors. Notably, however, HIPAA does not apply to many third-party applications that patients would use to access their data, raising stakeholder concerns about the privacy and security of information shared through APIs.

The final rule also requires hospitals that have adopted electronic health record systems to engage in electronic event reporting of patient admissions, discharges and transfers to patients’ primary care practitioners as a condition of participation (CoP) in the Medicare program. Hospitals and payors may need to make significant investments in health information technology (IT) to comply with the new requirements, which go into effect six months following publication of the final rule for hospitals, and on January 1, 2021, for payors.

This highly anticipated final rule has already garnered responses from key industry players, including America’s Health Insurance Plans, the nationwide association of health insurers, which stated that it shares HHS’s vision for expanded consumer data access but “remain[s] gravely concerned that patient privacy will still be at risk when health care information is transferred outside the protections of federal patient privacy laws.” The association cautioned that “any new rules must ensure we protect patient privacy, reduce health care costs, and get personalized information into the hands of patients.”

On the same day that CMS released the final rule, the HHS Office of the National Coordinator of Health IT (ONC) released a final rule implementing the information blocking provisions of the 21st Century Cures Act and updates to ONC’s health IT certification program. A separate On the Subject about the ONC final rule is forthcoming.

Read on for a summary of the key requirements and implications of the CMS final rule, and recommended next steps for payors and hospitals. For a review of our past coverage on these rules, please visit our Regulatory Sprint to Coordinated Care Resource Center.

Application Programming Interfaces

Under the final rule, Covered Plans and Agencies—which include Medicare Advantage (MA) plans, Medicaid state agencies, Medicaid managed care plans, Children’s Health Insurance Program (CHIP) agencies, CHIP Managed Care entities, and issuers of qualified health plans in federally facilitated exchanges, except for stand-alone dental plans—must adopt and implement an “openly published” API that permits third-party software applications to retrieve, at the direction of the patient or health plan member, a significant amount of clinical and payment information. The API technology must meet health IT standards established by ONC. Covered Plans and Agencies must comply by January 1, 2021.

The Covered Plan or Agency must make the following information available through the API:

• Data concerning adjudicated claims and encounter data, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and provider remittances and enrollee cost-sharing pertaining to such claims
• Clinical data, including laboratory results, if the Covered Plan or Agency manages such data.

The Covered Plans and Agencies must make this information available no later than one business day after a claim is adjudicated or the Covered Plan or Agency receives the data.

For MA plans, Medicaid and CHIP fee-for-service programs, Medicaid managed care plans and CHIP managed care entities, the API must also allow access to a provider directory of the payor’s network of contracted providers, including names, addresses, phone numbers and specialties, updated no later than 30 calendar days after the payor receives the information or an update.

For MA organizations that offer Part D plans, the API must allow the third-party application to retrieve:

• Standardized data concerning adjudicated claims for covered Part D drugs, including remittances and enrollee cost-sharing, no later than one business day after a claim is adjudicated
• Pharmacy directory data, including the number, mix and addresses of network pharmacies
• Formulary data that includes covered Part D drugs and any tiered formulary structure or utilization management procedure that pertains to those drugs.

While the open API initiative in the final rule specifically applies to Covered Plans and Agencies, CMS also expressed the hope that other stakeholders, such as state-operated exchanges and private payors, will adopt similar requirements for access to information and interoperability so that even more patients can broadly access their health information and better manage care.

Payor-to-Payor Data Exchange

In addition to proposing payor-to-patient exchanges through APIs, CMS also finalized its proposal to require MA plans, Medicaid managed care plans, CHIP managed care entities and qualified health plan issuers on the federally facilitated exchanges to forward patient information maintained within the ONC-identified US Core Data Set for Interoperability to other payors designated by the requesting patient for up to five years after the patient has disenrolled from the plan (with the approval and direction of the patient). CMS anticipates that payors will leverage the API they put in place to comply with patient access requirements to additionally provide other payors access to the same data. CMS allows payors to use other methods of data exchange to accomplish this requirement, however. Covered Plans and Agencies must comply with the payor-to-payor exchange requirement by January 1, 2022.

Notably, CMS elected to not finalize its proposal to require Covered Plans and Agencies to participate in trusted health information exchange networks. CMS noted that although some commenters showed support for the proposal, other commenters noted the need for a mature Trusted Exchange Framework and Common Agreement (TEFCA), a set of policies and procedures for interoperable exchange, to be put in place first. ONC published a second draft TEFCA on April 19, 2019, but has not yet finalized it.

Hospital Condition of Participation

CMS finalized its proposal to adopt a Medicare hospital CoP that requires hospitals, psychiatric hospitals and critical access hospitals (CAHs) that have electronic event notification capabilities to send electronic notifications upon a patient’s admission, discharge or transfer to or from the hospital’s emergency department or inpatient service department. The CoP becomes effective six months after the final rule’s publication in the Federal Register.

CMS modified the CoP slightly from the proposed rule. The final CoP does not require hospitals to include diagnosis information within the notification. Instead, the notification must include at a minimum the patient’s name, treating practitioner name and sending institution name. The CoP does not require hospitals to send notifications to all providers that have an “established care relationship” with the patient, but only to the patient’s established primary care practitioner or other practitioner or practice group identified by the patient as primarily responsible for the patient’s care.

CMS stated that electronic patient event notifications, or automated electronic communications from discharging providers to another facility, could improve care coordination and potentially reduce readmissions by making a receiving provider aware of the care the patient has received elsewhere. However, this CoP creates a new set of requirements on top of existing Promoting Interoperability measures that CMS adopted to incentivize the use of health IT to improve care. Hospitals must already spend significant resources to achieve the Promoting Interoperability measures, and the new CoP requirement will likely increase hospitals’ overall compliance burden with respect to health IT implementation.

Information Blocking and Public Reporting

The final rule discourages clinicians from engaging in the practice of information blocking by requiring the public display, via an indicator on the Physician Compare website, of physicians and other clinicians who fail to attest as part of the CMS Merit-based Incentive Payment System (MIPS) program that they:

• Did not knowingly and willfully take action to limit or restrict the compatibility or interoperability of certified health IT
• Implemented technologies and practices to ensure that their certified health IT is connected and compliant with applicable law
• Responded in good faith and in a timely manner to requests to retrieve or exchange electronic health information.

Clinicians who fail to attest “yes” to the above statements would receive a potential reduction of Medicare reimbursement under MIPS, in addition to the negative indicator on the CMS Physician Compare website, which is available to patients who are seeking to compare Medicare-participating physicians and other clinicians.

CMS also requires eligible hospitals and CAHs to make “yes/no” attestations concerning their use of certified health IT in order to participate in the CMS Promoting Interoperability program. A hospital or CAH’s failure to attest “yes” will result in a negative indicator on a future CMS website that will display hospitals’ attestations under the Medicare Promoting Interoperability program.

CMS included these reporting requirements in the final rule to discourage hospitals and clinicians from engaging in information blocking. CMS expects to post the information for both clinicians and hospitals in late 2020.

Recommended Next Steps

The final rule will have a significant impact on Covered Plans and Agencies and hospitals. These entities should consider taking several practical steps in response to the final rule.

Recommendations for Covered Plans and Agencies

Covered Plans and Agencies should consider the following next steps in response to the final rule:

• Assess the technological capabilities of IT systems and quickly make any necessary adjustments to offer an API that is consistent with ONC standards
• Develop user guides or other resources that explain how a plan member or patient may obtain data through the API and protect their privacy by only selecting reputable third-party applications
• Work with other Covered Plans and Agencies to develop technical mechanisms and policy frameworks for connecting and sharing data in accordance with the payor-to-payor exchange requirement, which becomes effective in 2022.

Recommendations for Hospitals and CAHs

Given the aggressive timelines in the final rule, hospitals will soon need to assess the capabilities of existing IT systems and their readiness to send electronic notifications as required by the new CoP. Even with necessary systems in place, hospitals should review their intake and discharge workflows to ensure that they are consistently identifying the practitioner primarily responsible for patients admitted to the emergency and inpatient departments. To the extent that hospitals are not consistently capturing this information, they should consider revising their policies, procedures and training to emphasize the importance of obtaining the information, and should set up event notifications to the identified individual or group practice.

If you would like assistance in complying with any of the new requirements, please contact one of the authors or your regular McDermott lawyer.

Our experienced team, which includes several attorneys who previously worked at the US Department of Health & Human Services (HHS), has advised many clients on the potential impact of the HHS proposed rules on their businesses and has analyzed the final rules. We will host a series of webinars to discuss the final rules. Details are below and you may register by clicking here.

• March 23, 2020: ONC Final Information Blocking Rule
• March 26, 2020: CMS Interoperability Rule
• March 31, 2020: Navigating the New ONC Requirements for APIs