Eclipsys SCM Acknowledgements

[Kathy Rivera-Vazquez]

Hello All –

I am currently working on an ADT interface with Eclipsys Sunrise Care Manager. Eclipsys mentions something about lower level acks and naks they require.

I am only aware of Application Level Acks/Naks

Can someone help me understand the “lower level” ack/nak.

Do tps procs come into the picture? How?

Thanks in advance

Kathy

Kathy Rivera-Vazquez RN
Senior Analyst - Integration
Hospital For Special Surgery
vazquezk@hss.edu

Topic

[David Caragay]

Did the vendor mean to say Minimum Lower Layer Protocol?  If so, this refers to MLLP (also called MLP), the HL7 standard for encapsulating an HL7 message.  You can mlp_tcp.pdl as delivered by cloverleaf.  This will handle your inbound and outbound encapsulation requirements

[Kathy Rivera-Vazquez]

David,

I asked the same question. The encapsulation is the same as any other interface.  This is a Connection Level Acknowlegdement.

The Eclipsys response was there are other accts that interface to SCM using Cloverleaf that can explain it better in a manner I could understand.

I am hoping to get that explaination here.

Thanks

Kathy Rivera-Vazquez RN
Senior Analyst - Integration
Hospital For Special Surgery
vazquezk@hss.edu

[David Caragay]

Although I’m not a tcp/ip expert, this sounds like they are speaking about the lower layers of the OSI reference model (Open System interconnection).  TCP/IP does use acks (not appl level acks) to establish a conventional connection between the client and server.   Normally the delivered cloverleaf protocols will handle this connection process for you.  If they are not referring to this, the MLLP or application acks/naks, I’m out of ideas.  Let me know what you find out.  Thanks

[Kathy Rivera-Vazquez]

David,

Now you’re talking !! The delivered protocols handle this ?? Where can I see them to see if they are doing to the vendor wants? Can I modify them??

Specifically when it comes to a negative acknowledgement.  I was under the impression that the “handshake ack” was simply a thank you may I have another message. I did not realize that a negative ack can be sent in the same respect.  Is this related to the recovery_33 procs???

Kathy

Kathy Rivera-Vazquez RN
Senior Analyst - Integration
Hospital For Special Surgery
vazquezk@hss.edu

[David Caragay]

Kathy,

Since the protocols are delivered with Cloverleaf, you may want to contact Quovadx to get the specifics on how they were written.  Hopefully you can use them as delivered.  I’ve always used the protocols as is and we have numerous tcp/ip connections implemented.  You also have the option of writing your own protocol, identified as PROTOCOL:upoc under the protocol drop-down selection.  Not a popular option but still available to you.

I didn’t think actual naks are used with tcp processing, I believe they use acks only at the connection-level.  This is not related to the recovery_33 tcl procs.  These procs are used at the application level for reply handling.

Have you implemented tcp connections previously?

[Kathy Rivera-Vazquez]

David

Implemented quite a few tcp connections. I have never had to discuss the connection acks with other vendors. Only at the application level.

The specifics of naks at the connection level like the Eclipsys folks are implying are completely foreign to me.

Didn’t think recovery_33 had anything to do with it.

You have been very helpful.

Thanks

Kathy

Kathy Rivera-Vazquez RN
Senior Analyst - Integration
Hospital For Special Surgery
vazquezk@hss.edu

[Richard Hart]

We are using iSoft’s version of SCM.

I beleive that that messaging component is similar with Cloverleaf connecting to MSMQ and sending and receiving data on different ports.

The MSMQ will send a TCP ACK (single character), encapsulated in MLLP when it receives the message from Cloverleaf and expects this in reply when an ACK is sent to Cloverleaf.

I modified the ‘tcp_acknak.pdl’ code for the variant and this has been in production for a few years.

The header is

define phrase basic-msg;

   ;

   field data = variable-array( not( ) );

   ; ;

end phrase;

define phrase ack-msg;

   ;

   ;

   ;

   ;

end phrase;

define phrase ack-msg;

   ;

   ;

   ;

   ;

end phrase;

A word of caution – we proved that if MSMQ crashes when a large number of message are queued – all are lost!

[Kathy Rivera-Vazquez]

Richard,

This is exactly what I am talking about. Thank you about the tcp ack nak explaination. It was very helpful. Especially the warning.

Can you please explain how you have configured the sending and receiving data on different ports?

As I understand it, the messages are sent on one port and the acknowledgements on a different. From a recovery perspective, how would the resending of messages work if there is a NAK?

Thank you in advance

Kathy

Kathy Rivera-Vazquez RN
Senior Analyst - Integration
Hospital For Special Surgery
vazquezk@hss.edu

[Richard Hart]

Kathy.

We send ADT messages (from multiple sites) on one port, LAB messages (from up to four sending systems at multiple sites) on another port and receive ACKS on a third port.,

We set the ‘send’ threads to communicate as a TCP client and the ACK thread as a server and select the icm_acknak (a tcp_acknak variant above) as the PDL.

I beleive that the PDL handles the resend – although not too well.  We have only had issues when the iSoft application is overloaded and  becomes unstable.

I wrote a Perl script to parse the Cloverleaf logs (we use TCL translations and display the ‘old’ and ‘new’ messages) and match a message with an ACK, so we can display a warning if a message did not receive an AC or had an error.

We also log the message control id on all threads, so if there are messages lost from MSMQ, we can work out where we are and recover from the message we have previously stored in daily cycled SMAT files.

We have recently found a bug (one of many!) where a good ACK is communicated to Cloverleaf when an error condition is raised.

I hope this helps.

[Kathy Rivera-Vazquez]

Richard,

You have done a great job in explaining the good and bad about these types of connections. Thank you for taking the time to make it understandable.

This tcp_acknak.pdl you mention. I do not see it in my directories.  Would you mind sharing??

Thanks again

Kathy

Kathy Rivera-Vazquez RN
Senior Analyst - Integration
Hospital For Special Surgery
vazquezk@hss.edu

[Richard Hart]

Kathy,

Below is the ‘original’ tcp_acknak.pdl code.  We use this between Cloverleaf sites and have nevere lost a message (yet!)

The ‘echo’ commnds have been added as we print the RCS ID for all code at startup.

/* $Id: tcp_acknak.pdl,v 1.3 2001/02/14 00:22:35 he00387 Exp $ */

/*

*

*/

define driver tcp_acknak;

   version: “1.0”;

end driver;

/* This driver manages the transmission of messages using the tcpip

* with a 4-byte length encoded structure.  The length placed in the

* encoding is EXCLUSIVE of the encoding bytes.

*

*   – Upon receiving an IB data message, a one character OB message is

*    sent.  The message is the ASCII value ACK (0x06).

*

*  – Upon sending an OB data message, a one character message is

*    expected in return.  The IB reply message is the ASCII value ACK

*    (0x06).  The current driver does nothing with NAKs other than to

*    print a message saying that a “Negative ack received.”

*

* The phrase basic-msg recognizes this message format.  Once recognized,

* the message data will be available from the ‘data’ field.

*/

define phrase basic-msg;

   field msglen = fixed-array( 4, any );

   length-encoded { encoding:network(bytes:4), store-in: msglen } =

begin

   field data = variable-array( any );

end;

end phrase;

define phrase ack-msg;

   ;

end phrase;

define phrase nak-msg;

   ;

end phrase;

/**********************************************************************

* End of declarative section, TCL management functions start here.   *

**********************************************************************/

#{#

# This is a standard ack/nak protocol; use the acknak style.

hci_pd_msg_style acknak phrase:basic-msg

field:data

ackphrase:ack-msg

nakphrase:nak-msg

timeout:600000

######################################################################

# hci_pd.open – Setup driver config during open phase

# Args:

#       config  = keyed list of config data from netconfig

# Notes:

#       It is our job to create hci_pd.device.  This variable is used

#       by hci_pd_open_device to properly open and connect the underlying

#       communication device.

#

proc hci_pd.open { config } {

   global hci_pd.device

   set hci_pd.device $config           ;# Just use it all

}

######################################################################

# hci_pd.initialize – Initialize the driver for use, open the device

# Args:

#       info    = currently unused

# Notes:

#       This function will cause the communication device to be opened.

#

proc hci_pd.initialize { info } {

global HciConnName

# construct a string that is in the same format as the rest of the

# logging and display this to the log file.

set my_ThreadName “[fmtclock [getclock] %X] $HciConnName tcp_acknak:INFO: RCS Info $Id: tcp_acknak.pdl,v 1.3 2001/02/14 00:22:35 he00387 Exp $”

echo $my_ThreadName

   hci_pd_open_device

}

#}#

[Richard Hart]

Kathy,

Below is the ‘icm’ version of tcp_acknak.pdl code.  We’ve called it icm_acknak.pdl

The ‘echo’ commnds have been added as we print the RCS ID for all code at startup.

/* $Id: icm_acknak.pdl,v 1.1 2003/07/14 02:20:06 hcimgr Exp $ */

/*

*

*/

define driver icm_acknak;

   version: “[fmtclock [getclock] %X] $HciConnName icm_acknak:INFO: RCS Info $Id: icm_acknak.pdl,v 1.1 2003/07/14 02:20:06 hcimgr Exp $” ;

end driver;

/* This driver manages the transmission of messages using the HL7 defined

* MLLP protocol.  Each message is bounded by a start character <0xb>

* and a stop string <0x1c><0xd>.

*

* The phrase basic-msg recognizes this message format.  Once recognized,

* the message data will be available from the ‘data’ field.

*

* Note that the ACK and NAk are also sent MLLP!

*/

define phrase basic-msg;

   ;

   field data = variable-array( not( ) );

   ; ;

end phrase;

define phrase ack-msg;

   ;

;

; ;

end phrase;

define phrase nak-msg;

   ;

   ;

; ;

end phrase;

/**********************************************************************

* End of declarative section, TCL management functions start here.   *

**********************************************************************/

#{#

# This is a standard ack/nak protocol; use the acknak style.

hci_pd_msg_style acknak phrase:basic-msg

field:data

ackphrase:ack-msg

nakphrase:nak-msg

timeout:600000

######################################################################

# hci_pd.open – Setup driver config during open phase

# Args:

#       config  = keyed list of config data from netconfig

# Notes:

#       It is our job to create hci_pd.device.  This variable is used

#       by hci_pd_open_device to properly open and connect the underlying

#       communication device.

#

proc hci_pd.open { config } {

   global hci_pd.device

   set hci_pd.device $config           ;# Just use it all

}

######################################################################

# hci_pd.initialize – Initialize the driver for use, open the device

# Args:

#       info    = currently unused

# Notes:

#       This function will cause the communication device to be opened.

#

proc hci_pd.initialize { info } {

global HciConnName

# construct a string that is in the same format as the rest of the

# logging and display this to the log file.

set my_ThreadName “[fmtclock [getclock] %X] $HciConnName icm_acknak:INFO: RCS Info $Id: icm_acknak.pdl,v 1.1 2003/07/14 02:20:06 hcimgr Exp $”

echo $my_ThreadName

   hci_pd_open_device

}

#}#

[Richard Hart]

kathy.

Lastly, I’m on Vacation from Thursday 30th ’til 1st August,

[Kathy Rivera-Vazquez]

Richard,

You have been most helpful. Have a wonderful vacation and thank you for your generous amount of time and code sharing.

I have a very good foundation thanks to you.

Kathy

Kathy Rivera-Vazquez RN
Senior Analyst - Integration
Hospital For Special Surgery
vazquezk@hss.edu

[Anonymous]

Kathy Rivera-Vazquez wrote:

David,

I asked the same question. The encapsulation is the same as any other interface.

[Author]

Replies