grm for multiple segments

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

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

–kk

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

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

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

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

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.

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.

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

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