getHL7Field

[Phil Jordan]

Is there a complete listing for getHL7Field, getHL7Segment, and others

that can be used?

Topic

[David Barr]

phil jordan wrote:

Is there a complete listing for getHL7Field, getHL7Segment, and others

that can be used?

These aren’t standard procs that are part of Cloverleaf.  You can look in the Tclprocs directory for a file called tclIndex that tells you where the source code file is for getHL7Field.  Browsing through that source file would help you to identify other procs that are available.

[Tom Rioux]

Phil,

We no longer use the “getHL7” commands here.

[Phil Jordan]

Thanks… That explains it.

[Charlie Bursell]

Amen Tom!   😀

[David Barr]

Without evaluating efficiency of the getHL7 functions, I think that a good argument can be made in favor of using HL7 specific parsing functions similar to those in the getHL7 library rather than rewriting an HL7 parser from scratch every time you write a TPS proc.

In my experience, using an HL7 library leads to more readable and maintainable code.  There can be a trade off between efficiency of the code and maintainability of the code.  It’s probably a good idea to have a rough idea of how efficient or inefficient you are making your code by relying on a library.  Keep in mind how many messages or fields per day will by processed by your library.  If you suspect that your library is a bottleneck for performance on your system, then either use a better library, make performance enhancements to your existing library (and post them in the TCL Library forum), or see if you can get better performance out of split, lsearch, split, lindex, etc.

At my current job, we’re using a pretty nice library, but unfortunately it is copyrighted by a consulting company, so I can’t post.

OK, now everyone can start flaming me for this unorthodox opinion. 🙂

[Jim Kosloskey]

David,

No that unorthodox.

At my pervious Cloverleaf shop and at this shop we use a fitering proc that deploys the grm functions.

I did some performance evaluation of that functionality years ago after being told it was inefficient but that was never quantified. My quantification of the grm functions convinced me and my management (both employers) the overhead was minimal compared to the value of repeatble, reusable code.

These are choices we can make because of the power that the entire Cloveleaf(R) product family makes available to us.

We each need to make the choice that best fits our needs.

For us (and me personally and professionally) our choice is to use reusable library of procs (tps, xltp, scripts, etc.) rather than copying and modifying.

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

[Tom Rioux]

While I do agree that the HL7 routines are more readable (not necessarily easier to manage), you have to remember that they are just routines.  If you have Cloverleaf or Tcl newbies coming behind you and they use the HL7 routines, they never get a true sense of how the data is retrieved.  I find that the lsearch command is so much more powerful and I can do so much more with it in fewer lines of code.  

I think I also saw someone write on here, “teach a man to fish”.   I’d rather learn the nuances of fishing rather than simply go to grocery store and buy the fish there.

When I was first taught Tcl, I lived and died by the HL7 routines.  However, now that I’m more versed in Tcl, I can’t see myself going back to it.   We do have a lot of reusable code, in just the same manner as Jim suggested.   But, as I have said before, skin that cat whatever way you feel is best for you and your shop.

[Max Drown (Infor)]

I’ve found this proc to be incredibly handy. There’s no loop in the code. I’d much rather use this proc than include the same code in every script that needs to extract HL7 fields. I did not write this script, but a huge thanks to whomever did write it.

proc hl7get {args} {

[code]proc hl7get {args} {

-- Max Drown (Infor)

[Author]

Replies