Top 5 EHR Integration Patterns for Patient Access API Consumers
When a payer's Patient Access API exposes member data, the consumers fall into three categories. Members using third-party apps (the original CMS-9115-F use case). Other payers receiving data under Payer-to-Payer Data Exchange. Providers' EHRs consuming the member's shared history. The EHR-side consumption is the integration most often underestimated, because Patient Access is usually discussed as a member-facing feature. Five integration patterns have emerged for EHRs consuming Patient Access in 2026. For the EHR-payer integration hub on this site, these are the practical paths.
1. Member-Initiated Pull Through SMART App Launch
The pattern that fits CMS-0057-F naturally. The member shares their Patient Access credentials or authorizes a SMART app inside the provider's EHR to pull their prior payer history. The EHR launches the SMART app, the app calls the prior payer's Patient Access API, and the data flows into the EHR's clinical view.
The pattern preserves member consent (the member initiates the share) and works with existing SMART App Launch infrastructure most major EHRs already support. The trade-off is the member friction; some members skip the share, leaving the EHR without the prior history.
2. Standing Authorization for Network Plans
A pattern that emerges in narrow-network plans where the EHR has standing authorization to query the payer's Patient Access API for any member of the plan. The pattern works when the member's enrollment in the plan implicitly authorizes the EHR-payer data exchange for clinical purposes.
The legal and consent framework for this is delicate; not all plans support it, and member-rights considerations vary by state. Where it works, the friction reduction for providers is significant.
3. EHR-Mediated Member Verification With Pull
A pattern that splits the share into two steps. The provider's EHR collects member verification (insurance card, member ID, demographic data) at intake. The EHR uses this verification to call the prior payer's Patient Access API, with member acknowledgment captured at the intake desk rather than through a separate SMART app launch.
The pattern works for providers with structured intake processes. It pushes some of the authentication complexity to the EHR's intake workflow rather than asking the member to launch a separate app.
4. Care-Coordination Pull Through Provider Access API
A pattern that uses the Provider Access API (rather than Patient Access) for the EHR-side pull. When the EHR is consuming data for a provider who is in-network with the payer, the Provider Access API is the appropriate channel and does not require per-request member consent.
The pattern fits provider organizations whose EHRs handle in-network member care. The complexity shifts to attribution: the Provider Access API requires the payer to know which members the requesting provider is attributed to.
5. Hybrid Pattern Combining Multiple Access Methods
A pattern that combines all of the above into one cohesive EHR workflow. Member-initiated share covers easy cases. Standing authorization covers narrow-network in-plan situations. Provider Access covers attribution-aware in-network cases. The EHR's data layer normalizes data from all sources into the clinical view.
This hybrid is operationally complex but provides the most complete data picture. Larger EHR deployments and integrated health systems with substantial payer-provider relationships tend toward this pattern.
How to Pick the Pattern for Your Provider Network
The pattern choice depends on the provider's relationship with the payer, the EHR's technical capability, and the member-experience priorities. Provider organizations with narrow-network relationships and integrated payer infrastructure use Patterns 2 and 4. Provider organizations with diverse payer relationships use Pattern 1 (Member-Initiated). Highly integrated health systems use the hybrid.
The patterns are not mutually exclusive. A typical health system uses Pattern 1 for out-of-network member care, Pattern 4 for in-network attributed members, and falls back to Pattern 3 for ambiguous cases.
For the synchronous notification side of EHR-payer interaction that complements these pull patterns, the CDS Hooks vs FHIR Subscriptions comparison covers the notification layer. For Epic-specific integration patterns within these flows, the Best practices for Epic integration with payer FHIR APIs covers the platform-specific guidance.
Sources
Top 5 Bulk Data Export Optimizations for Provider Access at Scale
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
Top 5 Async Export Patterns for FHIR Bulk Data Implementations
FHIR Bulk Data Access is built on the async pattern: the client requests an export, the server returns 202 Accepted with a status URL, and the client polls or subscribes for completion. The pattern is straightforward in spec but has multiple implementation variants in practice. The choice of async pattern affects consumer experience, server load, and operational reliability. Here are five patterns worth knowing for the FHIR Bulk Data knowledge base on this site.
1. Polling With Adaptive Backoff
The most common pattern. The client polls the status URL on a defined cadence. Initial polls happen frequently (every 30 seconds for the first few minutes), then back off exponentially as the export takes longer (every minute, every 5 minutes). The server returns Content-Length-Free 202 responses until the export completes, then returns 200 with the manifest.
This pattern is simple and conformant. The trade-off is the polling overhead, especially for long-running exports where the client polls many times before completion.
2. Long-Polling With Server-Side Hold
A variation where the client polls but the server holds the request open until either the export completes or a timeout is reached. The client receives the completion notification immediately when it happens (within the timeout), rather than waiting for the next polling cycle.
This pattern reduces the latency between completion and client notification at the cost of server-side connection management. Not all Bulk Data implementations support it; the standard Bulk Data IG specifies polling rather than long-polling.
3. Webhook-Based Completion Notification
A pattern where the client registers a webhook URL during the export request, and the server calls the webhook when the export completes. The client does not poll at all; it waits for the webhook.
This pattern is the most efficient for client-side resource usage. The trade-off is the webhook infrastructure complexity: the client has to expose a public HTTPS endpoint, handle authentication for incoming webhook calls, and deal with retry logic if the webhook delivery fails. The Bulk Data IG does not standardize this pattern; implementations that support it use vendor-specific extensions.
4. FHIR Subscriptions for Bulk Data Status
A pattern that uses FHIR Subscriptions (R4 channel-based or R5 topic-based) to deliver Bulk Data status updates. The client subscribes to status changes for a specific export job, and the server delivers Subscription notifications when the status changes.
This pattern fits FHIR-native architectures cleanly. The Subscription engine is reused for other use cases (PA decision notification, Provider Directory change alerts), so adding Bulk Data status notification through Subscriptions does not add new infrastructure.
5. Pre-Generated Snapshot With Direct Download
A pattern that pre-computes regularly scheduled exports and provides direct download links rather than requiring on-demand export requests. The server runs nightly or weekly exports for known consumer-Group pairs and exposes the resulting NDJSON files at predictable URLs.
This pattern shifts the async work entirely to the server side. Consumers download the latest available export rather than waiting for one to complete. The trade-off is freshness: pre-generated exports are by definition somewhat stale compared with on-demand exports. For some use cases (analytics, batch ingestion) the staleness is acceptable; for others it is not.
How the Patterns Combine in Production
Production CMS-0057-F deployments typically support multiple patterns. Polling with adaptive backoff is the baseline because it is conformant and works with any client. Webhook-based notification is offered for consumers who want it. Pre-generated snapshots cover high-volume routine use cases where freshness can be slightly relaxed.
FHIR Subscriptions for Bulk Data status is the emerging pattern for FHIR-native client architectures. It is not yet common in 2026 but is expected to grow as Subscription-based architectures mature.
How the Async Pattern Affects Consumer Performance
The async pattern is not just an implementation detail. Consumer-side performance depends on how quickly the consumer learns the export is complete and begins ingestion. A polling consumer with a 5-minute interval loses up to 5 minutes between completion and ingestion start. A webhook or Subscription consumer loses almost no time. For high-volume CMS-0057-F workflows where many exports happen per hour, the cumulative delta matters.
For the optimization techniques that make the export side fast regardless of which async pattern wraps it, the Top 5 Bulk Data export optimizations for Provider Access at scale covers the engineering layer. For monitoring async export health in production, the Top 5 tools for monitoring FHIR Bulk Data export health covers the observability layer.
Sources
The Complete Guide to Payer-to-Payer Data Exchange for CMS-0057-F
Payer-to-Payer Data Exchange is the most technically complex of the four CMS-0057-F APIs and the one with the fewest production deployments going into 2026. The flow looks straightforward in the IG: when a member switches health plans, the receiving payer requests a five-year history from the prior payer, the member opts in, the data transfers as FHIR Bundles, and the receiving payer ingests it. In practice, every step has operational depth that surfaces during real deployment. This guide lays out what Payer-to-Payer actually requires for the 5-year history reference on this site.
What the IG Actually Requires
CMS-0057-F requires that when a member enrolls in a new health plan, the new plan must request the member's five-year clinical and claims history from the prior plan if the member opts in. The transfer happens within one business day of the formal request. The data set excludes denied PAs and cost-sharing detail. Concurrent coverage adds quarterly sharing rules. The member must be educated about the option during enrollment.
The transport layer uses FHIR Bulk Data Access for the export, FHIR Member Match for identity confirmation, and FHIR Consent for the opt-in record. The conformance bar is set by HL7 PDex IG, CARIN BB IG, and FHIR Bulk Data Access IG together.
The Member Match Problem at the Center
Member Match is the gate that determines whether the transfer happens at all. The receiving payer sends a Patient and Coverage Bundle representing the member, and the prior payer's Member Match implementation has to confirm identity. A miss returns no data. A false positive returns another patient's history, which is a privacy incident.
The honest assessment is that Member Match accuracy varies widely across vendors. Most implementations support both deterministic matching (exact identifiers, name, DOB) and probabilistic matching with confidence scoring. The threshold for what counts as a match is configurable, and the tuning has operational consequences.
For deeper coverage of matching strategies, the Top 5 Member Match strategies for Payer-to-Payer lays out the options.
The Five-Year History That Most Plans Cannot Produce Cleanly
The five-year history requirement assumes the prior payer has the data, in FHIR-compatible form, retrievable for a single member, exportable as a clean FHIR Bundle. Most US health plans have the data, but not all of those conditions. Claims data may live in X12, not FHIR. Clinical data may live in claims-attached documents that have not been parsed into FHIR resources. Five years of history may span multiple internal systems that the payer has not unified.
Plans that can produce the five-year history cleanly are the exception in 2026. Plans that cannot have to choose between producing partial history (and risking CMS audit) or investing in data integration before the transfer flow is operational.
For practical patterns that work in production, the Best practices for 5-year history transfer covers the deployments that have shipped.
The Member Opt-In Flow That Sits in the Member Portal
CMS-0057-F requires the receiving payer to capture member opt-in for the transfer. The opt-in flow typically lives in the member portal during enrollment, with educational materials explaining what data will transfer and what the member is consenting to. Payers that treat this as a checkbox tend to have low opt-in rates and weak audit trails. Payers that treat it as a designed flow have higher opt-in rates and cleaner audit positions.
The educational materials require coordination across the payer's legal, marketing, and member-experience teams. Most plans underestimate this work during vendor selection.
The Transport Question: Direct API or TEFCA
Two transport models are emerging in 2026. The direct API model has receiving and prior payers running paired FHIR endpoints with point-to-point authentication. The TEFCA model uses a Qualified Health Information Network (QHIN) as the intermediary, with each payer connecting to TEFCA rather than to each other directly.
The direct API model gives payers more control. The TEFCA model reduces per-payer engagement work substantially.
For the deeper comparison, the TEFCA vs Direct API for Payer-to-Payer transfer covers which fits where. Most large-scale 2026 deployments are choosing a hybrid: TEFCA for the network discovery and authentication, direct API for the actual data transfer.
Sources
The Complete Guide to FHIR Bulk Data and Attribution for CMS-0057-F
FHIR Bulk Data Access is the transport layer underneath two of the four CMS-0057-F APIs. Provider Access uses it to deliver in-network provider panels. Payer-to-Payer Data Exchange uses it to transfer five-year member histories. The Bulk Data spec is conceptually simple: an async export that produces NDJSON files containing FHIR resources, with a manifest listing the files and a content-location header for polling. The implementation reality is far more complex than the spec suggests. This guide lays out what production-grade Bulk Data and attribution actually require for deeper Bulk Data engineering coverage on this site.
What FHIR Bulk Data Access Actually Does
A FHIR Bulk Data export starts with a request to the server's $export operation (system-level, group-level, or patient-level depending on scope). The server returns a 202 Accepted with a Content-Location header pointing to the status endpoint. The client polls the status endpoint until the export completes. The completed response is a manifest listing the NDJSON file URLs, each containing the exported FHIR resources of a specific type.
The pattern is async on purpose. Exports for realistic CMS-0057-F workloads (a 100,000-member provider panel, a 500,000-resource member history) cannot complete synchronously within HTTP timeout windows.
The Attribution Problem at the Center of Provider Access
Provider Access uses group-level Bulk Data export, where the Group resource represents a provider's attributed member panel. The server has to know which members are attributed to which provider, and the attribution model has to be exposed through the Group resource.
Most US payers have multiple attribution methodologies running in parallel: geographic (PCP nearest to the member's address), claims-based (PCP the member uses most), panel-assigned (member chose the PCP at enrollment), capitated (member is paying a capitated arrangement to a specific provider group). Production-grade Bulk Data implementations expose attribution as configurable rather than hard-coded.
For deeper coverage of the attribution patterns, the Best attribution-of-record patterns for CMS-0057-F Provider Access covers the field.
The NDJSON Output That Makes or Breaks the Consumer Experience
The export delivers data as NDJSON: newline-delimited JSON, one FHIR resource per line, files grouped by resource type. NDJSON makes streaming consumption efficient because the consumer can process line by line without loading the entire file.
The format is simple but the implementation has variability. Some exporters chunk files at fixed byte boundaries. Some chunk at resource-count boundaries. Some produce one massive file per resource type. The chunking strategy affects consumer-side memory usage, parallelism, and download resumability.
For the format-level comparison of NDJSON streaming versus batched JSON approaches, the NDJSON Streaming vs Batched JSON for FHIR Bulk Exports comparison covers the trade-offs.
The Performance Bar That Defines "Production-Grade"
A useful performance benchmark for CMS-0057-F-grade Bulk Data is: a 100,000-member group-level export with five years of history per member should complete in under 30 minutes and produce clean NDJSON output that consumers can ingest without error.
Implementations that miss this bar are not yet production-ready for the volume CMS-0057-F is going to drive after January 2027. Implementations that hit it cleanly typically have invested in async export tooling, parallel resource serialization, and snapshot consistency.
For the specific optimizations that make this performance achievable, the Top 5 Bulk Data export optimizations for Provider Access at scale covers the engineering patterns.
The Consumer-Side Pieces That Most Documentation Ignores
The exporter is half the story. The consumer (typically an EHR consuming Provider Access, another payer consuming Payer-to-Payer) has to fetch the NDJSON files, parse them, deduplicate against existing data, and integrate the resources into their data model. Consumer-side performance under realistic load is its own engineering problem, distinct from the exporter side.
Consumer-side issues that surface in production: NDJSON parsing errors on edge cases, memory pressure from large files, slow ingestion that bottlenecks the data pipeline, and reconciliation problems when the same resource arrives in multiple Bulk Data deliveries over time.
How This All Fits the CMS-0057-F Picture
Bulk Data is the technical foundation under two of the four CMS-0057-F APIs. Provider Access and Payer-to-Payer both depend on it being fast, reliable, and correct. The attribution layer determines who can request what data. The NDJSON output determines whether consumers can actually use the data efficiently.
Plans that invest in production-grade Bulk Data infrastructure ahead of the deadline avoid most of the surprises that catch other plans during the post-2027 traffic ramp. Plans that treat Bulk Data as a checkbox often discover the gaps when the volume arrives.
Sources
The Complete Guide to EHR Integration with Payer FHIR APIs in 2026
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
TEFCA vs Direct API for Payer-to-Payer Transfer: Which Wins
The transport architecture for CMS-0057-F Payer-to-Payer Data Exchange has two emerging models in 2026. The direct API model has each pair of payers running paired FHIR endpoints with bilateral authentication. The TEFCA model uses a Qualified Health Information Network (QHIN) as the intermediary. Both are conformant under CMS-0057-F; the choice has different implications for engineering work, operational cost, and network effects. This comparison lays out the trade-offs for related provider-side ePA guides on this site.
What Direct API Actually Means
In the direct API model, the receiving payer's platform connects directly to the prior payer's platform. Authentication is bilateral (typically OAuth 2.0 with payer-specific client credentials). The Member Match operation runs against the prior payer's endpoint. The Bulk Data export executes between the two platforms. The audit log lives at both ends.
For each pair of payers that exchange data, this setup has to be built. A plan with 50 partner relationships has 50 bilateral connections to maintain.
What TEFCA Means
In the TEFCA model, the receiving payer connects to a QHIN. The QHIN handles network identity, authentication, routing, and often Member Match coordination across the network. The prior payer is also a QHIN participant. The data flow happens between the two payers but mediated by the network's infrastructure.
For each new payer that joins the network, the existing participants gain a new available counterparty without per-relationship engineering work.
Where Direct API Wins
Direct API wins on three dimensions. First, control: the payer has full visibility into every step of the transfer, with no third-party in the data path. Second, latency: point-to-point transfers can be faster than network-mediated transfers because there is one fewer hop. Third, commercial simplicity: no QHIN subscription, no network transaction fees.
For payers with concentrated transfer volume to a small number of counterparties, direct API often makes economic sense. A payer with 80 percent of its transfer volume going to three specific counterparties does not benefit much from network access to dozens of other payers.
Where TEFCA Wins
TEFCA wins on coverage and engineering efficiency. The receiving payer connects once to the QHIN and gains access to all participating payers. For a payer expecting transfers from many smaller partners (Medicare Advantage plans receiving members from various employer plans, for example), the per-relationship engineering work without TEFCA becomes prohibitive.
TEFCA also wins on network identity. The QHIN handles the cryptographic infrastructure for authenticating which payer is requesting data, which is harder to operate well in a bilateral model with dozens of counterparties.
The Performance Question
Latency differences are real but small in 2026 deployments. A direct API transfer typically completes in seconds for Member Match, minutes for Bulk Data export of a five-year history. A TEFCA-mediated transfer adds maybe 100 to 500 milliseconds to Member Match and similar overhead to Bulk Data, depending on the QHIN.
For the one-business-day SLA, neither pattern is constrained by latency. The bottleneck is more often the prior payer's data layer or the receiving payer's ingestion logic.
The Operational Reality
In practice, most large-scale 2026 deployments are picking a hybrid. The QHIN handles network identity, authentication, and member-discovery (which prior payer to query for a given member). The actual data transfer happens point-to-point between the two payers, with the QHIN handling only the discovery layer.
This hybrid gives most of the engineering efficiency benefit of TEFCA without ceding full control of the data flow to the network. It is also the pattern that the major QHINs are increasingly supporting as default.
The Decision Rubric
The decision usually comes down to expected transfer volume distribution. Plans with concentrated volume to a few counterparties default to direct API for the highest-volume relationships and may add TEFCA as a fallback for long-tail transfers. Plans with diffuse volume across many counterparties default to TEFCA with direct API for any specific high-volume relationships where the payer wants more control.
For the specific TEFCA-integrated solutions worth evaluating, the Best TEFCA-integrated Payer-to-Payer solutions in 2026 covers the leading vendors. For the Member Match strategies that work in either model, the Top 5 Member Match strategies covers the algorithmic layer.
Sources
Standalone SMART vs EHR Launch for Da Vinci DTR Workflows
SMART App Launch defines two launch patterns. Standalone Launch starts the app outside any EHR context, typically from a web link. The user authenticates, picks a patient, and the app runs. EHR Launch starts the app from within the EHR, with the EHR providing Patient, Encounter, and other context. For Da Vinci DTR workflows, both patterns are technically conformant. The choice has substantial consequences for clinician adoption and the experience of completing a PA inside the provider workflow. This comparison lays out the trade-offs for the inter-payer transfer reference on this site.
What Each Launch Pattern Actually Does
Standalone Launch is essentially a web-app pattern. The user navigates to the DTR app URL (often from a CRD card with a launch link, or directly from a bookmark). The app prompts for authentication, the user logs in with payer-issued credentials, the app prompts the user to identify the patient, and the user then completes the questionnaire. The app runs in its own browser tab or window separate from the EHR.
EHR Launch starts the app inside the EHR. The EHR provides authentication tokens via SMART OAuth, passes Patient and Encounter context, and embeds the app in an EHR-controlled view. The clinician sees the DTR form without leaving the patient chart and the app already knows which patient is being treated.
Where EHR Launch Wins
EHR Launch wins on clinician experience. The clinician does not authenticate separately, does not pick the patient (the EHR already knows), does not switch context to a separate window, and sees the DTR form as part of the clinical workflow. Pre-population from EHR context works because the context is already provided.
EHR Launch also wins on adoption. Workflow integration that respects the clinician's existing pattern gets used. Workflow integration that requires context-switching gets bypassed in favor of legacy submission channels (phone, fax) regardless of how technically capable the DTR app is.
Where Standalone Launch Wins
Standalone Launch wins in narrow circumstances. Care management staff who handle PAs outside the clinician's direct workflow can use a standalone DTR app. Specialty providers whose EHR does not support SMART EHR Launch (or supports it poorly) can use standalone as a fallback. Initial pilot rollouts before the EHR-specific work is complete can use standalone for testing.
Standalone Launch is also the only path when the workflow originator is not in an EHR. For example, an automated batch submission tool processing accumulated PA requests overnight does not have an EHR launch context; it operates standalone.
The Adoption Gap That Matters Operationally
The data from production DTR deployments in 2025 and early 2026 shows a wide adoption gap. EHR-launched DTR apps see provider completion rates of 60 to 85 percent (depending on workflow design and EHR-specific quirks). Standalone-launched DTR apps see completion rates of 20 to 40 percent for clinician-facing cases, with the rest falling back to legacy submission.
The gap is not about technical quality. It is about whether the workflow asks the clinician to do additional work (find the standalone link, authenticate, pick the patient) or fits into work the clinician is already doing.
When Standalone is Actually the Right Choice
For care-management workflows (not clinician-facing), standalone is sometimes the right pattern. The care management team is processing PAs as their primary work; the standalone DTR app is the right tool for that work. They do not need EHR launch context because they are not embedded in EHR workflow.
For batch-style PA processing where multiple submissions are completed in sequence outside any single clinical encounter, standalone fits the work pattern better than EHR Launch (which would require launching from a specific patient context for each PA).
The Hybrid Pattern That Works Best in Production
Most production DTR deployments support both launch patterns. EHR Launch handles the clinician-facing case where it is supported by the target EHR. Standalone Launch handles care-management workflow, EHR-without-SMART-support fallback, and edge cases. The DTR app code is mostly shared; the difference is in the launch sequence.
For the broader catalog of DTR SMART app design patterns that work well in production, the Best DTR SMART app patterns for provider workflows covers the field-tested designs. For the broader workflow anti-patterns to avoid, the 5 EHR workflow anti-patterns that break Da Vinci PA adoption covers the failure modes.
Sources
NDJSON Streaming vs Batched JSON for FHIR Bulk Exports
The FHIR Bulk Data IG specifies NDJSON as the output format, but the implementation patterns vary. Pure NDJSON streaming produces a continuous newline-delimited file of resources. Batched JSON wraps batches of resources in JSON arrays, which is technically not NDJSON but appears in some implementations as a deviation. Each approach has consequences for consumer-side performance, memory usage, and error handling. For deeper Bulk Data engineering coverage on this site, this is the format-level decision.
What Each Format Actually Looks Like
NDJSON is a sequence of FHIR resources, one per line, each line being a complete JSON object representing one resource. There are no array brackets, no commas between resources, and no top-level object wrapping the file. A consumer reads one line at a time, parses it as JSON, and processes the resource.
Batched JSON wraps groups of resources in JSON arrays. A file might contain a top-level array of 1000 resources, then another array of 1000 resources, then another. Some implementations use one big array per file. Some use chunked arrays separated by newlines (which is closer to NDJSON but with each line being an array rather than a single resource).
Why NDJSON Wins For Streaming Consumption
NDJSON allows true streaming consumption. The consumer can process resources one at a time, in constant memory regardless of file size. A 10 GB NDJSON file processes in the same memory footprint as a 1 MB NDJSON file because the consumer only holds one resource at a time.
Batched JSON requires the consumer to either load entire batches into memory (which scales poorly for large files) or implement a custom streaming JSON parser (which is harder than line-based NDJSON parsing).
For CMS-0057-F workloads where Bulk Data files routinely run hundreds of MB to several GB, NDJSON's memory efficiency matters substantially.
Why Some Implementations Use Batched JSON Anyway
Batched JSON appears in implementations that were not built for streaming consumption from the start. Existing tooling that produces standard JSON output naturally produces arrays of resources rather than line-delimited individual resources.
Some implementations use batched JSON because the developers misread the spec or treated NDJSON as an aesthetic preference rather than a structural requirement. These implementations are technically non-conformant with the Bulk Data IG, even though consumers can sometimes handle the output if they implement custom parsing.
The Error-Handling Asymmetry
NDJSON has a useful error-handling property: a malformed line affects only that line. A consumer encountering a parsing error on one line can log the error and continue processing subsequent lines. The blast radius of a malformed resource is one resource.
Batched JSON has the opposite property. A malformed resource in the middle of an array can break parsing for the entire array. The blast radius of a malformed resource extends to all resources in the same batch.
For production reliability at scale, the NDJSON error-handling property matters. Real FHIR data sometimes contains edge cases that produce serialization errors; NDJSON limits the impact.
What the IG Actually Requires
The FHIR Bulk Data Access IG (STU 2.0.0 is the version current in 2026) specifies NDJSON as the output format. Implementations that produce batched JSON are non-conformant. Inferno tests for Bulk Data conformance check for NDJSON output specifically.
Payers selecting a Bulk Data implementation should verify NDJSON conformance during evaluation. Asking the vendor for a sample output file and checking that each line parses as an independent JSON object is the simplest test.
How the Implementation Choice Affects Vendor Selection
Most production-grade Bulk Data implementations in 2026 produce conformant NDJSON. The vendors that ship batched JSON tend to be older implementations or implementations that started outside the FHIR ecosystem and were retrofitted for Bulk Data.
A useful evaluation question is to ask the vendor specifically for an NDJSON sample (not a Postman collection, not a documentation example, an actual sample file from a recent export). Vendors with strong implementations produce this readily; vendors with weaker implementations sometimes need additional time to produce a real sample, which is an indicator.
For the broader Bulk Data IG conformance check that goes beyond just the output format, the Best practices for FHIR Bulk Data IG conformance in 2026 covers the full picture. For the export optimization techniques that work with NDJSON output, the Top 5 Bulk Data export optimizations for Provider Access at scale covers the engineering side.
Sources
Geographic vs Claims-Based Attribution: Which Fits Provider Access
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.