Documentation of policies and procedures, both technical and procedural, is critical for the proper operation and management of a PACS. Unfortunately, because the systems are so new in many healthcare facilities, it is necessary to design PACS policies and procedures from scratch - or worse, on an as-you-go basis.
But healthcare facilities initiating a PACS venture don't need to leap blindly. Here are some critical policies and procedures, as well as for those who are using the technology but have yet to install the proper policies.
Why policies and procedures? There is always a danger when creating these documents to become over-regulated and install a bureaucracy that stifles, rather than facilitates, the implementation of new technology. This is a major concern for the hospital environment, which needs to offer the latest, best practices in patient care.
Imagine a PACS that has gone down, patients waiting in the ER, and physicians anxiously anticipating the CT scans of a trauma case. Obviously, inefficient policies would last no longer than the first system outage. However, proper back-up and fail-over policies that are known and well documented can alleviate much of the danger inherent to these types of situations.
Leveraging existing resources
The good news is that PACS contains many aspects of typical IT projects that are implemented in a healthcare institution, and therefore, instead of starting from scratch, one could use some of these as a baseline and tailor them accordingly. As a matter of fact, it provides consistency.
There is no reason that a request to have a PACS workstation relocated would look totally different than a request to relocate a RIS terminal. The relocation of these workstations is a good example of where a proper procedure is not just a "nice-to-have" but a "must-have" based on the stringent requirements spelled out by the HIPAA privacy regulations.
Not only does the technical infrastructure have to be facilitated (network drop, power, and cooling availability), but someone needs to ensure that the location does not jeopardize the privacy of the information to be displayed. Configuration parameters for screen savers and auto log-off, as well as access and authorization rules, have to meet the specific needs of the physical location. For example, a password-protected screen saver might activate within three minutes after a workstation is not in use in the ER, although this is totally unacceptably short and unnecessary for a workstation in the OR.
To determine what type of policies and procedures are needed, we looked at our experience with the University of Texas Southwestern (UTSW) Medical Center in Dallas. The institution operates two university hospitals and five clinics on its campus. PACS has been a good fit largely because of the geographically disperse nature of the facilities.
Images from multiple modality types - CT, ultrasound, MR, PET, CR, and DR - are stored within a centralized architecture and are accessible from multiple locations on campus. Diagnostic workstations have been strategically located throughout the campus to provide geographic independence for staff radiologists. The system is supported by four IT resources - most of who have a background in radiology. Because the campus is dealing with such a wide range of modalities, acquisition locations, and people, the need for well-documented policies and procedures is paramount to the overall success of the system.
As you may imagine, the creation of policies and procedures can be an overwhelming and intimidating task. But, it doesn't have to be. By leveraging existing resources, one can start with baseline policies which can be molded to meet the specific needs of a particular system, such as PACS. It also is important to prioritize which policies should be put in place first. For example, when starting out it would be more important to have a disaster recovery and business continuity procedure in place than a procedure on how to produce CDs for patients.
Policy and procedure baselines
Policies, procedures, and site-specific documentation may be organized in several categories. One possible way to break these down is as follows:
• Architecture and Integration
• Disaster Recovery/Business Continuity
Through the use of broad categories one can easily begin to break down specific areas that require attention and prioritize them as necessary. It is fairly easy to determine