Michael J. Cannavo.
There are a number of important issues to be aware of when it comes to service of software-based systems like RIS, PACS, electronic medical record (EMR), and other related systems. And within these systems, there are items that need to be addressed separately such as system and modality interfaces, DICOM routers, and specialized turnkey hardware components such as vendor-neutral archives (VNA’s). Components like scanners or CD burners also may need repair or calibration from time to time.
What you get from your service agreement depends on what you contract for. Most facilities just sign the standard agreement without even reading it hoping that when they need service it will be taken care of in a timely fashion. Sadly there is no universal definition of the word “timely” any more than there are any penalties associated with failure to meet a certain standard of service responsiveness. There is a lot of vagueness in most service agreements with 95% of what is put in writing in the contract almost certain to be interpreted in the vendor’s favor. Understand that what is in writing is not just what matters most but ALL that matters. What a client thought may be covered and the vendor’s responsibilities to the end user are just that: what they thought, not what was contractually agreed to.
Responsiveness
If there is one key to a good service agreement, it's the company’s initial responsiveness and time to at least initiate, if not complete, a repair. Responsiveness is much more than just generating a service request and assigning it to someone.
Ideally, the person taking the request for support over the phone should know the account and its history so the client doesn’t have to answer the same basic questions time and again. They should also be able to log into a client’s system and get an idea of what the latest problem is so they can properly relay the issue internally and assign it to the person who, in their estimation, can address it best. Sadly that rarely happens.
It’s unrealistic to think that every issue can be fixed within a few hours or even a few days but merely saying “we are looking into it” after generating a service request simply doesn’t cut it. Even with the most minor issue, they should have a time frame for a fix. It is also crucial that the system be properly configured with a backup server or at the very least a test server that can be used as a temporary backup server when the primary server is down.
I would venture to say less than one in four systems in use today are properly designed with a backup system in place. This is especially true for facilities under 300 beds. This leaves a facility at a huge risk if the primary server fails. Using a server in the cloud eliminates many of these issues as most cloud systems are designed as hybrid systems with a small-scale server on site in the event connectivity to the cloud server in the cloud is lost. This also allows the system to function until network connectivity is reestablished.
Realistically not every problem requires a DefCon one response and most are fairly easily solvable in a short amount of time. Those that involve patient care and patient safety are always at the top of the list. Those that impact radiologist or technologist (tech) workflow are a very close second, although some might invert that criticality.
The rest of the problems may still need to be addressed but are usually problems that impact only that site or that several other end-users may have but not all and/or those that may not have been documented yet by others. Those are usually found and handled by PACS administrators from sites where there are two PACS administrators (PSA’s): one who handles operational issues and one for technical issues.
Service categories
Most service issues fall into one of four categories:
- System completely compromised or down (Critical) – the system is unable to be used. Running on a backup system (if/as available). Immediate real-time attention is required until the problem is fixed.
- System severely compromised but marginally usable (High) - Significant negative impact on radiologist and/or tech productivity - Immediate attention required: one-hour initiation of action maximum. Repair within eight hours. Use of a backup system is not required, although it may be used.
- System moderately compromised (Medium) - Moderate impact on radiologist and/or tech productivity but no or limited impact on patient care. 12-hour initiation of action required. Repair within one week.
- Limited impact on radiologist or tech productivity but no impact on patient care (Low) - Aggravation issues. 72-hour initiation of attention required. Repair within two weeks
I wish most vendors came close to what has been outlined above but few do. Most end users have a service ticket generated following a request for service and then impatiently wait to hear back from the vendor on what, if anything, is being done. That may be acceptable for items three and four but definitely not for items one and two.
Most PACS vendors are moving to the Cloud to eliminate hardware-related issues, especially if they did not provide the hardware. This allows them to better proactively monitor the system software especially since all end users in the Cloud are using the same software version.
A critical factor
Why is responsiveness so important? Radiologists are under pressure to turn around studies as quickly as possible. Most are also at full capacity with the volume of studies they are reading. If a system is completely down or if reading is compromised so that they can’t read at the speed they normally do this impacts not just the radiologists but patient care as well. Worse, stat studies may need to be read directly from the modality display with initial findings transferred to the requesting physician via phone. Reports are then officially dictated after reading the study a second time. In areas like mammography in which women do not want to wait long to hear the results of their studies, this also impacts patient satisfaction.
Most service contracts are not cheap with many costing 15% of the system list price per year. If a system lists at $500K and is discounted 50% service comes out costing the equivalent of an entirely new system every three years. That also does not include the cost of software upgrades (new features and functionality) that typically are not included in a service contract price (but can be and usually is discounted some by the vendor). Again, in a cloud-based system updates and upgrades are included and provided transparently to the client.
Ideally, a well-designed imaging system has support from a PSA who has a Certified Imaging informatics Professional (CIIP) certification. With that support, interfaces to the imaging modalities and clinical systems can be troubleshot and fixed without having to contact the vendor. These are some of the most problematic areas dealt with on a daily basis. A well-designed system with a backup server (with data replicated in real-time), a test server, and onsite support should allow the end user to address 95% of all system-related issues, excluding hardware replacement.
That said, do you still need service then? Unlike Microsoft and other software providers if you want a software update to the imaging software (aka, bug fixes) the only way you can get this is by having a service contract. There may be a few vendor exceptions out there but this is pretty much the industry standard.. You must have the software updates; there is no getting around it, especially if they may impact patient safety and security, let alone radiologist and technologist productivity.
Typically vendors update their system software twice a year while some do it annually. Few, if any, do it more frequently. Most facilities only update their systems every second or third upgrade version due to the time and testing required when implementing the new software. Again, this is transparent to the end user in a cloud system where service and support costs are built into the software-as-a-service (SaaS) fee.
Having vendor-provided service alone can’t keep a system humming, but it provides a solid foundation when used in coordination with onsite support and a well-designed system. In addition, the vendor and end users should also review the service and system requirements annually and make whatever changes are required to provide optimal performance on a 24/7 basis.
Known industry-wide as the PACSman, Michael J. Cannavo is an independent PACS consultant. He can be reached at [email protected] or by phone at 407-359-0191.
The comments and observations expressed are those of the author and do not necessarily reflect the opinions of AuntMinnie.com.