grmcreate doesn’t work

[Dennis Dunn]

Hi,

I’m trying to extract some field values from a grm object that I’ve created from a message object.  I am creating the message object using msgcreate and msgread to get the message from a file.  The file is len10 encoded and is well-formed; that is when I open the file in the Cloverleaf IDE testing tool the message is parsed correctly and I can see the paths to each of the fields.  If I do a msgget on the message that is created, I see all of the raw data, no suprises yet.

I then create a grm object from the message object using grmcreate with the proper arguments.  The problem I am having is that everytime I try to access a field from the PID segment using grmfetch, an empty datum is returned.  Accessing fields from the MSH segment works as expected.  

Creating a new message with grmencode and then using msgget on the new message shows that the new message is not the same as the original message.  The grmencoded message has the MSH, EVN and PV1 segments but the EVN and PV1 segments have been corrupted.  The rest of the segments are gone.  I confirmed my suspicion that the two messages are in fact different by using string length on the output of msgget and the difference is an order of magnitude.

Here is the output of my hcitcl session that illustrates the problems,  I’ve some PHI but you’ll get the drift.

hcitcl>package require libInsCheck

1.0

hcitcl>::libInsCheck::createFromFile one_adt.len

message7 grm1

hcitcl>msgget message7

MSH|^~&|xxxx|xxxx|||200704011349||ADT^A04|856F5BB9-7895-4FA2-AC52-DA5E3BA5ED16|P|2.4||1

EVN|A04|200704011349||CI|xxxx_xxxx|200704011341|226

PID|1|

PV1|1|

GT1|1|

IN1|1|

hcitcl>grmencode grm1

message8

hcitcl>msgget message8

MSH|^~&|SOARF|BMH1|||200704011349||ADT^A04|856F5BB9-7895-4FA2-A|P|2.4||1

EVN|A0|20||CI|B0D0_CSOLLER1|200704011341|226

PV1|A04

hcitcl>

Here is the code from my package that creates the message and grm objects from a len10 encoded file.

# Create a message/grm pair from a len10 encoded file.

proc ::libInsCheck::createFromFile {filename} {

   # read the file

   set msg [msgcreate]

   set file [open $filename r]

   msgread len10 $msg $file

   close $file

   

   # get the version and type

   set data [msgget $msg]

   set delim [string index $data 3]

   set fields [split $data $delim]

   set ver [lindex $fields 11]

   set type [lindex $fields 8]

   regsub -all {W} $type {_} type

   

   # create the grm

   set grm [grmcreate -msg $msg hl7 $ver {} $type]

   

   return

}

Do yo have any clues as to what’s going on?  

Thanks for reading this lengthy post and thanks for your help.

–dennis

Topic

[Jim Kosloskey]

Dennis,

It looks like you will always get the default message definitions from HCIROOT as you are not valuing the variant name in the grmcreate.

Also, if memory serves, the syntax for grmcreate is different for frl (and perhaps vrl and hrl) than for hl7, x12, etc. If that is the case, then you might need to determine what kind of message it is (the invoker might need to get that info from an argument).

Also I know you have provided a subset of the entire proc, but I will assume you have a grmfetch somewhere to get the actual fields.

I am not sure if I helped.

Jim Kosloskey

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

[Dennis Dunn]

Hi Jim,

>It looks like you will always get the default message definitions from

That is correct, we don’t have a variant defined for these messages.

>the syntax for grmcreate is different for frl (and perhaps vrl and hrl) >than for hl7, x12, etc.

Yes, I am only dealing with HL7 messages so I don’t need to worry about the others.

>Also I know you have provided a subset of the entire proc, but I will >assume you have a grmfetch somewhere to get the actual fields.

Yes, I was getting null datums back which led me to the whole troubleshooting process.  It is as if the message is not being parsed correctly by grmcreate.  The thing that really throws me is that when I open the file using the testing tool in the IDE, the message is parsed just fine.  The proc was really so I didn’t have to type the same thing over and over and to show you the steps I went through to create my grm object.

Thanks for your help.

— dennis

[Charlie Bursell]

We could make this work but question would be *WHY*?

HL7 is much better dealth with simply using Tcl splits, joins, etc.

[Dennis Dunn]

Hello Charlie,

>>We could make this work but question would be *WHY*?

I have some procedures in my package that perform database lookups based on values passed to the procedure.  If I use this package from within an xltp code fragment, I can pass in the parameters to my procedures via xlateInVals and get results to the translation via xlateOutVals.  To use the package from tps code, I was going to get the nessasary values from the message handle that is passed to the tps procedure in the args keyed list.  

My reading of the Cloverleaf Integration Services Reference Guide leads me to believe that the way to access the data of a message is through a grm object.  When I create a grm object from a message handle, the message data will be parsed and I can then access the field data using paths.  This does not seem to be happening.

I can think of a few reasons that the behaviour of the API and my expectations don’t mesh.

* I might not understand what the API is supposed to be doing.  This is very likely since I’ve only been using Cloverleaf for a few months.

* My original message could be malformed and grmcreate does it’s best to parse the message but ultimatly chokes.  This seems very unlikely since I can open the file that contains the message in the Cloverleaf HL7 testing tool and the testing tool parses the message just fine.  Perhaps the parser used in the testing tool is more lenient than the parser used by grmcreate and can handle malformed messages.

* Perhaps grmcreate has a bug that prevents it from parsing my message.  This seems very unlikely since Cloverleaf is a mature product and is well respected by the programming staff at the hospitals that I work with.

So, it looks like my problem is simply a lack of understanding which is why I post here.

>>HL7 is much better dealth with simply using Tcl splits, joins, etc.

I suppose I could write a little package that splits an HL7 message and gives me mechanisms to access the segments, fields and subcomponents but why bother?  Cloverleaf has already provided a really cool tcl extension that  does all of that as well as an addressing mechanism that takes into account things like multiple segments of the same type and repeating fields. However, since the ultimate goal is to get things done, I’ll look into this further.

Thanks for your help.

–dennis

[Charlie Bursell]

Cloverleaf *DOES* provide an API to parse HL7 messages.  It is the same API used inside the Xlate engine.  The problem is the amount of overhead.  There are no free lunches.  Just as there are many APIs avaialable to do many tasks it does not mean it is always the most ergonomic method to do it.

But you really have me confused now.  You mention using parameters from xlateInVals, etc and at the same time talk about using grmcreate.  You cannot use GRM inside Xlate.

As for any differences between the testing tool and engine when using GRM there are none.  It is the same API either way.

I certainly am not a Salesman and am not trying to sell you anything but as you said you have limited Cloverleaf experience, you may want to get some Implementation assistance here.

Just because it works does not make it necessarily correct.  You have to look for the most ergonomic method in terms of throughput unless throughput is not a prolem.  You must also look for the most maintainable method.  Remember that at least 60% to 70% of the life cycle cost is in the maintenance.  And, IMHO, simple Tcl splits and joins are much more maintainable than GRM

As those that know me will tell you, I am not shy about offering my opinion.  But is it is just *MY* opinion.  So, if you feel comfortable with what you are doing, please do not let my ramblings sway you.  🙄

[Dennis Dunn]

Hello Charlie,

>>You mention using parameters from xlateInVals, etc and at the

>>same time talk about using grmcreate.  

My library does not know about either xlateInVals or grmcreate.  It simply does the lookup based on the values of the parameters passed to the procedure.  In an xltp fragment, these values come from xlateInVals.  In a tps proc, these values would come from the message.

>>You cannot use GRM inside Xlate.

But I can use grm from the tcl shell, right?  According to the documentation I just need to make sure that I’ve done a setroot and that I call setHciDirs.

>>As for any differences between the testing tool and engine

>>when using GRM there are none.

That’s good to know.  So if the testing tool parses the message without any problems then grm should also be able to parse the message.

>>You must also look for the most maintainable method.

You make a very good point here, this is why I wanted to move my db lookup code to a package that I could use in different contexts.  

I probably shouldn’t have even mentioned db lookups or xlateInVals or any of that in my original post since they really aren’t important.  I might have been clearer if I had simply talked about my problem with grmcreate not parsing message data correctly when used from the tcl shell.

Thanks for your comments.

–dennis

[Michael Hertel]

Quote:

>>HL7 is much better dealth with simply using Tcl splits, joins, etc.

I suppose I could write a little package that splits an HL7 message and gives me mechanisms to access the segments, fields and subcomponents but why bother?

[Dennis Dunn]

Hi Michael,

Thanks for the code! That seems somehow simpler than dealing with path specs and grm objects.

–dennis

[Michael Hertel]

You’re welcome.

Feel free to email me if you run into syntax issues.

-mh

[Gaurav Mittal]

Hi Michael,

We are working Cloverleaf 5.8 version. Currently we have to xlate an xml to hl7 . while doing this we getting follwoing error:-

assertion ‘(grml)->grml_count == 1’ failedat Encode cpp1761

Can you help me in rectifying this error.

Regards,

Gaurav Mittal

[Michael Hertel]

Sorry Gaurav,

I am not experienced with 5.8 xlates.

We do everything with tcl here, no xlates.

Perhaps Jim K could help you?

[Author]

Replies