Radiology stopped being the only department generating images a long time ago. Cardiology has its echo loops and cath lab angiograms; endoscopy captures still frames and video in every GI and pulmonary procedure. Dermatology and wound care programs photograph a lesion or a healing wound at each visit, ophthalmology runs fundus cameras and OCT, and pathology scans whole slides. Each of those departments picked its own system on its own timeline, usually because that system fit the department’s workflow better than anything radiology already had installed.
Storage capacity is the least of what a VNA archive has to solve. Its actual job is pulling all of those separate systems into one archive, with one patient identity model and one retention policy. That turns out to be as much an organizational problem as a technical one.
Here is what the consolidation problem looks like once it gets past the pitch deck. First, which departments show up with imaging that was never built to leave its own silo. Then, what identity mismatches surface the moment two departments’ patient records sit in the same archive, and what a single retention policy has to reconcile that separate departmental defaults never had to.
Why a VNA Archive Has to Reach Past Radiology
DICOM standards and the integration profiles built on top of them started with radiology in focus, for a straightforward reason: radiology went digital first. By the time other departments caught up, cardiology found it easy to adopt and adapt the same DICOM services, since an angiogram and a CT scan are similar enough as data. Ophthalmology and dermatology had a harder time, because their imaging mapped onto DICOM less naturally. Each of those departments built its own specific solution for viewing, storage, and archiving instead of inheriting radiology’s.
That pattern has a documented history. As digital imaging spread through the 1990s and 2000s into new service lines, each department with a camera or a scanner tended to end up with a single vendor. That vendor provided the whole stack: viewer, storage, and archive together. Three compounding problems followed.
First came vendor lock-in inside each department’s own solution. Second came data silos, which left anyone outside the department with very limited visibility into what it held. Third came separate storage infrastructure per department, which ruled out any shared, centralized storage and the cost reductions that go with it. A product team evaluating a VNA archive today is trying to undo that accumulation, one department at a time.
What Each Department Actually Brings With It
Consolidation sounds like a storage decision until the first non-radiology study lands in the archive and turns out to look nothing like a CT.
DICOM defines a whole family of objects built for images other than radiology’s cross-sectional slices. The standard describes these as “images that are acquired by means of a camera or other sensors that are sensitive to visible or near-visible light.” Endoscopy equipment, operating microscopes, colposcopes, ophthalmology equipment, and digital or video cameras are the typical sources it names.
Pathology gets its own object entirely. A whole-slide image is a multi-frame, tiled structure representing one physical slide at a uniform resolution, frequently as one layer of a multi-resolution pyramid. That lets a viewer zoom from a full-slide overview down to individual cells without reloading the whole file. An archive proven only against radiology studies has yet to be proven against any of this.
Not everything even arrives wrapped in a DICOM object. A dermatology clinic or a wound care program photographs a lesion or a healing wound at every visit. The system doing that may never encode those photographs as DICOM, storing them instead as ordinary image files inside its own departmental record.
Bringing that content into a single archive takes more than pointing the same DICOM Query/Retrieve interface at a new source. It is a decision with three options. Wrap non-DICOM content in a DICOM object on the way in, preserve it in its native format alongside the DICOM studies, or leave it in place and link to it instead of migrating it. Each option has a different cost and a different answer to what “one archive” actually means once it is built.
One Patient, Several Identifiers
Object types are the visible half of the problem. The patient is the half that gets underestimated.
A cardiology system, an endoscopy system, and a pathology system each built before anyone planned to merge them rarely share one patient identifier scheme. The cardiology department’s medical record number may differ from the number the EHR uses. The pathology lab, working from a specimen accession number, may never have carried a patient identifier that lines up with either.
Consolidating departmental archives into one surfaces all of that at once. Every one of those systems has to agree on who a given patient is, or the same person’s studies sit in the archive as a set of disconnected records under different numbers.
The standards level solved this years ago, which is worth knowing before a product team tries to invent its own reconciliation logic. IHE’s Patient Identifier Cross-Referencing profile exists specifically to support cross-referencing patient identifiers across what it calls separate Patient Identifier Domains. Identity information travels from each source system to a cross-reference manager, which then makes the resulting list of matched identifiers available on query or through an update notification. Each departmental system in a consolidation project is, in this profile’s terms, its own identifier domain.
The work is standing up that cross-reference layer and feeding it correctly, rather than designing a matching algorithm from scratch.
One Retention Policy, or Several
Every departmental system arrived with its own default retention setting, usually whatever the vendor shipped, rarely anything a compliance officer reviewed department by department. Consolidating into one archive forces a decision those defaults never had to make explicit.
It helps to be precise about what actually governs this, because the assumption that HIPAA sets a retention clock for medical records is common and wrong. HHS is direct on the point: the Privacy Rule “does not include medical record retention requirements. Rather, State laws generally govern how long medical records are to be retained.” That means a health system, or the vendor building a platform for one, cannot look to a single federal timeline and call the retention question solved.
Requirements vary by jurisdiction and, within a jurisdiction, often by the type of record and the type of study. A pathology slide, a cardiology angiogram, and a dermatology photograph can therefore carry different retention obligations even though they now live in the same archive.
A consolidated archive has two honest options. It can apply the single most conservative retention period across every study type it holds, which is simple to build and expensive to run, since imaging volume only grows. Or it can configure retention per department and per study type inside one system, which costs more upfront. Only the second version avoids both deleting something too early and paying to keep everything forever.
Either option presupposes one archive. Separate departmental systems were never designed to talk to each other about retention in the first place.
The Migration Question
Every one of those departmental systems also holds years of existing studies, and consolidation eventually means moving them, rather than only pointing new studies at a shared archive going forward. That migration carries the same failure modes as any vendor neutral archive evaluation, which the linked piece works through in detail. What changes here is scale. Those failure modes apply once per departmental archive in scope, and each one has to be tested on its own.
What Consolidation Actually Buys
Done well, the payoff is concrete. A clinician looking up a patient sees every department’s imaging in one place, instead of opening one system per department and hoping to remember which one has the pathology slide. Storage stops being a separate line item per department, with a separate vendor behind each, and becomes one infrastructure decision, which is where the real cost savings live.
One published account tracked a large integrated delivery network’s transition to a consolidated archive, covering 54 radiology sites and 26 cardiology sites. It reported more than 10 percent overall cost savings and a 30 percent reduction in storage costs. Archive retrieval volume grew 120 percent and image production grew 40 percent over the same period.
That result belongs to that health system’s specific implementation, so it transfers to another consolidation project only as evidence, never as a forecast. It is still a measured outcome rather than a vendor promise, and it is the shape of the return a well-executed consolidation should produce.
What It Costs
None of that is free, and a product team scoping this work should budget for all of it, not just the storage line:
- Object mapping. Testing each department’s non-DICOM and visible-light objects individually, since a solution proven only against CT and MR has not actually been proven against endoscopy video or a whole-slide pathology scan.
- Identity reconciliation. Standing up and populating a cross-reference layer across every departmental system in scope, an integration and data-quality project in its own right, not a configuration toggle.
- Migration. Moving years of existing studies out of systems that were never built to export cleanly.
- Retention governance. Setting and enforcing a policy that reflects what each study type actually requires, department by department, instead of defaulting to whichever setting is easiest to configure once.
Where the PACS Layer Fits Into This
None of this is a decision a PACS makes on its own behalf, and a partner evaluating one should be wary of a pitch that implies otherwise. A vendor neutral archive is not part of what EBM offers in this market today, and nothing in this piece should be read as a claim of one.
What EBM mAIn PACS® does implement is native DICOM services: C-STORE, Query/Retrieve, Modality Worklist, and Storage Commitment. That surface covers the modalities it connects today, including endoscopy alongside CT, MRI, ultrasound, and X-ray. How studies move from there into a consolidated archive a partner has built or is evaluating separately is a question to scope with EBM against that specific archive.
The identity reconciliation, the retention governance, and the archive consolidation itself live above that DICOM surface, built on the standards this piece has walked through.
What This Means for Your Evaluation
The multi-department consolidation problem is an organizational project wearing a technical disguise. The DICOM object definitions and the identity cross-referencing profile it needs are already written. The difficulty is that each department built a working solution for itself, on its own timeline, with no reason to consider the others.
What a PACS actually does inside any one of those departments is a separate question from what the archive underneath all of them has to do. A product team that keeps the two questions distinct is the one whose consolidation still holds together five years in.