HL7 FHIR R4 has been adopted as the dominant data exchange standard for EHR interoperability, and cardiac device monitoring is among the use cases where structured data exchange offers the most clinical value. For EP clinic staff managing ICM patients, the relevant question is not whether FHIR is a good idea in principle — it clearly is — but what the standard actually specifies for device observation data, where current implementations fall short, and what a realistic integration looks like for a clinic using Epic or Cerner.
FHIR R4 provides two primary resources for implanted device data. The Device resource describes the physical device: manufacturer, model, serial number, UDI, implant date, and patient association. The DeviceMetric resource describes a measurement capability of a device — for example, a LINQ II's AF detection function or its pause threshold setting. In practice, most cardiac device monitoring integrations focus on the Observation resource rather than DeviceMetric for transmitting actual clinical findings, because Observation has a more mature implementation ecosystem and maps more directly to what the receiving EHR can consume.
The FHIR Observation resource carries a coded observation type (using LOINC or SNOMED codes), a subject reference (the patient), a device reference, an effective date-time, and a value — which can be a quantity, a codeable concept, a string, or several other types depending on what is being reported. An AF burden observation from a Confirm Rx transmission, expressed in FHIR R4, would look something like: observation type = LOINC 93241-4 ("AF burden"), value = 2.4%, unit = percent, effective period = the monitoring window, device = reference to the patient's Confirm Rx Device resource.
LOINC has expanded its cardiac device monitoring panel substantially in recent years. Relevant codes for ICM telemetry findings include:
Coverage for ICM-specific metrics is reasonable for the major arrhythmia summary statistics, but EGM waveform data, artifact classification results, and composite risk scores are not covered by existing LOINC codes. These require either local extension codes — FHIR R4 allows extension elements — or transmission via narrative text fields, which are not structured and cannot be queried or aggregated.
Epic's Cardiac Device Module supports structured import of remote monitoring data through two pathways. The first is the Implantable Device module under the Orders or Results section, which accepts structured observations mapped to Epic's internal cardiac device flowsheet rows. The second is through Epic's Device Observation Import (DOI) interface, which can receive incoming FHIR Observation bundles and map them to flowsheet entries using a site-configurable mapping table.
The practical challenge with Epic integration is that the mapping between incoming FHIR Observation codes and Epic flowsheet rows requires configuration at the site level. A clinic receiving FHIR data from an Implansense API endpoint needs an Epic analyst to map each LOINC code to the correct flowsheet row, verify the unit handling (percent vs. ratio vs. minutes), and configure the interface engine (typically Rhapsody or InterSystems HealthShare) to route the incoming bundles appropriately. This is a one-time implementation project, not a plug-and-play connection.
Once configured, the value is substantial: AF burden, pause counts, and episode summaries appear directly in the patient's cardiac device flowsheet alongside in-clinic interrogation data, without the coordinator manually transcribing from the monitoring platform PDF. The physician can see the device monitoring history in the same view as the in-office visit data.
Cerner's approach to cardiac device data integration runs through its Cardiology module, which supports structured device follow-up documentation. Cerner's FHIR R4 support is available through its Ignite API platform, and the Cardiology module has specific support for device observation import via structured message types. The implementation complexity is similar to Epic: the mapping between observation codes and Cerner documentation fields requires site configuration, and the interface routing requires coordination with Cerner support or an implementation partner.
Cerner practices that have completed the integration report consistent results: remote monitoring summaries appear in the cardiac device follow-up encounter template with structured fields populated, reducing documentation time and improving the accuracy of the monitoring history record.
Structured FHIR integration addresses the documentation and data availability problem. It does not address the transmission review and clinical triage problem. Even with a complete FHIR pipeline delivering AF burden and pause counts directly into the EHR, the coordinator still needs to review the original transmission, assess EGM quality, identify artifact, and determine whether the findings require escalation before the observation is worth documenting. FHIR ensures the documentation ends up in the right place in the structured record. The clinical judgment that precedes documentation is a separate workflow layer.
Implansense approaches the integration question accordingly: the clinical review and classification layer is distinct from the FHIR export layer. The coordinator reviews transmissions in the Implansense interface, and the reviewed, classified findings are exported to the EHR via FHIR Observation bundles, carrying both the original manufacturer measurements and Implansense's artifact-adjusted values with the relevant LOINC codes. The EHR receives structured data that reflects a reviewed finding, not a raw device classification that has not been assessed for artifact or clinical context.
For EP clinics evaluating whether to invest in FHIR-based cardiac device data integration, the technical standard is mature enough to support reliable data exchange for the core arrhythmia summary metrics. The implementation project is real, but it is scoped and achievable. The return is a structured monitoring record that persists in the EHR without manual transcription and supports longitudinal trend queries that are not currently possible from PDF attachments.
