FHIR Data Streaming: Real-Time Clinical Data for Research
FHIR data streaming means moving clinical data as FHIR resources continuously, as events happen, instead of in periodic batch exports. A new lab result, admission or prescription is sent onward within seconds or minutes using FHIR Subscriptions or an event pipeline, so downstream systems always work with current data. For research, streaming makes near real-time surveillance, trial monitoring and living cohorts possible, provided the data is normalized and governed as carefully as any batch extract.
Why FHIR data streaming matters now
For most of the last decade, research teams received clinical data in snapshots: a monthly or quarterly extract from the electronic health record (EHR), transformed and loaded into a research database. That rhythm suits many retrospective studies. It does not suit questions where timing matters, such as detecting an adverse drug reaction early, spotting eligible patients for a trial while they are still in clinic, or tracking an outbreak as it unfolds.
FHIR (Fast Healthcare Interoperability Resources) has made a different pattern practical. Because EHR vendors now expose FHIR interfaces, and because the FHIR specification includes mechanisms for notifying other systems when data changes, organizations can feed events into analytics platforms as they occur. The result is a shift from “what did the data look like last quarter” to “what is happening now”.
How FHIR data streaming works
There is no single streaming feature in FHIR. Instead, teams combine a few building blocks depending on their systems and needs.
FHIR Subscriptions
A Subscription tells a FHIR server to notify another system when resources matching certain criteria are created or updated. FHIR R4 included a basic Subscription resource; later work introduced topic-based subscriptions, where the server publishes named topics such as “new encounter” and clients subscribe to them. A backport implementation guide brings topic-based subscriptions to R4 servers. Notifications can be sent to a REST endpoint, over websockets or by other channels, and can carry the full resource or just a pointer that the receiver then fetches.
Bulk Data export with frequent runs
The FHIR Bulk Data Access specification lets a client request all resources of given types, optionally only those changed since a given time. Running incremental exports frequently, for example every hour, is not true streaming, but it gives near real-time freshness with simpler infrastructure and is often the first step organizations take.
Event pipelines
Many organizations place an event streaming platform between source systems and consumers. Changes from the EHR or an integration engine are published as FHIR resources onto event topics, and several consumers, such as an operational dashboard, a research platform and a quality team, each read the same stream at their own pace. This decouples producers from consumers and makes it easier to replay events if a downstream system needs to rebuild its data.
Translation from legacy messages
Much real-time clinical traffic still flows as HL7 version 2 messages. Integration engines can translate those messages into FHIR resources as they pass through, so research consumers see one consistent format. If you are weighing these formats, our comparison of FHIR, HL7 v2 and CDA explains where each fits.
What streaming changes for research
Streaming opens up research designs that batch data makes hard. It also raises new questions about quality and governance.
New research possibilities
- Pharmacovigilance. Signals such as a lab abnormality shortly after a new prescription can be detected in days rather than months.
- Trial feasibility and recruitment. Eligibility rules can run against current data, flagging potential participants to their care team while they are still under active care.
- Living cohorts. Cohort definitions update continuously, so an analysis always reflects the latest follow-up.
- Public health surveillance. Aggregated counts of diagnoses or test results can be monitored day by day.
New quality challenges
Streaming data arrives before it is final. Results are amended, diagnoses are refined and duplicate events appear when systems retry. A research pipeline has to handle updates and deletions, not just inserts, and must keep track of which version of a record an analysis used. The same normalization work needed for batch data, mapping local codes to standard terminologies, converting units and resolving references, has to happen continuously and automatically.
New governance questions
Continuous feeds can feel more intrusive than periodic extracts because they mirror patient care almost live. Data custodians will want to know exactly which resources are streamed, to whom, for which approved purposes and with what de-identification. They will also want to be able to pause or revoke a feed instantly.
Streaming architectures compared
Organizations choose between moving the stream to a central research store or processing it where it originates. The trade-offs are significant.
| Dimension | Stream to central research store | Federated processing at the source |
|---|---|---|
| Where patient-level events go | Copied continuously to a central platform | Processed inside the custodian’s environment |
| Data transfer approvals | Needed for every feed and recipient | Data never leaves the source, so approvals focus on outputs |
| Normalization | Central team maps every site’s codes | Shared pipeline runs locally at each site |
| Revoking access | Requires deleting copies downstream | Switch off the analysis at the source |
| Multi-site analysis | Pool all streams centrally | Run the same query at each site and combine approved results |
| Typical outputs to researchers | Patient-level tables | Aggregates, models or approved de-identified data in a secure workspace |
A federated approach fits naturally with a Trusted Research Environment (TRE). The stream lands in an environment controlled by the data custodian, normalization and analysis run there, and only results that pass an output check are released.
From stream to research-ready data
Raw FHIR events are rarely the format researchers want to analyze. A common pattern is to land streamed resources, normalize them, and continuously update a research data model such as the OMOP CDM. Because OMOP uses standard vocabularies and a fixed schema, analyses written once can run repeatedly as new data arrives, and the same analysis can run across many sites that use the same model.
Key design choices at this stage include:
- Idempotent processing. Processing the same event twice must not create duplicate records.
- Handling amendments. When a result is corrected, the research record must update and the change must be traceable.
- Latency targets. Not every use needs seconds. Agree on how fresh the data must be for each purpose and design to that, rather than chasing the lowest possible delay everywhere.
- Versioned snapshots. Analyses that will be published should run against a frozen snapshot so results can be reproduced later.
A worked example: safety monitoring for a new therapy
Imagine a hospital network that wants to watch for liver injury in patients starting a newly approved medication. In a batch world, the team would wait for the next quarterly extract, by which point any early signal is months old. With streaming, each new MedicationRequest for the drug and each new liver function Observation is published as an event within the hospital’s own environment. A normalization step maps local lab codes to LOINC and converts units. A small analysis job, approved by the data custodian, joins the two streams and counts patients whose results cross a defined threshold within a set window after starting the drug. Clinical safety staff see the patient-level alerts as part of care. The research team sees only aggregate counts by week, released after an output check. If the signal grows, the study team can request a deeper approved analysis without anyone exporting the underlying records.
Practical next steps
Teams considering FHIR data streaming for research can work through a short sequence.
- Pick one use case where timing clearly matters, such as trial recruitment or safety monitoring, and define the resources it needs.
- Check what your EHR and integration engine already support: Subscriptions, incremental bulk export or HL7 v2 to FHIR translation.
- Decide where the stream will be processed. Processing inside a Federated Trusted Research Environment at each site keeps patient-level events under the custodian’s control.
- Build normalization into the pipeline from day one, including handling of updates and deletions.
- Agree governance with the data custodian up front: purposes, outputs, de-identification and how to pause the feed.
Streaming does not replace batch data. It adds a faster lane for the questions that need it. With the right architecture, that lane can be as well governed as the slower one.
Frequently asked questions
Does FHIR support real-time data streaming?
FHIR provides Subscriptions, including topic-based subscriptions, that notify other systems when data changes. Combined with event pipelines or frequent incremental bulk exports, these support near real-time data flows.
What is the difference between FHIR Subscriptions and Bulk Data export?
Subscriptions push notifications as individual resources change. Bulk Data export pulls large sets of resources on request, optionally only those changed since a given time. Many organizations use both.
Is streamed clinical data good enough for research?
It can be, once it is normalized and the pipeline handles amendments, duplicates and deletions. Published analyses should use frozen, versioned snapshots so they can be reproduced.
Can FHIR data be streamed without sending it to a central platform?
Yes. In a federated design the stream is processed inside each custodian’s environment, and researchers receive only approved outputs.
Should streamed FHIR data be converted to OMOP?
Often, yes. Continuously updating an OMOP database lets standard analyses rerun as new data arrives and makes multi-site studies easier.
What is the biggest risk in FHIR data streaming for research?
Governance drift: feeds that grow beyond their approved purpose. Clear agreements on scope, outputs and the ability to pause a feed instantly are the main safeguard.