Bottom line. TEFCA can reduce the friction of reaching clinical records across otherwise separate health information networks, but it does not guarantee that a digital health startup has a lawful exchange purpose, complete patient data, reliable identity matching, usable FHIR resources, or durable unit economics. Physician investors should verify the contracting chain to a Qualified Health Information Network, the exact exchange-purpose code, vetting status, record-yield evidence, workflow integration, security controls, and dependency concentration. The investable asset is a governed data operation that converts permitted exchange into better clinical or administrative decisions, not a slide that says nationwide connectivity.[1][2]
Key takeaways
- TEFCA is a nationwide network-of-networks framework. A startup normally reaches it through a QHIN, participant, subparticipant, or other connector rather than by connecting to one federal repository.[1][4]
- Only authorized exchange purposes support a request: Treatment, Payment, Health Care Operations, Public Health, Government Benefits Determination, and Individual Access Services. Product use must map to the right purpose and requirements.[4]
- Treatment and Individual Access Services policies effective August 3, 2026 make today's diligence especially timely for virtual care, value-based care, patient-access, and longitudinal-record companies.[5][7]
- Connectivity is an input, not an outcome. Record discovery, patient matching, completeness, normalization, latency, duplication, and clinical use determine the product's actual value.
- FHIR-based exchange is advancing, while document-based exchange remains relevant. Investors should inspect the production mix rather than accept a generic interoperability label.[3][8]
- QHIN and connector agreements can create flow-down duties, audit exposure, change-management obligations, pricing risk, and termination dependency that belong in valuation and financing models.[2][9]
What TEFCA changes for startup diligence
TEFCA establishes a common policy and technical floor for electronic health information exchange across participating networks. ONC describes it as a path for providers, patients, payers, and public health organizations to share information beyond proprietary boundaries. The QHIN Technical Framework addresses functions such as identity resolution, authentication, directory use, and performance for QHIN-to-QHIN exchange, with some requirements flowing down to participants and subparticipants.[1][3]
For an investor, the important change is architectural. A company may be able to reach a broader set of endpoints through one governed connection instead of negotiating separately with every network. That can compress implementation time and strengthen a longitudinal-data product. It can also move risk into a contractual chain: the startup depends on its upstream connector, the connector depends on a QHIN, and all parties operate under changing common rules and standard operating procedures.[2][4]
Today's policy change expands the treatment diligence question
The Treatment Exchange Purpose Implementation SOP Version 2.0 became effective August 3, 2026. RCE guidance explains that HIPAA covered health care providers can use the TEFCA Required Treatment code after applicable vetting and that providers in value-based arrangements may qualify when a care model establishes clinical accountability through attribution, enrollment, assignment, or a similar mechanism.[4][5][6] This is useful for care-delivery startups, but it is not permission for any analytics vendor to query records because the data might improve care.
Ask management to identify the legal entity acting as the health care provider, the patient relationship or accountability mechanism, the exchange-purpose code asserted, who approved vetting, and when its directory entry became usable. Match that evidence to representative production transactions. If a business depends on a customer's treatment purpose, distinguish the startup's role as a business associate or service provider from the customer's authority to initiate the exchange.[5][6][10]
Individual access is a product line with identity obligations
The updated Individual Access Services SOP defines requirements for a company that has a direct contractual relationship with an individual to help that person access, inspect, obtain, or transmit required information. Its controls include approved identity-proofing services, at least Identity Assurance Level 2 proofing, at least Authenticator Assurance Level 2 authentication, and demographic matching steps.[7] These are product, fraud, support, conversion, and cost inputs - not background compliance details.
A patient-access startup should therefore report proofing pass rates, abandonment, manual-review volume, false-match and no-match rates, support cost, purge events, and record yield by demographic subgroup. Strong aggregate retrieval can conceal worse performance for people with name changes, unstable addresses, incomplete demographic histories, or records distributed across many systems. Physician advisors can test whether the resulting chart is clinically coherent rather than merely large.
Map the business model to its TEFCA proof burden
| Startup position | Evidence to request | Common diligence trap |
|---|---|---|
| Virtual or value-based care provider | Provider status, clinical-accountability mechanism, purpose code, vetting approval, directory entry, matched-record yield, workflow use, and care impact. | A broad treatment claim substitutes for evidence that the specific entity and patient cohort qualify. |
| Patient-access application | Direct patient terms, identity vendor, IAL2 and AAL2 controls, consent, match performance, error correction, support burden, and transmission controls. | Downloaded document count is called engagement while proofing abandonment and wrong-patient risk are omitted. |
| Data aggregation or normalization vendor | Upstream agreements, permitted role, document and FHIR mix, provenance, deduplication, terminology mapping, latency, uptime, and customer acceptance tests. | Nationwide access is marketed even though useful data depend on one connector or a narrow set of sources. |
| Workflow, decision-support, or research platform | Downstream use, minimum data set, missingness logic, source traceability, human review, clinical validation, purpose limitations, and deletion rules. | Better connectivity is treated as proof that the downstream recommendation or research dataset is valid. |
Measure the data product before valuing the network claim
A useful diligence metric is not connected lives. Start with eligible requests and build a waterfall: correctly formed request, successful patient discovery, returned response, correct match, non-duplicate content, required field availability, timely arrival, successful normalization, delivery to workflow, clinician or patient use, and measurable downstream effect. Report the waterfall by exchange purpose, customer, QHIN route, source organization, transaction type, and subgroup.
Complete does not mean clinically sufficient
Required information is constrained by what a responding node maintains and by the applicable TEFCA rules. A returned longitudinal document may still omit the recent external image, precise medication status, scanned note, device stream, or context necessary for a decision. Conversely, a large record can overwhelm the user with duplicates and stale entries. Test common clinical questions against time-stamped source records and score whether the product delivers the minimum information needed for its claimed workflow.[3][4]
Document exchange and FHIR solve different parts of the problem
ONC reported in 2025 that TEFCA participants could engage in document-based query and FHIR-based query through trusted APIs.[8] FHIR can support more discrete, application-friendly exchange, but its presence does not eliminate variation in endpoint behavior, supported resources, coding, or data quality. Documents may offer richer narrative at the cost of parsing and duplication. Require transaction-level evidence showing what is live today, what is piloted, and what remains on a roadmap.
The physician investor's eight-part TEFCA diligence framework
1. Trace the contracting and technical chain
Draw the chain from the startup's legal entity through every upstream participant or subparticipant to the designated QHIN. Collect executed agreements, incorporated policies, service descriptions, amendments, fees, audit rights, data-use restrictions, subcontractor terms, insurance obligations, suspension rights, and termination assistance. Confirm which systems are listed as nodes and who owns each production endpoint. A logo on a partner page is not a connection record.
2. Validate the exchange purpose transaction by transaction
Create a matrix of product feature, initiating entity, patient or member relationship, exchange-purpose code, legal basis, required vetting, response expectation, data retained, and downstream use. Sample production logs against that matrix. A company may support several permitted use cases, but each needs its own operational logic; a treatment purpose should not silently become a general prospecting, model-training, or commercial-data purpose.[2][4][5]
3. Stress-test identity and record reconciliation
Review identity proofing, authentication, demographics, enterprise master-patient-index logic, confidence thresholds, manual review, and correction workflows. Construct synthetic and consented test cases involving common names, twins, recent moves, name changes, missing middle names, and fragmented care. Measure false positives, false negatives, duplicates, merges, unmerges, and time to correction. Wrong-patient data create more risk than an empty response because the output can look authoritative.
4. Inspect provenance, normalization, and clinical usability
Trace representative allergies, medications, diagnoses, laboratory results, procedures, and notes from source through transport, parsing, terminology mapping, deduplication, display, and export. Preserve source, author, timestamp, status, and transformation history. Ask clinicians to perform real tasks using the output, then compare accuracy and time with the existing workflow. A normalized table that loses uncertainty or provenance can make a product faster and less safe.
5. Reconcile security duties across the chain
HIPAA status depends on the parties and functions: covered entities and business associates have direct obligations, including written business-associate arrangements where applicable.[10] TEFCA adds contractual and incident-reporting duties. The security-incident SOP requires participants and subparticipants to report suspected or actual TEFCA security incidents upstream within defined timelines and to notify likely affected downstream entities.[9] Test whether the incident plan can identify TEFCA information, reach the correct parties, and preserve other legal reporting workflows.
6. Quantify connector and policy concentration
Model the effect of an upstream outage, price increase, policy amendment, directory error, suspension, or termination. Review whether the startup can use another QHIN path, whether customer contracts promise more than upstream agreements provide, and how long migration would take.
7. Prove the downstream clinical or economic outcome
Separate exchange performance from product effectiveness. For a care company, test whether retrieved data change medication reconciliation, duplicate testing, risk adjustment, outreach, admission follow-up, or adverse-event detection. For an infrastructure vendor, measure implementation time, manual records work avoided, query cost, user adoption, and renewal. Use comparison groups or phased deployments when feasible; a before-and-after improvement can reflect customer selection, staffing, or concurrent workflow changes.
8. Convert evidence into revenue quality and valuation
Build gross margin from successful usable outputs, not queries sent. Include upstream transaction or subscription fees, identity proofing, cloud processing, terminology services, manual review, customer support, security, implementation, clinical oversight, and failed-request expense. Discount revenue that depends on a purpose interpretation, a single upstream route, unpaid pilots, roadmap FHIR functionality, or weak customer adoption. Reward repeatable implementation and audited record yield rather than theoretical reach.
Investment committee scorecard
| Dimension | Investment-grade evidence | Reserve or term response |
|---|---|---|
| Authority and participation | Executed chain, correct purpose, completed vetting, current node or directory evidence, and transaction logs align. | Condition funding on missing approvals; reserve revenue tied to unresolved use cases. |
| Data performance | Cohort-level match, response, completeness, latency, deduplication, and usability metrics reconcile to source samples. | Tie valuation credit to verified usable-record yield and customer acceptance. |
| Operations and security | Documented controls, tested incident escalation, provenance, correction, monitoring, and credible staffing capacity. | Require remediation milestones, insurance review, and board reporting for material gaps. |
| Economics and resilience | Positive contribution margin on used outputs, renewable customer contracts, and a tested upstream-continuity plan. | Apply concentration discounts and finance migration, pricing, and policy downside cases. |
Red flags that should change price or terms
- Management cannot name the initiating legal entity, upstream connector, QHIN, node, exchange-purpose code, or current vetting status.
- The company equates access to a network with complete nationwide records but provides no eligible-request or usable-record waterfall.
- A treatment rationale is used for a non-provider entity or a patient population without documented clinical accountability.
- Patient-access growth projections exclude identity-proofing failure, demographic mismatch, manual review, support, and erroneous-data correction.
- FHIR appears in the pitch, but production evidence consists only of documents or a limited pilot with no customer acceptance criteria.
- Data transformations discard source, author, status, time, or uncertainty, making reconciliation and clinical review difficult.
- The incident plan follows HIPAA only and does not map TEFCA upstream, downstream, and contractual reporting duties.
- One connector controls most record yield while contracts permit rapid repricing, suspension, or termination without practical transition support.
Frequently asked questions
What is TEFCA in plain English?
TEFCA is a nationwide policy and technical framework that connects qualified health information networks so participating organizations can exchange electronic health information across network boundaries for authorized purposes. It is a network of networks, not a single federal database or a universal data license.
Does joining a QHIN guarantee a startup complete clinical records?
No. Participation creates a governed route for permitted exchange, but record yield still depends on the exchange purpose, responding obligations, source participation, patient matching, data maintained by each source, query implementation, and workflow. Investors should measure usable record yield rather than rely on a connectivity claim.
Can a value-based care startup use TEFCA for treatment queries?
Potentially. The Treatment SOP effective August 3, 2026 includes circumstances in which a HIPAA covered health care provider has clinical accountability through attribution, enrollment, assignment, or a similar care model. The entity still must satisfy the applicable purpose, vetting, directory, contract, and legal requirements.
Is TEFCA exchange the same as a FHIR API product?
No. TEFCA supports governed exchange through technical patterns that include document-based exchange and facilitated FHIR. A startup must show which transaction path is live, what data arrive, how they are normalized, and whether the production workflow depends on documents, discrete FHIR resources, or both.
What is the most important TEFCA diligence metric?
Use a cohort-level usable-record yield: the percentage of eligible requests that produce correctly matched, timely, non-duplicative, clinically relevant information that reaches the intended workflow. Break it down by customer, QHIN path, exchange purpose, source, and patient subgroup.
Conclusion
TEFCA can be a meaningful infrastructure advantage for digital health companies that need longitudinal information across organizational boundaries. Its value is earned downstream: the right entity asserts the right purpose, identity is resolved safely, relevant information returns, provenance survives transformation, the output changes a workflow, and the unit economics hold after network and support costs. Physician investors can test this chain with clinical specificity. Credit verified usable-record yield, resilient contracts, and measurable workflow outcomes; reserve for ambiguous authority, incomplete records, matching failures, connector concentration, and roadmap functionality. Nationwide exchange is a capability. A durable business must prove what it accomplishes with it.
References
- Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology. Advancing Nationwide Interoperability with TEFCA, updated June 9, 2026. Accessed August 3, 2026. https://healthit.gov/policy/tefca/
- ONC TEFCA Recognized Coordinating Entity. Common Agreement resources, current as of August 3, 2026. Accessed August 3, 2026. https://rce.sequoiaproject.org/common-agreement/
- Office of the National Coordinator for Health Information Technology. Qualified Health Information Network Technical Framework, Version 2.0. Accessed August 3, 2026. https://healthit.gov/wp-content/uploads/2025/06/QTF-v2_508.pdf
- ONC TEFCA Recognized Coordinating Entity. Frequently Asked Questions, current as of August 3, 2026. Accessed August 3, 2026. https://rce.sequoiaproject.org/rce/faqs/
- ONC TEFCA Recognized Coordinating Entity. Exchange Purpose Implementation: Treatment Standard Operating Procedure, Version 2.0, effective August 3, 2026. Accessed August 3, 2026. https://rce.sequoiaproject.org/wp-content/uploads/2026/07/Treatment-XP-SOP-v2.0_7.1.2026_508.pdf
- ONC TEFCA Recognized Coordinating Entity. Exchange Purpose Vetting Process Standard Operating Procedure, Version 2.0, effective August 3, 2026. Accessed August 3, 2026. https://rce.sequoiaproject.org/wp-content/uploads/2026/07/XP-Vetting-Process-v2.0_7.1.2026_508.pdf
- ONC TEFCA Recognized Coordinating Entity. Individual Access Services Exchange Purpose Implementation Standard Operating Procedure, Version 3.0, effective August 3, 2026. Accessed August 3, 2026. https://rce.sequoiaproject.org/wp-content/uploads/2026/07/SOP-IAS-XP-v3_June2026_Clean_-5081.pdf
- Office of the National Coordinator for Health Information Technology. TEFCA Priorities and Plans for the Remainder of 2025, July 7, 2025. Accessed August 3, 2026. https://healthit.gov/blog/tefca/tefca-priorities-and-plans-for-the-remainder-of-2025/
- ONC TEFCA Recognized Coordinating Entity. TEFCA Security Incident Reporting Standard Operating Procedure, Version 1.0, July 1, 2024. Accessed August 3, 2026. https://rce.sequoiaproject.org/wp-content/uploads/2024/07/SOP-TSI-Reporting-v1-508.pdf
- U.S. Department of Health and Human Services, Office for Civil Rights. Covered Entities and Business Associates, current as of August 3, 2026. Accessed August 3, 2026. https://www.hhs.gov/hipaa/for-professionals/covered-entities/index.html
Editorial disclaimer: This article is for educational purposes only and does not constitute medical, legal, tax, accounting, privacy, cybersecurity, regulatory, reimbursement, or investment advice. TEFCA documents, exchange requirements, technical specifications, contracts, and applicable law are fact-specific and can change. Readers should consult qualified professionals and verify current primary sources before acting.