View source for Vendor Independent Archive Architecture for Imaging (VIAA-I) - Proposal

__NOTOC__

==1. Proposed Workitem: Vendor Independent Archive Architecture for Imaging (VIAA-I)==

* Proposal Editor: Fred Behlen
* Editor: TBA
* Date:    N/A (Wiki keeps history)
* Version: N/A (Wiki keeps history)
* Domain: Radiology
[[Category:RAD]]

==2. The Problem==

Today’s healthcare providers need flexible imaging connectivity to meet the demands of constantly changing referral and consulting relationships, as well as for the requirements and incentives of Meaningful Use.  At the same time, they want the security and flexibility of having possession and control of their own data over periods of times that exceed the lifetime of any single clinical applications system.

The name Vendor Independent Archive Architecture is chosen because any storage system that causes the customer to go through a vendor application to access and use data is vendor dependent.  True vendor independence requires that the data is stored in interchangeable storage systems and accessed and managed by multiple clinical applications systems from multiple vendors.  Therefore, it follows that a truly vendor independent archive cannot be a product, but rather a specification that can be supported by multiple vendors.

It is desirable to find solutions that can allow existing bulk image data to be used in successor systems. Storage formats vary, but there is substantial commonality of implementations that could allow existing storage objects to be usable by the successor applications if metadata update issues can be resolved. 

The costs of vendor dependence are manifested in:
* barriers to decommissioning PACS, applications and storage systems
* barriers to adopting and connecting new clinical applications: e.g. analytics and other specialty applications
* risks of unsynchronized patient data in PACS and EHR systems

The VIAA is an infrastructure extension of XDS proposed for the ITI domain. This VIAA-I proposal defines content profiles for DICOM data in the VIAA. The value is more freedom to select applications and to federate systems within the enterprise, with minimal dependence on vendors for archive middleware.

VIAA-I together with the ITI VIAA overcomes proprietary barriers to innovative applications that analyze and display patient data for clinical use. 

==3. Key Use Case==

'''Migration:''' A Radiology department adopts a new PACS product.   The new PACS can access the existing imaging data and the VIAA Registry with no need to physically move the data. If new physical storage is purchased, the data can be moved to the new platform with a quick and low cost bulk copy at high speed.

'''Federated imaging access:''' An expanding health system has collected data from acquired facilities into multiple image archives operating as VIAA Document Sources. A VIAA Document Consumer can act as a gateway, presenting a federated view of documents and images to the enterprise’s users.

'''Analytics:''' An enterprise has multiple clinical systems acting as VIAA Document Sources. An enterprise analytics system can mine the VIAA data without loading, interfering with, or depending on those clinical systems. Analytics adoption can improve business and quality processes.

==4. Standards and Systems==

Existing systems involved include:
* PACS, Specialty Imaging Applications/Workstations (post-processing workflow), Analytics, Whole Slide Imaging, Labs, Physical Storage, COTS Relational Databases

Standards used include:
* Standards include XDS, XDS-I, IOCM, DICOM, CDA, file access standards (CIFS, NFS, HTTP (RESTful storage services) ), SQL or NoSQL
* This is a new profile that does not anticipate a need to change existing profiles or standards
* This profile is dependent on the propose VIAA Profile in the IHE IT Infrastructure Domain

==5. Discussion==

The ITI VIAA proposal defines XDS extensions for managing and sharing unstructured patient data objects.  This Radiology proposal defines transactions and content profiles for storing DICOM objects and metadata for sharing in a VIAA repository.  IHE XDS and XDS-I provide the sematic framework for the VIAA data specification.  The core of the VIAA proposal is the combination of network accessible shared storage resources with a metadata registry to index. The VIAA Registry is a relational database instantiation of the XDS standard with minimal extensions.  Most commercial PACS and archive products are already compliant with the proposed VIAA Storage specification, and will require only a VIAA Registry interface to participate in VIAA-I.

Storage formats vary, though there is substantial commonality of existing implementations to store standard Part 10 file formats, individually or bundled in archive files. Similarly, updates that are contained in the PACS database can for most implementations be represented in a common format in the VIAA Registry.  Thus, content profiles can allow direct access to images within such common PACS file formats.  Private content formats may also be stored with VIAA-I, although their interoperability may be limited to applications that understand the private format.

DICOM storage in the VIAA-I is compatible with the IHE XDS.b-I Profile.  In XDS.b-I, a DICOM Study is shared by storing and registering a DICOM Key Object Selection (KOS, or “KO”) object, using the IHE transaction Provide & Register Imaging Document Set – MTOM-XOP [Rad-68].  The KOS object is a manifest that lists all SOP instances in the Study and provides a pointer to a DICOM repository from which the Study may be retrieved.  Similarly, in the VIAA an extended KOS object is included in the registration transaction. 
 
A VIAA registration transaction always registers a complete DICOM Study as it exists at the time of registration, by creating a DocumentEntry for each of the DICOM data BLOBs, a SubmissionSet for the entire submission, and SetLink records linking the SubmissionSet to each DocumentEntry.  Of course, additional DICOM Instances may be added to the Study at a later time, and the source system would then perform an additional transaction to add the additional instances.  In such a case, the additional instances are registered in a second Submission Set including a new KOS manifest object with a DocumentLink of type REPLACE, thus deprecating the original KOS manifest and including by-reference the other original registered objects.