How the NHS can benefit from an enhanced approach to long-term Digital Medical Image Management
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.
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:
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:
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:
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:
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.
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.
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’.
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:
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:
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.
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.
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:
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.
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.
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.
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.
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:
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.
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:
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 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