Forum Replies Created
-
AuthorReplies
-
I count interfaces based on message types: ADT, ORM, ORU, etc … You can have one thread for a vendor that receives ADT and orders on it, that’s two in my book, not one.
Another example is that we have an Epic inbound charge interface that receives charges messages from 4 sources. That’s 4 total, not 5, and certainly not 1.
Any localhosts in our sites do not count.
Similar at Cadence Health, but have 200 and adding another 20 in about 4 months. Right now, 2 people. Jim,
Code seems to be working. More testing to happen next week. I took a copy of hl7_reply_gen and created a tcl file called vs2_reply_gen.tcl. Added the code:
msgmetaset $ackmh DRIVERCTL [msgmetaget $mh DRIVERCTL]
right before:
return “{$disp $mh} {OVER $ackmh}”
and started it all up after adding the vs2_reply_gen to the IB tps proc stack of the threads defined to receive data from those monitors. I’m curious as to why Infor doe snot supply a Tcl proc for multi-server ACK/NAKs. Easy fix, but should not have been necessary.
Thanks. Project moving forward and that’s what matters.
I’m now told that they expect replies back (a change from what I was originally told). Does the regular hl7_reply_gen work for multi-server connections?
I received an error back “Unable to deliver to specified server connection.”
At Cadence Health, we are converting to 5.8.5 and getting new servers, and moving them to a new Data Center, and not using IBM’s HACMP software, but opted to use Semantec Veritas Cluster Services.
6.0 would have been nice, but to much change….We’ll be on it by end of year hopefully.
I got 30 in one of mine and working fine. However, I would not recommend that and we are looking at ways to minimize.
Some of the threads in that process are extremely low volume, and we do have 16Gb of memory on our box. Stopping/restarting process takes less than a minute.
Like I said, I would not recommend it.
Thank you for the resopnse. April 9, 2012 at 6:20 pm in reply to: Cloverleaf having a hard time processing large amt of data #76347We are currently in the process of backloading about 300,000 messages and I find it easiest by handling it with a fileset-local protocol thread. This allows me to set how many messages I want to read and how many seconds to do it in. I’m set at 10 messages every 10 seconds. That’s 86,400 messages a day. Pretty reasonable…
I guess the kicker was that I was running the proc in the IB Xlate Tps. I never knew that a Tps proc would never run in the “start” mode of an IB/OB xlate Tps.
I chose to use the alternative method instead of setting the “start mode” in the engine process configuration. The alternative solution worked perfectly.
As for why I chose the alternative method: fear of the unknown. I did not like the concept of changing the overall engine process to have it run xlation procs in start mode. I never had a need for that until now and I would probably forget that I set it.
The alternative is a very clear and self documenting when looking at the code. Very easy to understand.
Thanks again.
No joy. Get and error in RUN mode stating that can’t read $prevMRN: no such variableduring cequel command which look s like this:
if {[cequal $prevMRN $currMRN]} {….}
The tps is within the IB xlate routing thread. The global prevMRN is defined right under global HciConnName, the set prevMRN “” is defined in start up switch, the cequal command is within run switch.
I also make sure the engine processed in stopped/restarted before trying it. Frustrating for a simple idea.
I’ll give it a try.
Excellent. Thanks.
At CDH, we are in the throws of a mega device intgeration with Epic that uses Philips bedside monitors, and a whole bunch of other things (anesthesia carts etc …).
All interfaces will pass through our Cloverleaf engine. For the non-Philips monitors, we will be using iSirona. We did look at Capsule and determined that iSirona was the way to go for us. A much cheaper solution.
We did have issues with connectivity with Philips initially. The inbound thread needs to be considered as the client. If you set it up as a server, like most of your other inbound threads, you’ll experience many disconnects. It took us a while to figure this out. Once we switched it, connectivity was extremely stable.
This was more or less how to get the XML definition into Clovearleaf and testing it with an actual XML file.
I created a package and loaded a DTD by itself into the folder. This is not the same as taking an existing XML file with a DTD embedded into it. That would work according to the documentation. An XML schema is supposed to work too. Unless, you get a XML schema from your vendor, I would not attempt to create one unless you have some real good experience.
Working with external DTDs seems to be the easiest for me. Keep the file name of the DTD the same name as the root element within DTD. So I have a DTD called partial_dictation.dtd and my DTD looks like the example below (Keep it simple). When testing, leave out the reference to the DTD in the XML. It’s not needed, in fact, it wil cause an error.
The example has a root element called partial_dictation (matches file name).
Why do I bother posting…I found the answer to my problem. You can simply add the file extension in the FTP options under the Dir List Command of the fileset-FTP protocol. Been a long time since I messed around with this aspect.
The default is simply nlst (which for the life of me do not understand how it works since the nlst command is not a valid command for FTP in Unix, nlist is correct). See the sample output once FTP has been established to remote system below. There’s probably some sort of alias or something within Cloverleaf. Who knows…
ftp> cd partial
250 CWD command successful.
ftp>
ftp> nlst
?Invalid command
ftp> nlist
200 PORT command successful.
150 Opening data connection for /bin/ls.
total 32
-rwxr-xr-x 1 lacriola cachegrp 651 Jul 16 08:57 PV-BLD-399.xml
-rwxr-xr-x 1 lacriola cachegrp 649 Jul 16 08:57 PV-BLD-400.xml
-rwxr-xr-x 1 lacriola cachegrp 651 Jul 16 08:57 PV-BLD-402.xml
-rwxr-xr-x 1 lacriola cachegrp 663 Jul 16 08:57 V-BLD-401.xml
drwxrwxrwx 2 lacriola cachegrp 256 Jul 15 15:56 save
226 Transfer complete.
ftp> nlist *xml
200 PORT command successful.
150 Opening data connection for /bin/ls.
-rwxr-xr-x 1 lacriola cachegrp 651 Jul 16 08:57 PV-BLD-399.xml
-rwxr-xr-x 1 lacriola cachegrp 649 Jul 16 08:57 PV-BLD-400.xml
-rwxr-xr-x 1 lacriola cachegrp 651 Jul 16 08:57 PV-BLD-402.xml
-rwxr-xr-x 1 lacriola cachegrp 663 Jul 16 08:57 V-BLD-401.xml
226 Transfer complete.
By changing the default of nlst to nlst *xml, this solves the error in the protocol when it encounters a directory as part of the nlst return. I’m sure there’s other flags that could be used with nlst, but I’m happy with my current results. Moving forward…
-
AuthorReplies