{nule.org}

I had a bit more conversation with interested parties on the proposed segment group updates for the light HL7 lib, and I’ve thought about it quite a lot. It turns out there is already a standard way of describe message structures, specifically with respect to segment groups, and it would be dumb to come up with something else. Therefore the light HL7 lib will attempt to match the v2 specification as best it can.

Even with that settled, there’s still the question of how do you programmatically address a segment group? One way is to specify fully that segment group description when you request it from what’s going to be called the Hl7StructuredRecord class. So if you have a record, perhaps too simply defined as something like this:


MSH EVN PID { OBR [ { NTE } ] { OBX [ { NTE } ] } }


You might be able to define a group for your convenience called, let’s say “row” as


{ OBX [ { NTE } ] }


and from there another group called “test” as


{ OBR [ { NTE } ] "row" }


Where, I hope it’s clear, the “row” portion is the group you defined before. Note that the optional repeating NTEs in both would also be groups as well, and could be named maybe “row notes” and “test notes”.

What I envision is a call to our structured record as follows:


structuredHl7.getGroup("test", 1).getGroup("row", 1).getSegment("OBX").getField(...)


Similarly, if you were programmatically defining the structure, you’d be able to do the same thing, in the following format:


structuredHl7.getGroup("{ OBR [ { NTE } ] { OBX [ { NTE } ] } }", 1).getGroup("{ OBX [ { NTE } ] }", 1).getSegment("OBX").getField(...)


Confusing now? Probably. But I saw it as critically important that we have a number of ways to address messages, if for no other reason than to make it fairly easy to create code that uses these structured messages.

So what do these look like to create. That’s a good question, as there isn’t much code written yet. I do have an idea, however, and I think it will make that part of the project easier than actually calling the groups. I think I’m saving that for the next post, however, as I’ve gone on too long.

Lastly, I am working on the HL7 Comm software as well. The configuration interface sucks badly, and I know it. I want to add more options to the HL7 MLLP handlers as well, specifically I’d like to let you specify what to do on NACKs, attempts to resend, etc., and possibly craft in an error handling facility.

I will say that it’s so nice being (back) in the new house. I feel so much more motivated to do stuff like this that, though enjoyable, is still mentally taxing. It’s fun for me to work on, and doubly so when you write me to tell me you use it (even when you also tell me it’s broken!).