The key features of a VNA compared to PACS may be summarised,
as:
VNA
|
PACS
(+ other service-based systems)
|
Patient-centred / trans-departmental
|
Service-centred department-based
|
Multiple standards-based – DICOM,
HL7,
non-DICOM etc
|
DICOM and proprietary PACS-based formats
|
Seamless interface with RIS,
HIS and EMR
|
DICOM/HL7 incompatibility issues
|
Accept,
distribute,
display images and medical information from numerous disparate digital systems anywhere
|
Accept,
distribute,
display medical images only from and within the (usually proprietary) PACS
|
Free information / support data-sharing (XDS)
|
Hold information / inhibit data sharing (limited XDS)
|
Aggregate and consolidate enterprise-wide clinical content
|
Separate and fragment partial information
|
Integrate the entire medical enterprise to facilitate EMR
|
Enable the single department but may hamper EMR
|
Transfer data ownership to the facility
|
Preserve data ownership with the department and/or PACS supplier
|
Multiple distributed points of universal access
|
Limited department-centred points of access
|
Universal Viewer – usually web-based / “zero” footprint
|
Specialty-specific viewer – usually system-hardware-based
|
Accelerate and facilitate impending data migration
|
Retard and hamper impending data migration
|
Eliminate further data migrations
|
Perpetuate further data migrations
|
Enable replacement of PACS supplier
|
Obstruct changes of PACS supplier
|
Heal and harmonise diverse patient data across specialties
|
Limited or absent data healing and harmonisation
|
Sophisticated and customized rules-driven intelligence
eg clinical information life-cycle management (ILM)
|
Limited or absent intelligence
|
Traditional PACS has,
in essence,
been developed over decades to do a different and much easier job than a VNA. Aware of the considerable limitations of PACS and in response to the advent of VNA,
some PACS companies have produced Enterprise-Wide PACS,
variously dubbed super-PACS or PACS 2. These enhanced PACS solutions can receive information from non-medical-imaging specialties as well as Non-DICOM files. Even so,
viewing and storing the images are restricted to the PACS and its archive which continues to tie the user to a single PACS supplier and interface.
If VNA seems,
then,
to be the rational response to the greater medical facility’s growing need for comprehensive and immediate patient information at the point-of-care,
why are there so few VNA’s out there? The simple answers are that the developmental challenges of a VNA are massively greater than those of PACS and in many respects the starting point of a mature PACS can be a disadvantage. It is indeed technically and practically difficult and corporately awkward to jettison the relatively limited thinking and associated expertise of decades as well as abandon substantial historic investment. This reality is reflected in the number of PACS companies,
which runs to hundreds worldwide,
compared to true VNA companies which are still only a handful. The predicament of the PACS providers is aggravated when it is realised that much - if not all - of the job of the PACS can be done by a decent VNA but only a small part of the job of the VNA can be done by PACS
Figures 1-to-2 (below) illustrate a simplified evolution of the VNA from its historic precursor,
PACS. Figure 1 is a schematic of some typical variants of traditional PACS,
all of which manifest department-centred vertical architecture. Figure 2 shows how the VNA layer fits logically in the space between the clinical and storage layers in new and existing installations to integrate all the specialties,
to the HIS and RIS and add intelligence to the handling and archiving of clinical content of the patient and around the patient to yield a more comprehensive EMR functionality.
Figures 3/4 (below) shows a schematic of the TeraMedica Evercore® product configuration alongside that of another true VNA to illustrate differences that might be significant in meeting client requirements. While both solutions are truly patient-centred; the chief structural difference is that of the single instance patient record embedded in the TeraMedica EverCore architecture compared to the multiple instance patient record in another example of VNA.
Given that the achievement of true universality,
flexibility and robustness within the VNA are technologically challenging,
a number of companies have in response adopted what appears to be a reduced design and development brief for their VNA. For example,
ascribing a client table to multiple nodes within the organisational matrix - which is an expedient design practice that can be justified for a fixed organisation size and structure - can result in a profusion of tables that becomes problematic or even unmanageable over time,
especially as clinical images and objects proliferate and organisations grow and change. While the proposition of a simplified structure may sound persuasive at the outset the latent complications of multiple-node design may require frequent provider intervention to migrate and delete tables or find and reconnect dissociated structures. Mindful of such eventualities TeraMedica has not watered-down the task but instead embraced a total design philosophy to produce an enduring enterprise VNA with only a single-instance patient entry. VNA project implementation under this philosophy not only minimises external support interventions over time but also massively reduces the dependency burden on the local database administrator. All parties gain.
Beyond the philosophical and logical aspects inherent in the configurations of competing VNA’s,
differences with regard to user requirements can also be found in how alternative suppliers manage clinical content; an important and signal example is in the handling of Non-DICOM objects. While the storing of DICOM Part 10 files is an established procedure well known by PACS and VNA companies alike,
the crucial incorporation of Non-DICOM objects can be handled in a variety of ways that can greatly enable or significantly limit the utility of a VNA. TeraMedica,
for example,
believe that objects should be moved,
stored and retrievable in their native format; a DICOM-object should be stored appropriately as a DICOM-object and a Non-DICOM object in its native Non-DICOM format; a PDF for example - by its nature a document that is universally readable - should be stored and retrieved as a PDF. Perhaps surprisingly,
however,
it is nonetheless the case that some VNA providers encapsulate and store Non-DICOM objects in either proprietary encrypted formats such as .TAR and .ASF while others “wrap” the Non-DICOM object in a .DCM header and then store it in a DICOM format as a newly generated DICOM object. Both of these methods restrict any secondary reading of the object to the VNA when documents in the widely adopted .PDF format,
for example,
should be readable both within and outside of the VNA. Such an approach would seem to defeat the philosophical and practical aims of VNA which are to provide,
as stated at the start of this paper,
universal availability and multiple points of access.