PACS cannot succeed only as a piece of health IT. Policies, procedures, and support create the required environment for these systems to achieve their full potential.
A recent series of classes I conducted in the Middle East exemplified the challenges with installing, maintaining, and supporting PACS in this region. Although the technology is the same as used throughout Europe and North America, the PACS environment (policies, procedures, and support) is not.
Unfortunately, there is a big training gap on what is required to successfully implement PACS, which has led to a lack of infrastructure and support. In general, the IT staff at many facilities is very weak, or sometimes even non-existent. In these institutions, there are no policies with regard to basic IT good practices such as virus protection, network management tools. Even fundamental activities such as who is making a back-up, and how often this is done can be missing. There is no understanding that a PACS needs a dedicated PACS administrator. In many cases a technologist, or even a department head, will perform double duty to fill this role.
It is very easy for these facilities to buy a piece of technology, such as a PACS, but to change internal procedures, infrastructure, jobs, and workflow to accommodate it is--in many cases--not done. Job descriptions need to be changed and a very clear division of authorities is needed. For example, who is importing images from a CD, where are they kept, for how long, who is merging two patients or studies, checking log files, and so must be defined. Basic QA activities such as dose-creep analysis, reject analysis, calibrating CR systems and monitors have to be performed but are not being done.
Using technology without proper infrastructure and policies and procedures has the potential to create patient harm. The good news is that these countries are eager learners and are quickly picking up the required knowledge needed to successfully implement PACS. For expatriates, there are also some very good opportunities to help start these changes. However, there is still a lot of work to do and awareness of PACS issues, training, and education are critical. If these elements are not put in place soon, there could be some dramatic failures in the near future.
Tuesday, June 1, 2010
PACS Data Migration: How Clean Is Your Data?
In case you missed our May Webcast on data migration, there is still an opportunity to watch the video and have a look at the slides, just go to https:/www.healthimaginghub.com/webcast.html.
There were some interesting questions posed during the live Q and A portion of this event. The first one was from a listener who asked whether he could use his existing Centera archive when migrating data.
The answer was an unequivocal: "It depends." The reality is that it depends on the data storage format of the archive. Basically, the question boils down to whether or not an institution can re-use its existing physical storage device when migrating data. Many customers have invested a significant amount of money in these systems, and many of them come with their own intelligence for the PACS interface as well as provisions for data mirroring and back up.
Most newer archive systems are configured as a Storage Area Network (SAN) or a Network Attached Storage (NAS) device. Many institutions are moving toward a NAS, especially for new installations or as part of an upgrade. Although a SAN/NAS configuration is transparent to information storage, a NAS (at best) may deliver better performance and be more reliable.
With regard to data migration, assuming that the information is stored in a “native” DICOM format and that a new PACS is able to understand this; then yes, in principle, it is feasible.
In my career I have seen a couple of cases where this worked, but this has been an exception. When this works, the new database points to the old image data. In order to determine whether this is possible, one needs to do an analysis of the sending and receiving data. Note (and this is important) that a DICOM conformance statement is not necessarily sufficient to determine this feasibility, as it only specifies the interface and not the internal data format.
Another question from our Webcast asked how one could determine the level of “proprietariness” of an institution's archived data. Again, that is difficult to determine from paper specifications; however, it is an important piece of information for any institution to know.
The answer would determine, if, best case, an image archive can easily be migrated by just changing pointers, or worst case, if the image data has to be converted. For example, a proprietary compression format would have to be converted to a DICOM standard format. In other instances, image tags will have to be “morphed” added, or deleted to accommodate a new PACS. A rather good measure could be developed by doing a minor “fake” or “test” migration” with one day of generated data and performing an analysis of what was able to be seamlessly migrated.
One should note that as each institution has its own data environment, every data migration is a unique event to that facility. The image headers of data acquired by two identical modalities with the same software version (say a Phillips' MRI), archived on the same PACS (say a GE), with patient demographics generated by the same HIS/RIS (say McKesson) can be different because many institutions use different data dictionaries, protocols, codes, and so on.
In general, one can make general statements and have certain expectations about the data, but there will always be exceptions and deviations.
As such, I would strongly recommend that each institution learns the characteristics of its archived image data. It is always better to be prepared for future migrations than uncomfortably surprised when it comes time to perform this process. Of course, having a Vendor Neutral Archive (or a Storage Service Provider) could eliminate many of these issues.
There were some interesting questions posed during the live Q and A portion of this event. The first one was from a listener who asked whether he could use his existing Centera archive when migrating data.
The answer was an unequivocal: "It depends." The reality is that it depends on the data storage format of the archive. Basically, the question boils down to whether or not an institution can re-use its existing physical storage device when migrating data. Many customers have invested a significant amount of money in these systems, and many of them come with their own intelligence for the PACS interface as well as provisions for data mirroring and back up.
Most newer archive systems are configured as a Storage Area Network (SAN) or a Network Attached Storage (NAS) device. Many institutions are moving toward a NAS, especially for new installations or as part of an upgrade. Although a SAN/NAS configuration is transparent to information storage, a NAS (at best) may deliver better performance and be more reliable.
With regard to data migration, assuming that the information is stored in a “native” DICOM format and that a new PACS is able to understand this; then yes, in principle, it is feasible.
In my career I have seen a couple of cases where this worked, but this has been an exception. When this works, the new database points to the old image data. In order to determine whether this is possible, one needs to do an analysis of the sending and receiving data. Note (and this is important) that a DICOM conformance statement is not necessarily sufficient to determine this feasibility, as it only specifies the interface and not the internal data format.
Another question from our Webcast asked how one could determine the level of “proprietariness” of an institution's archived data. Again, that is difficult to determine from paper specifications; however, it is an important piece of information for any institution to know.
The answer would determine, if, best case, an image archive can easily be migrated by just changing pointers, or worst case, if the image data has to be converted. For example, a proprietary compression format would have to be converted to a DICOM standard format. In other instances, image tags will have to be “morphed” added, or deleted to accommodate a new PACS. A rather good measure could be developed by doing a minor “fake” or “test” migration” with one day of generated data and performing an analysis of what was able to be seamlessly migrated.
One should note that as each institution has its own data environment, every data migration is a unique event to that facility. The image headers of data acquired by two identical modalities with the same software version (say a Phillips' MRI), archived on the same PACS (say a GE), with patient demographics generated by the same HIS/RIS (say McKesson) can be different because many institutions use different data dictionaries, protocols, codes, and so on.
In general, one can make general statements and have certain expectations about the data, but there will always be exceptions and deviations.
As such, I would strongly recommend that each institution learns the characteristics of its archived image data. It is always better to be prepared for future migrations than uncomfortably surprised when it comes time to perform this process. Of course, having a Vendor Neutral Archive (or a Storage Service Provider) could eliminate many of these issues.
Subscribe to:
Posts (Atom)