The expansion of artificial intelligence within healthcare creates a data architecture problem that is different from traditional analytics. Health systems have historically built data pipelines for reporting, research, interoperability, and operational applications. AI uses many of the same data sources, but the way the data is consumed varies considerably depending on whether the system is being trained, evaluated, or used for inference.
Training requires relatively large datasets that represent the population and workflows in which the model will operate. This is not limited to the original development of the model. Models must also be evaluated against local populations, monitored for changes in performance, updated as clinical practice changes, and reassessed as the underlying data changes. As a result, a health system needs a repeatable mechanism for providing historical and incremental data rather than treating model training as a one-time extraction project.
Inference creates a different requirement. Most production AI systems do not need millions of records to make an individual prediction. They generally need a bounded set of information associated with a patient, encounter, claim, appointment, imaging study, or operational process. The challenge is usually not volume. It is ensuring that the information is sufficiently current for the workflow.
These two requirements overlap, but they are not identical. A data source that is appropriate for training may be too delayed for operational inference. Conversely, an API that works well for retrieving current information about an individual patient may be a poor mechanism for transferring several years of clinical history for model evaluation.
Health systems therefore need to consider both requirements when designing the data architecture supporting AI.
Enterprise data platforms
One approach is to use the health system's enterprise data platform as the primary source for AI.
In this model, data from the EHR and other operational systems is moved into an enterprise warehouse, lakehouse, or similar environment. This may be Snowflake, Databricks, Microsoft Fabric, or another technology. Data is then transformed from source-oriented structures into curated datasets intended for consumption.
The specific implementation pattern is less important than the separation between source data and consumable data. An AI developer generally should not need to understand thousands of EHR tables, local category values, source-specific identifiers, or the historical decisions that produced a health system's reporting architecture. Those concerns can be handled upstream and exposed to the AI workload through a more stable representation.
This approach is particularly effective for training and evaluation. Large historical datasets can be made available without repeatedly extracting the same information from transactional systems. New data can be incorporated over time, allowing models to be reevaluated against changes in patient population, clinical practice, documentation, or other factors that may contribute to drift.
It also gives the health system greater control over the data. Rather than building a new copy of the source data for each model vendor, the organization can determine what information is available, how it has been transformed, and which workloads are permitted to consume it. Modern data platforms can extend this approach through secure data sharing and other mechanisms that reduce or eliminate unnecessary copies.
The limitation is freshness.
Many healthcare analytical environments were not designed to represent operational state in real time. Epic Clarity is a common example. Many Clarity environments are refreshed on a scheduled basis, frequently overnight. This is generally acceptable for training, retrospective evaluation, population analysis, and many administrative use cases. It is not sufficient for an AI system that needs to know what happened several minutes ago.
This is not necessarily a limitation of the enterprise data platform itself. If data enters the platform through change data capture, streaming, APIs, or another low-latency mechanism, curated data can also be made available relatively quickly. The limitation is therefore determined by the complete pipeline from the originating system through the point of consumption.
Point interfaces
A second strategy is to connect AI applications directly to the systems that contain the required data.
This is currently one of the most common approaches because it follows an integration model that healthcare already understands. HL7 v2 can provide clinical and administrative events. FHIR can provide structured clinical data through APIs. DICOM and DICOMweb support medical imaging. C-CDA supports the exchange of clinical documents. Proprietary APIs and database interfaces fill many of the remaining gaps.
There are practical advantages to this approach. The standards and integration technologies are mature, health systems already operate the required infrastructure, and there is a substantial workforce familiar with implementing these interfaces.
For a limited number of AI products, point integration is often reasonable.
The difficulty appears as the number of products increases.
Interoperability formats are designed primarily to exchange information between systems. That does not mean they are the ideal representation for every downstream use of the information. FHIR resources are useful for exchanging clinical information, but retrieving a large longitudinal dataset through conventional FHIR APIs is considerably different from querying a curated analytical dataset. HL7 v2 messages are effective at communicating that something occurred, but a stream of messages is not itself a reconstructed representation of the current state of a patient.
Training usually requires the receiving application to transform these interfaces into another representation before they can be efficiently consumed. Historical loading must also be solved separately because an event interface generally begins providing information from the time it is activated.
There are operational consequences as well. APIs may impose rate limits. Interfaces need monitoring and reconciliation. Data can be copied into vendor environments. Local codes and identities require interpretation. The AI vendor or health system eventually develops transformation logic that is specific to the application.
None of these issues makes point integration inappropriate. The concern is repetition. If every AI application independently solves extraction, transformation, identity, terminology, data quality, historical loading, and incremental processing, the integration burden increases with each additional application.
Vendor-managed data copies
A related model is to provide each AI vendor with a copy of the data it requires.
This can be implemented through database extracts, files, SFTP, object storage, or scheduled data transfers. It is often an expedient way to begin an AI implementation because much of the transformation responsibility moves to the vendor.
The tradeoff is that each vendor begins maintaining its own representation of health system data.
This creates additional stores of sensitive information that require access control, retention policies, monitoring, security review, and reconciliation. It can also create semantic differences between applications. Two vendors may receive the same source data but interpret encounters, departments, providers, diagnoses, or other concepts differently.
The problem is therefore larger than duplicated storage. Transformation and interpretation are also duplicated.
This may be acceptable when an application is highly specialized or isolated from other enterprise AI workloads. It becomes increasingly difficult to manage when it becomes the default architecture for a large AI portfolio.
Data sharing and federation
Data sharing provides an alternative to repeatedly transferring datasets.
Modern platforms increasingly allow organizations to grant controlled access to data without creating another conventional copy. Snowflake data sharing, Delta Sharing, federated queries, governed views, and related technologies can all support variations of this model.
These approaches are particularly useful for training, backtesting, model evaluation, and other workloads that need access to large datasets.
They can also improve governance because the health system maintains greater control over the authoritative representation of its information. Changes to the underlying governed dataset can become available to consumers without producing and distributing another extract.
Data sharing does not, however, eliminate the other requirements of an AI data architecture. A shared dataset still requires defined semantics, identity resolution, quality controls, appropriate freshness, and version management. It also does not inherently provide an event indicating that an important change just occurred.
Federation primarily addresses how information is accessed. It does not replace integration, transformation, or event processing.
An integrated data and AI platform
A more scalable architecture combines the enterprise data platform with the integration capabilities required for operational AI.
Source systems continue to communicate through the mechanisms appropriate to them. Some information may arrive through database extracts or cloud data sharing. Other sources may use HL7, FHIR, DICOM, files, change data capture, APIs, or event streams.
Those different interfaces feed a common processing layer that transforms source-specific information into governed representations suitable for downstream consumption.
The resulting platform can then expose the data differently based on the workload.
Training and evaluation workloads can consume large datasets through bulk access, data sharing, or direct analytical queries. Incremental processing can continuously add new information so that models can be reevaluated and monitored over time.
Inference can use a different access path. An application may retrieve the current context required for a specific patient or workflow without moving a large dataset. Where latency requirements are more stringent, events can indicate that relevant state has changed and trigger the appropriate processing.
This allows the architecture to separate the representation of data from the mechanism used to move it.
An admission may arrive through an HL7 ADT message. Historical encounters may initially arrive through a database load. Additional information could be retrieved through FHIR. The AI application does not necessarily need to know which mechanism provided each piece of information. It needs a consistent representation of the encounter and sufficient information about its provenance and freshness to use it appropriately.
This becomes particularly important when multiple AI applications use the same information.
Patient identity should not be solved independently by every model. Neither should provider identity, terminology normalization, encounter interpretation, data-quality handling, or the definition of common operational events. These are reusable data capabilities.
The same principle applies to latency. Not all healthcare data needs to be available in real time. Attempting to stream every source would add considerable infrastructure and operational complexity without creating equivalent value. A nightly update may be entirely appropriate for one use case, while another requires changes within seconds.
The architecture should support different patterns rather than force all information through a single transport.
Designing for the next fifty AI applications
Point interfaces have supported healthcare interoperability for decades and will continue to be necessary. The problem is not the existence of point interfaces. It is using them as the primary abstraction between every AI application and every source system.
That approach becomes difficult as the AI portfolio grows.
A health system with a few models can tolerate application-specific integration. A health system operating dozens of AI products may have hundreds of relationships between models, source systems, data stores, interfaces, and workflows. Each new application can introduce additional extraction logic, transformations, security controls, monitoring, and copies of information.
At that point, the integration architecture becomes a limiting factor in AI adoption.
A more sustainable approach is to treat data ingestion, transformation, semantics, identity, quality, and change processing as shared capabilities. AI workloads can then consume that information through the mechanism appropriate to their purpose.
Training requires large, repeatable, continuously updated datasets. Inference requires current and appropriately scoped context. Event-driven workflows may require notification when that context changes.
Those are different consumption patterns, but they do not require separate data foundations.
The practical measure of an AI data architecture is: “what has to be rebuilt when the next application arrives”. An architecture intended to support AI at enterprise scale should reduce that work with each successive implementation rather than reproduce it.
.png)
.png)
.png)
