Connectivity Deja Vu

Tonight, there was semi-emergent IMPAX downtime to allow for the updating of the Connectivity Manager. The 6-8 hour anticipated impact on PACS was planned about 8 hours before it happened, and is necessitated by our imminent move to IMPAX 6.6.1. The system is due back up in less than one hour, and we'll see if we fare any better than last time. You see, this is all quite familiar. Here is a regurgitation of my post, "Connectivity Banisher" from January, 2009:

-----------------------------------------------------------------------------

In the world of Agfa Impax, a "Connectivity Manager" is:

. . . a middleware component in the integration between HIS, RIS, modalities, and PACS systems, linking patient and study data with images. To display the information available from a non-Agfa RIS in the Text area of IMPAX, connect to the Connectivity Manager. . .

The main purpose of the Connectivity Manager is to take data from one system, such as a HIS, and translate it into a format that another system, such as a modality, can understand. Connectivity Manager accomplishes this translation with mappings. The mappings tell Connectivity Manager how to translate incoming and outgoing messages to external systems. The following mappings must be configured so that Connectivity Manager knows which report source to go to for each study, and how to translate messages sent from IMPAX. . .

Map a reporting name into the Data Store by identifying the sending facility in the Connectivity Manager database. Identifying this value means it will work regardless of whether the sending facility sends their name along with the message or not. Also, if the sending facility changes their name at some point, mapping or configuration changes will not be necessary. The Default Assigning Authority identified in this mapping is the name of the report source entered in the Business Services Configuration Tool.

The sending facility is required to view reports in IMPAX. Connectivity Manager uses the Entering_organization and Requesting_Service mappings to populate the sending facility field. These mappings should include the Default Assigning Authority so that every report contains a sending facility.

Our Connectivity Manager was upgraded last night. And again this morning. From the rad's point of view, this means:

During this time Modality Worklists will not be available and Technologists will have to manually input ALL Patient Information. Studies sent to IMPAX will Fail Verification, and will not update with Reports until the downtime is ended.

I drew the short straw, and experienced the joys of the upgrade. Fortunately, the downtime lasted less than one hour, and not two. Of course, only a few of the techs got around to manually inputting ANY Patient Information. Still, we were OK. Until this morning, when this information (including the accession number by which we dictate) was suddenly absent once again. The culprit was, of course, the Connectivity Manager, which seemed to be confused by "multiple" inputs for the same patient. Now that's a problem, which we hope will be fixed by the experts before too much longer.

As usual, Dalai's Laws of PACS apply. In particular, the First and Third Laws are applicable:

I. PACS IS the Radiology Department.
III. Once PACS, never back.

When PACS malfunctions, the department malfunctions, and don't even consider asking anyone to go back to a manual process. It ain't gonna happen.

So, in the ideal land of Dalai-wood (Hooray for Dalai-wood!), PACS should never break. Since that isn't achievable, these thing need to be created with an eye toward simplicity and functionality. Based on what the "Connectivity Manager" is supposed to accomplish, I'm not really certain why it has to be a separate program or computer or whatever it is. Shouldn't the simple, basic, core PACS be able to talk to others? OK, provide a look-up table (user-configurable, of course), but do we have to have a big, separate, grandiose module that manages to bollux up the works when we upgrade it?

Yes, I know..."simple" and "basic" aren't in the vocabulary of a lot of PACS vendors. Neither is "easy". And "uptime" can be defined to the preferences of those making the definition. But as far as I'm concerned, if it isn't totally "up," then it's "down." (Which happens to be true for many things in life.) So, today, we were "down," courtesy of our dear Connectivity Manager.

---------------------------------------------------------------------

A party close to the 2009 update had this closing comment:

Please understand this is not normal hospital type workflow, and with the hundreds of other mappings to get right is an easy oversight, the missing "Cerner ID" should have been noticed during your sites testing and identified prior to the go live.

But once again an easy oversight by all involved.

This also was not a standard upgrade, Yes your CM software was upgraded to the latest version, But behind the scenes each and every interface was recreated from scratch, including the HL7 Feeds, all the modality’s (100’s) and each and every Impax device and client, There was months of work evolved with this upgrade.

On a different note, I truly enjoyed reading your blog, And can fully understand the frustration these upgrades cause the people working with the software. I do try my best to ensure as little impact to your job as possible.

I have yet to understand what, beyond me, makes our system any different than any other. And I'm not sure how we were able to squeeze "months" of work into 14 hours. Perhaps the process has been perfected in the last 6.5 years. Right.

----------------------------

ADDENDUM

Initially, the update seemed to have gone well, and I even sent an email congratulating those involved. WRONG.

It apparently did NOT go well. In the middle of it things went completely down for about 30 minutes. No PACS, no nuthin'. Did we have adequate communications on this? Did we share the responsibility properly?

And our 6.6.x upgrade has been inexplicably delayed.

Not good. Not good at all.