We are well on our way to deploying IntelePACS. In under two months, our first site should be live, with our remaining sites following shortly afterwards. That is, if all the pieces come together. If they do not… either we will incur delays, or more likely, will incur a rough and tumble go live period.

On the surface, this PACS deployment seems like it should be a walk in the park. We develop our own RIS, so the integration between RIS/PACS should be easier than some other organizations. However “should be” is not always “will be”. Part of our problem is man power and prior commitments. We are way behind schedule on a deployment for our new booking application, Purkinje. This means we are still investing energy into it, when we should be focused squarely on PACS.

Also, there just seems to be no shortage of other mini projects or problems needing resolution, and each of these cuts into our precious time. The idea of hiring a new person has been tossed around recently, but it is no magic fix. First of all, as we are well aware now, hiring takes time. Secondly, even if we find a good prospect, getting them up to speed on what PACS/RIS are takes more time. Since the entire company is so built around around those two systems, even simple things like printer problems often are connected to some specialized software.

Then there are all the little things that need attending to. We have to order all the equipment (modalities, PCs, software, scanners, etc), but to do that properly, we have to know where and how the equipment will be used. As others out there can surely attest to, space is often at a premium, so the size and placement of PC towers or printers or scanners is an issue. Buying something that just will not fit where it needs to go is an issue, as it takes time to renovate or acquire a replacement piece. So all of these little things need to be accounted for in advance.

Similarly, since this PACS deployment will affect almost every employee in some way, communicating with the various departments to either get their feedback on a change, or at a minimum, simply giving them advance warning of a change is important. Unfortunately, something that seems like a good idea to us, may seem the complete opposite to the end user. Identifying issues like these in advance, and finding some sort of resolution, is key. If you give the users reasons to dislike the system from the start, they may have little reason to change their outlook later. Conversely, if users see that you have their best interests at heart, they will often be more patient and understanding as the system experiences rough patches during implementation.

Sometimes, timelines necessitate compromise. For instance, we want to go “paperless”. However, there are different degrees of paperless. The most obvious is simply to have no paper work created or used during a patient visit. And while perhaps ideal, this is difficult to achieve. To us, at least initially, paperless will mean that the Radiologist has no paper. However, to simplify deployment to technologists, they will still do worksheets as they do now, and then scan them into PACS.

How these worksheets get scanned in is, again, not a simple issue. Scanning them into PACS versus RIS has various pros and cons. What hardware and software used also plays a role into the bigger picture. We have chosen to go with PACSGear’s PACSScan product, with hardware still a question mark at this point. This product makes it fairly easy for the user, simply select the patient from a worklist and scan. And it allows us to transition to an electronic form down the road. The thing is, it was also the first product we evaluated. Well, second actually, at one point we strongly considered QuickScan Pro to get data into the RIS. However, that involves integration work and time, so the simplicity of PACSScan won out.

The catch is, we already are aware of a severe limitation to PACSScan… data entered on sheets to be scanned in simply can not be harvested and fed to the RIS. Other solutions may have allowed for this, but we had to move fast, and in doing so, may have either limited ourselves, or (more likely) cost ourselves some money. Once everything gets deployed and smoothed out, we very likely will re-evaluate the scanning process, and to get more efficiency in our workflow, may transition away from PACSScan towards another product that does allow for OCR and integration with a RIS. Which could also be a temporary solution, depending on how quick (or slow!) we are to embrace voice recognition for our Rads.

We also have networks to deploy, hardware to build, and a manuals(!!) to write. There is lots to get done, and not much time to do it in. It will certainly be an interesting time. Personally, I am eager to see how it unfolds, and ultimately where shortcuts are taken, and the repercussions of such actions.

My words of advice to those of you planning a PACS deployment of your own is to give yourself double the time you think it will take, and to plan, plan, plan. We are essentially trying to do this in about four months. Maybe, when all is said and done, I will post how four months is plenty of time. For the moment though, four months seems very short (at least for our staff in our situation).

Bookmark to: