On May 12, 2025, Carequality amended its Framework Policies from version 2 (approved in 2023) to version 3 (adopted May 12, 2025). For those that rely on the nationwide network to pull needed medical records for patients, Carequality’s v3 Framework Policies add new requirements that must be met before Carequality Connections and Implementers may exchange records through Carequality. Some of those changes go beyond HIPAA and raise questions about whether the Information Blocking Rule is implicated.
All “Actors” must comply with the Information Blocking Rule. Actors include health information networks (HINs) and health information exchanges (HIEs), as those terms are defined in 45 C.F.R. § 171.102. In brief, a HIN/HIE is any entity that determines, controls, or has discretion to administer requirements, policies, or agreements that permit or enable access, exchange, or use of EHI among unaffiliated entities. While Carequality does not operate a central data repository, it does create and enforce a governance framework (policies, the Carequality Connected Agreement (CCA), Connection Terms, and Implementation Guides) that allows Implementers (EHR vendors, HIEs, networks, payers, providers) and their customers (Connections) to exchange data with each other. Carequality also administers requirements and policies that directly govern whether and how electronic health information (EHI) is exchanged (e.g., Treatment, Patient Request, Access Policy Assertions, Delegation rules). Those requirements are set by the Steering Committee and are mandatory for participants. In practice, Carequality is not merely a convener; it controls the rules of exchange which seems to fall squarely within the HIN/HIE definitions.
Carequality’s role is also shifting in relation to TEFCA. In early 2025, Carequality announced that it will align its policies and technical framework with TEFCA, positioning itself to operate as a Qualified Health Information Network (QHIN) (source: Carequality News & Insights, “Priorities for 2025” (February 18, 2025). This means that many of the same policies now embedded in the Carequality v3 Framework are being mapped toward TEFCA compliance.
Does Carequality Qualify as a HIN/HIE under the IBR?
That determination ultimately rests with the organization and with federal enforcers. For HINs/HIEs and health IT developers, enforcement is by the HHS Office of Inspector General (OIG), which may impose civil monetary penalties up to $1 million per violation; for providers, HHS (including CMS) established programmatic disincentives. However, based on the regulatory definitions and Carequality’s publicly-defined role, Carequality appears to meet the definition of a HIN (and arguably an HIE) because it determines and administers requirements and policies that enable EHI exchange among unaffiliated entities for Treatment, Payment, and Health Care Operations.
Notably, HIN/HIE Actors are subject to the “knows or should know” standard in 45 C.F.R. § 171.103(a)(1); whereas, health care providers who are Actors are held to an “actual knowledge” standard under § 171.103(a)(2)–(3). This distinction matters when evaluating whether any exchange policies are likely to “interfere with, prevent, or materially discourage” access, exchange, or use of EHI (absent an exception).
Comparing the Versions
The following comparison of Carequality’s Framework Policies v2.0 (July 31, 2023) and v3.0 (May 12, 2025) identifies what has changed, explains the practical impact for participants, evaluates the implications under HIPAA, and considers whether each change might trigger any concerns under the Information Blocking Rule.
1. Roles (Principals, Delegates, Initiator-Only)
Policy sections: 2.0; § 3.7; §§ 3.7.1–3.7.5 (v3.0)
What changed: v3.0 formalizes role definitions (Principal, First-Tier Delegate, Downstream Delegate) and requires Delegation Notices, Attestation Forms, and directory updates.
Practical impact: No more informal “on-behalf-of” activity; each delegation must be documented, traceable, and reflected in the directory or related SAML attributes. Queries lacking proper delegation metadata are rejected.
HIPAA impact: More stringent than HIPAA (BAA oversight does not require directory pointers or standardized Delegation Notices).
Information Blocking risk: Possible if Responders reject bona fide treatment queries solely because an otherwise authorized delegate’s paperwork is pending.
2. Permitted Purposes (including Patient Request transparency and Care Coordination)
Policy section: 3.1 (v3.0)
What changed: v3.0 maintains the same categories but (a) clarifies Care Coordination as a sub-category of Health Care Operations; (b) requires Patient Requesters to provide clear, accurate descriptions of downstream data use, with CARIN Code of Conduct recognized as a way to satisfy transparency; and (c) prohibits use of certain NHIN PurposeOfUse codes—PRESENT, EMERGENCY, DISASTER—replacing them with policy assertions where appropriate.
Practical impact: Initiators must label purposes precisely; consumer apps must update disclosures; misuse of prohibited PurposeOfUse codes can cause rejections.
HIPAA impact: More prescriptive than HIPAA; HIPAA does not require consumer apps to disclose downstream data uses.
Information Blocking risk: Generally low for providers. Burden is on Patient Requesters to meet transparency obligations.
3. Full Participation & Treatment “Credentialing”
Policy sections: 3.2; § 3.2.1 (v3.0)
What changed: Treatment Initiators must evidence provider status (e.g., NPI, licensure/certification such as CLIA for labs); v3.0 also codifies exceptions (e.g., Initiator-Only).
Practical impact: Smaller entities or atypical providers may be excluded from Treatment queries unless credentialing evidence is in place; Initiator-Only entities must be flagged.
HIPAA impact: More stringent than HIPAA, which allows disclosures to any “health care provider” (as defined) without imposing NPI/licensure proof for exchange.
Information Blocking risk: Heightened if credentialing screens bar legitimate providers who meet HIPAA’s provider definition.
4. “On Behalf Of” (OBO) Entities
Policy section: 3.2.1.3 (v3.0)
What changed: New Delegation Notice requirements by August 12, 2025; legacy OBO patterns are sunset with firm transition deadlines in September 2025.
Practical impact: Clearinghouses and other intermediaries must become formal Delegates or be de-listed.
HIPAA impact: More stringent than HIPAA (BA arrangements do not require central directory declarations).
Information Blocking risk: Possible if queries are blocked solely due to transition paperwork when the BA arrangement otherwise authorizes the activity.
5. Initiator-Only Delegate
Policy sections: 3.2.1.4; § 3.7.3 (v3.0)
What changed: Principals may designate Initiator-Only Delegates by attestation; model ties to the concept of Designated Record Set to clarify that the Principal remains the authoritative Responder.
Practical impact: Apps/tools that do not generate new clinical data can query but must rely on the Principal (not the delegate) to return records.
HIPAA impact: More stringent than HIPAA; HIPAA does not require a DRS-anchored delegation construct.
Information Blocking risk: Context-dependent – unreasonable delays in the Principal’s response could be scrutinized.
6. Patient Request — Identity Verification and Demographics
Policy sections: 3.6; § 3.6.1 (v3.0)
What changed: Requires use of a CSP vetted by a Carequality-approved certifying body (currently Kantara); mandates NIST IAL2/AAL2; requires verified demographic tokens; Responders may reject queries lacking verified demographics.
Practical impact: Consumer apps and portals must contract with or function as CSPs; Responders will expect IAL2/AAL2-based tokens and a prescribed demographic set for matching.
HIPAA impact: Significantly more stringent; HIPAA requires “reasonable verification” but does not prescribe NIST levels or third-party CSPs.
Information Blocking risk: Elevated if HIPAA-valid Patient Request transactions are rejected solely due to absence of a CSP token.
7. Delegation of Authority (new detailed framework and timelines)
Policy sections: 3.7; §§ 3.7.1–3.7.5 (v3.0)
What changed: Introduces detailed Delegation Notices/Revocations, SAML attributes (e.g., QueryAuthGrantor), directory pointers, and staged deadlines through September 22, 2025.
Practical impact: Principals, Delegates, and Implementers face new administrative tasks; misaligned directory/SAML configuration can block transactions.
HIPAA impact: More stringent; HIPAA requires BAAs but not directory-level delegation architecture.
Information Blocking risk: Significant, because technically valid queries could be rejected solely due to incomplete or misconfigured delegation documentation, which may be viewed as an unreasonable interference with EHI exchange unless a recognized IBR exception clearly applies.
8. Access and Patient Permission (Policy Assertions)
Policy sections: 4.4; § 4.4.1 (v3.0)
What changed: Expands standardized Access Policy Assertions (e.g., emergency handled as a policy assertion rather than a PurposeOfUse code); clarifies responder obligations, error handling, and consistent treatment of similarly situated requesters.
Practical impact: Initiators must support assertion signaling; Responders must align decisioning with asserted policies and their own documented access rules.
HIPAA impact: More prescriptive than HIPAA in how assertions are conveyed; HIPAA itself does not specify electronic assertion structures.
Information Blocking risk: Possible if Responders impose assertion requirements beyond what is reasonable to verify or process.
9. Non-Discrimination
Policy sections: 4.0; § 4.1 (v3.0)
What changed: Reinforces that no additional agreements, fees, or conditions may be imposed on Treatment queries; uniformly applied regardless of initiator type.
Practical impact: Reduces friction for Treatment exchange; curbs “special terms” gating access.
HIPAA impact: Generally consistent with HIPAA; HIPAA does not require extra contracts for Treatment disclosures.
Information Blocking risk: Low; these provisions help avoid discriminatory access policies.
The TEFCA Exception & the Double Standard Problem
One development that complicates this landscape is the new TEFCA Information Blocking Exception created under the HTI-1 Final Rule. As explained in my post “The HTI-1 Final Rule and the TEFCA Informaiton Blocking Exception: What It Means for HIEs & HINs,” this new IBR exception shields certain practices from being considered information blocking if they are necessary for, and consistent with, TEFCA participation. That means that for organizations participating in TEFCA, some of the same restrictive practices that might otherwise raise red flags under the Information Blocking Rule could be permissible. For example, credentialing requirements or assertion signaling might be tolerated under TEFCA’s governance because they are part of the uniform framework.
But this creates a conceptual puzzle: what about Carequality participants that have not yet opted into TEFCA? If those same practices are imposed under Carequality’s v3 Framework outside of TEFCA, are they “information blocking”? How can the very same requirement be viewed as reasonable when done under TEFCA but potentially unreasonable when done under Carequality? So, the real question becomes whether ONC and OIG will treat TEFCA alignment as a safe harbor that legitimizes policies, while non-TEFCA participants remain exposed to enforcement risk. If so,
HINs and HIEs face the uncomfortable prospect that the same conduct could be judged lawful or unlawful depending entirely on which governance framework they are operating under.
That inconsistency raises fairness and due process concerns, especially given the “knows or should know” standard applied to HINs and HIEs.
The Bottom Line
Most of the Carequality Version 3.0 requirements are more stringent than HIPAA (e.g., credentialing for Treatment, CSP/IAL2/AAL2 for Patient Request, and formal delegation architecture) and therefore appear to carry heightened risk under the Information Blocking Rule. Because HINs and HIEs are held to the stricter “knows or should know” standard, they must be especially careful that policy changes of this nature do not create requirements or procedures that effectively “interfere with” the access, exchange, or use of EHI in circumstances where HIPAA would otherwise allow disclosure. In short, participants may find themselves forced to clear hurdles set higher than HIPAA itself, and the risk of tripping grows with each added layer.
At the same time, the emergence of the TEFCA Exception means that identical practices may be shielded from enforcement if carried out under TEFCA’s umbrella. As Carequality continues to align with TEFCA, the regulatory paradox sharpens: the very same practice that protects a QHIN could expose a Carequality-only participant, or any non-TEFCA HIN/HIE, to allegations of information blocking. Whether these higher hurdles prove to be essential safeguards or unnecessary barriers, the way federal enforcers resolve this double standard will ultimately shape the future course of nationwide interoperability.