A statement of work for a new imaging deployment often lists “PACS integration” as a single line item, priced and scheduled like one task. It isn’t one task. A working system needs three separate integrations, each running on a different standard, each owned by a different vendor’s engineering team, and each with its own way of failing quietly.
A modality sends what it acquires to the PACS over DICOM. The worklist it queries before it scans belongs to the RIS, a second seam running on the same standard. The EHR meets the PACS at the boundary where a signed report and a viewable study have to reach a clinician.
Teams that scope pacs integration as one project usually get the first surface right, because it is the one every vendor demos. The second and third surfaces are where the schedule slips: what each connects, what has to be agreed before it works, how to test it, and where it breaks.
Why PACS Integration Splits Into Three Surfaces
Most imaging deployments run the same three systems. An EHR generates the order and holds the final report. A RIS runs the radiology-specific scheduling and reporting workflow in between. A PACS receives, stores, and distributes the images the exam produces.
Each handoff between those systems runs on its own standard, not a shared one.
| Surface | What crosses it | Standard that carries it |
|---|---|---|
| Modality outward | The image the scanner acquires, and before that the scheduled exam it queries for | DICOM: C-STORE and Storage Commitment to the PACS, a Modality Worklist query to the RIS |
| RIS, at the worklist seam | The scheduled exam the scanner asks for, then later the report | DICOM Modality Worklist, exposed on the RIS side and queried by the modality; HL7 works upstream, into the RIS |
| EHR to PACS or RIS | The order, the signed report, and access to the study itself | HL7 or FHIR for the report; a separate mechanism for image access |
Three handoffs, three standards, three places to test.
Surface One: Modalities, Over DICOM
The connection here is the most literal of the three. A scanner finishes an exam and pushes the resulting images into the PACS over a DICOM store operation. Before acquisition even starts, that same scanner queries the Modality Worklist service the RIS, or a broker in front of it, exposes for the exam it is about to run. Both operations run on DICOM but point at different systems, and DICOM does not connect two systems just because both claim to speak it.
Four things have to be agreed before a modality and a PACS will associate:
- the Application Entity Title, or AE title, each side identifies itself with
- the IP address and port each listens on
- which DICOM service classes and roles each implements
- which transfer syntax they use once connected
DICOM’s own network standard is specific about how exact that negotiation is. An association request carries a calling AE title and a called AE title. The standard states plainly that the calling AE title “identifies the Application Entity (AE) that shall contain the requestor of the A-ASSOCIATE service.” Get either title wrong, and the association is rejected, the standard naming the failure directly: “calling-AE-title not recognized” or “called-AE-title not recognized.”
Transfer syntax is negotiated the same explicit way. Each proposed presentation context carries a list of transfer syntaxes the requesting side is willing to use. The standard limits the outcome on purpose: “only one Transfer Syntax per presentation context shall be agreed to, even though more than one choice of Transfer Syntaxes may have been offered.” A modality that only sends JPEG-compressed pixel data and a PACS that only accepts uncompressed data can both be fully DICOM-conformant and still fail to agree on anything to send.
Reading two conformance statements side by side is not a test. DICOM compliance is self-declared, not certified: a vendor can publish a clean statement and still need middleware for a specific modality.
The real test sends a study end to end: confirm the association establishes, the study lands with metadata intact, and a worklist query returns the correct scheduled exam. Every Imaging Product Has to Speak DICOM covers what a conformance statement has to show to be worth trusting. The .dcm File: What Is Inside a DICOM Object covers what breaks when a study’s metadata is handled carelessly.
The failure mode here is rarely a total outage. More often it is a rejected association nobody notices until a study does not arrive, or a study that arrives readable but tagged incorrectly because nobody confirmed the connection against a real exam. EBM mAIn PACS® publishes its services list on its integrations page: native DICOM C-STORE, Query/Retrieve, Modality Worklist, and Storage Commitment. A modality vendor gets specific services to test against instead of a single adjective.
Surface Two: The RIS, at the Worklist Seam
The second surface is where a common assumption breaks: that the RIS pushes the scheduled exam to the scanner over the same HL7 connection that carries everything else it sends. The RIS does not publish the Modality Worklist over HL7. The RIS, or a broker in front of it, exposes that DICOM service itself, and the modality queries it directly.
HL7 does real work here, but earlier: getting the order into the RIS, from a referring physician, an EHR, or a scheduler working inside the RIS. A second distinction at the seam matters as much: the queue a reader works from, the reading worklist, is not the DICOM Modality Worklist. MWL feeds scheduled-exam data to the scanner before acquisition happens at all. The reading worklist sits downstream, after a study already exists, and it is usually where the PACS and the RIS meet a second time, over the report rather than the order.
What has to be agreed here:
- which HL7 version and local dialect the RIS speaks for order entry
- which system owns the Modality Worklist service
- whether the accession number stays consistent across every system that reads it
- how quickly a cancellation or reschedule in the RIS reaches the worklist a technologist is about to query
Where a Radiology Information System Ends and PACS Takes Over walks that full handoff and its failure modes in depth.
Testing it means placing a real order in the RIS, confirming it appears at the modality’s worklist query, then canceling or rescheduling it and timing how long the change takes to reach the scanner. A worklist that looks correct on day one of a pilot and drifts stale two months in is a far more common failure than one that never worked at all. The supported integration surface on EBM mAIn PACS® stays deliberately the DICOM side of this seam; order entry, scheduling, and the HL7 messaging that carries them into the RIS stay the RIS vendor’s responsibility.
Surface Three: The EHR, for Results and Image Access
The third surface gets scoped last, if it gets scoped as its own line item at all. Testing it last is correct, because it depends on both of the other two already working; going into a build with it unscoped is not. Once a study exists in the PACS, a radiologist signs a report against it. Two separate things then have to reach the EHR: the report itself, and a way for a clinician inside the EHR to open the images.
The report usually travels the same category of standard that carried the order in, most often an HL7 result message, sometimes a FHIR DiagnosticReport resource alongside the older HL7 feed. DiagnosticReport is the resource that carries the findings; ImagingStudy, the resource it often points at, does not. FHIR in Plain Terms: How the Standard Models Clinical Data covers what ImagingStudy holds instead: study metadata and pointers to where the pixel data lives, with DICOM retrieval left to a separate mechanism.
Image access is the part scoping conversations skip, because a signed report landing in the EHR feels like the integration is done. It is not. A referring physician who can read the report but cannot open the study is still going to call the radiology department.
How Medical Image Sharing Works Between Organizations covers the mechanisms in depth. A link-based web viewer launched from the EHR is the common answer for a single referral relationship. At health-system scale, the same problem gets solved with a shared registry instead of a point-to-point link: IHE’s Cross-Enterprise Document Sharing for Imaging profile. That is infrastructure well beyond what most single-vendor integrations need, and not part of what EBM offers in this market today.
Underneath both sits a question neither answers: whether the patient the EHR knows is the same patient record the RIS and PACS are keyed against. Two systems across an organizational boundary, or even two departmental systems in one hospital, do not automatically share a medical record number. IHE built a profile specifically for that reconciliation problem, Patient Identifier Cross-Referencing, targeted at “healthcare enterprises of a broad range of sizes” that need to reconcile identifiers “from multiple Patient Identifier Domains.” Whether a project needs infrastructure that formal or a simpler manual step depends on how many identifier domains are in play, a question worth asking rather than assuming the two patient IDs line up.
Testing this surface means confirming a signed report attaches to the correct patient’s chart, and confirming the image link a clinician clicks resolves to the right study rather than a login screen. Then test the patient registered under more than one identifier: that case exposes whether identity reconciliation was built or just assumed.
EBM’s own HL7 and FHIR integration has been tested in Taiwan; validating it against a specific US EHR is not yet part of what the platform offers in this market today. For image access itself, EBM mAIn PACS® moves studies by QR code, AirDrop, or secure web link, answering the viewer-compatibility half of this surface for a single referral relationship.
Sequencing: What Has to Work Before What
None of the three surfaces test well out of order, and treating them as parallel workstreams is a common way a schedule slips. Modality connectivity comes first, because nothing downstream matters if a study never reliably lands in the archive with correct metadata.
The RIS worklist seam comes second, though not because a worklist query needs the archive path: MWL and C-STORE are separate services, and either can work while the other fails. Testing it second proves the join, that the identifiers a scanner pulled off the worklist arrive intact on the stored study. The reading worklist that follows depends on the study existing at all. The EHR seam comes last, because it depends on a signed report and a correctly stored study both already existing.
That order matters for testing, not just building. When all three integrations go live in the same pilot week, the team ends up debugging three unfamiliar systems at once. Testing each surface on its own first, and only then running a full order-to-report cycle across all three, is faster.
Questions That Expose a Vendor’s Weak Spots
A short set of questions, asked separately for each surface, de-risks a pacs integration more than any general assurance of DICOM or HL7 compliance:
- Which DICOM services and roles does the modality vendor implement, and will they share the conformance statement, not just the claim? DICOM compliance is self-declared, not certified.
- Who owns the Modality Worklist service, the RIS or a broker in front of it, and how fast does a reschedule in the RIS reach it?
- Which HL7 version and local dialect does the RIS speak, and does anything downstream need an interface engine to consume it?
- Which standard carries the signed report back to the EHR, and is that the same mechanism carrying image access, or a separate one?
- How many patient identifier domains exist across the systems in scope, and what reconciles identity across them: a shared cross-reference service, a manual step, or an untested assumption?
A vendor who answers each with a specific mechanism has tested the integration. One who answers with “we’re fully compliant” has told you which surface to test first yourself.
What This Means for Your Integration
Scope a pacs integration as one line item, and the schedule holds until the RIS worklist seam or the EHR handoff surfaces a standard, an identifier mismatch, or an ownership question nobody resolved. Scope it as three integrations, each with its own agreements and its own test, and the project survives contact with the second and third surfaces.
EBM mAIn PACS® meets the first two surfaces on the DICOM side, with C-STORE, Query/Retrieve, Modality Worklist, and Storage Commitment named on its integrations page rather than left as an adjective. For a partner building an OEM or VAR product on that foundation, EBM Fabric™ is the platform-level version of the same architecture. The discipline is the same on all three: agree the specifics before the contract is signed, test each surface alone, then test the chain end to end.