Thursday, January 15, 2009

Connectivity Banisher

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 main purpose 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.

4 comments :

Anonymous said...

Dalai said: "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?"

And if that was done, then when the core PACS had been upgraded to enhance the functionality of the Connectivity Manager, it would still have broken (in this case).

It makes more sense to modularize components which do not need to communicate directly. That way if one goes down, both don't go down. (As matters stood, you could still read STAT studies.) And it's easier to provide them with separate machine resources for performance-intensive environments (i.e. high volume). Finally, if changes are needed in an integration module because of changes in what it integrates with, that module alone can be upgraded.

I'm not familiar with the product, but it's unlikely that a single lookup table is all that is needed to accomplish its task. I counted three likely tables in your description, and it's likely that there are more which are accessible only to service technicians, and which are specific to your specific installation.

Anonymous said...

Issue has been Resolved. By yours truly Michael Reiter, with the Agfa Integration Team,

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 evolved.

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.

Kindest Regards

Dalai said...

Michael, thanks for your help as well as your candid explanation of the circumstances and of course for your readership. Based on all this, is there any way to simplify installations such as ours?

Anonymous said...

Why is there not a Test System to test interfacing, upgrades and resulting PACS behavior prior to deploying on a production system?

Or is there? (uh oh)