{nule.org}

I was out of town for the better part of the week, but I’m getting back into the swing of things. The HL7 Comm upgrade is nearing completion, and I’ll dive into the posts on the BBS and emails you’ve sent me and will get caught up again.

I’ll have more details later, but I have some improvements to some existing communication clients, some brand new communication clients with Super Cool ™ features, compatibility with Java 1.4, and hopefully a whole new configuration interface for the HL7 Comm.

Work on the HL7 lib hasn’t been stalled, I’m still giving that a good hard think on how to extend it. I’m perhaps a bit of a weird programmer in that I think, way, way more than I type. Something like this that is complex and that I must get right the first time, I may think for months before I code in any enhancements.

So I’ll post more detailed notes later, but it’s coming.

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!).

There’s a new version of the light HL7 library right here. It fixes an issue that caused new empty fields to be appended to a segment if they were queried for but did not exist. Originally I didn’t think this was an issue, but I can see why people would not want it to do this.

My next goal is to enhance the library to make working with nested segments a bit easier. Right now you need to know the index of a particular segment to address it (the 12th NTE for example), but it really matters a lot more to know which segments are associated with which groups. For example that an OBX is associated with a particular OBR. To do this I need both an API that can address segment groups in a consistent and user-defined manner, but also a way to develop a lexical method of describing segment groups. For the latter I’m looking at something like () defines a group. Prefixing it with * means 0 or more, + means 1 or more {#,#} means a range. No prefix would indicate {1,1} or one and only one repetition. An example for a result style message might be +(OBR*(NTE)+(OBX*(NTE))), where we can have one or more result groups, led by an OBR segment. That OBR may have zero or more NTEs. Then each OBR has one or more OBXs, each of which may have zero or more NTEs of its own. Confusing? Probably.

Lastly, I’ve actually been asked to put a donate button on this page. I haven’t wanted to do that because I make a good salary, but I can see why users of the tools here would want to feel they contribute to its development and upkeep. I do pay several hundred dollars a year to upkeep this server, and more to maintain and backup servers and development laptops at home. It’s stuff I would have anyway, I suppose, but I guess you could measure that as a monetary impact this development has on my own income. So, if you feel so inclined, click the donate button to the right. If you wish your donation to be publicly acknowledged, make sure to tell me so in the paypal notes. Tell me what to show, including your name, organization, email and/or amount. If you don’t I won’t show anything to protect your privacy. I’ll create a page if it becomes necessary to list donors. I don’t have a non-profit organization to support this development, so don’t try to write the donation off. Whether your support comes in the form of emails to tell me that you use the software, bug reports, unit tests or whatever – I appreciate that. So you have my thanks.