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.