@nick-stainback
Forum Replies Created
-
AuthorReplies
-
Not sure if this in the documented solutions for this issue. However changing the mode from BIN to ASCII allowed the files to be downloaded.
August 27, 2010 at 3:32 pm in reply to: Permission error when running hcidbdump -e -D (testing 5.7) #72344Are you executing the command as hci? Also does the user executing the command have “execute” rights on the exec and databases folder.
August 26, 2010 at 5:19 pm in reply to: Permission error when running hcidbdump -e -D (testing 5.7) #72342can you access the contents of the error DB
hcidbdump -e ?
Are the message being written to the Error DB and what is the error state they are in when they get there?
if the downstream system does not need to have the OBX segments you could just use Pathcopy in the Xlate to copy all the segments that they did need leaving out the OBX… does the system need to have the OBX place holder with the NULL Value? I may not be understanding the whole question.
There is something with the regexp that is not parsing correctly and it is allowing all message but A04’s to pass which seems to be the oppasite of what you want to do.
unless there is a reason you have to use the regexp you can try
if {$MSH82 == “A04”} {
lappend dispList “CONTINUE $msgId”
} else {
lappend dispList “KILL $msgId”
}
I have had to do the same thing for a Lab system that would re-admit discharged patients that were updated in he HIS Billing software after discharge, but never to canceled visits
I don’t know that the Canceled date and time is sent in the A08 or anything that would indicate that the visit has been canceled.
Do you not always send the A11 to the downstream systems as well when the visit is canceled? This would remove it there and prevent them from ever sending the A08 or anything for that matter.
When you are setting up the Xlate in the GUI and you select “New” choose the “Inbund Record Format” of ADT_A31 and the “Outbound Record Format” of ADT_A01. Taking a closer look it appears that this is going to be the same issue as https://usspvlclovertch2.infor.com/viewtopic.php?t=2001&highlight=invalid+message+class It looks like the message that they are sending you back is an ACK of some sort is the process setup to handle ACK’s I can tell you this, The standard A34 is only going to have the PID and PD1 fields that match up the the A31.
The PD1 is optionsal so it will not be and issues, however the A31 by default will require a PV1 for most of the Mckesson Products. In Order to add the person record to the recieving system.
You may have to copy the account # to PV1 18 from the PID based on where the app is going to be looking for it.
Good luck, hope this helps,
Now assuming that the messages are standard A31 and A34 messages you will only have the PID and possibly the PD1. Will the HIM system be able to make the necessary updates with just this information is the A31? You Can Read it the message twice
set msgA34 [msgget $mh]
set msgA31 [msgget $mh]
Take the fields and segments needed for the A31 and keep them in var msgA31 and once you have both messages just continue the A31 first and then the A34
Thanks Jim,
I am hoping that these tables at their largest will be 10,000 rows so it sounds like we will be fine.
Thanks again,
Assuming that the ORM would be an inbound from the clients and the ORU’s would be outbound it should not matter. Just be sure you don’t duplicate IB ports.
Just setup your IB(ORM) from Port 1234 and OB(ORU) to IP 12.34.56.78 port 1234
Hope this helps…
If you are wanting to send the ADT’s that come into the existing IB thread to a new outbound that is FTP then, yea just setup the new outbound thread as FTP, configure the log-in and folder information for the FTP server. and then add the route to the IB Thread for whatever Trxids you want to go the the new OB thread. Hope this Helps,
-
AuthorReplies
