After understanding the desired scope of Enterprise Reporting (EI) and putting a foundational strategy in place, the major technical components of EI can be reviewed and a list of desirable attributes created. Having the attributes defined for the initial implementation as well as for the future expansion of EI will enable the organization to develop successful criteria for vendors to bid on.
Typically, the central component of an EI implementation is the Vendor Neutral Archive (VNA). The VNA is defined as:
“A medical device that stores medical images in a standard format with a standard interface, such that they can be accessed in a vendor-neutral manner by other systems.”
So-called “vendor neutrality” is implied by the standard format and interface, and the neutrality is with respect to vendor-specific devices that produce or consume those images (e.g., for display, distribution or analysis, with or without specific workflows, such as for radiology reporting, i.e., a PACS).
The VNA should allow any type of image file to be saved and retrieved from the VNA. Such files can be DICOM images from radiology, cardiology or ophthalmology; MPEG videos from surgery or pictures documenting skin conditions or wound care (JPEG, TIFF, PNG, etc.); or EEG and ECG/EKG PDF files. The VNA should not care what file format is being delivered and should retain the native format so the image can be returned to the originator in its original format when needed.
To achieve this, the captured image needs be tagged with sufficient data to identify the image, the person it is associated with, the date and time it was taken, the event that it is associated with (gallstone surgery, diagnostic X-ray for a possible fracture, burn wound healing, bed sore, etc.), and possible other desired parameters. This data is referred to as metadata – or data about the data – and are tagged to the image(s). These tags are important for linking the image to a patient or an encounter and enable the database to support data mining and highly specific retrieval. A VNA solution can provide much more effective and specific linking of images to a patient record, visit or procedure than images captured as BLOBs (Binary Large Object) frequently used by EMRs.
Many vendors now offer VNAs, with many having their roots in a PACS archive that was used for storage of DICOM images. These tend to encapsulate incoming images with a DICOM wrapper in order to process the image like any other DICOM file. DICOM has the advantage of storing all metadata directly in the image header, thus ensuring the image can always be displayed with the same fidelity as when it was initially stored. Some systems will store the file in its original format and as a DICOM image. Systems that don’t use DICOM wrapping will have a system to capture the metadata in a separate file that is then linked to the image file in the VNA database. The organization should determine the type of VNA they choose to have – one that stores everything in DICOM or one that stores the files directly in the images’ native format (including DICOM images), plus a metadata file when needed.
Possibly more important than the storage methodology are the protocols and workflows used to capture and retrieve the images. This provides the end user with tools to quickly and efficiently capture and store images but also retrieve them with greater ease. In the past few years new image handling protocols have been added such as Web Access to DICOM Persistent Objects (WADO), which allows querying and retrieving of images using the standard HTTP/HTTPS protocols or XDS-I.b, a SOAP Web Service based on protocols developed by Integrating the Healthcare Enterprise’s (IHE) Cross Enterprise Document Sharing (XDS) for imaging. XDS is becoming a cornerstone for successfully sharing documents (including images) within and between organizations.
Thinking through the workflows for each environment can reduce unwanted surprises, technical hurdles and user dissatisfaction. Each type of image capture will need to be addressed separately and engage the current users. Questions to ask each group of image producers and consumers include:
- Does your existing software work as desired?
- Does the existing workflow support the ideal workflow in your environment?
- Are the users productive and satisfied with the existing solution?
- What would they like to see to improve the current environment?
Specialties that already are using a PACS system may be the easiest to integrate with the VNA. Modern DICOM-based systems can leverage Imaging Object Change Management (IOCM), which most PACS vendors now support with their current software version. IOCM ensures updates that occur in the VNA or the PACS are also updating the other system. Reviewing the tools available in a vendor’s VNA offering is crucial when dealing with images that aren’t being ordered (this is also known as encounter-based imaging). This includes many point of care (POC) image acquisition systems that require tools to facilitate the generation of metadata using existing patient and visit information without disrupting the clinical workflow. The goal is to minimize the amount of manual entry needed to capture a fully defined image.
One big VNA benefit is that it provides a simplified interface between the EMR and the image store, reducing the number of interfaces that typically need to be maintained and monitored. With this single store, backup and/or high-availability solutions are greatly streamlined. Rather than finding solutions for each data store within the organization, the VNA can act as the data backup to all specialty systems and data sources. Moving images that have been stored in cameras, on memory sticks, on DVD, or desktop computers to the VNA can reduce data liability by ensuring images are:
- Monitored for access
- Removed when data becomes obsolete
- Identified for critical images
- Backed up
VNAs allow the use of best-of-breed specialty systems by moving the image archival to a central location. It should be noted that integration may suffer limitations if image source systems are not designed for bidirectional interaction with a VNA.
When starting the process of VNA selection, the existing data volume and data acquisition velocity (fresh data acquired annually) needs to be assessed. This will help ensure initial sizing and system scaling can be addressed. If the organization is hosting the data store, hardware vendors need to disclose when they plan to sunset or replace their current storage systems, as it makes no sense to invest in a platform that the vendor may sunset in one or two years.
Running through these steps with your various clinical and IT groups will help define the VNA requirements for a request for proposal (RFP). VNA systems are not cheap and attention to the details will ensure the investment can last for an extended period and deliver the desired functionality.
The next blog in this series will review considerations around data quality, data management and data migration from existing storage environments.