[Daniel DeLoach]

Well the fine folks from development were finally able to come back with a fix of sorts for our problem. This involved them making some kind of change to the syntax in the hcicmd.pl file in the bin folder. Exactly what is not clear to me – but it works now so this is good.

I’ll just need to make a note and keep a copy of this “custom” hcicmd.pl file somewhere so that I know its out there and have access to the custom version if it should ever get overwritten (upgrade, etc) and this should stop working again.

[Daniel DeLoach]

*DUH*

Nevermind, I need to override the original BULKCOPY first to clear out the output field.

*DOUBLE DUH*

[Daniel DeLoach]

Hmm…well, it “works” now, in that if I get |ABC~XYZ| coming in, I get |ABC~XYZ| going out.

Strangely, maddeningly, though – if I get |~ABC| coming in, I still get |ABC~ABC| going out. This isn’t the end of the world, as I think it will work as a practical matter (ie, receiving system will take it), but it is not what I would expect it to do.

Odd, no?

[Daniel DeLoach]

Thanks Jim!

See, I knew this, but had forgot the obvious (use %f99 for the counter)…

[Daniel DeLoach]

I have noticed this also, and it is kind of a bummer. In my previous life with another engine (left unnamed) it was possible to specify the local (ie, engine) and remote (ie, other system) ports. In this way you could specify not only what port you wanted to send out on from the engine box, but also the port data coming in had to be coming from, and not just to.

Granted this was often a meaningless distinction (or security overkill), but in our organization there were times when we had do deal with remote/external sites and this was a handy feature to have with regards to firewalls/security. Certainly perhaps an “enhancement” for a future version?  I guess maybe it would be possible to do this via a PDL (?), but that’s some extra-techy work for something that could be *easy*.

[Daniel DeLoach]

When I did just “append” (instead of “lappend”), I was back to only getting the first x number of characters back into the message – basically whatever text would be represented in the first set of braces {} in the “lappend” method.

So, get this – after all the work and tcl learning, we find an easy way in the sending system to have it do the wrapping at 68 characters before it even sends the message out. Aaaaah!

But, like I said, at least I did get to learn some tcl stuff, and now it wraps “properly” since the sending system is handling the line formatting.

[Daniel DeLoach]

Thanks everybody. I am getting pretty close.

David/James, I tried join and append (as opposed to lappend) but they didn’t seem to work. Robert, yeah I knew about the word-breaking but I needed to fix my bigger problem first which was the list/braces.

Here is what I have now. I know this is probably exremely inelegant, but through more than a few hours of trial and error this is what I have come up with:

Code:

set myIn0 [lindex $xlateInVals end]

set myIn0 [string map {~~ @@ ~ ” “} $myIn0]
set myIn0 [string map {@@ ~~} $myIn0]
set myOut “”
set myEnd [string length $myIn0]
set LoopStart 0

while {[expr $LoopStart + 68] < [expr $myEnd + 68]} {
set LoopStart [expr $LoopStart – 1]
set LoopEnd [string wordstart $myIn0 [expr $LoopStart + 67]]
lappend myOut [concat [string range $myIn0 [expr $LoopStart] [expr $LoopEnd – 1]] ~]
set LoopStart [expr $LoopEnd]
incr LoopStart
}

set myOut [string replace $myOut [expr [string length $myOut] -3] [string length $myOut] .]
set myOut [string map {"{" "" "}" ""} $myOut]

set xlateOutVals [list $myOut]

The set myOut [string map {“{” “” “}” “”} $myOut] near the end removes the braces, and the set xlateOutVals

seems to get the whole string out.

I re-worked the main part in the middle, using a while loop (instead of the for I had before). Basically I’m using an internal counter to keep my place as I move forward in the string, and I “back up” using the word start so I don’t break a word in half. One problem I did have was the word start (I believe) was causing this process to always clip off the period at the very end, so I used the

Code:

set myOut [string replace $myOut [expr [string length $myOut] -3] [string length $myOut] .]

to put it back on at the end (before the bracket removal and list output).

My last “problem”, should I choose to go that far, is that this still occasionally breaks lines at less than optimal places. I think I will add another section that looks to see if there is a “~~” in the current “line” and then resets the pointer to that spot and moves to the next “line” so that instead of:

Code:

but still prominent in  size.

ASSESSMENT: BI-RADS 5: HIGHLY
SUGGESTIVE OF MALIGNANCY

RECOMMENDATION Breast MRI of both breasts.

I would get:

Code:

but still prominent in  size.

ASSESSMENT: BI-RADS 5: HIGHLY SUGGESTIVE OF MALIGNANCY

RECOMMENDATION Breast MRI of both breasts.

It also seems to occasionally break things like:

Code:

January 10
, 2009

So I might need to figure a way around that too (maybe account for the comma or something). But that is optional, at least for now. Better the poor wrapping than have all of Radiology be down because of a report with more than 68 characters in a line (great system, that one).

Thanks for all your tips. This has been an unpleasant but educational experience!

[Daniel DeLoach]

Looks like I should probably change the end of that tcl to:

Code:

set xlateOutVals [list $myOut]

Then I get “everything”, but still those nasty braces:

Code:

OBX|1|TX|AWIDM.77056^GDT||{~~PATIENT HISTORY Patient is postmenopausal, has history of breast c ~} {ancer at age 57, has history of high-risk lesion on a previous biops ~} {y at age 56, and had first child at  age 32. No known family history ~} {of cancer. ~}

How do I get rid of that?

[Daniel DeLoach]

Well, Support was stumped too…they’ve passed this on to development. I’ll let you know if I find anything out.

Interestingly enough, from the command line “hcimcd” no longer works (for pstart/pstop, etc) but “hcicmdnt” does.

[Daniel DeLoach]

Alas, no cigar on the hcidbinit.

[Daniel DeLoach]

Thanks Sam.

I have reinitialized the db’s (before) but not in this case as they don’t appear to be having any problems. I guess I could give it a whirl but don’t think it will do anything.

[Daniel DeLoach]

See how dim I am? That works great…I think it will be what I need. I think of all the EO options enable_all was the one I hadn’t really looked at.

[Daniel DeLoach]

Thanks Russ!

Yes strange as it may seem, I actually stumbled onto the same solution. Even though that thread had been set up as multi-server for 2 years and worked fine with no problem, I found that if I changed it to server it would come right up. I kind of just guessed that this was potentially the problem area since the errors mentioned things like “idle” and so I assumed it had something to do with the protocol. Once you go in there there’s not alot to change, so I tried that and *POW* it worked.

We’re 5.5 so I guess maybe this strange bug is fixed when we go to our next version. File it under strange-but-true I guess.

Thanks for the input!

[Daniel DeLoach]

It only looks that way!

[Daniel DeLoach]

Thanks Jim,

Yes that was a consideration and I do think I may go and clamp this down a bit with some additional logic (eg, if OBX-2 =CE then CONCAT else COPY)…but since the CONCAT seems to work regardless (since OBX-5.2 is not generally valued otherwise) it seems ok for now. I do need to further test all the scenarios but I think the way the consultant originally set this up (questionable in many ways) these particular results are going through their own xlate and so are the only ones so affected.

Great point about the OBX-2 though and something to keep in mind for sure.

[Author]

Replies