|
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.
OTech is introducing its first Enterprise Architect training for experienced healthcare imaging
and IT professionals. PACS administrators and other IT professionals who are
looking to advance their careers into an enterprise level position, will gain
an in-depth understanding of Electronic Health Records. The training is based
on the requirements for Certified Healthcare Enterprise Architects (CHEA),
which is the capstone certification for those professionals who are either CIIP
or PARCA certified. The certification exam fee is included in this training. For
those who don’t need the training, however, there will be certification of
participation, which can be credited towards continuing PARCA and/or CIIP
certification.