Whitepaper: What Should the NHS Expect from VNA?

How the NHS can benefit from an enhanced approach to long-term Digital Medical Image Management

About the Author

Jamie Clifton is the Director of Product Management for BridgeHead Software. Jamie has been involved with Enterprise Data management for 10 years for many of the world’s foremost software companies. He currently drives the product strategy for BridgeHead’s archiving and m backup product lines into the healthcare sector focusing specifically on business continuity, Vendor Neutral Archiving (VNA) and Cross Enterprise Document Sharing (XDS). Jamie holds BSc (Hons) degree in Computing Science and Economics.

Executive Summary

Change is coming to the NHS. The management of medical image data is just one area among many that will be affected, albeit a highly important one. Wrongly handled, it could have an adverse effect both on patient care and cost control.

VNA allows, often for the first time, the opportunity to introduce common standards across varying PACS applications – standards that will improve effectiveness and address CIO concerns about information ownership by giving them greater access and more control over their base data

Previously, the NHS and Connecting for Health have proposed a centralised system for Picture Archiving and Communications System (PACS) data storage, one in which a few larger data centres manage the nation’s medical imaging content, and this is the situation deployed today. Originally intended to make sharing data more effective, this centralised approach has one major downside: it is a single-use system unable to cope with the critical data management requirements needed to sustain business continuity and protect these vital assets. In talking to PACS users, it seems they are looking for an ecosystem that:

• Reduces the cost of storage
• Reduces the number of systems they own
• Meets internal SLAs for their clinicians’ access
• Enables a robust plan for disaster recovery
• ensures PACS data has policies consistent with other IT systems

Essentially PACS users would like to take ownership of data and make decisions about its management that are right for their particular organisation

The Vendor Neutral Archive (VNA) is, I believe, a credible and effective response to these concerns. It will minimise storage costs, standardise data protection and allow continued improvements in content interoperability.

VNA is not a ‘one-size-fits-all’ solution, it will differ according to the goals and requirements of each trust; goals which are influenced by diverse factors eg an ageing population or differing regional risk factors

VNA is a necessary response to the difficulty of managing the archiving of medical images; it complements and supersedes the original ‘A’ in PACS. It allows (often for the first time) the opportunity to introduce common standards across varying PACS applications – standards that will improve effectiveness and address CIO concerns about information ownership by giving them greater access and more control over their base data.

Precise definitions of VNA will vary from one expert to another. However, underpinning these definitions is a critical set of imperatives that a VNA needs to guarantee, such as:

• Creating an independent archive for all medical images and electronic patient records
• Ensuring advanced storage management, independent of any single vendor or technology
• The ability to ingest data that is standards-based (DICOM, HL7, XDS etc)
• Facilitating disaster recovery of medical image data
• Using multiple access methods (DICOM, XDS, SQL, custom APIs etc)
• Laying the foundations for better – and more secure – data sharing
• Offering a full audit trail and security
• Integration into a standard HL7 infrastructure
• Being open as regards the data stored in it

VNA is not a ‘one-size-fits-all’ solution, it will differ according to the goals and requirements of each trust; goals which are influenced by diverse factors eg an ageing population or differing regional risk factors.

Some feature requirements will, however, be common for many organisations, such as:

• Locally integrating the archive across different content creators (eg PACS)
• Creating a high performing local storage cache of new, ‘live’ content
• deploying lower cost storage for the older, more static1 content

The transition of data between these tiers should be a seamless service offered by the VNA.

In addition there is an overarching need to share data nationally. This can be achieved in one of three ways:

• Federating searches across each regional VNA. This is where deploying standards such as XDS(i) are becoming increasingly adopted
• Moving older data to a central location. The problem with a single central archive approach as a solution to sharing content is that it is far from efficient. It is estimated that only 5% of content is ever shared, but with a centralised approach, 100% of the content must be moved to this location, which is inefficient. However, solutions such as XDS don’t require the wholesale movement of content to facilitate sharing making it potentially more cost effective
• Using a combination of both of the above. For example, a large city hospital, effectively managing smaller sites, may determine that both methods will give the best, most comprehensive solution

Deployment of a VNA will provide both a necessary and a major boost to the effective long-term storage, management and protection of medical image data. However, it is not a complete panacea. There will still be challenges that each region must see solved e.g. the recognition and resolution of patient ID errors and the ability to interpret data across disparate vendor solutions.

However, the overall effect of the VNA will, I believe, be massively beneficial to the NHS.

Introduction: the Changing Face of Medical Imaging in the NHS

Change is coming to the NHS – and with it a whole new range of potential service provision and technology options. The management of PACS data is just one area among many that will be affected. It is, however, a highly-important one. Wrongly handled, it could have an adverse effect both on patient care and cost control.

Deployment of a VNA will provide both a necessary and a major boost to the effective long-term storage, management and protection of medical image data

There are many elements that go to make up the PACS ecosystem and this paper will focus not on the provision of PACS itself (e.g. modalities and workflow), but on the long-term retention, protection and interoperability of the data generated by PACS. Any changes or improvements to the PACS ecosystem should improve patient care. Although the retention of PACS data is by no means ‘patient facing’, it is causing such challenges that in some more commercially oriented healthcare environments, the cost of this storage is adversely shaping the long-term economic viability of PACS.

A Vendor Neutral Archive (VNA) is being heralded, worldwide, as the solution to this problem. This paper will examine what a VNA is and how its adoption could help the NHS.

The situation today

Until now, the NHS (or rather Connecting for Health (CfH)) has in the past favoured a centralised model for PACS archive storage, one in which a few large data centres manage the nation’s medical imaging content. However, as contracts transition in 2013, the NHS has the ideal opportunity to change this significantly.

The reason (potentially the only reason) that centralisation was deemed necessary was to facilitate sharing of medical image data throughout the NHS. So let us ask the question “has better content sharing been achieved?”

Most CIOs that I speak to express the concern that their PACS providers effectively limit their local access to PACS data – if only via the contracts that are in place with the LSPs meaning they have to seek approval for even the smallest change to the way they manage this content. They feel like the PACS providers effectively own and control their PACS data. As a consequence, even though the NHS does now have a better ability to share PACS data than it did several years ago (if only because several years ago the answer was to post DVDs), the realisation of this potential benefit remains elusive. A medical image archive should not only be able to deliver data sharing capabilities, but many other benefits to a trust. Yet, today none of these are being realised.

To illustrate this point, let’s examine one of the critical activities that PACS owners have to manage: disaster recovery (DR). My colleagues and I visit hospitals on a regular basis where the relevant staff members are aware they are not fully protecting their PACS data; it is too large and existing disaster recovery tools cannot cope. You would imagine that the second copy of data stored offsite with the LSP would contribute to solving the disaster recovery issue? Sadly, it does not. As any trust that has had a significant data loss will tell you, if you try recovery from the central store, your PACS will be unable to cope2. The LSP data centre was never designed to be a disaster recovery solution.

Logically, these central repositories should have been able to offer more – they have not, at least not for trusts who are constantly striving for increased efficiencies and wanting ‘to do more with less’.

PACS: the challenges

Bearing in mind that our sole focus here is the storage and management of data, what are the key problems PACS owners would like to solve? While the main emphasis of this paper is on the NHS, my experience suggests that healthcare IT departments, the world over, voice similar concerns. These are:

¬
• Reducing the cost of storage : This could be as simple as using the most appropriate storage for the data and data access profile that an organisation is faced with. A large proportion of the data healthcare owns is rarely accessed so offline storage3 could save considerable amounts of money, with (if implemented correctly) little or no loss of performance
¬
• Reducing the number of systems they own : Traditionally, healthcare applications were purchased and run departmentally, often by non-IT staff. This has created resource and management silos. CIOs want to be able to standardise across applications and reduce both the physical and the management costs
¬
• Setting SLAs for their clinicians’ access : An SLA of less than three seconds to access an image is the one most cited by Radiologists. However, we need to remember that, for clinicians, performance may well be the number one requirement. Yet, for the hospital at large, it is just one concern among many, not least of which is the cost to maintain such performance
• Creating a robust plan for business continuity in the event of data loss and ensuring PACS data has policies consistent with other IT systems Disaster Recovery (DR) planning is both critical and complex. The more segregated the applications an organisation owns, the more complex disaster recovery becomes. Being able to create standardised policies, with standardised tools, would greatly aid hospitals in a swifter recovery in the event of a disaster
¬
• Taking ownership of data and making decisions about its management that are right for a particular organisation : Clinical decisions are becoming increasingly dependent on data. So too is the effective running of a hospital. Therefore, a CIO needs to make data available to whoever wants, it whenever they want it, albeit in a controlled, secure and cost-effective manner. In the quest for a complete and accessible Electronic Healthcare Record (EHR), data silos cannot continue to exist

The Vendor Neutral Archive

VNA is a vague phrase that often leads to misinterpretation and, as a consequence, to mistrust. At its simplest, a VNA could be summarised as a necessary response to the difficulty of managing the archiving part of the overall PACS

The concept of PACS is approaching its third decade, developed in a time when the demands placed upon it were very different. As the explosion in data really started to become apparent, there was a strong push to separate the workflow, modality management and workstation integration of PACS from the storage and protection of PACS data.

Additionally, PACS was originally synonymous with Radiology, as this was the first discipline to digitise. Today, however, almost every other medical imaging or medical observation system has gone digital, many adopting DICOM. While Radiology is still the biggest creator of content today, it is widely expected that Digital Pathology will rapidly overtake it. In this context, continuing to simply ship separated storage with each PACS-like system is not a scalable option.

The Vendor Neutral Archive (VNA) is, I believe, a credible and effective solution to these problems, in particular for the NHS. There are three main reasons for this:

• Storage costs will be minimised : Storage is growing exponentially as more diagnostic images are taken and their density increases. As a consequence, the cost of storing this content will also dramatically increase. However, a VNA should ensure that this rise in costs is kept to a minimum by ensuring the most appropriate storage systems are used and, importantly, that storage provision is not a dominant concern within the PACS ecosystem
• Continued improvements in content interoperability : The VNA may provide most of its benefits inside the hospital walls, but creating a group repository of content (regional or central) can make sharing data more efficient. The VNA should be able to accept content from many sources, share data by physical re-location (for example, to a group store) or by advertising its availability for interrogation (for example, through XDS(i)). However this is done, content movement and availability will be insulated from the production PACS and managed directly by the VNA
• Standardised data protection : Healthcare generates a large amount of static content. Traditional backup solutions are not ideally suited to protect this kind of data, in this volume. The VNA should allow better, easier protection of this largely inactive content, making the creation of an effective disaster recovery strategy a reality, not a myth

Like ‘Cloud’, VNA is a vague phrase that often leads to misinterpretation and, as a consequence, to mistrust. At its simplest, a VNA could be summarised as a necessary response to the difficulty of managing the archiving part of the overall PACS.

Thus, to return to a favourite theme of CIOs, the overall benefit of deploying VNA should be the ability to ‘do more with less’ and to do it better.

The standards bonus

My general view is that in order for the VNA to be successful it should focus on ‘archiving’, not altering or interpreting content – this is what the PACS is already doing

Part of VNA’s contribution to effectiveness will come in the form of standards. In the past PACS providers did not really have to disclose what they were doing internally: the system was a ‘black box’. As it evolves the EHR will not only span more than one PACS, but also a wider range of data that is fundamental to the trust’s patient management and diagnoses. In this environment ‘black boxes’ have no part – this is where standards come in.

VNA can be the vehicle to set and reinforce standards. Essentially, if you have a VNA, you can mandate that all PACS providers interact with it to the standards you set. More bluntly, if a hospital implements a VNA, it can enforce standards. This should re-establish data ownership – an important response to NHS Trusts who may believe that the PACS vendor effectively owns their image data.

Clearly, these standards are not going to be developed from scratch. They will be based on DICOM, HL7 and possibly XDS. A VNA-based approach, at the very least, will allow a clear standards-based platform to be created and built on which, in turn, should lower costs and increase the efficiency of data sharing. This enforcement of standards is essential if we are to build the patient record from disparate sources. Achieving this alone would make VNA adoption worthwhile. But VNA has much more to offer, as we shall see.

The key characteristics of a VNA

Below are what I believe can and will be the critical features of a VNA. All are features that will add value to the healthcare organisation:

• 1. A VNA will create an independent archive for all medical images and electronic patient record data Radiology is the obvious beneficiary of a VNA, but other clinical data will also benefit from being in a controlled and regulated archive. All clinical and administration files, as well as other medical image files outside radiology, need the same cover. An NHS Trust has many sources of data all of which need to be accessed, managed and protected in a consistent fashion
• 2. A VNA will ensure advanced storage management independent of any single storage vendor The VNA should ‘virtualise’ storage from the application. This would allow IT to manage storage provision without adversely affecting the application that created the data. This storage independence will allow data to be held more efficiently (using compression and de-duping) and migrated more easily as hardware technology changes. Regardless of storage technology or vendor, a VNA should be able to apply a standard set of advanced data management actions across all storage platforms transparent to the application using the data
• 3. A VNA will ingest data that is standards based (DICOM, HL7, XDS etc.) It seems obvious, but bears repeating: a VNA is a healthcare application. Therefore, it should speak the language of healthcare. It should offer custom integration APIs, but must provide standards-based protocols
• 4. A VNA will improve disaster recovery of medical image and clinical data. The VNA itself should be highly resilient to disaster (geo-disbursed, multi-copy, for example) and have clearly documented steps for recovery. It should also have facilities to recover any data, of any size, lost by the user or the application
• 5. A VNA will use multiple access methods (DICOM, XDS, SQL, custom APIs etc.) Data should be stored in the format in which it was sent, but the VNA should give options for accessing this content using multiple methods. For example, DICOM could be ingested by the DICOM protocol, but accessed via HTTP; or DICOM could be found in a file system, but accessed by the protocol
• 6. A VNA will lay the foundations for better sharing The VNA cannot tell you how to share data, but it should be open and flexible enough to facilitate sharing. For example, it could integrate with XDS/ XDS(i) or allow multiple applications to safely query a single dataset. It also needs to ensure that all data can be found by every appropriate application; this means agreeing internal meta-data taxonomy. But, once agreed, this can be administered through the VNA Consideration should be given to onward usage of content, for example, DICOM-based viewing. The VNA should store what it is given and should not materially alter this content in order to ensure regulatory compliance. In fact, the VNA can be used to enforce the DICOM standard to ensure that data is compliant, consistent and always searchable. However, storing data and making it available for search is one thing, but interpreting the data for use, when not the originating application, is another. In this regard, there is much debate on where responsibility lies for data translation: Should the VNA deploy tag morphing? Should the opening application be able to recognise content from others? Should the viewer be the translation platform? Should the VNA refuse to accept content that does not conform to a pre-described standard?
• 7. A VNA will be fully auditable and secure Organisations, and indeed vendors, will have to examine areas around data governance that they did not have to deal with given the closed nature of the current LSP contract. Most PACS vendors have implemented, or are implementing, the DICOM Storage Commitment to ensure that DICOM data is safely committed to external storage. But the integrity of the data still needs to be maintained once responsibility is transferred. Encryption, auditing and user authentication are all areas that a VNA should be capable of providing
• 8. A VNA will be integrated into HL7 infrastructure It may seem self-evident, but it needs to be stated: DICOM by itself is not enough. The VNA should be able to use the HL7 feed to trigger events that act on the DICOM data stored. At a minimum, the two HL7 events that the VNA should respond to are: Pre-fetch requests: these should be scripted and flexible in their actions; Patient merge and update: to ensure the data is kept current
• 9. The underlying data schema should be published This may not (and probably should not) be public, but a vendor should provide all the knowledge a hospital will need to recover all data from storage – without reference to the vendor, without the application running and with the ability to overcome obstacles such as encrypted content. This will reassure an organisation that, whatever decisions it makes in the future, it knows it owns its data.

Deploying the VNA in the NHS

Few if any of the concepts we have spoken about are new or revolutionary. What is unique is that they come together in VNA. That is not to say that, when a Trust adopts a VNA, one size is going to fit all. Each Trust will have its own set of goals and requirements that will influence how they define a VNA. All will aim to give the highest level of care, of course. However, other factors may shape how they deliver services or manage solutions. For example, a high number of elderly patients may influence service delivery in one area, but a greater risk of disaster may be the main concern in another.

Fixing local issues first

The Vendor Neutral Archive is, I believe, a credible and effective solution to these problems, in particular for the NHS

The important starting point for a VNA deployed in the NHS is that it must start at the local level. It is highly likely that cloud services such as Master Patient Index (MPI) or storage will be part of the overall solution but, in order to effectively consume these services, the VNA must bridge the gap between the local PACS and the remote services (especially with Cloud storage)which will be generally slower.

Once the PACS considers a study ‘complete’ then it would send a copy of this data over to the VNA, likely via DICOM C-Store. The PACS may additionally keep a copy on Storage Area Network (SAN) if it is considered likely to be called regularly or edited in some way, meaning the PACS itself is likely to have a small working copy cache, with all studies sent to the VNA.

The VNA will virtualise storage and protection across all content creators and, at the same time, ensure that speed of service is still met. Worldwide clinicians demand rapid access to content, usually less than three seconds, and since Cloud tends to be slower than local storage, managing this at a local level is an essential starting point.

Data policy services, again running locally, can then be used to copy content between storage systems, invisibly to the end application – meaning if content was originally stored on local Network Attached Storage (NAS) system and later needed to be copied or moved to lower cost Cloud storage as it ages, then this is easily achieved. This is another key concept in storage virtualisation, resulting in minimising the use of costly local storage while the exponential part of data growth can take place in the most cost effective location, maybe the cloud.

Recalling content

The VNA will be registered with each PACS. As a result, the PACS will know the data it wishes to recall (since it created it), but if that data has been moved out to the cloud, or maybe even to offline storage, then how do we ensure it is recalled promptly?

The VNA should be monitoring to what is happening in the organisation, and it will do this by listening to HL7 traffic. Even in ‘walk-in’ clinics, the first thing a patient does is register their arrival. This generates HL7 traffic which the VNA can respond to and ensure suitable content is called back from the Cloud to local storage, where SLAs can be met. This is known as ‘pre-fetch’.

Many people see pre-fetch as a ‘night before operation’, but most Cloud systems will respond within a minute and most tape libraries within 5 minutes, so the head start needed in recalling content does not have to be great. This means even walk-in clinics and A&E should rarely, if ever, be compromised.

In addition to general use, hospitals may be recalling content for disaster recovery reasons. Consequently, the VNA should keep multiple copies of content, in multiple locations, such that if any content is lost, it can be seamlessly rebuilt from the other copies.

Wide area sharing and access

As the diagram shows, it is not just storage that is provided by the Cloud. Many of the management services that the VNA and PACS depend upon may also be supplied in the Cloud. Generally it will be the PACS, as the manager of workflow, that consumes these services, not the VNA – especially regarding the Master Patient Index (MPI).

However, while the requirement to talk to the MPI clearly lies with the PACS, the VNA needs to listen to and accept HL7 traffic, so that it can perform such actions as ‘pre-fetch’ and ‘patient merge and update’. In this way, data management and, in particular, data integrity can be maintained by the VNA independently of the overall workflow, which is the province of the PACS.

Sharing of data is another area where the VNA may directly interact with Cloud services. As the VNA receives content, it can register this as available for sharing with a central (possibly XDS) registry. Now, any remote requests through the registry for this content will be serviced directly by the VNA, isolating and removing load from the local PACS.

In this same way, if the local PACS wants remote content, it would query the (XDS) Registry (plus associated MPI lookups), and recall content directly from the remote system’s VNA. The local PACS may subsequently determine to pass this content to its local VNA instance or it may decide that this content should not be retained locally.

Viewing of content

During this conversation we will encounter the question “how do I view DICOM content that I didn’t create and I may not understand?”

My general view is that in order for the VNA to be successful it should focus on ‘archiving’, not altering or interpreting content – this is what the PACS is already doing. The VNA can offer bi-directional tag morphing, but there are some serious questions that need answering before this is implemented:

• 1. Why are the PACS vendors using non-standard tags, even private tags? If they are using them, does the NHS have their usage fully documented?
• 2. Changing tags is easy, knowing what to change them to is hard. Who is tasked with ensuring that the morphing is correct in the beginning, then constantly upgraded and tested for all combinations of images you could meet in the future?
• 3. If the PACS cannot convert images (and they all can) then the most efficient way of doing this is at the viewing stage: and the rise of the uni-viewer is addressing this issue. Companies that are skilled in viewer technology have the most experience in how to morph tags

VNA as a Cloud service

The diagram above is very simple, and I would expect that more than one organisation will share a single VNA – likely to be deployed at a city or local county level. Very large hospitals may have the requirement to have their own, but typically we see them offering VNA services out to smaller satellite facilities.

The important starting point for a VNA deployed in the NHS is that it must start at the local level

In principle, VNA could be deployed as a single, national service but this would reduce the interconnection with the local PACS and it would be hard for the individual trusts to consume this service efficiently.

With the advent of XDS(i), there is little reason for a single national VNA because with the localised approach data is still available nationally, albeit managed and, for the most part, consumed regionally – which, after all, is where 95% of the access will be anyway.

Conclusion

The likelihood is that no single model of VNA will fit every circumstance; each hospital or Trust will have to define a VNA in relation to its needs. There will also be questions to resolve, such as ID, tagging and ownership. However, the present situation, in relation to long-term storage and management of data is, I believe, untenable. The overall effect of the VNA will, therefore, be massively beneficial to the NHS. I have covered a number of aspects of the VNA in these pages but at its simplest, three basic points summarise the benefits the NHS should see from the adoption of VNA:

• Storage costs will be minimised
• Data protection will be standardised
• Content interoperability will be improved

Deployment: a summary

There is much more detail that is needed when designing a VNA solution for a department, hospital or a region and each organisation may make different decisions. An overall summary of the deployment stages is:

• 1. VNA is likely to be deployed at the trust or trust group level
• 2. It will interact with regional and national services (for example, by sharing registries)
• 3. It will enable easier consumption of all storage offerings, including cloud
• 4. It will be part of the overall model for sharing PACS data
• 5. It will have disaster recovery built into its design and also be able to accept other non-DICOM content types (a subject we have not discussed in this paper)

References

1 BridgeHead defi nes static content as older content that is unlikely to be accessed again and in most cases cannot be altered. Dynamic content would be the opposite to this, and dynamic content often ages and becomes static over time

2 There are instances of trust’s trying to recall large amounts of data from the existing central archive, to recover from failure, but the PACS isn’t able to cope. This is generally caused by many and frequent DICOM timeout issues

3 DVD or tape for example.Generally any storage system that limits the amount of ‘spinning’ the media is required to do when not in direct use

Companies

• BridgeHead Software Limited