A patient arrives in your emergency department at two in the morning, transferred from a hospital ninety miles away after a fall. She is confused, cannot give a reliable history, and her family is still driving in. Somewhere in another health system's record is the fact that would change everything you are about to do: the anticoagulant she takes, the allergy that rules out your first-line plan, the baseline that tells you her confusion is new. Whether that fact reaches your screen in the next ten minutes, in a structured form your systems and any AI tool can actually read, or whether it arrives hours later as a faxed page in a pile, is not a clinical question. It is an interoperability question, and it was decided long before this patient fell, by the data standards and exchange rules the country and your organization did or did not adopt. This lesson is about that invisible substrate, because it turns out that what your AI can safely do next is decided less by the cleverness of any model than by whether the data it needs can move, in a form it can understand, when it is needed.

Interoperability Is the Substrate of Enterprise AI

Interoperability is the ability of different information systems to exchange data and, crucially, to use it: not just to move a document from one system to another, but to move it in a structured, standardized form that the receiving system can read, file, and compute on. The distinction matters enormously for AI. A scanned PDF of an outside record is technically "exchanged," but to a model it is close to useless: the medication is a picture of text, the allergy is buried in prose, the lab value is trapped in an image. Structured, standardized data is the opposite: the medication is a coded entry a model can match against the current order, the allergy is a discrete field a decision-support tool can check, the lab value is a number with a known unit and reference range. AI does not run on documents. It runs on data, and interoperability is what determines whether the data exists in a form the AI can use at all.

This is why interoperability is not a plumbing detail to delegate and forget; it is the substrate on which the entire enterprise AI ambition rests. Every advanced use a health system hopes AI will unlock, a longitudinal risk model that sees the whole patient, a decision-support tool that reconciles medications across settings, an ambient system that pulls the relevant history into a note, depends on data that is complete, standardized, and exchangeable. Fragmented or non-standard data does not merely limit these tools; it endangers them, because a model fed a partial or inconsistent picture produces confident conclusions from an incomplete foundation, which is exactly the failure mode this program returns to again and again. A health system that has not solved interoperability has not built the ground its AI will stand on, no matter how many models it licenses. The models are the visible ambition. Interoperability is the invisible substrate that decides whether the ambition is safe or reckless.

It helps to be concrete about what "structured and standardized" actually buys you at the level of a single data point. Consider a potassium result. In a fax or a scanned discharge summary, that value is a smudge of ink inside an image: a model cannot reliably read it, cannot know its unit, cannot tell whether 5.9 is a fresh critical value or a three-week-old result, and cannot compare it to the patient's baseline. Now consider the same value delivered as a structured Observation: it carries a code that says exactly which test it is, a numeric value, an explicit unit (mmol/L), a reference range, and a timestamp. Only in the second form can an AI tool do anything trustworthy with it, such as recognize it as newly critical, correlate it with the patient's ACE inhibitor, and surface it to the clinician. The difference between those two representations of the identical clinical fact is the entire difference between data an AI can safely use and data it can only misread. Multiply that single value across every medication, allergy, problem, and result in a record, and you have the reason interoperability is not a nicety but the precondition for safe computation.

There is a discipline that follows directly from this, and it is the iron rule of the entire program applied to data: verify, do not repeat blindly. A vendor telling you their tool "integrates with your EHR" is making a claim about a connection, not a claim about whether the specific elements your clinical use depends on actually arrive structured, coded, complete, and current. The connection can be real and the data still useless, if what flows through it is a bundle of scanned attachments or free-text blobs. So the leader's job is not to accept the integration story but to verify the substrate underneath it: which elements, in what form, from which sources, arriving how fast. That verification, unglamorous as it is, is where the safety of every downstream AI output is actually decided.

AI does not run on documents; it runs on data. Interoperability is what decides whether the data your AI needs exists in a form it can actually use, and it was decided long before the model arrived.

USCDI: The Baseline Vocabulary Everyone Must Speak

If interoperability is the goal, standards are how it is achieved, and the foundational US standard is USCDI, the United States Core Data for Interoperability. USCDI is a standardized set of health data classes and data elements, a defined common vocabulary, that certified health IT must be able to exchange. Think of it as the agreed baseline list of what a patient's record must be able to say in a form everyone can read: demographics, problems, medications, allergies, lab results, clinical notes, and a growing set of other elements, each defined so that "penicillin allergy" or "hemoglobin A1c" means the same structured thing whether it originated in your EHR or a system across the state. USCDI is versioned and expands over time, and the ONC HTI-1 rule set USCDI version 3 as the baseline that certified health IT had to support by January 1, 2026. That date matters: it means the floor for what standardized data your certified systems can exchange rose, and the elements in USCDI v3 are, in effect, the vocabulary your interoperable AI can most reliably assume is present.

The strategic point for a health-system leader is that USCDI defines the reliable raw material for AI. If a data element is in USCDI and your systems are certified to the current version, you can reasonably build an AI workflow that depends on that element being present and standardized across the settings you exchange with. If an element is not yet in USCDI, or your systems lag the required version, then any AI that depends on it is building on sand, because the data may be absent, unstructured, or inconsistent at the boundaries between systems. Tracking USCDI, which version your systems support and which elements you rely on, is therefore not a compliance chore for the IT department; it is a direct input to what AI your organization can responsibly attempt. The version of a data standard sets the ceiling on the AI you can safely build, which is not an obvious sentence until you have watched a promising AI project stall because the data it needed was never standardized in the first place.

There is a second strategic use of USCDI that leaders often miss: it is a roadmap, not just a floor. USCDI expands over time, adding new data classes and elements with each version, and each expansion quietly enlarges the set of AI workflows an organization can reliably support. An element that was free text or absent in one version, and therefore off-limits as a dependable AI input, may become a defined, standardized element in the next, at which point AI that depends on it moves from building on sand to building on rock. A leader who tracks the trajectory of USCDI is effectively reading a roadmap of which AI ambitions are about to become feasible and which remain premature. This is a far more disciplined way to plan an AI portfolio than chasing whichever model demos best, because it ties the ambition to the one thing that actually determines whether the ambition can be met safely: whether the data it needs is defined and standardized across the settings the patient moves through.

A Mini Worked Example: When the Version Is the Ceiling

Picture a quality team that wants to deploy an AI tool to flag patients whose social circumstances put them at risk of readmission: unstable housing, food insecurity, lack of transportation. The tool is impressive in the demo. But the demo ran on a curated dataset where those social factors were cleanly coded. In your organization, that information lives, if it exists at all, as a sentence a social worker typed into a free-text note. The AI cannot reliably find it, cannot standardize it, and cannot compare it across patients. The gating question is not "is the model good" but "are these elements defined and captured in a standardized form our systems support." If the relevant social determinants data classes are present in the USCDI version your certified systems support, and you are actually capturing them as coded elements, the tool has real ground to stand on. If they are not, the tool will quietly underperform for exactly the underserved patients it was meant to help, because the substrate never carried the signal. Same tool, and the version of the standard, plus whether you capture to it, decides whether it is safe to trust. That is what it means to say the version of a data standard sets the ceiling on the AI you can safely build.

FHIR: The Modern Conduit for the Data

If USCDI is the vocabulary, FHIR is the modern grammar and conduit that carries it. FHIR, Fast Healthcare Interoperability Resources, is a standard for structuring and exchanging healthcare data through modern web technology, breaking the record into discrete, addressable "resources" such as a Patient, a MedicationRequest, an Observation, or an AllergyIntolerance, each retrievable through a standard interface. Its significance for AI is practical and large: FHIR is how a modern AI application actually reaches into the record to get the specific, structured data it needs, rather than parsing a whole document dump. An AI tool that wants the patient's current medication list can request the MedicationRequest resources; one that needs the latest potassium can request the relevant Observation. Because the HTI-1 era pushed standardized FHIR-based access forward, including standardized API access to USCDI data, the conduit for AI to reach clean, structured, current clinical data has matured, which is a large part of why the current wave of clinical AI is possible at all.

It is worth being precise about the relationship, because leaders conflate these terms and then cannot reason about them. USCDI is what data (the standardized elements), FHIR is how it moves and is addressed (the resources and the API), and interoperability is the resulting capability (the data can be exchanged and used). An organization can have FHIR interfaces and still lack real interoperability if the data flowing through them is incomplete or non-standard, and it can name USCDI elements it does not actually capture cleanly. The three have to be true together: the elements defined (USCDI), the conduit in place (FHIR), and the data actually flowing in usable form (interoperability achieved). AI depends on all three holding at once, which is why a leader has to understand them as a stack, not as interchangeable buzzwords.

The table below lays the three side by side so you can hold them apart in your head and ask the right question of each layer. Notice that a failure in any one row is enough to leave an AI tool reasoning over a hole in the record, and that no amount of strength in the other rows compensates.

Read the table as a diagnostic rather than a glossary. When an AI initiative is proposed, walk down the rows and ask, for the specific elements this tool depends on: are they defined and captured to the standard (USCDI), are they exposed as clean resources through the API (FHIR), and do they arrive complete and current from every setting the patient moves through (exchange)? A yes on all three is what "interoperability achieved" means for that tool. Any no is a blind spot you are about to hand a model that will not tell you the blind spot exists.

TEFCA and the National Exchange Layer

Standards let two systems that connect speak the same language, but a health system also needs to reach the many systems it has no direct connection to, the outside hospital, the specialist across the state, the urgent care the patient visited on vacation. That is the exchange layer, and its national expression is TEFCA, the Trusted Exchange Framework and Common Agreement, which establishes a common set of rules and a network-of-networks so that participating organizations can exchange data across the country under one trust framework rather than negotiating thousands of point-to-point connections. For AI, the exchange layer determines completeness, and completeness is a safety property. A longitudinal model or a medication-reconciliation tool that sees only the data generated inside your own walls is working from a partial record, and a partial record is precisely how an AI tool arrives at a confident, wrong conclusion, missing the outside anticoagulant, the specialist's diagnosis, the discontinued drug. The broader and more reliable the exchange, the more complete the picture the AI reasons over, and the less likely it is to be blindsided by the fact that lived in another system.

It is worth noting that exchange is not only about breadth but about reliability and timeliness, both of which are safety-relevant for AI. A network that technically connects to thousands of organizations but delivers outside records slowly, incompletely, or in a form that lands as an unstructured attachment gives the AI little it can actually use at the moment of decision. For a medication-reconciliation tool on admission, data that arrives structured within minutes is worth far more than a complete record that arrives as a PDF two hours after the first orders are placed. A leader evaluating readiness for a given AI use should therefore ask not only whether the organization can reach outside data, but whether it can reach it fast enough, structured enough, and reliably enough for the specific clinical moment the AI is meant to support. The right question is never simply "are we connected," but "for this AI task, does the data arrive in time, in structure, and in full."

The through-line across USCDI, FHIR, and TEFCA is that they are not separate IT initiatives competing for budget with the AI program; they are the AI program's foundation, the layers that decide whether the data an AI needs is defined, reachable, and complete. A health-system leader who treats interoperability as a cost center to minimize while pouring resources into models has the priorities inverted. The models are only as good as the data they can reach, in the form they can use, across the settings the patient actually moved through. Fragmentation at any layer, missing standard elements, immature APIs, or a narrow exchange footprint, propagates directly into the AI as blind spots and errors. Interoperability is where a leader decides, years in advance and mostly invisibly, what their AI will and will not be able to safely do.

Transparency You Can Now Demand: Source Attributes for Predictive Tools

There is a second reason this substrate story matters right now, and it connects interoperability to the transparency requirements that arrived with the same regulatory wave. Under the ONC HTI-1 rule, certified health IT carrying predictive decision-support interventions (the category regulators call predictive DSI, the AI and machine-learning risk tools) must expose a defined set of source attributes: a nutrition-label-style set of facts about the intervention, including what data it was developed and validated on, the populations involved, and how it should and should not be used. This is not a courtesy. It is a transparency obligation you, as a care-delivery professional, can now demand to see before you trust a tool's output on a patient. And it connects straight to interoperability, because the honest answer to "what data does this tool need, and does that data reliably reach it in your setting" is exactly the substrate question this lesson is built on. A predictive tool validated on a population whose data was rich and standardized may quietly degrade in your setting if the same elements arrive sparse, unstructured, or missing from outside sources. The source attributes tell you what the tool assumes; interoperability tells you whether your reality matches those assumptions. Reading one without the other is how a tool that is safe on paper becomes unsafe at the bedside.

The practical move is to hold the two together. When a vendor or an internal team proposes a predictive tool, ask to see the source attributes, then ask the interoperability questions the attributes imply: the tool assumes it will have the outside medication list, so does exchange actually deliver that list, structured, in time? The tool was validated where problems were coded to a standard, so are we capturing problems to that same standard, or are ours buried in free text? This is verification, not repetition. The tool's documentation is a claim; your substrate is the reality; and only checking one against the other lets you say, defensibly, that the tool is safe to run here.

An AI-Readiness Checklist for a Single Use Case

Because the question "are we ready to deploy this AI safely" is too big to answer in the abstract, answer it one use case at a time, against the data the specific tool depends on. The following checklist turns the stack into questions a clinical or informatics leader can actually walk through before signing off. If any answer is no, you have not found a reason to abandon the tool, but you have found a blind spot to close, scope around, or disclose before the tool touches a patient.

1. Elements: Which specific data elements does this tool depend on to produce a safe output, and are they defined in the USCDI version our certified systems support?
2. Capture: Are we actually capturing those elements as coded, structured data, or do they currently live as free text, scanned images, or gaps in the record?
3. Conduit: Are those elements exposed as clean FHIR resources the tool can retrieve through a standard API, rather than requiring the tool to parse whole documents?
4. Reach: For a patient who was seen elsewhere, does our exchange footprint actually deliver those elements from the outside settings that matter for this use?
5. Timeliness and structure: Do the elements arrive fast enough and structured enough for the clinical moment the tool supports, or do they land late or as unreadable attachments?
6. Transparency: Have we reviewed the tool's source attributes, and does our data reality match the populations and inputs the tool was validated on?
7. Failure visibility: When a needed element is missing, does the tool signal the gap, or does it return the same fluent, confident output as when the record is complete?
8. Human accountability: Is there a clear point where a clinician verifies the output against the record, and does the workflow make it easy to document why they agreed or disagreed?

A tool that passes every line is one you can deploy with the substrate genuinely under it. A tool that fails a line can still be deployed, but only with the failure named and managed: scoped to the population where the data is complete, paired with a manual check that fills the gap, or disclosed to the clinician as a known limitation. What you must never do is deploy across a failed line while pretending the substrate holds, because that is precisely how a confidently blind tool reaches the bedside looking exactly like a safe one.

Why Fragmentation Is a Safety Problem, Not Just an Efficiency One

It is tempting to file interoperability under efficiency: better exchange means less faxing, less re-entry, fewer phone calls chasing records. All of that is true, and all of it undersells the stakes once AI enters the picture. When a human clinician works from a fragmented record, they usually know it is fragmented. They see the gaps, they know the outside records have not arrived, and they compensate by asking, calling, and holding their conclusions loosely until the picture fills in. An AI tool does not do this on its own. It reasons over the data it is given as if that data were the world, and it presents its output with the same fluent confidence whether the record is complete or full of holes. This is the crucial asymmetry: fragmentation degrades human judgment visibly and AI judgment invisibly. The clinician knows what they do not know; the model does not know what it was never given, and it will not tell you that its clean-looking answer rests on a record missing half the patient.

That asymmetry is why fragmented or non-standard data does not merely slow AI down but actively endangers patients through it. An efficiency problem makes you wait; a safety problem lets a confident, wrong output reach the point of care looking exactly like a correct one. The medication-reconciliation tool that never saw the outside anticoagulant does not return a warning that its data may be incomplete. It returns a clean reconciliation, and a busy clinician under time pressure, primed by automation bias, may accept it. The failure did not announce itself as a data problem, which is precisely what makes it dangerous. Interoperability is therefore not an operational nicety the AI program can inherit later; it is a patient-safety control, and a health system that scales AI on a fragmented foundation is scaling the reach of exactly this invisible failure.

The asymmetry compounds in a way worth naming explicitly, because it is where scale turns a data problem into a systemic safety problem. When you deploy a tool broadly, you are not deploying its correct answers broadly; you are deploying its behavior on whatever data actually reaches it, which is to say you are deploying its blind spots at the same scale as its insights. If the substrate is thin for one patient population (say, the transferred and traveling patients whose records live elsewhere, or the underserved patients whose social and outside-care data was never coded), the tool will be quietly least reliable for exactly those patients, and it will be least reliable everywhere they present, all at once. Fragmentation does not distribute its harm evenly or randomly; it concentrates it on the patients whose data was already hardest to gather, which are frequently the patients already least well served. A leader who scales an AI tool without first verifying the substrate for the hardest cases is not being efficient. They are industrializing a blind spot and pointing it at the people who can least afford it.

This is also where the iron rule earns its keep at the level of policy rather than a single note. "Verify, do not repeat blindly" is easy to say about one AI output a clinician reads. At the enterprise level, it means something more demanding: do not repeat the vendor's readiness claim, the demo's clean performance, or the assumption that "we have modern systems, so the data must be fine." Verify the substrate for the specific tool and the specific patients, and keep verifying it, because standards versions change, exchange partners come and go, and an integration that carried structured data last year can silently degrade to attachments after a system upgrade on either side. Interoperability is not a box you check once. It is a safety property you monitor, exactly as you would monitor any other control that stands between a confident wrong answer and a patient.

A Worked Example: The Same Model, Two Data Foundations

Return to the confused patient from the opening. Imagine a medication-reconciliation AI meant to catch dangerous interactions and duplications on admission. In the first health system, interoperability is thin: the outside hospital's records arrive as a faxed PDF, the system's certified software lags a USCDI version, its FHIR interfaces are partial, and it participates in no broad exchange network. The AI reconciles medications using only what is structured in its own EHR. It does not see the anticoagulant prescribed at the transferring hospital, because that data sat in an image no model could read, and it confidently reports a clean reconciliation. The tool is not malfunctioning. It answered correctly given the data it could reach, and the data it could reach was dangerously incomplete because interoperability was never solved. The blind spot is not in the model; it is in the substrate.

In the second health system, the substrate holds. Certified software supports the current USCDI baseline, FHIR APIs expose the medication and allergy resources cleanly, and participation in a national exchange framework means the transferring hospital's structured medication list flows in within minutes. The same reconciliation AI now reasons over a complete, standardized picture: it sees the outside anticoagulant, flags the interaction with the drug the ED is about to give, and surfaces the allergy that rules out the first-line plan. A clinician verifies the flag, adjusts the plan, and documents the decision. Same patient, same model, opposite outcome, and the difference is entirely the data foundation the AI stood on. This is the lesson's core claim made concrete: interoperability is not a precondition you can defer until after the AI is chosen. It is the substrate that decides whether the AI is a safety tool or a confidently blind one, and building it is one of the highest-leverage, least glamorous investments a health-system leader can make in the safety of everything the organization will ever ask AI to do.

Key Takeaways

• Interoperability, the ability to exchange data and actually use it in structured, standardized form, is the invisible substrate that decides what enterprise AI can safely do, because AI runs on data, not on documents.
• A scanned PDF is technically exchanged but useless to a model; structured, standardized data (coded medications, discrete allergies, numeric labs) is what an AI tool can read, check, and compute on.
• USCDI (US Core Data for Interoperability) is the baseline standardized vocabulary certified health IT must exchange; ONC HTI-1 set USCDI v3 as the baseline by January 1, 2026, and USCDI defines the reliable raw material for AI.
• The version of a data standard sets the ceiling on the AI you can safely build: if an element is in USCDI and your systems meet the current version, you can depend on it; if not, any AI relying on it builds on sand.
• FHIR is the modern conduit that carries the data as discrete, addressable resources (Patient, MedicationRequest, Observation, AllergyIntolerance) through a standard API, which is how a modern AI application actually reaches clean structured data.
• Understand the stack, not the buzzwords: USCDI is what data, FHIR is how it moves and is addressed, and interoperability is the resulting capability, and AI depends on all three holding at once.
• TEFCA and the exchange layer determine completeness, which is a safety property: a model that sees only your own walls reasons over a partial record and reaches confident, wrong conclusions by missing the outside fact.
• Interoperability is not a cost center competing with the AI program; it is the AI program's foundation, and fragmentation at any layer propagates directly into the AI as blind spots and errors.