[John Hervatin]

Sounds like a great lead, Scott.  Thanks!

[John Hervatin]

Thank you all for your feedback.  Jim’s mention of GRM functions reminded me of what it was that I had heard that led me to ask the question in the first place.  Seeing that it would be “a huge pain”, I will probably avoid that route.

Don’t know why some took my question to mean I was having trouble with Tcl.  I’m not a pro, but that’s not why I asked.  I just see a lot of our Tcl scripts needing to access a lot of the same HL7 fields in ways that would benefit from having some pre-written modules that allow accessing specified fields and components more directly.  In other languages that I’m more familiar with, I could do something like  obsId = getHL7value(“OBX-3.1″,”2.3”, 1, 1, y)  after having developed the getHL7value function and made it availabe to any other script that wants to use it. However easy it is to get to a field component using split, lindex, etc., it’s still a lot of busy work if you have to reference a great many fields.

So, I will turn to Google and figure out how to develop and use functions in tcl.  😀

[John Hervatin]

Hey Charlie!  I met you in Dallas a couple of years ago, but I’m not that memorable.

Yes, I was talking about HL7.  The technique you showed is exatly how we go fish out segments and fields we need.

What I was wondering was if there is some available proc that takes an HL7 message and builds a tree structure like what becomes available to Xlates (and referenced with indexes like “1(0).0(0).PV1(0).00194(0)” etc.  But something that a tcl proc could use so it wouldn’t have to parse out with split and lindex.

Then I could traverse different branches of the tree in all different ways for the logic I need to apply.

I thought maybe whatever parses the message into the tree structure for Xlate might also be usable outside Xlate.  Something like that could be quite handy.

[John Hervatin]

I have seen receiving systems that don’t like the .br.  Another substitution you could make is a tilde.  Then you will have created repetitions of the OBX-5 field.  Many receivers display each repetion on a separate line, so the tilde acts like a line break.

[John Hervatin]

Thanks for all your help, Jim.

The vendor system is Oracle Identity Manager and is being installed by an outfit called Entology who has been very cooperative, though we have both been learning as we go in building this interface.  

Since most of our existing inbound tcp-ip interfaces use mlp_tcp.pdl which looks for x0b start and x1c0d termination, I asked the vendor to encapsulate their xml message with these characters, and the message handoff was then successful.  I also constructad a very simple reply in xml format that is sent back over.  It’s always a “success” message built by a reply gen tcl in the Inbound TPS., meaning simply that we took possession of the message, but not necessarily that it is sound.  That appears to be adequate for now, at least.

We have also successfully built the interface on the receiving side (Cerner Millennium) and managed to post our first couple of transactions to achieve the expected changes in the target database (woo hoo!).

One remaining issue is a snag with message flow.  It appears that OIM opens a connection and then closes it with each message.  When several messages are sent in quick succession, the first one processes through but the second get gets a “connection refused”.  I figure it’s because the Cloverlef thread also terminates when the client goes away, and has not quite released the socket by the time the second message tries to open a new connection on that port.  The sender evidently jost stops, without retrying.

Entology says they can’t just avoid closing the connection, as each new message will open a new one.  They are on Linux OS running a jBOSS application server (whatever that is).  

Anyone have any advice on how to direct this vendor?  Would I be correct in asking them to configure their interface to either build a delay between their messages or to have it retry repeatedly if a connection is refused?  If so, what is a typical configuration?  Continue trying for what length of time and at what kind of intervals?

I mentioned that we encapsulated the XML messages with the MLP start and termination codes.  On a philosophical level, though, isn’t an XML message self-decribing.  Would it not be sufficient for the Cloverleaf driver to just look for the beginning and ending root element tags to determine the start and end of message (but the tags need to remain part of the message.  Wouldn’t this suggest a general-purpose PDL that recognizes xml messages generically?  Does such an animal exist already and not need to be re-invented?

And, as for ACKing or NAKing the message, there is a practical limit to the amount of validation that the inbound TPS tcl script can do to decide if the message is sound or not.  In the Xlate process, there is built-in functionality in Cloverleaf that validates the incoming XML message against the referenced XML Schema.  So, we could be accepting and ACKing a message in inbound TPS that will later be rejected by the Xlate.  Is there a way to draw upon this XML validation in order to ACK or NAK the incoming message?

[John Hervatin]

Thank you Jim!

We’ll follow that lead.  We had been considering having the vendor encapsulate the message with the mlp characters, but your suggestion seems more sensible.

Our next question would be what is typical as far as sending an ACK/NAK back to the sender?  What exactly needs to be sent back and how is this accomplished?

— John

[John Hervatin]

Thank you, John.  At first I thought you made a typo with your “x0a” because the testing tool displayed that character as “0xa”.  When I changed my VRL with that assumption, there was no change.  But when I tried “x0a” as the Termination character in the Global Properties, it resolved my problem.

The HRL test now gives:

Please Wait ……

Command Issued: hcihrltest -a  -d 1 -f eof ABr.hrl /hci/qdx5.5/integrator/editest/data/AB.csv

Command output:

MESSAGE 1

Field Number:          1

Field Name:             AB

— Begin VRL Segment AB(0) —  

Length of Repeat Field:         7

Repeat Field Offset from Field: 0

Type: ch >10<   A: ch >1<   B: ch >2< —- End VRL Segment AB(0) —-   — Begin VRL Segment AB(1) —   Length of Repeat Field:         7 Repeat Field Offset from Field: 7 Type: ch >10<   A: ch >4<   B: ch >8<

and the XLT test gives:

Please Wait ……

Command Issued: hcixlttest -d 1 -f eof AB_to_1234.xlt /hci/qdx5.5/integrator/editest/data/AB.csv

Command output:

MESSAGE 1

A1: ch >1< A2: ch >4< B1: ch >2< B2: ch >8<

Thanks for your help!

[John Hervatin]

Thank you for your replies so far.

Jim:  I believe my Xlate already does what you asked me to do.  It performs the following copies:

  AB(0).A –> A1

  AB(1).A –> A2

  AB(0).B –> B1

  AB(1).B –> B2

So, if the input file has

   10,1,2

   10,4,8

I expect

  AB(0).A = 1

  AB(1).A = 4

  AB(0).B = 2

  AB(1).B = 8

In the HRL Test, with the “EOF Terminated” option, I get

Please Wait ……

Command Issued: hcihrltest -a  -d 1 -f eof ABnl.hrl /hci/qdx5.5/integrator/editest/data/AB.csv

Command output:

MESSAGE 1

Field Number:          1

Field Name:             AB

— Begin VRL Segment AB —  

Length of Repeat Field:         16

Repeat Field Offset from Field: 0

Type: ch >10<   A: ch >1<   B: ch >2<0xa>10< —- End VRL Segment AB —-  

So, Cloverleaf doesn’t know that the 0xa following the 2 terminates that field.

Now, is 0xa the new line character??  I tried configuring the HRL with Global Properties Termination = n, but with the same HRL test output.

What exactly does Cloverleaf see when reading this file?  How could one find out?

I suspect that the file consists of this string:

   10,1.2<0xa>10,4,8<0xa>

Or is 0xa the value of r ?

Max, I intend to use the Fileset:Local / single configuration, but that does not come into play in the XLT test

[Author]

Replies