Vendor Neutral Archive

The exact definition and feature set is contentious though, and evolves as different vendors of VNAs attempt to distinguish themselves from their competitors and avoid being excluded, and customers express desires ranging from pragmatic to fantastic.

Whilst such systems all have standard interfaces (DICOM and IHE) for ingestion and distribution of images over the network and on physical media (like CD), typically the workflow and optimal performance for display are achieved using proprietary software and protocols.

A complicating factor is that the (PACS) offerings are in a constant state of flux with respect to features and quality of service, and traditionally users will abandon one vendor and replace their product with another's every 3–5 years.

The concept of a VNA theoretically allows for greater stability (re-usability and less frequent migration) at the archive level, despite rapid evolution and change at the higher application-level (display and workflow).

The first DICOM demonstrations at RSNA beginning in 1992 made use of a so-called "central test node",[6] which arguably was one of the first DICOM-based vendor neutral archives, though that label was not in use at the time.

In 1998, Erickson and Hangiandreou[8] discussed the advantages of once again separating the archive functionality from the conventional monolithic PACS and making use of pre-fetching to populate the "interpretation storage device".

In one of many blog entries[10] on the subject, Michael Gray makes a reference to an early description of the concept of separating the front-end clinical applications from the back-end storage function, in an article by Nadim Daher, a Medical Imaging Market Analyst at Frost & Sullivan.

[11] A long running Aunt Minnie PACS Forum thread digressed to discuss the issue of neutral archives amongst a broader audience after a response from Michael Gray.

[12] A white paper from 2009 by Wayne DeJarnette [13] is an early attempt to establish a definition based on a required feature set, and his company has also provided a more recent interpretation.

Acuo provided a service giving vendor agnostic viewing over a single normalized central repository for all imaging content.

It was Michael Gray who in 2004 coined the phrase "Vendor Neutral Archive" directly referencing the Acuo platform’s ability to separate Viewing, Content Management and Message Orchestration, and Storage.

Herman Oosterwijk provides a more recent description on behalf of Teramedica, in his white paper,[17] in which he offers a more detailed definition: "A Vendor Neutral Archive (VNA) is a medical device that provides scalable image and information and life cycle management so that images and related information can be queried, stored, and retrieved in a manner that is defined by open standards at multiple department, enterprise, and regional level while maintaining patient privacy and security.

The relationship of VNA to storage of medical images in the cloud is also nebulous, though offers high potential for buzzword compliance, and Michael Gray provides some clarity in his paper commissioned by EMC.

Standards exist that cover some use cases, such as IHE Patient Information Reconciliation (PIR) and Imaging Object Change Management (IOCM).

For an archive to span departments, institutions, regions or even national boundaries, the question of identification of entities and concepts must be addressed.

Thus each identifier needs to either be qualified by its "assigning authority" when used (the approach taken by the DICOM-based IHE Multiple Image Manager Archive (MIMA) profile) or coerced into a single "canonical" identifier that spans the scope of the larger domain that includes all integrated cross-enterprise systems (the approach taken by IHE Cross Enterprise Document Sharing.

This feature is reminiscent of what is common in the HL7 version 2 world, a so-called Interface Engine, which is designed to map pretty much anything to anything else, depending on the source and target.

A fully featured VNA might have the ability to transcode any single instance into another form depending on what the requesting system needed ("object morphing", if you will).

DICOM describes many different "Information Object Definitions" and "SOP Classes" for storage of images with specific metadata related to particular modalities and applications, and the list of these grows as technology evolves.

This may be achieved through the use of field-modifiable configuration to add new SOP Classes, or by analysis of the contents of the objects "header", or by the simple of approach of accepting, storing and regurgitating anything transferred via a DICOM C-STORE operation.

The SOAP Web Service based transactions of the IHE Cross Enterprise Document Sharing for Imaging are also generally considered a prerequisite for a claim to be a VNA.

DICOM SR objects may also be produced in the context of the IHE specifies these in the Simple Image and Numeric Report (SINR) profile.

Since many Acquisition Modalities, mammography CAD systems and quantitative image analysis workstations produce SR objects, a VNA should be capable of storing and regurgitating these.

For specific domains, such as Radiotherapy, an older format, the DICOM RT Structure Set, which can encode 3D patient relative coordinate isocontours (only) is used, and some non-RT workstations produce these as well instead of SRs.

A common concept in a PACS is for the user (such as a modality operator or interpreting radiologist) to flag some images (or other objects) as being "key", i.e., of particular interest for some reason.

Since many medical imaging techniques deliver non-trivial amounts of ionizing radiation to the patient, the dose exposure needs to be tracked, and in some jurisdictions this must be recorded by law.

In radiology and nuclear medicine applications, the practice of dictating and transcribing (or using speech recognition) is well entrenched and the output of these is typically unstructured or minimally structured prose, encoded as plain text and distributed by fax or HL7 version 2 messages or some equally primitive mechanism.

The same principles apply as for the storage of any non-DICOM content, including the use of HL7 version 2 messages or XDS to provide metadata in lieu of a structured "header", such as in the case of reports rendered as PDF, when they have not been encapsulated in DICOM or CDA objects.