US health payers are increasingly building AI and ML models for member outreach prioritization, prior auth automation, fraud detection, and care management. The training data for these models has historically come from claims warehouses with custom feature engineering. FHIR data stores provide a more structured alternative that maps cleanly to ML feature representations. Six patterns dominate FHIR-based ML training data preparation in 2026. For more on healthcare AI infrastructure coverage, these are the practical patterns.
1. Patient Timeline Construction
The most foundational pattern. The training data set represents each patient as a chronological sequence of events: encounters, observations, conditions, medications, procedures. The FHIR resources (Patient, Encounter, Observation, Condition, MedicationStatement, Procedure) construct the timeline; the model consumes the sequence.
The pattern fits many payer ML applications: predicting future utilization, identifying members at risk for chronic disease progression, scoring care management priority. The timeline construction is straightforward when the data is in FHIR.
2. Resource-Type Feature Encoding
A pattern where each FHIR resource type produces specific feature representations for ML. Conditions become indicator features (member has condition X = 1, else 0). Observations become value features (most recent A1c = 7.2). Procedures become count features (number of office visits in last year). The ML feature matrix is built by mapping FHIR resources to these encoded features.
The pattern handles tabular ML well. The feature engineering work is in the encoding logic (how to handle missing data, value ranges, time windowing).
3. Embedding-Based Representation for Deep Learning
A pattern that uses neural embeddings to represent FHIR resources as dense vectors. Each Condition code maps to a vector. Each medication maps to a vector. Each observation pattern maps to a vector. The model consumes embeddings rather than raw codes.
The pattern fits deep learning approaches (transformer models, recurrent networks) that benefit from dense representations. The embedding layer is typically trained on broad clinical data and reused across specific tasks.
4. Privacy-Preserving Synthetic Data Generation
A pattern for cases where training data privacy is a constraint. The FHIR data is used to train a synthetic data generator (a generative model that produces realistic but synthetic FHIR resources). The downstream ML model trains on the synthetic data rather than the original PHI.
The pattern fits scenarios where data sharing across organizational boundaries is restricted or where the model will eventually be deployed in environments with stricter data access. The trade-off is that synthetic data can drift from real-data statistics, affecting model performance.
5. Federated Learning Across Payer Data Sets
A pattern for ML training across multiple payers without centralizing the data. Each payer trains a partial model on their own FHIR data; the partial models are aggregated to produce a combined model. No payer shares raw data with others.
The pattern is technically possible but operationally complex. Adoption in US payer markets is limited in 2026 but growing for specific use cases (rare disease prediction, fraud detection across plan boundaries).
6. Multimodal Combination With Free-Text Notes
A pattern that combines structured FHIR data (the easy-to-process clinical resources) with unstructured clinical notes (DocumentReference resources or attached free-text content). The combined representation captures information that pure structured data misses.
The pattern requires NLP infrastructure to process the free-text component. AWS Comprehend Medical, Google Cloud Healthcare API natural language, and similar services handle this. Production deployments are growing as LLM capabilities make free-text processing more accessible.
How Production ML Pipelines on FHIR Are Structured
Production payer ML on FHIR typically has three layers. The FHIR data store handles canonical resource storage. A feature engineering layer (often using Databricks, Snowflake, or similar) transforms FHIR resources into ML-ready features. The model training and serving infrastructure (SageMaker, Vertex AI, Databricks MLflow) handles the actual ML work.
The three-layer pattern separates concerns cleanly. The FHIR data layer can be reused for analytics and compliance APIs alongside ML. The feature engineering layer is ML-specific. The model layer is task-specific.
How This Connects to LLM Applications
LLM applications on FHIR data are a specific case of the broader ML pattern, with the multimodal pattern (Pattern 6) being particularly relevant because LLMs process text well. For deeper coverage of LLM-specific patterns, the 5 Patterns for using FHIR data to train payer LLM applications covers the LLM angle.
For the broader claims analytics modernization that supports many of these ML use cases, the Top 5 claims analytics modernization patterns using FHIR covers the analytics infrastructure.