Project Management Applied to PACS Implementations


Published on

Project success is measured by the smoothness of project implementations and the tangible productivity gains the radiology department experiences.

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Project Management Applied to PACS Implementations

  1. 1. Project Management Applied to PACS Implementations 1/19/06 Marie Richards, M.Ed., PMP, ITIL, CPEHR, CPHIT Email:, 214-668-6781 Marie Richards Project Manager at 5 PACS installationsAfter leading Picture Archiving Communication System (PACS) implementations at 5 hospital sites, I learned that success ismeasured by the smoothness of project implementations and the tangible productivity gains the radiology departmentexperiences. Productivity gains are often improved turnaround times, improved quality indicators, improved physiciansatisfaction survey results and an increase in the number of patient procedures. Here are some insights gained from applyingproject management principles to PACS implementations which influence project successes.Project InitiationThe PACS project initiation tasks clearly define the project objectives. These were outlined in a document that identified thebusiness value for the PACS system and how that value would be measured. It summarized the constraints and assumptionsaround timing, budget and modalities targeted. From one hospital to the next, we found that the type and number ofmodalities, as well as the hospital facilities involved in the implementations varied. We documented the charter which identifiedthe project manager, the project owner, the project sponsor – usually the Director of Radiology, the hospital’s PACS Systemadministrator(s) and other key stakeholders. Along with the enthusiasm for PACS, it was critical to have a Radiologist as aclinical owner to play an active role in helping with workflow decisions affecting the productivity of Radiologists. The approvalof this document established the authority for the project.Targeted Business Benefits from PACS InstallationsAs project managers, our responsibility is to ensure that the PACS benefits which the hospital anticipates are documented forlater 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 orretrieval, 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
  2. 2. -the period when the hospital is legally required to retain the film. Hence a transition to PACS anticipates an extended benefitrealization period, as relevance of previously captured images on film fades, or with phased transitions of specific modalities toPACS.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 SelectionOnce the buy decision was made, the hospital identified a vendor whose system could support the business benefits outlinedin the business case presented for acquiring a PACS system. Prashila Dullabh, MD (, who was theInformatics 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 Healthcares Information Technology(HIT) vendors”. (1). PACS systems must meet the essential user requirements to yield anticipated benefits. A structured RFPAuthor: Marie Richards, M.Ed., PMP, ITIL Page 2 of 15
  3. 3. template facilitates the precise evaluation and scoring of responses when compared to user requirements. Such a templateshould cover functional, technical and training requirements along with the total cost of ownership (TOC). Dr. Dullabh reportsthat once the RFP responses were evaluated and scored, site visits were arranged to hospitals using the PACS systems forthe top 3 vendors. Once the final 2 vendors were identified, a thorough technical review was conducted.Technical EvaluationTechnical review of the vendor’s PACS considered the current technical architecture in place at each facility, compared withthe 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. Weconsidered the number and location of image acquisition devices in a single or in multiple facilities. We assessed the locationof the radiology technicians’ image reviewing workstations and the radiologists’ reading workstations; the location of centralstorage servers for archived PACS images – SAN; the location of a failover server to which images could be sent in the eventof failure of the primary production image server; image distribution requirements; the size of images to be transported; thecarrying capacity of the network during peak use times; the current study volumes for the hospital and anticipated growth peryear.It was important that for some facilities, operating rooms have mobile image capture devices, and mobile image displayworkstations. This allowed technicians to confirm that the images taken in the operating rooms were adequate before leavingthat area. Additionally, we considered the work patterns of radiologists with regard to the single or multiple locations fromwhich they would access the images, as well as the implications for their user security access profiles. In some cases thetechnical assessment identified a need to upgrade the existing network to accommodate the anticipated normal and peaktransmission loads, or to establish a virtually separate network.Disaster RecoveryThe final configuration for the equipment installed at the Data Center was important to assess early, since this was added tothe list of all other equipment requiring replacement in the case of a disaster. When the specifics were available further alongin the project, such as the name and model of the equipment, memory specifications, number of processors, and anyperipheral equipment, this was listed within an existing Data Center disaster recovery contract. Of course, this activityassumes 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 needto be separately specified. In addition to the physical recovery of equipment, vendor support agreements should specify whoAuthor: Marie Richards, M.Ed., PMP, ITIL Page 3 of 15
  4. 4. reactivates the equipment in case of a disaster, i.e. reactivates the operating system, restarts and resynchronizes thedatabases and applications.IntegrationTwo variations in PACS systems were selected at 5 hospital sites. Installing the AMICAS PACS system required abidirectional interface between the Radiology Information System (RIS) system and the PACS so orders could be sent fromthe RIS directly to PACS, as well as status updates from PACS sent to the RIS. Installing McKesson HMI at one site includeda pre-integrated interface between the McKesson Radiology Manager (RIS) and the McKesson PACS system (McKessonHorizon Medical Imaging). At another site, a bidirectional interface between the RIS system and the PACS was developed soorders could be sent from the RIS directly to PACS, as well as status updates from PACS sent to the RIS. All solutionsrequired robust interface testing, and participation of an experienced integration specialist as a member of the core projectteam.User EvaluationCritical to your users’ satisfaction is obtaining buy-in from influential radiologists with regard to the impact of PACS on theirproductivity. We recommend site visits by the project’s clinical owner to a similar hospital elsewhere which has implementedPACS. Questions can be answered on these visits as to whether their radiologists have been able to eliminate paper, and ifso, within which process areas. Questions regarding the orthopedic surgeon’s use of a PACS system which displays films onmonitors instead of a view box at eye level still need to be answered. Protocol questions related to whether radiologists willread all images captured, even if those images have been interpreted by a surgeon have to be ironed out. Radiologists found ithelpful to view the entire workflow process from patient exam being taken through to final dictation where that could bearranged.Dictation, Voice ClipsAll hospitals investigated the radiologist’s ability to dictate on specific patients by clicking an onscreen link to that patient’sstudy, which would activate a dictation system. A well integrated system could store the voice file along with the patient’sidentification on the dictation system’s worklist, with a visible indicator that the PACS study was dictated. It was helpful tohave the initial interpretations of an image from persons other than radiologists, stored as voice clips associated with thestudy. This voice clip was accessed by the radiologists prior to the final interpretation being dictated.Author: Marie Richards, M.Ed., PMP, ITIL Page 4 of 15
  5. 5. Modalities – DICOM ReadinessAll image capture devices for each modality must be able to capture images and associate them with patient record accordingto the latest DICOM standards, before they can send these images to PACS. Images range from radiographic images toscanned documents. Part of the solution for the PACS implementation was using medically acceptable digitizers to digitize thehard copy patient films, and send a DICOM compatible image to the PACS system. At each hospital, modalities which werenot DICOM compatible were targeted for upgrade to DICOM compatibility by that modality’s technical engineer. Printersdesignated for the limited printing of films were scheduled for upgrade so as to accept DICOM images. One image distributionmethod to referral physicians was the burning of PACS images on CDs. The CD Burners may come bundled with the PACSsystem, 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 whichcould not read the CDs. These physicians had to be provided an alternative for viewing the images.Modality Worklist ReadinessThe existing modalities in the hospital needed to be capable of displaying a worklist of patient orders, indicating patients whowere 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 PACSimplementation schedule was particularly challenging.Vendor Implementation ExperienceVendor selection decisions considered the vendor’s experience in implementing PACS at hospitals, the version of PACSsoftware 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 maynot be apparent until the system was installed in production. A vendor should provide an implementation plan to guide thesequence of implementation tasks, e.g. site specific data collection, ordering and site delivery of equipment, and the currentworkflow analysis. The vendor should be able to offer advice on the workflow processes which will change when PACS isimplemented. The vendor should have the ability to design new workflows for your facility, and train your expert users on-siteon these new workflows. It is critical that the vendor accommodates travel of more than one implementation specialist to yoursite 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.Author: Marie Richards, M.Ed., PMP, ITIL Page 5 of 15
  6. 6. Project PlanningProject 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 resourcesrequired and verifying that the budget assigned will be adequate for the project. This meant confirming with the vendor theequipment specified and the availability of that equipment from the manufacturer. The equipment was ordered at the earliestpossible time. During this phase, we reviewed the contract to clarify the commitments, and summarize the essential scope ofwork components for the project team.Based on the date the vendor contracts were signed, and the anticipated delivery dates for the equipment, we defined theproject 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 andthe constraints inherent within the vendor resources available to the project. On one implementation the PACS systemadministrator was new to the facility, to the workflows and to the interfacing clinical applications. The learning curve risk wasoffset by having the PACS administrator role shared between the project owner and the PACS administrator. On anotherproject, 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 withoutnecessarily impacting the planned go-live dates. Events factored into the schedule were holidays, vacation days of teammembers, 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, andthose modalities which would be considered for later implementation. Additionally, the work was broken down into worksegments for hardware ordering and installation, network assessment and upgrade, site preparation – electrical wiring andconnectivity 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 ofsubsequent modalities. Site specific data cataloged image capture devices and printers which were DICOM ready and thoserequiring an upgrade. Other work segments were training, PACS rollout, and go-live plans. This work was listed within aproject schedule, and plans developed to manage and respond to risks. We also confirmed the resources, and the budget forthe project.Author: Marie Richards, M.Ed., PMP, ITIL Page 6 of 15
  7. 7. The critical path tasks were ordering and delivery of hardware, vendor on-site days for training, vendor provided training for thePACS system administrator, initial workflow reviews, interface testing completion and go-live dates. The scope of work andschedule, quality, staffing, communication plans were reviewed on-site at the kick-off meeting and finalized for approval.Project ExecutionOne focus within project execution was to identify the requirements for PACS to be considered successful within that radiologydepartment, 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 flowfrom the time the hospital receives an exam order or exam prescription from the ordering physician. This process identified thedepartment’s legal requirements for patient care documentation; notification requirements to alert the transporter that thepatient is ready to be transported; location requirements for reviewing workstations; system availability requirements for bothdaytime and nighttime workflows; data communication and update requirements between interfaced systems; workflowrequirements for radiologists and non-radiology physicians.Reviewing the user workflows helped the analysts understand the work individual users do, and the requirements for theappearance of individual worklists and other PACS screen functions. Additionally, we reviewed the workflows to understandwhat the performance requirements for PACS were during the expected daily use, and during peak use times. Performancerequirements defined the acceptable limits for the speed with which images would be sent to the PACS server from the imagecapture modalities and how fast the first image within a group of images – a study – should display for the radiologists. Otherrequirements 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 relocatedto a central area, with each radiologist situated at a reading desk. The room was painted dark green, the lighting dimmed andthe temperature adjusted to provide the best environment for reading images. Some sites had physical construction of readingAuthor: Marie Richards, M.Ed., PMP, ITIL Page 7 of 15
  8. 8. areas for radiologists, or adjustable desks to accommodate radiologists whose physical height varied, but who shared thesame space on different schedules. We found it essential that the infrastructure readiness (cabling and environment) becompleted 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 patientrecord for a period of time designated by each State. This meant that there would be a diminishing medical or legal need, but aneed nevertheless, to retrieve older films for comparison, from the physical film storage rooms, for a defined period of time.Workflow AnalysisThe complete workflow analysis identified user needs in different areas. The radiology department needed to provide referringphysicians access to images. The solution for some referring physicians whose volume of referrals was small, was to burn aCD for them with the images and image reader software embedded. Internet access to PACS images was provided at all oursites, using appropriate security protocol to create a secure connection for data transmission from an image web server. Thussome physicians could access the images from home or another location securely. Another limited-use option was to print theimages from special printers. We recommend confirming the alternatives for access with the radiology community, beforeinstalling 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 PACSnetwork by first logging into the hospital network. The technical challenge was to determine how to best authenticate the userIDs for staff logging into PACS via the hospital network Also at one site, there was an URL encryption enhancementrequested 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 toretrieve previous films for scheduled patients, and digitize these films so they could be reviewed by the Radiologists throughPACS. This new task required that the clerical staff received additional training for digitizing images, and had their jobdescriptions changed.An important aspect of workflow reviews was to identify the paper generated from the time a patient’s radiology exam isscheduled through to dictation and availability of results to the ordering physician. The elimination of as many paper processesas possible is a goal of PACS. Some hospitals were able to eliminate the printing of the order requisition. Other hospitalsfound that the PACS software allowed them to enter some notes online, respond to the questionnaires via checkboxes online,Author: Marie Richards, M.Ed., PMP, ITIL Page 8 of 15
  9. 9. or allowed the technician to mark up an online template diagram at the point where radiology technicians reviewed the imagesbefore sending them through for interpretation. These notes were drawings associated with the study and were available tothe reading Radiologist, thus removing some additional dependency on paper. There was some paper on which a patientsignature was required such as consent forms. These were scanned by a device capable of sending a DICOM compatiblescanned 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 aradiology technician’s workstation just outside the operating room in the hallway. This allowed the technicians to take surgicalimages within the operating room, send these images to PACS from just outside the OR. Radiologists located elsewhere in thehospital could interpret the images and communicate to the OR physician by phone. The new capability presents an excitingprocess 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 ata technician’s workstation. This required a change in workflow for the X-ray technician who would now review an image on aworkstation, for a patient as their name appears on the displayed worklist. This was an efficient, interim method to build thetechnician’s familiarity with workstations displaying digital images and worklists. Transitioning to CR from X-ray abbreviates thelearning curve for technicians to become comfortable with a PACS technician’s workstation.Interface DevelopmentWorkflow reviews were crucial for identifying the systems that would communicate with PACS. The selected PACS systemssupported an interface between the Hospital’s Radiology Information System (RIS) and the PACS. Decisions which limit theamount 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 messagesfrom the RIS are transmitted to PACS. The radiology results – dictated interpretations – are transcribed into the RIS and sentto 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 orthrough a secure web access viewer.Author: Marie Richards, M.Ed., PMP, ITIL Page 9 of 15
  10. 10. There may be an interface required between the PACS system and a dictation system (see Dictation, Voice Clips section). Atsome hospital sites, there was a backup server receiving a simultaneous feed of PACS images as the production server. Thisbackup 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 allthe interfacing systems. PHNS’ Integration specialist, Karl Fisher ( advises reviewing the interfacespecifications from the ADT source system (HIS), from the RIS, from the PACS vendor, and any systems to which the PACSimages or updates should be distributed, e.g. ED information system, or a data exchange application. The interface specialistdeveloped the interface engine’s data mapping capability for mapping specific messages between the sending and receivingsystems. Obtaining clarification from the vendor about their application’s interface specifications is important, especially withregard to how orders within the sending system (RIS) are uniquely identified within PACS. There should be clarity regardinghow a single order with its unique accession number translates within PACS which often has multiple images for a studygenerated from that single order.Interface challenges experienced within PACS implementations will vary with the maturity of the vendor and/ or systems. KarlFisher 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. Thesevariations, if not uncovered early, will delay the project during integration testing, since the vendor’s HL7 experts may not beavailable 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 asuccess. A good strategy was to let the RAA take ownership of the integrated testing process, while other persons played asupporting role to the RAA.Author: Marie Richards, M.Ed., PMP, ITIL Page 10 of 15
  11. 11. A challenge we had to overcome was to develop the interface so that there was an unique identifier which linked multipleimages within PACS resulting from a single order, to that single order within the RIS. This unique identifier was necessary toallow any updates within messages linked to multiple images, to update the appropriate single order within the RIS. Becauseof the “1-to-Many feed” and “Many-to-1 order updates”, the PACS unique identifier must be able to point backwards to itsparent 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 receivingPACS images. One PACS system design allowed for simultaneous data feeds to both a production server and a failoverbackup or contingency server. Traditional parallel data delivery designs can lead to lack of data synchronicity if the productionserver were to fail during times of queued message delivery. A serial message delivery design was implemented to betterassure 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, followingdefined integration test plans. This comprehensive integration testing at one site, highlighted a problem within one RIS systemthat had gone undiscovered. This meant that fixing the RIS system was an unplanned event within the project, and causeddelays 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 StrategyMy 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 notraining required at this point, since they would also receive images for interpretation on film, as they did before. The benefit tothe hospital was that a collection of prior digital images would accumulate on-line and be available for reference, whenever theradiologists were ready to read and interpret the images via PACS. Thus at go-live of the actual soft copy reading of PACSimages for most patients, the Radiologists would reference one tool – PACS, not flip between PACS for current images andfilms on view boxes for prior images.Author: Marie Richards, M.Ed., PMP, ITIL Page 11 of 15
  12. 12. Another strategy was to go live with both collection of images and softcopy reading by the radiologists at the same time. Thisabbreviated the go-live event. However, following go-live, there would be period of time when radiologists needed to have allprior 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 toactual use by the doctors and technicians, since desktop space is always at a premium in clinical areas. Image viewingworkstations were needed by technicians for each modality’s technician, physicians in ICU, ED, on stationary workstations andphysicians 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 asto not interrupt patient care tasks.TrainingPreparation for training involved scheduling technicians and radiologists within their rotation and weekend schedules. Planningincluded 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 totheir peers. Sometimes it is determined that some personnel may not adjust well to the workflow changes, and may need to bereassigned.Training end users occurred the same week as they were designated to start using PACS. Training was carried out by thevendor, at the hospital site within the modality departments designated to go live with diagnostic reading on PACS. Foreffective training, this required 2 vendor trainers to be onsite. That training concentrated on helping technicians to view andselect from their list of patient orders, on their modality monitors. The radiology technicians had to learn how to adjust theimage or retake the image if it did not meet the standards for sending to PACS. Technicians learned how to submit all imagesthat make up a study as part of the single order. They were given a couple of days to hone their techniques within the liveproduction environment, before the radiologists received their training on reading the PACS images sent by the technicians forinterpretation. The radiologists’ training occurred at their diagnostic workstations, and required 2 vendor trainers to beavailable for that training, along with the PACS system administrator. Since the technicians had been trained before theradiologists, 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 dictationsystem as they did before PACS, and dictate the patient’s identifying information and procedure name.Author: Marie Richards, M.Ed., PMP, ITIL Page 12 of 15
  13. 13. CommunicationPACS projects convened persons from across many organizational units and external vendors, with their attendantcommunication 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 thenumber 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-coreproject team communications. Within our PACS projects we had communication plans for managing the inherent complexitiesfrom intersecting and crisscrossing communication channels. This included scheduled project meetings at which attendancewas required, documented contact roles and responsibilities, designated decision makers, those who provided advice, orthose 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, issueidentification and progress updates. Issue resolution activities beyond very brief discussions were followed up outside of thatproject meeting. A lesson learned from one implementation was that using project meeting time to discuss contract detailsused up too much project time, since some project team members had limited interest. Another lesson learned was that it wasessential for system and network engineers to be fully engaged in the project from the kick-off meeting so that they understandthe project objectives.It was helpful to clarify the formal and informal reporting relationships within the team, as well as the mechanism for providingperformance feedback to the functional managers requiring that feedback. Additionally, we found success in establishing anearly strategy for building awareness among external physicians for the flimless environment.Staffing RequirementsStaffing 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 staffassigned on a following implementation. Additionally, I received permission to organize a corporate PACS conference wherestaff participating in PACS projects throughout the country gathered to share their best practices and lessons learned withAuthor: Marie Richards, M.Ed., PMP, ITIL Page 13 of 15
  14. 14. each other. This had an immediate payoff on subsequent PACS projects, as those lessons were incorporated into theimplementation for smoother and faster PACS implementation results.ConstraintsConstraints are factors that limit the project teams options. Some constraints experienced on our projects were: a) the hospitaland IT staff availability,b) vendor software readiness statusc) availability of vendor designated hardwared) availability of vendor resourcesThese factors were managed through scheduling project tasks to reflect availability dates. Modality readiness for go-live withinthe PACS environment was constrained by the availability of the modality vendor to schedule DICOM upgrades for their imagecapture devices. Another constraint was the customer environment. On one project, the type and model of vendor specifiedservers had to be changed to suit the customer environment.Scope Change ControlRequest for changes to the initial equipment order for workstations, scanners, digital devices, or display monitors can and didcome out of some workflow review sessions, so part of the planning for the project budget included a contingency budget forjust such an eventuality. Within some projects, workflow reviews yielded changes in some workstation locations, whichrequired additional costs for electrical and network wiring activities.Project ClosingProject 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 productivitygains.Some of our vendor contracts included a clause requiring 60 day post go-live assessment of performance, prior to finalfinancial closure.We found it helpful, after the initial modalities went live, to conduct a formal review of the lessons learned, before the coreproject team disbanded. The focus of our lessons learned activities was to identify our successes, and our opportunities forimprovement. Suggestions for improvement were incorporated within another hospital’s PACS implementations or withinsubsequent modality implementations at the current hospital site.Author: Marie Richards, M.Ed., PMP, ITIL Page 14 of 15
  15. 15. Benefits RealizationWe determined that the various benefits to be achieved could be measured only after some time had passed. Our PACSimplementations focused on capturing productivity measures before any workflows changed, and then targeted review periodsin the future to reassess gains, in keeping with the hospital’s routine productivity assessment schedules.Reference: (1) Marie Richards, M.Ed., PMP, ITIL Page 15 of 15