Before implementing a PACS system one needs ton consider a number of items that are going to directly influence the outcome of the system. I have decided to compile a list of items that I believe practices looking at implementing PACS should consider. Please note that this list is by no means comprehensive, but is only intended to be a guideline for those dipping their toes into PACS waters.
LAN (Local Area Network)
The local area network is one of the most critical parts of a PACS system implementation, because it is the means of distributing the images to all the machines on the network. Without a decent, robust, high speed LAN in place the image distribution and system reliability is going to be a failure. I would suggest investing in good equipment and skilled networking professionals to ensure that your communications network allows your PACS system to distribute image data quickly, efficiently and with as little down time as possible. I believe that Gbps infrastructure should be implemented where ever possible.
DICOM Status
The DICOM status of all your modalities should be considered. Are the devices at an acceptable DICOM level for the PACS system, is DICOM work list, print, send, etc. enables on the devices. The cost of upgrading the DICOM packages on the devices needs to be considered in the PACS pricing.
CR or DR
The implementation of DR systems at the moment is still much more expensive than implementing a CR solution, however the benefits of DR also need to be considered in this equation. DR systems are said to have the throughput capability of 2 standard analogue rooms. CR may be the cheaper solution in the short term, but I believe that the throughput capabilities of a digital machine could quite possibly allow for more patients to be done in the department and therefore offset the costs. (Please note I am not a financial person)
Statistics
Statistics are an interesting thing and I for one believe that statistics are only a representation of the facts that the person compiling them wishes for the party viewing them to see. (i.e. stats can lie) I would therefore suggest that a decent amount of time needs to be spent analysing the statistical data from various systems to determine things such as patient numbers, procedure numbers, frequency, historical and expected growth, etc in order to get a clear understanding of the costs etc. involved in setting up the PACS system. PACS systems costs are effectively related to the number of patients/procedures that are expected to be done as they result in a certain amount of data that is required to be stored by the PACS system. The other aspect that is going to affect the amount of information that needs to be stored is obviously the type of data that needs to be stored. Different procedures result in different amounts of data. For instance your 64 slice CT scanner is going to generate a lot more information that needs to be stored than your Panorex scanner. So the statistical data presented needs to be as accurate as possible to allow for the correct amount of storage to be budgeted for in the PACS system.
Remote sites
Remote sites or other branches physically separate from the main "PACS branch" need to be investigated too. One needs to ask if the branches are Tele-Radiology branches that only send information to the central PACS branch for analysis there of if the site is a Diagnostic branch in its won right with Radiologists on site diagnosing images. These questions need to be assessed so that you can determine if a WAN (Wide Area Network) solution needs to be implemented and to what extent it needs to be implemented. WANs are basically links between multiple LANs(local Area Networks). These WANs are typically rented from a telecommunications company on a monthly basis, they are much slower than your Local Area Network, but cost a lot more. Other things like WAN compression can also be investigated, but please note that trying to compress an already compressed file will just result in more overhead and basically slow down the lines. Wireless solutions are also arriving as viable alternatives recently, but there are negatives to such solutions such as high latency, stability issues due to weather and possible legal issues depending on your local laws.
Users
It is a well known fact that people resist change and when implementing a PACS system there is bound to be some resistance. Change management needs to be taken into consideration and budgeted for. Users also nee to be educated and this is also an additional cost.
Marketing
I believe that a PACS implementation needs to have a marketing campaign to allow for a smooth transition, after all Radiology is about the referral base and without having the referring doctors on board from the start I believe that any system will fail.
RIS/HIS
The RIS (Radiology Information System) and HIS (Hospital Information System) need to be compatible. HL7 has basically ensured that the systems will talk to one another, but when I say compatible I mean compatible in the environment. The RIS needs to be friendly for the users to use and intuitive. There is no point in having the best diagnostic quality system in place when the reception and typing staff can not get the information that is required in and out of the system. I am also a firm believer in using an integrated PACS/RIS system. There should be no reason to have to pay additional development fees to get an old RIS system to be compatible with the new PACS system, just get the RIS that is already integrated with the PACS.
Billing
The billing aspect of PACS may not be a factor in many countries and in many instances where the hospital is responsible for the billing system, but where I come from our practice has its own billing system which needs to integrate with the PACS/RIS so we can generate accounts and get paid. The development costs of implementing such a link also needs to be considered when pricing the PACS implementation.
Well that is all I can think of for now. If you have any other ideas on something I might have left out please feel free to post a comment. :)
