Care Coordination Data Sharing: FHIR, TEFCA, and Info Blocking for Mid-Market Healthcare

Why info blocking is the regulator with teeth right now The healthcare CIO who spent the last fifteen years building HIPAA muscle has a reflex: when a regulator-facing question lands, route it to privacy and security, scope the data, lock it down. That reflex was correct in 2003 and almost correct in 2018. In 2026 it is the single most common source of penalty exposure we see in mid-market provider engagements. The rule with teeth this year is not HIPAA. It is the ONC information-blocking rule under the 21st Century Cures Act, and the posture it demands is the inverse of the HIPAA reflex: data must move unless an enumerated exception applies. The disqualified-provider penalties HHS finalized in 2024 changed the calculus. Before that final rule, info blocking was a regulator with rhetoric and a complaint portal but no operational consequence for a hospital, clinic, or behavioral health provider. The penalty pathway applied to certified health IT developers and HIEs, entities the average provider could blame, document around, and outlive. After the final rule, providers are direct subjects of a disqualification mechanism with downstream consequences that, depending on federal program participation, affect Medicare reimbursement, Promoting Interoperability participation, and program-specific payment adjustments. The OIG penalty authority for developers and networks (up to a million dollars per violation) was already in place; what shifted in 2024–2025 is that providers can no longer route the question to the EHR vendor and call it handled. We read provider-side info-blocking complaints every quarter. The pattern is consistent. A patient requests records through a portal, a referring provider asks for a CCDA, a payer requests claims-attached clinical data under a permitted use, or a third-party app developer attempts a USCDI pull through the FHIR endpoint the EHR vendor stood up. The request is denied, delayed, or returned in a format the recipient cannot use. The provider's compliance team, asked later why, points at the EHR. The EHR points at the provider's configuration, the provider's BAA scope decisions, the provider's consent matrix, or the provider's "we don't release behavioral health that way" policy that predates the rule and was never revisited. The defense does not work. The rule's "actor" definition pulls the provider in directly. The provider is responsible for the configuration of their certified health IT, the policies layered on top of it, and the operational decisions their staff make at the point of request. The EHR vendor's job under the same rule is narrower, they have to make the technology capable of compliant exchange, and they are typically already doing that job, because their own certification depends on it. The remaining gap is the provider's posture: who can release what, to whom, in what format, on what timeline, with which exception cited and documented. The exposure compounds. A disqualification finding is an enforcement determination that travels, federal program participation, network contracts, accreditation reviews, and acquisition diligence all read the OIG and ONC registers. A first finding is rarely fatal. The second shows up in every payer contract renewal and every M&A data room for the next five years. Calling this a HIPAA-adjacent problem and routing it to the same team is the failure mode. Info blocking and HIPAA do not point the same direction and do not respond to the same architecture. Run them as one program with two polarities, release-by-default for one, restrict-by-default for the other, under a single architecture that knows which polarity applies to which request. The eight info-blocking exceptions in plain English The information-blocking rule defines eight exceptions. If the provider's denial, delay, or degradation of access fits inside one of them, with documentation, the conduct is not info blocking. If it does not fit, it is. The exceptions are written in regulatory prose; they need to be readable by intake staff, release-of-information leads, and integration engineers, because those are the people who decide in real time whether to release. We summarize each below in the form we deliver to clients. 1. Preventing harm. The provider may withhold or limit access if release would substantially risk harm to the patient or another person and the determination follows the provider's own pre-existing policy on harm review. The exception is narrower than the HIPAA harm standard. It requires an individualized determination, a documented basis, and a policy that pre-dates the request. "We don't release psychotherapy notes" is too broad; "the treating clinician has reviewed this specific request and documented a substantial harm concern" is the form the exception takes. 2. Privacy. The provider may decline to fulfill a request if doing so would violate state or federal privacy law (including 42 CFR Part 2, state mental-health statutes, minor-consent rules, and similar). The exception is conditional on the provider having a written privacy practice that specifies the basis. The trap is that "privacy" here means a real legal restriction, not a discretionary preference. Withholding behavioral-health data from an in-network primary-care physician with a valid treatment-relationship request, in a state that does not require additional consent, is not a privacy exception, it is info blocking dressed up as privacy. 3. Security. The provider may decline access if fulfilling the request poses a specific security risk that cannot be mitigated through less restrictive means. This is not a general "we are not sure this app is safe" stance. It requires a documented security analysis of the specific risk, the considered mitigations, and the conclusion that denial is the least restrictive available option. App-vetting policies that categorically block patient-authorized third-party apps fail the exception unless each denial is individually documented. 4. Infeasibility. The provider may decline if the request is technically infeasible due to specific, documented circumstances, uncontrolled events (natural disaster, ransomware), segmentation that the provider's certified technology cannot perform, or resources required that are not reasonably available. The exception has a notification obligation: within ten business days, the provider must inform the requestor in writing why the request is infeasible. "Our EHR can't do that" rarely qualifies if the EHR is certified and the request is for USCDI. 5. Content and manner. The provider may fulfill a request in an alternative content set or manner if the requested form is not technically possible or would be unreasonable. This is the most-used exception and the most-abused. The rule sets a content priority: USCDI elements first, then EHI, in the format the requestor specified, then a mutually agreeable format, then the provider's choice. Skipping straight to "we'll send you a CCDA PDF in two weeks" because that is what the release-of-information team has always done is the canonical content-and-manner failure. 6. Fees. The provider may charge fees for access, exchange, or use, but the fees must be based on objectively verifiable costs, must not be discriminatory, and must not exceed levels permitted by other applicable law (HIPAA's reasonable-cost-based fee for individual access, in particular). Fees that exceed HIPAA's individual-access ceiling for a patient request, or fees imposed on a patient-authorized app, are typically info blocking. Fees on a payer or third-party requestor for a non-permitted-use exchange may be defensible. 7. Licensing. The provider may license interoperability elements (APIs, data, content) on reasonable, non-discriminatory terms. The license terms cannot be used to entrench market position, lock out competitors, or coerce a requestor into commercial relationships. The exception applies most often to certified health IT developers; providers encounter it when their EHR vendor's API license is the actual blocker and the provider is asked to escalate. 8. Health IT performance. The provider (or developer) may take a system temporarily offline for maintenance or improvement if the downtime is consistent with normal operating practice and is communicated. Scheduled maintenance windows, security patching, and incident response fit. Indefinite or undocumented downtime, or downtime that affects exchange while internal access continues, does not. The exceptions are conjunctive in practice: each requires both a substantive condition and contemporaneous documentation. A denial that would have qualified under "preventing harm" but was never written down with the basis and the policy reference is, on review, indistinguishable from a denial without grounds. The documentation is the exception. FHIR API requirements: USCDI v3 reality The certified health IT a provider uses is required, under the ONC Cures Update final rule, to expose a FHIR R4 API supporting the United States Core Data for Interoperability. As of the publication of this guide, USCDI v3 is the operative standard; USCDI v4 has been adopted and is sequencing into compliance dates over 2026–2027, and v5 is in development. Providers who scope their FHIR posture to v1 (the original 2020 set) are exposing themselves to two risks: the static one of supporting a now-superseded standard, and the dynamic one of having no internal mechanism for the next version when it arrives. USCDI v3 covers a broader and more clinically meaningful surface than the original list. Beyond the v1 demographics, problems, medications, allergies, lab results, and immunizations, v3 adds elements around health insurance information, social determinants (SDOH assessments and goals), sex parameters for clinical use, sexual orientation and gender identity, occupational data, and an expanded clinical-notes set. Each new element is a place where a FHIR endpoint either correctly exposes the data, returns an empty bundle when the data is recorded but not mapped, or returns an error. We see all three failure shapes. The most common is the second: the EHR has the field, the clinician documents into it, and the FHIR endpoint does not map it because the provider's integration team scoped the original deployment to v1 and never revisited. The endpoint returns a 200, but the bundle is missing elements a v3-aware requestor expects. Under the rule, returning an incomplete bundle without explanation is a content-and-manner question; if the provider has the data and the certified system can map it, the omission is the conduct. "All data" in the rule's context is not literal. The rule applies to "electronic health information" (EHI), defined as the HIPAA designated record set with carve-outs for psychotherapy notes and litigation-anticipation material. The FHIR API requirement, separately, is scoped to USCDI plus, on patient or authorized request, the broader EHI set. A provider's FHIR posture has to support: USCDI v3 elements as standard API responses; bulk FHIR ( ) for population-level requests; the broader EHI set when explicitly requested; and SMART-on-FHIR app authorization for patient-authorized third-party apps. The patient-authorized app pathway is where the rule meets the smartphone. A patient who authorizes a third-party app to pull from their provider's FHIR endpoint is exercising a right the rule protects. The provider cannot block the app because it has not been "vetted," cannot impose a per-pull fee on the patient-authorized request, and cannot require the patient to come into the office to authorize. The SMART-on-FHIR flow, properly implemented, is how the provider satisfies the obligation; absent a security-exception finding documented per request, blocking the flow is info blocking. Bulk FHIR matters disproportionately for ACO, value-based-care, and payer-side workflows. A payer or downstream ACO that needs population-level data for quality measurement, risk adjustment, or care management has a permitted use. The endpoint must support the bulk export; if it does not, the provider must fall back to an alternative manner under the content-and-manner exception, with notification, within timelines. We have read denials that simply said "we don't do bulk." That is not an exception; that is the conduct. USCDI v4 is the forward-looking question. The added elements concentrate around imaging, advance directives, expanded SDOH, and additional clinical-decision-support context. Providers who built their playbook to v1, were caught out by v3, and have not updated for v4 will be caught out twice in eighteen months. The fix is a quarterly review cadence on the FHIR endpoint against the published USCDI version, owned by a named IT role and reviewed by compliance. TEFCA participation: when, why, and what it costs The Trusted Exchange Framework and Common Agreement is the federal nationwide-exchange network that went operational in late 2023 and reached production scale in 2024–2025. TEFCA is participated in through Qualified Health Information Networks (QHINs), a small set of designated networks (eHealth Exchange, Epic's Nexus, CommonWell, Health Gorilla, Kno2, MedAllies, KONZA, and others approved during 2024) that act as the inter-network backbone. A provider does not "join TEFCA" directly; the provider connects to a QHIN, and the QHIN handles the cross-network exchange. The participation question for a mid-market provider has three dimensions: which QHIN, at what cost, and on what timeline. Which QHIN. The functional choice is between a QHIN the provider's EHR is already integrated with (Epic Nexus for Epic shops, CommonWell for many community-hospital and ambulatory deployments, eHealth Exchange for federated-government settings) and a QHIN the provider's regional HIE is connected to. The wrong question is "which QHIN is best." The right question is "through which QHIN does our existing connectivity reach the most counterparties our patients actually exchange with." That is an analysis of referral patterns, payer contracts, and the regional HIE landscape; it takes a week with the right data. At what cost. QHINs charge participation fees that vary by org size, transaction volume, and use-case scope. The headline cost for a mid-market provider is typically low to mid five figures annually, plus integration. Integration is the larger number for orgs without an existing connection: an EHR integration project, a directory and identity workstream, and a policy update for the new permitted-use scope. We have seen ranges from $40K (riding on existing EHR connectivity) to $300K (greenfield through a regional HIE intermediary). The recurring is tractable; the one-time integration is the budget question. On what timeline. TEFCA participation is not federally mandated for most providers in 2026. It is becoming de facto mandatory through three channels. First: payer contracts increasingly cite TEFCA-compliant exchange as a requirement for value-based arrangements. Second: federal use of TEFCA for treatment, payment, and operations exchange creates pressure for any provider serving Medicare and Medicaid at scale. Third: the content-and-manner exception is harder to invoke when a TEFCA-mediated path is available and the provider declines to use it. Cost-benefit by org size is approximately: under 50 clinicians, TEFCA is rarely the right first investment unless a contract or specific relationship demands it; the regional HIE plus a robust FHIR endpoint covers most of the surface. 50–500 clinicians, participation through the existing EHR's QHIN is usually defensible and increasingly necessary. Above 500 clinicians, TEFCA is the baseline assumption; the open question is single QHIN versus multiple for redundancy and reach. Behavioral-health providers face an additional layer. The 42 CFR Part 2 final rule (2024) aligned consent management with HIPAA in important ways but preserved substance-use confidentiality protections. TEFCA exchange of Part 2 data requires the QHIN and the provider to support segmented data and consent-aware exchange. Not every QHIN supports this at parity, and a behavioral health provider's QHIN selection has to filter for that capability first. The four failure modes Securem sees Across the healthcare and behavioral-health engagements we run on info-blocking and interoperability scope, four failure modes recur. Each is sanitized below from real findings. Failure mode 1: Patient access portal that doesn't actually expose USCDI. A multi-site primary-care group deployed the patient portal that came with their EHR and reported full patient access. The portal exposed demographics, medications, problems, and lab results. It did not expose the USCDI v3 additions: SDOH assessments the practice had documented for two years, SOGI fields, the expanded clinical notes set. The ROI team was answering individual chart requests for the missing elements manually, in five-to-ten-business-day windows. The portal configuration was eight years old. The fix was a configuration update plus an internal audit of every v3 element against the actual API response. Five days of work; the finding had been live for eighteen months. Failure mode 2: Provider-to-provider exchange that fails on consent. A regional behavioral health provider received treatment-related referrals from primary-care practices and replied through an HIE-mediated exchange. The replies were systematically delayed by a consent-verification workflow that pre-dated the 2024 Part 2 final rule and required wet-signature consent for each disclosure. The state had aligned with the federal Part 2 update; the wet-signature requirement was no longer mandatory. Replies were taking two-to-four-week windows because of physical signature handling. Referring providers had stopped sending substance-use cases for follow-up. The fix was a policy update aligning to current Part 2 plus a consent-capture workflow redesign. Referral volume recovered over two quarters. Failure mode 3: Payer access blocked by policy that no longer applies. A specialty-care provider had a longstanding policy of denying payer access to clinical records outside individual-claim audit requests, based on historical disputes with a regional payer. After the info-blocking rule and the prior-authorization-related federal rules took effect, the payer began submitting permitted-use requests through the FHIR endpoint. The provider's policy routed those requests through the old ROI channel, with denials and delays. The payer documented the conduct and filed a complaint. The defense, that the provider had a policy and applied it consistently, was not an exception. The policy was the conduct. The fix was a policy revision recognizing the permitted-use framework, plus an exchange path matched to the request type. Failure mode 4: Behavioral health data carve-out that overscopes. A community mental-health provider, applying a precautionary read of state mental-health law, segmented all patient records as Part 2-equivalent and refused exchange without per-disclosure consent. The actual Part 2 scope applied only to a subset of patients and a subset of records. Outside that scope, state law permitted treatment-relationship exchange without per-disclosure consent. The blanket carve-out was overscoping the privacy exception. The fix was a data-classification project: which records fell under Part 2, which under state mental-health law, and which under HIPAA-with-no-additional-restriction. The exchange posture differentiated by category afterward. The pattern: the provider's policy or configuration was older than the rule, the staff applying it had no authority to deviate, and the architecture made the wrong default cheaper than the right one. The fix in each case was a rule-aware policy refresh plus a configuration update inside systems the provider already owned. The architecture that satisfies HIPAA + info blocking + 42 CFR Part 2 Three rules, one architecture. The mistake is treating them as three separate compliance programs with three separate technical surfaces. A single architecture, scoped correctly, satisfies all three; what differs is the polarity (release-by-default vs. restrict-by-default) and the documentation overlay. The architecture has six load-bearing components. 1. A unified consent and authorization service. Patient consent, authorized-app authorizations, payer permitted-use determinations, and Part 2 segmented-data consents all represented in one service that the FHIR endpoint, the HIE connection, and the QHIN exchange can read at request time. Granular is the operative word: per-record-type, per-recipient-class, per-purpose-of-use. The most common failure is a binary "consented / not consented" flag that cannot represent "consented for treatment to in-network providers, not consented for payer disclosure beyond minimum-necessary, opted out of TEFCA exchange of Part 2 data." The service is a well-modeled data table with an API surface. 2. A request router that maps each inbound request to the applicable polarity. A SMART-on-FHIR patient access request defaults to release; a payer permitted-use request defaults to release within minimum-necessary; an internal analytics query defaults to minimum-necessary restriction. The router reads the request type, consults the consent service, and either fulfills or routes to a documented exception path. This is where the info-blocking release-by-default polarity meets the HIPAA minimum-necessary restraint. 3. A unified audit trail. Every release, denial, and delay logged with the requestor, request type, data set returned or refused, rule cited (info-blocking exception, HIPAA authorization, Part 2 consent), policy reference, and timestamp. One log, not three. We have seen orgs maintain a HIPAA disclosure log, a separate ROI denial log, and an HIE exchange log, with no cross-reference. That is three audit trails to defend; it should be one. 4. A documented exception policy library. Each of the eight info-blocking exceptions has a written policy staff can apply at the point of request, specifying the substantive condition, documentation requirement, and escalation path. Without the library, every denial is ad hoc and, on review, looks like the conduct. 5. A USCDI version management practice. The FHIR endpoint's USCDI coverage reviewed every quarter against the current published version. New elements scoped, mapped, exposed; deprecated elements flagged. Owned by a named IT role with compliance review. 6. A TEFCA / HIE exchange path with consent-aware segmentation. The outbound exchange path supports the full set of permitted-use cases with the consent service feeding the segmentation logic. For Part 2 data specifically, the path either supports segmented exchange or routes that data to an alternative path with documented consent. The architecture above is not novel. Every certified EHR supports the technical primitives. What is missing in the orgs we audit is the connective tissue, and connective tissue is not vendor work, it is internal program work. Where the Diagnostic fits When a provider engages us on the Pass-Audits Diagnostic for interoperability scope, we run the Healthcare Interoperability Diagnostic, a fixed-scope, fixed-price written assessment over two to three weeks. The output is a report the CIO can hand to the board, the auditor, the next payer renewal, and the next acquisition diligence. The structure is the architecture above plus the rule overlay: we inventory every exchange path, audit it against info blocking + HIPAA + Part 2, and produce a sequenced remediation list with owner and effort estimate. We do not implement the remediation, that work belongs to the provider's IT and compliance teams, or to a partner of their choice. We document what to fix, in what order, why, and what "done" looks like for each item. The Diagnostic is not a vCISO retainer. The partners run productized retainers when an org wants ongoing program oversight; the Diagnostic is the standalone written assessment. Most providers we work with start with the Diagnostic, sit with the report for a quarter, and decide independently whether retainer-shape oversight makes sense afterward. The Healthcare Interoperability Diagnostic, and three actions a healthcare CIO can take this month Three actions any healthcare CIO can take this month, regardless of whether they engage us: 1. Run the FHIR endpoint against the published USCDI v3 element list. Pick ten patient charts that exercise the v3 additions (SDOH, SOGI, expanded clinical notes, occupational data). Pull each through the FHIR endpoint and confirm every populated element is in the response. Most orgs find at least one missing mapping on the first pass. 2. Pull the last six months of release-of-information denials and code each against the eight exceptions. Every denial that does not fit one of the eight is a finding. Every denial that does fit but lacks contemporaneous documentation of the basis is a finding. The volume of findings is the provider's current info-blocking exposure; the trend is the provider's program direction. 3. Map every external exchange path to its consent posture. Patient portal, SMART-on-FHIR apps, HIE connection, QHIN connection (if any), direct payer feeds, ROI channel. For each, document what the consent service tells it and what the default is when the consent service is silent. The defaults are the architecture; the defaults are usually wrong. Three actions, one quarter, no engagement required. If the FHIR audit, the denial coding, or the consent map surfaces gaps the org cannot close internally, or if the architecture decision is large enough that getting it wrong is expensive, that is where the Diagnostic comes in. Two to three weeks, fixed price, written report you keep regardless. The FHIR / TEFCA / Info-Blocking Readiness Checklist paired with this guide gives you a worksheet for the three actions above plus the six architecture components from section six. Use it on the next FHIR endpoint review. Use it on the next QHIN selection conversation. Use it on every release-of-information policy refresh, and we will keep updating it as the rule landscape moves.