Wiring the Clinical Record

Integration between Epic, GE Centricity, and the document systems in between

A field guide to the standards, the systems, and the work

Jason Newell

June 2026

Contents

Part I The problem the interfaces solve 1

Part II The vocabulary 2

II.1 Messages: HL7 version 2 2

II.2 Documents: CDA and C-CDA 3

II.3 The API generation: FHIR, SMART, OAuth, CDS Hooks 3

II.4 Images: DICOM, PACS, VNA 3

II.5 Identity and the profiles that move records: IHE 4

II.6 The code systems 4

II.7 The infrastructure and the rules 4

Part III The systems 4

III.1 Epic, and why there is no single Epic 4

III.2 The several things called Centricity 5

III.3 Document and content systems 6

Part IV The integration patterns 6

IV.1 The HL7 v2 interface, the workhorse 7

IV.2 FHIR and SMART on FHIR, the modern read path 8

IV.3 Document and record exchange 9

IV.4 Imaging 9

IV.5 The engine in the middle 9

IV.6 Custom extracts out of Epic 10

Part V The EHR as a headless CMS 10

Part VI How a project actually goes 12

Part VII The tradeoffs, pathway by pathway 13

Part VIII What does not close 15

Appendix A Glossary 15

Appendix B Sources and further reading 16

Part I The problem the interfaces solve

A potassium result comes back high. It exists, for the moment, only inside a lab analyzer in a basement, a number with a units label and a timestamp. The patient is three floors up. The clinician who ordered it is somewhere between two other patients. Between that number and the moment it changes what someone does, there is a gap, and the gap is the whole subject of this guide.

Nothing about the result is hard. The chemistry is solved. The hard part is moving the number to the one chart, out of the hundreds of thousands a health system holds, where it belongs, attached to the right patient, in a form the receiving system will accept, fast enough to matter, and with proof it arrived. That is integration. It is not the glamorous part of healthcare technology, and it is where most of the work actually lives.

We talk about electronic health records as if each were a single thing you could point to. There is no single Epic. Every hospital that runs Epic runs its own copy, configured by its own analysts, with its own data, its own network rules, and its own list of which interfaces are switched on. The same holds for every other platform. An application that reads from one Epic was not built to read from all of them. It was built to read from one, and the next site is a new project wearing the last one's clothes.

So the question is never whether something integrates with Epic. The question is how, with which standard, at which site, and who signs off.

This guide walks the ground in order. The vocabulary first, because the field drowns newcomers in acronyms. Then the systems themselves, Epic and the several things that have been called Centricity. Then the handful of patterns nearly every integration turns out to be. Then a unifying way to see all of it. Then how a real project moves, and finally the honest tradeoffs, pathway by pathway.

Figure 1. The clinical integration landscape, where the system of record sits behind an interface layer and the standards live on the wires.

Part II The vocabulary

The acronyms are not decoration. Each names a real boundary where one system hands data to another, and most arguments about integration are really arguments about which boundary you are standing on. Here are the families that matter.

II.1 Messages: HL7 version 2

HL7 is both an organization, Health Level Seven International, and the family of standards it publishes. When an interface analyst says an HL7 feed, they almost always mean HL7 version 2, the pipe-and-caret messaging format that has carried clinical events between systems since the late 1980s and still carries most of them. A v2 message is a short burst of text fired the instant something happens, built from segments, each a line beginning with a three-letter code.

MSH is the header, naming the sending and receiving systems and the message type.

PID carries patient identity. OBR names an order, and OBX carries a single observation or result.

The message types are a vocabulary of their own. ADT announces admissions, discharges, and transfers, the heartbeat of patient movement. ORM and its newer cousins carry orders. ORU carries results. SIU carries scheduling. MDM carries documents and their status. DFT carries charges. A v2 interface usually rides MLLP, a thin wrapper over TCP that marks where each message starts and stops, and the receiver answers every message with an ACK so the sender knows it landed. HL7 version 3, an XML reimagining from the 2000s, never displaced v2 in messaging and survives mainly through one descendant, the document standard below.

II.2 Documents: CDA and C-CDA

A message is an event. A document is a snapshot. The Clinical Document Architecture, CDA, is an XML format for a whole human-readable clinical document: a discharge summary, a progress note, a continuity-of-care record. Consolidated CDA, C-CDA, is the tightened American profile that pins down which templates and codes a conforming document uses, so a summary leaving one vendor can be read by another. When a record crosses from one organization to another, it usually crosses as a C-CDA document, not as a stream of messages.

II.3 The API generation: FHIR, SMART, OAuth, CDS Hooks

FHIR, Fast Healthcare Interoperability Resources, pronounced fire, is HL7's modern standard and the first one that feels like the rest of the software industry. It is a REST API: you ask for a Patient, an Observation, a MedicationRequest, a DocumentReference, each a defined resource, and you get back JSON over HTTPS. The version nearly everyone builds against today is R4. SMART on FHIR is the layer that lets an outside app launch inside the EHR and read data with the user's permission, using OAuth 2.0, the same authorization handshake that lets a website sign you in with another account, narrowed by scopes that say exactly which resources the app may touch. CDS Hooks is a companion standard for decision support, calling an outside service at the moment a clinician places an order so it can return a warning or a suggestion. Bulk, or backend, FHIR moves whole populations at once for analytics rather than one patient at a time. USCDI, the United States Core Data for Interoperability, is the government's list of data classes a certified system must expose this way.

II.4 Images: DICOM, PACS, VNA

Pixels travel separately from text. DICOM is the standard for medical images and the metadata stapled to them, the format every scanner, viewer, and archive speaks. A PACS, picture archiving and communication system, stores and serves those images to radiologists. A VNA, vendor-neutral archive, is a store meant to outlive any one vendor's viewer. The order for an image and the report that comes back still travel as HL7 v2; only the pixels are DICOM.

II.5 Identity and the profiles that move records: IHE

IHE, Integrating the Healthcare Enterprise, does not invent standards so much as nail down how to combine them for a specific job. Its profiles are the plumbing of cross-organization exchange. XDS, Cross-Enterprise Document Sharing, defines a registry that holds metadata about who has which documents and a repository that holds the documents themselves. PIX and PDQ reconcile patient identity across systems that each assigned their own medical record number. XCA stretches the same idea across organizational lines. These are the gears inside a health information exchange.

II.6 The code systems

Even when two systems agree on the format, they have to agree on the words. SNOMED CT codes clinical findings and procedures. LOINC codes lab tests and measurements. ICD-10 codes diagnoses. CPT codes procedures for billing. RxNorm codes medications. An interface that does not map these correctly will deliver a result the receiving system files under the wrong test, which is worse than no result at all.

II.7 The infrastructure and the rules

An interface engine sits in the middle of all this. Mirth, now NextGen Connect, along with Rhapsody, Cloverleaf, and Corepoint, are the engines that receive messages, transform them, and route them onward, so that twenty systems can each speak their own dialect to one hub instead of to each other. An HIE, health information exchange, is the regional or national network that connects organizations. TEFCA, the Trusted Exchange Framework and Common Agreement, is the federal effort to connect the exchanges to each other through certified hubs called QHINs. Over all of it sits HIPAA: protected health information moves only under a business associate agreement, only the minimum necessary, with access logged, and information-blocking rules now penalize a system that hoards data a patient or clinician is entitled to.

Part III The systems

III.1 Epic, and why there is no single Epic

Epic runs a large share of American hospitals, by most counts more than forty percent of acute-care beds, and a great deal of integration work is Epic integration work for that reason alone. Inside, Epic keeps its live operational data in Chronicles, a hierarchical database tuned for the speed a busy floor demands. That data is copied each night into Clarity, a relational reporting database, and onward into Caboodle, a data warehouse, with the analytics tooling Epic calls Cogito on top. The distinction matters: real-time reads and writes touch Chronicles through Epic's interfaces, while analytic extracts come from Clarity and Caboodle, hours behind but easy to query.

On the integration surface, Bridges is the module that runs HL7 v2 interfaces, and it handles an enormous volume of admission, order, and result traffic across Epic's installed base. Interconnect is the web-services server that exposes Epic's FHIR APIs and other real-time services. Care Everywhere is Epic's record-exchange network, the thing that pulls an outside C-CDA into the chart. MyChart is the patient portal. Beaker is the lab system, Cosmos the de-identified research dataset, and Hyperspace, now moving to the Hyperdrive client, is the application clinicians actually look at, the frame a SMART app launches inside.

For outside developers, Epic's program was for years called App Orchard. It is now Epic Vendor Services, with products listed in a marketplace called Epic Showroom and registered through Connection Hub, organized into tiers. Epic exposes on the order of hundreds of FHIR R4 endpoints across dozens of resource types, with the USCDI data set as the floor, and participates in national exchange as a QHIN through Epic Nexus.

Program names and figures in this space change often. Treat the specifics here as current to the middle of 2026, and check them before quoting them in anything that has to be right.

Figure 2. Where a custom extract comes from, with real-time reads and analytic pulls leaving the EHR by different doors.

III.2 The several things called Centricity

Centricity is not one product, and the history is itself a lesson in integration, because the pieces went to different owners and now speak different languages. Centricity began as a family of GE Healthcare products spanning ambulatory records, practice management, revenue cycle, and imaging. In 2018, GE sold the ambulatory and revenue-cycle line to Veritas Capital, which spun it into Virence Health and merged it into athenahealth. Centricity Business, the revenue-cycle product, became athenaIDX, and the ambulatory record line was folded into athenahealth. GE HealthCare, since 2023 an independent public company, kept the imaging line.

So when someone says they need to integrate with Centricity, the first question is which one. The imaging Centricity, still a GE HealthCare product, means Centricity PACS, the Centricity Universal Viewer, the Centricity Enterprise Archive, and Centricity RIS, sitting now beside newer platforms like True PACS and the Datalogue vendor-neutral archive. It speaks DICOM for images and HL7 v2 for orders and results, with IHE profiles for sharing. The ambulatory Centricity, now an athenahealth concern, speaks HL7 v2 and, increasingly, FHIR, like any other ambulatory record. The same brand name points at two integration problems with almost nothing in common.

III.3 Document and content systems

Between the record and the archive sits a third category that is easy to forget: the systems that hold scanned forms, faxes, outside records, signed consents, and the long tail of paper that clinical work still generates. These are enterprise content management systems, sometimes purpose-built clinical document repositories. They usually arrive in an integration either as the receiver of an HL7 MDM feed, which announces and indexes a new document against a patient and encounter, or as a participant in document exchange, publishing and consuming C-CDA through the XDS pattern. A document does not need to live inside the EHR to be reachable from it. It needs an index entry the EHR can resolve.

Part IV The integration patterns

Almost every integration is a variation on one of a few patterns. Learn the shapes and most projects stop being surprising.

IV.1 The HL7 v2 interface, the workhorse

This is still the most common integration in healthcare, and the least discussed, because it is old and it works. A source system, a lab analyzer, a registration desk, a scheduling package, emits a v2 message the moment an event happens. The message lands in an interface engine, which transforms it, renaming the field the source calls one thing into what the destination expects, mapping the local code to the standard one, and routes it onward to Epic Bridges, which files it into Chronicles. The receiver answers with an ACK. When people say an interface is down, they usually mean the acknowledgements stopped coming and messages are piling up in a queue.

Figure 3. How an HL7 v2 result reaches the chart, routed and transformed along the pipe and acknowledged on the way back.

IV.2 FHIR and SMART on FHIR, the modern read path

When the need is to read patient data into an outside application, or to run an app inside the chart, FHIR is the path built for it. A SMART on FHIR app launches from inside the chart with the current patient already in context, redirects to Epic's authorization server to request the scopes it needs, receives a token once the clinician and the site's rules allow it, and then queries the FHIR API for the resources it was granted. The app renders in a frame inside the chart and feels native. For population-scale work, backend FHIR moves many patients at once with no human in the loop. For decision support, CDS Hooks lets an outside service speak up at the moment of an order. The limit worth knowing early: FHIR is excellent for reading and uneven for writing, and many write-heavy or event-driven workflows still fall back to v2.

Figure 4. A SMART on FHIR app launching inside the chart, with the OAuth handshake that lets an outside app read patient data by permission.

IV.3 Document and record exchange

Moving a whole record across an organizational boundary is a different pattern with different gears. The sending system publishes a C-CDA document, registering its metadata with a registry and storing the document itself in a repository. The receiving system queries the registry to learn what exists, then retrieves the document from the repository. Patient identity is reconciled first, through PIX and PDQ, so both ends agree whose record this is. Epic's Care Everywhere is a large-scale version of this idea, and TEFCA is the attempt to make every such network reach every other one.

Figure 5. Sharing a document, not just a message, through the registry and repository pattern behind cross-organization exchange.

IV.4 Imaging

Imaging splits cleanly. The order and the eventual report travel as HL7 v2, the same as any other order and result. The pixels travel as DICOM, from the modality to the PACS or VNA, and a viewer, often launched from inside the chart with the study already selected, shows them to the radiologist. Integrating imaging means wiring both halves and making sure the accession number that ties them together survives the trip. Lose it, and the study orphans: invisible until someone goes looking for an image the chart insists should be there.

IV.5 The engine in the middle

The reason an interface engine almost always sits between systems is combinatorial. Twenty systems wired directly to each other are a tangle that grows with the square of the count. Twenty systems each wired to one engine grow in a line. The engine is also where transformation, monitoring, alerting, and replay live, the place an analyst watches when something stalls and the place a message can be re-sent after a fix.

IV.6 Custom extracts out of Epic

When an organization wants its own data out of Epic for a purpose no standard interface covers, the path depends on whether the need is live or analytic. Live data leaves through Interconnect, FHIR, and Bridges, in real time and under the same governance as any other interface. Analytic data leaves through Clarity and Caboodle, a night behind but shaped for reporting. The recurring trap is treating either as a one-time build. Because every Epic is its own instance, a custom extract is validated and enabled site by site, and a thing that worked at one hospital is a fresh project at the next.

Part V The EHR as a headless CMS

Step back from the wires and a shape appears that the rest of software already named. A headless content management system keeps content in a repository and serves it through an API, with no presentation layer of its own. The thing that renders it, the website, the mobile app, the kiosk, is a separate, swappable front end. The content does not know or care which head is asking.

Healthcare has been building toward the same shape without using the word. The system of record holds structured data and points at content it does not store. The content, the images, the signed documents, the reports, lives in repositories, a VNA, a document store, a PACS, reachable by reference. FHIR turned the record itself into an API: ask for a resource, get JSON, render it however you like. The chart in Hyperdrive, the radiology viewer, the SMART app in its frame, the patient portal, a registry pulling a cohort, these are heads. Each renders the same underlying content. None of them owns it.

Figure 6. One content store, many heads, with content served by API and reference and the EHR just one head among several.

Read this way, several earlier pieces line up. The pointer-not-copy rule from imaging is the headless rule exactly: the head holds a reference, the body holds the bytes. A custom path out of Epic is not an escape from the EHR, it is a new head attached to the same content, under the same identity and the same governance. SMART on FHIR is the clean case, an outside head launched over the record with the user's permission, interchangeable with the native one. And the federated model is the catch the web version does not have. There is no single API to point a head at. There are hundreds, one per site, each enabled on its own terms.

The lesson is not that healthcare should copy web architecture. It is that the separation was always there, latent in the split between the record and the content, and naming it tells you where the leverage is. Build a better head and you build it once, against an interface that, at every site, resolves to the same few resources. The body is the hard part, and the body is shared.

Part VI How a project actually goes

The technical work is rarely the long pole. The shape of a real integration project looks like this.

• Scope the data, not the systems. Name exactly what moves, in which direction, whether it is real time or batch, and whether you are reading or writing. Most disagreements dissolve once this is written down.
• Choose the pathway. Match the need to the standard built for it before writing any code.

Figure 7. Choosing the integration pathway, matching the thing you need to move to the standard built for it.

• Start the paperwork immediately. The business associate agreement, the security review, and the sponsorship of a real customer site are the slow steps, often months. They run in parallel with everything else only if you start them first.
• Build in the sandbox. Epic and the others publish sandboxes with synthetic patients. Build and validate there before touching anything real.
• Map and transform. This is the unglamorous core. Reconcile identifiers, map every code system, and decide what happens to the messages that do not fit the happy path.
• Test the failures, not just the successes. Confirm the result reaches the right chart, then confirm what happens when an ACK never comes, when a duplicate arrives, when a patient has merged records.
• Go live site by site. The federated model is not a footnote. Each site is its own enablement, its own security posture, its own go-live.
• Monitor and maintain. Interfaces rot. Standards version, endpoints move, an upstream system changes a field. An integration is a thing you keep, not a thing you finish.

Part VII The tradeoffs, pathway by pathway

No pathway is simply best. Each buys something and charges for it. Here is the ledger, pathway by pathway.

HL7 v2 interfaces

FHIR and SMART on FHIR

Document and record exchange

DICOM and imaging

Custom extracts

The honest summary is that the choice is usually between maturity and modernity. HL7 v2 is ugly, verbose, and everywhere; it will carry an event today, at every site, with no app review. FHIR is clean, documented, and partial; it reads beautifully and writes haltingly, and it still has to be enabled one site at a time. Document exchange moves the whole record but not in real time. Custom extracts give you precisely what you want and a maintenance bill to match. And the question of whether to buy an interface engine or wire systems point to point answers itself the moment the third system arrives: the engine costs a license and a skill to operate, and it saves you from a tangle that grows with the square of the count.

Part VIII What does not close

The result in the basement is still just a number.

What decides whether it matters is not the database it came from or the one it lands in. It is the wire between them, the map that renames its fields, the acknowledgement that comes back, the one chart out of hundreds of thousands that it reaches. We spend our attention on the systems because they have names and logos and sales teams. The work has always been in the spaces between them, unglamorous and load-bearing. An assistant that reasons over a chart inherits whatever the reconciliation beneath it got right or wrong, and will read fluently over a record that is quietly mismatched. The hard part was never the reasoning. It was getting the scan, the report, and the patient to agree on who they belong to, and the record only counts as a record once it arrives.

Appendix A Glossary

A compact reference to the terms used above.

Appendix B Sources and further reading

Current-state facts about products, ownership, and program names were checked against the following in June 2026. Specifics in this field change often; verify before relying on them.

open.epic.com. Epic's public developer portal: FHIR APIs, USCDI support, Showroom and Connection Hub.

Epic integration guides, Saga IT and others (2026). Vendor Services and Showroom naming, Bridges and HL7 v2 message types, FHIR R4 endpoint counts.

GE HealthCare, Enterprise Imaging and DICOM conformance pages. Centricity PACS, Universal Viewer, Enterprise Archive, RIS, True PACS, and Datalogue.

Healthcare IT News, Fierce Healthcare, company filings. The Centricity ownership history: GE to Veritas, Virence, athenahealth, and athenaIDX.

HL7 International and IHE specifications. HL7 v2, FHIR, C-CDA, and the XDS, PIX, and PDQ profiles.