Most writing about vendor neutral archives explains, at length, that a vendor neutral archive is vendor neutral. The harder question is what changes for an AI engine when the images of record live in the archive, not the PACS.
What is a vendor neutral archive?
A vendor neutral archive (VNA) is a medical imaging store that holds studies from every department in standard DICOM format, independently of the PACS, RIS or viewer that created them. It keeps the objects, the index and the retention rules in one place and serves them to any system speaking DICOM. Hospitals buy one so that replacing a PACS does not mean migrating the images.
"Neutral" is a claim about format, and format is the whole product: studies stored as the standard defines them can go to a viewer, a research platform or an AI engine with no translation layer. That is why the DICOM standard matters to an archive buyer.
VNA vs PACS: which one actually holds your images?
A PACS is a workflow system — worklist, viewer, hanging protocols, the tools a radiologist reports with. A vendor neutral archive is a storage system that holds objects from many departments in a form a future system can read. Some products do both, so "we have a VNA" tells you nothing until you know which role it is playing.
| The question | Why it surprises people | What it changes for AI |
|---|---|---|
| Who owns the object? | You own the study; the storage under it may sit in the vendor's cloud account. | Whether an engine can read it without a contract change. |
| Who owns the index? | Ask whether the index is queryable by you, or only through the vendor's tooling. | Without it you retrieve known studies but cannot select a cohort. |
| Who can bulk export? | Ask whether your own staff can run one, and what it is priced at if they cannot. | The real cost of adding a second engine, or leaving. |
What changes for an AI engine when the archive is the source of truth
When the archive rather than the PACS holds the images of record, three things change for an AI engine: where it subscribes for new studies, which system you must query when a finding has to be explained months later, and which copy of the pixels the model actually read. If the archive and the PACS hold copies that differ in compression or tags, that last question decides whether a re-run reproduces the original result.
That third change is the one teams meet late. Archives are routinely configured to re-encode objects on ingest — into a different transfer syntax, or at a compression ratio somebody chose years ago to control storage cost. A model evaluated on the modality's original output is not necessarily reading the same pixels once the archive has finished with them, and nothing in the workflow announces the difference. Ask what happens to an object between being received and being served back, and ask it before you compare two runs and conclude that the model has drifted.
Prior studies are the quiet win. When the archive holds everything and the PACS only a recent window, it is the only system that can hand an engine a comparison study from four years ago. The same asymmetry decides where an engine should subscribe: an archive receives studies on its own timetable, which suits retrospective and routine work — including validating a model against your own population before you trust it prospectively — and suits urgent reads badly.
Routing is a separate discipline, covered in how studies reach an AI engine. The archive question is narrower: which system holds the object you must produce later?
Expert Insight: where I would not put the archive in the path
I would not make the archive the trigger for time-critical reads. In the deployments I have worked on, studies land in the archive after the acute workflow has moved on, and stroke work cannot wait for that. Let the archive be the record, not the doorbell — where the urgent trigger should come from instead is a routing decision, and it belongs in a different conversation. For routine and retrospective work the opposite holds: the archive has the priors.
DICOMweb, XDS-I and the interfaces an AI engine can actually use
DICOMweb is usually the most practical interface for an AI engine, because it runs over HTTP and needs no DICOM association per request. Three services do the work: QIDO-RS to find studies, WADO-RS to retrieve them, STOW-RS to store objects back. IHE's XDS-I profile covers cross-enterprise sharing. Ask which of these your archive exposes.
QIDO-RS — find
Query by patient, accession, modality or date. This lets an engine select a cohort rather than be handed one study at a time.
WADO-RS — retrieve
Fetch a study, series or instance. Check what returns: the original transfer syntax, or something re-encoded.
STOW-RS — store
Write objects back in. This decides whether AI output can live in the archive at all — confirm it is switched on for your instance, because a datasheet line is not a configuration.
The DICOM standard and IHE publish these definitions openly, so "supports DICOMweb" is testable rather than a matter of trust. Test it against your own instance, under your own access control and data residency rules.
Where do AI findings live?
There is no settled answer. An AI finding can be written back as a DICOM secondary capture, as a structured report object, into the RIS as report text, or into the vendor's own console and nowhere else. Each option changes retention, discoverability and what the next radiologist sees, so decide deliberately before go-live.
| Where the finding goes | What you gain | What it costs you |
|---|---|---|
| Secondary capture in the archive | Visible in any viewer, retained with the study. | Looks like a clinical image forever, to systems that cannot tell. |
| Structured report object | Machine-readable, separable from the images. | Few viewers render it well, so it goes unseen. |
| RIS report text | Lands where the referrer already looks. | Overlay and reasoning are lost; only words survive. |
| Vendor console only | Nothing to integrate on day one. | Outside your retention policy and your audit trail. |
Whatever you choose, the output is decision support: Fractify returns findings with confidence scores, urgency on a 1-5 scale and treatment guidance, and a qualified clinician reviews every one. Where that sits beside the diagnostic record is a medico-legal question first.
How neutral is it really? The exit test
Neutrality is decided at the exit, not the ingest. Every archive can accept DICOM. The test is the bulk export on the day you replace it: do studies come back as standard DICOM with the original tags and the study-instance UID chain intact, or re-wrapped with private tags the next system must be taught to read?
1. Pick a hostile sample
Not a clean CT. A multi-frame study, one with corrected demographics, and a non-DICOM object.
2. Export it without the vendor
Your staff, your credentials, documented interfaces. If this needs a support ticket, you have your answer.
3. Ingest it somewhere neutral
Load it into an open-source archive or an independent viewer. Whatever fails to parse is a cost found early.
4. Diff the tags
Compare exported headers against what went in. Missing UIDs and dropped private tags break a future AI run.
Non-DICOM objects are where this gets uncomfortable, and they are usually why the archive was bought: dermatology photographs, endoscopy video, scanned forms. They have no worklist and no standard metadata to select on, which is why their AI story stays vague. Run the exit test on one.
What to ask before you sign
Ask five things: which system holds the copy of record, who owns the index, whether QIDO-RS, WADO-RS and STOW-RS are enabled rather than merely supported, what a bulk export costs in money and days, and where AI output will be written. Get the answers into the contract, not only the tender response.
- Copy of record — named in writing; does AI read it or a derivative?
- Index — can you run a cohort query yourself?
- Interfaces — enabled, and tested against your instance.
- Exit — a rehearsed export, before signature.
- AI output — one destination, one retention rule.
Answer those and adding an AI engine later is configuration, not a project; leave them open and the archive decision has become the AI decision. PACS integration with AI and cloud versus on-premise total cost of ownership turn on the same fact.
Fractify reads DICOM and integrates at the PACS and DICOM layer, so this is the first thing we ask a hospital. If you would rather test interfaces than argue datasheets, the hospital deployment route starts with a 14-day free trial, no credit card.
Frequently asked questions
These are the questions hospital IT leads, PACS administrators and radiology managers ask most often when an archive is being bought, replaced or opened up to an AI engine. The answers below assume the distinction drawn above: the archive is the system that holds the objects of record, and the PACS is the system radiologists report from.
What is a vendor neutral archive in healthcare?
A vendor neutral archive is a medical imaging store holding studies from many departments in standard DICOM format, independently of the PACS or viewer that created them. It holds the objects, the index and the retention rules, so replacing a PACS does not force a migration.
What is the difference between a VNA and a PACS?
A PACS is a workflow system: worklist, viewer, hanging protocols, the tools radiologists report with. A VNA is a storage system that holds objects in a form a future system can read. The difference is a role, not a product category, and some platforms play both.
Do I still need a PACS if I have a VNA?
Yes, in almost every case. An archive stores and serves objects; it does not give a radiologist a worklist, hanging protocols or reporting tools. Some vendors bundle both roles into one platform, but the reading workflow still has to exist somewhere.
Can AI read images directly from a VNA?
Yes, where the archive exposes DICOMweb or standard DICOM query and retrieve services and the network path allows it. The constraint is freshness, not capability: archives receive studies after the acute workflow has moved on, which suits routine and retrospective work more than urgent reads.
Is there an open source vendor neutral archive?
There are established open-source DICOM archives: dcm4chee and Orthanc are two widely used examples, and either can play the archive role. Licensing is not neutrality, though: an archive configured to re-encode studies on ingest is no easier to leave than a proprietary one.
How do I know if a VNA is genuinely vendor neutral?
Test the exit rather than the ingest. Export a difficult sample yourself, using documented interfaces and your own credentials, then load it into a different system and compare the tags against what went in. Missing UIDs or unparseable objects tell you more than a datasheet.
Where should AI findings be stored — in the VNA or the RIS?
There is no settled convention. A secondary capture keeps the overlay visible in any viewer; a structured report is machine-readable but poorly rendered; RIS text lands where referrers look but loses the imagery. Pick one destination, attach a retention rule, document it.
How long does a VNA migration take?
No honest fixed number exists. Duration is set by study volume, the proportion of non-DICOM objects, whether the outgoing vendor cooperates, how much tag remediation is needed, bandwidth, whether you move everything or tier by age, and the reconciliation pass proving nothing was lost.
See Fractify working on your own scans — live demo takes 15 minutes.
Request a Free Demo →