On May 17, 2023, the Federal Trade Commission (“FTC”) announced an enforcement action (“Enforcement Action”) against Illinois-based Easy Healthcare Corporation (“Easy Healthcare”), which operates the Premom application, for allegedly violating Section 5 of the FTC Act and the Health Breach Notification Rule (“HBNR”). Easy Healthcare has developed, advertised, and distributed a mobile application called the Premom Ovulation Tracker (“Premom”) that allows users to input and track various types of personal and health information. In the complaint (“Complaint”), the FTC alleges that Easy Healthcare deceived users by disclosing users’ sensitive health data with third parties and failed to notify consumers of these unauthorized disclosures in violation of the HBNR. The proposed order (“Proposed Order”), which was brought by the U.S. Department of Justice on behalf of the FTC, imposes a civil penalty of $100,000 and prohibits Easy Healthcare from sharing user personal health data with third parties for advertising, among other requirements. As part of a related action, Easy Healthcare has agreed to pay an additional $100,000 to Connecticut, the District of Columbia, and Oregon for violating their respective laws.

Continue Reading FTC Announces Enforcement Action Against Ovulation Tracking App Premom

On January 19, 2022, the U.S. Department of Health and Human Services (HHS) Office of the National Coordinator for Health Information Technology (ONC) published the Trusted Exchange Framework and Common Agreement (TEFCA) for health information exchange. The Trusted Exchange Framework established a set of non-binding, foundational principles for trust policies and practices to help facilitate exchange among health information networks (HINs). The Common Agreement under TEFCA developed the infrastructure model and governing approach for users in different networks to securely share basic clinical information with each other—all under commonly agreed-to expectations and rules, regardless of which network they happen to be in. TEFCA’s main goal is to encourage interoperability across the country by developing uniform policies and technical requirements to regulate data sharing and to ensure that all participants can access real-time health information. For a more detailed breakdown of the structure and function of TEFCA see Crowell’s previous post.

The development of TEFCA was mandated by the 21st Century Cures Act. In 2019, the ONC issued a Notice of Funding Opportunity and ultimately appointed The Sequoia Project, Inc. to serve as the Recognized Coordinating Entity (RCE). About a year after the long-awaited TEFCA publication, ONC held an event on February 13th, 2023 to recognize the first set of applicant organizations that were approved as qualified health information networks (QHINs). The approved HINs consist of CommonWell Health Alliance, eHealth Exchange, Epic TEFCA Interoperability Services, Health Gorilla, Kno2, and KONZA National Network. These six potential QHINs agreed to the same data sharing infrastructure, which allows them to connect to one another and enables their participants, including provides, payers, and public health agencies, to exchange health information nationwide. This first cohort of potential QHINs will undergo onboarding over the course of the year. The ONC plans to announce additional QHINs as they are approved by the RCE.

Since TEFCA participation is voluntary, the extent of its impact is limited by the number of entities that apply for QHIN designation. With widespread network participation, TEFCA is intended to:

  • allow networks to securely share and access data
  • make a core set of data available for networks under the Common Agreement
  • curtail the need for entities to join multiple HINs and agreements which will decrease costs and improve efficiency
  • create a common set of privacy and security requirements for HINs and IT developers to protect patient data

Crowell Health Solutions (CHS) recently hosted “Industry Views on the Trusted Exchange Framework and Common Agreement,” a podcast examining the advancement of information exchange governance in our healthcare landscape, the significance and potential impact of TEFCA, the participation of HINs in TEFCA, and the evolution of data sharing and interoperability in the next 10 years. While TEFCA is still in the early stages, CHS looks forward to tracking the progression of the framework and its impact on health information exchange.

To learn more about TEFCA, recent activities and future implications listen to Industry Views on the Trusted Exchange Framework and Common Agreement here.

On March 2, 2023, the Federal Trade Commission (“FTC”) announced an enforcement action against California-based online counseling service BetterHelp, Inc. (“BetterHelp”) for allegedly sharing consumers’ health information, including sensitive information about mental health challenges, for advertising purposes in violation of Section 5 of the FTC Act.

This latest enforcement action comes just one month after the FTC announced an enforcement action against GoodRx for allegedly violating Section 5 of the FTC Act and the Health Breach Notification Rule (“HBNR”). Where the GoodRx enforcement action marked the first time the FTC enforced the HBNR, the BetterHelp enforcement action similarly sets a new precedent for the FTC: This is the first FTC enforcement action returning funds to consumers whose health information was compromised by BetterHelp’s alleged misdeeds. The proposed order (“Proposed Order”) also sets out extensive requirements to prohibit BetterHelp from disclosing health information for advertising and misrepresenting its information sharing practices. The GoodRx and BetterHelp enforcement actions appear to be part of a larger effort by the FTC to monitor the practices of websites, apps, and connected devices that capture consumer’s sensitive health information.

The Complaint

According to the Complaint, BetterHelp offers online counseling services by matching users with BetterHelp therapists and facilitating counseling via BetterHelp’s various websites and apps. BetterHelp also offers specialized versions of its counseling services for people of the Christian faith, members of the LGBTQ community, and teenagers. To sign up for BetterHelp’s services, consumers must fill out a questionnaire that asks sensitive mental health questions, such as whether they have experienced depression or suicidal thoughts, have previously been in counseling, or take any medications. Consumers also provide their name, email address, birth date, and other personal information. In its press release on the enforcement action, FTC suggests that consumers are “pushed’ to provide this information by “repeatedly showing them privacy misrepresentations and nudging them with unavoidable prompts to sign up for its counseling service.” Consumers are then matched with a BetterHelp counselor and pay between $60 and $90 per week for counseling.

The Complaint alleges that in recognition of the amount of sensitive health information consumers provide, BetterHelp “repeatedly promised” to keep this information “private and use it only for non-advertising purposes such as to facilitate consumers’ therapy.” However, over a period of seven years from 2013 through 2020, BetterHelp purportedly “continually broke these privacy promises, monetizing consumers’ health information to target them and others with advertisements” for BetterHelp’s services. For example, BetterHelp allegedly shared its users’ email addresses and the fact they were in counseling with Facebook, which in turn identified similar consumers and targeted them with BetterHelp advertisements. BetterHelp also allegedly shared its users’ information with other third-party advertising platforms, such as Pinterest, Snapchat, and Criteo. These advertising efforts reportedly brought in “tens of thousands of new paying users, and millions of dollars in revenue” to BetterHelp. BetterHelp also allowed these third-party companies to use BetterHelp users’ information for their own research and product development, further evidence that BetterHelp failed to contractually limit how third parties could use consumers’ health information.

The Complaint also alleges that BetterHelp “failed to employ reasonable measures to safeguard the health information it collected from consumers.” BetterHelp is accused of not training its employees on how to properly protect user information when using it for advertising purposes and not overseeing its staff’s use of user information.

The Proposed Order

The Proposed Order imposes a $7.8 million fine on BetterHelp, to be paid into a fund, to refund consumers who signed up and paid for BetterHelp’s counseling services between August 1, 2017, and December 31, 2020. The FTC reports that this is the first enforcement action seeking to return funds to consumers whose health information was compromised. In addition to the monetary penalty, the Proposed Order prohibits BetterHelp from sharing users’ “individually identifiable information relating to the past, present, or future physical or mental health or condition(s)” with third-parties for advertising or re-targeting previous users. Further, the Proposed Order requires BetterHelp to:

  • Obtain users’ affirmative express consent before disclosing personal information to third-parties for any purpose;
  • Establish, implement, and maintain a comprehensive privacy program that includes strong safeguards to protect consumer information;
  • Direct third parties to delete the consumer health information and other personal information that BetterHelp revealed to them; and
  • Limit how long BetterHelp retains personal and health information according to a data retention schedule. 

Takeaways

Digital health companies and other companies that operate websites, apps, or connected devices that capture consumer’s sensitive health information should take heed of the FTC’s enforcement actions against both BetterHelp and GoodRx. As evidenced by the BetterHelp enforcement action, companies must safeguard user information and not endeavor to leverage this information for advertising opportunities in violation of promises made to consumers. The BetterHelp enforcement action also underscores the need for appropriate user notification mechanisms to obtain user consent before disclosing their information to third parties. Further, companies should recall from the GoodRx enforcement action that even companies that are not subject to the requirements of the Health Insurance Portability and Accountability Act could still be subject to the HBNR. While the FTC did not allege violations of the HBNR by BetterHelp, further enforcement action could still be looming.

The BetterHelp enforcement action is especially noteworthy as it is the first time the FTC has endeavored to redress consumer injuries for those whose sensitive health information was inappropriately used and disclosed. This is the FTC’s second “first” in the area of health information enforcement in the span of just one month, so companies should be on the lookout for more to come.

For more information or advice regarding this enforcement action or data privacy issues in general, please contact the professional(s) listed below or your regular Crowell & Moring contact.

On February 1, 2023, the Federal Trade Commission (“FTC”) announced an enforcement action (“Enforcement Action”) against California-based telehealth and prescription drug discount provider GoodRx Holdings, Inc. (“GoodRx”) for allegedly violating section 5 of the FTC Act and the Health Breach Notification Rule (“HBNR”). The proposed order (“Proposed Order”), which was brought by the U.S. Department of Justice on behalf of the FTC, marks the first time the FTC has enforced the HBNR and could signal the beginning of increased scrutiny and enforcement of the HBNR. In addition to imposing a civil penalty of $1.5 million, the Proposed Order prohibits GoodRx from sharing health information for advertising purposes and imposes several requirements on GoodRx, including requirements to (1) obtain user consent for any other sharing of information, (2) seek the deletion of information held by third parties, (3) limit how long it can retain personal and health information, and (4) implement a privacy program.

The Expanding Scope of the HBNR

The HBNR is relatively simple in its requirements as a breach notification rule and requires vendors of personal health records (“PHRs”) and PHR related entities to notify consumers, the FTC, and, in some cases, the media, in the event of a breach of security of unsecured PHR identifiable health information. If a service provider to one of these entities experiences a breach, it must notify the entity, which in turn must carry out its notification obligations.

What is less simple, however, is the scope of the HBNR. The HBNR defines a PHR as an electronic record of PHR identifiable health information on an individual that can be drawn from multiple sources and that is managed, shared, and controlled by or primarily for the individual. A vendor of PHRs is defined as an entity that offers or maintains a PHR, while a PHR related entity is defined as an entity that (1) offers products or services through the website of a vendor of PHRs; (2) offers products or services through the websites of covered entities as defined under the Health Insurance Portability and Accountability Act (“HIPAA”) that offer PHRs to individuals; or (3) accesses information in, or sends information to, a PHR. The HBNR does not apply to HIPAA-covered entities or entities to the extent that they engage in activities as a business associate. This does not necessarily mean, however, that entities performing functions as a business associate are wholly exempt from the HBNR since many business associates engage in both HIPAA-covered activities and non-HIPAA-covered activities.

As further detailed in a previous article, the FTC issued a policy statement in September 2021 (“Policy Statement”) that appears to have significantly expanded the rule’s scope to sweep in a large number of technology companies and activities, including health apps that leverage application programming interfaces (“APIs”). For example, an app is subject to the HBNR if it collects information directly from consumers and has the technical capacity to draw information through an API that enables syncing with a consumer’s fitness tracker. According to the Policy Statement, an app that draws information from multiple sources is also subject to the HBNR, even if the health information comes from only one source – for example, if a blood sugar monitoring app draws health information only from one source (e.g., a consumer’s inputted blood sugar levels), but also takes non-health information from another source (e.g., dates from the calendar on the consumer’s phone), it is subject to the HBNR. In addition, the Policy Statement clarified that a “breach” is not limited to cybersecurity intrusions or nefarious behavior, but also covers incidents of unauthorized access such as sharing of covered information without an individual’s authorization.

The Complaint

According to the Complaint, GoodRx is a vendor of PHRs and is subject to the HBNR as it maintains “an electronic record of PHR identifiable health information on an individual that can be drawn from multiple sources and that is managed, shared, and controlled by or primarily for the individual.” The Complaint asserts that GoodRx’s website and mobile apps are electronic records of PHR identifiable health information that are capable of drawing information from multiple sources, and the information is managed, shared, or controlled by or primarily for the user. While PHRs are traditionally considered a rather narrow product focused on patients organizing and managing their health information, the Policy Statement demonstrated that the FTC is taking an expansive interpretation of the HBNR’s definition of “PHR” and, consequently, what constitutes a “vendor of PHRs.” It is little surprise therefore that the FTC considers GoodRx subject to the HBNR, particularly in light of the examples articulated in the Policy Statement.

The Complaint alleges that since 2017, GoodRx “repeatedly” violated its promises to users that it would only share their personal information with limited third parties for limited purposes, would restrict third parties’ use of such information, and would never share personal health information with advertisers or other third parties. Without providing notice to users or obtaining their consent, GoodRx allegedly shared information with third-party advertising companies and platforms, which included potentially sensitive information on prescription medications and personal health conditions, in an effort to provide targeted advertisements to users. According to the Complaint, these disclosures revealed “extremely intimate and sensitive details about GoodRx users” that could be linked to such conditions as mental health conditions, substance addiction, and sexual and reproductive health.

According to the FTC, these disclosures constitute a “breach” (i.e., disclosures without the individual’s authorization) that require notification under the HBNR. As noted above, this is broader than the typical interpretation of “breach,” but as the Policy Statement explained, the FTC is seemingly interpreting the HBNR’s definition of “breach” to cover virtually any sharing of information without the individual’s authorization. The Enforcement Action suggests that, in practice, the FTC may be more likely to enforce the HBNR where the entity repeatedly fails to abide by the statements in its privacy policies.

The Complaint also alleges the following:

  • GoodRx allowed third parties to use GoodRx’s information for their own internal purposes, such as for research and development or advertisement optimization purposes.
  • GoodRx displayed a seal at the bottom of its telehealth services homepage attesting HIPAA compliance, which stated “HIPAA Secure. Patient Data Protected.”
  • GoodRx failed to implement adequate policies or procedures to prevent the improper disclosure of sensitive health information.

The Proposed Order

In addition to imposing a $1.5 million civil penalty on GoodRx, the Proposed Order prohibits GoodRx from engaging in certain practices, requires it to notify individuals as required under the HBNR, and requires it to engage in various activities designed to bolster its compliance program. Specifically, the Proposed Order includes the following prohibitions and requirements:

  • GoodRx is prohibited from disclosing health information to third parties for advertising purposes, and the company must obtain affirmative express consent from users before disclosing their health information to third parties for non-advertising purposes.
  • GoodRx is prohibited from making misrepresentations regarding various aspects related to its information privacy and security practices.
  • GoodRx must provide users notice of the breach and Enforcement Action.
  • GoodRx must instruct third parties that received health information to delete such information.
  • Within 180 days of entry of the Proposed Order, all GoodRx businesses must establish and implement a comprehensive privacy program that protects the privacy, security, availability, confidentiality, and integrity of personal information. The program must include, among other elements, policies and procedures, assessments, and mandatory annual training for all employees.
  • GoodRx businesses that collect, maintain, use, disclose, or provide access to personal information must hire an independent third party to conduct an initial privacy assessment and biennial assessments thereafter.
  • GoodRx must annually certify to the FTC its compliance with the requirements of the Proposed Order and report, within 30 days of discovery, incidents of noncompliance.

Takeaways

Digital health companies and other organizations across the health care industry should take note of the Enforcement Action and evaluate whether the HBNR applies to their business, particularly since the FTC appears to have significantly expanded the rule’s scope through the Policy Statement. Although HIPAA-regulated activities are generally exempt from the HBNR, many organizations engage in both HIPAA-covered and non-HIPAA-covered activities. For example, a digital health company may be a business associate with respect to certain products it offers on behalf of a HIPAA-covered entity while also offering direct-to-consumer products that are not subject to HIPAA.  

The Enforcement Action is especially noteworthy as it is the first time the FTC has taken enforcement action under the HBNR, a rule that has been in effect since 2009. As first foreshadowed in the Policy Statement, the Enforcement Action could be a harbinger of increasing reliance on the HBNR as a lever for the FTC to penalize companies that misuse health information and violate their promises to consumers.

For more information or advice regarding the applicability of the Enforcement Action to your organization, please contact the professional(s) listed below or your regular Crowell & Moring contact.

Third Circuit Rules on Manufacturer Restrictions on Contract Pharmacies

The first of three pending appeals on whether a pharmaceutical manufacturer can limit distribution of covered 340B drugs to contract pharmacies resulted in a clear victory for pharmaceutical manufacturers.  The Third Circuit resolved conflicting decisions among district courts within the Third Circuit by ruling that the 340B program did not require pharmaceutical manufacturers to distribute or deliver drugs purchased by 340B covered entities to all contract pharmacies that the entity had partnered with.  Sanofi-Aventis U.S., LLC v. HHS, Case No. 21-3167 (1/30/2023).  The court rejected the government’s contrary interpretation that would have required manufacturers to deliver drugs to any location designated by the covered entity. 

Both cases were filed by manufacturers after the government sent letters stating that manufacturers had violated the 340B program by restricting the delivery of drugs to a covered entity’s contract pharmacies. The manufacturers prevailed in AstraZeneca Pharms. LP v. Becerra, 2022 WL 484587 (D. Del. Feb. 16, 2022), and the government prevailed in Sanofi-Aventis U.S., LLC v. HHS, 570 F. Supp. 3d 129 (D.N.J. 2021).

The Third Circuit decision focused on the statutory language requiring that manufacturers “shall offer” drugs that are available to anyone at any price to “covered entities” for “purchase” at a discount. 42 U.S.C. §256b(a)(1). The court observed that “nowhere” did Section 340B mention contract pharmacies, and further, that neither the word “offer” nor the word “purchase” implied any specific requirement for delivery or distribution.  The court held that 340B “imposes a price term for drug sales to covered entities, leaving all other terms blank.” The court rejected the government’s interpretation that would have given covered entities discretion to fill in the blanks on delivery or distribution so long as they foot the bill. Said the court, “when Congress’s words run out, covered entities may not pick up the pen.”

Not All Statutory Interpretation Issues Were Resolved

The Third Circuit noted that its decision did not necessarily give manufacturers the right to impose any and all conditions on the use of contract pharmacies.  The court noted that it might come to a different result if a drug maker barred all use of contract pharmacies, where a covered entity that lacks an in-house pharmacy would have no way to dispense the drugs and so could not in practice “accept” them. But it refused to speculate on a situation that had not been presented. 

Pending Appeals Could Create Circuit Conflicts

Two other circuits are considering the same issue on appeal.  The government has appealed from a decision in the District of Columbia that two manufactures’ policies of restricting the use of contract pharmacies did not violate the 340B statute. Novartis Pharmaceuticals Corp. v. Espinosa, Nos. 21-cv-1479 (DLF), 21-cv-1686 (DLF) (D.D.C. Nov. 5, 2021) (appeal pending). 

 The Seventh Circuit also heard argument in October of 2022 in a manufacturer’s appeal from an Indiana decision that upheld the government’s interpretation, but no opinion has been issued. Eli Lilly and Company v. Becerra, Case No. 21-3128 (7th Cir.).

States Weigh In

States have also recently weighed in on the treatment and availability of 340B covered drugs dispensed by contract pharmacies. 

In December of 2022, a court upheld 38 Ark. Code Ann. § 23-92-604(c) from a challenge by the Pharmaceutical Manufacturers Association that the law was preempted by the Federal 340B statute.  Pharma v. McClain, Case No. 4:21-CV-864-BRW (E.D. Ark. 12/12/22).  The law prohibits pharmaceutical manufacturers from denying or prohibiting “340B drug pricing for an Arkansas-based community pharmacy that receives drugs purchased under a 340B drug pricing contract pharmacy arrangement with an entity authorized to participate in 340B drug pricing.”  The court held that the 340B program did not preclude states from protecting state interest related to the distribution of pharmaceuticals within the state.  The case is on appeal to the Eighth Circuit. 

Finally, in a policy that became effective on January 1, 2023, Pennsylvania issued guidance that appears to eliminate Medicaid reimbursement for 340B covered drugs dispensed by contract pharmacies. That guidance can be found here:  MAB2022122201.pdf (pa.gov).  The policy arises out of ongoing tension between the Medicaid rebate program and 340B discounted pricing, because a manufacturer is obligated to offer rebates or discounts under only one of these programs on drug purchases.  Failure of state Medicaid programs to earn rebates for drugs that are purchased under the 340B program but reimbursed under the Medicaid program has led to conflicts over, essentially, whether 340B covered entities or state Medicaid programs should receive the financial benefit of Federal drug discounting programs.  In addition, both states and manufacturers have alleged significant documentation errors by covered entities and their contract pharmacies in identifying 340B covered drugs that are dispensed to Medicaid beneficiaries, leading to protracted disputes and requests for recoupment by manufacturers.

Throughout the COVID-19 pandemic, the Centers for Medicare and Medicaid Services (CMS) issued a number of waivers and flexibilities to help healthcare providers manage the influx of patients during the Public Health Emergency (PHE). The implementation of the Acute Hospital Care at Home (AHCaH) individual waiver in 2020 allowed qualifying hospitals to provide hospital at home (H@H) programs. These programs provide similar services as those administered during inpatient visits, such as physician visits and monitoring, drug prescription, nursing services, diagnostics, etc. Since its employment, 144 systems including 260 hospitals across 37 states have utilized the AHCaH waiver, rapidly increasing the number of H@H programs in the United States. While the initiative was originally set to expire with the end of the PHE, the AHCaH waiver program was extended until December 31, 2024, with the passing of the Consolidated Appropriations Act, 2023 (CAA 2023). The extension of this program sends a strong message about the importance of permanently integrating home-based care delivery models into our healthcare system. Despite the lengthy extension, the nature of this waiver program remains temporary and the concerns about the expiration effects on relevant stakeholders continue to be pertinent.

Continue Reading Hospital at Home Programs Extended, But Final Push Is Needed

On December 29, President Joe Biden signed into law the Consolidated Appropriations Act, 2023 (P.L. 117-164) (the “Act”)—an approximately $1.7 trillion spending package, which consists of all 12 fiscal year (FY) 2023 appropriations bills and funds the federal government through September 30, 2023, provides additional assistance to Ukraine, and makes numerous health care policy changes.  

Continue Reading President Biden Signs End-of-Year Legislation Including Telehealth, Medicare & Medicaid, Mental Health, Pandemic Preparedness, and Other Health Care Provisions

On December 21, 2022, the Centers for Medicare & Medicaid Services (CMS) issued a proposed rule that would adopt standards under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) for “health care attachments” transactions, which would: (1) support health care claims adjudication and prior authorization transactions; (2) adopt standards for electronic signatures to be used in conjunction with health care attachments transactions; and (3) adopt a modification to the standard for the referral certification and authorization transaction. This builds on the HIPAA Transactions Rule standards for financial and administrative transactions among health care providers and health plans and aligns with Department of Health and Human Services (HHS) interoperability regulations.  Comments on the proposed rule are due March 21, 2023.

Background and Context

To enable health information to be exchanged more efficiently and to achieve greater uniformity in the transmission of health information, the CMS proposed rule would implement requirements of the Administrative Simplification subtitle of HIPAA and the Affordable Care Act to adopt transaction standards for electronic health care attachments and electronic signatures, building on the HIPAA Transactions Rule adopted at 45 C.F.R. Part 162. There are already adopted transactions requirements for health care claims and referral and certification transactions; however, at this time, there are no adopted HIPAA standards, implementation guides, or operating rules for health care attachments or electronic signatures.  This proposed rule would establish electronic standards for ‘‘health care attachments’’ transactions, which would support health care claims and prior authorization transactions, and would establish a standard for electronic signatures to be used in conjunction with health care attachments transactions. This rule also proposes modifying the referral certification and authorization transaction standard to move to a new version of the current standard.

In making medical necessity determinations as part of coverage decisions, health plans often require additional information that cannot adequately be conveyed in the adopted prior authorization request or health care claims transaction. This proposed rule would support electronic transmissions of this type of information, with the goal of facilitating prior authorization decisions and claims processing, reduce burden on providers and plans, and result in more timely delivery of patient health care services.

In September 2005, CMS issued a proposed rule to adopt certain standards with respect to health care attachments. Rather than a standard with generalized applicability, CMS proposed to adopt health care claims attachment standards with respect to specific service areas that included ambulance services, clinical reports, emergency department, laboratory results, medications, and rehabilitation services. CMS did not finalize the rule due to comments received related to the standards’ lack of technical maturity and stakeholders’ lack of readiness to implement electronic capture of clinical data. Standards for electronic signatures were also proposed in an August 1998 proposed rule, but were not adopted because stakeholder feedback indicated that electronic signature technology was not yet mature. This proposed rule was issued before the Health Information Technology for Economic and Clinical Health (HITECH) Act incentives to adopt electronic health records, and therefore, before many health care providers had clinical data in electronic form.

Key Provisions

1. Adoption of Standards for Health Care Attachments Transactions

Scope of Health Care Transaction Standard

To define the scope of when the health care attachment standard would be used, CMS defines “attachment information” as documentation transmitted by a health care provider or requested by a health plan in order to make a decision about health care that is not included in either the claim or encounter information or the referral certification and authorization transaction. Use of the word ‘‘documentation’’ is intended to be broad to indicate the wide scope of information that may be included. 

The proposed rule defines a health care attachment transaction as the transmission of any of the following:

  • Attachment information from a health care provider to a health plan in support of a referral certification and authorization transaction;
  • Attachment information from a health care provider to a health plan in support of a health care claims or equivalent encounter transaction; or
  • A request from a health plan to a health care provider for attachment information.

CMS clarifies that it is not proposing to adopt attachments standards for all health care transaction business needs and believes covered entities should gain experience with a limited number of standard electronic attachment types so that technical and business issues can be identified to inform potential future rulemaking for other electronic attachments standards.

Code Set, Implementation Specifications, and Standards

CMS proposes new requirements for a code set to be used for health care attachments transactions in addition to Accredited Standards Committee X12 (X12) standards for requesting and transmitting attachment information and Health Level Seven (HL7) standards for clinical information content, which are outlined below.

Code Set (LOINC for HIPAA Attachments): Logical Observation Identifiers Names and Codes (LOINC) is the code system, terminology, and vocabulary for identifying individual clinical results and other clinical information. CMS proposes numerous implementation specifications containing specific instructions for how to utilize LOINC for HIPAA Attachments to identify the specific kind of information that a health plan electronically requests of a health care provider and a health care provider electronically transmits to a health plan; to specify certain optional modifier variables for attachment information (e.g., a time period for which the attachment information is requested); and for structured attachment information, to identify specific HL7 Implementation Guide: LOINC Document Ontology document templates. Where an implementation specification requires the use of LOINC, it instructs users to utilize the codes valid at the time a transaction is initiated.

Standards and Implementation Specifications: CMS proposes adopting the following three X12N Technical Report Type 3 (TR3) implementation specifications for requesting and transmitting attachment information, and three HL7 implementation guides for the clinical information embedded in those transactions. CMS explains that the proposed attachments standards would satisfy the requirements to adopt a standard to support health care claims and support prior authorization transactions.

CMS proposes adopting the following HL7 implementation guides and X12 standards for health care attachments transactions:

  • HL7 CDA R2 Attachment Implementation Guide: Exchange of C-CDA Based Documents, Release 1, March 2017
  • HL7 Implementation Guide for CDA Release 2: Consolidated CDA Templates for Clinical Notes (US Realm) Draft Standard for Trial Use Release 2.1, Volume 1 — Introductory Material, June 2019 with Errata
  • HL7 Implementation Guide for CDA Release 2: Consolidated CDA Templates for Clinical Notes (US Realm) Draft Standard for Trial Use Release 2.1, Volume 2 — Templates and Supporting Material, June 2019 with Errata
  • X12N 275 – Additional Information to Support a Health Care Claim or Encounter (006020X314): the standard a provider must use to electronically transmit attachment information to a health plan to support a health care claims or equivalent encounter information transaction
  • X12N 275 – Additional Information to Support a Health Care Services Review (006020X316): the standard a provider must use to electronically transmit attachment information to a health plan to support a prior authorization request
  • X12N 277 – Health Care Claim Request for Additional Information (006020X313): the standard a health plan must use to electronically request attachment information from a health care provider to support a health care claim

2. Adoption of Standards for Electronic Signatures

This rule proposes a standard for electronic signatures to be used in conjunction with health care attachments transactions. Section 1173(e)(1) of the Social Security Act requires the HHS Secretary, in coordination with the Secretary of Commerce, to adopt standards specifying procedures for the electronic transmission and authentication of signatures for HIPAA transactions. The August 1998 proposed rule, which was never finalized, did not propose a standard but rather enumerated the following three implementation features: user authentication, message integrity, and non-repudiation.  In the September 2005 proposed rule, CMS recognized that an electronic signature consensus standard still did not exist and sought industry input on how signatures should be handled when an attachment is requested and transmitted electronically.

Definition of Electronic Signature: CMS proposes defining the term “electronic signature” as an electronic sound, symbol, or process, attached to or logically associated with attachment information and executed by a person with the intent to sign the attachment information. CMS states that it intends to define the term as broadly as possible to ensure that it meets health care providers’ and health plans’ needs now and can also encompass future electronic signature technologies. CMS clarifies that the electronic signature standard would pertain only to electronic signatures for attachment information transmitted by a health care provider in an electronic health care attachments transaction.

Electronic Signature Standard: In this proposed rule, CMS has decided not to propose a standard for electronic signature or requirements on when to require electronic signature. Instead, it states that it defers to the industry to continue to establish those expectations and requests feedback from industry on these issues. While CMS is not proposing to specify when an electronic signature must be required, it is proposing that, where a health care provider uses an electronic signature in a health care attachments transaction, the signature must conform to the implementation specifications in the HL7 Implementation Guide for CDA Release 2: Digital Signatures and Delegation of Rights, Release 1 (hereafter Digital Signatures Guide). CMS states that the Digital Signatures Guide promotes the aforementioned three features by utilizing digital signature technology to implement identity management using digital certificates, encryption requirements to support message integrity, and multiple signed elements to support nonrepudiation.

3. Modification to Referral Certification and Authorization Transaction Standard

This proposed rule would modify previously adopted HIPAA standards for referral certification and authorization transactions. The referral certification and authorization transaction includes the following transmissions:

(a) A request from a health care provider to a health plan for the review of health care to obtain an authorization for the health care.

(b) A request from a health care provider to a health plan to obtain authorization for referring an individual to another health care provider.

(c) A response from a health plan to a health care provider to a request described in paragraph (a) or paragraph (b).

In this rule, CMS proposes adopting Version 6020 of the X12N 278 for referral certification and authorization transactions standard to replace Version 5010 of the X12N 278. CMS notes that Version 6020 of the X12N 278 provides significant technical improvements and structural changes over Version 5010, including better supporting referral certification and authorization transactions for dental services and revising and expanding the drug authorization segment.

We note that this modification follows a recently proposed rule in November 2022 that would modify the referral certification and authorization transaction standard.  Those proposed modifications addressed retail pharmacy drugs and dental, professional, and institutional request for review and response.  As previously discussed, this November proposed rule also adopts other standards, including the NCPDP Batch Standard Subrogation Implementation Guide Version 10 (to replace Version 3.0).

Compliance Dates

CMS proposes that the compliance date for adopting the new standards would be 24 months after the effective date of the final rule, which is 60 days after the final rule is published in the Federal Register, for all covered entities.

Takeaways

This proposed rule is part of a growing focus by HHS on interoperability, including electronic access to clinical data and rules on prior authorization. As we have previously discussed, CMS has recently proposed rules on interoperability and prior authorization, which are also open for comment. The Office of the National Coordinator for Health Information Technology (ONC) has also previously published a request for information, which covered standards for electronic prior authorization, among other things.  

We recommend assessing how your organization would be impacted by the proposed rule, if finalized, and consider commenting on the applicability and standards. For more information, or to better understand how this guidance impacts your organization, please contact the professionals listed below, or your regular Crowell & Moring contact.

On January 4, in its most recent effort to expand federal support for addressing health-related social needs (HRSNs), the Centers for Medicare & Medicaid Services (CMS) issued guidance to clarify an existing option for states to address HRSNs through the use of “in lieu of” services and settings policies in Medicaid managed care. This option is designed to help states offer alternative benefits that take aim at a range of unmet HRSNs, such as housing instability and food insecurity, and to help enrollees maintain their coverage and improve health outcomes. 

Background

“In lieu of” services can be used as immediate or longer-term substitutes for state-covered services or settings to offset potential future acute or institutional care and improve the quality and health outcomes for the enrollee. The recent guidance builds on the 2016 Medicaid and Children’s Health Insurance Program (CHIP) managed care final rule, which formally recognized states’ and managed care plans’ abilities to cover “in lieu of” services and significantly expanded its flexibility by permitting coverage of services in an institution for mental disease (IMD) with certain limitations. The final rule required that states’ “in lieu of” services must be medically appropriate and cost-effective, prevents managed care plans from requiring services for enrollees as a substitute for a state plan covered service or setting, and factors services’ utilization and actual costs into capitation rates.

States and CMS are using 1115 waiver authority to pursue “in lieu of” services and other HRSN-related services and supports. In recent months, CMS approved 1115 waivers in Arizona, Arkansas, Massachusetts, and Oregon that include “in lieu of” services proposals to address HRSNs. While several states currently use “in lieu of” services to cover mental health and substance use disorder treatment in IMD settings, CMS explains that additional guidance is necessary at this time for non-IMD and other types of services, including those to reduce the need for future costly state plan-covered services.

Guidance: CMS’ Six Principles on Appropriate and Efficient Use of “In Lieu Of” Services

In guidance addressed to state Medicaid directors, CMS clarifies its expectations for the use of “in lieu of” services and settings and provides a policy framework for states in order to qualify for a Section 1115 waiver. The guidance also establishes the following six principles to guide states in this area: (i) Medicaid program alignment, (ii) cost-effectiveness, (iii) medical appropriateness, (iv) enrollee rights and protections, (v) monitoring and oversight, and (vi) retrospective evaluation (when applicable).

CMS has developed these clarifying parameters to ensure adequate assessment of the alternative services and settings prior to use, ongoing monitoring for appropriate utilization and enrollee protections, and financial guardrails to ensure accountability and prevent inappropriate use of Medicaid resources. States must fulfill each of the below requirements to obtain CMS approval of states’ managed care plan contracts that include “in lieu of” services in accordance with 42 CFR § 438.3(a).

  1. “In lieu of” services must advance the objectives of the Medicaid program
  2. “In lieu of” services must be cost effective
  3. A brief description of each “in lieu of” services in the Medicaid managed care program, and whether the service was provided as a benefit during the base data period;
  4. The projected “in lieu of” services cost percentage, which is calculated by dividing the portion of the total capitation rates that would be attributable to a service, excluding short term stays in an IMD, for a specific managed care program by the projected total capitation payments for that program;
  5. A description of how the “in lieu of” services (both material and non-material impact) were taken into account in the development of the projected benefit costs, and if this approach was different than that for any of the other services in the categories of service; and
  6. An actuarial report that includes the final “in lieu of” services cost percentage, the actual plan costs for services for the specific managed care program, the portion of the total capitation payments that is attributable to services (excluding a short term stay in an IMD), and a summary of the actual managed care plan costs for delivering services based on claims and encounter data. The report should be submitted to CMS no later than 2 years after the completion of the contract year that includes services.
  7. “In lieu of” services must be medically appropriate
  8. The name and definition of each “in lieu of” services and the services or settings which they substitute, including the relevant coding;
  9. Clinically oriented definitions for the target population;
  10. A contractual requirement for the managed care plans to utilize a consistent process to ensure that a provider using professional judgement determines the medical appropriateness of the service for each enrollee; and
  11. If the projected cost percentage is higher than 1.5 percent, states must provide a description of the process to determine medical appropriateness.
  12. “In lieu of” services must be provided in a manner that preserves enrollee rights and protections
  13. “In lieu of” services must be subject to appropriate monitoring and oversight
  14. An actuarial report provided by the state’s actuary certifying the final “in lieu of” service cost percentage specific to each managed care program as outlined above;
  15. Written notification within 30 days of determining that an “in lieu of” service is no longer a medically appropriate or cost-effective substitute, or for any other areas of non-compliance;
  16. An attestation to audit encounter, grievances, appeals, and state fair hearing data to ensure accuracy, completeness, and timeliness, including data to stratify utilization by demographics when possible; and
  17. Documentation necessary for CMS to understand how the utilization, cost, and savings for an “in lieu of” service was considered in the development of actuarially sound capitation rates.
  18. “In lieu of” services must be subject to retrospective evaluation (when applicable)

CMS will require states with final “in lieu of” services cost percentages greater than 1.5 percent to submit a retrospective evaluation for each managed care program that includes “in lieu of” services. At a minimum, evaluations should include the following information:

  • The impact each service had on utilization of state plan-covered services or settings, including associated cost savings, trends in managed care plan and enrollee use of each service, and impact of each service on quality of care;
  • An assessment of whether encounter data supports the state’s determination that each service is a medically appropriate and cost-effective substitute;
  • The final “in lieu of” services cost percentage consistent with the actuarial report;
  • Appeals, grievances, and state fair hearings data separately for each service including volume, reason, resolution status, and trends; and
  • The impact each service had on health equity initiatives and efforts undertaken by the state to mitigate health disparities.

Evaluations must be submitted to CMS no later than 24 months after the completion of the first five contract years that include “in lieu of” services. If the retrospective evaluation identifies substantive issues, CMS may determine whether to permit the state to take corrective action to remedy the deficiency or terminate the service.

Next Steps

States that use “in lieu of” services for their Medicaid managed care contracting will have until the contract rating period beginning on or after January 1, 2024, to conform with this guidance for existing services. Effective January 4, 2023, any state managed care plan contract that includes new “in lieu of” services must conform to the guidance.

The guidance demonstrates the Administration’s interest and commitment to bolster federal support for reimbursement of “in lieu of” services to address HRSNs. States can leverage existing federal policy flexibilities to offer expanded benefits to Medicaid beneficiaries and improve population health. In addition, the guidance may offer opportunities for plans, providers, health technology companies, and others to improve access to health-related social care services for vulnerable populations.

For more information on how the guidance could impact your organization, please contact the professionals listed below, or your regular Crowell & Moring contact.

On December 6, 2022, the Centers for Medicare & Medicaid Services (CMS) issued a Proposed Rule that would (i) further enhance health data exchange by establishing data exchange standards for certain payers, (ii) improve patient and provider access to health information, and (iii) streamline processes related to prior authorization for medical items and services. The regulations impact CMS-regulated payers and provide incentives for providers and hospitals that participate in the Medicare Promoting Interoperability Program and the Merit-based Incentive Payment System (MIPS).

This Proposed Rule officially withdraws, replaces, and responds to the comments received from the December 2020 CMS Interoperability proposed rule, further builds on the May 2020 CMS Interoperability and Patient Access final rule, and diverges from the December 2020 CMS Interoperability proposed rule in a few key ways. Most of the Proposed Rule’s provisions will be effective on January 1, 2026. The deadline to submit comments is March 13, 2023. Our initial takeaways are summarized below.

The below summary does not focus on the Medicaid and Children’s Health Insurance Program (CHIP) Fee for Service (FFS) proposals. The Proposed Rule also notes that the Medicare FFS program is evaluating opportunities to improve automation of prior authorization processes, and, if the Proposed Rule is finalized, Medicare FFS would align its efforts for implementing its requirements as feasible.

1.  Proposed Rule withdraws, replaces, and responds to comments to the December 2020 CMS Interoperability proposed rule:

CMS reports that it received approximately 251 individual comments on the December 2020 CMS Interoperability proposed rule by the close of the comment period on January 4, 2021. The agency explains that the December 2020 CMS Interoperability proposed rule will not be finalized due to the concerns raised by the commenters—including concerns related to the short comment period for stakeholders to conduct a thorough analysis and provide feedback, as well as the short implementation timeframes. For these reasons, CMS withdrew the December 2020 CMS Interoperability proposed rule. The new Proposed Rule incorporates the feedback CMS had already received, proposes updates and provides additional time for public comment, until March 13, 2023.

2.  Proposed Rule builds on the May 2020 CMS Interoperability and Patient Access final rule:

This newly Proposed Rule builds on the May 2020 CMS Interoperability and Patient Access final rule by requiring impacted payers (newly included Medicare Advantage Organizations (MAO); state Medicaid and CHIP FFS programs; Medicaid managed care plans; CHIP managed care entities; and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFE)) not only to establish standards-based Patient Access Application Programming Interface (API), but also to implement new Provider Access API, a standardized payer-to-payer data exchange API, and a Prior Authorization Requirements, Documentation and Decision (PARDD) API. To ensure providers utilize this technology, CMS also proposes to include the “electronic prior authorization” measure for the Merit-based Incentive Payment System (MIPS) Promoting Interoperability performance category for MIPS eligible providers and the Medicare Promoting Interoperability Program for eligible hospitals and critical access hospitals (CAHs).

a.  Patient Access API

(i) Security risk remains the only reason to deny an individual’s access request via Patient Access API.

CMS reiterates in the Proposed Rule that the only reason payers could deny API access to a health app that a patient wishes to use and access through the Patient Access API is potential security risk to the payer. CMS enumerates that these security risks include insufficient authentication or authorization controls, poor encryption, or reverse engineering. The payer must make that determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which patients seek to access their electronic health information.

(ii) Prior authorization information would be included via the Patient Access API.

CMS proposes to require impacted payers (now including  MAOs) to share certain prior authorization information through the Health Level 7® (HL7®) Fast Healthcare Interoperability Resources® (FHIR®) standard Patient Access API.

(iii) Payers would be required to report metrics about the use of Patient Access API.

Additionally, CMS proposes to require impacted payers to report metrics in the form of aggregated, de-identified data to CMS on an annual basis about how patients use the Patient Access API to assess whether CMS’s Patient Access API policies are successful. Specifically, CMS proposes that payers annually report:

  • The total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and
  • The total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient.

(iv) Data provided via the Patient Access API would include all data classes and elements currently included in USCDI v.1.

Finally, CMS proposes a clarification that the data that impacted payers must make available are “all data classes and data elements included in a content standard at 45 C.F.R. 170.213,” instead of “clinical data, including laboratory results.” The current data standard at 45 C.F.R. 170.213 remains USCDI v. 1.   

b.  Provider Access API

In addition to the Patient Access API requirement, the Proposed Rule requires impacted payers to implement and maintain a FHIR API that makes patient information directly available to providers with whom payers have contractual relationships (i.e. in-network providers) and with whom patients have treatment relationships. The proposal includes a patient opt-out option (where the December 2020 CMS Interoperability proposed rule included an opt-in policy) by which patients could choose not to participate in the Provider Access API. Through this provision, CMS seeks to reduce the burden on patients and improve care by ensuring that providers can access comprehensive patient data. Importantly, both the proposed Patient and Provider Access APIs require that payers share prior authorization request and decision information for medical items and services (excluding drugs).

c.  Payer-to-Payer Data Exchange API

(i) Payers would be required to implement a FHIR API for payer-to-payer data exchange.

The Proposed Rule would rescind the payer-to-payer data exchange policy that did not impose a standard for the exchange, and proposes to require impacted payers to implement and maintain a payer-to-payer FHIR API to build a longitudinal patient record when the patient moves from one payer to another, or when the patient has concurrent coverage. CMS proposes an opt-out option for patients. While non-impacted payers may benefit from implementing the payer-to-payer API, they would not be under any obligation to do so. Therefore, the impacted payers in this Proposed Rule would only be responsible for their own side of the data sharing requests and responses.

(ii) Payers would have to exchange data with any concurrent payers that member reports within one week of the start of coverage.

The Proposed Rule requires impacted payers to collect information about any concurrent payer(s) from patients before the start of coverage with the impacted payer and, within one week of the start of a member’s coverage, to exchange data with any concurrent payers that the member reports. Such exchange would continue on at least a quarterly basis. The receiving impacted payer would have to respond with the appropriate data within one business day of receiving the request for a current patient’s data from a known concurrent payer for that patient. To the extent that an individual is enrolled with payers not subject to the Proposed Rule that refuse to exchange data with the impacted payer, the impacted payer would not be required to provide data to that concurrent payer and would not be required to continue to request data exchange quarterly. An impacted payer is required to respond to a non-impacted payer, however, if that non-impacted payer requests data exchange in accordance with the Proposed Rule.

d.  Prior Authorization Requirements, Documentation, and Decision (PARDD) API

(i) Payers would need to build a PARDD API to streamline authorization process.

CMS proposes requirements for an API to streamline the prior authorization processes, that is the process by which a provider must obtain approval from a payer before providing care in order to receive payment for delivering items or services.  Specifically, CMS proposes to require impacted payers to build and maintain a FHIR Prior Authorization Requirements, Documentation, and Decision (PARDD) API. The Proposed Rule would not apply to outpatient drugs, drugs that may be prescribed, those that may be administered by a physician, or that may be administered in a pharmacy, or hospital.

CMS acknowledges that its PARDD API proposal will result in changes to the impacted payers’ customer service operations and procedures, and encourages payers to evaluate the procedural and operational changes as part of their implementation strategy, and to make appropriate resources available when the API is launched.

Given the delayed implementation date of January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), CMS encourages those payers that currently maintain cumbersome prior authorization processes on their individual websites or through proprietary portals to develop short-term mechanisms to make prior authorization information more easily understandable and publicly available to providers and patients, if they elect to wait until 2026 to implement the PARDD API.

(ii) Payers must share certain information with patients and providers.

As noted in the Patient Access API description, there are a few key pieces of information which payers are responsible for sharing with patients and providers within clear timelines under the Proposed Rule. Specifically, payers must share lists of covered items and services (excluding drugs) which require prior authorization, share the corresponding documentation requirements, respond to prior authorization requests within specified timeframes, provide clear reasoning for request denials, and publicly report prior authorization metrics including approvals, denials, and appeals.

The PARDD API, however, also would allow providers to query the payer’s system to determine whether a prior authorization was required for certain items and services and to identify documentation requirements. Further, the PARDD API would automate the compilation of necessary data for populating the HIPAA-compliant prior authorization transaction (X12 278) and enable payers to provide the status of the prior authorization request, including whether the request has been approved (and for how long) or denied (with a specific reason), which would support current Federal and state notice requirements for certain impacted payers.

(iii) Impacted payers would be required to annually report on prior authorization metrics.

CMS stated it believes that transparency regarding prior authorization processes would be an important consideration for individuals to choose new plans. CMS proposes to require impacted payers to publicly report annually (by March of each year), on the payer’s website or via a publicly accessible hyperlink(s), on the following nine aggregated metrics about prior authorization:

  1. A list of all items and services that require prior authorization.
  2. The percentage of standard prior authorization requests that were approved, aggregated for all items and services.
  3. The percentage of standard prior authorization requests that were denied, aggregated for all items and services.
  4. The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.
  5. The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.
  6. The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.
  7. The percentage of expedited prior authorization requests that were denied, aggregated for all items and services.
  8. The average and median time that elapsed between the submission of a request and a determination by the payer, plan, or issuer, for standard prior authorizations, aggregated for all items and services.
  9. The average and median time that elapsed between the submission of a request and a decision by the payer, plan or issuer, for expedited prior authorizations, aggregated for all items and services.

This proposed reporting would be at the organizational level for MA, the state level for Medicaid and CHIP FFS, the plan level for Medicaid and CHIP managed care, and the issuer level for QHP issuers on the FFEs.

(iv) CMS encourages payers to adopt prior authorization gold-carding programs.

The Proposed Rule also encourages payers to adopt gold-carding programs, where payers relax prior authorization requirements for providers that have a demonstrated history of compliance with all payer documentation requirements to support the requests, appropriate utilization of items or services, or other evidence-driven criteria. To further encourage the adoption and establishment of gold-carding programs, CMS is considering including a gold-carding measure as a factor in the quality star ratings and seeks comment for potential future rulemaking on the incorporation of such a measure into star ratings for these organizations and on imposing gold-carding as a requirement in payer’s prior authorization policies.

e. Electronic Prior Authorization for the MIPS Promoting Interoperability Performance Category and the Medicare Promoting Interoperability Program.

CMS acknowledges that the anticipated benefits of the PARDD API are contingent on providers using health IT products that can interact with payers’ APIs.  Therefore, the Proposed Rule also creates a new “electronic prior authorization” measure for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS, as well as for eligible hospitals and critical access hospitals (CAHs) under the Medicare Promoting Interoperability Program. Under this proposal, MIPS eligible clinicians, eligible hospitals, and CAHs would be required to report the number of prior authorizations for medical items and services (excluding drugs) that are requested electronically using data from certified electronic health record technology (CEHRT) using a payer’s PARDD API. CMS determines a final score for each MIPS eligible clinician based on their performance in the MIPS performance categories and applies a payment adjustment (which can be positive, neutral, or negative) for the covered professional services they furnish based on their final score. Under the Medicare Promoting Interoperability Program, eligible hospitals and CAHs that do not successfully demonstrate meaningful use of CEHRT are subject to Medicare payment reductions. CMS requests comment on additional steps CMS could take to encourage providers and health IT developers to adopt the technology necessary to access payers’ PARDD APIs.

CMS also notes that on January 24, 2022, ONC published an RFI titled “Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria” (87 FR 3475) requesting comment on how updates to the ONC Health IT Certification Program could support electronic prior authorization.

f.  Interoperability Standards for APIs

Finally, this Proposed Rule seeks to clarify the specific standards at 45 C.F.R. 170.215 that apply for each API discussed in the proposal. For example, CMS proposes to require impacted payers to implement an HL7 FHIR API that would work in combination with the adopted HIPAA transaction standard—ASC X12 Version 5010×217 278 (X12 278) for dental, professional, and institutional requests for review and response— and use certain HL7 FHIR Da Vinci Implementation Guidelines (IGs) developed specifically to support the functionality of the PARDD API to conduct the prior authorization process. Covered entities would continue to send and receive the HIPAA-compliant prior authorization transactions while using the FHIR PARDD API.

g.  Requests for Information (RFI)

There are also five RFIs in the Proposed Rule on the following topics:

  • Accelerating adoption of standards related to social risk data;
  • Electronic exchange of behavioral health data;
  • Electronic exchange for Medicare fee-for-service;
  • Incentives for exchange in accordance with the Trusted Exchange Framework and Common Agreement; and
  • Advancing interoperability and improving prior authorization for maternal health.

3.  Summary of the Proposed Rule’s major changes from the December 2020 Interoperability proposed rule:

In sum, the Proposed Rule features the following major changes from the December 2020 proposed rule:

  • Requiring impacted payers to use the health information technology standards at 45 C.F.R. 170.215 that are applicable to each corresponding set of API requirements, including the payer-to payer API;
  • Including MAOs as impacted payers;
  • Extending the implementation timeline for the policies within the newly proposed rule, with opportunities to seek extensions, exemptions, or exceptions for certain payers;
  • Clarifying existing Medicaid beneficiary notice and fair hearing regulations that apply to Medicaid prior authorization, and changing terminology related to Patient Access API; and
  • Including a new Electronic Prior Authorization measure for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS.

For more information, please contact the professional(s) listed below, or your regular Crowell & Moring contact.