Last year I started a blog series on enterprise image management, or as some like to refer to it, VNA’s (VNA’s Let’s Make a Deal, November 23, 2011 http://www.healthcare-informatics.com/blogs/jlmblog/vnas-lets-make-deal). As promised in that blog, I intend to do a number of blogs addressing various aspects of an enterprise image management application.
Image Lifecycle Management or ILM is often touted as a feature of a VNA application. Storing data in one central location should make it easier to manage the data by reducing the effort associated with keeping track of where the data is. Managing the data separately can also reduce the liability, assuming that it is the only copy of the data. While as promising as this might seem, there is yet no clear-cut definition of what is meant by ILM, or how it will work!
For ILM to be successful there are a number of challenges that must be overcome.
I am reminded by Chris Magyar of Agfa Healthcare that ILM is broader than Document Retention Management, in that there are many uses cases outside of retention/disposition that manage data location, multiple copy management, storage format, integrity tests, etc. Therefore, one needs to focus on more than just document retention when defining ILM. Many of these topics remain to be addressed in terms of a standard definition of ILM.
Deletion Messaging and Synchronization
One of the features described for a VNA is the ability to apply rule sets to determine when data can be removed from the VNA. Theoretically, if the VNA is the common central repository for data, then applying a rule set should be more efficient in terms of data deletion because it can be done in one location. While this may be implemented in the VNA, if attached systems cannot support the capability, there is no guarantee that the deletion will be recognized!
Clearly the best way to address this would be through standards adherence. The ACR/NEMA committee has addressed this through the DICOM Supplement 95: Audit Trail Messages. The problem is that few PACS applications today have implemented this supplement, and it only addresses DICOM images. Clearly, further work will be required to enable all applications to take advantage of ILM features of a VNA. As Tim Kaschinske of BridgeHead Software points out, one example is the work IHE (http://www.ihe.net/Technical_Framework/upload/IHE_RAD_Suppl_IOCM_Rev1-1_TI_2011-05-17.pdf) is doing on Imaging Object Change Management (IOCM), but it will require implementation by the PACS vendors to take hold.
Without a reliable method of communicating between systems, synchronizing the data becomes a challenge. If the data is deleted off the central archive, but a system using that archive is not aware that the data has been removed, there will be illegal references to the data that no longer exists. Also, when do changes take effect? Are they real time or batch transactions? If batch, something might be earmarked for deletion in the cache, when a change in the patient status might change the deletion status.
An effective ILM application is dependent on an effective rule set for study deletion. If there is to be a central repository and consistent rule set, it must take into account all policies impacting retention. For example, consider the legal ramifications if legal holds are not part of the rule set. Similarly, research needs may need to be taken into consideration. Are teaching files excluded from disposition – a significant factor if a study marked for deletion is an important teaching case?
Another factor is the amount of leeway given to the system administrator. Does deletion impact just the database pointer, or does it also delete the images from the archive? Vendors may restrict the amount of authority given to administrators in the belief that there is a liability back to them if information is inadvertently deleted based on a policy implemented by the administrator.
Similarly, how does the system handle changes in policies? If the current retention period changes say from seven to five years, can the rule set be easily modified to reassess the archive and update it?
Perhaps the most challenging issue is who “owns” the process? It is straightforward to suggest that as the central repository, the VNA should control the rule set and retention/deletion policies. On the other hand, it is likely that many VNA’s will be set up to interact with more than just image generation systems, such as with an EMR. And, in such instances, there may be parallel systems for managing documents that is separate from the VNA. In those cases, the more complete answer may be for the EMR to control the rule sets and processes across all repositories. I am reminded by Chris Magyar that there could be clinical metadata used in retention rules that includes data outside of the DICOM study in the VNA – again a factor impacting rules ownership.
Conversely, there will be those that might argue that the originating systems such as a PACS have a say in the process.
Beyond retention rules deployment, there is the question of rules management. Who develops the rules and who approves them? Is there an audit trail for follow up if there is a problem? Who tests the rules before they are implemented?
The bottom line? Don’t take it on face value that a VNA solution is the answer for ILM. Make sure your organization has thought through the workflow and implications of ILM and how you envision ILM policies being managed. This will require coordination between image generating systems, a VNA, and hospital systems such as the EMR. It may take several capital cycles to achieve an effective solution. ILM doesn’t come for free. As noted above, besides the capital cost, there are operational costs associates with implementation that must be factored into an ROI. So it is important to make sure VNA solutions under consideration fit with your master plan.
I’d like to recognize the technological heavy lifting of two well respected industry experts, Tim Kaschinske of BridgeHead Software, and Chris Magyar of Agfa Healthcare. They have both been great resources for VNA and ILM concept validity!