grm for multiple segments

[Roman Partigula]

Hi everybody

I want to use grm object but I don’t know how to do it for

multiple segments though. For example if I want to get a patient

name my code will be:

keylget args MSGID mh

set gh [grmcreate -msg $mh hl7 $ver $variant type ]

set dh [grmfetch $gh 0(0).PID(0).00108 ]

set patName [ datget $dh VALUE]

But what should I do if it is a multiple segment like OBX for example?

set dh [grmfetch $gh 0(0).OBX(i).00573 ]

I guess I would have to do an iteration by but I don’t know how many OBX segments there

Please advice

Thanks

Topic

[Jim Kosloskey]

Roman,

I just had a similar challenge and this is how I approached it:

Luckily I had a field in the segment I was interested in that would always be populated if the segment existed. So I simply checked to see if that field was nul. If it was null I knew I had exhausted the iterations. I did my iteration using a while. The while was dependent on a switch which I set inside the while when I detected the above described null condition.

I am not sure what you can do if there is not a field in the segment in question which is always populated. I think most times there is always a field you can rely on. One way would be to check every field to see if they are all null (a bit of ‘brute force’).

There is a grmpathinfo command which is poorly documented in the Reference Guide. There are indications it requires a grmId (makes sense) and a segId. I am not sure what the segId is but it would be nice if it were an address path up to the segment and grmpathinfo indicated if the segment occurred or not. That way you could simply execute grmpathinfor with your address path to the segment with repetition in place inside the iteration and if the segment were not found, you exhausted the iteration set.

You might experiment with the grmpathinfo and see if you can figure out how it works.

If you decide to see what the grmpathinfo command could do for you and you would like some assistance, email me directly.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Kevin Kinnell]

Couldn’t you just msgget the message and count the OBX’s to find out?

–kk

[Jim Kosloskey]

Sure, but the challenge was how to solve the problem in grm.

In my case, grm was already in use so I just needed to add the modification.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Kevin Kinnell]

This kind of makes me wonder how an Iterate in an xlate knows…

[Charlie Bursell]

The obvious question I would ask would be “Why GRM?”  This problem is so easily solved in TCl using splits/joins.  Assumong you have Tcl 8.4, use the lsearch command to iterate through all of the segments.

I don’t use GRM a lot with HL7 but I suppose you could do something like:

set iter 0

while {![catch {set dh [grmfetch $gh 0(0).OBX($iter).00573 ]}] } {

               incr iter    

               Your code here

}

This assumes an iterating segment.  If the group iterates adjust as required

[Roman Partigula]

Kevin Kinnell wrote:

Couldn’t you just msgget the message and count the OBX’s to find out?

–kk

I can. But what makes these grm so usefull if you whant

to change a field value on the fly

Using msgget you would have to split message, make changes

to a field, stick it back and join message

using grm you can do it a couple steps

[Roman Partigula]

I just tried it

it doesn’t create an exception though

creates dh but no exception

Charlie Bursell wrote:

The obvious question I would ask would be “Why GRM?”

[Charlie Bursell]

Thet is one of the main reasons I would not use GRM!

The only other method I can think of would be to key on some field taht I know would have to be there.

set iter -1

while {1} {

  incr iter

  set dh [grmfetch $gh 0(0).OBX($iter).#1 ]

  if {[lempty [datget [lindex $dh 0] VALUE]] {break}

 

   YOUR CODE HERE

}

The above assumes OBX.1.1 would always be populated if the segment were present.  Choose whatever field.

You never did say why you insist on doing this with GRM

[Kevin Kinnell]

Actually, I meant that you could find out the number of segments by doing a

msgget, splitting the segments and counting them in whatever way makes

sense (total, groups, etc.)  Then use grm, if you want.

[Roman Partigula]

for changing values on the fly it would have sence I think

You should not  to split,change value, put the field back,join the message.

especially with complex fields

you would just use grmstore one time

 

Charlie Bursell wrote:

Thet is one of the main reasons I would not use GRM!

The only other method I can think of would be to key on some field taht I know would have to be there.

set iter -1

while {1} {

[Roman Partigula]

yes,

this is probably would be the way to go

Kevin Kinnell wrote:

Actually, I meant that you could find out the number of segments by doing a

msgget, splitting the segments and counting them in whatever way makes

sense (total, groups, etc.)

[Kevin Kinnell]

Um, well — it’s an awfully inefficient way to go, of course.  It’s easy for you,

but it eats a LOT of time in the engine.  Charlie can speak for himself, but

I think that’s what he was getting at.

If you do what I said, you’ll have almost all of the overhead of just splitting

the message and putting it back together PLUS all of the overhead of using

GRM–if you are handling a lot of messages that will be pretty significant.

[Jim Kosloskey]

Roman,

I tested the catch as Charlie described and it functions for me. Recheck your usage.

I don’t want to start any ‘religious battles’ but we use one filter proc for virtually all of our filtering. The one proc works with virtually every supported Cloverleaf(R) message type.

I first coded that proc 13 years ago and it has been modified once. The proc has sufficient flexibility in its construct that it has met at least two organizations needs well for these 13 years and still going strong. I just this past year used it for X12 messages with no change to the proc whatsoever.

It is GRM that allowed us to do this.

At the location I was at before and at this location, we did a measurement to quantify the relative efficiency. The difference was small enough that it was decided the overhead cost was worth it in trade for not having to write a new access/filter proc every time a different filter requirement came along. Moreover, an Integration Engineer without Tcl knowledge (like Level 1) can immediately begin filtering messages with only the documentation of the arguments for the proc at their side. IMHO the only way to decide if GRM is for you is to measure its impact on your system and weigh that against how you want your environment to function.

The beauty and power of Cloverleaf(R) is you are not locked into one way of doing things. You get to decide what is best for you.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Roman Partigula]

yes

this code works

thanks

the only think to know which field always will be populated 🙂

Charlie Bursell wrote:

Thet is one of the main reasons I would not use GRM!

The only other method I can think of would be to key on some field taht I know would have to be there.

set iter -1

while {1} {

[Jim Kosloskey]

Roman,

Since you are asking the question regarding knowing which field might always be populated, I am guessing you do not have detailed integration specifications.

So, you need to query the sending system (vendor, whatever) to determine if there is one field which will always exist if a segment exists. If the segment in question has a required field, that is SUPPOSED to always be populated, but …

I played around a little with the grmpathinfo command which is very poorly documented and could not get it to return anything but a zero (0) no matter what I tried.

If someone from Healthvision can shed some light on what grmpathinfo is supposed to do and how it is to be used, that might be helpful.

Thanks,

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Author]

Replies