Epic Bridges Integration

What is Epic Bridges integration?

Epic Bridges integration means exchanging data with a hospital's Epic system through interfaces configured in Bridges, the Epic module that health systems use to build, run and monitor their interfaces. Most Bridges interfaces send or receive HL7 v2 messages for admissions, orders, results, scheduling and charges, and the hospital's own analysts build the Epic side.

Bridges lives inside each customer's Epic installation. An outside vendor does not log in to it. The vendor's work sits on the other end of the connection: an endpoint that receives or sends messages, maps them into the product, and answers with accurate acknowledgments.

Many hospitals also run their own interface engine between Bridges and outside systems. In that case your product connects to the engine, and the engine team becomes a second party to every test and every change.

Who builds which part of a Bridges interface?

Everything inside Epic is configured by hospital staff, and everything past the connection point is the vendor's own work. Knowing who owns each piece prevents weeks of waiting on a task nobody picked up.

• Hospital Bridges analyst: Configures the interface in Bridges, including which events trigger messages, the field mapping out of Epic and any filters.
• Hospital interface engine team: Routes and transforms messages between Bridges and outside systems, and runs the connection to the vendor.
• Hospital security and network team: Approves the VPN or private link, firewall rules and the vendor security review.
• Clinical and operational owners: Decide which orders should produce a message, who acts on returned results and what happens during downtime.
• Vendor engineering team: Supplies the interface specification, builds the listener or sender, maps data into the product, handles acknowledgments and supports every test cycle.
• Vendor product owner: Confirms the workflow at each site and signs off that the data in the product matches what clinicians see in Epic.

Ask for one named contact for each hospital role at the start. Interface work stalls most often while a question waits for an owner, not while code is being written.

Which HL7 v2 feeds run through Bridges?

Bridges handles the operational HL7 v2 feeds that move events between Epic and other systems. open.epic lists the interface types Epic publishes specifications for, including incoming and outgoing patient administration, orders and results interfaces.

• ADT, patient administration: Registrations, admissions, transfers, discharges, updates and merges, so the product knows who and where the patient is.
• ORM and OML, orders: New, changed and cancelled orders sent to a lab, imaging or device system.
• ORU, results: Lab results, device readings or reports sent back into Epic, or out of Epic to an outside system.
• SIU, scheduling: Appointment bookings, reschedules and cancellations.
• DFT, charges: Financial transactions from an outside system into Epic billing.
• MDM, documents: Notes and documents with their status, for example a transcribed report.

Each feed has its own specification, and each hospital configures it differently. A results interface that files cleanly at one site can need new code mappings, new identifiers and a different order-matching rule at the next. Ask early whether the site sends the feed directly from Bridges or through its own engine, because that decides who changes a filter when a new event type is needed.

How does a Bridges interface project run?

A Bridges interface project runs in five stages, and the hospital's queue sets the pace of each one. The vendor's work runs alongside the hospital's at every stage.

• 1. Request: The hospital adds the interface to its project list. Both sides agree the message types, events, facilities and fields, and start the security review and business associate agreement.
• 2. Specification: The vendor shares its interface specification. Both sides compare it with Epic's specification for that interface type, then agree field mappings, code sets, identifiers and acknowledgment rules.
• 3. Connectivity: The network team sets up the link, usually MLLP over a VPN or private connection, and both sides prove a test message and an ACK can cross it.
• 4. Testing: The Bridges analyst builds the Epic side in a test environment. Both sides run unit, integrated and end-to-end tests with test patients, covering new, updated, cancelled and merged records.
• 5. Go-live: The interface moves to production with a cutover plan. Both sides watch queues, errors and acknowledgments, with named contacts for the first weeks.

Build the vendor endpoint to replay stored messages. When a mapping problem appears in testing, a replay through corrected code costs minutes, while a fresh round of hospital test messages can cost a week of queue time.

Expect the hospital to ask for evidence at each gate, such as test results signed by both sides before the production build and a cutover checklist with rollback steps. Keep those documents per site, because the next hospital will ask for the same ones.

When should a product use Bridges instead of Epic's FHIR APIs?

Use Bridges and HL7 v2 when the product needs to hear about events as they happen, such as every admission, every new order or every result. Use Epic's FHIR APIs when an app or a job needs to ask for data, for example the record of the patient a clinician has open.

The certified FHIR API under 45 CFR 170.315(g)(10) is a read API. ASTP/ONC states that it covers read services and excludes write capabilities. Epic publishes additional FHIR APIs on Epic on FHIR, and some of them create data, so writing through FHIR depends on which APIs the hospital enables for your app.

FHIR does define subscriptions for change notices. Whether a given Epic organization offers one for your event is a question to put to that organization in writing. Until it confirms, plan event feeds on HL7 v2 through Bridges.

Many products use both paths: an HL7 v2 feed for events and a SMART on FHIR app for work inside the chart. Keeping a separate owner and test script for each path stops a change to the feed from breaking the app, or the other way round.

Rules that apply to an Epic interface

An interface that carries patient data is a channel for ePHI, so the HIPAA rules apply to the connection, the vendor's message store and its logs. These facts are worth having in the interface specification and the security review.

• open.epic publishes Epic's HL7 v2 interface types with technical specifications, including incoming and outgoing patient administration, orders and results interfaces.
• ASTP/ONC describes the 45 CFR 170.315(g)(10) Standardized API as read services for single and multiple patients that specifically exclude write capabilities.
• For remote monitoring vitals, Epic on FHIR describes two filing routes, an HL7 v2 interface or the Observation.Create API, and the second is a write API outside the certified read API.
• For the vendor endpoint, 45 CFR 164.312 makes audit controls mandatory and leaves transmission encryption addressable, which in practice means encrypting the MLLP link or documenting an equivalent control such as the VPN.
• A vendor that receives PHI to perform a service on behalf of a covered entity is a business associate under 45 CFR 160.103 and needs a contract meeting 45 CFR 164.504(e). A disclosure to a provider for the patient's treatment does not need one under 45 CFR 164.502(e).

The business associate question depends on the role, not on the interface. A device company that monitors patients for the hospital is usually a business associate. A specialist practice that receives a referral to treat the patient usually is not.

What to have ready before the hospital's kickoff

Arriving at the first hospital call with these items shortens the queue more than any later effort. Use the list as a readiness checklist.

• Interface specification: Every segment and field you read or send, required or optional, code sets, examples and your error responses.
• Listener or sender: An HL7 v2 endpoint over MLLP that validates, de-duplicates on the message control ID and stores raw messages for replay.
• ACK behavior: AA only after your write commits, AE or AR with a reason when it does not, and a written agreement on what the hospital engine does with each.
• Identifier plan: Which identifiers you need (MRN with its assigning authority, enterprise ID, encounter number) and how merges are handled.
• Mapping layer: Per-site configuration for identifiers, code sets and local values, so the second hospital is a configuration change.
• Test scripts: New, updated, cancelled, merged and transferred records, plus unusual characters and a downtime resend.
• Security package: Your security questionnaire answers, network requirements and the draft business associate agreement.
• Operations: Monitoring for errors, queue depth and silence, a downtime and resend procedure, and named support contacts.

How Agnotic can help

Bridges projects are won or lost on the vendor's readiness when the hospital's analyst finally has time. Agnotic Technologies builds that vendor side: HL7 v2 listeners and senders over MLLP, acknowledgment handling, replayable message stores, per-site mapping, test scripts for updates, cancels and merges, and monitoring the hospital team can see.

Agnotic also builds the FHIR side when the product needs it, so the event feed and the in-chart app are designed together rather than as two separate projects.

Sources

• open.epic: Explore by interface type (HL7 v2 interface specifications)
• Epic on FHIR: API specifications
• HL7 International: HL7 Version 2 product suite
• ASTP/ONC: Standardized API for patient and population services, 45 CFR 170.315(g)(10)
• 45 CFR 164.312: Technical safeguards
• 45 CFR 164.502(e): Disclosures to business associates
• 45 CFR 164.504(e): Business associate contracts