I think that the bad message needs to be reviewed before the action is taking.
If a bad message is deleted without checking, it may impact the other messages which are needed to be transmitted in order, such as many MPI messages belong to this category.
It is possible that many messages in queue have the same bad pattern because usually the messages in the same queue are created by the same application. It they are deleted with checking, we may not know the problem because all the "bad" messages are skipped and there may be a serious problem (patient security) there we do not know. Perhaps the problem is caused by the code of HL7.
I saw an example of the bad message in queue for BCMA because it contains thousand CR in the message. After reviewing the message, we found the CR problem and referred the bug to the TIU (CPRS) developer for patching. Vista HL7 may catch the problem and let the message passed with more than 512 CR (carriage return, or ASCII <13>, segment delimiter) by enhancing the code. However, I think that it is not worthy and rather let the application to fix the CR problem.
Another example is related to VIE, in some case, the VIE does not like the default action as "Ignore" and need to be set as "restart." I do know the reason, I think that it may relate to Vista HL7 "error trap" (possibly to be caught in the device "SYS$NET") or it could be a network or system level connection problem.
I saw the "error trap" in HLCSTCP4 did not trap the system level "write error" or "read error" (when the client is disconnected or when the writing of buffer is error out). This may cause looping without knowing the problem, I think that this may need to be revised:
I $$EC^%ZOSV["WRITE" D Q ;HL*1.6*77 modifications start here
. D CC^HLCSTCP2("Wr-err")
. S:$G(HLPRIO)="I" HLERROR="108^Write Error"
. D UNWIND^%ZTER ;HL*1.6*77 modifications end here
I $$EC^%ZOSV["READ" D CC^HLCSTCP2("Rd-err") S:$G(HLPRIO)="I" HLERROR="1
08^Read Error" D UNWIND^%ZTER Q
To remove the message from queue:
- kill the x-ref, "AC","O",<ien of link>,<ien of message in file #773>
- The status of the message may optionally be set to error(4).
You mentioned a problem with a problem message at the top of a queue that is holding up processing on the remainder of the queue. I'm told that you should delete the front queue entry.
A little more that I gathered from my conversation with the VistA HL7 team...
The VistA HL7 package (the CLASSIC that's been used for years) is being frozen; no new development, and patching only for critical problems. They are documenting known problems with the package, and work arounds. (This problem will most likely be included.) As mentioned before, they've rewritten the VistA HL7 package and are encouraging everyone to transition as soon as possible and practical.
Here's a blurb from one of the VistA HL7 developers about the new software...
Any message that won't successfully transmit after several attempts over a defined period of time is automatically taken off the queue and an error generated to the local site. This unblocks the queue, but is done in such a way to guarantee that the site isn't flooded with huge numbers of errorred messages.
Hope this helps!
LJAOn 12/22/05, Larry Andreassen <[EMAIL PROTECTED] > wrote:There are now two different flavors of the VistA HL7 package on VistA...(1) VistA HL7 (I'll call it) CLASSIC(2) VistA HL7 NEWThe VistA HL7 package has been totally rewritten recently. I have little awareness of the features in the NEW VistA HL7 package, but will make inquiries of the VistA HL7 team.Also, will ask for their advice on your question.
On 12/22/05, Robert Leonardo <[EMAIL PROTECTED] > wrote:Larry A.,
Thanks for helping me configure the encoding characters for my interface. I have made the appropriate changes and tried sending a new message. The trouble I'm running into now is that the logical link does not give up sending the bad message (protocol requires ack) at the front of the line to let the ones behind it try to go. I have tried the purge messages function in the HL7 Main Menu but it seems to only allow me to delete messages that have been around more than a day. T-1.
Is there another way to clear out the outgoing queue?
Thanks,
Robert
