Re: [HAPI-devel] Placement of ZLR segment
Hi Bryan-Attached is a test file I've been using for in my unit tests for the
transformation. The file was generated using a conformance profile generated
by VA's Message Workbench and a sample message generated by NIST's Message
Maker. It conforms to the layout described in my original message. I've also
done a rough comparison of the test file against the live data we're receiving
from the laboratory in question and the two match. If you run the message
through the parser I think you'll see the behavior I'm describing. If you (or
your team) have time, maybe you can take a look at the output and comment on
it?Thanks,Jim> Date: Thu, 22 Mar 2007 17:13:10 -0400> From: [EMAIL PROTECTED]>
To: [EMAIL PROTECTED]> Subject: Re: [HAPI-devel] Placement of ZLR segment> CC:
hl7api-devel@lists.sourceforge.net> > Hi Jim,> > No, you have to customize the
message class to put a Z-segment in the> middle of a group. Actually looking at
your output structure, the ZLR> should appear after the OBX group ... is that
not happening?> > Bryan> > On 3/13/07, Jim Krygowski <[EMAIL PROTECTED]>
wrote:> >> > Hey All-> >> > I'm in the middle of coding a 2.3.z (as defined by
CDC's ELR guide) to 2.3.1> > message transformer and have run into something of
a problem. The ORU^R01> > message I'm transforming looks like this:> >> > MSH>
> PID> > {> > OBR> > ZLR> > {> > OBX> > { [ NTE ] }> > }> > }> >> >
but what I'm getting out of HAPI once I parse the message looks like this:> >>
> MSH> > PID> > {> > OBR> > {> > ZLR> > OBX> > { [ NTE ] }> > }>
> }> >> > So a message like:> > MSH...> > PID...> > OBR...> > ZLR...> >
OBX|1...> >> > ends up with two observations, one containing the ZLR and a
blank OBX and> > the other for the OBX:> >> >
response(0).order_observation(0).observation(0) contains> > ZLR and an empty
OBX> > response(0).order_obsercation(0).observation(1) contains> > OBX 1> >> >
I suppose there's no way for HAPI to know a priori that the ZLR in this> >
message should be associated with the order_observation group and not the> >
observation group so is it possible to direct the parser to associate it in> >
that fashion? The issue is clearly something I can code around but it would> >
be cleaner if I didn't have to.> >> > Thanks,> >> > Jim> >> >> >> >> >> >> >> >
> > Get news, entertainment and everything you
care about at Live.com. Check it> > out!> >
-> >
Take Surveys. Earn Cash. Influence the Future of IT> > Join SourceForge.net's
Techsay panel and you'll get the chance to share your> > opinions on IT &
business topics through brief surveys-and earn cash> >
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> >
___> > Hl7api-devel mailing list> >
Hl7api-devel@lists.sourceforge.net> >
https://lists.sourceforge.net/lists/listinfo/hl7api-devel> >> >
_
Live Search Maps – find all the local information you need, right when you need
it.
http://maps.live.com/?icid=wlmtag2&FOR M=MGAC01
sample2.3.z.txt
Description: application/binary
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Hl7api-devel mailing list
Hl7api-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
Re: [HAPI-devel] Preserving spaces in XML text nodes
I have been emailing Bryan and James off-list, and Bryan found the issue. I
am posting the solution here for anyone else that may encounter it in the
future.
It has nothing to do with XML at all... leading spaces are being stripped in
the parser, before XML-encoding begins. And it isn't really a problem... I
was unaware that the HL7 spec mandates stripping leading spaces. The parser
is just doing what it's supposed to do. Unfortunately, it's not what I need
it to do.
The solution, as Bryan wrote to me:
> The HL7 spec has a rule against leading whitespaces, and HAPI enforces
> this by stripping them, but this is
> configurable. Here are the relevant lines in
> ca.uhn;hl7v2.validation.impl.DefaultValidation:
>
> Rule trim = new TrimLeadingWhitespace();
> getPrimitiveRuleBindings().add(new RuleBinding("*", "FT", trim));
> getPrimitiveRuleBindings().add(new RuleBinding("*", "ST", trim));
> getPrimitiveRuleBindings().
> add(new RuleBinding("*", "TX", trim));
>
> You could try changing these rules by providing your own ValidationContext
> to the Parser.
So what I did was subclass DefaultValidation and added the following:
super();
Iterator iter = getPrimitiveRuleBindings().listIterator();
for (int i = 0, n = getPrimitiveRuleBindings().size(); i < n; i++)
{
Object o = iter.next();
if (o instanceof RuleBinding)
{
RuleBinding binding = (RuleBinding) o;
if (binding.getActive()
&& binding.appliesToVersion("*")
&& binding.appliesToScope("TX"))
{
iter.remove();
if (log.isDebugEnabled())
log.debug("Rule removed: " +
binding.getVersion() + " " +
binding.getScope() + " " +
binding.getRule().getClass().getName() + "
" +
binding.getRule().getDescription());
}
}
}
This removes the leading-whitespace stripping for all TX fields while
leaving all the other default validations intact.
Greg Groves
Florida Hospital
--
View this message in context:
http://www.nabble.com/Preserving-spaces-in-XML-text-nodes-tf3415885.html#a9718209
Sent from the hl7api-devel mailing list archive at Nabble.com.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Hl7api-devel mailing list
Hl7api-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
Re: [HAPI-devel] Placement of ZLR segment
Jim,
You may want to just go with Bryan when he says that "you have to customize
the message class to put a Z-segment in the middle of a group." HAPI
obviously has some default behavior for deciding where an unknown Z-segment
belongs when it encounters it in a message in the middle of parsing. It
clearly isn't where we like to think it belongs. When I say "we" I mean
those of us in public health using the CDC 1977 standard for Electronic Lab
Reporting based on the HL7 v2.3 ORU_R01 message (what we call "2.3.z"
because of the ZLR segment).
I have code for this (ZLR segment class,
ca.uhn.hl7v2.model.v23.group.ORU_R01_ORDER_OBSERVATION modified to add the
ZLR, code that uses these two classes), which I can send you if you like.
I have already made it available to James Agnew for posting on the HAPI
website.
Charles Fisher
Division of Epidemiology
New York State Dept. of Health
518-474-2735
Jim Krygowski
<[EMAIL PROTECTED]
com> To
Sent by: Bryan Tripp <[EMAIL PROTECTED]>
hl7api-devel-boun cc
[EMAIL PROTECTED] hapi-list
orge.net
Subject
03/28/2007 10:37 Re: [HAPI-devel] Placement of ZLR
AMsegment
Hi Bryan-
Attached is a test file I've been using for in my unit tests for the
transformation. The file was generated using a conformance profile
generated by VA's Message Workbench and a sample message generated by
NIST's Message Maker. It conforms to the layout described in my original
message. I've also done a rough comparison of the test file against the
live data we're receiving from the laboratory in question and the two
match. If you run the message through the parser I think you'll see the
behavior I'm describing. If you (or your team) have time, maybe you can
take a look at the output and comment on it?
Thanks,
Jim
> Date: Thu, 22 Mar 2007 17:13:10 -0400
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: [HAPI-devel] Placement of ZLR segment
> CC: hl7api-devel@lists.sourceforge.net
>
> Hi Jim,
>
> No, you have to customize the message class to put a Z-segment in the
> middle of a group. Actually looking at your output structure, the ZLR
> should appear after the OBX group ... is that not happening?
>
> Bryan
>
> On 3/13/07, Jim Krygowski <[EMAIL PROTECTED]> wrote:
> >
> > Hey All-
> >
> > I'm in the middle of coding a 2.3.z (as defined by CDC's ELR guide) to
2.3.1
> > message transformer and have run into something of a problem. The
ORU^R01
> > message I'm transforming looks like this:
> >
> > MSH
> > PID
> > {
> > OBR
> > ZLR
> > {
> > OBX
> > { [ NTE ] }
> > }
> > }
> >
> > but what I'm getting out of HAPI once I parse the message looks like
this:
> >
> > MSH
> > PID
> > {
> > OBR
> > {
> > ZLR
> > OBX
> > { [ NTE ] }
> > }
> > }
> >
> > So a message like:
> > MSH...
> > PID...
> > OBR...
> > ZLR...
> > OBX|1...
> >
> > ends up with two observations, one containing the ZLR and a blank OBX
and
> > the other for the OBX:
> >
> > response(0).order_observation(0).observation(0) contains
> > ZLR and an empty OBX
> > response(0).order_obsercation(0).observation(1) contains
> > OBX 1
> >
> > I suppose there's no way for HAPI to know a priori that the ZLR in this
> > message should be associated with the order_observation group and not
the
> > observation group so is it possible to direct the parser to associate
it in
> > that fashion? The issue is clearly something I can code around but it
would
> > be cleaner if I didn't have to.
> >
> > Thanks,
> >
> > Jim
> >
> >
> >
> >
> >
> >
> >
> >
> > Get news, entertainment and everything you care about at Live.com.
Check it
> > out!
> >
-
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
your
> > opinions on IT & business topics through brief surveys-and earn cash
> >
http://www.techsay.
