Misuse of Network Monitor?

[David Teh]

Hi folks,

In the cluster of hospitals that I am, there seems to be an entrenched belief that the Network Monitor can be used to monitor the processes of the servers the QDX is communicating with.

Have you encountered this? Any good way to counter this?

TIA!

Topic

[Michael Lacriola]

Although I have not tried it, you might be able to bastardize an outbound FTP thread to a remote server directory and keep the conneciton up. If the server goes down, the thread will go into “opening” status which then you can set an alert to “do something.”

We are currently configuring OpenWater. I hope they don’t come to me and say, “Let’s put your stuff on here…”

[David Teh]

Apologise if I wasn’t clear.

Since the thread is monitoring only the port in Cloverleaf, and not the process on the other system, rightly Cloverleaf should not be used for monitoring other systems.

But apps people don’t seem to understand this and usually don’t bother to put in place mechanisms to monitor their own application interface program status.

[Keith McLeod]

I am not sure I would call it misuse.  I would recommend that since 99% of the time the any issue of a downed interface on the application side gets a ticket openedd to the cloverleaf resource.  Thye in fact are not the ones that can effect the fix. I would put your documentation in place to clearly indicate where the problem is based on the symptom and take it one step further to either have an operations staff member step throught a quick procedure of resetting the Apps interface or clearly direct the trouble ticket to the application analyst on call and not the Cloverleaf resource indicating what specifically needs to be reset.  This keeps the call volume dwon for the Cloverleaf or any other engine staff and generally bring a quicker resolution to the problem.

[Anonymous]

Unfortunately in our hospital I get calls for every system’s interface… that is the way it is… Most people come to the “Interface” programmer, because they usually know the logistics of everything that is interfaced…

We usually do find that the Cloverleaf engine is our monitoring device to a problem in an interfaced system. But, sometimes an interfaced system’s internal processes may go down and Cloverleaf can not see this because it is still connected and getting ACKs. I get called because ADT or Orders are missing, so my investigation starts with, is Cloverleaf connected and sending? OK, so, now to the system’s interface to see what is happening there… Most systems have decent monitoring, but some are not so exciting to look at, if you can see them… for example, Dictaphone’s voice server is just a bunch of services you can only stop and start and then you have to dig into the files to see what happened… I’ll just say Tech Support of our interfaced systems, know me well… Mary.

[David Teh]

Hi folks,

Thanks for all the responses.

Operationally, we have most of what has been suggested already in place.

But in an effort to catch some of these application failures earlier (rather than wait for it to be flagged in the Network Monitor), I attempted to talk to some of these apps folks about ensuring that proper alert mechanisms are in place on the apps systems. I’ve found that most of them can’t be bothered and relied totally on the Network Monitor to check on their systems.

Really frustrating…….have you encountered this?

[Jim Kosloskey]

David,

Yes I have encountered this and it can be very frustrating.

Your management needs to determine if it is efficient and warranted to rely on middleware to be the first alert for integration issues.

Unless your management decides Cloverleaf should NOT be the primary detector of Sending/Receiving system integration issues, there will be little change to what you are experiencing.

My preference would be that the sending and receiving systems be properly configured to detect all possible anamolies forst and Cloverleaf be a secondary detector.

However, many humans will let someone else perform their responsibilities if they have the chance.

Rant over…

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Daniel Lee]

75% of the calls I get end up being application issues.  It’s just that the interface engineer is the best equipped to play detective and figure out where the issue is.

[David Teh]

Hi folks,

In my experience with these apps team, it also doesn’t help that most evaluate vendor systems as if those are isolated systems. Only at some later point would they deal with the ‘necessary evil’ of interface issues. By then users are pretty much sold on the system and it almost always look like internal IT is incompetent or something like that.

Some of these vendors, suppposedly having some reputation in the healthcare industry, can say they have no TCP/IP socket programs or HL7 knowledge. Oh boy……

Sorry, ranting!

Thanks again!

[Author]

Replies