Optimal utilization of wildcards when routing messages

Homepage Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Optimal utilization of wildcards when routing messages

  • Creator
  • #49623
    John Pope

    Hello All,

    Cloverleaf 3.8.1P

    AIX 5.3

    (upgrade to 5.5 coming soon!)

    I have a registration system that utilizes 15 different ADT event types.

    There are currently 42 “downstream” ancillary systems, with TCP/IP HL7 mlp client connections that receive ADT.

    To eliminate a “hub and spoke” configuration with one server sending to 42 clients, I divided the load between several localhost client/servers, that in turn feed the downstream systems.



    _hci_static_raw —-> 1_inbound, 2_inbound, 3_inbound


    _hci_static_raw —-> 1_outbound


    _hci_static_raw —-> 2_outbound


    _hci_static_raw —-> 3_outbound



    > ADT_Lab, ADT_Rx, ADT_Cardio



    > ADT_Rad, ADT_ER, ADT_MedRec



    > ADT_OBGYN, ADT_Pedi, ADT_Rehab

    (there are actually 7 “#_outbound” servers, each sending to 6 clients)

    When routing messages, every one of these servers has a route defined for each of the ADT event types or TRXIds sent from the Reg system (15 in all).

    This means we have a total of 105 message routes defined for ADT (7 localhost servers with 15 routes defined for each.

    Due to the fact that not all ancillary systems need all ADT event types, the number of details under each route varies.

    Example: The route for an ADT^A08 in the 1_outbound thread, may have 6 detail lines, because all six systems fed from this thread may want to receive A08 transactions, but the route for ADT^A34 may only have 1 detail defined, because the downstream systems may prefer to do manual merging.

    I am now trying to determine the best way to set up the wildcard routes.

    What do you think would be the best appraoch?

    A.  Define one all inclusive route


    and utilize the xlate route detail preproc to kill the message before being translated if the system does not want the event type?

    I would go from 105 defined routes to 7.

    B. Define a route definition for each ancillary system? (the same event type will get processed several times in some cases like the A08 example listed above).

    I would go from 105 defined routes to 42.

    C.  Make enough routes to cover all the different combinations of Event types sent to the 6 ancillary systems?

    I would go from 105 defined routes to roughly 35.

    D. Define the routes based on the number of likely translation files?

    Example:   1 route for all event types except A17 and A34.  Another route for A17s and a final one for A34s.

    I would go from 105 defined routes to 21.

    E.  Something I’m not thinking of.

    I’m not sure about how well I did communicating my thoughts, so feel free to contact me, if you find yourself in need of any clarifications.  I also apologize if this seems a bit long winded.

    Thanks in advance!

    Jonathan Pope

    (617) 638-8615


Viewing 1 reply thread
  • Author
    • #62758
      Mike Grieger

      So, it sounds like you have 3 translation files at most for each recipient?  All ADT types except for A17 and A34

    • #62759
      John Pope

      I believe you have a good grasp of the situation.  

      It seems like “C” would really be the best configuration choice.

      Although “D” would “look” cleaner, I’d still have to use tcl to kill messages on occassion for unwanted transactions. I wonder if what I would gain in simplicity to implement, would be worth the extra processing to perform the additional filtering??


      Thanks for your input.


Viewing 1 reply thread
  • The forum ‘Cloverleaf’ is closed to new topics and replies.

Forum Statistics

Registered Users
Topic Tags