One of the ideals behind a Vendor Neutral Archive (VNA) is that the data will be in a standards-based format making it available to any application that complies with the DICOM standard. So, in theory, once the data has been migrated from a proprietary archive to a VNA, it is simply the case of pointing a new PACS at it – making expensive and time-consuming migrations a thing of the past. The other great aspiration is that, once in a central VNA, any DICOM application can access the data, thus facilitating sharing between organisations.
In order to achieve these goals, two things are required: a rigorous compliance to the DICOM standard; and a high level of data integrity, standardisation and currency.
The data quality within an enterprise is compromised by legacy data, errors, manual entry and workarounds. It is further compromised by integration between systems, often breaking down the data standardisation to the lowest common denominator that can be exchanged across the PACS environment. During integration, workarounds are applied to address incompatibilities in one or more systems or the transfer protocol used (typically HL7 and DICOM). Examples include: variation lengths of data fields and data types; unsupported characters; duplicate and omissions of data in mandatory fields; inconsistent order of multi-value fields; inconsistent coded values; non-compliance to standards by the applications; non-unique and inconsistent primary IDs; and so on.
Once in the archive, the data in the VNA needs to be maintained to ensure its integrity and that it's current across all the systems in the local PACS environment. In order to replace the PACS, all the available data must be available for migration. This includes files, current meta-data and additional clinical data held in the PACS. For sharing, the data must be accurate and up-to-date. Its format must be compatible with all systems across the enterprise – this is particularly true for identifiers and coded data. It will also need enterprise-wide version control.
In summary, data quality and compliance to a global standard is at the heart of a good VNA implementation. In reality, not all systems, including many PACS, are fully compliant with DICOM and HL7; therefore, compromises and workarounds are required to address all these issues. The integration of PACS, with it’s own VNA, will be defined by the PACS application’s level of compliance to the HL7 and DICOM standards, its local implementation, the integration of all the other systems involved (including modalities), and the underlying quality of the source data. The ability of a PACS vendor to resolve all these issues and implement a successful enterprise PACS solution presents a challenge to an independent provider of a truly vendor neutral archive.
Should VNA providers enforce standards compliance or find the best compromise?
To be more specific – should a VNA provider enforce both strict DICOM compliance and a high standard of data integrity and standardisation, or find the best compromise? To rigorously enforce compliance to the DICOM standard, and implement a truly vendor neutral archive, three things are required. Firstly (the most contentious), there must be a common interpretation of the standard applied to the VNA and PACS application. Although it is a well-defined standard, it is still open to interpretation. Not all of its components must be implemented and, most importantly, it must incorporate enough flexibility so as to not inhibit progress by allowing private tags, and the introduction (and retirement) of new DICOM Service-Object Pair (SOP) classes to the standard. The second element required is an integration policy where three simple options are available: accept; reject; or fix! Finally a minimum data quality, taxonomy and terminology must be defined and enforced across the enterprise or cross-enterprise environment.
So, what does this mean? BridgeHead has found a number of non-compliant or differing interpretations to the DICOM standard from a number of PACS vendors. A policy of ‘reject’ would make the VNA truly neutral, but incompatible with these PACS. A policy of ‘accept’ would compromise the data and transfer the data quality and integration issues on to the next PACS to resolve (even if it was fully compliant). The same would apply if the policy were to ‘fix’. But, the far bigger problem is the data integrity, currency, taxonomy and terminology across the two or more PACS connected to the VNA. This requires standardisation and cleaning on a monumental scale across legacy systems. Another consideration is the completeness, accuracy and maintenance of the data being passed to the VNA – is it sufficient in the short-term to facilitate PACS-to-VNA-to-PACS migration and the long-term sharing via the VNA?
The VNA can, of course, be integrated with the PACS by turning off strict compliance; however, this would, in effect, tether the VNA to the PACS in its DICOM archive. And, in the absence of the use of DICOM and Grayscale Softcopy Presentation States (GSPS), sharing would be implemented via the PACS rather than the VNA, with a PACS-to-PACS integration via a third party device.
So, should a VNA be vendor neutral by rigorously enforcing standards and data integrity at the expense of interoperability with common PACS implementation? Or, should those standards be dropped to support integration and compromise its neutrality?
BridgeHead’s solution is to remove these problems by using an intermediate system that will map IDs and codes, translate data into standard formats, check for the latest versions and enforce integrity (not too dissimilar to the HL7 integration, and DICOM gateways you can find today in the PACS environment). But, there are some unanswered questions that need to be considered: how will this work when it comes to publishing to cross-enterprise document sharing (XDS) registry? Should the XDS repository (the VNA) be responsible for ‘normalising’ the data published to the registry and delivered to the consumer; and whose version of the truth should the registry and consumers except?
