Project Management Applied to PACS Implementations

Project Management Applied to PACS Implementations
1/19/06

Marie Richards, M.Ed., PMP, ITIL, CPEHR, CPHIT
Email: marierichards@hotmail.com, 214-668-6781

Marie Richards
Project Manager at 5 PACS installations

After leading Picture Archiving Communication System (PACS) implementations at 5 hospital sites, I learned that success is

measured by the smoothness of project implementations and the tangible productivity gains the radiology department

experiences. Productivity gains are often improved turnaround times, improved quality indicators, improved physician

satisfaction survey results and an increase in the number of patient procedures. Here are some insights gained from applying

project management principles to PACS implementations which influence project successes.

Project Initiation

The PACS project initiation tasks clearly define the project objectives. These were outlined in a document that identified the

business value for the PACS system and how that value would be measured. It summarized the constraints and assumptions

around timing, budget and modalities targeted. From one hospital to the next, we found that the type and number of

modalities, as well as the hospital facilities involved in the implementations varied. We documented the charter which identified

the project manager, the project owner, the project sponsor – usually the Director of Radiology, the hospital’s PACS System

administrator(s) and other key stakeholders. Along with the enthusiasm for PACS, it was critical to have a Radiologist as a

clinical owner to play an active role in helping with workflow decisions affecting the productivity of Radiologists. The approval

of this document established the authority for the project.

Targeted Business Benefits from PACS Installations

As project managers, our responsibility is to ensure that the PACS benefits which the hospital anticipates are documented for

later evaluation, along with interim achievements which would be tracked to demonstrate acceptable progress.

Hospitals face increasing costs of film, film supplies, film storage, personnel cost of handling film during film storage or

retrieval, in addition to the time spent searching for lost films. Despite a transition to PACS, some of these costs remain during

Author: Marie Richards, M.Ed., PMP, ITIL Page 1 of 15

-the period when the hospital is legally required to retain the film. Hence a transition to PACS anticipates an extended benefit

realization period, as relevance of previously captured images on film fades, or with phased transitions of specific modalities to

PACS.

Some benefits our customers envisioned were:

- An improvement in diagnostic capabilities using powerful image display monitors.

- An easier workflow with the reduction in the manual retrieval of previous films over time and searches for lost film.

- Reduction in the number of images that require re-taking.

- Reduced demand for, and the expense of printed film.

- Improved alternatives for sharing film with referring physicians. Some alternatives are web-based access to the PACS

images, images printed to a CD on request, or providing limited printing for special requests within pre-defined agreements.

- Reduced cost of physical film storage; reduced labor costs for film retrieval and searching for lost films.

- Compliance with HIPAA security access rules using configurable user access system profiles for online film viewing.

- Improved film distribution capabilities to physicians in the ER, ICU, other clinical areas, physicians in their homes via the

web, or to physicians providing coverage for weekend, nighttime or complex readings.

- Easier onsite and offsite storage of digital images, through server mirroring techniques, archiving of images, and offsite

storage of tapes.

- Improved productivity within turnaround times for:

1. Exam completion to transcription

2. Preliminary report turnaround

3. Final report turnaround

4. Overall patient procedures

- Increased volumes of diagnostic procedures submitted for interpretation.

After the “Buy” Decision – Vendor Selection

Once the buy decision was made, the hospital identified a vendor whose system could support the business benefits outlined

in the business case presented for acquiring a PACS system. Prashila Dullabh, MD (Prashila@gmail.com), who was the

Informatics Manager at Adventist Healthcare Corporation’s (AHC) PACS implementations, outlined the approach used at AHC.

The user requirements were identified, and reflected in an RFP sent to the top 6 vendors listed in the KLAS report. KLAS is a

“research and consulting firm specializing in monitoring and reporting the performance of Healthcare's Information Technology

(HIT) vendors”. (1). PACS systems must meet the essential user requirements to yield anticipated benefits. A structured RFP


template facilitates the precise evaluation and scoring of responses when compared to user requirements. Such a template

should cover functional, technical and training requirements along with the total cost of ownership (TOC). Dr. Dullabh reports

that once the RFP responses were evaluated and scored, site visits were arranged to hospitals using the PACS systems for

the top 3 vendors. Once the final 2 vendors were identified, a thorough technical review was conducted.

Technical Evaluation

Technical review of the vendor’s PACS considered the current technical architecture in place at each facility, compared with

the vendor‘s recommendations. Since PACS transports large, digital files from image capture modalities across the network,

the Hospital’s current bandwidth utilization and the future demands which PACS would place on the network was studied. We

considered the number and location of image acquisition devices in a single or in multiple facilities. We assessed the location

of the radiology technicians’ image reviewing workstations and the radiologists’ reading workstations; the location of central

storage servers for archived PACS images – SAN; the location of a failover server to which images could be sent in the event

of failure of the primary production image server; image distribution requirements; the size of images to be transported; the

carrying capacity of the network during peak use times; the current study volumes for the hospital and anticipated growth per

year.

It was important that for some facilities, operating rooms have mobile image capture devices, and mobile image display

workstations. This allowed technicians to confirm that the images taken in the operating rooms were adequate before leaving

that area. Additionally, we considered the work patterns of radiologists with regard to the single or multiple locations from

which they would access the images, as well as the implications for their user security access profiles. In some cases the

technical assessment identified a need to upgrade the existing network to accommodate the anticipated normal and peak

transmission loads, or to establish a virtually separate network.

Disaster Recovery

The final configuration for the equipment installed at the Data Center was important to assess early, since this was added to

the list of all other equipment requiring replacement in the case of a disaster. When the specifics were available further along

in the project, such as the name and model of the equipment, memory specifications, number of processors, and any

peripheral equipment, this was listed within an existing Data Center disaster recovery contract. Of course, this activity

assumes that the hospital has equipment replacement as a feature within disaster recovery contracts and procedures.

Replacement agreements for workstations within the hospital are handled differently depending on the hospital, and may need

to be separately specified. In addition to the physical recovery of equipment, vendor support agreements should specify who


reactivates the equipment in case of a disaster, i.e. reactivates the operating system, restarts and resynchronizes the

databases and applications.

Integration

Two variations in PACS systems were selected at 5 hospital sites. Installing the AMICAS PACS system required a

bidirectional interface between the Radiology Information System (RIS) system and the PACS so orders could be sent from

the RIS directly to PACS, as well as status updates from PACS sent to the RIS. Installing McKesson HMI at one site included

a pre-integrated interface between the McKesson Radiology Manager (RIS) and the McKesson PACS system (McKesson

Horizon Medical Imaging). At another site, a bidirectional interface between the RIS system and the PACS was developed so

orders could be sent from the RIS directly to PACS, as well as status updates from PACS sent to the RIS. All solutions

required robust interface testing, and participation of an experienced integration specialist as a member of the core project

team.

User Evaluation

Critical to your users’ satisfaction is obtaining buy-in from influential radiologists with regard to the impact of PACS on their

productivity. We recommend site visits by the project’s clinical owner to a similar hospital elsewhere which has implemented

PACS. Questions can be answered on these visits as to whether their radiologists have been able to eliminate paper, and if

so, within which process areas. Questions regarding the orthopedic surgeon’s use of a PACS system which displays films on

monitors instead of a view box at eye level still need to be answered. Protocol questions related to whether radiologists will

read all images captured, even if those images have been interpreted by a surgeon have to be ironed out. Radiologists found it

helpful to view the entire workflow process from patient exam being taken through to final dictation where that could be

arranged.

Dictation, Voice Clips

All hospitals investigated the radiologist’s ability to dictate on specific patients by clicking an onscreen link to that patient’s

study, which would activate a dictation system. A well integrated system could store the voice file along with the patient’s

identification on the dictation system’s worklist, with a visible indicator that the PACS study was dictated. It was helpful to

have the initial interpretations of an image from persons other than radiologists, stored as voice clips associated with the

study. This voice clip was accessed by the radiologists prior to the final interpretation being dictated.


Modalities – DICOM Readiness

All image capture devices for each modality must be able to capture images and associate them with patient record according

to the latest DICOM standards, before they can send these images to PACS. Images range from radiographic images to

scanned documents. Part of the solution for the PACS implementation was using medically acceptable digitizers to digitize the

hard copy patient films, and send a DICOM compatible image to the PACS system. At each hospital, modalities which were

not DICOM compatible were targeted for upgrade to DICOM compatibility by that modality’s technical engineer. Printers

designated for the limited printing of films were scheduled for upgrade so as to accept DICOM images. One image distribution

method to referral physicians was the burning of PACS images on CDs. The CD Burners may come bundled with the PACS

system, or may be purchased separately. CD Burners burned the studies and imbedded the image reader software to the CD.

Acceptance of these CDs for viewing images varied among referring physicians. Some physician’s had older model PCs which

could not read the CDs. These physicians had to be provided an alternative for viewing the images.

Modality Worklist Readiness

The existing modalities in the hospital needed to be capable of displaying a worklist of patient orders, indicating patients who

were waiting for exams to be taken. Some upgrades of modalities were required to support and display worklist data.

Scheduling these individual modality upgrades with vendors on a timeline which was supportive of the overall PACS

implementation schedule was particularly challenging.

Vendor Implementation Experience

Vendor selection decisions considered the vendor’s experience in implementing PACS at hospitals, the version of PACS

software purchased, and the vendor’s ability to present a useful implementation plan. Some 'gotchas' in this area were:

Software not previously implemented elsewhere, still having ‘bugs’ which could delay the implementation, or bugs which may

not be apparent until the system was installed in production. A vendor should provide an implementation plan to guide the

sequence of implementation tasks, e.g. site specific data collection, ordering and site delivery of equipment, and the current

workflow analysis. The vendor should be able to offer advice on the workflow processes which will change when PACS is

implemented. The vendor should have the ability to design new workflows for your facility, and train your expert users on-site

on these new workflows. It is critical that the vendor accommodates travel of more than one implementation specialist to your

site during and after the go-live week to train radiologists and help with go-live technical and user issues.

Once your contract negotiations are final - you can begin your PACS project.


Project Planning

Project planning activities included clarifying the scope of work, breaking down the work into the hardware, network, workflow,

training, integration, testing, go-live and rollout components, identifying and obtaining commitments for the human resources

required and verifying that the budget assigned will be adequate for the project. This meant confirming with the vendor the

equipment specified and the availability of that equipment from the manufacturer. The equipment was ordered at the earliest

possible time. During this phase, we reviewed the contract to clarify the commitments, and summarize the essential scope of

work components for the project team.

Based on the date the vendor contracts were signed, and the anticipated delivery dates for the equipment, we defined the

project schedule. Project scheduling took into account other hospital activities and projects that impacted our resources or go-

live planning activities.

Risks that we had to manage, mitigate, or work around were identified, e.g. risks linked to finalizing the equipment order and

the constraints inherent within the vendor resources available to the project. On one implementation the PACS system

administrator was new to the facility, to the workflows and to the interfacing clinical applications. The learning curve risk was

offset by having the PACS administrator role shared between the project owner and the PACS administrator. On another

project, 2 PACS system administrators were assigned to the project. One PACS system administrator was assigned from IT,

and another from the Hospital. Additionally, flexibility was built into the schedule to accommodate some delays without

necessarily impacting the planned go-live dates. Events factored into the schedule were holidays, vacation days of team

members, accreditation visits to the hospital and other site projects.

The output from the Planning phase was a scope of work document, which identified modalities within this phase of work, and

those modalities which would be considered for later implementation. Additionally, the work was broken down into work

segments for hardware ordering and installation, network assessment and upgrade, site preparation – electrical wiring and

connectivity wiring, modality upgrades for those modalities selected for the first go-live phase, identification of server locations,

workstation locations, radiology reading room work surface changes and preparations, and follow-on implementations of

subsequent modalities. Site specific data cataloged image capture devices and printers which were DICOM ready and those

requiring an upgrade. Other work segments were training, PACS rollout, and go-live plans. This work was listed within a

project schedule, and plans developed to manage and respond to risks. We also confirmed the resources, and the budget for

the project.


The critical path tasks were ordering and delivery of hardware, vendor on-site days for training, vendor provided training for the

PACS system administrator, initial workflow reviews, interface testing completion and go-live dates. The scope of work and

schedule, quality, staffing, communication plans were reviewed on-site at the kick-off meeting and finalized for approval.

Project Execution

One focus within project execution was to identify the requirements for PACS to be considered successful within that radiology

department, at a detailed level. A department was those people and work processes aligned around a specific modality, e.g.

Angiography, CT, CR/or Plain Film departments. For each modality within the project scope, we examined the information flow

from the time the hospital receives an exam order or exam prescription from the ordering physician. This process identified the

department’s legal requirements for patient care documentation; notification requirements to alert the transporter that the

patient is ready to be transported; location requirements for reviewing workstations; system availability requirements for both

daytime and nighttime workflows; data communication and update requirements between interfaced systems; workflow

requirements for radiologists and non-radiology physicians.

Reviewing the user workflows helped the analysts understand the work individual users do, and the requirements for the

appearance of individual worklists and other PACS screen functions. Additionally, we reviewed the workflows to understand

what the performance requirements for PACS were during the expected daily use, and during peak use times. Performance

requirements defined the acceptable limits for the speed with which images would be sent to the PACS server from the image

capture modalities and how fast the first image within a group of images – a study – should display for the radiologists. Other

requirements uncovered the following:

- What the default presentation of the image should be for an individual radiologist.

- What the ambient environment should be for the rooms where most images would be read.

- How spacious the work space area should be to accommodate the workstations and display monitors.

- What support is required to keep the monitors appropriately calibrated so that the images were not distorted when being

read.

- What the security profiles for each user group should be in order to comply with HIPAA confidentiality regulations.

- What the ergonomic features for human comfort at the reading areas should be.

The requirements gathering process led to some interesting discoveries. At one site, the radiology reading room was relocated

to a central area, with each radiologist situated at a reading desk. The room was painted dark green, the lighting dimmed and

the temperature adjusted to provide the best environment for reading images. Some sites had physical construction of reading


areas for radiologists, or adjustable desks to accommodate radiologists whose physical height varied, but who shared the

same space on different schedules. We found it essential that the infrastructure readiness (cabling and environment) be

completed as early as possible to facilitate system performance testing.

Workflow reviews uncovered the legal requirement for the length of time to retain images captured before PACS was installed.

Whereas film can be digitized, the original source of images from which an interpretation is made is seen as the legal patient

record for a period of time designated by each State. This meant that there would be a diminishing medical or legal need, but a

need nevertheless, to retrieve older films for comparison, from the physical film storage rooms, for a defined period of time.

Workflow Analysis

The complete workflow analysis identified user needs in different areas. The radiology department needed to provide referring

physicians access to images. The solution for some referring physicians whose volume of referrals was small, was to burn a

CD for them with the images and image reader software embedded. Internet access to PACS images was provided at all our

sites, using appropriate security protocol to create a secure connection for data transmission from an image web server. Thus

some physicians could access the images from home or another location securely. Another limited-use option was to print the

images from special printers. We recommend confirming the alternatives for access with the radiology community, before

installing PACS, along with any technical pre-requisites and limitations.

Some issues relating to access permissions involved identifying single sign mechanisms for users to access the PACS

network by first logging into the hospital network. The technical challenge was to determine how to best authenticate the user

IDs for staff logging into PACS via the hospital network Also at one site, there was an URL encryption enhancement

requested of the vendor, to allow the retrieval of PACS images to the hospital’s web portal.

Workflow reviews identified the need for digitizers to be installed at specific locations. The clerical staff was thus able to

retrieve previous films for scheduled patients, and digitize these films so they could be reviewed by the Radiologists through

PACS. This new task required that the clerical staff received additional training for digitizing images, and had their job

descriptions changed.

An important aspect of workflow reviews was to identify the paper generated from the time a patient’s radiology exam is

scheduled through to dictation and availability of results to the ordering physician. The elimination of as many paper processes

as possible is a goal of PACS. Some hospitals were able to eliminate the printing of the order requisition. Other hospitals

found that the PACS software allowed them to enter some notes online, respond to the questionnaires via checkboxes online,


or allowed the technician to mark up an online template diagram at the point where radiology technicians reviewed the images

before sending them through for interpretation. These notes were drawings associated with the study and were available to

the reading Radiologist, thus removing some additional dependency on paper. There was some paper on which a patient

signature was required such as consent forms. These were scanned by a device capable of sending a DICOM compatible

scanned image to PACS.

Workflows adjusted for PACS boosted the speed with which Radiologists could interact with Operating Room physicians.

Mobile computed radiography stations were identified as being most useful within some operating rooms, along with a

radiology technician’s workstation just outside the operating room in the hallway. This allowed the technicians to take surgical

images within the operating room, send these images to PACS from just outside the OR. Radiologists located elsewhere in the

hospital could interpret the images and communicate to the OR physician by phone. The new capability presents an exciting

process improvement from which many patients will benefit.

At a few if our PACS implementations, the hospital first converted the X-ray department over to Computed Radiography.

Computed Radiography (CR) or Digital Radiography (DR) allows the healthcare facilities to produce digital images, viewable at

a technician’s workstation. This required a change in workflow for the X-ray technician who would now review an image on a

workstation, for a patient as their name appears on the displayed worklist. This was an efficient, interim method to build the

technician’s familiarity with workstations displaying digital images and worklists. Transitioning to CR from X-ray abbreviates the

learning curve for technicians to become comfortable with a PACS technician’s workstation.

Interface Development

Workflow reviews were crucial for identifying the systems that would communicate with PACS. The selected PACS systems

supported an interface between the Hospital’s Radiology Information System (RIS) and the PACS. Decisions which limit the

amount of developmental work required in this step is always a plus for any PACS project.

Interface development focused on ensuring that ADT messages from the registration system and radiology order messages

from the RIS are transmitted to PACS. The radiology results – dictated interpretations – are transcribed into the RIS and sent

to PACS. The RIS should be notified from PACS when the exam is complete, i.e. all images for the exam study are received.

This notification triggers the procedure billing tasks, and allows the images to be viewed from the hospital’s image viewers or

through a secure web access viewer.


There may be an interface required between the PACS system and a dictation system (see Dictation, Voice Clips section). At

some hospital sites, there was a backup server receiving a simultaneous feed of PACS images as the production server. This

backup server provided a failover solution in the event the production server failed.

The essential steps within the interfaces utilizing HL7 communication protocols were to review interface specifications for all

the interfacing systems. PHNS’ Integration specialist, Karl Fisher (karl.fisher@phns.com) advises reviewing the interface

specifications from the ADT source system (HIS), from the RIS, from the PACS vendor, and any systems to which the PACS

images or updates should be distributed, e.g. ED information system, or a data exchange application. The interface specialist

developed the interface engine’s data mapping capability for mapping specific messages between the sending and receiving

systems. Obtaining clarification from the vendor about their application’s interface specifications is important, especially with

regard to how orders within the sending system (RIS) are uniquely identified within PACS. There should be clarity regarding

how a single order with its unique accession number translates within PACS which often has multiple images for a study

generated from that single order.

Interface challenges experienced within PACS implementations will vary with the maturity of the vendor and/ or systems. Karl

Fisher suggested that some things to look out for would be:

• Variations in each vendor’s implementation of HL7.

• Inconsistencies between the vendor’s specifications and the vendor’s software.

• Site specific nuances for implementing the vendor’s specifications that are not addressed within the vendor’s HL7

specifications. This is usually uncovered with the integration specialist’s expert analysis.

Unit testing phase of integrations is the best time to uncover and resolve variances within the vendor’s specifications. These

variations, if not uncovered early, will delay the project during integration testing, since the vendor’s HL7 experts may not be

available during integration testing on a timely basis to help diagnose, correct and retest problems.

Within integration testing, it was important to obtain the focused participation of the Receiving Application Analyst (RAA),

since they can best decide how data should display within the receiving system for data integration to be considered a

success. A good strategy was to let the RAA take ownership of the integrated testing process, while other persons played a

supporting role to the RAA.


A challenge we had to overcome was to develop the interface so that there was an unique identifier which linked multiple

images within PACS resulting from a single order, to that single order within the RIS. This unique identifier was necessary to

allow any updates within messages linked to multiple images, to update the appropriate single order within the RIS. Because

of the “1-to-Many feed” and “Many-to-1 order updates”, the PACS unique identifier must be able to point backwards to its

'parent' order so that updates sent back to the ordering system can reference that parent order.

Another interface challenge was found in the planning for the failure of the production server – the primary server receiving

PACS images. One PACS system design allowed for simultaneous data feeds to both a production server and a failover

backup or contingency server. Traditional parallel data delivery designs can lead to lack of data synchronicity if the production

server were to fail during times of queued message delivery. A serial message delivery design was implemented to better

assure that data delivered to a backup server is identical to that of the production server.

Quality assurance for interfaces during project execution was achieved through exhaustive integration testing, following

defined integration test plans. This comprehensive integration testing at one site, highlighted a problem within one RIS system

that had gone undiscovered. This meant that fixing the RIS system was an unplanned event within the project, and caused

delays in the completion of testing.

The PACS system administrator’s application skills were strengthened as a result of participating in the integration testing.

This proved critical during go-live and beyond for adequate user support.

Go Live Strategy

My participation on 5 PACS projects allowed me to see the outcomes of different go-live strategies.

One strategy was to go-live with just the interfaces being active, so that ADT patient data and orders were sent to PACS,

along with any images taken by the DICOM-ready modalities. There would be no change to the radiologists’ workflow, and no

training required at this point, since they would also receive images for interpretation on film, as they did before. The benefit to

the hospital was that a collection of prior digital images would accumulate on-line and be available for reference, whenever the

radiologists were ready to read and interpret the images via PACS. Thus at go-live of the actual soft copy reading of PACS

images for most patients, the Radiologists would reference one tool – PACS, not flip between PACS for current images and

films on view boxes for prior images.


Another strategy was to go live with both collection of images and softcopy reading by the radiologists at the same time. This

abbreviated the go-live event. However, following go-live, there would be period of time when radiologists needed to have all

prior films for patients delivered to them, and to view these films on view boxes.

Both strategies required careful planning for workstation staging and roll out, so as to occur within a couple of weeks prior to

actual use by the doctors and technicians, since desktop space is always at a premium in clinical areas. Image viewing

workstations were needed by technicians for each modality’s technician, physicians in ICU, ED, on stationary workstations and

physicians in OR on mobile workstations. Radiologists read from the diagnostic workstations linked to dual display monitors.

Workstation rollout required very precise scheduling of the vendor and or desktop service specialists for rollout activities so as

to not interrupt patient care tasks.

Training

Preparation for training involved scheduling technicians and radiologists within their rotation and weekend schedules. Planning

included reviewing with the modality department heads, the workflow changes that would occur and the impact on their staff.

Department staff managers determined which of their staff could be identified as expert users to provide subsequent training to

their peers. Sometimes it is determined that some personnel may not adjust well to the workflow changes, and may need to be

reassigned.

Training end users occurred the same week as they were designated to start using PACS. Training was carried out by the

vendor, at the hospital site within the modality departments designated to go live with diagnostic reading on PACS. For

effective training, this required 2 vendor trainers to be onsite. That training concentrated on helping technicians to view and

select from their list of patient orders, on their modality monitors. The radiology technicians had to learn how to adjust the

image or retake the image if it did not meet the standards for sending to PACS. Technicians learned how to submit all images

that make up a study as part of the single order. They were given a couple of days to hone their techniques within the live

production environment, before the radiologists received their training on reading the PACS images sent by the technicians for

interpretation. The radiologists’ training occurred at their diagnostic workstations, and required 2 vendor trainers to be

available for that training, along with the PACS system administrator. Since the technicians had been trained before the

radiologists, training allowed the radiologists to begin reading the minute they were trained.

For sites where there is no interface between PACS and a dictation system, radiologists will need to access the dictation

system as they did before PACS, and dictate the patient’s identifying information and procedure name.


Communication

PACS projects convened persons from across many organizational units and external vendors, with their attendant

communication complexities. Our PACS projects interfaced with technical disciplines within Network Management,

Systems/Hardware Management, Integration Management, Desktop, and contracted vendors for PACS applications, wiring,

modality upgrades, and radiology experts within the hospital staff. Within project management, the formula used to define the

number of communication channels managed when people are involved in a project is: n(n-1)/2, where n = number of people.

If there are 20 persons involved in a core project team, there are 190 communication channels. That excludes the non-core

project team communications. Within our PACS projects we had communication plans for managing the inherent complexities

from intersecting and crisscrossing communication channels. This included scheduled project meetings at which attendance

was required, documented contact roles and responsibilities, designated decision makers, those who provided advice, or

those who just needed to remain informed on the project’s progress at defined periods.

In this setting, everyone worked on multiple projects. That meant project meetings were structured around action items, issue

identification and progress updates. Issue resolution activities beyond very brief discussions were followed up outside of that

project meeting. A lesson learned from one implementation was that using project meeting time to discuss contract details

used up too much project time, since some project team members had limited interest. Another lesson learned was that it was

essential for system and network engineers to be fully engaged in the project from the kick-off meeting so that they understand

the project objectives.

It was helpful to clarify the formal and informal reporting relationships within the team, as well as the mechanism for providing

performance feedback to the functional managers requiring that feedback. Additionally, we found success in establishing an

early strategy for building awareness among external physicians for the flimless environment.

Staffing Requirements

Staffing requirements for PACS project identified the need for 1 to 2 PACS system administrators for a PACS implementation.

The rationale there was to provide a backup administrator for assisting with system administration and user assistance needs.

Designated administrators required formal training in the PACS application selected, which was provided at the vendor site.

Other competencies were built using the technique of one person from a previous implementation shadowing the staff

assigned on a following implementation. Additionally, I received permission to organize a corporate PACS conference where

staff participating in PACS projects throughout the country gathered to share their best practices and lessons learned with


each other. This had an immediate payoff on subsequent PACS projects, as those lessons were incorporated into the

implementation for smoother and faster PACS implementation results.

Constraints

Constraints are factors that limit the project team's options. Some constraints experienced on our projects were: a) the hospital

and IT staff availability,

b) vendor software readiness status

c) availability of vendor designated hardware

d) availability of vendor resources

These factors were managed through scheduling project tasks to reflect availability dates. Modality readiness for go-live within

the PACS environment was constrained by the availability of the modality vendor to schedule DICOM upgrades for their image

capture devices. Another constraint was the customer environment. On one project, the type and model of vendor specified

servers had to be changed to suit the customer environment.

Scope Change Control

Request for changes to the initial equipment order for workstations, scanners, digital devices, or display monitors can and did

come out of some workflow review sessions, so part of the planning for the project budget included a contingency budget for

just such an eventuality. Within some projects, workflow reviews yielded changes in some workstation locations, which

required additional costs for electrical and network wiring activities.

Project Closing

Project closure activities may occur in phases. Post go-live, there are audits to ensure that images are transferred accurately,

that expected transmission times are maintained, and that workflow processes are honed to achieve the maximum productivity

gains.

Some of our vendor contracts included a clause requiring 60 day post go-live assessment of performance, prior to final

financial closure.

We found it helpful, after the initial modalities went live, to conduct a formal review of the lessons learned, before the core

project team disbanded. The focus of our lessons learned activities was to identify our successes, and our opportunities for

improvement. Suggestions for improvement were incorporated within another hospital’s PACS implementations or within

subsequent modality implementations at the current hospital site.


Benefits Realization

We determined that the various benefits to be achieved could be measured only after some time had passed. Our PACS

implementations focused on capturing productivity measures before any workflows changed, and then targeted review periods

in the future to reassess gains, in keeping with the hospital’s routine productivity assessment schedules.

Reference:
(1) http://www.healthcomputing.com/


Project Management Applied to PACS Implementations

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (11)

Semelhante a Project Management Applied to PACS Implementations

Semelhante a Project Management Applied to PACS Implementations (20)

Project Management Applied to PACS Implementations