- This topic has 6 replies, 6 voices, and was last updated 3 years, 5 months ago by
.
-
Topic
-
We are running CIS 6.2.6.1 on AIX 7.2 TL 2. one of the most popular questions our interface team gets asked is, “Was the message sent to system X?”, If so what time was the data sent and possibly provide the ack message (rare occasions getting the request to provide the ack).
This process started when our Health System ran Eclipsys as their HIS and used eLink as the Interface engine. This tracefile process would capture the raw untranslated message (input), the translated message (output), and vendor’s HL7ack to be saved to a file named specifically to System X’s name. This process was migrated over when our system switched to Cloverleaf 10 + years ago, for example sending Radiology orders to Pacs, you could see the input time of the message, the output time of when the message was sent, the ack time from the vendor. You can look at the input, raw message vs the translated message in case any questions regarding formatting came up in this tracefile that was created named TApacs<hosptal abbreviation>. One other side note when we upgraded to 6.2 a few years back we changed from SMAT File to SMAT Sqlite DB’s.
As helpful as this process is from a testing/troubleshooting standpoint I feel its an antiquated process, that involves a lot of extraneous file I/O from an SAN perspective. I was wondering what type of process other Cloverleaf users follow as I’m sure this is a pretty common question in our line of work, “Was the messages sent to system X?”
Jeff
-
Replies
-
-
We use SMAT files for that. They are an accurate representation of what was sent/received.
You shouldn’t get a lot of these questions as the main target is that messages should be sent/received in a normal situation. However we do get the occasional question whether a certain order or result was sent/received, mainly from our PACS key users. Turns out most of the time it is the PACS that hasn’t sent messages when it should have, or hasn’t processed messages (correctly) that it received.
But SMAT should be enough for this imho.Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands
-
Thanks Robert for the feed back, we’ve noticed only few systems out of the many we interface require a little more maintenance in this area, Optum CAC is one we frequently deal with. Since we still use a ksh script to perform the cyclesave functionality based off time I’m going to looking into creating symbolic links to the file system those SMAT DB’s reside on to try and leverage the SMAT Database utility in the GUI. It looks like 20.1 may now provide this built in functionality to cyclesave off time instead of file size so we may even make that switch as well.
-
-
We also use SMAT as the source of truth for this.
We’ve tried saving the ACKs to SMAT as well, but have had issues with it working consistently — probably something wrong in my build, we’re still fine tuning it.
It would be helpful if I could tell when the process writes the message to SMAT.
I’m guessing it’s sometime after State 14, but can’t see anything in an ‘enable_all’ process log that says the message is being written to SMAT. Does anyone know where this happens?
-
As I recall SMAT records are written immediately after an IB message is received at the protocol and immediately after the OB message is written to the protocol.
The only time I have not seen an acknowledgment message when SMAT is turned on is either the receiving system did not send one or someone suspended SMAT temporarily.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
-
-
- You must be logged in to reply to this topic.
