Epic Cupid Integration for Cardiology Workflows & Connected Systems
Digital Growth Lead
Writes about healthcare technology, interoperability, and AI-driven transformation across modern care systems.
Part of our complete guide to integrating with Epic via FHIR.
Epic Cupid is Epic's cardiovascular information system (CVIS). It handles cardiology orders, documentation for the cath lab, echo and ECG, structured measurements and reports, and brings data from ECG carts, hemodynamic systems and cardiac imaging into the patient's chart over HL7, DICOM and device interfaces.
All Epic modules in one place: see our Epic modules list for what each module does and where apps integrate.
Cardiology generates a flood of data that does not look like anything else in the chart: angiography runs from the cath lab, echo loops, ECG waveforms, structured measurements, and device readouts. Pulling all of that into one coherent cardiovascular record is the job of Epic Cupid, and any team connecting a cardiology device, an ECG management system, or a cardiology app to Epic has to understand how Cupid handles it.
This guide explains Epic Cupid for the people building and scoping cardiology integrations: what the CVIS manages, how device and image data flows in, and which standards carry which part of the workflow. For the full module-by-module view, our Epic integration services are the hub this guide links back to.
What is Epic Cupid?
Cupid is Epic's Cardiovascular Information System (CVIS). It manages the cardiology equivalent of what Radiant does for radiology: ordering, scheduling, procedure documentation, structured reporting, and result routing, but for cardiac studies. Because it lives inside Epic, the cardiology team works from the same record as everyone else, with orders, results, and history in one place.
Like Radiant in imaging, Cupid coordinates the workflow and the structured data while images and waveforms are stored in a PACS or VNA. The value is in the structured cardiovascular record: measurements, findings, and procedure logs that are queryable, not just scanned documents. That structure is what makes cardiology data useful downstream.
What Cupid manages
Cupid's scope spans the main cardiology service lines.
Cath lab work covers invasive cardiology: procedure logging, device and inventory tracking, and structured reporting for catheterization and intervention. Echo and imaging handle the non-invasive side, with echocardiography workflow, images routed to PACS or a VNA, and the measurements that go into the report. ECG management covers waveform capture and storage, the confirmation workflow where a cardiologist over-reads and signs, and integration of the result into the chart. Each of these is a connection point for a device or an external system.
How device and image data flow in
Cardiology is device-heavy, so the inbound data flow is where most integration work lives.
On the way out, Cupid sends orders and worklists to modalities and devices, much like Radiant's modality worklist. On the way back, structured data, measurements, and findings flow from cardiology devices and ECG management systems into Cupid, while images and waveforms go to the PACS or VNA. An ECG, for example, is captured on a cart, stored as a waveform, surfaced in Cupid's confirmation queue for a cardiologist to read, and then filed to the chart. Each device vendor has its own quirks, which is why cardiology integrations reward experience with the specific systems in play.
Cardiology standards: HL7, DICOM, and FHIR
The same three standards from imaging appear here, with a cardiology twist.
HL7 v2 carries orders and results between Cupid and external systems through Epic Bridges, covered in our Epic Bridges integration guide. DICOM handles the images and waveforms, echo and angiography images, and ECG waveforms, stored in the PACS or VNA. FHIR R4 exposes Observations, procedure data, and reports to connected apps; our Epic FHIR integration guide covers that path. A complete cardiology integration usually uses HL7 for orders and results, DICOM for the imaging and waveforms, and FHIR for any app reading the data.
Where cardiology apps and devices fit
A lot of cardiology innovation sits around Cupid rather than inside it. Remote cardiac monitoring, AI ECG interpretation, structural heart planning tools, and cardiology-specific patient apps all need to exchange data with Epic. A remote monitoring product, for instance, collects data outside the hospital and needs to surface meaningful events into the cardiology workflow without burying clinicians in noise. An AI ECG tool reads waveforms, returns an interpretation, and has to land that result where the cardiologist already works.
The integration pattern is consistent: read the data you need through the right standard, run your logic, and return results into the workflow in a way that respects how the heart team already operates. Cupid and the modules around it are the connection surface. The routes, approvals and timeline behind that connection are covered in our Epic EHR integration guide.
The gotchas worth knowing
Cardiology integrations have their own pitfalls:
- Device diversity. Cath lab, echo, and ECG systems come from many vendors, each with its own interface quirks.
- Waveforms are not images. ECG waveform handling differs from standard imaging and needs specific attention.
- Structured reporting matters. The value of Cupid is structured measurements; an integration that loses that structure loses the point.
- CVIS is not PACS. As with Radiant, Cupid coordinates while the PACS or VNA stores images and waveforms.
- PHI throughout. Cardiac data is PHI, so access control and audit logging apply across the chain.
If you are weighing these points for a specific device or application, discuss your cardiology workflow with our team before committing to a build. Tell us what you are connecting, the data that must move and how the hospital is set up today.
ECG management in depth
ECGs are deceptively complex to integrate. Unlike a static image, an ECG is a waveform with both a visual representation and underlying measurement data, and it moves through a confirmation workflow before it is final. A cart captures the tracing, the waveform is stored, the study appears in a cardiologist's queue to be over-read and confirmed, and only then is the result authoritative in the chart.
An integration that treats an ECG like a simple document misses the confirmation step and the structured measurements, both of which matter clinically. Handling the waveform, the measurements, and the confirmation state correctly is what separates a real ECG integration from a screenshot in the chart.
Structured reporting and downstream analytics
The reason Cupid is valuable, rather than just a place to attach cardiology PDFs, is its structured reporting. Measurements from an echo or a cath procedure are captured as discrete data, which means they can flow into analytics, quality reporting, and registries such as the cardiology registries many programs submit to. An integration that preserves that structure feeds those downstream uses; one that collapses a report into free text breaks them.
When scoping a cardiology integration, it is worth asking early which structured measurements have to survive the journey, because that decision shapes how you read from Cupid and the modules around it.
Remote cardiac monitoring and connected devices
Cardiology has more connected devices reaching into the home than almost any specialty: implantable monitors, wearable patches, and remote blood-pressure programs all generate data that clinicians want in context. The integration problem mirrors the one in ambulatory remote monitoring: the raw stream is large, and the clinical value is in the events and trends, not every sample. A cardiac remote-monitoring integration earns its place by surfacing the actionable findings into the cardiology workflow and leaving the rest accessible but out of the way. Done well, it extends the cardiovascular record beyond the hospital walls without drowning the heart team in data.
How we approach Epic Cupid work
Healthcare is the only industry we work in, and we have built EHR integrations and HL7 interfaces for healthtech startups and hospital teams, across hospital EHRs and ambulatory systems such as eClinicalWorks (see our eClinicalWorks integration guide). We understand the CVIS-versus-PACS split, the device and waveform data flows, and the FHIR resources a cardiology app needs to read.
We build to HIPAA requirements, sign BAAs and are ISO 27001:2022 certified, which matters when cardiac device data is in scope. The pattern we see is that cardiology integrations succeed when the device specifics, the standards, and the structured-reporting requirements are designed together from the start.
Why cardiology integrations reward specialists
Cardiology sits at an unusual intersection of devices, images, waveforms, and structured measurements, and few of those behave like ordinary chart data. An echo study produces images and discrete measurements; a cath procedure produces a structured log and inventory usage; an ECG produces a waveform that has to be over-read before it counts. A generalist integration team can move data, but moving it without losing the structure, the confirmation state, or the measurement detail takes familiarity with how cardiology systems actually work. This is why cardiology projects reward teams that have done them before: the failure modes are specific, the device vendors each have their quirks, and the difference between a working integration and a frustrating one is in the details that only show up under real clinical use. Scoping with that reality in mind, and budgeting for device-by-device testing, is what keeps a Cupid integration on track.
Where to start
List the cardiology data and devices your project touches: cath lab logs, echo measurements, ECG waveforms, or an app reading results. That scope tells you which standards and which systems, Cupid, the devices, the PACS or VNA, you have to integrate with. From there, the most reliable approach is to prove one device or one study type end to end, confirm the structured data and confirmation workflow survive the trip, and only then extend to the rest of the cardiology estate. That staged path keeps a complex cardiology rollout predictable.
If you want help scoping or building a Cupid or cardiology integration, see our Epic integration services, or reach out to talk through your cardiology workflow, the devices in play, and the structured data you need to preserve.
Related guides
Plan your cardiology integration before committing to a build.
Tell us which device or application you are connecting, the data that must move and your hospital’s current setup. Discuss interface options, access dependencies and an end-to-end validation plan.
Frequently Asked Questions
What is Epic Cupid?
What does Epic Cupid manage?
How does cardiology device data get into Epic Cupid?
What standards are used in Epic cardiology integration?
What is the difference between Cupid and Radiant?
