How AI Moves CGM Data Into the EHR

Raw CGM data is not documentation. I learned that the hard way.

We had a clean integration on paper: Libre and Dexcom readings arriving through FHIR, timestamps aligned, patient identity mapped, everything validated. The stream looked beautiful. Then clinicians opened the chart and asked the only question that mattered: “What am I supposed to do with this right now?”

That was the friction. Not the device feed. Not the API. Not even the EHR writeback. The problem was clinical context.

Continuous glucose monitoring only becomes useful inside documentation when the flow changes from a device firehose into a structured narrative. AI is what makes that possible at scale.

CGM data is finally leaving the device silo

Dexcom and Abbott are no longer just patient-facing tools. Their data is now flowing into Epic and Cerner through FHIR-based pathways, and that changes the architecture completely. Instead of waiting for a patient to manually reconcile logs at a visit, we can move time-series glucose data into workflows that clinicians already trust.

But I do not buy the idea that “if it’s in the chart, it’s integrated.” I’ve seen integrations that dumped thousands of CGM points into a note field and called it digital transformation. That is not integration. That is noise with a transport layer.

What clinicians need is summarized, attributable, and actionable data:

• time in range over the relevant window
• hypoglycemia episodes that matter clinically
• trends tied to meals, medication changes, and adherence patterns
• exceptions that require review, not every datapoint ever collected

That is where AI belongs.

AST and the part everyone underestimates

At AST, we have built and reviewed healthcare workflows where device data looks “done” because the API works, but the workflow still fails. In one respiratory-care deployment, we saw the same pattern: the input stream was solid, the clinical output was useless until we added rules for summarization, suppression, and escalation. CGM is no different.

In another AST integration, our team spent weeks untangling why structured data never showed up in the right place in the EHR. The culprit was not the interface engine. It was context loss between ingestion and documentation. Same lesson here: if CGM data enters the chart without interpretation, it creates more work for the clinician than the patient.

The architecture that actually works

The best pattern I’ve seen is a layered one:

1. Ingest the stream. Pull CGM readings from Dexcom or Abbott into a secure ingestion layer using FHIR where available, plus vendor-specific APIs where needed.
2. Normalize the data. Convert device-specific payloads into a common model with consistent units, time zones, encounter linkage, and patient identity resolution.
3. Run AI summarization. Use rules plus machine learning to detect trends, anomalies, and clinically relevant changes. Do not ask a model to “understand diabetes” in the abstract. Ask it to detect useful patterns in bounded, auditable ways.
4. Attach clinical context. Link CGM summaries to medications, problem lists, recent encounters, and relevant documentation windows.
5. Write back selectively. Push only the summary, exceptions, and clinician-ready artifacts into Epic or Cerner via appropriate FHIR resources and documentation workflows.

The key is selective writeback. More data is not more value. The EHR already has enough clutter. If AI cannot reduce cognitive load, it is a liability.

Why AI matters specifically for patient engagement

Patient engagement dies when the feedback loop is too slow. CGM is one of the few data sources that can close that loop in near real time, but only if the system can translate readings into something a provider or care manager can act on without reading a day-by-day trace.

AI helps in three ways:

1. It compresses the signal. A week of glucose data becomes a clinically usable summary instead of a graph that only one person on the team knows how to read.

2. It prioritizes attention. If a patient has a pattern of overnight lows, missed boluses, or post-meal spikes, the system can surface that pattern instead of dumping raw values into documentation.

3. It supports outreach. Patient engagement teams can use the same summaries to trigger messaging, education, scheduling, or escalation before the next visit.

That last one matters most. If the workflow ends at charting, you built passive documentation. If it ends in proactive outreach, you built engagement.

What breaks first

Every time we design this kind of flow, the first thing that breaks is not the model. It is identity, timing, or trust.

Identity breaks when you cannot reliably match the device user to the chart patient.

Timing breaks when readings arrive out of order or get batched in a way that ruins trend detection.

Trust breaks when clinicians see AI-generated summaries that are technically accurate but operationally wrong for the encounter.

That last one is the trap. A summary can be numerically correct and still be clinically useless. I would rather ship a narrower summary that clinicians trust than a broad one they ignore.

We’ve had to make that tradeoff inside actual delivery pods. The smart move is not to maximize model output. The smart move is to maximize clinician confidence.

Where Epic and Cerner fit

Epic and Cerner are not the destination for every CGM datapoint. They are the clinical record, which means the data that lands there should already be filtered, summarized, and ready for action.

That means building around their strengths:

• FHIR for interoperable transport
• documentation workflows for chart insertion
• patient portals for engagement loops
• tasking and inbox workflows for outreach

If you try to treat the EHR like a streaming analytics platform, you lose. If you treat it like the clinical system of record and feed it only the right context, you win.

My blunt take

The future is not “AI reads CGM.” The future is “AI makes CGM document itself in a way clinicians can actually use.”

That difference sounds small. It is not.

One version creates more chart noise. The other turns continuous device data into a usable clinical signal that supports patient engagement, follow-up, and better decision-making. That is the work. That is the architecture. And that is where the real value sits.

When we build it well, CGM stops being a disconnected device feed and becomes part of the care conversation in Epic, Cerner, and every workflow around them.

That is the point.