If you’ve ever watched an RPM platform choke during a spike in device traffic, you already know the problem isn’t the volume of data on its own. It’s the mismatch between how medical devices generate data (constant, small, relentless) and how most backend systems expect to receive it (occasional, batched, predictable). Kafka reframes that relationship entirely by treating the data as a continuous stream rather than a series of discrete requests.

Why RPM Platforms Outgrow Traditional Architectures

Most RPM systems start simple. A device sends a reading, an API endpoint receives it, a database stores it. That works fine for a pilot program with a few dozen patients. It falls apart once you’re dealing with thousands of connected devices, each one is a small, independent data source firing constantly, and any hiccup in your ingestion layer means lost vitals data, which in healthcare is not a minor inconvenience.

What you actually need is a system that can absorb bursts of incoming data without breaking a sweat, hold onto that data reliably even if downstream services are temporarily unavailable, and let multiple consumers (alerting engines, analytics dashboards, EHR sync jobs) read from the same stream independently. That’s the exact shape of problem Kafka was designed to solve, and it’s why so many teams building a remote patient monitoring platform eventually land on an event-streaming architecture rather than trying to scale a request-driven one further.

How Kafka Fits Into an RPM Pipeline

In a typical setup, each device or gateway publishes readings to a Kafka topic, often partitioned by patient ID or device type to keep related events grouped and ordered. From there, separate consumer groups can process the same stream for entirely different purposes. One service checks incoming vitals against clinical thresholds and triggers alerts. Another writes raw readings to long-term storage. A third feeds a live dashboard that clinicians actually watch during their shift.

This separation matters more than it might seem at first glance. If your alerting logic and your storage logic are tightly coupled in a single service, a slowdown in one drags down the other, and in RPM that could mean a delayed alert for an actual clinical emergency. With Kafka, each consumer moves at its own pace against the same durable stream, so a slow analytics job never puts a critical alert at risk.

Designing for Reliability, Not Just Throughput

Throughput gets most of the attention in these conversations, but reliability is where RPM platforms live or die. Kafka’s replication model means a broker going down doesn’t mean losing data, since replicas hold copies across multiple nodes. Combine that with proper retention settings, and you get a stream that can be replayed if a downstream consumer needs to reprocess a window of readings after a bug fix or an outage.

Idempotent producers matter here too. Medical devices on spotty cellular or Bluetooth connections often retry sends, and without deduplication logic, that retry can quietly duplicate a vitals reading in your system, throwing off averages or triggering a false alert. Building this correctly from day one saves a lot of debugging later, and it’s the kind of detail that separates a platform that survives a device firmware update from one that doesn’t.

Where This Gets Complicated: Compliance and Latency Together

Healthcare adds a layer most Kafka tutorials never mention: every message in that stream is likely PHI, which means encryption in transit and at rest, strict access control on topics, and audit trails for who consumed what. None of that is optional, and retrofitting it after the pipeline is live is far harder than designing it in from the start.

At the same time, you’re balancing this against latency requirements that general-purpose IoT platforms don’t usually face. A dropped temperature reading from a smart thermostat is an inconvenience. A delayed alert on a cardiac patient’s irregular rhythm is a different category of problem entirely. This is part of why broader healthcare IoT solutions tend to bake compliance and low-latency alerting into the same architectural layer rather than treating them as separate concerns bolted on afterward.

Getting the Architecture Right the First Time

Kafka isn’t a magic fix you drop into an existing RPM system and walk away from. It changes how your team thinks about data: as an ongoing stream to be processed continuously, not a static record to be queried on demand. That shift touches your alerting logic, your storage strategy, and how your clinical teams actually consume the data day to day.

Get the partitioning strategy wrong, skip the idempotency work, or treat compliance as an afterthought, and you’ll end up with a system that’s technically streaming but practically fragile. Get it right, and you have a platform that can scale from a hundred patients to a hundred thousand without a redesign, which in this space, is usually the whole point.

This is the gap between having remote patient monitoring devices and having a monitoring system. The devices were never the hard part. The hard part is the architecture that moves a reading from the patient’s body to a clinician’s attention fast enough for it to matter, and does that reliably for thousands of patients at once. Teams building remote patient monitoring software are increasingly finding that the difference between a program that reduces readmissions and one that quietly gets abandoned by clinicians comes down to whether the underlying data layer streams or merely syncs.

This article walks through what a real streaming architecture for RPM looks like: the layers involved, the protocols that fit each layer, the tradeoffs between them, and the operational failure modes that only show up once you are running the system at scale.

Why batch and polling break down for monitoring

Most digital health products that “monitor” patients were originally built around the same pattern as any other web application: the device stores readings locally, an app periodically fetches them, and a backend job processes whatever arrived. This works fine for a fitness app. It fails for clinical monitoring because the entire value of RPM depends on the gap between an event happening and someone finding out about it.

A polling architecture treats every reading as equally urgent, or rather, equally non-urgent, because nothing gets prioritized until the next scheduled pull. A streaming architecture treats data as a continuous flow of events, each of which can be evaluated the instant it arrives. That distinction is the entire reason streaming exists as a discipline separate from ordinary application backend work.

RISK: The silent failure mode: Polling architectures do not fail loudly. They fail by being technically functional while clinically useless, quietly missing the window where an intervention would have prevented a hospitalization. Because the system still “works,” this failure often goes undiagnosed for months.

Anatomy of a vitals stream, sensor to alert

A production RPM streaming pipeline is made up of five distinct layers. Each has its own failure modes, and treating any one of them as an afterthought is usually where these programs break down at scale.

Device and edge capture

Wearables, cuffs, glucometers, and bedside sensors generate raw readings, typically over Bluetooth Low Energy to a hub device or directly over WiFi or cellular. Edge logic here handles basic signal validation, noise filtering, and local buffering so a dropped connection does not mean lost data.

Gateway and protocol normalization

A gateway service receives readings over lightweight publish-subscribe protocols, most commonly MQTT, and normalizes them from dozens of device-specific formats into a consistent internal event schema before anything downstream has to deal with vendor variation.

Ingestion and event broker

Normalized events land on a distributed event broker, typically Apache Kafka or a managed equivalent such as AWS Kinesis or Azure Event Hubs. Partitioning by patient ID here matters enormously, it is what keeps a single patient’s readings in order while still letting the system scale horizontally across hundreds of thousands of concurrent patients.

Stream processing and rules evaluation

A stream processing engine, such as Apache Flink or Kafka Streams, evaluates each event against clinical thresholds and trend logic in near real time: is this reading out of range, is it trending in a dangerous direction, does it correlate with another recent reading from the same patient. This is where raw data becomes a clinical signal.

Storage, delivery, and alerting

Flagged events are converted into HL7 FHIR Observation resources and pushed into the EHR, while parallel paths deliver dashboard updates over WebSocket connections and route urgent alerts to a clinician’s device. Everything, flagged or not, also lands in long-term storage for trend analysis and audit.

Picking the right transport for each layer

No single protocol handles the entire journey well, and teams that try to force one, usually REST polling, across every layer are the ones who end up rebuilding the pipeline eighteen months in. The right approach mixes protocols deliberately by layer.

Research into patient outcomes with RPM consistently points to timeliness as the variable that determines whether a program actually reduces hospitalizations or simply generates data nobody acts on. The protocol stack is not a backend implementation detail, it is the mechanism that determines whether "real time" is a marketing phrase or an operational reality.

The data volume problem nobody budgets for

Individually, a single vitals reading is a tiny payload. The problem is never one patient, it is the multiplication. A cardiac patient on continuous ECG monitoring can generate a meaningful data point every few seconds. Multiply that across a health system running RPM programs for thousands of chronic disease patients simultaneously, and the ingestion layer is now handling a sustained, continuous event volume that most legacy healthcare IT infrastructure was never designed to absorb.

The RPM device market itself illustrates the pace of this growth: global market value is projected to climb from roughly $67 billion in 2026 toward well over $100 billion by the early 2030s, with real time monitoring types leading that expansion. Every percentage point of that growth translates directly into event throughput that an ingestion architecture has to be built to absorb, not retrofit for after the fact.

RISK: Alert fatigue is a data problem: As device density per patient increases, naive threshold-based alerting produces a flood of low-value notifications. Stream processing has to include correlation and deduplication logic, not just per-reading threshold checks, or clinicians start ignoring the alert channel entirely, which defeats the entire purpose of the system.

Where IoT devices fit in the architecture

The device layer deserves more architectural attention than it usually gets. Every connected blood pressure cuff, glucometer, and wearable is effectively a distributed sensor node, and the growing footprint of IoT in remote patient monitoring means the edge is no longer a thin client, it is doing real work: buffering readings during connectivity gaps, performing basic anomaly filtering before transmission, and managing power consumption so a device stays usable for weeks rather than days.

Edge intelligence also matters for reliability. A home network drops, a patient travels out of coverage, or a device battery dies mid-sync. A well designed edge layer buffers locally and reconciles once connectivity resumes, rather than silently dropping readings, which is what happens by default in architectures where the device assumes the network is always available.

Reliability, security, and compliance in transit

Streaming health data at scale introduces operational demands that a batch system never has to face: guaranteed delivery, ordering guarantees per patient, encryption at every hop, and audit trails that satisfy HIPAA requirements for data that is moving, not just data at rest.

• Every hop between device, gateway, broker, and EHR is encrypted in transit, not just the endpoints

• Dead-letter queues and retry logic catch failed message delivery instead of silently discarding events

• Event partitioning preserves per-patient ordering even under high concurrent load across the platform

• Consumer lag and broker throughput are monitored continuously, with alerting on the monitoring system itself

• Alert correlation and deduplication logic sits ahead of clinician-facing notifications to prevent fatigue

• Retention policies on raw event data are defined explicitly against regulatory and clinical requirements

What a production stack typically looks like

The technology choices matter less than the discipline of building each layer for its actual job rather than stretching one tool to cover all of them. A health system’s engineering team building this from scratch benefits from starting with the ingestion and processing layers, since those are the two that are hardest to retrofit once a program is already running with live patients on it.

What to assess before you build

Most organizations do not need to build all six layers from zero. The useful starting point is an honest audit of what already exists and where the real bottleneck sits.

• Map your current data path end to end, and note every point where a reading waits for a scheduled job rather than being pushed

• Measure your actual alert latency today, from device reading to clinician notification, not the number in the vendor brochure

• Check whether your EHR supports FHIR subscriptions or only polling based integration

• Evaluate device-level buffering behavior during connectivity loss, most teams discover gaps here first

• Estimate event throughput at your target patient volume, not your current pilot cohort size

Our engineering team builds custom healthcare software around exactly this kind of streaming infrastructure, from edge device integration through Kafka-based ingestion to FHIR-compliant EHR delivery, tailored to the specific device mix and clinical program a health system is running.

Then it expands, and the stack that worked for five hundred patients starts to strain at five thousand, and by fifty thousand the cron job that used to poll for new readings every minute is taking four minutes to run, the alert engine is generating more noise than signal, and the database that used to answer a dashboard query in milliseconds is now scanning months of raw rows to plot a single trend line. None of this is a failure of the original build. It is what happens when a system designed around a population is asked to operate at the scale of a platform.

This piece walks through what actually changes as an RPM platform grows from a pilot to a population scale deployment, where the architecture genuinely needs to be different rather than just bigger, and what a stack built for millions of readings looks like in practice. Where it helps, we point to connected device and IoT engineering work and API gateway architecture that underpins it.

What changes between a pilot and a population

Scale in RPM is not one threshold, it is several, and each one breaks a different layer of the stack first. A platform that survives the jump from five hundred to five thousand patients can still fall over between fifty thousand and half a million, because the bottleneck moves from the database to the alert engine to the network layer as volume grows.

~500 A single relational database and a polling job handle everything. This is the pilot stage, and almost any reasonable architecture survives it.

~5,000 Polling intervals start slipping, dashboard queries against raw time series rows slow down, and the first alert fatigue complaints reach the clinical team. The cracks are visible but tolerable.

~50,000 The relational database can no longer keep up with sustained write volume from continuous devices. This is where most first generation stacks require a rebuild, not a tune up.

500,000+ Multi region device connectivity, edge based pre processing, and horizontally partitioned ingestion become necessary rather than optional. This is platform territory, built for many programs and device types at once.

The point of mapping it this way is not to scare a small program into over building. A five hundred patient pilot does not need a platform built for five million readings a day. The point is to know which threshold is coming next, so the rebuild happens on purpose rather than during an outage.

The pipeline that gets data off the device and into the system

Every RPM platform starts the same way functionally: a device produces a reading, and that reading needs to travel from the device, across an unreliable network, into a system that can store it, evaluate it, and surface it to a clinician. At pilot scale this can be a simple HTTP endpoint that a device or its companion app calls directly. At population scale, that same direct call becomes a single point of failure the moment device count crosses into the tens of thousands.

The pattern that holds at scale separates device communication from downstream processing entirely. Devices publish over a lightweight protocol built for constrained, intermittent connections, typically MQTT, to a broker designed to handle a very large number of simultaneous low bandwidth connections. A bridge layer translates those messages into a durable, high throughput stream, most commonly Apache Kafka or a Kafka compatible alternative, where they can be processed, fanned out, and replayed if a downstream consumer falls behind.

This decoupling matters for a reason beyond throughput. When ingestion and processing are separate systems, a spike in device traffic, a slow downstream consumer, or a maintenance window on the alert engine does not cause readings to be dropped. The stream holds them until the consumer catches up. A direct device to database call has no equivalent buffer, and under sustained load it simply starts failing requests, which in RPM means missed readings from a real patient.

PATTERN- Decouple before you optimize. Most early performance problems in RPM platforms are framed as database tuning problems. Often the actual issue is architectural: the system has no buffer between device traffic and processing, so any slowdown anywhere in the pipeline propagates immediately back to the device connection. Adding a stream layer between ingestion and processing solves more scaling problems than almost any single database optimization.

Why a general purpose database stops working

Health readings are, structurally, time series data. A heart rate reading, a glucose value, a blood pressure pair, a pulse oximetry sample: each one is a timestamp, a patient identifier, a value, and a small amount of metadata. A standard relational table can store this shape of data without complaint at low volume. The trouble starts with the access pattern, not the schema. RPM systems write constantly and read in time ranges, and that combination is exactly what general purpose databases are not optimized for.

Purpose built time series databases such as TimescaleDB or InfluxDB handle this differently from the start. They automatically partition data by time, index along the time axis natively, and compress older data aggressively, which means a query for a patient’s last seven days of readings stays fast even when the underlying table holds years of history across millions of patients. A relational database asked to do the same thing degrades steadily as the table grows, because it was never designed around the assumption that almost every query filters by a time window.

In practice, platforms operating at real scale run a tiered storage model rather than one database doing everything: a time series store for active, frequently queried data, a relational store for patient records, care plans, and device inventory, and a cold storage tier for older readings that need to be retained for compliance but are rarely accessed. This is also where interoperable data architecture earns its keep, since readings eventually need to leave this stack entirely and land in an electronic health record as structured, codeable clinical data.

The problem nobody budgets for: too much data, not too little

The instinct when building an RPM program is to worry about missing a critical reading. The lived experience of most mature programs is the opposite problem: too many alerts, most of them not clinically meaningful, arriving faster than a care team can act on them. A continuous glucose monitor alone can generate hundreds of data points a week per patient. Multiply that across a panel of several thousand patients on several device types, and a naive threshold based alert rule, fire whenever a value crosses a fixed line, will bury a care team in noise within days.

NOISE

Static thresholds do not account for individual baselines

A heart rate of 110 is unremarkable for a patient mid walk and concerning for a patient at rest. A single fixed threshold applied across a population either misses real events or triggers constantly on patients whose normal range sits near the line. This is the single largest driver of alert fatigue in deployed RPM programs.

LATENCY

Batch alerting introduces a dangerous lag

Some early RPM builds evaluate alert rules in a nightly or hourly batch job because that was simple to build at pilot scale. At population scale this means a genuinely urgent reading can sit unreviewed for hours, which defeats the purpose of continuous monitoring entirely.

ROUTING

Every alert reaching every care team member does not scale

A program with a hundred patients can route every alert to one nurse. A program with tens of thousands of patients across multiple conditions and care teams needs alert routing logic that matches severity and patient assignment, or the most overloaded inbox in the organization becomes the actual bottleneck in patient safety.

DRIFT

Device calibration drift produces false signal at scale

A small percentage of devices drifting out of calibration is invisible at pilot scale and becomes a measurable source of false alerts once a fleet reaches tens of thousands of units. Fleet level device health monitoring, not just patient level reading monitoring, becomes its own operational requirement.

The fix that actually holds up is layered rather than a single smarter threshold: individualized baselines instead of fixed cutoffs, real time stream based evaluation rather than batch jobs, severity aware routing rather than broadcast alerts, and ongoing device fleet health monitoring as a parallel data stream to patient readings.

The largest challenge is not a lack of data, it is too much of it. Without intelligent filtering, monitoring increases workload instead of reducing it.

on remote monitoring at scale, industry analysis, 2026

Edge processing and the offline reality of remote care

Cloud native architecture assumes a device can reach the cloud. A meaningful share of RPM patients live in areas with inconsistent connectivity, and even in well connected areas, home networks drop. A platform that assumes every reading reaches the server the moment it is generated will quietly lose data during exactly the connectivity gaps that matter most.

The answer at scale is edge processing: lightweight computation that happens on or near the device itself, buffering readings locally during an outage, performing basic validation before transmission, and batching uploads once connectivity returns rather than discarding what was collected offline. This also reduces unnecessary network chatter, since not every raw reading needs to travel individually the moment it is captured.

Scale has a financial side, not just a technical one

Current CMS remote patient monitoring billing codes require documented device readings across at least sixteen days within a thirty day period, along with tracked clinical review time, to support reimbursement. This is not a minor detail buried in a compliance appendix. It means time logging, audit trails, and reading count tracking have to be built into the platform from day one, because a program that cannot produce this documentation at scale leaves real reimbursement on the table no matter how clinically effective the monitoring itself is.

• Confirm the platform tracks per patient reading counts against the documented day threshold automatically, not through manual chart review

• Build clinical time tracking into the care team workflow itself, not as a separate system reconciled after the fact

• Design audit trails that satisfy both compliance review and payer documentation requests without custom reporting work each time

• Treat outcomes and adherence dashboards as a product requirement, since value based contracts increasingly tie payment to demonstrated results, not just monitoring activity

What to verify before scaling past the pilot

Most RPM scaling failures are predictable in advance, because the same handful of assumptions break in the same order every time volume grows past what the original build was designed for.

• Confirm ingestion is decoupled from processing through a durable stream layer, not a direct device to database call

• Move time series reads off a general purpose relational database before query latency becomes a clinical workflow problem

• Replace fixed threshold alerting with individualized baselines before alert fatigue causes real alerts to be ignored

• Build edge buffering for offline tolerance before, not after, a connectivity gap causes a documented data loss event

• Build billing relevant tracking, reading counts, clinical time, audit trails, into the platform itself rather than a downstream spreadsheet

• Plan the database and alerting rebuild at the fifty thousand patient threshold deliberately, rather than discovering it during an incident

Engineering teams building remote monitoring infrastructure can find related architecture detail in the IoT and connected device services overview, and in the broader API gateway architecture guide, which covers the integration layer that eventually connects monitoring data back into the electronic health record. Programs further along this path may also find the clinical documentation cost analysis relevant, since incomplete documentation of monitoring derived findings creates many of the same downstream billing problems described above.

If you nodded along and Googled it later, you are not alone. FHIR is simultaneously the most important technical standard in digital health and one of the least well-explained concepts in healthcare founding conversations. This guide is for founders who need to understand FHIR well enough to make product decisions, evaluate vendor claims, and have credible conversations with health system buyers — not to write API documentation.

What FHIR actually is — the plain-English version

The analogy that makes it click

Imagine that every hospital, clinic, pharmacy, lab, and insurance company stores patient data in a different language — literally. One speaks French, one speaks Mandarin, one speaks Swahili. Getting them to share information requires a translator for every pair of systems. FHIR is the universal language that every system agrees to speak. It is a standardized format for packaging and exchanging health data so that any FHIR-speaking system can read what any other FHIR-speaking system sends — without a custom translator for every connection.

More precisely: FHIR (Fast Healthcare Interoperability Resources) is a standard published by HL7 International that defines exactly how health data should be structured, labeled, and transmitted between digital systems. The “API” part means that FHIR data is designed to be accessed over the internet using the same web technology that powers every app you use — which is why integrating health data via FHIR is dramatically simpler than the legacy alternatives.

Before FHIR, health data exchange required custom integration work for every connection between systems — a hospital’s Epic EHR and a pharmacy’s software each needed a bespoke bridge built between them. FHIR replaces those custom bridges with a shared standard, the way email replaced having a custom connection between every pair of inboxes.

Three concepts you need to understand

FHIR conversations in healthcare typically involve three ideas that get conflated. Keeping them separate will help you evaluate what vendors and engineers are actually telling you.

What data actually travels over FHIR

When your product connects to a hospital’s EHR via FHIR, the data you can access is organized into specific resource types. Understanding which resources your product needs — and whether a given EHR actually exposes them — is one of the most important questions in any enterprise healthcare integration conversation.

R01 Patient

Demographics, identifiers, contact info. Every clinical encounter is linked to a Patient resource — it is the anchor for everything else in the health record.

R02 Observation

Lab results, vital signs, social history entries. A blood pressure reading, an HbA1c result, a BMI — all Observations. The most frequently accessed resource in clinical AI applications.

R03 MedicationRequest

Active prescriptions and medication orders. Your product needs this resource for medication management, drug interaction checking, or adherence monitoring.

R04 Condition

Diagnosed conditions and problem list entries. This is how your application knows a patient has type 2 diabetes or heart failure — the conditions are coded to standard terminologies (ICD-10, SNOMED CT).

R05 Encounter

Clinical visits and admissions. Each time a patient sees a provider, an Encounter resource is generated. Essential for care coordination, transitions-of-care, and billing workflows.

R06 DiagnosticReport

Structured diagnostic results — radiology reports, pathology reports, cardiology findings. If your product involves imaging AI or specialty diagnostics, this resource is critical.

R07 DocumentReference

Clinical notes, discharge summaries, prior authorization letters. Unstructured documents are referenced here — important for ambient scribe output, care summaries, and CDI workflows.

📌 Founder takeaway: Before your next hospital demo, ask your engineering team: “Which FHIR resource types does our product read from and write back to the EHR?” If they can’t answer this in under two minutes, you have a scoping problem that will surface at the worst time — during a procurement conversation. Peerbits’ healthcare API gateway architecture guide covers how to structure this for production at scale.

Why your product probably needs FHIR — even if your CTO hasn’t said so

Healthcare founders sometimes assume FHIR is a “nice to have” — something to implement when they get to enterprise sales. This assumption fails in three predictable ways.

First, hospital buyers now require it in RFPs. As of 2026, most US health system IT procurement processes include a FHIR API compliance requirement as a standard evaluation criterion. A product that cannot demonstrate FHIR-based EHR integration does not make it past the first RFP filter at the majority of large health systems — the conversation never gets to a demo.

Second, CMS mandates have made it a regulatory requirement for many workflows. In December 2024, CMS finalized CMS-0057, requiring healthcare providers and payers to implement five FHIR-based APIs covering patient access, provider directory, drug formulary, prior authorization, and administrative data. If your product touches any of these workflows for a covered entity, FHIR is not optional — it is a compliance requirement that affects your customer’s regulatory standing.

Third, not having FHIR creates compounding technical debt. Products that build proprietary data integrations early end up with a maintenance nightmare: a different custom connection for every EHR they support, each one breaking when EHR versions update, each one requiring bespoke engineering for every new customer. FHIR integration upfront is a one-time investment that pays compounding returns with every additional customer.

The regulatory timeline every health-tech founder should know

FHIR adoption is being actively accelerated by regulatory mandates. As a founder, you need to know which of these affects your customers — because their compliance obligations become your product requirements.

2020–2021

ONC 21st Century Cures Act Final Rule

Required certified health IT developers to implement FHIR R4 Patient Access APIs. Established the information-blocking prohibitions. Most major EHRs (Epic, Cerner, Athenahealth) now expose FHIR R4 endpoints — this is why your team can connect to them.

2023–2024

TEFCA (Trusted Exchange Framework) Phase 1

Established the national network for health information exchange using FHIR and underlying standards. Participating Qualified Health Information Networks (QHINs) enable broader data exchange than individual EHR connections. If your product needs population-level data access, TEFCA is the pathway.

Dec 2024

CMS-0057 Final Rule — Five FHIR API Mandate

CMS finalized requirements for payers and providers to implement five FHIR APIs: Patient Access, Provider Directory, Drug Formulary, Prior Authorization, and Administrative. If your product supports prior authorization workflows or payer connectivity for a covered entity, this mandate directly affects your integration requirements.

Late 2026

FHIR R6 Expected

The next major version of the FHIR standard, with most clinical and administrative resources achieving “normative” status — meaning long-term stability and reduced future migration complexity. If you are building a new platform today, understanding the R4-to-R6 migration path is relevant for your 18-month roadmap.

What “FHIR-compliant” actually means — and what vendors get wrong

Every digital health vendor in 2026 claims to be “FHIR-compliant.” This claim ranges from genuinely robust to almost meaningless, and knowing how to evaluate it is one of the most practically valuable things a non-technical founder can learn.

What does “FHIR-compliant” actually mean?

At minimum, it means the vendor can send and receive data in FHIR format. But “can exchange FHIR data” and “exchanges clinically useful FHIR data” are very different things. A system can be technically FHIR-schema-valid while sending data with missing terminology bindings, incorrect coding, or incomplete resource populations that make the data useless in downstream clinical workflows. Ask for specific resource types supported and conformance to the US Core Implementation Guide — not just “we support FHIR.”

What is the difference between FHIR R4 and FHIR R5?

FHIR R4 (released 2019) is the current production standard and what the majority of US health systems expose via their EHR APIs. FHIR R5 (released 2023) introduced new features but has limited adoption due to its “trial use” status. For most health-tech products in 2026, FHIR R4 with US Core Implementation Guide conformance is the target. Don’t let a vendor confuse you by claiming R5 features when your customers are running R4.

What is an “Implementation Guide” and why does it matter?

The base FHIR standard is intentionally flexible — it defines possible data fields but doesn’t always require specific ones. An Implementation Guide (IG) adds those requirements for a specific use case or country. The US Core IG is the most important one for US health-tech: it specifies which FHIR resources must be supported, which data fields are required, and which terminology codes must be used. A product conforming to US Core IG is genuinely interoperable; a product claiming “FHIR support” without IG conformance may not be. See our Healthcare API Gateway guide for more on implementation guide enforcement.

Can FHIR read data AND write data back to the EHR?

Reading (GET) is far more broadly supported than writing (POST/PUT). Most EHRs today expose robust read APIs under the 21st Century Cures Act mandate — but write-back access (your product writing data back into the patient record) requires separate EHR vendor agreements, additional authorization scopes, and in some cases separate app certification. If your product’s value proposition depends on writing data into Epic or Cerner (e.g., an ambient scribe writing notes, a CDI tool writing coding suggestions), confirm write-back access specifically — not just “FHIR support.”

The five FHIR questions to ask before every hospital demo

You do not need to understand FHIR deeply to ask good questions about it. The following five questions — asked of your engineering team before a hospital demo — will surface the integration risks and readiness gaps that could derail an enterprise deal at the worst moment.

• “Which EHR systems have we tested our FHIR integration against, and which is the customer running?”Epic, Cerner, Oracle Health, Athenahealth, Meditech, and Allscripts all expose FHIR APIs — but each has its own data model quirks, authentication flows, and resource availability. “We support FHIR” is not the same as “we have a tested connection to your Epic environment.” This question surfaces whether your team has done real integration work or theoretical compliance work.

• “Do we conform to the US Core Implementation Guide — and have we run a validator against our resources?”US Core conformance is the clinical interoperability bar, not just schema validity. If your team can’t run the HL7 FHIR validator against your resources and show a clean conformance report, you are not ready for a health system integration conversation. Peerbits validates against US Core in every healthcare software development services.

• “Do we read only, or do we write data back to the EHR — and have we confirmed write-back access with the customer’s EHR vendor?”This is the question that most founders don’t know to ask. If your product’s value depends on writing into the EHR, and your customer’s Epic environment hasn’t approved your application for write-back access, your go-live is blocked until it does. That approval process can take weeks to months.

• “How do we handle FHIR data from patients who have records at multiple health systems?”Patients with records at multiple institutions will have different Patient resource IDs at each. Matching a patient across systems — patient matching — is one of the hardest problems in FHIR implementation. If your product needs a longitudinal patient view across EHRs, your team needs to explain how they solve this.

• “Is our FHIR integration layer a clean abstraction, or are we building point-to-point connections per customer?”If your team is building a custom FHIR connection for each new hospital customer, you have a scaling problem that will hit you at 10 customers. The answer you want is a centralized API gateway that handles FHIR authentication, multi-source normalization, and per-tenant isolation as a platform service — not a per-customer engineering project. Peerbits has built production-scale FHIR gateway infrastructure for health systems and digital health platforms — see our API Gateway Architecture Guide for the full design.

The 2025–2026 shift is architectural. Healthcare systems are deploying AI agents — autonomous systems that don’t just respond to queries but pursue goals across multiple systems, handle the full lifecycle of a workflow, and escalate to humans only when a decision requires judgment or authority that should remain human. The difference isn’t a matter of degree. It is a fundamentally different product category.

This article maps six real deployment patterns for healthcare AI agents — the use cases that are delivering measurable outcomes for health systems and digital health platforms today — and explains the engineering requirements that make them viable. Peerbits builds these capabilities into custom healthcare platforms, with integrations across Epic, Cerner, Oracle Health, and payer APIs.

What makes an AI agent different from a chatbot

The distinction matters practically, not just semantically. Understanding what separates an AI agent from a chatbot determines whether a given use case is actually within scope for each technology.

This capability gap is why health system buyers have moved beyond chatbot evaluations. The operational problems they are trying to solve — prior authorization backlogs, documentation burden, care gap closure, revenue cycle leakage — require an agent that can execute, not just advise. Peerbits' healthcare software trends analysis mapped this shift in enterprise buyer priorities as one of the defining signals of the year.

Six production-grade AI agent use cases

The following use cases are drawn from live deployments and peer-reviewed analysis of agentic AI systems in healthcare. Each maps to a specific pain point with a defined architecture pattern.

Use Case 01 · Clinical Documentation

Ambient documentation agents — the scribe that closes the loop

The VA’s 2026 deployment of ambient scribe technology to every VA medical center nationwide is the largest government healthcare AI deployment in US history. The pattern it follows is now commercially available: a voice-first agent listens to the patient encounter in real time, structures clinical content into a SOAP note, and pushes a draft to the EHR for physician review and signature — without the physician touching a keyboard.

What separates an agent from a transcription tool here is the downstream step: the agent doesn’t just produce a note. It surfaces ICD-10 coding suggestions based on the documented conditions, flags documentation gaps that could affect billing (missing specificity, absent medical necessity language), and can route queries to the CDI team automatically if the note falls below a documentation quality threshold. The physician reviews, edits, and signs — the execution cycle runs autonomously. Peerbits integrates these ambient documentation workflows as part of custom EHR development engagements, with specialty-specific note templates for primary care, hospitalist, and surgical workflows.

Platforms like Nuance DAX and Abridge are consistently saving clinicians one to two hours of documentation time per day in production deployments

Use Case 02 · Revenue Cycle Management

Prior authorization agents — from weeks to hours

Prior authorization is among the most administratively burdensome processes in US healthcare — and among the most well-suited to agentic automation. The workflow is deterministic at its core: read the clinical record, identify the payer’s coverage policy for the requested service, gather the required supporting documentation, and submit. The problem is that this involves five or six different systems, each with its own data model and access pattern, requiring a human to manually orchestrate the whole sequence.

A prior authorization agent handles this end-to-end: it pulls the patient’s clinical history from the EHR via FHIR API, retrieves the payer’s current coverage criteria (updated via a policy feed), assembles the prior auth package, submits to the payer portal, monitors for response, and — critically — reads denial letters and assembles corrected appeals autonomously when a denial comes back. The human reviewer sees a fully assembled package with a recommendation, not a blank form. Peerbits builds these agents as part of revenue cycle management software development with bidirectional payer API integration.

Prior authorization agents reduce average auth turnaround from 5–7 business days to under 12 hours in production deployments — Menlo Ventures 2025 State of AI in Healthcare

Use Case 03 · Patient Engagement

Care gap closure agents — proactive outreach that acts on responses

Traditional patient engagement platforms send reminders. AI agents close gaps. The distinction is operational: a reminder tells a patient they’re due for a mammogram; a care gap closure agent identifies the population cohort from the EHR’s quality reporting data, segments by risk and outreach history, generates personalized messages, sends them via the patient’s preferred channel, interprets responses in natural language, books the appointment when the patient says yes, and updates the care gap registry — all without staff intervention.

Patient engagement AI is growing at 20× year-over-year, driven precisely by this shift from notification to execution. The agent handles the full cycle of outreach-to-scheduling, escalating to a human coordinator only when a patient expresses hesitation that requires clinical counseling. Peerbits builds these closed-loop patient engagement platforms with EHR-native care gap data, multi-channel outreach (SMS, app push, portal message), and scheduling integration.

Health systems using proactive AI care gap agents report 30–45% appointment fill rates on automated waitlists — NextGen Healthcare 2025

Use Case 04 · Diagnostic Support

Multi-agent diagnostic orchestration — radiology triage at scale

The FDA has cleared over 1,200 AI/ML-enabled medical devices as of mid-2025, with radiology representing the largest single category. The next architectural step is multi-agent orchestration: rather than a single AI model reviewing an imaging study, a planner agent routes the study to specialized agents (a lung nodule characterization agent, a bone density agent, a comparison agent that pulls prior studies from the PACS), synthesizes their outputs into a structured report, assigns a finding priority score, and queues it for radiologist review in priority order — not chronological order.

Oxford University’s tumor board agents, built in collaboration with Microsoft, demonstrate the same pattern in oncology: agents that summarize patient charts, determine cancer staging, and draft guideline-compliant treatment plans — all prepared before the tumor board convenes, so the human discussion is focused on judgment rather than preparation. The architecture for these multi-agent systems requires careful design of the orchestration layer — how agents hand off context, how conflicting outputs are resolved, and how human override is surfaced. This is an area where Peerbits’ healthcare API gateway architecture provides the integration backbone.

Multi-agent radiotherapy planning systems have matched expert performance for cervical cancer and exceeded it for lung cancer in peer-reviewed evaluation — NPJ Digital Medicine, 2026

Use Case 05 · Care Coordination

Discharge and transitions-of-care agents — closing the post-discharge gap

The 30-day readmission window is one of the most expensive failure modes in US healthcare — and one of the most documentation-dependent. Discharge instructions that don’t reach the patient’s PCP, medication reconciliation that doesn’t happen at the transition, follow-up appointments that aren’t booked before the patient leaves. Each of these is a workflow gap that an agent can close.

A transitions-of-care agent monitors the discharge planning workflow from the moment an inpatient admission is flagged for discharge: it pulls the patient’s post-acute care preferences, identifies in-network PCPs with availability, sends a C-CDA summary to the receiving provider via Direct messaging or FHIR API, schedules the 7-day follow-up appointment, enrolls the patient in a medication adherence check-in sequence, and flags any patients who haven’t confirmed receipt of discharge instructions within 24 hours for a nurse callback. Human staff intervene on exceptions; the agent handles the execution baseline.

Agentic discharge workflow tools reduce 30-day readmission rates by 12–18% in high-risk patient cohorts — consistent across multiple health system pilots

Use Case 06 · Research & Life Sciences

Drug discovery and clinical trial agents — science that runs overnight

Over 30% of new drugs in 2025 involved generative AI at some stage of development. The agentic pattern in life sciences is among the most advanced: autonomous agents that execute protein property predictions, analyze experimental datasets, generate hypotheses, and design follow-up experiments — all without human prompting between cycles. Systems like ProtChat demonstrate the pattern: a multi-agent architecture where specialized agents handle protein analysis, evaluation, and visualization tasks, operating continuously across datasets that no human team could process at the same speed.

For clinical trial operations, agents handle eligibility screening (reading patient records against inclusion/exclusion criteria at scale), site feasibility assessment, adverse event monitoring, and protocol deviation detection — reducing the administrative burden on clinical research coordinators so they focus on the work that requires human judgment. Peerbits builds these data pipeline and research automation capabilities on top of multi-tenant healthcare platform architectures designed to handle the data volumes research workflows require.

Agentic protein analysis systems autonomously execute complex multi-step benchmarks across drug interaction datasets without manual intervention — Nature NPJ Digital Medicine, 2026

The engineering stack behind production healthcare agents

Healthcare AI agents fail in production not because of the AI model but because of the infrastructure around it. The five-layer architecture below is the minimum viable foundation for a production-grade healthcare agent — built from Peerbits’ deployment experience and aligned with the HIPAA by Design engineering framework.

How to evaluate and prioritize AI agent use cases

The question most healthcare technology leaders face is not “can we use AI agents?” — the answer is clearly yes. The question is “which use case do we build first, and how do we scope it so it delivers value without creating unacceptable clinical risk?”

The evaluation framework Peerbits uses with health system and digital health clients starts with three filters:

• Is the workflow deterministic enough to be governed? The best first agent use cases are workflows where the rules are clear, the failure modes are well-understood, and human override is easy to design. Prior authorization and documentation improvement pass this test. Autonomous diagnosis generation does not — at least not yet.

• Is the data surface clean and accessible? An agent that depends on unstructured, inconsistently populated EHR data will fail unpredictably. Assess the data quality and API availability of every source the agent will need before scoping the feature.

• Is the escalation design as strong as the automation design? The best agent deployments are designed from the escalation case backward — every scenario where the agent should not act autonomously must be explicitly handled. Skipping this step is the most common cause of clinical workflow failures in production AI agents.

• Does the architecture support HIPAA compliance at every data hop? Every PHI-bearing API call, every inference event, every output stored — all require BAA coverage, encryption, and immutable audit logs. This is non-negotiable and must be engineered in from day one, not retrofitted after deployment.

• Can you measure clinical and operational outcomes, not just technical metrics? Agent deployments that can only report API latency and uptime won’t survive their first enterprise renewal. Define outcome metrics (auth turnaround time, documentation burden per physician, readmission rate) before you build.