EPIC EHR (HL7)
EPIC·AE_HSc_EPICIntegrationGuide
Overview
The EPIC integration links AlertEnterprise with EPIC EHR systems via HL7 v2 messaging — the standard interoperability protocol in US healthcare. The integration consumes patient + provider events from EPIC and surfaces them into AE for downstream identity, access, and visitor workflows. Common in healthcare-vertical deployments and at fin-services / mixed-use campuses where healthcare-affiliated facilities are part of the access-control envelope.
Architecturally distinctive vs. the standard AE connector pattern: this is an HL7 message integration with field-mapping driven by HL7 segment locators (e.g., patientFirstName ← /PID-5-2, medicalRecordNumber ← /PID-3-1) rather than a REST / SDK provisioning model. Configuration is HL7-field-mapping centric.
Architecture
Composed from this connector's actors + edges. Trust zones are color-coded; trust crossings render as thicker lines.
Authentication
1 method supported
HL7 v2 messages are typically delivered over MLLP — a TCP-based framing protocol — between an EPIC interface engine and AE's HSC Application Agent. Authentication at the transport layer is typically network-zone based (segregated VLAN, firewall ACL) rather than per-message credentials. TLS-MLLP is recommended where supported.
Prerequisites
Everything that must be in place for this connector to work, with the owner who's responsible.
EPIC interface engine configured to send HL7 messages to AE
customerCustomer's EPIC deployment requires an outbound interface (typically configured in Bridges or via Cloverleaf) sending HL7 messages to AE's HSC Application Agent endpoint over MLLP / TLS-MLLP.
HSC Application Agent Server configured to receive HL7
aeAE's HSC Application Agent must be configured with the appropriate HL7 listener port + protocol (MLLP / TLS-MLLP) and field-mapping configuration.
HL7 field-mapping spec
jointThe customer-specific field mapping (which HL7 fields populate which AE attributes) must be agreed and configured before message exchange begins.
Known limitations
Documented constraints to set customer expectations before deployment.
Inbound-only HL7 v2 today
informationalThe integration is documented as inbound HL7 v2 consumption. Outbound HL7 (AE → EPIC) and FHIR R4 are not in scope of the current guide.
Patient data is PHI under HIPAA
criticalAll inbound data is Protected Health Information under HIPAA. AE-side storage, audit, and access-control configuration must satisfy the customer's HIPAA posture (BAA, encryption-at-rest, audit logging, minimum-necessary access).
Data fields
6 fields mapped between AE Guardian and the vendor system.
| AE field | Vendor field | Description | Direction | Required |
|---|---|---|---|---|
| patientFirstName | HL7 /PID-5-2 | Patient first name — extracted from the HL7 PID segment, field 5, component 2. | inbound | no |
| patientLastName | HL7 /PID-5-1 | Patient last name — PID segment, field 5, component 1. | inbound | no |
| medicalRecordNumber | HL7 /PID-3-1 | MRN — PID segment, field 3, component 1. Primary identifier for downstream AE matching. | inbound | yes |
| controlSequenceNumber | HL7 /PID-18 | Account / control sequence number. | inbound | no |
| alias | HL7 /PID-9-1 | Patient alias name. | inbound | no |
| patientRoom | HL7 (location segment — per deployment mapping) | Patient room / location — used for downstream visitor / access workflows. | inbound | no |
- src/connectors/epic/source.pdf — p5 — Chapter 2, HL7 Field Mapping
- src/connectors/epic/source.pdf — p17 — Chapter 3, HL7 Message Codes
- src/connectors/epic/source.pdf — p13 — HSC Application Agent Server Configurations