Most OEMs and VARs come to a vendor neutral archive with a problem already in hand. Imaging data has to outlive the PACS that created it. A migration that ran slowly, cost more than it was scoped for, or quietly dropped something nobody noticed until an old prior would not open is what turns that into an urgent question. It is also why “vendor neutral” gets scrutinized instead of taken on faith.
The label is something a vendor applies to its own product. The only way to know whether it holds is to test what it is supposed to guarantee: imaging data comes out of the archive as intact as it went in. That has to be true regardless of which PACS vendor sits in front of it today, or five years from now.
“Vendor Neutral Archive” Is a Description, Not a Certification
DICOM defines the objects and the services that move them. IHE defines profiles for how systems combine those services into working transactions. Neither body defines a vendor neutral archive, and IHE’s own archive migration proposal calls it a so-called term and rules the use case out of its scope. So the label is shorthand for an architecture choice, a long-term store built on standard DICOM interfaces and decoupled from any single PACS vendor’s proprietary format, not a status a body confers.
That shorthand is useful, but it describes an intent, not a guarantee. A product can implement standard DICOM services on the way in and still hold data in a proprietary internal structure that only its own tools fully understand on the way out. Standard input and standard output are two different claims, and a vendor’s marketing page rarely distinguishes between them.
What Actually Makes a Migration Lossy
Migrations do not usually fail on the obvious part. Single-frame pixel data moves cleanly almost every time. What gets left behind, dropped, or silently corrupted is everything built around it.
Private tags. The DICOM standard reserves odd-numbered attribute groups for vendors to store information the standard itself does not define, everything from proprietary processing parameters to annotation coordinates a specific viewer relies on. A receiving archive that has no dictionary for the originating vendor’s private tags either drops that data or stores it as an opaque, unreadable block. Either way, whatever depended on it stops working the moment the study lands somewhere new.
Presentation states. Window and level settings, cropping, rotation, and saved annotations are not baked into the image. They live in a separate object, stored and transmitted independently of the pixel data they describe. A migration that moves images but not presentation states produces a study that opens fine and looks wrong: every saved measurement, every window preset a radiologist configured, gone, even though the image itself migrated perfectly.
Structured reports. Measurements, CAD findings, and key-image references are frequently stored as a distinct object type built around a hierarchy of coded content rather than pixel data. That object references the images it describes by their unique identifiers. Migration tooling built around the assumption that every object is a picture can skip these objects entirely. Worse, it can preserve them while the identifiers they reference get renumbered, so the report survives but points at nothing.
Encapsulated documents and video. Scanned consent forms and burned-in report pages travel as encapsulated documents inside a DICOM wrapper, carrying a PDF or CDA payload rather than pixel data. Ultrasound cine and endoscopy video are a different thing again: native image SOP classes, Ultrasound Multi-frame Image Storage and Video Endoscopic Image Storage, holding many frames in one object. Migration tooling written for single-frame images handles neither well. A wrapper can survive while the payload inside it no longer opens, and a multi-frame object can arrive with its frames or its timing information incomplete.
None of these four categories are exotic. They are the normal contents of a working imaging archive, which is exactly why an archive that only proves itself on plain CT and X-ray images has not proven much.
Test the Conformance Statement, Not the Brochure
Every DICOM implementation is required to publish a document that states exactly which parts of the standard it supports. That means the SOP classes, the transfer syntaxes, whatever a vendor built on top of the base standard, and where its private extensions live. Comparing two vendors’ documents side by side is how a technical buyer sees, concretely, whether and to what extent two systems will actually interoperate. It is a far more specific artifact than a claim on a website, and it is one every serious vendor should hand over without hesitation.
The conformance statement is the starting point, not the finish line. It tells you what a system claims to support. It does not prove the system handles your specific mix of private tags, presentation states, structured reports, encapsulated documents, and video correctly on the way out. That only gets proven one way: run an actual migration test before signing anything.
Export a representative sample into the candidate archive: annotated studies, structured reports, and whatever encapsulated documents and video your workflow produces. Then pull it back out again, into a different viewer than the one that wrote the original data. If everything that mattered in the source study is present and correctly linked in the result, the archive earned the label. If something is missing, better to find out during a pilot than during the next migration.
Who Actually Sets the Retention Clock
A common assumption is that HIPAA sets the retention clock for medical images. It does not. HIPAA’s documentation retention rule covers the policies, procedures, and records the rule itself demands. Those have to be kept for six years from the date of creation or the date they were last in effect, whichever is later.
That requirement governs administrative documentation, not the underlying clinical images. How long imaging studies themselves must be retained is set elsewhere: state medical record laws, payer requirements, and accreditation standards. Those obligations vary by jurisdiction and by the type of study.
What that means for an archive evaluation is practical, not academic. Retention has to be configurable to whatever the applicable requirement actually is, not fixed to whatever period the vendor shipped as a default. The archive also needs a legal hold mechanism: the ability to exempt specific studies from a retention or deletion policy when litigation or a formal record request requires it.
That exemption has to work without exempting the entire archive or disabling lifecycle management altogether. A vendor who cannot describe how retention policy gets configured, per jurisdiction, per study type, has not actually built for this requirement. They have built a default and hoped it fits.
Storage Tiering and the Economics of “Forever”
Imaging data does not shrink, and an archive with no tiering strategy turns that growth into the most expensive, least examined line item in a deployment. A genuinely neutral archive separates the tiering decision from the PACS entirely. Recent, actively referenced studies sit on faster, more expensive storage. Older studies that are rarely retrieved move to slower, cheaper storage, on a policy the buyer controls rather than one the vendor bundles invisibly into a flat price.
The part of this economics conversation that gets skipped most often is what it costs to get data back out of a tier, not just what it costs to put it in. Retrieval and egress pricing, especially out of a cloud storage tier, can run well ahead of the storage cost itself. Ask about egress pricing as its own line item during evaluation. An archive that is inexpensive to fill and costly to leave is not neutral in any sense that matters to the buyer.
The Questions That Decide It
These belong in the evaluation, not in the contract review. The first four test what the archive does with data on the way in and while it sits there. The last five test the only thing that finally proves neutrality: what happens the day a partner decides to leave.
On ingestion and at rest:
- Can we see the current conformance statement, and will you walk through where private extensions live in it?
- What happens to private tags from a third-party PACS during ingestion: preserved, dropped, or stored opaquely?
- How are encapsulated documents and multi-frame objects, scanned PDFs, ultrasound cine, endoscopy video, handled on both ingestion and export?
- Can retention policy be configured per jurisdiction and per study type, and is there a legal hold mechanism?
On the way out:
- Format. Does export produce standard DICOM Part 10 files a different system can ingest directly, or a proprietary export bundle that needs the outgoing vendor’s own tooling to unpack.
- Completeness. Does the export include presentation states, structured reports, encapsulated documents, and video by default, or only on request, or not at all.
- Cost. Is there a defined egress cost in the contract before you sign, or is it negotiated after notice of termination, when leverage has already shifted.
- Timeline. What is the maximum daily throughput for a full export, and what does that put the total exit timeline at for the archive size you are actually building.
- Ownership of the process. Does self-service export exist through an API, or does every exit run through the outgoing vendor’s professional services queue on their schedule.
A vendor who has thought through all nine of these before you ask is a different kind of vendor than one who has only thought through onboarding.
Working Storage and the System of Record
A PACS keeps its own working storage, and that is a different thing from an archive. A PACS’s local storage exists for fast retrieval of active, recently read studies, the cache a reading workflow depends on for speed. An archive is the long-term system of record, built to hold everything for as long as retention requires, independent of how fast any single PACS needs to read it back today.
Decoupling the two is the entire point of a neutral archive. A product team can then swap or upgrade the PACS in front of it without touching the archive underneath, or swap the archive without disrupting the reading workflow on top of it. A PACS with excellent read performance and a proprietary archive underneath still leaves a product locked in exactly the way an archive is supposed to prevent.
Where the PACS Layer Fits Into This Decision
None of this is a decision the PACS makes for you, and it should not try to. A vendor neutral archive is not part of what EBM offers in this market today. What EBM mAIn PACS® does implement is native DICOM services: C-STORE, Query/Retrieve, Modality Worklist, and Storage Commitment, along with open APIs. EBM states that surface connects any modality or viewer without custom middleware.
Those same services are how an archive is written to and queried, so a partner’s archive choice sits on the other side of a documented seam rather than inside the PACS. For a partner building on EBM Fabric™, the same principle holds at the platform level. Its edge-to-cloud architecture, designed to support HIPAA compliance, assumes the archive underneath is a separate decision, made on its own merits rather than a default a product team inherits by accident.
What This Means for Your Evaluation
Those nine questions are cheap to ask during an evaluation and expensive to ask afterward. Before a contract is signed, a vendor has every reason to answer them. After it is signed, the answer is whatever the contract already committed to, and the migration test you skipped becomes the migration you pay for.
The archive and the PACS itself are separate layers with separate failure points. Treating them as one purchase is how a product team ends up locked into a proprietary store it never meant to buy. An archive that exports cleanly keeps the PACS in front of it swappable, and the viewer reading from it swappable too. One that does not export cleanly makes every other choice in the stack provisional, whatever the contract for those layers says.