Storage size is the metric that quietly shapes hosting cost, backup windows, and disaster-recovery RTO over the life of a FHIR platform. A new public benchmark from Health Samurai loaded the same Synthea dataset (1,000 patients, around 2 million resources) into four FHIR servers running on identical hardware, and the storage footprint after import ranged from 4.24 GB to 22.6 GB. That spread is large enough to change the conversation about which server fits which deployment.

The Storage Numbers After Identical Data Load

The four servers, ranked by on-disk size after loading the same Synthea data:

• Microsoft FHIR Server: 4.24 GB
• Aidbox: 6.83 GB
• Medplum: 11.8 GB
• HAPI FHIR: 22.6 GB

That is a 5.3x spread on the same dataset. For more on FHIR storage and hosting models, the trade-offs behind the numbers matter more than the ranking itself.

What Drives the Spread

The spread is not really about how efficiently each server encodes a FHIR resource. The dominant factor is how each server treats search indexes at write time. HAPI, Medplum, and the Microsoft FHIR Server pre-build search indexes as resources arrive. The index tables, supporting structures, and metadata they maintain on write are what fill most of the disk. Aidbox ships without default search indexes; the operator decides which indexes to create based on the queries the application actually issues.

That single design choice produces the bulk of the footprint difference. The Microsoft FHIR Server happens to land smallest in this snapshot, which reflects SQL Server 2022's storage layout for the indexed columns it builds. HAPI's footprint reflects the JPA schema's broader pre-built index coverage.

Why the Indexing Default Matters in Production

A FHIR platform that pre-builds every plausible index ships ready for any query the application might issue. The cost is on disk, in import time, and in write throughput. A FHIR platform that ships with no default indexes is faster to import and smaller on disk, but the operator carries a real responsibility: an unindexed search at production load will degrade in ways that are hard to debug after the fact.

Neither default is wrong. They serve different operator profiles. Teams that want the platform to handle search performance automatically benefit from the pre-indexed default. Teams that own their search patterns and want explicit control prefer the no-default-indexes posture. The benchmark report makes the trade-off readable, which is the useful contribution.

What the Storage Footprint Implies for Hosting Cost

Storage cost itself is rarely the limiting factor in a CMS-0057-F deployment. What scales with storage is everything around it: backup volume, replication bandwidth, restore time, snapshot storage on cloud disks, and the working-set size that has to fit in memory for hot paths to stay fast. A FHIR platform that is 5x larger than its peers has 5x the backup time, 5x the replication catch-up window after a node loss, and 5x the cold-storage spend.

That is not a reason to pick the smallest footprint; it is a reason to understand what the footprint implies operationally before committing.

A Note on the Source

The benchmark was authored by Marat Surmashev, VP of Engineering at Health Samurai, which is also the company that develops Aidbox. The repository is open source and reruns daily, which makes the storage numbers re-verifiable on the live dashboard, but the obvious caveat applies: this is a vendor-run benchmark, and readers evaluating any of the four servers should re-run it against their own workload before drawing conclusions.

What to Do With This Number

Storage footprint is one input among many. For the broader question of how PostgreSQL-based FHIR engines compare on storage and operational tooling, the Top 5 PostgreSQL-based FHIR engines for 2026 covers the substrate layer. For how storage and indexing choices feed into the data store patterns a reusable FHIR investment depends on, the Top 6 FHIR data store patterns for reusable compliance investment covers the architectural side.

— Beatrix Landsberg

Da Vinci publishes a portfolio of FHIR Implementation Guides covering provider-payer interactions. CMS-0057-F anchors on a few of them (CRD, DTR, PAS) but several others matter for the broader provider-side workflow. EHR integration teams need to understand which IGs are required for compliance, which are emerging standards, and which are experimental but worth watching. For payer-provider FHIR integration reading on this site, here are six worth knowing in 2026.

1. Da Vinci CRD IG STU 2.0.1

Coverage Requirements Discovery (CRD) is the order-time decision support IG. The CRD service responds to CDS Hooks calls from the EHR with information about whether PA is required, what documentation is needed, and what comes next. CMS-0057-F requires CRD as part of the Prior Authorization API.

For EHR integration teams, CRD is the entry point. A clinician's order triggers the CRD call; everything downstream depends on whether CRD fires reliably and returns useful information.

2. Da Vinci DTR IG STU 2.0.1

Documentation Templates and Rules (DTR) is the questionnaire-rendering IG. The DTR SMART app launches inside the EHR (typically from a CRD card), renders the payer-specific Questionnaire, runs CQL rules to drive conditional logic, and collects the supporting documentation needed for the PA decision.

DTR is where the provider workflow lives. If DTR is awkward to use, providers abandon the workflow and submit PAs through legacy channels regardless of what the rest of the stack does.

3. Da Vinci PAS IG STU 2.0.1

Prior Authorization Support (PAS) is the submission and response IG. The completed Bundle from DTR is sent to PAS, the payer renders a decision, and the response flows back. PAS often round-trips through X12 278 / 275 inside the payer back office.

PAS is the layer most often confused with the entire ePA workflow. In practice, PAS is the submission endpoint that closes the loop the CRD-DTR sequence opened. All three IGs operate together; isolating any one of them produces an incomplete picture.

4. Da Vinci PDex IG STU 2.1.0

Payer Data Exchange (PDex) is the IG that governs clinical data exchange between payers and providers, including the broader Patient Access API scope. PDex is referenced by CMS-0057-F for Provider Access and Payer-to-Payer flows, and it carries the clinical resource profiles (Condition, Procedure, Observation) that PDex Plan Net and CARIN BB do not cover.

For EHR integration teams, PDex Patient Access is the IG that defines what clinical data the EHR can expect when consuming the Patient Access API.

5. Da Vinci HRex IG

Health Record Exchange (HRex) is a foundation IG that PDex and the other Da Vinci IGs reference for shared profiles and patterns. Most implementations do not directly target HRex but pull profiles from it through the IGs that use it.

For deep implementation work, HRex is worth understanding because changes there ripple through PDex, PAS, and others.

6. Da Vinci Risk-Based Contract IG (Emerging)

The Risk-Based Contract IG is newer Da Vinci work that addresses value-based care contract data exchange between payers and providers. It is not part of CMS-0057-F but signals where the Da Vinci portfolio is heading.

For payers and EHRs that participate in risk-based contracts (which is most large US payers and many health systems), the Risk-Based Contract IG is worth tracking. Production deployments are limited in 2026 but expected to grow.

How to Read Da Vinci IG Maturity

Da Vinci IGs use the standard HL7 maturity ladder: Draft, Trial Use (STU), and Normative. STU 2.0.1 or later for CRD, DTR, and PAS represents maturity adequate for CMS-0057-F production work. Earlier versions exist but should not be the integration target for new work in 2026.

A useful pattern during integration planning is to verify which IG versions the target EHR and the payer's platform actually support, because mismatches surface as conformance failures during testing.

For the CDS Hooks layer that powers CRD specifically, the Top 5 EHRs with strong CDS Hooks support for Da Vinci CRD covers the EHR-side picture. For the SMART App patterns that power DTR, the Best DTR SMART app patterns for provider workflows covers the implementation side.

Sources

• Da Vinci CRD IG v2.0.1

— Beatrix Landsberg

Member Match accuracy determines whether Payer-to-Payer Data Exchange works at all. A false negative loses the member's history, a false positive triggers a privacy incident. Five strategies have emerged as the practical patterns in 2026, each with different operational characteristics and trade-offs. Most production deployments combine two or three of them. Here are the five worth knowing for more on payer-to-payer transfers decisions.

1. Deterministic-First with Probabilistic Fallback

The most common pattern in 2026 deployments. The Member Match engine first attempts a deterministic match (exact identifier, name, DOB, SSN where allowed). If no deterministic match, it falls back to probabilistic with a high confidence threshold (typically 0.9 or above). Below the threshold, the request returns no match and the receiving payer cannot consume data.

This pattern minimizes false positives at the cost of accepting some false negatives. The trade-off works for plans that consider data loss less risky than wrong-patient data.

2. Probabilistic with Operator Review for Mid-Confidence

A more aggressive pattern that adds an operator-review queue for mid-confidence matches (typically 0.7 to 0.9). The match returns provisional, and a human reviewer at the prior payer confirms or rejects before the data transfer completes.

The pattern catches more matches than deterministic-first but requires operational capacity. Plans with high member-switching volume need to staff the review queue carefully or face transfer backlogs.

3. Referential MPI with Universal Identity Source

Pattern where the Member Match engine consults a third-party referential identity database (Verato's Universal Identity is the canonical example) to fill demographic gaps. The receiving payer's request gets enriched with referential data, which improves match quality against the prior payer's records.

The pattern increases match accuracy on incomplete data substantially. The trade-off is the commercial relationship with the referential provider and the data flow through their infrastructure during matching.

4. Coverage-Anchored Match

Some implementations leverage the Coverage resource in the Member Match Bundle for additional matching signal. The receiving payer's Coverage information often includes prior plan ID, group number, or subscriber details that the prior payer can use to confirm match in cases where demographic data alone is ambiguous.

The pattern is particularly effective when members move between plans within the same parent insurer (Medicare Advantage to Medicare Advantage at the same carrier) or between affiliated plans. Member ID transitions become a strong match signal.

5. Network-Mediated Match via TEFCA

For payers participating in TEFCA, Member Match can route through the network's identity infrastructure rather than running point-to-point. The QHIN handles the match across multiple data partners, and the result is delivered to the requesting payer. The pattern shifts the match operation out of the payer's direct control but reduces the per-relationship engineering work.

For payers without TEFCA participation, this pattern is not available. Most 2026 deployments are not yet using TEFCA for Member Match at production scale, but the path is starting to materialize.

How to Pick the Strategy for Your Plan

The strategy choice usually combines two or three patterns rather than picking one. A typical mid-market payer uses deterministic-first with probabilistic fallback as the baseline (covers the easy cases cleanly), adds coverage-anchored matching for cases where demographic data is ambiguous (catches plan-switching cases), and may add operator review for high-stakes cases (specialty drug PA history, ongoing chronic care).

Plans with substantial member acquisition volume from sources with weak data quality benefit from referential MPI. Plans with stable member populations that switch primarily within established carrier relationships rely more on coverage-anchored matching.

For the underlying deterministic versus probabilistic trade-off, the Deterministic vs Probabilistic Member Match comparison lays out the algorithmic side. For the Consent flow that runs alongside Member Match in the Payer-to-Payer transfer, the Top 5 FHIR Consent patterns for Payer-to-Payer covers the parallel layer.

Sources

• Da Vinci PDex IG v2.1.0 (Member Match operations)

— Beatrix Landsberg

FHIR Bulk Data export performance becomes a load-bearing concern for CMS-0057-F when realistic Provider Access volume arrives. A payer with a 200,000-member network and many in-network provider organizations runs hundreds of group-level exports per quarter. Slow exports compound into operational issues: missed SLAs, stale data, frustrated provider IT teams. Five optimizations consistently make the difference between a Bulk Data implementation that scales and one that does not. For the FHIR Bulk Data knowledge base on this site, these are the field-tested techniques.

1. Parallel Resource Serialization

The most impactful optimization. A naive Bulk Data implementation iterates through the member panel serially, fetching each member's resources one at a time and writing them to NDJSON. A tuned implementation parallelizes across members (and across resource types within a member) using a worker pool.

The performance delta is substantial. A serial implementation of a 100,000-member export might run 4 to 8 hours; a parallelized implementation can complete the same export in 20 to 40 minutes on similar infrastructure.

2. Snapshot Consistency at Export Start

A pattern that prevents the data drift that surfaces during long-running exports. The exporter captures a point-in-time snapshot of which member resources to include at export start, and the actual export reads from that snapshot rather than from live data. If the panel changes during the export (members added or removed), the export reflects the consistent snapshot rather than producing inconsistent output.

The pattern matters more than it sounds. Without snapshot consistency, a panel that loses a member halfway through the export produces output where some resources for that member are included (those exported before the change) and others are not (those that would have been exported after). Consumers cannot easily detect or recover from this inconsistency.

3. Streaming NDJSON With Chunked Output

A pattern where the exporter writes NDJSON to the output destination (typically S3 or equivalent) progressively rather than buffering the entire file in memory before writing. The output is chunked at reasonable size boundaries (typically 100 to 500 MB per file) so consumers can download and process in parallel.

The pattern matters for memory efficiency and consumer-side parallelism. Implementations that produce one massive NDJSON file per resource type force consumers to download serially; chunked output allows parallel download.

4. Resource-Type-Specific Pipelines

A pattern where the export pipeline branches by resource type, with each type having its own optimized fetch and serialization path. Patient resources have different access patterns than Observation; Condition has different patterns than Procedure. A pipeline that treats all resource types identically misses optimizations available within each type.

The implementation complexity is in maintaining type-specific pipelines without code duplication. Frameworks that abstract the type-specific logic cleanly produce better results than monolithic export code.

5. Compression at the Output Boundary

The simplest but often skipped optimization. NDJSON output compresses well (typical compression ratios of 5 to 10 to 1 with gzip). Producing compressed output reduces download time for consumers and storage cost for the exporter. The Bulk Data IG allows compressed output if the manifest declares it.

Some consumers cannot handle compressed output (typically due to consumer-side implementation limitations rather than spec issues). Production exporters should support both compressed and uncompressed output, with the choice negotiated at request time or configured per consumer.

How These Optimizations Compound

The optimizations are not independent. Parallel serialization combined with chunked streaming output combined with compression produces something close to optimal throughput for typical CMS-0057-F workloads. Implementations that adopt one or two but skip the others leave significant performance on the table.

A useful benchmark for production-grade is: a tuned implementation can complete a 100,000-member group-level export with five-year history in under 30 minutes, producing compressed NDJSON output in chunks under 500 MB. Implementations that hit this benchmark cleanly handle CMS-0057-F volume without operational stress.

For the broader async export patterns that wrap these optimizations into a complete delivery model, the Top 5 Async export patterns for FHIR Bulk Data implementations covers the operational layer. For monitoring the health of Bulk Data operations in production, the Top 5 tools for monitoring FHIR Bulk Data export health covers the observability side.

Sources

• FHIR Bulk Data Access IG v2.0.0

— Beatrix Landsberg

CMS-0057-F is often discussed from the payer side, but most of the value depends on the EHR side cooperating. Da Vinci CRD has to fire inside the provider's EHR workflow. DTR has to render as a SMART app inside the EHR. PA decisions have to flow back to the EHR through CDS Hooks responses or FHIR Subscriptions. The Patient Access API depends on the EHR consuming the member's transferred history when the member shares it. None of this works if EHR integration is weak. This guide lays out what production-grade EHR-payer integration actually requires in 2026, for the EHR-payer integration hub on this site.

The Three Integration Surfaces That Matter

Three EHR integration surfaces carry the weight of CMS-0057-F adoption. CDS Hooks is the entry point for CRD: the EHR calls out to the payer's CRD service when the clinician hits a workflow trigger (order-sign, order-select, appointment-book), and the service returns coverage-requirements information inline. SMART App Launch handles DTR: the EHR launches the payer's DTR SMART app inside the provider workflow to render the questionnaire and collect documentation. FHIR REST is the broader surface for the Patient Access and Provider Access APIs that EHRs and third-party apps consume.

Each surface has its own conformance bar, its own vendor-EHR support gaps, and its own operational quirks.

Where Major EHRs Stand in 2026

Epic, Cerner Oracle Health, athenahealth, Allscripts, eClinicalWorks, and NextGen are the major US EHRs by market share. Their CDS Hooks support varies. Their SMART App Launch maturity varies. Their willingness to ship updates that improve Da Vinci compatibility varies.

Epic and Cerner Oracle Health have the strongest CDS Hooks and SMART App Launch support in 2026. They certify third-party apps through structured programs (Epic App Orchard, Cerner CODE) that gate which payer-built apps can launch in production. athenahealth and Allscripts have growing support but more variance across customer installations. eClinicalWorks and NextGen are weaker on Da Vinci patterns.

For deeper EHR-specific coverage, the Top 5 EHRs with strong CDS Hooks support for Da Vinci CRD breaks down where each EHR sits.

The Vendor-Side Approval Process That Surprises First-Timers

Submitting a payer-built CDS service or SMART app to Epic or Cerner takes time. Epic App Orchard certification typically runs three to six months. Cerner CODE certification can be similar. The process includes security review, conformance validation, and operational testing.

Payers building CMS-0057-F integration in 2026 need to start the EHR certification process well ahead of the January 2027 deadline. Plans that delay until late 2026 risk launching CDS services that work in test but are not approved for production in the target EHRs.

For the SMART app patterns that work well across these EHR certifications, the Best DTR SMART app patterns for provider workflows covers the field-tested designs.

The Provider Network Engagement Problem

EHR integration is technical, but the adoption inside provider organizations depends on more than technical conformance. Providers have to actually use the CDS prompts, complete the DTR forms, and follow through to PAS submission. Plans that focus only on technical integration without provider-network engagement see low adoption even when the technical layer works.

Strong engagement looks like provider onboarding documentation, support during initial workflow integration, feedback loops for provider issues, and incentives that align with the new workflow (faster PA decisions, reduced denial rates) rather than working against it.

How the Notification Path Closes the Loop

After the EHR submits a PAS Bundle and the payer renders a decision, the decision has to flow back to the EHR. Two patterns exist: CDS Hooks card with an updated response (the EHR refreshes the prompt with the new decision) or FHIR Subscriptions notification (the EHR is alerted to a status change and fetches the updated decision).

The CDS Hooks vs Subscriptions choice has operational consequences for how the EHR experiences the decision flow. For the comparison in depth, the CDS Hooks vs FHIR Subscriptions for EHR-Payer notification comparison covers the two patterns side by side.

Sources

• Da Vinci CRD IG v2.0.1

— Beatrix Landsberg

For health plans that do not have member-selected PCPs (most PPO plans, traditional Medicare, many Medicare Advantage plans without HMO product design), the attribution-of-record for Provider Access has to come from somewhere. Two methodologies dominate: geographic attribution (member's address mapped to nearest provider) and claims-based attribution (member assigned to provider based on actual care utilization). Both are conformant; the choice has substantial operational consequences. This comparison lays out the trade-offs for the EHR-payer integration hub decision-making.

What Each Methodology Does

Geographic attribution maps the member's address to the nearest in-network provider of a specified type (typically PCP). The implementation uses geocoding (member address to coordinates) combined with provider location data (clinic addresses) to identify the closest provider, then attributes the member to that provider.

Claims-based attribution analyzes the member's claim history over a defined look-back window (12 to 24 months typically) and identifies the provider the member used most often or most recently for primary care. The provider with the most visits (or the most recent visit, depending on the algorithm) becomes the attribution-of-record.

Where Geographic Wins

Geographic attribution wins on completeness. Every member with a known address has a geographic attribution; there are no edge cases where the methodology cannot assign. New members who do not yet have claim history get attributed at enrollment based on their address.

Geographic also wins on simplicity. The algorithm is deterministic and explainable: this member lives at this address, the nearest in-network PCP is this provider, attribution is to that provider. Disputes have a clear basis.

Where Claims-Based Wins

Claims-based attribution wins on clinical accuracy. The provider the member actually sees is the provider with the most clinical context for that member. A geographically nearest provider may have never seen the member; a claims-based provider has documented care relationships.

For Provider Access purposes, the clinical accuracy matters because the receiving provider is consuming the data to provide care. A provider who has never seen the member benefits less from the member's claims history than the provider who has been treating them.

The Edge Cases That Break Each Pattern

Geographic attribution breaks for members with unstable addresses (recently moved, multiple residences, snowbirds). It breaks for members whose preferred provider is far from their stated address (a member who travels to a specialist or chooses a provider outside their immediate area). It breaks for members in densely-served areas where many providers are equally near.

Claims-based attribution breaks for members with no recent claims (newly enrolled members, members who do not use care actively, infants). It breaks when the member sees specialists more than primary care (which is common for chronic conditions managed primarily by specialists). It produces shifting attribution as care patterns change.

The Hybrid That Most Production Implementations Use

In practice, most production CMS-0057-F implementations combine the two. Claims-based attribution is primary when sufficient claim history exists. Geographic attribution is the fallback when claims data is unavailable or ambiguous. Member-selected PCP overrides both when present.

The hybrid handles the edge cases of both pure methodologies. The implementation complexity is in the precedence logic: when does claims-based apply, when does geographic kick in, when does member selection override both.

How the Choice Affects Dispute Handling

Provider disputes about attribution happen regardless of methodology. Providers query "why is this member attributed to me" (typically because they want them removed) or "why is this member not attributed to me" (typically because they want them added).

Geographic attribution produces disputes about distance calculations and provider matching. Claims-based attribution produces disputes about look-back window length and the relative weight of visits versus diagnoses. Both methodologies need clear documentation and an appeals process.

The Audit Trail That Survives Regulatory Scrutiny

Whichever methodology the plan uses, the attribution-of-record needs an audit trail. Which methodology was applied, which data points drove the decision, when the assignment was made, when it was last updated. Plans that capture this audit trail systematically defend attribution decisions cleanly. Plans that treat attribution as a derived field without audit trail struggle when disputes arise.

For the broader attribution-of-record pattern catalog beyond just geographic versus claims-based, the Best attribution-of-record patterns for CMS-0057-F Provider Access covers the full set. For the Group resource patterns that hold the attribution output, the Top 6 FHIR Group Resource patterns for provider panel management covers the data layer.

Sources

• CMS-0057-F Final Rule (Provider Access attribution)

— Beatrix Landsberg

The FHIR Bulk Data Access IG (STU 2.0.0 in the version current for 2026) is what Inferno tests against for CMS-0057-F conformance. The IG looks short, but the practical conformance bar covers more than the spec text suggests. Production implementations need to handle several patterns correctly, not just one. Here are seven best practices for Bulk Data and attribution coverage implementations targeting CMS-0057-F.

1. Use the Correct Prefer Header Pattern

The Bulk Data IG requires the client to send Prefer: respond-async on the export request. The server responds with 202 Accepted only if the request had this header. Implementations that respond with 202 without the Prefer header are technically non-conformant, even if the rest of the flow works.

The same applies to the optional Prefer: handling=strict header for error handling preferences. Implementations should respect both when present.

2. Return Conformant 202 Status With Content-Location

The 202 Accepted response must include a Content-Location header pointing to the status URL. The status URL is what the client polls for completion. Some implementations return 202 without Content-Location, expecting the client to know the status URL by convention, which is not conformant.

The status URL should be stable for the duration of the export. Clients that lose the URL cannot recover the export status; they have to start a new export.

3. Handle the Status Endpoint Correctly Across States

The status endpoint has three states: in-progress (202 with optional X-Progress header), failed (4xx or 5xx with an OperationOutcome), and completed (200 with a manifest). Implementations need to handle all three states cleanly.

Common gaps include not implementing the X-Progress header (which is optional but useful), returning generic 5xx errors instead of OperationOutcome for failures, and inconsistent handling of the completed state across different export sizes.

4. Produce Conformant Manifest at Completion

The completion response is a JSON manifest with specific required fields: transactionTime (when the export was initiated), request (the original request URL), requiresAccessToken (true if downloading the NDJSON files needs auth), output (the list of files), and error (the list of error files if any).

Implementations sometimes skip the error array, return non-ISO-8601 timestamps for transactionTime, or use non-standard structures for the output entries. These are conformance bugs that Inferno catches.

5. Output NDJSON, Not Batched JSON

The output files must be NDJSON: one FHIR resource per line, no array brackets, no commas between resources. Implementations that produce arrays of resources (batched JSON) are non-conformant even if consumers can sometimes handle the output.

For deeper coverage of this format-level requirement, the NDJSON Streaming vs Batched JSON for FHIR Bulk Exports comparison covers why the spec specifies NDJSON.

6. Handle the DELETE Operation on the Status URL

The client can DELETE the status URL to cancel an in-progress export. Implementations must support this and clean up any partial output. Implementations that ignore DELETE leak storage and continue exports that the client no longer wants.

The Inferno tests check this pattern. Implementations that pass Inferno on the happy path sometimes fail on the cancellation case.

7. Support the _outputFormat Parameter (Where Relevant)

The export request can specify _outputFormat, with the value typically being NDJSON. Implementations should accept the parameter and return appropriate Content-Type headers on the output files. Skipping the parameter handling is conformant in narrow cases but breaks for clients that rely on it.

How to Test Conformance Beyond Inferno

Inferno is the conformance suite of record for CMS-0057-F, but it does not test everything. Production-grade testing should include realistic-volume exports (100,000+ members, not just the test profiles), realistic data variety (multiple resource types, edge cases in resource content), and operational scenarios (concurrent exports, cancellation mid-export, status URL access after long delays).

For the operational monitoring that catches issues conformance testing misses, the Top 5 tools for monitoring FHIR Bulk Data export health covers the observability side. For the async export patterns that the conformance rules wrap, the Top 5 Async export patterns for FHIR Bulk Data implementations covers the operational layer.

Sources

• FHIR Bulk Data Access IG v2.0.0

— Beatrix Landsberg

The attribution-of-record is the answer to a deceptively complex question: which provider does this member belong to for the purpose of Provider Access data sharing. CMS-0057-F leaves the attribution methodology to the payer, but the payer has to articulate the methodology and apply it consistently. The IG expects attribution exposed through the Group resource. Five attribution-of-record patterns have emerged as defensible in 2026 deployments. For broader context, Bulk Data and attribution coverage covers the surrounding architecture.

1. Member-Selected PCP Attribution

The simplest pattern. The member identified a primary care provider at enrollment (or updated their selection later), and that PCP is the attribution-of-record. The Group resource for each PCP contains the members who selected them.

This pattern works cleanly when the plan structure assumes PCP selection (most HMO plans, many Medicare Advantage plans). It does not work for plans without member-selected PCPs (most PPO plans, traditional Medicare).

2. Claims-Based Attribution With Look-Back Window

The most common pattern when PCP selection is absent. The payer analyzes member claims over a defined look-back window (typically 12 to 24 months) and identifies the provider the member sees most often or most recently for primary care. That provider becomes the attribution-of-record.

The pattern handles plans without explicit PCP selection. The trade-off is that attribution can shift over time as claims patterns change, and providers may dispute attribution when they see a member infrequently or only for specialty care.

3. Geographic Attribution as Fallback

A pattern that attributes members to providers based on geographic proximity when neither member selection nor recent claims provide a clear answer. The member's address is mapped to nearby in-network providers, and one is selected as the attribution-of-record (typically the nearest PCP).

The pattern is a last-resort fallback. Geographic attribution often produces friction because the geographically nearest provider may not be where the member actually receives care.

4. Specialty Carve-Out Attribution

A pattern that handles attribution differently for specialty care than primary care. Behavioral health, oncology, specialty pharmacy, and others may have distinct attribution: the specialty provider is attribution-of-record for the specialty-specific Provider Access requests, while the PCP is attribution-of-record for general Provider Access.

The pattern matters more for plans with carved-out specialty benefits. Implementations that hard-code single-attribution per member break when specialty carve-out arrangements exist.

5. Hierarchical Attribution With Multiple Records

A pattern that supports multiple attribution-of-record assignments per member, each scoped to a clinical context. Primary care attribution to the PCP. Behavioral health attribution to the BH provider. Specialty attribution to the relevant specialist. Provider Access requests are matched to the relevant attribution scope.

This pattern is the most operationally complete and the most implementationally complex. Plans with substantial specialty carve-outs or integrated primary plus behavioral health benefit from this pattern; plans with simpler structures may not need the complexity.

How Attribution Affects the Group Resource

Each attribution-of-record assignment maps to membership in a FHIR Group. A provider's Group resource lists the members attributed to them. Provider Access $export operations against a Group return data for those members.

The Group resource has to stay in sync with the underlying attribution data. Implementations that build Group resources statically and let them drift produce incorrect Provider Access output. Implementations that rebuild Group resources on a regular cadence (or expose attribution as a live query rather than a static resource) stay current.

For the Group resource patterns specifically, the Top 6 FHIR Group Resource patterns for provider panel management covers the implementation patterns.

The Audit Trail That Matters During Disputes

Attribution disputes happen. Providers query "why is this member in my panel" or "why is this member not in my panel." Payers need to answer with the attribution methodology, the data sources, and the timing. A defensible attribution implementation captures the audit trail at the time of each attribution decision: which methodology was applied, which data points drove the decision, and when the assignment was made.

For the comparative question of geographic versus claims-based attribution as the foundational methodology, the Geographic vs Claims-Based Attribution comparison covers the choice in depth.

Sources

• CMS-0057-F Final Rule (Provider Access attribution)

— Beatrix Landsberg

Have you ever wondered why your medical records feel like they’re trapped in the digital dark ages? It’s often because of the way health information is structured, or rather, isn’t structured. But what if I told you there’s a secret weapon that could change everything? Today, I’m diving into the fhir data model, and trust me, it’s more exciting than it sounds. This isn’t just about ones and zeros; it’s about revolutionizing how we access and use health information. Digitize forms to reduce errors, save time, and enhance client experience with fast, reliable digital transformation solutions today.

The fhir data model - What is it and why should you care?

Okay, first things first. What exactly is the fhir data model? In a nutshell, it’s a standardized way of representing health information electronically. Think of it as a universal language for healthcare data. Instead of every hospital and clinic using its own unique system, fhir provides a common framework. Why is this important? Well, imagine trying to assemble furniture when every piece uses a different type of screw and wrench. Frustrating, right? The fhir data model solves this problem by ensuring that all the pieces (medical records, lab results, etc.) fit together seamlessly. This means better interoperability, improved data sharing, and ultimately, better patient care.

“The beauty of fhir,” as Dr. Emily Carter, a leading health informatics expert, once told me, “is its simplicity and flexibility. It’s designed to adapt to the evolving needs of healthcare, not the other way around.”

Unlocking the Power of Interoperability

One of the biggest advantages of the fhir data model is its ability to promote interoperability. This fancy word simply means that different systems can “talk” to each other and exchange information easily. For example, your primary care physician can quickly access your allergy information from a specialist’s office, or a hospital can seamlessly share your medical history with a rehabilitation center. This interoperability can lead to -

1. Reduced medical errors - Having a complete picture of your health history helps prevent doctors from prescribing medications you’re allergic to or ordering unnecessary tests.
2. Improved care coordination - When healthcare providers can easily share information, they can work together more effectively to manage your health.
3. Empowered patients - The fhir data model can enable you to access your own medical records and share them with whomever you choose, putting you in control of your health information.

I remember once, my grandmother had to repeat her entire medical history multiple times to different doctors after she moved. With a properly implemented fhir data model, that wouldn’t have happened.

The fhir Data Models and the Future of Healthcare

So, how will fhir data models shape the future of healthcare? Well, the possibilities are pretty exciting. Imagine -

• Personalized medicine - By integrating data from various sources, including genomic information, the fhir data model can help doctors tailor treatments to your specific needs.
• Remote patient monitoring - Wearable devices and other remote monitoring technologies can seamlessly share data with your healthcare providers, allowing them to track your health and intervene early if necessary.
• Artificial intelligence in healthcare - The fhir data model can provide the standardized data needed to train AI algorithms that can help doctors diagnose diseases, predict patient outcomes, and develop new treatments.

Kinda makes you think, huh?

Challenges and Opportunities

Of course, implementing the fhir data model isn’t without its challenges. It requires investment in new technologies, training for healthcare professionals, and a commitment to data security and privacy. But the potential rewards are enormous. As more and more healthcare organizations adopt the fhir data model, we can expect to see a significant improvement in the quality, efficiency, and accessibility of healthcare.

Final Thoughts

In conclusion, the fhir data model is more than just a technical specification. It’s a game-changer that has the potential to transform the way we approach health information. By promoting interoperability, empowering patients, and enabling innovation, the fhir data model can help us create a healthier future for all. What do you think about the potential of fhir data model? I, for one, am incredibly optimistic about what’s to come. Hopefully, this article has inspired you to learn more and advocate for the adoption of the fhir data model in your own community.

— Beatrix Landsberg

Have you ever felt completely lost in a sea of healthcare data? Like, drowning in a jumble of numbers, codes, and abbreviations that just… don’t make sense? I definitely have. For years, I struggled to make heads or tails of the information I needed. Then I discovered the fhir format, and honestly, it completely changed the game. Today, I want to share my story and how learning about fhir formats not only solved my data struggles but also opened up a whole new world of possibilities. Trust me, it’s more exciting than it sounds!

The Data Jungle — My Initial Struggles

Before fhir, working with healthcare data felt like hacking my way through a dense jungle. Different systems spoke different languages. Sharing information between hospitals, clinics, and even departments within the same organization was a nightmare. I remember one particularly frustrating project where we spent weeks just trying to map data fields between two databases. It was a huge time suck, and honestly, pretty demoralizing. It felt like trying to fit square pegs into round holes, constantly. I was constantly asking myself “Why is this so hard?” and “Isn’t there a better way?”.

Then, I heard whispers about something called fhir.

Discovering the FHIR Format — A Ray of Hope

Someone (I think it was at a conference, or maybe I read it online, I can’t remember exactly) mentioned the “fhir format” as a potential solution. At first, I was skeptical. I’d heard promises before, and they rarely delivered. But the more I looked into it, the more intrigued I became. The basic idea – a standardized way to represent healthcare information using web-friendly technologies – seemed like a breath of fresh air. It felt… modern.

“FHIR is about connecting healthcare data,” as Dr. Emily Carter, a leading expert in health informatics, once said. “It’s about making information accessible and usable, regardless of the system it comes from.”

I decided to dive in.

My FHIR Journey — Learning and Implementing

Here’s how I tackled learning and implementing fhir —

1. Started with the Basics — I spent time reading the official fhir documentation. Yes, it can be a bit dense, but it’s essential to understand the fundamentals.
2. Hands-on Practice — I started experimenting with fhir resources using online tools and sample datasets. This is where things really started to click.
3. Community Engagement — I joined online forums and attended webinars to connect with other fhir developers and learn from their experiences.
4. Small Projects First — I began by implementing fhir in small, targeted projects, such as building a simple patient record viewer.
5. Iterate and Improve — I continuously refined my approach based on feedback and new learnings.

It wasn’t always easy. There were definitely moments of frustration, and a few times I almost gave up. But I persevered, and I’m so glad I did.

The Transformation — From Struggle to Success

Once I started implementing fhir format, things started to change dramatically. Data sharing became much simpler and faster. Interoperability improved significantly. And I could actually understand the data I was working with!

Here are just a few of the benefits I experienced —

• Reduced Development Time — No more endless hours spent mapping data fields.
• Improved Data Quality — Standardized data formats led to fewer errors.
• Enhanced Interoperability — Seamless data exchange between different systems.
• Greater Innovation — Ability to build new applications and services on top of fhir data.

Honestly, it felt like a huge weight had been lifted off my shoulders. I went from struggling to make sense of healthcare data to being able to confidently work with it and leverage it to improve patient care.

So, there you have it. My journey from healthcare data chaos to fhir format clarity. It wasn’t always easy, but it was absolutely worth it. What about you? Have you explored the power of fhir yet? I hope my story inspires you to give it a try. You might be surprised at how much it can transform your own healthcare data journey.

— Beatrix Landsberg