Vendor Neutral Archive

Traditionally, the need to store medical images has been most common in the radiology and nuclear medicine departments, and has been implemented in the form of sub-specialty and departmental (PACS), which have combined the functions of image management and image archiving into a single solution. 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. Further, the persistent storage "inside" a proprietary PACS may not be in a standard form, the PACS may not update the stored files with the latest study and demographic updates and annotations stored in the database, and it may extend, abuse or depend on specific standard and non-standard (private) DICOM attributes in the stored files.

Over time, in many implementations, the underlying storage infrastructure has been "factored" out of the traditional (PACS) at the hardware and file system (DAS, NAS, SAN) level, and are supplied instead by non-domain-specific computer data storage vendors.

As more medical specialties incorporate images in their practice, the need to extend image storage and distribution capability to other departments, enterprise wide. Increasingly there is a desire to inter-operate at a higher application level, separating departmental-specific workflows, display and analysis solutions from image storage infrastructure, using standard protocols that are image and metadata aware, without sacrificing display performance.

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. This triggers the need to "migrate" the images and associated information to the new architecture without data loss, a non-trivial task despite the use of standard formats for image encoding. 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). Of course, migrating from one vendor's VNA to another isn't trivial either, just hopefully less frequent.[1]

An alternative term for a VNA is a "PACS Neutral Archive", which perhaps better conveys the original intent, but this term is rarely used, and for better or for worse, VNA has become the buzzword of choice amongst customers and salesmen.[2]

As noted above, the archive of images is naturally mostly static—that is, most of the content of an archive is unchanged, with only a (relatively) small number of studies added each day, with few changes and corrections required.

From the early days of PACS, it was expected that standard interoperability boundaries would need to be defined.[3] The ACR-NEMA, and later DICOM, standards arose to address not only the need for a standard file format but also protocols for storage of images from acquisition modalities to archives, and to query and retrieve images from the archive. Even the first ACR-NEMA standard from 1985[4] defined FIND and GET transactions.[5] I.e., the separation of workstations and workflow management from archives was envisaged from the beginning. 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. Homegrown PACS or mini-PACS typically described the archive and workstation as separate entities.[7] Many, but not all, monolithic commercial PACS continued to make use of proprietary protocols between their integrated workstations and archives, but the need to support separate third-party workstations for specialized work, such as 3D processing and radiotherapy planning, was always recognized, and implemented using the DICOM protocol.

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". They also describe query and retrieval from multiple archives (in a manner that would now be called a federated query) to provide inter-enterprise image sharing. The article noted some of the practical challenges at the time, such as the relative inefficiency of doing DICOM queries against such multiple archives and separating out those responses relevant for pre-fetching, as well as challenges of patient identifiers. Nevertheless, the ability to have images in a separate system from the workstation was felt to be an important capability. Ultimately, Erickson and colleagues developed this into a startup company, TeraMedica[9] in 2000, which was purchased by Fuji Medical Systems in 2015.

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.[14]

Michael Gray offers his essential ingredients of a VNA in his 2009 blog entry,[15] making reference to Acuo's checklist of attributes, the most recent form of which can be found in Shannon Werb's white paper on attributes of a "true" VNA.[16]

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. Characteristic for a VNA is that it provides a patient-centric approach that transcends upgrades and changes of the different viewing, acquisition, and workflow management components as they should be interchangeable without having to migrate, convert, or change the data formats or interface of the VNA."

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.[18]

Various alternative deployment models[19] and frameworks[20] have been described, which address matters of cost, value and barriers to entry.

Since the term "VNA" has been so abused as a marketing term, it has already achieved mythical status.[21]

A passive archive will simply store what it receives, and potentially overwrite the same thing when it is received again with changes but the same (unique) identifiers. This is insufficient in a production operation, where mistakes are made, and it is necessary to correct patient demographics, or correct mistakes (wrong patient or request or side was selected during an exam and incorrect information present in the image headers).

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.

In general, within a domain such as an individual institution, patient identifiers and identifiers of request, studies and reports (e.g., by accession numbers) are assigned uniquely within that domain, but not outside. Most internal systems (and most PACS) do not manage the existence of multiple identity domains, and if identifiers are used across domains then collisions and ambiguity occur. 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. When importing outside images into the local archive, this matter also has to be addressed, usually by mapping the outside identifier into an internal identifier and re-encoding the information (coercion) in the DICOM "header" or other meta-data (such as by the manner specified in Import Reconciliation Workflow).

Whether support for this is an essential feature for a VNA depends on what environment it is intended to be deployed in (within one enterprise or across enterprises), but robust support provides insurance against future deployment configuration changes (such as enterprise mergers).

Likewise, local code sets used for such things as procedure codes (for "orderables", as opposed to billing codes), are not well standardized, and where these are useful in images to drive workflow and display (such as hanging protocols), an ability to map these too is a useful feature.

One purpose of a VNA is to store information and serve it to multiple systems that may have different requirements for its use and expectations for very specific characteristics of the DICOM attributes and values stored in them, both standard and private.

The concept of "dynamic tag morphing" is touted as a solution to the problem of two different systems expecting different values in the same attribute. "Tag morphing" refers to changing the values in one or more attributes (usually DICOM data elements in this context). This may be done "statically", in which case only one mapping is performed, or "dynamically", in which case multiple mappings, each specific to a particular recipient, is performed.

In its degenerate form, the ability to map any tag and value to any other is inherently dangerous and undermines the value of attempting to standardize attributes in the first place, and the efforts by modality and PACS vendors to use them "properly". That said, there is variation in the installed base and even new products in how some fields are used, particularly for highly specific and advanced forms of imaging, and corresponding variation in what advanced display and analysis applications expect in their input. Accordingly this is a popular feature, despite its dangers. Some will argue strongly that it is an essential feature to be classed as a VNA.

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 typical use case is to change the values in Series Description supplied by acquisition modalities, in order to allow two different PACS sharing the same data to use different hanging protocol rules based in Series Description. Arguably, this could be achieved in a more standard way if modalities populated other attributes in more detail, acquisition protocols and codes for them were better standardized and hanging protocol engines were more flexible, but given the limitations of the state of the art, this technique remains useful.

Dynamic tag morphing is distinct from the specific attribute changes related to Cross-domain Identity and Code Resolution (what DICOM in PS 3.4 refers to as "coercion"), for which there are standards defined for what to change, when and how, and which often involve additional actors such as a Master Patient Index, though some proponents lump these together and some products implement them using the same mechanism.

Michael Gray was an early proponent of tag morphing and regards it an essential VNA feature.[22] A description of tag morphing use-cases can be found in Wayne Dejarnette's 2010 white paper.[23]

Disk is cheap, though power and air-conditioning are not, but regardless, storage has a finite cost, particularly when one is paying as one goes rather than using a locally hosted capitalized infra-structure.

Accordingly, when medico-legal retention periods expire, or the clinical utility expires (such as on a patient's death), many users would like to be able to purge their storage. The rules for this are complex, and vary between jurisdictions as well as according to local policy. Given the conflicting demands of financiers, risk managers, litigators, researchers and educators, coming to agreement on such a policy may be difficult.

Regardless, a potentially useful VNA feature is support for locally customizable rule-based purging (culling) criteria, whether it be by implementing the rules directly, or responding to IHE Imaging Object Change Management (IOCM) requests from a separate rules engine.

VNAs should have no difficulty storing DICOM content such images and associated information such as presentation states and so-called "evidence documents", such as DICOM Structured Reports containing such things as measurements recorded by the modality, or post-processing results such as from CAD.

In a clinical setting, however, other document and bulk object types may be available that it would be desirable to store. Most PACS take the approach of converting these to DICOM, in some cases using objects intended to "encapsulate" another type of object. The classic example is a scanned document stored as a PDF file and encapsulated in a DICOM PDF object along with sufficient metadata to identify it and manage it, as if it were an image. VNAs should support these type of encapsulated DICOM objects and the DICOM "header" provides a means to obtain the metadata for indexing to support query and retrieval. Michael Gray elaborates in detail on this topic in his white paper on the subject.[24]

For other object types, or when there is no DICOM encapsulation object available, or when there is no need to interface with DICOM systems, as long as there is a standard means of providing the necessary metadata for indexing, such as by using HL7 version 2 messages or XDS registry services, then in theory a VNA could store anything.

Specific types of non-DICOM content, such as an HL7 CDA document instance containing, for example, a radiology report, could be stored either as a XDS, or first encapsulated in a DICOM Encapsulated CDA object and stored using DICOM services, or its content and header could be transcoded into a DICOM Structured Report instance. 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).

A description of Wayne Dejarnette's approach to non-DICOM object storage in his product is described in his 2009 white paper.[25]

There is general agreement that the use of the DICOM file format is required for images, and that where images are compressed for archival or transport, standard, not proprietary, compression schemes (transfer syntaxes) need to be used. Indeed, a distinguishing feature of most VNAs as opposed to many traditional PACS is the avoidance of proprietary internal formats ostensibly used in the past for "performance" reasons, whilst still obtaining good performance across the interfaces.

Implementations may vary in the range of supported compression schemes, whether or not reversible (lossless) compression is mandatory for medico-legal archival purposes. Implementations also vary in the range of modality-specific image types that they support; though many archives will support all DICOM image information objects in principle, some extreme cases, like whole slide pathology images and long videos may not be supported. A general feature of VNAs is to attempt to preserve all attributes as originally supplied, including private (proprietary) attributes whether from the acquisition modality or added by other intervening applications (such as QC workstations or PACS).

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. Since the DICOM format is inherently extensible, and all new objects build upon a common encoding and pattern, a VNAs should be able to store any DICOM image object, regardless of whether the SOP Class is recognized or new. 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.

Support of the basic DICOM C-STORE, C-FIND, C-MOVE and preferably C-GET are fundamental and not debated. The basic uncompressed transfer syntaxes including implicit and explicit VR little-endian, and the less common big-endian transfer syntax are typically supported. The range of compressed transfer syntaxes usually includes lossless JPEG and reversible and irreversible JPEG 2000, occasionally JPEG-LS, and usually lossy JPEG for images that were supplied that way (especially true color photographs. Support for motion compression (other than multi-frame JPEG) is less common, but perhaps more common in VNAs than in PACSs, especially for storage and regurgitation without viewing.

Most would agree that an important VNA interface is the original version of Web Access to DICOM Persistent Objects (WADO), which allows single images to be retrieved with an HTTP URL in either DICOM file format or pre-rendered into a consumer format like JPEG.

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.

The grayscale or color rendering transformation applied to images for display should be stored as a DICOM Presentation State object. These objects support grayscale and true color images, as well as the application of a pseudo-color lookup table to grayscale images. Presentation states can also record any zooming and panning (displayed area selection) applied. IHE uses these in the Consistent Presentation of Images (CPI) profile

Since many modern PACS can also store image annotations using DICOM Presentation State objects, a VNA needs to support these, including not just storage and regurgitation, but also selection and display in any viewer supplied as a VNA component.

The preferred format for storage of annotations, regions of interest, and measurements is the DICOM Structured Report (SR) object, which allows structure, coded and semantic information to be persisted, rather than just presentation. IHE refers to these as Evidence Documents (ED). 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. Ideally, any viewer component should be capable of a generic (if not ideal) rendering of the content of any SR, including display of coordinates on referenced images.

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 VNA needs to support these too.

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. Though obsolete PACS may only record this as a flag in an internal database, modern PACS use the DICOM Key Object Selection object (a specialized form of SR) to export this information. This usage is described in the IHE Key Image Note (KIN) profile. A VNA needs to support storage and regurgitation of KOS objects, as well as selection and display of these in any viewer.

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. DICOM defines a specialized form of Structured Report, the Radiation Dose Structured Report (RDSR) to encode this. IHE uses these in the Radiation Exposure Management (REM) profile. A VNA must support storage and regurgitation these, and ideally, would be able to extract critical information for display in any viewer.

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 persistent form of these "documents" is not well-standardized, but many customers expect a VNA to be able to accept them in whatever local format is preferred. 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. Now that HL7 has promised to relax its previously closed IP policy, including offering CDA free for use, it is possible that CDA will become the preferred form of encoding, but VNAs will still need to accept (and possibly transcode) reports in a plethora of form from the installed base. DICOM defines templates for the encoding of human-generated reports as DICOM Structured Report (SR) objects, and IHE specifies these in the Simple Image and Numeric Report (SINR) profile.

In addition to DICOM RT Structure Sets, for a VNA to be usable in an enterprise that performs Radiotherapy, the entire family of DICOM RT objects for beam, ion and brachytherapy need to be stored and regurgitated.

DICOM defines a Raw Data object that is essentially a conventional DICOM composite instance header with patient, study, series and instance information, but no payload. It was intended for the storage of the raw data that is not easily represented as an image or image-like object, such as the raw views obtained from the detectors of a CT scanner, or the k-space data from an MRI scanner, but can be used to encode anything. A VNA should be able to store and regurgitate these, even though it may be unaware of their contents and only the originating device may be able to interpret them.

Though there are many consumer formats for encoding audio in widespread use, these lack the header or metadata necessary to identify the patient and encounter. A VNA that wants to support these needs to have a means of providing such information, such as submission using XDS. DICOM does define a Basic Audio object, and though it does not support the plethora of audio codecs available in the consumer world, some PACS do produce them, so a VNA should support these.

Time-based waveforms (such as ECGs) may be stored as DICOM or in a multitude of other formats, and the same principles apply as for audio; i.e., if the format is a medically oriented one, use the header meta-data for indexing during ingestion, if not, use XDS to register it.

A DICOM MR Spectroscopy object is defined, and since some modalities produce it, a VNA should be able to store and regurgitate instances of it.

DICOM allows for the concept of Private SOP Classes, which use the DICOM encoding and transfer mechanisms but whose content is opaque. Vendors use these to good effect when necessary to encode information that has not been standardized, and also abuse them for convenience in lieu of using a standard encoding. Regardless, since their content may be important to the clinical workflow, a VNA should be configurable to accept, store and regurgitate these.