Problem with misplaced NTE segment
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
Problem with misplaced NTE segment
by Johnny2R
::
Rate this Message:
I've run into a strange problem with an NTE segment in an HL7 message which I think is malformed (but which I still have to be able to deal with). The messages I'm receiving have an NTE segment after the PD1 segment, whereas I think it should be after the MSH segment. HAPI chokes on it somewhat, in that it knows it's there but doesn't deal with it right. In the code below, nteRepCount is correctly set to 1, and ormMsg.getNTE(i) returns a non-null NTE. But all the fields of the NTE are null. If I reformat the message so that the NTE segment is where it should be, this gives me the data I'm expecting.
int nteRepCount = ormMsg.getNTEReps(); for (int i = 0; i <= nteRepCount; i++) { NTE nte = ormMsg.getNTE(i); String value = nte.getComment(0).toString(); } Now, I'm wondering how I can actually grab the real NTE segment even if it is mislocated. Unfortunately I'm working with a big established hospital system which isn't about to be changed merely because it's sending malformed messages - it's something my code has to cope with. I was hoping I could use the lower-level Terser to get the values but that still gives me a non-null but empty NTE. This is using HAPI 0.6 (I upgraded from 0.5.1). |
|
|
Re: Problem with misplaced NTE segment
by James Agnew
::
Rate this Message:
Hi Johnny,
You are probably running up against one of the more unusual features of the parser. If it detects a segment it doesn't expect, it will move to the end of the current group, and add a non standard segment there. Unfortunately, this often has the by-product of causing it to skip past the natural location of segments which come later in the message, so they end up being added as nonstandard segments in a child group. The end result is that the message will re-encode (seemingly) correctly, but if you actually examine the structures in the message, pretty much everything in the message after the unexpected segment is in a wacky place. This is something I have a fix for in the next version of HAPI (it's part of a huge cleanup of how the PipeParser works I'm doing in order to improve performance and allow the parser to deal with unexpected situations more gracefully), but I don't expect to be able to release this for a while yet. Incidentally, you are also getting hit by another bug which the cleanup addresses, which is that messages are currently given a single empty repetition of all optional repeating segments, even if none were in the original message being parsed. ormMsg.getNTE(i) returns null, but that's not actually where the content in the NTE segment in your message ended up. The easiest way to figure out where the contents went (other than waiting for the next version of HAPI :) ) is to save the contents of your message in a text file, and use the treepanel to parse and display the message tree: ca.uhn.hl7v2.view.TreePanel(new String[] { "message_file.hl7" } ); Browse around and you should be able to find the contents you are looking for and which repetitions of which groups they are in. Cheers, James On Tue, Aug 4, 2009 at 9:26 AM, Johnny2R <grails@...> wrote:
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Hl7api-devel mailing list Hl7api-devel@... https://lists.sourceforge.net/lists/listinfo/hl7api-devel |
|
|
Re: Problem with misplaced NTE segment
by Johnny2R
::
Rate this Message:
James,
Thanks for that, it's really useful to know how it works. I established in the end that the segment was in fact in the right place, I had just been misinformed about it in the spec (it was part of the patient group, not an order level NTE), so it's probably just as well I didn't find a way to successfully relocate it! (Apologies for not mentioning this on the list - I got a couple of off-list messages and this was in a reply to one of them, and I forgot it was not public). But in fact one of the things which was frustrating me was that I could ever so easily have retrieved the value by simple Java string parsing (regex, etc), if I had had access to the raw text of the message. But I have not found a means in HAPI to actually get the raw message text. You suggest I save the contents of my message in a text file, but how do I do that? I'm using SimpleServer, and the message is handed off to my handler application ready-parsed. |
|
|
Re: Problem with misplaced NTE segment
by James Agnew
::
Rate this Message:
Good to hear!
If you want access to the raw string for some kind of pre-processing as you mention (like reordering an out of place segment for instance), one easy way to do this is to subclass PipeParser and override the parse(String) method. You can then modify the string that is passed in and then pass your modified string to the super.parse(String) implementation. You can then instantiate your parser subclass and pass it to the connectionhub, server, or whatever you are using to receive messages. Make sense? Cheers, James On Fri, Aug 7, 2009 at 5:30 AM, Johnny2R <grails@...> wrote:
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Hl7api-devel mailing list Hl7api-devel@... https://lists.sourceforge.net/lists/listinfo/hl7api-devel |
|
|
Re: Problem with misplaced NTE segment
by Johnny2R
::
Rate this Message:
Yes, makes good sense, thanks. What would be handiest, though, is if the raw message text could be passed to the registered handling application. How could that happen?
|
|
|
Re: Problem with misplaced NTE segment
by James Agnew
::
Rate this Message:
Hmm, I can see two ways of doing this.
The obvious one is to have the receiving application reencode the message: String messageText = new PipeParser().encode(message); The less obvious way, which I've used in the past, is to just use MinLlpWriter and MinLlpReader directly. This method gives you loads of control, since no parsing occurs at all, but you need to create your own socket and then pass it's input and output streams to the respective reader and writer. This method is a fairly big change and a bit more work, but gives you great flexibility. I've used it in the past for situations where I was crucially concerned with performance. Thinking about this, it would probably be quite nice to allow a message object to store its original text as a convenience. Maybe a getter and setter could be added for getOriginalText, and the parser could add that in there when available. I guess the documentation would need to be quite explicit, since there is a chance people could call the setters on the message and then expect the original text to change (i.e. confusing it with a re-encode method). Thoughts anyone? James On Fri, Aug 7, 2009 at 10:18 AM, Johnny2R <grails@...> wrote:
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Hl7api-devel mailing list Hl7api-devel@... https://lists.sourceforge.net/lists/listinfo/hl7api-devel |
|
|
Re: Problem with misplaced NTE segment
by Johnny2R
::
Rate this Message:
Ah, your 'most obvious' method should have been obvious to me, too. I'll give it a go. But yes, I think having access to the raw original text of the message would be a useful convenience.
|
| Free embeddable forum powered by Nabble | Forum Help |
