|
The HL7 system managers guide is a good
resource, and is available on the VDL. From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Larry Andreassen I just received another more detailed response from the VistA HL7 team,
and am including below... 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:
On 12/22/05, Larry
Andreassen <[EMAIL PROTECTED]>
wrote: 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! On 12/22/05, Larry
Andreassen <[EMAIL PROTECTED]
> wrote: There are now two different flavors of the VistA HL7 package on (1) VistA HL7 (I'll call it) CLASSIC (2) The 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.,
|
