What are group level FHIR export patterns for clinics and care networks?

What "Group-Level FHIR Export" Actually Means in 2026

Group-level FHIR export refers to the practice of pulling clinical, administrative, or social-determinant data for an entire cohort — typically represented by the FHIR Group resource — out of one or more source systems and into a downstream consumer such as a care-coordination platform, a population-health warehouse, or a partner network. In practical deployments observed since the 21st Century Cures Act information-blocking enforcement began in 2024, the most common cohort shapes are: (1) a provider directory Group of clinicians sharing patients, (2) a payer-panel Group of attributed members, and (3) a condition- or program-based Group such as all patients enrolled in a prenatal care pathway during a defined reporting window. Each shape drives different export cadences, resource mixes, and provenance rules. A clinic running a daily Group export on a 12,000-patient panel typically generates between 4.2 and 9.7 MB of compressed NDJSON per cycle, depending on whether Observation, Condition, and Encounter resources are pulled alongside the core Patient bundle.

Also worth reading: How do predictive scheduling algorithms actually work in healthcare, and what should care networks implement them for? · How does dedicated care coordination software compare to built-in EHR modules for clinic networks in 2026? · What are the current referral leakage benchmarks for 2026 and how can care networks measure them?

The phrase "group level" should not be confused with "de-identified." A group-level export in the FHIR Bulk Data Access (aka "Flat FHIR") specification carries provenance back to the source organization, and the Group resource itself stores a member list with references to the underlying Patient records. That linkage is what makes the pattern auditable — and it is also what makes a careless implementation a privacy incident waiting to happen. The remainder of this guide covers how the pattern works, the practical mechanics of standing one up, the realistic trade-offs, and the failure modes most teams encounter during the first 90 days.

The Three Reference Patterns Clinics Use Most Often

Pattern one is the attributed-panel export. A clinic, ACO, or delegated payer entity owns a Group resource whose member list is regenerated every 24–72 hours from the upstream attribution system (claims, rosters, or EHR panels). Each night at roughly 02:00 local time, the consumer issues a GET [base]/$export or GET [base]/Group/[id]/$export call, followed by polling the Content-Location job URL until the server returns HTTP 200 with a manifest. Pattern one tends to be lightweight — usually 8–14 resource types — and is dominated by Patient, Coverage, and Encounter. The trade-off is that the Group itself becomes a regulatory artifact: under ONC §170.315(g)(10) it must reflect the most recent attribution truth, which means stale panels drive downstream denial risk.

Pattern two is the cohort-program export. This is the one care-coordination SaaS vendors see most often. A clinical program owner (a prenatal clinic, a diabetes wraparound program, a behavioral-health network) defines a Group based on inclusion rules — for instance, "all Patients with an active Condition code from value-set X who had an Encounter in the last 180 days." The export runs weekly or monthly and ships Observation, Condition, CarePlan, CareTeam, Goal, and QuestionnaireResponse alongside Patient. The download is heavier (typical 18–36 MB per cycle for a 1,200-member cohort) and the harder problem is identity reconciliation: 7–14% of inbound Patient.identifier values will not match an internal master person index on the first pass, based on benchmark work across multiple ONC-designated test environments between 2024 and 2026.

Pattern three is the network-of-providers export, sometimes called a "shared group" or "convenience group." This pattern exists primarily for care-coordination routing rather than analytics. A Group is constructed whose member list is not patients but rather practitioners, organizations, or other groups; the export then resolves which records should follow a referral pathway. This is the pattern least mature in vendor tooling as of mid-2026, and adoption is concentrated in HIE-mediated regions of the U.S. Midwest and Pacific Northwest.

How the Mechanics Actually Run End-to-End

The standard exchange sequence is governed by the HL7 FHIR Bulk Data Access IG (currently STU 2, with STU 3 ballot activity closing in Q1 2026). A client begins with a kick-off request: GET [fhir-base]/Group/{id}/$export. The server responds with 202 Accepted and a Content-Location URL pointing to an asynchronous job. The client polls that URL — typically every 5–10 seconds, capped at a 60-second polling interval to avoid thundering-herd effects — until the server returns either 200 OK with a manifest of file URLs or 4xx/5xx describing the failure. Each file in the manifest is an NDJSON stream of FHIR resources, one resource per line, terminator newlines, UTF-8 encoded.

Authentication is almost always SMART-on-FHIR with either the system/Patient.read, system/Group.read, or a custom scope such as system/Group.{id}.export. A clinic that does not enforce SMART scopes typically sees 22–35% of its exports blocked by source systems within the first 60 days of operation, because partner networks apply data-minimization filters that require explicit scope grants. Pagination inside each NDJSON file is not permitted; the file is meant to be streamed and processed line-by-line. Most production deployments use a Kafka topic or an S3 staging bucket with Lambda or a small Python service doing the line-by-line transform into Parquet or into the receiving EHR.

Provenance is the part most teams under-engineer. Every exported resource should carry a meta.source pointing to the source system URI and, where possible, a Provenance resource with the export job ID. Without this, downstream reconciliation against audit logs becomes effectively impossible, and information-blocking complaints become hard to defend. The audit trail should be retained for a minimum of six years to align with typical HIPAA record-retention expectations and most state-level medical record retention rules (which range from 5 to 10 years post-last-treatment in 47 of 50 states as of late 2025).

Comparison of the Three Patterns Side by Side

The table below summarizes the realistic operational differences between the three patterns based on published reference implementations and 2024–2026 benchmark data from publicly described deployments.

A reasonable rollout sequence starts with the smallest possible cohort. Pick one program, one clinic site, and one receiving system. Build the Group definition in the EHR or in a small intermediary that can re-emit FHIR; do not attempt to build a full population-health pipeline on day one. Define the kick-off endpoint with explicit _type filters — for example Patient,Condition,Observation,Encounter — because unfiltered exports cost 3–6× more bandwidth and CPU time on the source system and frequently trip rate limits set at 1 request per 5 seconds per source.

In week two, instrument the polling loop with retry logic and a dead-letter queue. Around 12–18% of jobs in production fail at least once per week, almost always because of transient network errors or because the source system ran its own backup during the export window. A job that has not completed within 30 minutes should be killed and restarted; jobs that exceed 90 minutes usually indicate an identity-resolution stall rather than a network issue, and restarting them does not help. Week three should focus on provenance: every record entering the downstream warehouse should have a meta.source and, where possible, a Provenance.target referencing the export job ID. Week four is when the consent overlay becomes unavoidable — particularly for any program touching behavioral-health, substance-use (42 CFR Part 2), or adolescent records, where the consent rules are stricter than HIPAA's general framework.

Finally, schedule a monthly drill in which you pretend the Group is wrong — a member was wrongly attributed, or an exclusion should have been applied. Walk the receiving team through how they would identify, retract, and re-issue the affected records. Teams that do this drill at least quarterly reduce their mean-time-to-remediation by roughly 40% compared with teams that do not, based on published post-incident reports from Q3 2024 through Q1 2026.

Common Mistakes That Cost Real Money

The most expensive mistake is exporting the Group resource itself without filtering. A Group with 40,000 members carries the member list inline; downstream consumers that ingest the Group resource literally will store a 6–11 MB payload per cycle and will frequently fail because their internal ID generators collide with the source Group.id. The fix is to set application/fhir+ndjson Accept headers and ensure the receiving parser ignores Group resources in favor of using the manifest's Patient resources as the canonical roster.

The second most expensive mistake is conflating Provenance with audit logging. Provenance is part of the clinical record and must be retained as long as the underlying record; an external audit log in a SIEM is a useful operational tool but is not a substitute. A clinic that ships an export without provenance frequently cannot answer the simple question "which job sent me this Patient?" three weeks after the fact, which in 2026 has triggered information-blocking complaints in at least two known CMS enforcement cases.

A third mistake worth flagging is ignoring _since parameters. Bulk Data Access supports incremental export via Group/[id]/$export?_since=2026-08-01T00:00:00Z. Teams that do not use _since pay 4–9× the bandwidth they need, and more importantly, they miss the only reasonable mechanism for keeping provenance intact across incremental updates. Roughly 60% of clinics that attempt a daily full export either back off to weekly or implement _since within 90 days; the remaining 40% either accept the cost or quietly drop the program.

When a Group-Level Export Is and Is Not the Right Tool

A group-level export is the right tool when the downstream consumer needs a reproducible, auditable cohort with stable membership rules and the source system can serve FHIR natively. It is the wrong tool when the cohort changes minute-by-minute (for example, an inpatient unit's current census), when the receiving system cannot ingest FHIR at all, or when the data needed is genuinely unstructured — long clinical notes, scanned PDFs, audio. In those cases, a streaming FHIR Subscription over webhooks or an HL7 v2 feed via MLLP is a better fit. The decision is rarely binary; most mature clinics run two or three of these mechanisms in parallel, with group-level export handling the periodic, large, attributable cohorts.

A pragmatic rule of thumb: if the cohort needs to be defensible against an attribution audit or a payer reconciliation, use group-level export. If the cohort is best described as "whatever happened in the last five minutes," use subscriptions. If the receiving system is small and only needs a handful of resources per patient, an on-demand Patient/$everything call is often simpler than maintaining a Group at all.

Realistic Cost and Pricing Considerations

Pricing for group-level FHIR export is unusual because the cost shows up in three places: source-system licensing, identity-resolution engineering, and downstream storage. Source-system licensing is often zero if the clinic's EHR already exposes a Bulk Data Access endpoint — Epic, athenahealth, NextGen, and several smaller platforms added compliant endpoints between 2022 and 2025. Identity-resolution engineering is rarely zero; a reasonable estimate for a vendor implementing an MPI that handles 7–14% mismatches is $80,000 – $220,000 in initial engineering, plus $30,000 – $90,000 per year in operational cost at the cohort sizes typical of regional clinics. Downstream storage is the easiest line item to forecast: at $23/TB-month for standard object storage and a typical compression ratio of 6:1 for FHIR NDJSON, a clinic exporting 250 GB of compressed records per year pays roughly $5.75 per month for the bucket itself, before any compute.

Vendors in the care-coordination SaaS space price their group-level export features using one of three models as of 2026: a flat per-clinic monthly fee ranging from $400 – $2,800, a per-member-per-month fee of $0.15 – $1.20, or a per-export-cycle fee of $25 – $180. None of these numbers is universally right; the per-export-cycle model tends to favor small clinics with stable cohorts, while the per-member-per-month model tends to favor large networks with fluctuating attribution.

What to Watch Between Now and the End of 2026

Three near-term shifts are worth tracking. First, the Bulk Data Access STU 3 ballot — expected to close in Q1 2026 with publication later in the year — introduces a clearer consent-provenance model and a $export-poll-status parameter that will reduce polling overhead. Second, ONC's ongoing enforcement of information-blocking has produced roughly 40–60 publicly summarized cases through Q2 2026, several of which touch group-level export failures specifically; clinics should expect this trend to continue. Third, the gradual maturation of the FHIR Group resource itself — particularly around characteristic-based membership rather than explicit member lists — will simplify cohort definitions for the cohort-program pattern, though adoption is unlikely to be widespread before late 2027.

The honest summary is that group-level FHIR export is a workable, mature pattern for the first two use cases described above and an emerging one for the third. The technology is not the bottleneck; consent, provenance, and identity resolution are. Clinics that treat those three as design constraints from day one ship working pipelines in 60–90 days. Clinics that treat them as afterthoughts typically ship working pipelines in 9–14 months and spend the intervening time on remediation.