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:
•    Administration
•    Maintenance
•    Support
•    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 that the administration section would include the guiding principles for the project, its governance and leadership, roles and responsibilities, and perhaps an organizational chart. This information will serve not only as a reference, but also as a template for defining future policies and procedures.

One area that requires a great deal of focus and discipline is a policy for change management. Whether a facility is large or small, has two diagnostic workstations or two hundred, supports one small radiology practice or a large conglomeration of facilities, it is absolutely critical to have a policy in place for making changes to the system.

This would include not only changes to the system such as software upgrades, but changes to workflow such as how images are being distributed, compression settings, network settings, monitor settings, locations of workstations, and so on. Think of all the different areas of the IT infrastructure, including the impact on end-users, that can be affected by even the most benign system change.

A best practice regarding change management is to designate a representative from each area for which the change could have a potential impact and meet to collectively discuss the issues. Having expertise present regarding the network, operating system, PACS architecture, and workflows can save hours of downtime and negative impact to not only PACS, but other systems which may suffer the after effects of implementing a change which is thought to be benign.

A good policy will include a definition of the purpose and scope, descriptions of what constitutes a planned change versus an emergency change, and general guidelines for the procedure on how to request a change. A policy for managing change should be at the top of the list of things to do when implementing PACS.

The disaster recovery/business continuity policies and procedures are another critical set of rules. As a matter of fact, one should not implement a new system, subsystem, or even add any part to the PACS without documenting what to do when the system fails, for whatever reason. Although we are highly dependent on technology, this is OK, as long as we have a proper backup procedure in place.

A great example of how not to implement a PACS is an institution in our area that did away with its ER film processor and replaced it with only a single CR reader. Suffice it to say that if the CR reader goes down, personnel will be scrambling to get x-ray images to referring physicians in a timely fashion.

It would be impossible to discuss every policy and procedure which may be defined as part of a PACS implementation in the scope of this article. Furthermore, not every policy would apply to every situation or facility on the basis of how the system is utilized.

One thing is certain, however: the existence of policies, procedures, and documentation can be a lifesaver. Let us leave you with one last thought. If it is important enough for the manufacturers of far less sophisticated devices such as blenders, VCRs, and electric toothbrushes to include detailed instructions, then isn't it important enough for us to do this for the PACS applications that we manage?

In future installments in this series, we'll explore additional policies and procedures and offer specific examples, based on our experience and practices at UTSW.

Herman Oosterwijk, MS, MBA, is president of Aubrey, Texas-based OTech Inc., which specializes in PACS training and publications. Daniel Knepper, BS, ASRT(R), is a senior information resources manager at UTSW Medical Center in Dallas. He has been involved in PACS planning and implementation for several years.