[Ryan Spires]

Go to the root of the directory you want, type:

find . -type d -print | cpio -ov > dir.cpio

When you need to extract or put back into place… go to the where you want to extract and then type:

cpio -id < dir.cpio This should rebuild your directory structure… I can’t take credit for this…  one of my coworkers pointed it out to me. try it in a “safe” place first to make sure it does what you want.

[Ryan Spires]

Think i got it this time…

set lastDayOfMonth [clock format [clock scan “[clock format [clock scan “1 month”] -format %m/01/%Y] -1 day”] -format %m%d%Y]

breaking it out:

set firstDayNextMonth [clock format [clock scan “1 month”] -format %m/01/%Y]

set lastDayThisMonth [clock format [clock scan “$firstDayNextMonth -1 day”]]

[Ryan Spires]

I would prefer to do as Jim suggested…. a lookup table…

However, if you want a simple list (one that would require mod of code to maintain)

Then you could do something like:

tcl>set praList

Deceased {Duplicate Provider} Inactive Inactive/AHP Inactive/Resident Inactive/Student Unknown

tcl>lsearch $praList $data

This will return a -1 if no value found or the index of where it is found in the list.

[Ryan Spires]

The system we are interfacing with is McKesson Horizon Surgery. (HSM)

Anyone else interfacing with this product, inbound reports containing embedded pdf (base 64) in HL7.

We do have an inbound charge interface from the same product that is behaving.

[Ryan Spires]

The two procs, 1 was basically a modified version of a RawHl7Ack did not have any grm statements, pretty basic validation… –Does it have an MSH type stuff and then creating the Ack from hardcoded values… nothing special

The other proc is a filter, which does call two other procs internally to do segment parsing and field parsing.  Both of those procs are in the same file and they are not doing GRM either.  —not the way i would have written to filter, but to each their own I guess.

In any case, I really don’t see an issue with the procs at this point.

Looks like conditions will always be met to either CONTINUE or KILL  the  handle based upon the conditions…and no way to  fall through without.

I have turned up my e/o for the connection just to see some more noice… I haven’t done so yet for the process, but I will be doing that next.

[pdl :open:INFO/1: fr_ghhsm_rpt:03/04/2011 08:21:28] Scheduling driver reopen try in 15.0 secs

[pd  :pdtd:INFO/1: fr_ghhsm_rpt:03/04/2011 08:21:28] Set driver status to PD_STATUS_OPENING

[pti :sche:INFO/1: fr_ghhsm_rpt:03/04/2011 08:21:28] Thread has 0 ready events left.

[pti :sche:INFO/2: fr_ghhsm_rpt:03/04/2011 08:21:28] Performing apply callback for thread 3

[pti :sche:INFO/1: fr_ghhsm_rpt:03/04/2011 08:21:43] Thread has 1 ready events.

[pdl :open:INFO/0: fr_ghhsm_rpt:03/04/2011 08:21:43] Driver attempting reopen

[pti :sche:INFO/1: fr_ghhsm_rpt:03/04/2011 08:21:43] Thread has 0 ready events left.

[pti :sche:INFO/1: fr_ghhsm_rpt:03/04/2011 08:21:43] Thread has 1 ready events.

[pti :sche:INFO/1: fr_ghhsm_rpt:03/04/2011 08:21:43] Thread has 0 ready events left.

[pti :sche:INFO/2: fr_ghhsm_rpt:03/04/2011 08:21:43] Performing apply callback for thread 3

[pti :sche:INFO/1: fr_ghhsm_rpt:03/04/2011 08:21:44] Thread has 1 ready events.

[pd  :pdtd:INFO/1: fr_ghhsm_rpt:03/04/2011 08:21:44] Set driver status to PD_STATUS_UP

[pti :sche:INFO/1: fr_ghhsm_rpt:03/04/2011 08:21:44] Thread has 0 ready events left.

[pti :sche:INFO/2: fr_ghhsm_rpt:03/04/2011 08:21:44] Performing apply callback for thread 3

[pti :sche:INFO/1: fr_ghhsm_rpt:03/04/2011 08:21:44] Thread has 1 ready events.

[pdl :PDL :INFO/0: fr_ghhsm_rpt:03/04/2011 08:21:44] read nothing (link closed)

[pdl :PDL :ERR /0: fr_ghhsm_rpt:03/04/2011 08:21:44] read returned error 0 (Error 0)

[pdl :PDL :INFO/0: fr_ghhsm_rpt:03/04/2011 08:21:44] no PDL exception handler registered => input error

[pdl :PDL :INFO/0: fr_ghhsm_rpt:03/04/2011 08:21:44] input-error in dfa ‘basic-msg’

[pdl :PDL :ERR /0: fr_ghhsm_rpt:03/04/2011 08:21:44] PDL signaled exception: code 1, msg device error (remote side probably shut down)

I did notice something just above “input-error in dfa ‘basic-msg’”

Then the connection drops (goes to opening).. I am not seeing what actually is hitting the pdl.    Again this may very well be normal, the pdl being used is the mlp_tcp.pdl, and is in use just about everywhere, so i don’t really think it is the issue or it most definitely would have been noticed by others.

[Ryan Spires]

Thanks for the replies…  I’ll check again to see, we were only using the rawHl7ack Proc and one other filter proc… no Xlate in this case….

Only two threads in this particular process…

Ryan Spires

[Ryan Spires]

One thing i have found helpful is to run the data through the testing tool with your inbound variant defined (hl7)  The hl7 testing tool will show you exactly what path you should be iterating against.  (group vs segment) based on which numbers increase in the path detail.

[Ryan Spires]

You didn’t specify how the file is delivered… One think you can check if it is a file or ftp on the outbound is what your message terminator.

Check to see if it is “nl”  vs  “eof”   perhaps the engine is adding the extra line.

Can check this on the inbound too.. to make sure you are keeping the entire file intact as you process through the engine.

[Ryan Spires]

Jennifer,

Yes, turns out that the rtimeout has been replaced with timeout (timeout works birectionally) and tmotries, specifies the number of retries.

I removed rtimeout from the pdl

added tmotries:3

addied timeout:60000000

This provides sufficient time for the thread to respond and will now retry if no response.

I have attached our version.

[Ryan Spires]

you don’t need to create a “view”

step 1 ) ADD all messages to view

step 2)  Remove specified message by quickview –   use the last option, regular expression, select not include those, put your fin or mrn into the box

that will narrow down to just the patient your looking for, but with all message types

step 3)  Remove specified messages by quick view, -use the last option again, regular expression, select not include those, put in the message type you want to keep ORU   for example…

I would then skim through the list of messages remaining in your “view”

make sure all or ORU and all match your patient…

Then step 4) select all messages in view

step 5) resend messages in view

hope that helps

[Ryan Spires]

once you filter to the fin or mrn, you can remove from view all that are NOT (select the box) ORU^R01  for example

[Ryan Spires]

If you can identify the mrn or fin number it may be a bit easier…

Then in smat you can isolate  (add only specified messages to view)  with fin or mrn listed…

Once you have confirmed that only the messages you have identified are “in view”  you can select all messages in view and resend to the desired thread.

[Ryan Spires]

if the hardcoding is in the iterate with the concat action, it will put the hardcoding into the data with each iteration.

move your hardcoding our into its own copy command above the iterate.

Inside the iterate when you use the

concat

~1(0).1(0).5(0).0(0).OBX(0).#5(0)

1(0).1(0).5(0).0(0).OBX(%s1).#5(0)

it will pull what you have hardcoded. the first time but not each subsequent time.

[Ryan Spires]

are you adding that before the segment iterate or within it?

If you want at the top, I suspect you would want to add before the iterate.

[Ryan Spires]

Are you wanting to eliminate the subsequent OBX’s alltogether…

If so, it sounds like you are doing a bulkcopy, or a pathcopy within the segment iterate…

If you have a pathcopy using the iteration variables of the segment, you could remove it…

if you are doing a bulk copy, then you can use the pathcopy using source of @null and destination of the OBX segment within the iterate (and use your iteration variable) it will null all subsequent OBX segs being sent outbound.

Ryan

[Author]

Replies