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 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.
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 30+ healthtech startups and hospital teams. We understand the CVIS-versus-PACS split, the device and waveform data flows, and the FHIR resources a cardiology app needs to read.
Our work is HIPAA-compliant by default, with SOC 2 and ISO 27001 behind it, 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.
