Vendor neutral archive in PACS.

An archive is a location containing a collection of records, documents, or other materials of historical importance. An integral part of Picture Archiving and Communication System (PACS) is archiving. When a hospital needs to migrate a PACS vendor, the complete earlier data need to be migrated in the format of the newly procured PACS. It is both time and money consuming. To address this issue, the new concept of vendor neutral archive (VNA) has emerged. A VNA simply decouples the PACS and workstations at the archival layer. This is achieved by developing an application engine that receives, integrates, and transmits the data using the different syntax of a Digital Imaging and Communication in Medicine (DICOM) format. Transferring the data belonging to the old PACS to a new one is performed by a process called migration of data. In VNA, a number of different data migration techniques are available to facilitate transfer from the old PACS to the new one, the choice depending on the speed of migration and the importance of data. The techniques include simple DICOM migration, prefetch-based DICOM migration, medium migration, and the expensive non-DICOM migration. "Vendor neutral" may not be a suitable term, and "architecture neutral," "PACS neutral," "content neutral," or "third-party neutral" are probably better and preferred terms. Notwithstanding this, the VNA acronym has come to stay in both the medical IT user terminology and in vendor nomenclature, and radiologists need to be aware of its impact in PACS across the globe.

Vendor Neutral Archive in PACS

To understand the concept of Vendor Neutral Archive (VNA), a look back into history is needed. Before standards such as American College of Radiology (ACR), National Electrical Manufacturers Association (NEMA), and Digital Imaging and Communications in Medicine (DICOM) entered the picture, modalities used to communicate with other modalities and equipment only if they were all manufactured and sold by the same vendor. Besides the modality, important accessories such as the printer, workstation, and PACS needed to be manufactured by the same vendor if sharing data were to be possible. However, with the introduction of standards and vendor conformance, modalities of different vendors could communicate with each other within a department, with seamless integration enabling more efficient workflow.

Although this multivendor setup looked quite functional, a serious problem arose if there was a need to change a PACS vendor. The new vendor experienced difficulty in reading the data stored at the server since the data in the storage server were stored in a format that could be read only by the earlier vendor.

Although this was bad enough, another problem was integrating a PACS installed in the radiology department with a PACS installed in, say, the cardiology department. Even if both are DICOM compliant, making them communicate with each other and share data are never easy “plug and play” situation. Interoperability emerged as a hugely contentious issue. This was when the concept of VNA became increasingly accepted as a method to address the practical problems in interoperability.

Archiving and its Challenges

An archive is a location containing a collection of records, documents, or other materials of historical importance. In the context of computers, it is generally a long-term storage, often on disks and tapes. Archiving is typically done in a compressed format so that data are saved efficiently, using less memory resources and allowing the whole process of archiving to be executed rapidly. PACS can archive images for several years: 3-5 years is very common. PACS storage has inbuilt mechanisms to take care of disk failures through RAID (Redundant Array of Independent Disks, also called inexpensive disks). Depending on the patient load, types of modalities, and the duration for which the images are to be stored, the storage size varies from terabytes (212) to petabytes (215) or even exabytes (218) and zetabytes (221).

A few challenges present themselves in archiving. A common misconception in archiving is “my PACS is DICOM conformant and hence there will be no interoperability problems.” The reality is that every PACS has its own internal formats to store data and its inherent proprietary methods to store image presentation states and key image notes.

When a hospital needs to migrate a PACS vendor, the complete earlier data need to be migrated in the format of the new PACS.[1] This is both time- and money consuming. Part of the problem occurs because DICOM is in reality a cooperative standard and not an enforced one and hence has limitations. Vendors make their own conformance statements, which may or may not conform to all that is expected of them and there may be a few gaps and inconsistencies.

Inability of vendors to comply fully with their conformance statements occurs occasionally. Such situations arise when a vendor providing a detailed conformance standard states that interoperability between their machine and other vendors machine is the responsibility of the user and not the vendor's. Similarly, equipment may have conformed to DICOM standards at testing and installation, but subsequent non-conformance when the standards change is not the vendor's responsibility. Data that are not in conformance with DICOM standards—where the data are in a format understood only by a specific vendor—are called “dirty data.”[2]

Features of VNA

VNA is an application engine that handles the data of a vendor and at a fast speed. It is stationed between the modality and the PACS [Figure 1]. The imaging data are pushed to VNA directly from the modality. Thereafter, VNA forwards it to the PACS, along with the priors. VNA stores the image presentation states and key image in DICOM format.[3]

Figure 1

Vendor neutral archive (VNA) is stationed between the modality and PACS. The imaging data is pushed to VNA directly from the modality. Thereafter, VNA forwards it to PACS, along with the priors. VNA stores the image presentation states and key image in DICOM format

So what does VNA do? It simply decouples the PACS and workstations at the archival layer.[4] Let us take a situation where (a) the modality did not have a field in the Graphical User Interface (GUI) to permit data entry for the technologist and (b) the modality work list was not supported. In this situation, there could be the possibility that the accession number is entered into the study description field, and a compulsory field in the DICOM header in front of the accession number is left blank. This would cause problems not only in efficient workflow but also in retrieval of images in the future.

To handle this problem, an application engine was developed that would check the DICOM header for any of the non-conformances and automatically normalize the DICOM tags and additionally, send the received DICOM file in its original form. Another issue that one comes across is that of non-conformance of transfer syntax. Some of the common ones being JPEG lossless, JPEG 2000 lossless, JPEG 2000, and Implicit VR Little Endian.

As the DICOM standard grows, more and more of syntax are being added, with different vendors using different ones. It is quite possible that two vendors, whose systems are expected to be used together, use different syntax. This problem is handled by developing an application engine that receives the data using one kind of syntax and transmits this data using the syntax of the target system.

Finally, the application engine needs to perform the above two functions at a fast speed. Thus, it is stationed between the modalities and the PACS and performs tag morphing and routing. Table 1 outlines a list of ideal characteristics of VNA and the advantages of VNA Figure 2.

Table 1

Ideal characteristics and advantages of vendor neutral archive

Figure 2

Vendor neutral archive can work as enterprise archive for all departments like radiology and cardiology, seamlessly integrating their data

Post-Implementation Issues in VNA

Migration of old data

When a department decides to implement VNA in a new PACS, there remains the problem of legacy data lying within the old PACS. Working with two different PACS systems or two different databases running at the same time in a department is an inefficient situation.

To address this, the data belonging to the old PACS are transferred to the new one by a process called migration of data. One important factor regarding migration is the way the data are archived. A few PACS vendors archive images using the plain and simple DICOM formats. Many alter the process in a proprietary way: They may either compress data with a proprietary algorithm or put certain types of flags on specific studies.

Techniques in migration of old data

There are a number of different data migration techniques.[5] The choices depend on the speed with which the data need to be migrated and how important the data are once they are migrated.

One technique is to perform a simple DICOM migration from the old system to the new one. The speed with which this will happen will primarily depend on the old PACS. Expectedly, simultaneous clinical usage will slow down the migration process.

A second technique is to perform a DICOM migration based on prefetch. The migration engine is connected to the active Radiology Information System (RIS) and as orders are entered, a prefetch begins from the old PACS storage, making those studies that will act as priors, thereby facilitating the migration of the old PACS. Importantly, there is no interference with clinic or radiological workflow.

The third option is medium migration. This is useful when the earlier PACS used tapes or jukebox as a medium for its long-term archive. In such scenarios, the tapes, jukeboxes, etc., are handed over to the migration vendor for migration. Though the method can be fast, it will not have data records available for review or prefetch.

The fourth and the most expensive methodology is performing a non-DICOM migration—moving the raw database and image sets of the old archive.

Has the problems related to archiving shifted?

The recent arrival and immediate acceptance of VNA raises an important question. Are departments now stuck with a VNA vendor? Initial experiences the world over indicate that this may not be so. Rather, VNA advantageously ensures the following:

All files are stored in a compatible DICOM 3.0 format.

The DICOM DIR format is utilized to store data in VNA.

The database schema is, importantly, open and shared with the customer. The customer additionally has the option to choose a preferred database (e.g., Oracle, DB2, My SQL, etc.) for the VNA.

The customer can write their own applications and adapters. They can pull and push images in EMR, HIS, etc., conveniently, using VNA

Differences Between DICOM Archive and VNA

There are few differences between archiving as DICOM and VNA even though they both fulfill the basic needs of storage.

VNA is able to perform “context management.” This term denotes the ability of VNAs to present data in a format that is different from the original stored format.

DICOM archive does not interface with RIS and/or HIS, whereas VNA can be interfaced with RIS and/or HIS.

DICOM archive stores only DICOM objects, whereas VNA stores DICOM objects as well as non-DICOM objects such as from.pdf, scanned documents, etc.

Future of Archiving with VNA

In the end, VNA is an archive that has been developed on an open architecture. It can be easily migrated, ported to interface with another vendor's viewing, acquisition, and workflow engine to manage medical images and related information.[67]

Besides images sourced from radiology, the latest PACS will allow storage of images from other sources such as endoscopes, opthalmoscopes, bronchoscopes, and from the departments of dermatology, pathology, etc., An emerging term for such images is “Visible Lights.”

Among the companies that have taken the lead in adoption of the VNA architecture are Carestream, Acuo, Dejarnette, Mach 7, Meddiff, Terra Medica, GE, etc., Some of the storage companies such as EMC, IBM, HP, and Hitachi have also come forward with their VNA-based storage solutions.

Summary

Finally, a section of industry believes that “vendor neutral” may not be a suitable term to describe these significant changes in archiving. The better and preferred term may be “architecture neutral,” “PACS neutral,” “content neutral,” or “third-party neutral.” Notwithstanding this, the VNA acronym has come to stay in both the medical IT user's jargon and in vendor nomenclature, and radiologists need to be aware of its impact in PACS across the globe.