Connecting the Record and the Content

Integrating medical document systems with Epic, and building custom paths out of it

Jason Newell

June 2026

Contents

Part I. The vocabulary you need 1

Part II. Two systems, one patient 2

Part III. The standards that move the data 4

Part IV. The integration patterns 5

Part V. Building custom paths out of Epic 9

Part VI. How a project actually runs 10

Part VII. Where it breaks 11

What does not close 11

A clinician opens a chart. The orders are there, the medications, the note from last week. The scan they need is not. It was taken on a machine in a different building, stored by a different vendor, and it sits in a system that has never heard of the chart now asking for it. Somewhere a report is being dictated about that scan, and in an hour it will have to find its way back into the chart, attached to the right patient, under the right encounter, readable by a person who will never know how it arrived.

This is the ordinary condition of a hospital. There is rarely one system. There is a system that holds the record of what happened, and there are other systems that hold the content the record refers to: the images, the signed documents, the waveforms, the scanned consent forms. The record knows that a chest CT exists. The archive knows what the chest CT looks like. Neither is complete without the other, and the work of joining them is what this article is about.

A note on names before going further, because the names cause real confusion. Centricity is a GE brand, and over the last few years it split. The ambulatory side, the old Centricity Practice Solution and Centricity Business revenue-cycle product, left GE Healthcare in 2018, became Virence, merged into athenahealth in 2019, and the revenue-cycle piece was renamed athenaIDX in 2020. What GE HealthCare still ships under the Centricity name lives in enterprise imaging: Centricity Universal Viewer, Centricity Enterprise Archive, the clinical gateway and XDS registry that surround them. So when someone says “Centricity,” ask which one. For most of what follows, the interesting Centricity is the imaging and archive side, because that is the content repository, and Epic is the record. The patterns hold regardless of vendor.

Part I. The vocabulary you need

Most of the difficulty in this field is vocabulary. The standards are not hard once you know which one carries which thing. Here is the working set.

Part II. Two systems, one patient

Hold two boxes in mind. On one side, the system of record: the EHR, the place a clinician works, the place the legal chart lives. It is built for transactions and workflow, for the act of caring for a patient in real time. It holds orders and results and notes and the patient’s identity, but it does not want to be the warehouse for every gigabyte of pixel data a radiology department produces in a year.

On the other side, the content repository: the PACS, the archive, the document store. It is built to hold large objects for a long time and serve them back fast. It knows nothing about the encounter or the bill. It knows the study, the series, the object, and the identifiers stamped on them.

Figure 1. The record and the content are different systems with different jobs, joined by an integration layer.

The integration layer in the middle is the whole subject. It carries a primary feed in each direction, the solid arrows, where one system tells the other that something happened. It also carries reference traffic, the dashed arrows, where the record points at content it does not store. A scan does not get copied into the chart. The chart gets a pointer, and the pointer resolves to the archive when a clinician clicks it. Understanding which traffic is a copy and which is a pointer saves more grief than any other single idea here.

Part III. The standards that move the data

There is no single wire. A chart is assembled from several formats, each good at one thing, and an integration almost always speaks more than one.

Figure 2. Each standard is good at one kind of payload, and most integrations speak several.

HL7 v2 is the oldest and still the most common. It is a stream of events. A patient is admitted, so an ADT message goes out. An order is placed, so an ORM follows. A result is ready, so an ORU carries it. A document is signed, so an MDM message announces it. The format is ugly and the parsing is fiddly, but it is everywhere, it is fast, and a hospital’s interface engine is mostly HL7 v2 traffic by volume.

DICOM carries images and the study metadata bound to them. It is its own world, with its own network protocols, and the radiology department lives inside it. The EHR rarely speaks DICOM directly. It speaks HL7 to order the study and to receive the report, and it links out to a viewer for the pixels.

C-CDA packages a slice of the chart as one structured document: a care summary, a referral, a discharge summary. It is the unit of exchange when a whole snapshot has to travel between organizations, and it is what most health-information-exchange traffic looked like before FHIR.

FHIR is the modern path. It exposes the chart as discrete resources over a normal web API. You ask for a Patient, an Observation, a MedicationRequest, and you get JSON back. For documents and images, the useful resources are DocumentReference, which is the pointer, and Binary, which is the bytes. FHIR is where new integration goes, but it does not replace the older formats so much as sit beside them.

IHE profiles are the recipes that make repositories interoperate. When two archives have to share documents, XDS defines how one registers a document and another finds it. XDS-I does the same for imaging. PIX and PDQ handle identity, matching a patient across systems that assigned different numbers. XCA reaches across organizational boundaries. IHE is not a new standard so much as a set of agreements about how to use the existing ones the same way.

Part IV. The integration patterns

There is no single right way to connect two systems. There are a handful of patterns, each with a cost, and most real deployments use several at once.

Messaging through an interface engine

The default. Systems do not talk to each other directly. They talk to an engine, and the engine routes, filters, and rewrites. Epic’s engine is Bridges. Many sites also run a third-party engine alongside it.

Figure 3. One engine sits between every system, so each connection is built once.

Pros. One place to see and change every interface. New systems connect to the hub, not to each of the others, so the number of connections grows with the number of systems rather than with its square. Mature, well understood, and the path of least resistance at any large hospital.

Cons. The engine is a single point of failure and a bottleneck for skills. HL7 v2 is loosely specified, so every interface carries site-specific quirks that have to be discovered and mapped by hand. The work is real and it never fully ends.

Imaging exchange with DICOM and IHE

The order leaves the record and the image lands in the archive, and the two have to be reconciled.

Figure 4. An imaging order leaves the record, the image lands in the archive, and the report returns.

The order is placed in the EHR. A modality worklist gives the scanner the patient and order so it stamps the right identifiers onto the study. The modality acquires the images and pushes them to the PACS and the archive. The radiologist reads and signs a report, and an ORU result carries that report back into the chart. The pixels stay in the archive; the chart holds a reference, resolved through XDS-I or a FHIR DocumentReference when someone wants to look.

Pros. Clean separation of duties. The record stays light, the archive does what it is built for, and the image is available to any viewer that can resolve the reference.

Cons. Identity is the whole ballgame. If the accession number or the patient identifier is wrong at the modality, the study orphans, and an orphaned study is invisible until someone goes looking for an image that the chart insists should be there.

Document exchange

Signed documents, scanned forms, outside records. These move as C-CDA documents, as HL7 v2 MDM notices that announce a document exists, or as FHIR DocumentReference and Binary. The notice and the bytes are separate concerns: the notice tells the chart a document is available, and the bytes are fetched on demand.

Pros. A document is a stable, human-readable unit. It survives version changes in the underlying systems better than discrete data does.

Cons. Documents duplicate easily. The same outside summary can arrive three times through three paths and land in the chart three times, and de-duplication is a problem every site solves and never finishes solving.

API-led integration with SMART on FHIR

Instead of moving data into your system, you run inside theirs. A SMART on FHIR app launches inside the EHR with the patient already in context, authorizes through OAuth 2.0, and queries the FHIR API for what it needs.

Figure 5. A SMART on FHIR app launches in context and authorizes through OAuth, and the token stays inside Epic’s flow.

CDS Hooks is the companion pattern. Rather than waiting to be opened, an external service is consulted at defined moments, when an order is placed or a chart is opened, and it can return advice into the workflow.

Pros. The app lives where the clinician already works. No bulk copy of data leaves the building. Read access to the federally required data classes works consistently across Epic sites with little custom configuration, because those resources are mandated.

Cons. The open-API story is narrower than it sounds. Production access needs formal approval, a sponsoring customer, and a security review. Read is far easier than write. Anything that has to change the chart, or anything outside the standard resources, falls back to proprietary interfaces and a longer timeline.

Network exchange

For records that live in other organizations, the path is the exchange network. Epic’s Care Everywhere reaches other systems through Carequality, CommonWell, and now TEFCA, the nationwide framework that went live in late 2023. Epic’s own qualified network, Epic Nexus, is how Epic sites plug into that mesh, and through it an authorized app can reach a patient’s records across organizations rather than integrating with each site one at a time.

Pros. Reach without a point-to-point interface for every partner. The right pattern for cross-organization use cases, payer exchange, and letting a patient pull records from anywhere they have been seen.

Cons. You get what the network exposes, in the form it exposes it, with the latency it allows. Governance, consent, and identity matching across organizations are harder than inside one.

Batch and flat file

The unglamorous path that still moves a great deal of data. Overnight extracts, CSV and fixed-width files, reporting feeds out of Clarity and Caboodle.

Pros. Simple, robust, and the natural fit for analytics, where last night’s data is fine and no live connection is needed.

Cons. Not real time, by definition. A flat-file integration that someone starts treating as if it were live is a familiar way to get hurt.

Part V. Building custom paths out of Epic

The reverse direction has its own shape. When data has to leave Epic for a downstream system, a data warehouse, a registry, a custom application, there are four well-worn routes, and the choice among them is decided by latency, payload, and who owns the pipe.

Figure 6. Four routes out of Epic, chosen by latency, payload, and ownership.

Real-time HL7 v2 feeds through Bridges carry live events with low latency, and they are the right tool when a downstream system needs to know the instant something happens. Web services and APIs, Epic’s Interconnect layer and the FHIR endpoints, handle request-and-response and the write-backs that messaging cannot. Bulk FHIR export, the backend-services flow, is built for cohorts and population data, where you want many patients at once rather than a stream of events. Reporting extracts out of Clarity and Caboodle feed analytics overnight, where no live connection is needed and the data can stay at rest.

What surrounds all four is the gatekeeping, and it is worth saying plainly. Epic’s marketplace is now Showroom, and its basic listing is Connection Hub; the old App Orchard name is retired, and a hospital IT team still asking you to get listed in App Orchard is working from an old map. A Connection Hub listing means you have one live customer connection. It is not a seal of approval. Deeper, proprietary integration runs through Epic’s Vendor Services program. Across all of it, the recurring requirements are a sponsoring customer who wants the integration, a security review the customer runs before anything touches production, and a timeline measured in months, not weeks. The listing review alone runs a couple of months. Plan for it as part of the work rather than a formality at the end.

Pros of going custom out of Epic. You get exactly the path your use case needs, and you are not waiting for a packaged integration that may never come. For population data and analytics especially, the bulk and reporting paths are powerful.

Cons. You inherit the maintenance. Epic’s releases move, the FHIR resources and the federal data floor shift versions, and every custom interface is something your team now owns through all of it. Tokens and credentials stay inside Epic’s flows and are not handed to an outside backend, which is correct security and also one more constraint to design around.

Part VI. How a project actually runs

The order of the work matters more than people expect. Identity and security are not the last steps. They are the early ones, and skipping them to get to code is the most reliable way to lose months.

Figure 7. The order of work, with identity and security before the build, not after.

Scope the use case first, narrowly. What data, which direction, how fresh does it need to be. Then map the data and the identity: which fields, in which code systems, and how a patient in one system is matched to the same patient in the other. This is the master-patient-index question, and it decides whether the whole thing works. Only then choose the pattern from Part IV, because the use case and the identity model should drive that choice rather than a preference for the newest standard.

Build in the sandbox, against test endpoints, never against production. Run the security and compliance review early, because a health system performs its own vendor security review before letting anything connect, and findings from that review can reshape the design. Test against a real validation harness, go live with one customer, and then accept that the last stage, monitoring and support, is permanent. Interfaces drift. Systems upgrade. The integration that worked last quarter fails quietly this quarter, and someone has to notice.

The dashed loop in the figure is the honest part. A security finding or an identity mismatch sends you back to the mapping stage, and it will happen more than once.

Part VII. Where it breaks

Every failure mode here comes from a real outage, not a style preference.

Identity is first and worst. A mismatched patient identifier or a wrong accession number does not throw an error. It silently attaches content to the wrong chart, or to no chart, and the damage is found later, by a person, looking for something that should be there. The master patient index is not paperwork. It is the load-bearing wall.

Semantic mapping is second. Two systems both record a lab result, and they use different code systems, different units, different ideas of what normal means. The message moves fine. The meaning does not, unless someone mapped it by hand and checked it.

Version drift is third. The standards move underneath you. A FHIR version retires, a federal data floor advances, an old API is deprecated on a date that arrives whether you noticed it or not. An integration that is not being maintained is already breaking; it just has not told anyone yet.

Duplication is fourth, and it is mostly a document problem. The same outside record arrives through three paths and lands three times. De-duplication is never finished.

And there is the failure that has a familiar shape to anyone who builds documents as much as systems: the thing that works in test and fails in production, because production has a quirk that test did not, an extra identifier, a different network boundary, a per-site configuration nobody documented. The fix is the same as it ever is. Validate in the environment you will actually launch in, and write down the quirks while you still remember them.

What does not close

You can build every interface correctly and the gap between the record and the content still does not close. It narrows. Integration is not a project that finishes; it is a thing a hospital maintains, the way it maintains the building, because the systems underneath keep moving and the patient keeps needing both halves of their own chart in one place at one time.

This is the layer that any clinical intelligence inherits. An assistant that reasons over a chart is only ever as good as the reconciliation beneath it. Give it a chart where the scan is orphaned, the outside summary arrived three times, and the lab result came in under a code nobody mapped, and it will reason fluently over a record that is quietly wrong. The hard part was never the reasoning. It was getting the scan, the report, and the patient to agree on who they belong to.