21 Aug
Your pitch deck says “FHIR-native.” Your data model says something else.
That gap is where healthcare AI deals die after the first term sheet conversation. Not because the product doesn’t work. Because the architecture underneath it can’t survive contact with an actual hospital system, and the investor’s technical reviewer found that out in week two.
Healthcare-focused funds stopped taking “we support FHIR” at face value years ago. Too many portfolio companies burned six months discovering their integration plan didn’t match reality. So now, before the check gets written, someone qualified is going to open your API documentation and start asking specific questions. Here’s what they’re actually checking, and where most startups get caught short.
Why FHIR diligence happens before the term sheet, not after
A few years ago, technical diligence on a healthcare AI startup meant checking HIPAA boxes and calling it done. That’s changed.
CMS-0057-F put a hard deadline on payer-to-payer and provider APIs built on FHIR. Every major EHR vendor now requires standards conformance to even open a sandbox. Investors who’ve been burned by a portfolio company stuck in integration purgatory learned the lesson: architecture debt in year one becomes a stalled pilot in year two, and a stalled pilot kills the next round.
So the diligence moved earlier. Funds with healthcare partners now bring in an outside FHIR architect during the second or third meeting, sometimes before a term sheet exists at all. They’re not evaluating your idea anymore. They’re evaluating whether your idea can actually connect to the systems it needs to reach.
That’s a different test, and it catches teams off guard.
US Core conformance: the test most startups fail first
Ask ten healthcare AI founders if their platform is FHIR compliant, and ten will say yes. Ask which US Core profiles they conform to, and the room gets quiet.
US Core is the baseline implementation guide that defines the actual data elements, cardinalities, and terminology bindings a system has to support to call itself conformant. It’s not optional scaffolding. It’s the profile every major EHR and most payers require before they’ll grant API access.
The gap shows up fast in diligence. A reviewer pulls up your CapabilityStatement endpoint, checks it against the US Core Patient, Observation, and Condition profiles, and finds half the required fields missing or loosely typed. That single check tells them more about your engineering discipline than an hour of product demo.
Fix this before the call, not during it:
- Publish a working CapabilityStatement at a public or sandboxed endpoint
- Map every core resource (Patient, Observation, Condition, MedicationRequest) against the current US Core version, not a version from two releases ago
- Document known gaps honestly. A reviewer trusts “we don’t support X yet, here’s the timeline” far more than a vague compliance claim that falls apart under one query.
EHR integration reality: Epic and Cerner don't care about your roadmap
Your roadmap slide says “Epic integration Q3.” The investor’s next question: through App Orchard, through a direct SMART on FHIR app registration, or through a data partner who already has the relationship?
Those are three completely different timelines, and conflating them is one of the fastest ways to lose credibility in a diligence call. Epic’s App Orchard review process alone can run months. Investors who’ve watched a portfolio company underestimate this timeline once will ask pointed questions about which path you’re actually on, not which one sounds good in a deck.
The same applies to Oracle Health (formerly Cerner). Each vendor has its own certification process, its own quirks in how it implements the FHIR spec, and its own patience threshold for startups that show up unprepared. A team that can name the specific program, the specific contact, and the specific milestone they’ve hit signals something a roadmap slide can’t: they’ve actually started.
The Da Vinci question every investor asks now
Ask about prior authorization workflows and watch how fast a founder’s answer reveals whether they’ve read the actual implementation guides or just the press coverage.
The Da Vinci Project’s guides, Coverage Requirements Discovery, Documentation Templates and Rules, Prior Authorization Support, and Clinician Data Exchange, are becoming the shared architecture for how payers and providers exchange authorization and clinical data under the CMS mandate. Investors ask about them even when your product has nothing to do with prior auth, because the answer tells them whether your team builds toward where regulation is heading or waits until it’s forced.
A basic PAS request structure looks like this:
{
"resourceType": "Claim",
"status": "active",
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/claim-type",
"code": "professional"
}]
},
"use": "preauthorization",
"patient": { "reference": "Patient/example" },
"provider": { "reference": "Organization/example" },
"insurance": [{
"sequence": 1,
"focal": true,
"coverage": { "reference": "Coverage/example" }
}]
}
You don’t need to have shipped this. You need to know why it’s structured this way and where your own product’s data would slot into it. That’s the difference between a team that’s studied the standard and one that’s guessing.
Terminology mapping: where the demo breaks in production
Demos run on clean data. Production runs on whatever a hospital’s legacy system has been collecting for fifteen years.
Terminology mapping, matching your internal codes to SNOMED CT for clinical findings, LOINC for lab results, RxNorm for medications, sounds like a back-office detail until it’s the reason your pilot stalls. A reviewer who’s seen this failure before will ask a specific question: how do you handle a lab result coded in a local system with no clean LOINC mapping? If the answer is “we haven’t hit that yet,” that’s an honest answer. If the answer dodges the question, that’s a red flag.
Three things worth having ready:
- A documented terminology service or mapping table, even a partial one
- A clear answer for unmapped or ambiguous codes: does the system flag them, reject them, or guess?
- Evidence you’ve tested against messy real-world data, not just a clean synthetic dataset
TEFCA and QHIN: the network question nobody preps for
Security and provenance: your audit trail is a product feature
HIPAA compliance is table stakes. What separates a pass from a fail in diligence is whether your system can prove, resource by resource, who touched what data and when.
FHIR’s Provenance resource exists for exactly this. Every write to a patient record, every AI-generated recommendation that touches clinical data, should carry a traceable record: source, author, timestamp, method. Investors ask about this not because they distrust your intentions, but because a health system’s compliance team will ask the exact same question before signing a contract, and “we log it in application logs somewhere” isn’t an answer that survives that conversation.
Build the audit trail into the data model from day one. Retrofitting provenance after a pilot is already live is expensive, and it shows in how long that retrofit takes.
Build, buy, or facade: the decision investors actually price
Here’s the question underneath all the others: are you building your FHIR layer from scratch, licensing an interoperability platform, or running a facade in front of legacy systems you don’t control?
Each answer changes the math an investor runs. Build-from-scratch signals control and long-term differentiation, but it also means your burn rate carries the full weight of standards maintenance as the specs evolve. Buy or license speeds up time-to-pilot but raises questions about margin and vendor lock-in down the road. A facade approach, translating HL7 v2 or proprietary formats into FHIR at the edge, often the fastest path to a working demo with a real hospital, but investors will want to know it’s a bridge, not a permanent architecture.
None of these answers is wrong on its own. What matters is whether you’ve made the tradeoff deliberately and can explain why, instead of discovering the decision retroactively when a technical reviewer asks the question directly.
What to fix before your next raise
Most of what gets flagged in FHIR diligence isn’t a fundamental flaw. It’s a gap between what the pitch claims and what the architecture actually does. Close that gap before the call, not during it.
Start with the CapabilityStatement. If you can’t produce one that a reviewer could check against US Core in five minutes, that’s the first thing to fix. Then work outward: EHR integration path, Da Vinci positioning, terminology strategy, network story, provenance model. Each one is a question you will get asked. The startups that raise smoothly are the ones who’ve already answered it in writing before the meeting starts.
If you’re building the FHIR layer itself and want a second set of eyes before your next investor call, that’s worth a conversation before the deck goes out, not after the questions start.
FAQs
Because interoperability gaps are the single biggest reason healthcare AI pilots stall after a term sheet is signed. A weak FHIR layer adds months to EHR integration timelines and creates compliance exposure under CMS-0057-F. Investors run this check early because it forecasts time-to-revenue more reliably than almost any other technical signal in the deal.
US Core is the baseline FHIR implementation guide defining which patient data elements a system must support, and how. Most EHR vendors and payers won't grant API access without US Core conformance. A startup that says "FHIR-native" but can't produce a conformant CapabilityStatement usually fails its first technical diligence call.
Yes. The Da Vinci guides, CRD, DTR, PAS, and CDex, are becoming the standard architecture for payer-provider data exchange under CMS-0057-F. Investors ask about them regardless of your product category because your answer shows whether your team designs around coming regulation or reacts to it after the fact.
A FHIR facade is a translation layer that converts data from a legacy EHR or claims system, often still running HL7 v2, into standards-compliant FHIR resources. No investor requires one specifically. What they do require is a clear answer for how your system connects to hospitals that haven't modernized, since most of the US healthcare system still hasn't.
Two to six weeks is typical once term sheet talks begin, longer if the fund brings in an outside FHIR architect for a deeper review. Startups that keep a current CapabilityStatement, clean API documentation, and sandbox access ready can cut that window significantly.
"FHIR compliant" is an unverifiable marketing phrase. US Core conformant is a specific, testable standard: a reviewer can pull your CapabilityStatement and check it against required resources and fields in minutes. One is a claim. The other is evidence, and evidence is what gets checked in diligence.
ISO 27001:2022 Certified
Aigilx health specializes in developing Interoperability solutions to create a healthcare ecosystem and aids in the delivery of efficient, patient-centric and population-focused healthcare.
