hl7api-devel — developer list

Re: [HAPI-devel] Message parsing issues when Z segments present

[Alan S. <ma...@as...>]

I had this problem, in the end I didn't need any of the information  
in the Z segments so just stripped them out prior to parsing (moving  
them to the end of the message also worked)

What I don't know is whether the spec allows non standard segments in  
the middle of the message, it seems a little unreasonable to expect  
the parser to be able to correctly identify structures that contain  
them.

Alan Shields

On 4 Jul 2006, at 20:13, Rob Redmond wrote:

> Hello all,
>
> I'm seeing some unexpected parsing results when there are Z  
> segments present in my input messages.  I am using HAPI via Mirth's  
> HL7StringToXML transformation;  it contains a call to  
> PipeParser.parse() as well as uses DefaultXMLParser
>
> The input message is:
> MSH|^~\&|PM|MSH|RIS|MSH|20060628112841||ADT^A08^ADT_A08| 
> Q27661356T23715662X4|P|2.3
> EVN|A08|20060628112803|||2875337
> PID|1||806902092|....<clip>
> ZPI|||||||||UNPR|1872802^XXXXX^XXXXXX
> ZEI|
> PV1|1|E|ER|||ER|...<clip>
> PV2|||^MINOR COMPLAINTS NOS||||N|||0|||||||||||||^^1
> ZVI|||||||||AMBULANCE USED|||L5|20060627134700
> OBX|1|CE|PHONE_REQ||N
> IN1|1|....<clip>
> IN2||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 
> (999)999-9999
> So, three Z segments:  ZPI and ZEI following the PID and ZVI  
> following the PV*'s
>
> The problem I am seeing is that the encoding produces an XML  
> message with empty PV* tags (<PV1 /> and <PV2 />), followed by an  
> ADT_A08.PR1ROL group containing the ZPI, ZEI segments as well as  
> additional, fully populated PV1 and PV2 tags.
>
> Any ideas?  Based on the debug output, I believe the issue is with  
> the message parsing, and not the XML encoding that follows.  Is it  
> possible that MessageIterator.newSegment() is incorrectly setting  
> the Parent element?  Removing the ZPI and ZEI segments produces  
> complete PV* segments in the correct position.
>
> Let me know you're interested in the full input messages, XML dump  
> or debug logs.
>
> Thanks
> Rob.
>
>
>
> <ADT_A08>
>     <MSH>
>         <MSH.1>|</MSH.1>
>         etc.  Looks okay
>     </MSH>
>     <EVN>
>         <EVN.1>A08</EVN.1>
>         etc.  Looks okay
>         </EVN>
>     <PID>
>         <PID.1>1</PID.1>
>         etc.  Looks okay
>     </PID>
>     <PD1/>
>     <NK1/>
> **  <PV1/>             *** Shouldn't be empty
> **  <PV2/>            *** Shouldn't be empty
>     <DB1/>
>     <OBX/>
>     <AL1/>
>     <DG1/>
>     <DRG/>
>     <ADT_A08.PR1ROL>
>         <PR1/>
>         <ROL/>
>         <ZPI>
>             <ZPI.9>UNPR</ZPI.9>
>             <ZPI.10>
>                 <UNKNOWN.1>1872802</UNKNOWN.1>
>                 <UNKNOWN.2>CHAN</UNKNOWN.2>
>                 <UNKNOWN.3>CHRISTOPHER</UNKNOWN.3>
>             </ZPI.10>
>         </ZPI>
>         <ZEI/>
>         <PV1>
>             <PV1.1>1</PV1.1>
> **            etc.  Complete PV1 here, but it shouldn't be in the  
> group
>         </PV1>
>         <PV2>
>             <PV2.3>
> **            etc.  Like PV1, shouldn't be here
>         </PV2>
>         <ZVI>
>             <ZVI.9>AMBULANCE USED</ZVI.9>
>             <ZVI.12>L5</ZVI.12>
>             <ZVI.13>20060627134700</ZVI.13>
>         </ZVI>
>         <OBX>
>             <OBX.1>1</OBX.1>
>             etc.  Looks okay
>         </OBX>
>     </ADT_A08.PR1ROL>
>     <GT1/>
>     <ADT_A08.IN1IN2IN3>
>         <IN1>
>             <IN1.1>1</IN1.1>
>             etc.
>         </IN1>
>         <IN2>
>             <IN2.63>
>             etc.
>         </IN2>
>     </ADT_A08.IN1IN2IN3>
>     <ACC/>
>     <UB1/>
>     <UB2/>
> </ADT_A08>
> ------
> Rob Redmond
> Software Developer
> T: 416-340-4800 ext 5914
> E: ro...@cl...
>
> clearcanvas
> 438 Richmond St. W., Suite 620
> Toronto, ON, Canada M5V 3S6
> www.clearcanvas.ca
>
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel

[HAPI-devel] Message parsing issues when Z segments present

[Rob R. <ro...@cl...>]

Hello all,
 
I'm seeing some unexpected parsing results when there are Z segments present
in my input messages.  I am using HAPI via Mirth's HL7StringToXML
transformation;  it contains a call to PipeParser.parse() as well as uses
DefaultXMLParser
 
The input message is:
MSH|^~\&|PM|MSH|RIS|MSH|20060628112841||ADT^A08^ADT_A08|Q27661356T23715662X4
|P|2.3
EVN|A08|20060628112803|||2875337
PID|1||806902092|....<clip>
ZPI|||||||||UNPR|1872802^XXXXX^XXXXXX
ZEI|
PV1|1|E|ER|||ER|...<clip>
PV2|||^MINOR COMPLAINTS NOS||||N|||0|||||||||||||^^1
ZVI|||||||||AMBULANCE USED|||L5|20060627134700
OBX|1|CE|PHONE_REQ||N
IN1|1|....<clip>
IN2|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||(999)999-9
999

So, three Z segments:  ZPI and ZEI following the PID and ZVI following the
PV*'s
 
The problem I am seeing is that the encoding produces an XML message with
empty PV* tags (<PV1 /> and <PV2 />), followed by an ADT_A08.PR1ROL group
containing the ZPI, ZEI segments as well as additional, fully populated PV1
and PV2 tags.  
 
Any ideas?  Based on the debug output, I believe the issue is with the
message parsing, and not the XML encoding that follows.  Is it possible that
MessageIterator.newSegment() is incorrectly setting the Parent element?
Removing the ZPI and ZEI segments produces complete PV* segments in the
correct position.
 
Let me know you're interested in the full input messages, XML dump or debug
logs.
 
Thanks
Rob.
 
 
 
<ADT_A08>
    <MSH>
        <MSH.1>|</MSH.1>
        etc.  Looks okay
    </MSH>
    <EVN>
        <EVN.1>A08</EVN.1>
        etc.  Looks okay
        </EVN>
    <PID>
        <PID.1>1</PID.1>
        etc.  Looks okay
    </PID>
    <PD1/>
    <NK1/>
**  <PV1/>             *** Shouldn't be empty
**  <PV2/>            *** Shouldn't be empty
    <DB1/>
    <OBX/>
    <AL1/>
    <DG1/>
    <DRG/>
    <ADT_A08.PR1ROL>
        <PR1/>
        <ROL/>
        <ZPI>
            <ZPI.9>UNPR</ZPI.9>
            <ZPI.10>
                <UNKNOWN.1>1872802</UNKNOWN.1>
                <UNKNOWN.2>CHAN</UNKNOWN.2>
                <UNKNOWN.3>CHRISTOPHER</UNKNOWN.3>
            </ZPI.10>
        </ZPI>
        <ZEI/>
        <PV1>
            <PV1.1>1</PV1.1>
**            etc.  Complete PV1 here, but it shouldn't be in the group
        </PV1>
        <PV2>
            <PV2.3>
**            etc.  Like PV1, shouldn't be here
        </PV2>
        <ZVI>
            <ZVI.9>AMBULANCE USED</ZVI.9>
            <ZVI.12>L5</ZVI.12>
            <ZVI.13>20060627134700</ZVI.13>
        </ZVI>
        <OBX>
            <OBX.1>1</OBX.1>
            etc.  Looks okay
        </OBX>
    </ADT_A08.PR1ROL>
    <GT1/>
    <ADT_A08.IN1IN2IN3>
        <IN1>
            <IN1.1>1</IN1.1>
            etc.
        </IN1>
        <IN2>
            <IN2.63>
            etc.
        </IN2>
    </ADT_A08.IN1IN2IN3>
    <ACC/>
    <UB1/>
    <UB2/>
</ADT_A08>

------
Rob Redmond
Software Developer
T: 416-340-4800 ext 5914
E:  <mailto:ro...@cl...> ro...@cl...
 
clearcanvas
438 Richmond St. W., Suite 620
Toronto, ON, Canada M5V 3S6
 <http://www.clearcanvas.ca/> www.clearcanvas.ca
 

Re: [HAPI-devel] HL7 Message Grammar

[Bryan T. <bp...@gm...>]

Hi Gerald,

The HL7 database has this information, although it's expensive. There
are also XML schema for later versions, which are free. Both are
available from hl7.org.

Bryan

On 7/3/06, Gerald Bortis <Ge...@we...> wrote:
> Hi all,
>
> I would like to create an HL7 message building tool, and I was wondering
> if there was a grammar available which lists all messages and their
> segments and fields which could be parsed. Could this be accomplished
> using the HAPI library? Thanks for any input.
>
> Gerald
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>

[HAPI-devel] HL7 Message Grammar

[Gerald B. <Ge...@we...>]

Hi all,

I would like to create an HL7 message building tool, and I was wondering
if there was a grammar available which lists all messages and their
segments and fields which could be parsed. Could this be accomplished
using the HAPI library? Thanks for any input.

Gerald

Re: [HAPI-devel] Non-Standard Segments

[Scott A. <sa...@bj...>]

Thank you, Bryan.

I thought it worked something like that, but I just wasn't sure.  

For some reason using the Terser hadn't occurred to me.  I was trying
to figure out how I could use the string-arg getter without much luck. 
The Terser solution is pretty slick though, so I'm going with that.

- Scott Arnold

>>> "Bryan Tripp" <bp...@gm...> 6/16/2006 2:41 PM >>>
Hi Scott,

After you call addNonstandardSegment(name) you can use the new segment
as you would any other, except that there will be no typed accessor on
the parent group. You have to use the string-arg getter or Terser to
get at the segment you've added.

If you use the name of a known segment (e.g. "PID") then the segment
will have the corresponding class. If the name isn't recognized, the
segment will be of class GenericSegment. GenericSegment is a nuisance
to code against directly but Terser handles the details transparently.

Bryan

On 6/16/06, Scott Arnold <sa...@bj...> wrote:
> Anyone know of any examples or able to explain how to manipulate
> non-standard segments (i.e. a Z segment)?  I know there is a
> addNonstandardSegment method that can be called, but have no clue
beyond
> that.  The javadocs don't help much.  I experimented with
> addNonstandardSegment, but couldn't figure it out.
>
> I assume there is a relatively simple way to custom build a
> non-standard segment and append it to the message.  Even something
as
> simple as just appending it as a String I build myself, and then
being
> able to get it back as a String I have to parse myself.  Anyone able
to
> help?
>
> I'm currently using HAPI 0.5 beta.
>
> Thanks,
>
> Scott Arnold
> Analyst
> BJC HealthCare
>
>
>
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li... 
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel 
>


_______________________________________________
Hl7api-devel mailing list
Hl7...@li... 
https://lists.sourceforge.net/lists/listinfo/hl7api-devel 

Re: [HAPI-devel] Non-Standard Segments

[Bryan T. <bp...@gm...>]

Hi Scott,

After you call addNonstandardSegment(name) you can use the new segment
as you would any other, except that there will be no typed accessor on
the parent group. You have to use the string-arg getter or Terser to
get at the segment you've added.

If you use the name of a known segment (e.g. "PID") then the segment
will have the corresponding class. If the name isn't recognized, the
segment will be of class GenericSegment. GenericSegment is a nuisance
to code against directly but Terser handles the details transparently.

Bryan

On 6/16/06, Scott Arnold <sa...@bj...> wrote:
> Anyone know of any examples or able to explain how to manipulate
> non-standard segments (i.e. a Z segment)?  I know there is a
> addNonstandardSegment method that can be called, but have no clue beyond
> that.  The javadocs don't help much.  I experimented with
> addNonstandardSegment, but couldn't figure it out.
>
> I assume there is a relatively simple way to custom build a
> non-standard segment and append it to the message.  Even something as
> simple as just appending it as a String I build myself, and then being
> able to get it back as a String I have to parse myself.  Anyone able to
> help?
>
> I'm currently using HAPI 0.5 beta.
>
> Thanks,
>
> Scott Arnold
> Analyst
> BJC HealthCare
>
>
>
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>

[HAPI-devel] Non-Standard Segments

[Scott A. <sa...@bj...>]

Anyone know of any examples or able to explain how to manipulate
non-standard segments (i.e. a Z segment)?  I know there is a
addNonstandardSegment method that can be called, but have no clue beyond
that.  The javadocs don't help much.  I experimented with
addNonstandardSegment, but couldn't figure it out.

I assume there is a relatively simple way to custom build a
non-standard segment and append it to the message.  Even something as
simple as just appending it as a String I build myself, and then being
able to get it back as a String I have to parse myself.  Anyone able to
help?

I'm currently using HAPI 0.5 beta.

Thanks,

Scott Arnold
Analyst
BJC HealthCare

[HAPI-devel] Conformance Classes System II

[Daniel N. <dan...@ya...>]

I still haven't managed to compile xml profiles into java classes, so
as an alternative approach I am trying to use the standard xml profiles
generated from MWB to validate HL7 2.5 messages. 
Unfortunatelly I get :
java.lang.NullPointerException
	at
ca.uhn.hl7v2.conf.check.DefaultValidator.makeTableName(DefaultValidator.java:428)
	at
ca.uhn.hl7v2.conf.check.DefaultValidator.testTypeAgainstTable(DefaultValidator.java:391)

Any advice on this or the previous post will be of great help.

The piece code I am attempting to use is:
  String id = "OUL_R24";  
  String profilesDirectoryPath ="C:\\PROFILES\\25\\";
  HL7Exception[] exceptions =null;
  DefaultValidator val = new DefaultValidator();
  try {
     String profileString =  
         (new FileProfileStore(profilesDirectoryPath)).getProfile(id);
     System.out.println(profileString);
     if (profileString != null) {
          ProfileParser profParser = new ProfileParser(false);


          RuntimeProfile profile = profParser.parse(profileString);

          exceptions = val.validate(hapiMsg, profile.getMessage());

      } else {
          throw new ProfileException("Unable to find the profile " +
id);
      }
  } catch (IOException e) {
      throw new ProfileException("Error retrieving profile " + id, e);
  }
catch (ProfileException pex) 
{
  pex.printStackTrace();
} 

Cheers
Dani

Re: [HAPI-devel] HAPI and other HL7 middlewares...

[Seref A. <ser...@ku...>]

Hi again,
Exactly my thoughts!!!. All  we need on top of HAPI is a "designer" for 
message and listener composition/configuration. Eclipse was also my 
first consideration. My target platform is also j2ee, so HAPI has pretty 
much all I need, however, I could not find what I need most: time to 
work on this. :) Other than these issues, HAPI is perfect for my use. 
Actually i considered porting it to C# (actually .net) but when i saw 
that it used xerces, and other libs in JAVA, i gave up on this idea.
The reason i thought this was there were no open source projects in MS 
world that can be compared to HAPI. Oh whatever, i just wanted to say 
that, a GUI tool for providing Chameleon like functionality would make 
HAPI a much stronger option for many
Best Regards
Seref

Stefan Turalski wrote:

>Hi Seref,
>
>Thank you for so complete explanation. 
>Now I become quite sure that the HAPI could be "the choice". The licensing
>and its impact of architecture is another topic, and as you said it is not
>the place to discuss it.
> 
>For the record, after more than a while with chameleon I founded it somehow
>useful, especially in a multi-technology scenario, there is API for
>.NET/Java/C++/Delphi + there is code generation support that was useful
>during my first steps (but also causes some limitations, as it is always
>with code generators). From the other side, what I only need is integration
>with one technology platform - J2EE :-)
>It is working, the library of segments is useful, and so on. Although, in
>generally, I don't know if I would like to have separate message definitions
>in one tool then source generated from it, and no way back - I couldn't find
>any option to import my code that I changed into the Chameleon :(
>There is also no easy way to define the rules for 'default' behavior, I
>assume that everything should be done in code. The approach from HAPI, where
>there is a listener, applications, the list of registered handlers seems to
>work off the shelf. 
>
>However maybe someone could think about a plug-in for Eclipse to do message
>building more easy / similar to how it is done in Chameleon ?
>
>Once again, I would like to thank for you support - Bryan, Seref; and the
>group's users for their patience ! :-)
>
>--
>Best regards,
>Stefan
>
>P.s. Seref, if you would be so kind to pass me the contact details of
>someone from SeeBeyond it would be great
>  
>
>
>  
>
>>-----Original Message-----
>>From: hl7...@li... 
>>[mailto:hl7...@li...] On Behalf 
>>Of Seref Arikan
>>Sent: Sunday, June 11, 2006 10:32 AM
>>To: ste...@s3...
>>Cc: hl7...@li...
>>Subject: Re: [HAPI-devel] HAPI and other HL7 middlewares...
>>
>>Hi Stefan,
>>Well, to be honest, my experience with chameleon was pretty 
>>limited. I helped a friend of mine to test it for an 
>>integration scenario with only a few messages to arrive, but 
>>more to come in future. What was good about chameleon was: it 
>>had a very clear and helpfull help document, it was very easy 
>>to set up and get ready to go. It generated the listeners 
>>itself, and after a couple of hours of work, the test system 
>>was working. I was impressed, since the guys I was tring to 
>>help knew nothing about HL7 and they could easily adopt it 
>>with a little help.
>>For SeeBeyond, their product portfolio is not very well 
>>documented on their web site, I don't know why? But I have 
>>met with some of their guys and they have provided me a great 
>>deal of info about their solution. 
>>Since It was a company meeting, I am not sure how much of 
>>info i can provide here, but they have a set of products for 
>>healthcare information management and messaging, and if I'm 
>>not wrong, they are building the backbone of NHS in UK. If 
>>you want, I can try to provide you contact info of someone 
>>from SeeBeyond. And by the way, I am kinda related to 
>>SeeBeyond because of my company's work with Sun Microsystems, 
>>so please take any info from me, with a little bit of b.s :) 
>>My impression about their products were mostly positive; but 
>>the are built on a more generic framework than chameleon or 
>>HAPI, so as always more power and flexibility means more work 
>>for you. Not sure about the licence costs though.
>>At the moment, I am using HAPI for 2.x messaging, and I did 
>>not have any problems so far. Open source has its own set of 
>>problems (please please please don't take this as a go for a 
>>flamewar, I'm so tired of that....) but for my case, I mostly 
>>deal with 2.X integration, and no one seems to care much 
>>about some aspects of the standarts. So, when I get a data or 
>>error that I should not be getting, I can get to the bottom 
>>of everything, and I have done this before. Again for any 
>>open source project, an active list like this is very 
>>valuable, and a big plus.
>>So, even if I have a (kinda) business relationship with Sun 
>>Microsystems related products, my choice at the moment is still HAPI.
>>Best Regards
>>Seref Arikan
>>
>>Stefan Turalski wrote:
>>
>>    
>>
>>>Hi Seref,
>>>
>>>Thank you for your help, it is always nicer to get another developer 
>>>opinion rather that marketing stuff.
>>>
>>>Since my first steps in HL7 I always prefer to have an ability to 
>>>change the code. At the beginning I thought that was the 'pride & 
>>>prejudice' of a developer, then I realized that in case of (as you 
>>>mentioned) ad-hoc messages you just need to have such an option.
>>>
>>>If I would be an integrator then I'll opt for an open-source 
>>>      
>>>
>>solution, 
>>    
>>
>>>anyway that is why I pointed the HAPI in my 
>>>      
>>>
>>evaluation/research at the 
>>    
>>
>>>first place.
>>>But I also need to provide some background information (for 
>>>      
>>>
>>example to 
>>    
>>
>>>the technical sale). In a few cases the BizTalk is already 
>>>      
>>>
>>at the site 
>>    
>>
>>>and when they already paid for it, they expect that someone 
>>>      
>>>
>>else will re-use it.
>>    
>>
>>>I tested Chameleon when I was learning what the HL7 really 
>>>      
>>>
>>is. I have 
>>    
>>
>>>to admin that it was quite helpful, but the one that I'll need right 
>>>now is rather something like Iguana (but I already have only 
>>>      
>>>
>>a few hours with it).
>>    
>>
>>>Would you be so kind to give some background, maybe share 
>>>      
>>>
>>some details 
>>    
>>
>>>on how the work with Interfaceware look like (are there any 
>>>      
>>>
>>issue, the 
>>    
>>
>>>you meet in field?)
>>>
>>>I must to admit that I didn't know any of Seebeyond product, anyway 
>>>they seems to focus on supply chain, doesn't they?
>>>
>>>--
>>>Best regards,
>>>Stefan
>>>
>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: Seref Arikan [mailto:ser...@ku...]
>>>>Sent: Thursday, June 08, 2006 5:11 PM
>>>>To: ste...@s3...
>>>>Cc: hl7...@li...
>>>>Subject: Re: [HAPI-devel] HAPI and other HL7 middlewares...
>>>>
>>>>Hi there,
>>>>Well, there are many products for hl7 related 
>>>>        
>>>>
>>functionality, ranging 
>>    
>>
>>>>from delphi components to biztalk(i remember saying ouch 
>>>      
>>>
>>when i heard 
>>    
>>
>>>>the licence cost:). Seebeyond has a pretty good product for 
>>>>        
>>>>
>>hl7, dicom 
>>    
>>
>>>>and custom messaging(which is owned by Sun microsystems at 
>>>>        
>>>>
>>the moment) 
>>    
>>
>>>>Chameleon by interfaceware is really good, but for all 
>>>>        
>>>>
>>these products, 
>>    
>>
>>>>there is a considerable amount of licence cost, and also 
>>>>        
>>>>
>>when it comes 
>>    
>>
>>>>to hl7 messaging, i found being able to hack source code, and very 
>>>>valuable asset. Especially for 2.x, messaging is still very muc 
>>>>ad-hoc, and a lot of customization is necessary. so, you 
>>>>        
>>>>
>>can consider 
>>    
>>
>>>>open source a really big advantage in this respect.
>>>>However, if you don't consider cost as a problem, then i should say 
>>>>that i really liked interfaceware solution.
>>>>regards
>>>>
>>>>Seref
>>>>
>>>>
>>>>Stefan Turalski wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>Hi,
>>>>>
>>>>>In a next few days I should summarize my evaluation of HAPI and I 
>>>>>should compare it with another HL7 router / interfaces / engines / 
>>>>>mappers / whatsoever.
>>>>>
>>>>>How do you think should I be aware of any existing comparisons, or 
>>>>>would you like to propose some tool ?
>>>>>
>>>>>I'm doing such a comparison because it my be inconvenient 
>>>>>          
>>>>>
>>for us to 
>>    
>>
>>>>>use open source project code.
>>>>>In real world the MPL in case of something like HL7 (you have the 
>>>>>logic of your app in message processing code) just may 
>>>>>          
>>>>>
>>don't work :(
>>    
>>
>>>>>Definitely I'll compare HAPI to the BizTalk, and may be to
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>the Orion
>>>>   
>>>>
>>>>        
>>>>
>>>>>Symphonia, should I take an other systems into account?
>>>>>
>>>>>In advance I would like to thank you for the advices.
>>>>>
>>>>>--
>>>>>Best regards
>>>>>Stefan Turalski
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>------------------------------------------------------------
>>>>        
>>>>
>>----------
>>    
>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>-- The information contained in this e-mail and in any
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>attachments is
>>>>   
>>>>
>>>>        
>>>>
>>>>>confidential and is designated solely for the attention of the 
>>>>>intended recipient(s). If you are not an intended
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>recipient, you must
>>>>   
>>>>
>>>>        
>>>>
>>>>>not use, disclose, copy, distribute or retain this e-mail
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>or any part
>>>>   
>>>>
>>>>        
>>>>
>>>>>thereof. If you have received this e-mail in error, please
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>notify the
>>>>   
>>>>
>>>>        
>>>>
>>>>>sender by return e-mail and delete all copies of this
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>e-mail from your
>>>>   
>>>>
>>>>        
>>>>
>>>>>computer system(s). Please direct any additional queries to:
>>>>>com...@s3.... Thank You.
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>------------------------------------------------------------
>>>>        
>>>>
>>----------
>>    
>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>--
>>>>>
>>>>>-------------------------------------------------------------
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>----------
>>>>   
>>>>
>>>>        
>>>>
>>>>>-
>>>>>
>>>>>_______________________________________________
>>>>>Hl7api-devel mailing list
>>>>>Hl7...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>>>>>
>>>>>
>>>>>-------------------------------------------------------------
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>----------
>>>>   
>>>>
>>>>        
>>>>
>>>>>-
>>>>>
>>>>>No virus found in this incoming message.
>>>>>Checked by AVG Free Edition.
>>>>>Version: 7.1.394 / Virus Database: 268.8.3/358 - Release
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>Date: 6/7/2006
>>>>   
>>>>
>>>>        
>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>--
>>>>No virus found in this outgoing message.
>>>>Checked by AVG Free Edition.
>>>>Version: 7.1.394 / Virus Database: 268.8.3/358 - Release
>>>>Date: 6/7/2006
>>>>
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>The information contained in this e-mail and in any 
>>>      
>>>
>>attachments is confidential and is designated solely for the 
>>attention of the intended recipient(s). If you are not an 
>>intended recipient, you must not use, disclose, copy, 
>>distribute or retain this e-mail or any part thereof. If you 
>>have received this e-mail in error, please notify the sender 
>>by return e-mail and delete all copies of this e-mail from 
>>your computer system(s).
>>    
>>
>>>Please direct any additional queries to: com...@s3....
>>>Thank You.
>>>
>>>
>>> 
>>>
>>>      
>>>
>>
>>--
>>No virus found in this outgoing message.
>>Checked by AVG Free Edition.
>>Version: 7.1.394 / Virus Database: 268.8.3/360 - Release 
>>Date: 6/9/2006
>>
>>
>>
>>_______________________________________________
>>Hl7api-devel mailing list
>>Hl7...@li...
>>https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>>
>>    
>>
>
>
>The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
>Please direct any additional queries to: com...@s3....
>Thank You.
>
>
>  
>



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.3/361 - Release Date: 6/11/2006

Re: [HAPI-devel] HAPI and other HL7 middlewares...

[Stefan T. <ste...@s3...>]

Hi Seref,

Thank you for so complete explanation. 
Now I become quite sure that the HAPI could be "the choice". The licensing
and its impact of architecture is another topic, and as you said it is not
the place to discuss it.
 
For the record, after more than a while with chameleon I founded it somehow
useful, especially in a multi-technology scenario, there is API for
.NET/Java/C++/Delphi + there is code generation support that was useful
during my first steps (but also causes some limitations, as it is always
with code generators). From the other side, what I only need is integration
with one technology platform - J2EE :-)
It is working, the library of segments is useful, and so on. Although, in
generally, I don't know if I would like to have separate message definitions
in one tool then source generated from it, and no way back - I couldn't find
any option to import my code that I changed into the Chameleon :(
There is also no easy way to define the rules for 'default' behavior, I
assume that everything should be done in code. The approach from HAPI, where
there is a listener, applications, the list of registered handlers seems to
work off the shelf. 

However maybe someone could think about a plug-in for Eclipse to do message
building more easy / similar to how it is done in Chameleon ?

Once again, I would like to thank for you support - Bryan, Seref; and the
group's users for their patience ! :-)

--
Best regards,
Stefan

P.s. Seref, if you would be so kind to pass me the contact details of
someone from SeeBeyond it would be great
  


> -----Original Message-----
> From: hl7...@li... 
> [mailto:hl7...@li...] On Behalf 
> Of Seref Arikan
> Sent: Sunday, June 11, 2006 10:32 AM
> To: ste...@s3...
> Cc: hl7...@li...
> Subject: Re: [HAPI-devel] HAPI and other HL7 middlewares...
> 
> Hi Stefan,
> Well, to be honest, my experience with chameleon was pretty 
> limited. I helped a friend of mine to test it for an 
> integration scenario with only a few messages to arrive, but 
> more to come in future. What was good about chameleon was: it 
> had a very clear and helpfull help document, it was very easy 
> to set up and get ready to go. It generated the listeners 
> itself, and after a couple of hours of work, the test system 
> was working. I was impressed, since the guys I was tring to 
> help knew nothing about HL7 and they could easily adopt it 
> with a little help.
> For SeeBeyond, their product portfolio is not very well 
> documented on their web site, I don't know why? But I have 
> met with some of their guys and they have provided me a great 
> deal of info about their solution. 
> Since It was a company meeting, I am not sure how much of 
> info i can provide here, but they have a set of products for 
> healthcare information management and messaging, and if I'm 
> not wrong, they are building the backbone of NHS in UK. If 
> you want, I can try to provide you contact info of someone 
> from SeeBeyond. And by the way, I am kinda related to 
> SeeBeyond because of my company's work with Sun Microsystems, 
> so please take any info from me, with a little bit of b.s :) 
> My impression about their products were mostly positive; but 
> the are built on a more generic framework than chameleon or 
> HAPI, so as always more power and flexibility means more work 
> for you. Not sure about the licence costs though.
> At the moment, I am using HAPI for 2.x messaging, and I did 
> not have any problems so far. Open source has its own set of 
> problems (please please please don't take this as a go for a 
> flamewar, I'm so tired of that....) but for my case, I mostly 
> deal with 2.X integration, and no one seems to care much 
> about some aspects of the standarts. So, when I get a data or 
> error that I should not be getting, I can get to the bottom 
> of everything, and I have done this before. Again for any 
> open source project, an active list like this is very 
> valuable, and a big plus.
> So, even if I have a (kinda) business relationship with Sun 
> Microsystems related products, my choice at the moment is still HAPI.
> Best Regards
> Seref Arikan
> 
> Stefan Turalski wrote:
> 
> >Hi Seref,
> >
> >Thank you for your help, it is always nicer to get another developer 
> >opinion rather that marketing stuff.
> >
> >Since my first steps in HL7 I always prefer to have an ability to 
> >change the code. At the beginning I thought that was the 'pride & 
> >prejudice' of a developer, then I realized that in case of (as you 
> >mentioned) ad-hoc messages you just need to have such an option.
> >
> >If I would be an integrator then I'll opt for an open-source 
> solution, 
> >anyway that is why I pointed the HAPI in my 
> evaluation/research at the 
> >first place.
> >But I also need to provide some background information (for 
> example to 
> >the technical sale). In a few cases the BizTalk is already 
> at the site 
> >and when they already paid for it, they expect that someone 
> else will re-use it.
> >
> >I tested Chameleon when I was learning what the HL7 really 
> is. I have 
> >to admin that it was quite helpful, but the one that I'll need right 
> >now is rather something like Iguana (but I already have only 
> a few hours with it).
> >Would you be so kind to give some background, maybe share 
> some details 
> >on how the work with Interfaceware look like (are there any 
> issue, the 
> >you meet in field?)
> >
> >I must to admit that I didn't know any of Seebeyond product, anyway 
> >they seems to focus on supply chain, doesn't they?
> >
> >--
> >Best regards,
> >Stefan
> >
> >
> > 
> >
> >  
> >
> >>-----Original Message-----
> >>From: Seref Arikan [mailto:ser...@ku...]
> >>Sent: Thursday, June 08, 2006 5:11 PM
> >>To: ste...@s3...
> >>Cc: hl7...@li...
> >>Subject: Re: [HAPI-devel] HAPI and other HL7 middlewares...
> >>
> >>Hi there,
> >>Well, there are many products for hl7 related 
> functionality, ranging 
> >>from delphi components to biztalk(i remember saying ouch 
> when i heard 
> >>the licence cost:). Seebeyond has a pretty good product for 
> hl7, dicom 
> >>and custom messaging(which is owned by Sun microsystems at 
> the moment) 
> >>Chameleon by interfaceware is really good, but for all 
> these products, 
> >>there is a considerable amount of licence cost, and also 
> when it comes 
> >>to hl7 messaging, i found being able to hack source code, and very 
> >>valuable asset. Especially for 2.x, messaging is still very muc 
> >>ad-hoc, and a lot of customization is necessary. so, you 
> can consider 
> >>open source a really big advantage in this respect.
> >>However, if you don't consider cost as a problem, then i should say 
> >>that i really liked interfaceware solution.
> >>regards
> >>
> >>Seref
> >>
> >>
> >>Stefan Turalski wrote:
> >>
> >>    
> >>
> >>>Hi,
> >>>
> >>>In a next few days I should summarize my evaluation of HAPI and I 
> >>>should compare it with another HL7 router / interfaces / engines / 
> >>>mappers / whatsoever.
> >>>
> >>>How do you think should I be aware of any existing comparisons, or 
> >>>would you like to propose some tool ?
> >>>
> >>>I'm doing such a comparison because it my be inconvenient 
> for us to 
> >>>use open source project code.
> >>>In real world the MPL in case of something like HL7 (you have the 
> >>>logic of your app in message processing code) just may 
> don't work :(
> >>>
> >>>Definitely I'll compare HAPI to the BizTalk, and may be to
> >>>      
> >>>
> >>the Orion
> >>    
> >>
> >>>Symphonia, should I take an other systems into account?
> >>>
> >>>In advance I would like to thank you for the advices.
> >>>
> >>>--
> >>>Best regards
> >>>Stefan Turalski
> >>>
> >>>
> >>>
> >>>      
> >>>
> >>------------------------------------------------------------
> ----------
> >>    
> >>
> >>>-- The information contained in this e-mail and in any
> >>>      
> >>>
> >>attachments is
> >>    
> >>
> >>>confidential and is designated solely for the attention of the 
> >>>intended recipient(s). If you are not an intended
> >>>      
> >>>
> >>recipient, you must
> >>    
> >>
> >>>not use, disclose, copy, distribute or retain this e-mail
> >>>      
> >>>
> >>or any part
> >>    
> >>
> >>>thereof. If you have received this e-mail in error, please
> >>>      
> >>>
> >>notify the
> >>    
> >>
> >>>sender by return e-mail and delete all copies of this
> >>>      
> >>>
> >>e-mail from your
> >>    
> >>
> >>>computer system(s). Please direct any additional queries to:
> >>>com...@s3.... Thank You.
> >>>
> >>>      
> >>>
> >>------------------------------------------------------------
> ----------
> >>    
> >>
> >>>--
> >>>
> >>>-------------------------------------------------------------
> >>>      
> >>>
> >>----------
> >>    
> >>
> >>>-
> >>>
> >>>_______________________________________________
> >>>Hl7api-devel mailing list
> >>>Hl7...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> >>> 
> >>>
> >>>-------------------------------------------------------------
> >>>      
> >>>
> >>----------
> >>    
> >>
> >>>-
> >>>
> >>>No virus found in this incoming message.
> >>>Checked by AVG Free Edition.
> >>>Version: 7.1.394 / Virus Database: 268.8.3/358 - Release
> >>>      
> >>>
> >>Date: 6/7/2006
> >>    
> >>
> >>> 
> >>>
> >>>      
> >>>
> >>
> >>--
> >>No virus found in this outgoing message.
> >>Checked by AVG Free Edition.
> >>Version: 7.1.394 / Virus Database: 268.8.3/358 - Release
> >>Date: 6/7/2006
> >>
> >>
> >>    
> >>
> >
> >
> >The information contained in this e-mail and in any 
> attachments is confidential and is designated solely for the 
> attention of the intended recipient(s). If you are not an 
> intended recipient, you must not use, disclose, copy, 
> distribute or retain this e-mail or any part thereof. If you 
> have received this e-mail in error, please notify the sender 
> by return e-mail and delete all copies of this e-mail from 
> your computer system(s).
> >Please direct any additional queries to: com...@s3....
> >Thank You.
> >
> >
> >  
> >
> 
> 
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.8.3/360 - Release 
> Date: 6/9/2006
> 
> 
> 
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> 


The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: com...@s3....
Thank You.

[HAPI-devel] Conformance Classes System

[Daniel N. <dan...@ya...>]

Hi,

I am trying to compile an OUL_R24.xml profile generated from Messaging
Workbench 1.6.5.5, but I get an ugly error message 
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.VersionIDchildren.Co
mpVersionID
ConformanceError:
ca.uhn.hl7v2.conf.classes.exceptions.ConformanceError: Could not find
underlying
 SubComponent datatype. This is a bug. Exception:
java.lang.NoSuchMethodExceptio
n: ca.uhn.hl7v2.model.v25.datatype.ST.<init>()
:

In order to get to this point I had to manually fulfill the msgStructId
which seemded to be empty. 

I would be very grateful if somebody could give a hint on it. 

Thanks in advance.
Dani


The full trace can be found below:
C:\projectesdani\IHE\HAPISENCER\hapi-0.5beta>"java" -classpath
"C:\projectesdani
\IHE\HAPISENCER\hapi-0.5beta\lib\hapi-0.4.2.jar;";"C:\projectesdani\IHE\HAPISENC
ER\hapi-0.5beta\hapi-0.5beta.jar;";"C:\projectesdani\hapi25support\lib\_log.jar;
C:\projectesdani\hapi25support\lib\_xml.jar;";"C:\projectesdani\hapi25support\li
b\_xpath.jar;C:\projectesdani\hapi25support\lib\commons-logging.jar;";"C:\projec
tesdani\hapi25support\lib\hapi-0.4.2.jar;C:\projectesdani\hapi25support\lib\jaxe
n-full.jar;";"C:\projectesdani\hapi25support\lib\jdom.jar;C:\projectesdani\hapi2
5support\lib\junit-addons-1.4.jar;";"C:\projectesdani\hapi25support\lib\log4j-1.
2.8.jar;C:\projectesdani\hapi25support\lib\saxpath.jar;";"C:\projectesdani\hapi2
5support\lib\xercesImpl.jar;C:\projectesdani\hapi25support\lib\xmlParserAPIs.jar
;";"C:\jd\jdev\lib\ant.jar;C:\jd\jdev\lib\optional.jar"
ca.uhn.hl7v2.conf.classe
s.generator.builders.ConfGen -v "C:\PROFILES\25\OUL_R24.xml"
marianito.jar com.s
ystelab.ihe.profiles
marianito.jar
ConfGen: verbose display enabled
Generating Source...
Generating Segment: com.systelab.ihe.profiles.MsgOULR24
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.FieldFieldSeparator

Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.FieldEncodingCharact
ers
Generating Field:
com.systelab.ihe.profiles.MSHchildren.FieldSendingApplication

Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.SendingApplicationch
ildren.CompNamespaceID
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.SendingApplicationch
ildren.CompUniversalID
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.SendingApplicationch
ildren.CompUniversalIDType
Generating Field:
com.systelab.ihe.profiles.MSHchildren.FieldSendingFacility
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.SendingFacilitychild
ren.CompNamespaceID
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.SendingFacilitychild
ren.CompUniversalID
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.SendingFacilitychild
ren.CompUniversalIDType
Generating Field:
com.systelab.ihe.profiles.MSHchildren.FieldReceivingApplicatio
n
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.ReceivingApplication
children.CompNamespaceID
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.ReceivingApplication
children.CompUniversalID
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.ReceivingApplication
children.CompUniversalIDType
Generating Field:
com.systelab.ihe.profiles.MSHchildren.FieldReceivingFacility
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.ReceivingFacilitychi
ldren.CompNamespaceID
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.ReceivingFacilitychi
ldren.CompUniversalID
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.ReceivingFacilitychi
ldren.CompUniversalIDType
Generating Field:
com.systelab.ihe.profiles.MSHchildren.FieldDateTimeOfMessage
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.DateTimeOfMessagechi
ldren.CompDateTime
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.DateTimeOfMessagechi
ldren.CompDegreeOfPrecision
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.FieldSecurity
Generating Field:
com.systelab.ihe.profiles.MSHchildren.FieldMessageType
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.MessageTypechildren.
CompMessageType
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.MessageTypechildren.
CompTriggerEvent
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.MessageTypechildren.
CompMessageStructure
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.FieldMessageControlI
D
Generating Field:
com.systelab.ihe.profiles.MSHchildren.FieldProcessingID
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.ProcessingIDchildren
.CompProcessingID
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.ProcessingIDchildren
.CompProcessingMode
Generating Field: com.systelab.ihe.profiles.MSHchildren.FieldVersionID
Generating Primitive:
com.systelab.ihe.profiles.MSHchildren.VersionIDchildren.Co
mpVersionID
ConformanceError:
ca.uhn.hl7v2.conf.classes.exceptions.ConformanceError: Could not find
underlying
 SubComponent datatype. This is a bug. Exception:
java.lang.NoSuchMethodExceptio
n: ca.uhn.hl7v2.model.v25.datatype.ST.<init>()

Re: [HAPI-devel] HAPI and other HL7 middlewares...

[Seref A. <ser...@ku...>]

Hi Stefan,
Well, to be honest, my experience with chameleon was pretty limited. I 
helped a friend of mine to test it for an integration scenario with only 
a few messages to arrive, but more to come in future. What was good 
about chameleon was: it had a very clear and helpfull help document, it 
was very easy to set up and get ready to go. It generated the listeners 
itself, and after a couple of hours of work, the test system was 
working. I was impressed, since the guys I was tring to help knew 
nothing about HL7 and they could easily adopt it with a little help.
For SeeBeyond, their product portfolio is not very well documented on 
their web site, I don't know why? But I have met with some of their guys 
and they have provided me a great deal of info about their solution. 
Since It was a company meeting, I am not sure how much of info i can 
provide here, but they have a set of products for healthcare information 
management and messaging, and if I'm not wrong, they are building the 
backbone of NHS in UK. If you want, I can try to provide you contact 
info of someone from SeeBeyond. And by the way, I am kinda related to 
SeeBeyond because of my company's work with Sun Microsystems, so please 
take any info from me, with a little bit of b.s :)
My impression about their products were mostly positive; but the are 
built on a more generic framework than chameleon or HAPI, so as always 
more power and flexibility means more work for you. Not sure about the 
licence costs though.
At the moment, I am using HAPI for 2.x messaging, and I did not have any 
problems so far. Open source has its own set of problems (please please 
please don't take this as a go for a flamewar, I'm so tired of that....) 
but for my case, I mostly deal with 2.X integration, and no one seems to 
care much about some aspects of the standarts. So, when I get a data or 
error that I should not be getting, I can get to the bottom of 
everything, and I have done this before. Again for any open source 
project, an active list like this is very valuable, and a big plus.
So, even if I have a (kinda) business relationship with Sun Microsystems 
related products, my choice at the moment is still HAPI.
Best Regards
Seref Arikan

Stefan Turalski wrote:

>Hi Seref,
>
>Thank you for your help, it is always nicer to get another developer opinion
>rather that marketing stuff.
>
>Since my first steps in HL7 I always prefer to have an ability to change the
>code. At the beginning I thought that was the 'pride & prejudice' of a
>developer, then I realized that in case of (as you mentioned) ad-hoc
>messages you just need to have such an option.
>
>If I would be an integrator then I'll opt for an open-source solution,
>anyway that is why I pointed the HAPI in my evaluation/research at the first
>place. 
>But I also need to provide some background information (for example to the
>technical sale). In a few cases the BizTalk is already at the site and when
>they already paid for it, they expect that someone else will re-use it. 
>
>I tested Chameleon when I was learning what the HL7 really is. I have to
>admin that it was quite helpful, but the one that I'll need right now is
>rather something like Iguana (but I already have only a few hours with it).
>Would you be so kind to give some background, maybe share some details on
>how the work with Interfaceware look like (are there any issue, the you meet
>in field?)
>
>I must to admit that I didn't know any of Seebeyond product, anyway they
>seems to focus on supply chain, doesn't they?
>
>--
>Best regards,
>Stefan
>
>
> 
>
>  
>
>>-----Original Message-----
>>From: Seref Arikan [mailto:ser...@ku...] 
>>Sent: Thursday, June 08, 2006 5:11 PM
>>To: ste...@s3...
>>Cc: hl7...@li...
>>Subject: Re: [HAPI-devel] HAPI and other HL7 middlewares...
>>
>>Hi there,
>>Well, there are many products for hl7 related functionality, 
>>ranging from delphi components to biztalk(i remember saying 
>>ouch when i heard the licence cost:). Seebeyond has a pretty 
>>good product for hl7, dicom and custom messaging(which is 
>>owned by Sun microsystems at the moment) Chameleon by 
>>interfaceware is really good, but for all these products, 
>>there is a considerable amount of licence cost, and also when 
>>it comes to hl7 messaging, i found being able to hack source 
>>code, and very valuable asset. Especially for 2.x, messaging 
>>is still very muc ad-hoc, and a lot of customization is 
>>necessary. so, you can consider open source a really big 
>>advantage in this respect.
>>However, if you don't consider cost as a problem, then i 
>>should say that i really liked interfaceware solution.
>>regards
>>
>>Seref
>>
>>
>>Stefan Turalski wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>In a next few days I should summarize my evaluation of HAPI and I 
>>>should compare it with another HL7 router / interfaces / engines / 
>>>mappers / whatsoever.
>>>
>>>How do you think should I be aware of any existing comparisons, or 
>>>would you like to propose some tool ?
>>>
>>>I'm doing such a comparison because it my be inconvenient for us to 
>>>use open source project code.
>>>In real world the MPL in case of something like HL7 (you have the 
>>>logic of your app in message processing code) just may don't work :(
>>>
>>>Definitely I'll compare HAPI to the BizTalk, and may be to 
>>>      
>>>
>>the Orion 
>>    
>>
>>>Symphonia, should I take an other systems into account?
>>>
>>>In advance I would like to thank you for the advices.
>>>
>>>--
>>>Best regards
>>>Stefan Turalski
>>>
>>>
>>>
>>>      
>>>
>>----------------------------------------------------------------------
>>    
>>
>>>-- The information contained in this e-mail and in any 
>>>      
>>>
>>attachments is 
>>    
>>
>>>confidential and is designated solely for the attention of the 
>>>intended recipient(s). If you are not an intended 
>>>      
>>>
>>recipient, you must 
>>    
>>
>>>not use, disclose, copy, distribute or retain this e-mail 
>>>      
>>>
>>or any part 
>>    
>>
>>>thereof. If you have received this e-mail in error, please 
>>>      
>>>
>>notify the 
>>    
>>
>>>sender by return e-mail and delete all copies of this 
>>>      
>>>
>>e-mail from your 
>>    
>>
>>>computer system(s). Please direct any additional queries to:
>>>com...@s3.... Thank You.
>>>
>>>      
>>>
>>----------------------------------------------------------------------
>>    
>>
>>>--
>>>
>>>-------------------------------------------------------------
>>>      
>>>
>>----------
>>    
>>
>>>-
>>>
>>>_______________________________________________
>>>Hl7api-devel mailing list
>>>Hl7...@li...
>>>https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>>> 
>>>
>>>-------------------------------------------------------------
>>>      
>>>
>>----------
>>    
>>
>>>-
>>>
>>>No virus found in this incoming message.
>>>Checked by AVG Free Edition.
>>>Version: 7.1.394 / Virus Database: 268.8.3/358 - Release 
>>>      
>>>
>>Date: 6/7/2006
>>    
>>
>>> 
>>>
>>>      
>>>
>>
>>--
>>No virus found in this outgoing message.
>>Checked by AVG Free Edition.
>>Version: 7.1.394 / Virus Database: 268.8.3/358 - Release 
>>Date: 6/7/2006
>>
>>
>>    
>>
>
>
>The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
>Please direct any additional queries to: com...@s3....
>Thank You.
>
>
>  
>



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.3/360 - Release Date: 6/9/2006

Re: [HAPI-devel] HAPI and other HL7 middlewares...

[Stefan T. <ste...@s3...>]

Hi Bryan,

I know that list, the problem is (as usual) time limit (day = 24 hours, and
my request for additional 6 was rejected several times already :)
That is the main reason why I asked other developers for help.

I definitely should give a look at Mirth (some one on the VistA mailing list
also mentioned this project in different context), right now I'm little
aware of the fact that there is rather no community and WebReach Inc. has to
be contacted when you are interested in development. (strange?)

The MD Link looks promising, but there is no trail / demo (or I just
couldn't find it ?).

In context of the MPL, I think in some time (as in other few systems) the
internal processing logic somehow migrate to the open-source code. 
IMHO it is a limitation when you need to keep in mind that the open source
code and your code have to be separated. Sometimes it is easier to build-in
custom things on the generic level (even it isn't good decision form the
design point of view).
For example, during the research I played a little with the PID datatype, I
prepared a bean 'PID' and then I extended the PID datatype with our
propriety fields. I know that I could inherit and add everything 'outside'
the HAPI, but is was easier to do it 'inside', especially when I know that
such a interface would be build once (and work only with this system).

On the other hand, where I have no source code opened, I'm forced to make
this 'outside'/'inside' decision and everything should be outside the
com.middleware. The profit then is that you could (I hope so) force the
integrator to repair bugs / make changes / etc.. 

However, I'm still quite sure that HAPI could be used in our solution, it
works well, is easily extendable, the code is clear and understandable, the
problem my be (as I already mentioned in a letter to Seref) that client
(hospital) already has something.
 
By the way, have you any opportunity to work with the Iatric 'Magic
Interfaces' http://www.iatric.com/interfaces/magic/magic.asp ?

--
Best regards,
stefan


> -----Original Message-----
> From: Bryan Tripp [mailto:bp...@gm...] 
> Sent: Thursday, June 08, 2006 6:06 PM
> To: Seref Arikan
> Cc: ste...@s3...; hl7...@li...
> Subject: Re: [HAPI-devel] HAPI and other HL7 middlewares...
> 
> There is also a good list of tools maintained by HL7 Australia:
> 
> http://www.hl7.org.au/HL7-Tools.htm
> 
> And a couple of other products that comes to mind are Mirth
> (http://mirth.sourceforge.net/) and MD Link, which my brother 
> works on (http://www.mdisolutions.com/products/md_link.php).
> 
> 
> On another note, Stefan, what do you see as the barrier 
> introduced by the MPL license? The MPL lets you use HAPI in 
> both open-source and closed-source commercial systems. If you 
> release a closed-source system that incorporates HAPI, you 
> have to provide the HAPI source, as well as the source for 
> any modifications you make to HAPI. But you don't have to 
> include source code for your implementations of HAPI 
> interfaces (like Application) that implement your system 
> logic, and you don't have to include source code for any 
> other part of your system. The MPL is very different from the 
> GPL in that sense.
> 
> Bryan
> 
> On 6/8/06, Seref Arikan <ser...@ku...> wrote:
> > Hi there,
> > Well, there are many products for hl7 related 
> functionality, ranging 
> > from delphi components to biztalk(i remember saying ouch 
> when i heard 
> > the licence cost:). Seebeyond has a pretty good product for 
> hl7, dicom 
> > and custom messaging(which is owned by Sun microsystems at 
> the moment) 
> > Chameleon by interfaceware is really good, but for all 
> these products, 
> > there is a considerable amount of licence cost, and also 
> when it comes 
> > to hl7 messaging, i found being able to hack source code, and very 
> > valuable asset. Especially for 2.x, messaging is still very muc 
> > ad-hoc, and a lot of customization is necessary. so, you 
> can consider 
> > open source a really big advantage in this respect.
> > However, if you don't consider cost as a problem, then i should say 
> > that i really liked interfaceware solution.
> > regards
> >
> > Seref
> >
> >
> > Stefan Turalski wrote:
> >
> > > Hi,
> > >
> > > In a next few days I should summarize my evaluation of HAPI and I 
> > > should compare it with another HL7 router / interfaces / 
> engines / 
> > > mappers / whatsoever.
> > >
> > > How do you think should I be aware of any existing 
> comparisons, or 
> > > would you like to propose some tool ?
> > >
> > > I'm doing such a comparison because it my be inconvenient 
> for us to 
> > > use open source project code.
> > > In real world the MPL in case of something like HL7 (you have the 
> > > logic of your app in message processing code) just may 
> don't work :(
> > >
> > > Definitely I'll compare HAPI to the BizTalk, and may be 
> to the Orion 
> > > Symphonia, should I take an other systems into account?
> > >
> > > In advance I would like to thank you for the advices.
> > >
> > > --
> > > Best regards
> > > Stefan Turalski
> > >
> > >
> > > 
> --------------------------------------------------------------------
> > > ---- The information contained in this e-mail and in any 
> attachments 
> > > is confidential and is designated solely for the attention of the 
> > > intended recipient(s). If you are not an intended recipient, you 
> > > must not use, disclose, copy, distribute or retain this e-mail or 
> > > any part thereof. If you have received this e-mail in 
> error, please 
> > > notify the sender by return e-mail and delete all copies of this 
> > > e-mail from your computer system(s). Please direct any 
> additional queries to:
> > > com...@s3.... Thank You.
> > > 
> --------------------------------------------------------------------
> > > ----
> > >
> > 
> >---------------------------------------------------------------------
> > >---
> > >
> > >_______________________________________________
> > >Hl7api-devel mailing list
> > >Hl7...@li...
> > >https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> > >
> > >
> > 
> >---------------------------------------------------------------------
> > >---
> > >
> > >No virus found in this incoming message.
> > >Checked by AVG Free Edition.
> > >Version: 7.1.394 / Virus Database: 268.8.3/358 - Release Date: 
> > >6/7/2006
> > >
> > >
> >
> >
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.1.394 / Virus Database: 268.8.3/358 - Release Date: 
> > 6/7/2006
> >
> >
> >
> > _______________________________________________
> > Hl7api-devel mailing list
> > Hl7...@li...
> > https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> >
> 


The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: com...@s3....
Thank You.

Re: [HAPI-devel] HAPI and other HL7 middlewares...

[Stefan T. <ste...@s3...>]

Hi Seref,

Thank you for your help, it is always nicer to get another developer opinion
rather that marketing stuff.

Since my first steps in HL7 I always prefer to have an ability to change the
code. At the beginning I thought that was the 'pride & prejudice' of a
developer, then I realized that in case of (as you mentioned) ad-hoc
messages you just need to have such an option.

If I would be an integrator then I'll opt for an open-source solution,
anyway that is why I pointed the HAPI in my evaluation/research at the first
place. 
But I also need to provide some background information (for example to the
technical sale). In a few cases the BizTalk is already at the site and when
they already paid for it, they expect that someone else will re-use it. 

I tested Chameleon when I was learning what the HL7 really is. I have to
admin that it was quite helpful, but the one that I'll need right now is
rather something like Iguana (but I already have only a few hours with it).
Would you be so kind to give some background, maybe share some details on
how the work with Interfaceware look like (are there any issue, the you meet
in field?)

I must to admit that I didn't know any of Seebeyond product, anyway they
seems to focus on supply chain, doesn't they?

--
Best regards,
Stefan


 

> -----Original Message-----
> From: Seref Arikan [mailto:ser...@ku...] 
> Sent: Thursday, June 08, 2006 5:11 PM
> To: ste...@s3...
> Cc: hl7...@li...
> Subject: Re: [HAPI-devel] HAPI and other HL7 middlewares...
> 
> Hi there,
> Well, there are many products for hl7 related functionality, 
> ranging from delphi components to biztalk(i remember saying 
> ouch when i heard the licence cost:). Seebeyond has a pretty 
> good product for hl7, dicom and custom messaging(which is 
> owned by Sun microsystems at the moment) Chameleon by 
> interfaceware is really good, but for all these products, 
> there is a considerable amount of licence cost, and also when 
> it comes to hl7 messaging, i found being able to hack source 
> code, and very valuable asset. Especially for 2.x, messaging 
> is still very muc ad-hoc, and a lot of customization is 
> necessary. so, you can consider open source a really big 
> advantage in this respect.
> However, if you don't consider cost as a problem, then i 
> should say that i really liked interfaceware solution.
> regards
> 
> Seref
> 
> 
> Stefan Turalski wrote:
> 
> > Hi,
> >
> > In a next few days I should summarize my evaluation of HAPI and I 
> > should compare it with another HL7 router / interfaces / engines / 
> > mappers / whatsoever.
> >
> > How do you think should I be aware of any existing comparisons, or 
> > would you like to propose some tool ?
> >
> > I'm doing such a comparison because it my be inconvenient for us to 
> > use open source project code.
> > In real world the MPL in case of something like HL7 (you have the 
> > logic of your app in message processing code) just may don't work :(
> >
> > Definitely I'll compare HAPI to the BizTalk, and may be to 
> the Orion 
> > Symphonia, should I take an other systems into account?
> >
> > In advance I would like to thank you for the advices.
> >
> > --
> > Best regards
> > Stefan Turalski
> >
> >
> > 
> ----------------------------------------------------------------------
> > -- The information contained in this e-mail and in any 
> attachments is 
> > confidential and is designated solely for the attention of the 
> > intended recipient(s). If you are not an intended 
> recipient, you must 
> > not use, disclose, copy, distribute or retain this e-mail 
> or any part 
> > thereof. If you have received this e-mail in error, please 
> notify the 
> > sender by return e-mail and delete all copies of this 
> e-mail from your 
> > computer system(s). Please direct any additional queries to:
> > com...@s3.... Thank You.
> > 
> ----------------------------------------------------------------------
> > --
> >
> >-------------------------------------------------------------
> ----------
> >-
> >
> >_______________________________________________
> >Hl7api-devel mailing list
> >Hl7...@li...
> >https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> >  
> >
> >-------------------------------------------------------------
> ----------
> >-
> >
> >No virus found in this incoming message.
> >Checked by AVG Free Edition.
> >Version: 7.1.394 / Virus Database: 268.8.3/358 - Release 
> Date: 6/7/2006
> >  
> >
> 
> 
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.8.3/358 - Release 
> Date: 6/7/2006
> 
> 


The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: com...@s3....
Thank You.

Re: [HAPI-devel] HAPI and other HL7 middlewares...

[Bryan T. <bp...@gm...>]

There is also a good list of tools maintained by HL7 Australia:

http://www.hl7.org.au/HL7-Tools.htm

And a couple of other products that comes to mind are Mirth
(http://mirth.sourceforge.net/) and MD Link, which my brother works on
(http://www.mdisolutions.com/products/md_link.php).


On another note, Stefan, what do you see as the barrier introduced by
the MPL license? The MPL lets you use HAPI in both open-source and
closed-source commercial systems. If you release a closed-source
system that incorporates HAPI, you have to provide the HAPI source, as
well as the source for any modifications you make to HAPI. But you
don't have to include source code for your implementations of HAPI
interfaces (like Application) that implement your system logic, and
you don't have to include source code for any other part of your
system. The MPL is very different from the GPL in that sense.

Bryan

On 6/8/06, Seref Arikan <ser...@ku...> wrote:
> Hi there,
> Well, there are many products for hl7 related functionality, ranging
> from delphi components to biztalk(i remember saying ouch when i heard
> the licence cost:). Seebeyond has a pretty good product for hl7, dicom
> and custom messaging(which is owned by Sun microsystems at the moment)
> Chameleon by interfaceware is really good, but for all these products,
> there is a considerable amount of licence cost, and also when it comes
> to hl7 messaging, i found being able to hack source code, and very
> valuable asset. Especially for 2.x, messaging is still very muc ad-hoc,
> and a lot of customization is necessary. so, you can consider open
> source a really big advantage in this respect.
> However, if you don't consider cost as a problem, then i should say that
> i really liked interfaceware solution.
> regards
>
> Seref
>
>
> Stefan Turalski wrote:
>
> > Hi,
> >
> > In a next few days I should summarize my evaluation of HAPI and I
> > should compare it with another HL7 router / interfaces / engines /
> > mappers / whatsoever.
> >
> > How do you think should I be aware of any existing comparisons, or
> > would you like to propose some tool ?
> >
> > I'm doing such a comparison because it my be inconvenient for us to
> > use open source project code.
> > In real world the MPL in case of something like HL7 (you have the
> > logic of your app in message processing code) just may don't work :(
> >
> > Definitely I'll compare HAPI to the BizTalk, and may be to the Orion
> > Symphonia, should I take an other systems into account?
> >
> > In advance I would like to thank you for the advices.
> >
> > --
> > Best regards
> > Stefan Turalski
> >
> >
> > ------------------------------------------------------------------------
> > The information contained in this e-mail and in any attachments is
> > confidential and is designated solely for the attention of the
> > intended recipient(s). If you are not an intended recipient, you must
> > not use, disclose, copy, distribute or retain this e-mail or any part
> > thereof. If you have received this e-mail in error, please notify the
> > sender by return e-mail and delete all copies of this e-mail from your
> > computer system(s). Please direct any additional queries to:
> > com...@s3.... Thank You.
> > ------------------------------------------------------------------------
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >Hl7api-devel mailing list
> >Hl7...@li...
> >https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> >
> >
> >------------------------------------------------------------------------
> >
> >No virus found in this incoming message.
> >Checked by AVG Free Edition.
> >Version: 7.1.394 / Virus Database: 268.8.3/358 - Release Date: 6/7/2006
> >
> >
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.8.3/358 - Release Date: 6/7/2006
>
>
>
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>

Re: [HAPI-devel] HAPI and other HL7 middlewares...

[Seref A. <ser...@ku...>]

Hi there,
Well, there are many products for hl7 related functionality, ranging 
from delphi components to biztalk(i remember saying ouch when i heard 
the licence cost:). Seebeyond has a pretty good product for hl7, dicom 
and custom messaging(which is owned by Sun microsystems at the moment)
Chameleon by interfaceware is really good, but for all these products, 
there is a considerable amount of licence cost, and also when it comes 
to hl7 messaging, i found being able to hack source code, and very 
valuable asset. Especially for 2.x, messaging is still very muc ad-hoc, 
and a lot of customization is necessary. so, you can consider open 
source a really big advantage in this respect.
However, if you don't consider cost as a problem, then i should say that 
i really liked interfaceware solution.
regards

Seref


Stefan Turalski wrote:

> Hi,
>
> In a next few days I should summarize my evaluation of HAPI and I 
> should compare it with another HL7 router / interfaces / engines / 
> mappers / whatsoever.
>
> How do you think should I be aware of any existing comparisons, or 
> would you like to propose some tool ?
>
> I'm doing such a comparison because it my be inconvenient for us to 
> use open source project code.
> In real world the MPL in case of something like HL7 (you have the 
> logic of your app in message processing code) just may don't work :(
>
> Definitely I'll compare HAPI to the BizTalk, and may be to the Orion 
> Symphonia, should I take an other systems into account?
>
> In advance I would like to thank you for the advices.
>
> -- 
> Best regards
> Stefan Turalski
>
>
> ------------------------------------------------------------------------
> The information contained in this e-mail and in any attachments is 
> confidential and is designated solely for the attention of the 
> intended recipient(s). If you are not an intended recipient, you must 
> not use, disclose, copy, distribute or retain this e-mail or any part 
> thereof. If you have received this e-mail in error, please notify the 
> sender by return e-mail and delete all copies of this e-mail from your 
> computer system(s). Please direct any additional queries to: 
> com...@s3.... Thank You.
> ------------------------------------------------------------------------
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Hl7api-devel mailing list
>Hl7...@li...
>https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>  
>
>------------------------------------------------------------------------
>
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.1.394 / Virus Database: 268.8.3/358 - Release Date: 6/7/2006
>  
>



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.3/358 - Release Date: 6/7/2006

[HAPI-devel] HAPI and other HL7 middlewares...

[Stefan T. <ste...@s3...>]

Hi,

In a next few days I should summarize my evaluation of HAPI and I should
compare it with another HL7 router / interfaces / engines / mappers /
whatsoever. 
How do you think should I be aware of any existing comparisons, or would you
like to propose some tool ? 

I'm doing such a comparison because it my be inconvenient for us to use open
source project code.
In real world the MPL in case of something like HL7 (you have the logic of
your app in message processing code) just may don't work :(

Definitely I'll compare HAPI to the BizTalk, and may be to the Orion
Symphonia, should I take an other systems into account?

In advance I would like to thank you for the advices.

--
Best regards
Stefan Turalski


The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: com...@s3....
Thank You.

Re: [HAPI-devel] A question about something like HD.setValue()

[Bryan T. <bp...@gm...>]

Hi Stefan,

OK, I think I understand. For write protection you will have to change
code, although you could do it at the AbstractPrimitive level without
much trouble.

For convenient copying of field values, I'd suggest Terser instead of
adding setValue() to Type, but do whatever you find convenient.

Bryan

On 6/5/06, Stefan Turalski <ste...@s3...> wrote:
> Hi Bryan,
>
> Indeed, in some cases I would like to write-protect the field. As you wrote
> the Type or AbstractType don't have setValue method for the reason. In case
> when HAPI user know exactly that he would like to overwrite whole field at
> once, he (me) could remove the write protection at Type level, in that way
> only in this case he could write the whole field.
>
> You see, I prefer to have a strong mapping between the MSH-10 in inbound
> message and MSA-2 in outbound message, and as these are Primitive(s) the
> mapping is quite easy to write. Thus I would like to re-use the same
> architecture for mapping between the fields of type Type. So I would need a
> method setValue on the Type level.
>
> I hope that this time it is clearer, if it isn't please feel free to ask
> more question.. Maybe my decisions are wrong and I would be glad to know
> about that :-)
>
> --
> Best regards,
> Stefan
>
> ps. of course to the method that sets the field the logic how to get / parse
> / validate values from 'in' parameter should be passed to the 'out' filed.
> And then on the Type level the setValue message is rather abstract one, but
> could be easily extended in the specific implementation. So in case of, for
> example, HD type, there could be additional type that inherits after HD,
> name it MSH_3 / MSH_4 / MSH_5 ... In this specific implementations the
> mapping would be done. That is basically what I already started to do ...
>
> > -----Original Message-----
> > From: Bryan Tripp [mailto:bp...@gm...]
> > Sent: Sunday, June 04, 2006 6:01 PM
> > To: ste...@s3...
> > Cc: hl7...@li...
> > Subject: Re: [HAPI-devel] A question about something like
> > HD.setValue()
> >
> > Hi Stefan,
> >
> > I'm not sure I understand the issue. Is it that you want to
> > write-protect fields in some circumstances (by setting your
> > canSetValue flag to false)? Or is it that you want setValue()
> > implemented at the Type level instead of the Primitive level? Or both?
> >
> > The reason Type and AbstractType don't have setValue() is
> > that the types may be composites, or even composites of
> > composites (so you would need setValue(index) and
> > setValue(index, index) as well, but these wouldn't make sense
> > for Primitive types). When you set values using Terser, if no
> > subcomponent is specified and the Type is in fact Composite,
> > then it's assumed that you want to set the first component.
> >
> > Bryan
> >
> > On 6/1/06, Stefan Turalski <ste...@s3...> wrote:
> > >
> > >
> > >
> > > Hi,
> > >
> > > In some specific cases I think that it makes sense to have setValue
> > > method on the level of AbstractType.
> > > e.g the MSH-5 and MSH-6 fields are almost in all cases just
> > retrieved
> > > from inbound message and passed to the outbound message.
> > >
> > > I know that this works only in context of specific types
> > and methods (e.g.
> > > the HD.setValue has sense only after the
> > getReceivingApplication call).
> > >
> > > What I did is that I added additional variable to the HD class that
> > > stores the information if setValue is allowed.
> > > I set it as true in the MSH class implementation of
> > > getReceivingApplication method.
> > >
> > > Then I call the setValue
> > > out.getMSH().getReceivingApplication().setValue(
> > > in.getMSH().getSendingApplication() );
> > >
> > > As you may assume at the end of setValue I set the
> > canSetValue to false.
> > >
> > > The problem I faced is multithreading - but right now
> > decided to not
> > > bother with that..
> > >
> > > So, what do you think about that, should it be done in
> > other way / do
> > > you see any other potential bugs / problems that will arise
> > after such
> > > a wrapping?
> > >
> > > --
> > > Best regards
> > > Stefan Turalski
> > > ________________________________
> > > The information contained in this e-mail and in any attachments is
> > > confidential and is designated solely for the attention of the
> > > intended recipient(s). If you are not an intended
> > recipient, you must
> > > not use, disclose, copy, distribute or retain this e-mail
> > or any part
> > > thereof. If you have received this e-mail in error, please
> > notify the
> > > sender by return e-mail and delete all copies of this
> > e-mail from your computer system(s).
> > > Please direct any additional queries to:
> > com...@s3....
> > > Thank You.
> > > ________________________________
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Hl7api-devel mailing list
> > > Hl7...@li...
> > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> > >
> > >
> > >
> >
>
>
> The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
> Please direct any additional queries to: com...@s3....
> Thank You.
>

Re: [HAPI-devel] The most convenient way to handle query stored in the QPD

[Nico V. <ni...@sk...>]

Hi Bryan, Stefan,

A query parameter list like "@PID5.1^thename^@PID5.2^xxxx" is not IHE specific.

It's part of the HL7 standard - see QIP datatype (query input parameter 
list) or Q22 event in chapter 3 for more info.

Regards

Nico

At 5/06/2006, Bryan Tripp wrote:
>Hi Stefan,
>
>I'm not familiar with that syntax. I don't think it's part of the HL7
>standard, but maybe it's standard for IHE.
>
>Does anyone else know?
>
>Thanks,
>Bryan
>
>On 6/5/06, Stefan Turalski <ste...@s3...> wrote:
> > Hi Bryan,
> >
> > Thank you for your answer. Thanks to your suggestion I hope that I 
> avoided a
> > lot of messy code.
> >
> > However, I would like to ask another question then... In the IHE's MESA
> > tests cases there is a QPD query that looks somehow like this
> > "@PID5.1^thename^@PID5.2^xxxx". Basing on your experience, is it a common
> > way to formulize a query in HL7 and should I bother to write a common class
> > (sort of parser) for that, or the syntax of queries is rather different in
> > each particular HL7 enabled system?
> >
> > --
> > Best regards,
> > stefan
> >
> > > -----Original Message-----
> > > From: Bryan Tripp [mailto:bp...@gm...]
> > > Sent: Sunday, June 04, 2006 6:07 PM
> > > To: ste...@s3...
> > > Cc: hl7...@li...
> > > Subject: Re: [HAPI-devel] The most convenient way to handle
> > > query stored in the QPD
> > >
> > > Hi Stefan,
> > >
> > > Terser is the best way. The types of fields 3 and up on a QPD
> > > depend entirely on the query, so Varies has to be used. You
> > > can deal with the Varies fields directly if you like, but the
> > > code can get ugly. Terser makes it transparent.
> > >
> > > Bryan
> > >
> > > On 6/2/06, Stefan Turalski <ste...@s3...> wrote:
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > In the HAPI structure that represents the QPD (2.5) segment
> > > there is
> > > > only support up to QPD-3 field, should I retrieve all other fields'
> > > > data using Terser ?
> > > >
> > > > In other words, Is there a generic way to retrieve data
> > > from the User
> > > > Parameters field (QPD-3) that is of Varies type,  or the
> > > Terser is the
> > > > only way to get these data?
> > > >
> > > > --
> > > > Best regards,
> > > > Stefan
> > > > ________________________________
> > > > The information contained in this e-mail and in any attachments is
> > > > confidential and is designated solely for the attention of the
> > > > intended recipient(s). If you are not an intended
> > > recipient, you must
> > > > not use, disclose, copy, distribute or retain this e-mail
> > > or any part
> > > > thereof. If you have received this e-mail in error, please
> > > notify the
> > > > sender by return e-mail and delete all copies of this
> > > e-mail from your computer system(s).
> > > > Please direct any additional queries to:
> > > com...@s3....
> > > > Thank You.
> > > > ________________________________
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Hl7api-devel mailing list
> > > > Hl7...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> > > >
> > > >
> > > >
> > >
> >
> >
> > The information contained in this e-mail and in any attachments is 
> confidential and is designated solely for the attention of the intended 
> recipient(s). If you are not an intended recipient, you must not use, 
> disclose, copy, distribute or retain this e-mail or any part thereof. If 
> you have received this e-mail in error, please notify the sender by 
> return e-mail and delete all copies of this e-mail from your computer 
> system(s).
> > Please direct any additional queries to: com...@s3....
> > Thank You.
> >
>
>
>_______________________________________________
>Hl7api-devel mailing list
>Hl7...@li...
>https://lists.sourceforge.net/lists/listinfo/hl7api-devel

Re: [HAPI-devel] The most convenient way to handle query stored in the QPD

[Stefan T. <ste...@s3...>]

Hi Nico,

You are completely right about the QIP data type. But as you look into the
2.5 data type description there is only an example, not a particular
explanation how this Values (in mater of fact in ST data type) should be
parsed (e.g. the IHE ITI TF-2 in table 3.21-3 list all the important
fields).

That is why I asked about the @PID.5.1^FamilyName... In the HL7 you have a
PID (Patient Identification Segment) and I know that the @PID.5.1 points to
the PID-5's (Patient Name (XPN)) first component (Family Name (FN)) (and so
one).

The problem is: Should I build a parser that get the QPD-3 field, cast it to
the QIP, then parse the QIP-2 as some kind of query. Basing on this query
should I prepare a new PID instance for which I would look for match in my
system. 
Or.
Is there already something that do it in HAPI, and as I've seen there is no
such a support in HAPI. :(

Hopes that's explain my problem (that already gone, I manage to parse it).

--
Best regards,
stefan

> -----Original Message-----
> From: Nico Vannieuwenhuyze [mailto:ni...@sk...] 
> Sent: Thursday, June 08, 2006 10:03 AM
> To: Bryan Tripp; ste...@s3...
> Cc: hl7...@li...
> Subject: Re: [HAPI-devel] The most convenient way to handle 
> query stored in the QPD
> 
> Hi Bryan, Stefan,
> 
> A query parameter list like "@PID5.1^thename^@PID5.2^xxxx" is 
> not IHE specific.
> 
> It's part of the HL7 standard - see QIP datatype (query input 
> parameter
> list) or Q22 event in chapter 3 for more info.
> 
> Regards
> 
> Nico
> 
> At 5/06/2006, Bryan Tripp wrote:
> >Hi Stefan,
> >
> >I'm not familiar with that syntax. I don't think it's part 
> of the HL7 
> >standard, but maybe it's standard for IHE.
> >
> >Does anyone else know?
> >
> >Thanks,
> >Bryan
> >
> >On 6/5/06, Stefan Turalski <ste...@s3...> wrote:
> > > Hi Bryan,
> > >
> > > Thank you for your answer. Thanks to your suggestion I hope that I
> > avoided a
> > > lot of messy code.
> > >
> > > However, I would like to ask another question then... In 
> the IHE's 
> > > MESA tests cases there is a QPD query that looks somehow 
> like this 
> > > "@PID5.1^thename^@PID5.2^xxxx". Basing on your 
> experience, is it a 
> > > common way to formulize a query in HL7 and should I 
> bother to write 
> > > a common class (sort of parser) for that, or the syntax 
> of queries 
> > > is rather different in each particular HL7 enabled system?
> > >
> > > --
> > > Best regards,
> > > stefan
> > >
> > > > -----Original Message-----
> > > > From: Bryan Tripp [mailto:bp...@gm...]
> > > > Sent: Sunday, June 04, 2006 6:07 PM
> > > > To: ste...@s3...
> > > > Cc: hl7...@li...
> > > > Subject: Re: [HAPI-devel] The most convenient way to 
> handle query 
> > > > stored in the QPD
> > > >
> > > > Hi Stefan,
> > > >
> > > > Terser is the best way. The types of fields 3 and up on a QPD 
> > > > depend entirely on the query, so Varies has to be used. You can 
> > > > deal with the Varies fields directly if you like, but 
> the code can 
> > > > get ugly. Terser makes it transparent.
> > > >
> > > > Bryan
> > > >
> > > > On 6/2/06, Stefan Turalski <ste...@s3...> wrote:
> > > > >
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > In the HAPI structure that represents the QPD (2.5) segment
> > > > there is
> > > > > only support up to QPD-3 field, should I retrieve all 
> other fields'
> > > > > data using Terser ?
> > > > >
> > > > > In other words, Is there a generic way to retrieve data
> > > > from the User
> > > > > Parameters field (QPD-3) that is of Varies type,  or the
> > > > Terser is the
> > > > > only way to get these data?
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Stefan
> > > > > ________________________________ The information contained in 
> > > > > this e-mail and in any attachments is confidential and is 
> > > > > designated solely for the attention of the intended 
> > > > > recipient(s). If you are not an intended
> > > > recipient, you must
> > > > > not use, disclose, copy, distribute or retain this e-mail
> > > > or any part
> > > > > thereof. If you have received this e-mail in error, please
> > > > notify the
> > > > > sender by return e-mail and delete all copies of this
> > > > e-mail from your computer system(s).
> > > > > Please direct any additional queries to:
> > > > com...@s3....
> > > > > Thank You.
> > > > > ________________________________
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Hl7api-devel mailing list
> > > > > Hl7...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > > The information contained in this e-mail and in any attachments is
> > confidential and is designated solely for the attention of the 
> > intended recipient(s). If you are not an intended 
> recipient, you must 
> > not use, disclose, copy, distribute or retain this e-mail 
> or any part 
> > thereof. If you have received this e-mail in error, please 
> notify the 
> > sender by return e-mail and delete all copies of this 
> e-mail from your 
> > computer system(s).
> > > Please direct any additional queries to: 
> com...@s3....
> > > Thank You.
> > >
> >
> >
> >_______________________________________________
> >Hl7api-devel mailing list
> >Hl7...@li...
> >https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> 
> 
> 


The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: com...@s3....
Thank You.

Re: [HAPI-devel] The most convenient way to handle query stored in the QPD

[Bryan T. <bp...@gm...>]

Hi Stefan,

I'm not familiar with that syntax. I don't think it's part of the HL7
standard, but maybe it's standard for IHE.

Does anyone else know?

Thanks,
Bryan

On 6/5/06, Stefan Turalski <ste...@s3...> wrote:
> Hi Bryan,
>
> Thank you for your answer. Thanks to your suggestion I hope that I avoided a
> lot of messy code.
>
> However, I would like to ask another question then... In the IHE's MESA
> tests cases there is a QPD query that looks somehow like this
> "@PID5.1^thename^@PID5.2^xxxx". Basing on your experience, is it a common
> way to formulize a query in HL7 and should I bother to write a common class
> (sort of parser) for that, or the syntax of queries is rather different in
> each particular HL7 enabled system?
>
> --
> Best regards,
> stefan
>
> > -----Original Message-----
> > From: Bryan Tripp [mailto:bp...@gm...]
> > Sent: Sunday, June 04, 2006 6:07 PM
> > To: ste...@s3...
> > Cc: hl7...@li...
> > Subject: Re: [HAPI-devel] The most convenient way to handle
> > query stored in the QPD
> >
> > Hi Stefan,
> >
> > Terser is the best way. The types of fields 3 and up on a QPD
> > depend entirely on the query, so Varies has to be used. You
> > can deal with the Varies fields directly if you like, but the
> > code can get ugly. Terser makes it transparent.
> >
> > Bryan
> >
> > On 6/2/06, Stefan Turalski <ste...@s3...> wrote:
> > >
> > >
> > >
> > > Hi,
> > >
> > > In the HAPI structure that represents the QPD (2.5) segment
> > there is
> > > only support up to QPD-3 field, should I retrieve all other fields'
> > > data using Terser ?
> > >
> > > In other words, Is there a generic way to retrieve data
> > from the User
> > > Parameters field (QPD-3) that is of Varies type,  or the
> > Terser is the
> > > only way to get these data?
> > >
> > > --
> > > Best regards,
> > > Stefan
> > > ________________________________
> > > The information contained in this e-mail and in any attachments is
> > > confidential and is designated solely for the attention of the
> > > intended recipient(s). If you are not an intended
> > recipient, you must
> > > not use, disclose, copy, distribute or retain this e-mail
> > or any part
> > > thereof. If you have received this e-mail in error, please
> > notify the
> > > sender by return e-mail and delete all copies of this
> > e-mail from your computer system(s).
> > > Please direct any additional queries to:
> > com...@s3....
> > > Thank You.
> > > ________________________________
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Hl7api-devel mailing list
> > > Hl7...@li...
> > > https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> > >
> > >
> > >
> >
>
>
> The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
> Please direct any additional queries to: com...@s3....
> Thank You.
>

Re: [HAPI-devel] message problem

[Bryan T. <bp...@gm...>]

Hi Kurtis,

When you create the ACK message do you set the value of MSH-1? This
and a few other fields are required. Feel free to use the static
method DefaultApplication.makeACK(...), which fills in the basics
automatically.

Bryan

On 6/4/06, Kurtis Fraser <fra...@uc...> wrote:
> I am currently developing client and server programs using HAPI.  For the
> server, I am using SimpleServer.  Basically what I want from the server
> side, is to simply display the message to a text box that I have in my GUI
> and then send an ACK.  I have a class that implements application (and I
> register this with the server), and in processMessage I encode the message
> received and display it to the text box and then I return an ACK message.
> This is where the problem comes in, I always get the following error:
>
> ERROR [Thread-7:ca.uhn.hl7v2.app.Responder]: Attempting to send error
> message to remote system.
> ca.uhn.hl7v2.HL7Exception: Can't encode message: MSH-1 (field separator)
> is missing
>        at ca.uhn.hl7v2.parser.PipeParser.encode(PipeParser.java:499)
>        at ca.uhn.hl7v2.parser.PipeParser.encode(PipeParser.java:484)
>        at ca.uhn.hl7v2.app.Responder.processMessage(Responder.java:162)
>        at ca.uhn.hl7v2.app.Receiver$Grunt.run(Receiver.java:121)
>
> Any help would be appreciated..
>
> -Kurtis
>
>
>
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>

Re: [HAPI-devel] message problem

[Miguel R. <mro...@gm...>]

hi kurtis, as the error message is saying you need to define the  field
separator for your message, for example:

protected static String FLD_SEP = "|";
protected static String ENC_CHAR = "^~\\&";
protected static String APL_ENV = "MedSys";

ADT_A01 creaCtaPac = new ADT_A01();

//field separator
creaCtaPac.getMSH().getFieldSeparator().setValue(FLD_SEP);
//encoding chars
creaCtaPac.getMSH().getEncodingCharacters().setValue(ENC_CHAR);
//sending app
creaCtaPac.getMSH
().getSendingApplication().getNamespaceID().setValue(APL_ENV);
//sending site
      creaCtaPac.getMSH().getSendingFacility().getNamespaceID().setValue(
estacion.getName());
//destination app
creaCtaPac.getMSH
().getReceivingApplication().getNamespaceID().setValue(APL_REC);
//destination site
creaCtaPac.getMSH().getReceivingFacility().getNamespaceID().setValue("");
//event date time
creaCtaPac.getMSH().getDateTimeOfMessage().getTimeOfAnEvent().setValue(
   FECHA_HL7.format(Calendar.getInstance().getTime())
);
//security info
creaCtaPac.getMSH().getSecurity().setValue("");
//message type
creaCtaPac.getMSH().getMessageType().getMessageType().setValue("ADT");
creaCtaPac.getMSH().getMessageType().getTriggerEvent().setValue("A01");
        hope this helps

greetings

On 6/4/06, Kurtis Fraser <fra...@uc...> wrote:
>
> I am currently developing client and server programs using HAPI.  For the
> server, I am using SimpleServer.  Basically what I want from the server
> side, is to simply display the message to a text box that I have in my GUI
> and then send an ACK.  I have a class that implements application (and I
> register this with the server), and in processMessage I encode the message
> received and display it to the text box and then I return an ACK message.
> This is where the problem comes in, I always get the following error:
>
> ERROR [Thread-7:ca.uhn.hl7v2.app.Responder]: Attempting to send error
> message to remote system.
> ca.uhn.hl7v2.HL7Exception: Can't encode message: MSH-1 (field separator)
> is missing
>         at ca.uhn.hl7v2.parser.PipeParser.encode(PipeParser.java:499)
>         at ca.uhn.hl7v2.parser.PipeParser.encode(PipeParser.java:484)
>         at ca.uhn.hl7v2.app.Responder.processMessage(Responder.java:162)
>         at ca.uhn.hl7v2.app.Receiver$Grunt.run(Receiver.java:121)
>
> Any help would be appreciated..
>
> -Kurtis
>
>
>
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>

[HAPI-devel] It is a bug in ca.uhn.hl7v2.model.v25.message.RSP_K21.java

[Stefan T. <ste...@s3...>]

Hi,

In the ca.uhn.hl7v2.model.v25.message.RSP_K21.java the methode
RSP_K21_QUERY_RESPONSE() has code:
ret =  (RSP_K21_QUERY_RESPONSE) this.get("QUERY_RESPONSE");

I assume it should be: 
ret =  (RSP_K21_QUERY_RESPONSE) this.get("RSP_K21_QUERY_RESPONSE"); 

Am I right?

I try to use this(which inherits over RSP_21
message).getQUERY_RESPONSE().getPID().getPatientIdentifierList() -but the
length of this list is 0.
Should I use Terser to set these values of PID or is there an another trick
to set fields like IDNumer / Patient Name and others that are under a list
of values (and are not returned as the value directly) ?

--
Best regards
stefan


The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: com...@s3....
Thank You.

Re: [HAPI-devel] The most convenient way to handle query stored in the QPD

[Bryan T. <bp...@gm...>]

Hi Stefan,

Terser is the best way. The types of fields 3 and up on a QPD depend
entirely on the query, so Varies has to be used. You can deal with the
Varies fields directly if you like, but the code can get ugly. Terser
makes it transparent.

Bryan

On 6/2/06, Stefan Turalski <ste...@s3...> wrote:
>
>
>
> Hi,
>
> In the HAPI structure that represents the QPD (2.5) segment there is only
> support up to QPD-3 field, should I retrieve all other fields' data using
> Terser ?
>
> In other words, Is there a generic way to retrieve data from the User
> Parameters field (QPD-3) that is of Varies type,  or the Terser is the only
> way to get these data?
>
> --
> Best regards,
> Stefan
> ________________________________
> The information contained in this e-mail and in any attachments is
> confidential and is designated solely for the attention of the intended
> recipient(s). If you are not an intended recipient, you must not use,
> disclose, copy, distribute or retain this e-mail or any part thereof. If you
> have received this e-mail in error, please notify the sender by return
> e-mail and delete all copies of this e-mail from your computer system(s).
> Please direct any additional queries to: com...@s3.... Thank
> You.
> ________________________________
>
>
>
>
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
>
>