TDM, a history of Impact

Today I came across the acronym 'TDM'. I've worked in the field of healthcare IT for quite some time now, and I was sure I had heard it before. Just could not find the right drawer in my head.

From the context and some other drawer in my head I derived that it had to do with an integration platform and message brokering. Enter Google. Now this is old stuff, so I had to look a bit further. The answer:

TDM is an acronym for Transaction Distribution Broker, and it is a communication broker created by CAI - Century Analysis Inc. I think it was then already bundled with the (then BAZIS, now iSoft) ZIS (Hospital Information System, but then the Dutch acronym). In 1998 it was transformed to Impact, which again was bundled with iSoft ZIS to make it communicate with the outside world.

By now, CAI does not exist anymore. It was acquired by New Era of Networks Inc. (NEON) in 1999. NEON was acquired by Sybase in 2001. Sybase now offers the product under the name "e-Biz Impact".

Thanks to Ric Cross for providing the meaning of TDM. He knows a lot more about it (I quote):

Transaction Distribution Management - There was no binary by that name in the product suite ... just a marketing name to provide some clue as to the products purpose. A "Distributed Computing Environment" (DCE) based "POSIX compliant" message broker.

At the time the term was "Message Oriented Middleware" TDM had several pieces that worked together, the Broker Server Manager (BSM) the Store and Forward Manager (SFM) and message client/servers, we called them Adaptive Interface Modules (AIMs). The concept "Common Services" was the prevalent and primary underpinning of the functionality of the suite. The TDM client GUI was in my biased opinion one of the better parsers of the day. You used the GUI to craft "Production Objects", basically, under the covers C++ class structures for the proprietary "Object Definition Language" (ODL). The ""Production Object" consisted of an inbound definition and the outbound definition. The Outbound Rules were where the transformation of data took place, rules would consist of rule components, with qualifiers and filters (pre and post), built in function calls, etc.

The GUI layout was good. What was clever was the ability load sample data to test the parse and step through the outbound rules.

Typically a developer took the the Production Objects and referenced them to a SFM. The SFM was defined with AIMs for either Inbound or Outbound and presto you were moving messages. You could embed Production Objects within the AIM, make a ODL function call to it to determine data values, set dynamic links, as an example, which SFM or any number of manipulations, use it to call another AIM to retrieve additional data etc, all in all some fairly sophisticated processing could be developed.