|18% of the users are ready|
to throw out their system
Our newsletter poll showed that 18 percent of current PACS users are unhappy with the current vendor and another 18 percent is very frustrated, which could be a good reason to consider switching vendors. It is therefore critical to practice what we have learned during the first set of implementations, which allows us to be better prepared for the selection process and hopefully result in selecting a vendor we can embrace and be happy with. Even if you do not intend to switch your vendor, these recommendations might assist you to be better prepared for a new system from the same vendor.
Here are 12 critical items to consider during the selection and preparation process (note that his blog is a companion of the Youtube series on this subject):
1. Collect extensive data from current users.
Organizing a workshop is a great way to gather input. In the ones I have participated in, we would typically spend an afternoon and create groups of multi-functional teams consisting of physicians, radiologists, IT, technologists, support, service, biomed, and administration. It is important to appoint a “scribe” for each team, and have him or her list the top three items that are most annoying and, or time consuming, and list the top three items that are most valuable, and finally, list 10 functions or features that one couldn’t do without. At the end of the meeting aggregate all the lists and prioritize them with the whole group, as well as publish the results for those who couldn’t participate, and ask for comments.
2. Re-engineer the workflow and review procedures.
It is a good idea to document the current workflow and perform a thorough analysis taking in to consideration the flow of a patient, physician, radiologist, images, reports, and any other people or systems who are involved with the process. This information would be benchmarked against current requirements for throughput, turnaround time, etc. and desired key indicators. The key indicators should be prioritized, for example, for an ER it could be efficiency, patient wait time, physician turn-around, etc. For the ICU, or main radiology it would be different. One should find out whether there are limitations in current production that dictate certain workflows, and review policies and procedures and challenge them; note that policies have a lot of details on down-time procedures, back-ups, etc. and it is a good opportunity to review those.
3. Re-evaluate external data import and export rules.
The input and output of clinical data is often a bottleneck, such as where are CDs created, and should this activity be centralized in the file room, for example, or decentralized in each department or location. The same applies for the rules for importing data on CDs, who does it, where is it done, how is the information reconciled with potential existing patient records, where is it going to be stored, in the archive, local cache or only the workstation to be pulled up for comparison? Another increasing issue is the electronic connection. How do you deal with electronic data transfer from an IDN, PHR, other HIEs which are being established. Remember, never ever import any information without checking and determining potential reconciliation issues.
4. Anticipate hardware and software changes.
There will be regular software updates and changes, how are these covered and anticipated? Such changes as higher resolution and increased data output from modalities, and new standard extensions defined by IHE and DICOM could impact performance and require upgrades. It is almost certain that new computer hardware and CPU memory requirements will have to be addressed during the life of the PACS, as well as upgraded disk capacities, new OS upgrades and database upgrades. Remember never to buy too much storage capacity as the price will drop and capacity will probably double for the same enclosure on an annual basis.
5. Create a “sensible” RFP and write a better contract.
An RFP should neither be too long nor too short; I have seen RFPs that are 500 pages and some that were 25. I suggest RFPs should be less than 100 for a typical facility. Don’t ask a vendor to specify hardware specs for “commodity” components such as monitors, as these are pretty much all from the same manufacturer anyway, but, rather focus on application level functionality. Focus on workflow and integration requirements. Review contracts and address any disputes and, or issues that come up, and most importantly, have it reviewed by a consultant in addition to a lawyer. Include an arbitration clause, and I include a money back guarantee in case of non-performance, but make sure you state performance requirements clearly. Also, make sure you address upgrades and extensions to make sure that there are no extra charges for that.
6. Include a complete test system.
A test system should include a RIS simulator and the capability to create test transactions, a test broker/worklist provider and set it up to provide a test worklist for demos, as well as a test PACS server with a capacity of a few days to a week (poll users for what is an acceptable test capacity). Make sure the system always provides a dual path for reports and image access, e.g. from a web server independent from the PACS (in case the PACS is down). Test and simulate modalities, using test images which are available from IHE “Connectathon” activities as well as, AAPM to test imaging pipeline, calibration, and performance. Your test system should also have network sniffer capability and validation tools loaded, as well as network monitoring tools.
7. Look at alternate service agreements.
Consider in-house support versus outsourcing, or third party service providers. Also consider an arrangement of time and or materials versus full warranty. It is important to bundle training and negotiate this line item. Going forward, clearly specify what responsibilities the various departments including IT, biomed, RIS support and PACS support, have, and clearly specify the boundaries. For example, spell out who addresses the work list being down, the RIS or PACS support person? It is important to specify and include every detail, for example, who is calibrating the monitors (automated, manual, biomed, PACS administration, etc.), who is vacuuming the computers, air filters, who is cleaning the CR cassettes, who is clearing the CR plate jams, and many more.
8. Consider a VNA or cloud service for your archive.
Based on another recent OTech newsletter poll, we found that 50 percent of our readers are considering “Vendor Neutral” archiving. However, there is no uniform agreed upon definition of the VNA, therefore, be very specific in the specification of YOUR level of integration (see resources). Weigh costs and requirements of the VNA against the strategic importance of keeping your data “close to your chest.” Develop a roadmap for integrating the other specialties and “ologies”– work with an institution-wide task group to see whether there are economies of scale that can be achieved by incorporating more parts of the enterprise.
9. Consider pay for service.
One might consider archiving all of the images and related information to the cloud, or only archiving externally for backup and disaster recovery. An important factor to consider is the tradeoff between the cost of capital vs operations cost. Look at the potential risk of outsourcing, even systems of giants such as Amazon and Sony have been known to go down, and closer to home, Cerner had a serious downtime period as well. There is always a risk of hackers or simply infrastructure issues caused by a construction crew cutting a fiber communication connection somewhere. Another important consideration is how the cloud fits within the IDN/RHIO/HIE and NHIN strategy. Most institutions have almost no choice as they might have an internal skill set limitation and availability issues, but if not, this could also be a consideration.
10. Perform a risk analysis.
Look at workflow bottlenecks for physicians, radiologists, technologists, patients, PACS/RIS administrators, service, IT and determine security and privacy risks. Walk as a patient would walk, and find if there is any potential security cracks allowing access and visibility to information that should be private. Evaluate audit trails, what is their accessibility, level of detail, and security, as well as standards support, or is it a proprietary vendor-specific format that is hard to access and report from. Re-evaluate back-ups, disaster recovery, redundancy, and business continuity and determine the money the enterprise is willing to spend to prevent every additional potential minute of downtime. Remember, the more redundancy, the more expensive it is. Implement patient safety rules and checks, and establish an overall quality improvement plan including several QA steps.
11. Create a detailed acceptance test procedure.
Make the acceptance test part of the contract and tie compliance to payment and penalties. Always modify and customize the “standard” acceptance test provided by the vendor. Preferably, let the acceptance test be performed by an independent party or consultant, or, if that is not possible, get volunteers from other departments who are not familiar with your flow and are preferably unbiased to execute them. Create detailed scenarios to include patient admission, the performance of tests, etc. Cover all exception scenarios such as, but not limited to, merging patient, exam merge, append, delete, update patients. Make sure you cover all modalities, specialties and departments.
12. Anticipate future standards updates.
New DICOM extensions need to be planned for covering new modalities, services, and structured report templates. For example, IVUS was a not around five years ago and many PACS systems have been, and are still struggling, to facilitate that. There will be new HL7 extensions and new versions, as well as IHE extensions. New scenarios for different specialties will be covered by IHE and new and updated exchange standards such as PIX and PDQ will be introduced. There will be new document standards covered by XDS, XDS-I, and CDA. I strongly recommend that the vendor be required to support any new standards up to a specified date after a particular release date (for example three years), preferably at no charge or as part of the normal service agreement.
In conclusion, whether or not you are looking for a different vendor, or planning to stay with the same vendor, apply lessons learned as mentioned above and you’ll be guaranteed to be better prepared for the transition to a new system and end up happier with your vendor than you might be today.