Implementing a PACS By Ginny Poulin RN MS

Implementing a PACS By Ginny Poulin RN, MS & Shelly Fisher

Agenda w Preparing for a PACS w PACS Components Data acquisition, Servers, Workstations w Disaster Recovery and Business Continuity w Workflow / Integration w Cost Justification w Summary and Questions

OBJECTIVES w Identify all the key components of a successful PACS Implementation w Design a successful PACs model w Identify the cost justification components necessary to present and win approval for PACS implementation

PACS Environments - Complex w PACS – not a single “product” w Highly integrated w Requires time to get it all right w Takes using it to get it right w Takes customer involvement, too

Preparing for Your PACS w Start with the end in mind – what is your perfect environment? Where does data originate, who needs to see it – and where w Some items you learn with experience – be flexible w PACS vendor will have different concept of workflow w PACS is a highly integrated environment – standards are key w Purchase items with standards in advance Modalities - buy with DICOM Store, MWL, MPPS Workstations – support for IHE presentation states, key object notes Servers – support for all the above and HL-7 interfaces

PACS Parts / Environment PACS Parts DICOM Archive Reports images RIS HL-7 messages HL-7 Interface DICOM MWL DICOM Server Workflow Engine Web Server images Work stations Dictation system images PACS Environment modalities printer

Preparing for Your PACS w Transition plan – comparison studies, training plan, etc. w Cultural Issues Dealing with Change Who will promote the system / will someone turn film printing off? Relationship between doctors w Communication and Education Plan w Networks – internal and external w Security requirements w Business Associates Agreements w Working with existing environments – such as EM

PREPARING THE PHYSICIANS w Teleradiology w E-Signature w Access from home w ? ? ? Ask Skip? ? ?

What Every PACS Vendor will Need to Know w w w w Exam Volumes and Mix Peak Days? Modality inventory – type and DICOM capabilities Where will exams be viewed Approximate number of users of different types What type of workstations and where will they be located Existing network information / network contact name RIS – whose and HL-7 capabilities / IS contact name EMR – whose and CCOW capabilities - CCOW is standard for integrating the desktop w Shared resource plan (SAN, tape system, disaster recovery site, etc) w Security requirements

What to do with existing, non. DICOM modalities? w Digital modalities must be upgraded to DICOM Store or images frame grabbed. w Upgrade is preference, but may not be available or cost effective w CR and/ or DR implemented w Need plan for comparison studies - digitize films? Hang them?

Modality Connectivity w Connect via fastest connection supported w Modality Worklist Services queries supported – name, ID, date, push? w DICOM Store Services information transmitted – birth date, accession #, etc. missing anything, like series description, or anything odd w Modality Performed Procedure Step Informs RIS / PACS that exam is complete

WORK STATIONS w Types of users: Radiologists, ER, ICU, orthopedics, pulmonologists, other specialists Requirements vary by users, location, environment w Sample Workstation Configurations Only requirement by ACR for radiologist: 50 ftl = aprox. 160 nits 1 MP 5 MP $1500 $80, 000 Increasing quality/complexity and cost

WORK STATIONS Design Points for various users Ease of use, run on any hardware, limit tools and cost Average clinical user More complexity, hardware restrictions, more tools Power clinical user Efficiency, speed, stability, tools, specialty hardware Radiologist

DICOM Server/Archive w Broad DICOM Services – Service Object Pairs w Support for standards in the backend CAN YOU GET ORIGINAL DATA BACK OUT? ? ? w Architecture – Hardware / Software Data integrity, stability/reliability, redundancy, speed, growth, supportability and manageability, maturity (not a place for brand new technology)

HL-7 Integration

Driving Factors for Integration § § § Staff Efficiency Data Integrity Improved Tracking Limiting User Accesses Auto-routing exams to where they would most likely be needed § Reduced cost / complexity of storage environment (shared SAN)

Let’s Start with Workflow w We’ll need some volunteers! w What we’ve just shown is how data is moved through the department and what we are doing with it.

HL-7 Integration Alice in Workflow goes here

Items we would have noticed, if we’d been paying attention w How many times was the patient name entered into the system? Hint: it’s a number less than 2

Items we would have noticed, if we’d been paying attention w Who enters the information? Hint: it is someone who knows how to type reasonably well

Items we would have noticed, if we’d been paying attention w Does the PACS create image data or report data? Hint: No, it just stores it and provides access to the appropriate users

Items we would have noticed, if we’d been paying attention w This exam identifier, called the accession #, is pretty key to the tracking process.

Other items of note w The transfers between different RIS / PACS/ Modalities is handled by STANDARD Methods: HL-7 & These DICOM Services: Modality Worklist & DICOM Store Make sure all new Modality orders include these – Also ask for Modality Performed Procedure Step (MPPS)

What to expect in the integration process w Meditech to PACS First, it is a process, an expensive one and it takes time – so get started as early as possible n n Interface Vendor is KEY and effects the BOTTOM Line BIG TIME Meditech requires additional hardware Vendors need to understand each other’s language, as well as site’s workflow Then, they need to map one ‘s Terminology to the other’s ADT, reports and orders matching them to test

Meditech to PACS (continued) w Sample mapping issues: What is used for key patient identifier and what is it called – Patient ID, MR#, etc. How many physician types come across in an order and what are their types? Do we get information on patient location? How many characters in exam ID (DICOM has a limitation) For Distributed Environment, site identifiers can be concatenated to patient and exam IDs.

Meditech to PACS (continued) w Testing Phase: Once mappings done, test messages. Everything being transferred to PACS database as expected? Are messages consistent? Test in abnormal conditions for example, with HL-7 link down, do messages queue properly? Resolve all issues, then, test with production system, real data § Once tested with production system, real data, ready to deploy

Meditech to PACS (continued) w Can purchase interface from Meditech or other party w Heywood Hospital selected Iatric’s Engine w Reasons n n >50% savings Accommodated our schedule One on One help – A team approach Weekly conference calls and then some

Why do interface early w Data integrity Any PACS worth its salt tests data before storing – won’t allow for duplicate patient IDs. First patient name with ID stored in system is assumed to be correct, so later, the right one could get rejected. Early studies may just for telerad, but bad data will live – if you store data permanently Want to store data early to build up comparison studies in system for doctors Of course, won’t find the comps if they are under the wrong patient ID

Why do interface early w Get DICOM integration done early Large part of complexity of PACS is with modality integration – and they are all a bit different Examples: some Ultrasounds won’t take birthdates, Some want to change key data – even against IHE specs, for example, some insert their own study instance UID Once integration is done, you can concentrate on training the users!

Improved Tracking w PACS always knows the status of the exam w PACS can assist finding and repairing “broken” studies

BRIT’s Exam Loop Order Arrived at RF Study Reported Patient Arrives at Department Study Read Order Canceled Study arrives, but no order! Study arrives at server

Limiting User Access w PACS can limit the patient access to just those patients with known relationship w Information come from order (but PACS can enhance it with “groups”)

Sharing SAN / Archive Resources w RIS and PACS must have support for same SAN / Disk vendor w Meditech has limited support, EMC is certified w Cost of SAN server, archive and support can be shared

PACS installed, integrated and tested. Now - Training w Determine skills sets early – and get additional training for users before system deployed – example – everyone should know how to use a mouse w Bring on additional staff, work additional hours or reduce workload during training w Assign a trainer – new users will be around all the time

Cost Justification Hard savings and Soft savings Hard savings you can readily measure Soft savings may be by far the greater saving, but they are much harder to measure These will differ from site to site Note: it’s a hard saving if your CFO says it is

Hard and Soft Savings Hard savings Soft savings • Reduced film, chemical and folder cost • Reduce off-site storage cost • Reduced cost of processor maintenance • Reduced retakes • No repeat studies due to lost exams • More efficient use of personne Technologists, radiologists, others • More efficient use of equipment • Reduced space requirements • Reduced Liability • Improved exam tracking

What does a film-based system cost? And we know that things cost more in small hospitals!

What are typical savings with PACS Hard to measure because more items change in environment

STORAGE w SAN vs NAS vs Modality storage n n n Other data to be stored? Protecting the data for 30 yrs Meeting future needs

Total Savings and Analysis

Paying for your PACS w Straight Payment w Leases, with delayed payments w Off balance sheet leases - one expense replaces another expense - include technology upgrades in out years w Price per exam models w This year, aggressive government write-offs for capital

LET’S TALK w. Questions