hl7api-devel — developer list

[HAPI-devel] RE: log4j

[Guevara, A. <Ale...@uh...>]

replacing definitely!!
 
I was thinking about using the jakarta-commons-logging library. That way if
hapi is run using the jdk1.4, we can use the jdk logging packages.
 
alex6
 
 

-----Original Message-----
From: Leslie Mann (2147) [mailto:lm...@TA...] 
Sent: May 1, 2003 2:21 PM
To: hl7...@li...
Subject: RE: log4j



Alexei: 

Would this be adding or replacing? 

When I originally started looking at HAPI I was curious as too why there was
a custom logging solution being employed.  Personally I think that switching
the logging to log4j, or some other widely used open loggin solution, is an
excellent idea.  This would be one less thing to have to relearn.  

Leslie 

	-----Original Message----- 
From:   alexei guevara [SMTP:ale...@ho...] 
Sent:   Thursday, May 01, 2003 1:22 PM 
To:     hl7...@li... 
Subject:        [HAPI-devel] log4j 

	I'm looking into adding log4j support to hapi. Should I go and do it
or maybe there are some concerns about doing it ? 

	

	alex6 

	MailFiler <HYPERLINK "http://www.mailfiler.com"
\nhttp://www.mailfiler.com> [AG-BW1TDQ]


	---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (HYPERLINK "http://www.grisoft.com"
\nhttp://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003



---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
 


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

RE: [HAPI-devel] log4j

[Leslie M. (2147) <lm...@TA...>]

Alexei:

Would this be adding or replacing?

When I originally started looking at HAPI I was curious as too why there was
a custom logging solution being employed.  Personally I think that switching
the logging to log4j, or some other widely used open loggin solution, is an
excellent idea.  This would be one less thing to have to relearn.  

Leslie

> -----Original Message-----
> From:	alexei guevara [SMTP:ale...@ho...]
> Sent:	Thursday, May 01, 2003 1:22 PM
> To:	hl7...@li...
> Subject:	[HAPI-devel] log4j
> 
> I'm looking into adding log4j support to hapi. Should I go and do it or
> maybe there are some concerns about doing it ?
> 
>  
> 
> alex6
> 
> MailFiler <http://www.mailfiler.com> [AG-BW1TDQ]
> 
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
> 
> 

[HAPI-devel] log4j

[alexei g. <ale...@ho...>]

I=92m looking into adding log4j support to hapi. Should I go and do it =
or
maybe there are some concerns about doing it ?

=20

alex6

HYPERLINK "http://www.mailfiler.com"MailFiler [AG-BW1TDQ]

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
=20

[HAPI-devel] RE: RE: message database

[Guevara, A. <Ale...@uh...>]

std way:

//create data object from message encapsulates code
//to extract data from the msg using the std methods like //getMSH().get... 

DataObject do = createDataObjectFromMessage( msg );
sink.store( do );


using visitor:

DataObjectCreatorVisitor v = 
	new DataObjectCreatorVisitor( 
		//these are the matching rules
		new String[] {
			"MSH-9-2",
			"^PID(?:|.*?){5}(.*)|"
		}
	);	

msg.accept( v );
sink.store( v.getDataObject() );

As you can see, using the Visitor pattern is just another way to do it. One
that usually tends to be more elegant and easier to use. (the idea is that
the hapi source code generator will generate the base visitor code, and even
some core visitors, like the DataObject creator). If we'll be using the
Visitor pattern only to implement the logging feature, then most probably it
will be an overkill...




-----Original Message-----
From: Tripp, Bryan 
Sent: April 29, 2003 3:36 PM
To: Guevara, Alexei
Subject: RE: RE: message database


You're far too happy ;)  Anyway, isn't loving a pattern an anti-pattern
("Golden Hammer")?   

I still don't see it for message logging.  Maybe if you wrote some
pseudocode?  

Bryan 

> -----Original Message-----
> From: Guevara, Alexei
> Sent: April 29, 2003 3:27 PM
> To: Tripp, Bryan
> Subject: RE: RE: message database
> 
> 
> 
> 
> I like it, but for some reason I can't think of any use cases.
> Anyone?
> 
> Message logging is a good candidate, we could have different visitors,
> each to log some piece of info of the message (or the whole message) 
> ... The visitor will construct the Data Object (the one that will be 
> thrown onto the DataSink) .....
> 
> It will provide as well the foundations for a more granular message
> processing mechanism ... we could even use it to extract a very 
> specific piece of data from a message ... and so on ... on and on ... 
> I love the visitor pattern ;)
> 
> alex6
> 
> 
> 
> 
> 
> 
> www.mailfiler.com [HAPI-devel]
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
>  
> 

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
 


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

RE: [HAPI-devel] RE: message database

[Tripp, B. <Bry...@uh...>]

Hi Alexei, 

Hmm ... so this would look something like: 

MessageVisitor
+visitMessage(Message)
+visitGroup(Group)
+visitSegment(Segment)
+visitComposite(Composite)
+visitPrimitive(Primitive)

... and then we would add accept(MessageVisitor) to each message element?  

I like it, but for some reason I can't think of any use cases.  Anyone?  

Actually I don't understand how it applies to message logging.  Can you
explain further?  If we're going after specific fields, we don't have to do
any traversal, and we only really deal with leaf nodes (which are all
Strings).  If the need is to store the whole message, I think I like your
other suggestion (Hibernate) better.  Maybe I'm missing something.  

Bryan  

> -----Original Message-----
> From: Guevara, Alexei [mailto:Ale...@uh...]
> Sent: April 29, 2003 2:37 PM
> To: hl7...@li...
> Subject: [HAPI-devel] RE: message database
> 
> 
> 
> 
> That sounds good as an initial aprox. !!!
> 
> It comes to my mind that adding support for the Visitor 
> pattern to the hapi
> message classes will help a lot in this message logging 
> project and any
> other project that required the traversal of the message tree ... Any
> thought ?
> 
> alex6
> 
> -----Original Message-----
> From: Tripp, Bryan 
> Sent: April 28, 2003 3:46 PM
> To: Guevara, Alexei; 'hl7...@li...'
> Subject: RE: message database
> 
> 
> Hi Alex & Alexei, 
> 
> I'm inclined to agree.  Actually it's starting to look like a 
> relatively
> small step to generalize beyond the message -> persistent 
> storage cases.
> How about something along these lines (these are interfaces) ... 
> 
> DatumLocation 
> +getSpec() : String
> 
> DataSource
> +pull(loc: DatumLocation) : String     <-- gets a value 
> +makeLocation(spec : String) : DatumLocation      
> 
> DataSink
> +push(loc: DatumLocation, value: String)  <-- sets a value
> +makeLocation(spec : String) : DatumLocation
> 
> ** Note: spec is a source-specific string that defines an 
> item or set of
> data to be extracted (e.g. "MSH-9-2", a regular expression like
> "^PID(?:|.*?){5}(.*)|", an XPath, a method name on an EJB, etc.).
> 
> DataSource
> |-RDBSource    
> |-EJBSource
> |-XMLSource
> |-StringSource
> |-ParsedMessageSource
> |-UnparsedMessageSource
> 
> DataSink
> ... similar to sources.  
> 
> Just wanted to throw something out there ... I'm sure it can 
> be improved ...
> any ideas?  
> 
> Bryan 
> 
> 
> > -----Original Message-----
> > From: Guevara, Alexei [mailto:Ale...@uh...]
> > Sent: April 28, 2003 2:53 PM
> > To: 'hl7...@li...'
> > Subject: RE: [HAPI-devel] message database
> > 
> > 
> > JDO is a very good replacement for entity beans and there 
> are a couple
> > of open source impl. available (castor and hibernate). Most
> > people prefer to
> > use Hybernate (theoretically it's better). Besides JDO 
> could map to a
> > relational DB or to LDAP (under the covers).
> > 
> > Personally I'll prefer to create a simple framework to 
> encapsulate the 
> > mapping of HL7Msgs --> Data Repository. (simple means: no ejbs, no 
> > jdo, no jdbc). The framework will provide extension points (through
> > interfaces) to
> > accomodate such low level behavior)
> > 
> > 
> > alex6
> > 
> > -----Original Message-----
> > From: Tripp, Bryan
> > To: 'Alex Harvey'; Hapi
> > Sent: 28/04/2003 1:25 PM
> > Subject: RE: [HAPI-devel] message database
> > 
> > Hi Alex,
> >  
> > Mapping from message -> EJB just seems to me like a distinct but
> > similar task, compared to mapping from message -> RDB.  You 
> could use
> > a similar
> > approach, but if you're using EJBs I would just ignore the fact that
> > there is a RBD underneath (it could be LDAP in 6 months).  
> >  
> > Bryan
> > -----Original Message-----
> > From: Alex Harvey [mailto:al...@9p...]
> > Sent: April 28, 2003 12:55 PM
> > To: Hapi
> > Subject: RE: [HAPI-devel] message database
> > 
> > 
> > This is pretty much what I had in mind. I thought I would 
> make a few 
> > generic lookup JSP pages based on those types of fields and have a 
> > simple Struts war to deploy.
> >  
> > One question though: Database access. Should the interface class use
> > EJB or not? Our requirement is that all database access 
> goes through 
> > EJB's in our environment. Is that too heavy handed for something
> > like this or
> > maybe there's a way to abstract that out and allow a 
> replacement class
> > that uses some JDBC.
> >  
> > -----Original Message-----
> > From: Tripp, Bryan [mailto:Bry...@uh...]
> > Sent: Monday, April 28, 2003 11:45 AM
> > To: 'Alex Harvey'; Hapi
> > Subject: RE: [HAPI-devel] message database
> >  
> > Hi Alex,
> >  
> > Sounds like a great idea.  I think Abe Tio may have been working on 
> > something like this.  Did you make any progress Abe?
> >  
> > This isn't really on my radar, but I do have some thoughts on the
> > matter ... If you want a way to write arbitrary fields to arbitrary
> > tables, for
> > a variety of incoming messages, I think it would be nice to just
> > configure your tool with a map of message paths to DB fields.  For
> > example a map might contain these entries: 
> >  
> > MSH-7  ->  PatientMessages.Date
> > PID-3  ->  PatientMessage.MRN
> > TEXT  ->  PatientMessages.WholeText   
> >  
> > ... in which case your system would write MSH-7 to the Date field in
> > the PatientMessages table, etc. ("TEXT" is just meant to indicate
> > a special
> > value that gets the complete text of the message).  I think 
> that would
> > be really general and handy.  
> >  
> > Of course this is just a special case of the more general need for 
> > mapping from HL7 data sources to HL7 data sinks.  Ideally we should 
> > treat HL7 messages, databases, text files, XML documents, etc. as 
> > sources and sinks, formalize a datum path in each case (e.g. Terser 
> > path, table.field, regular expression, XPath), take over the world, 
> > etc., but message -> database is probably a very good place 
> to start.
> >  
> > Bryan
> > -----Original Message-----
> > From: Alex Harvey [mailto:al...@9p...]
> > Sent: April 28, 2003 11:49 AM
> > To: Hapi
> > Subject: [HAPI-devel] message database
> > Has anyone ever considered making a generic database to 
> track incoming
> > HL7 messages? I've been considering doing something like this for A 
> > messages to be able to easily refer back to a complete 
> message history 
> > received for a given patient. Is there anyone that would be 
> interested 
> > in collaborating on this?
> >  
> > -Alex
> > 
> > 
> > This e-mail may contain confidential and/or privileged 
> information for 
> > the sole use of the intended recipient. Any review or 
> distribution by 
> > anyone other than the person for whom it was originally intended is 
> > strictly prohibited. If you have received this e-mail in 
> error, please 
> > contact the sender and delete all copies. Opinions, conclusions or 
> > other information contained
> > in
> > this e-mail may not be that of the organization.
> > 
> > 
> > 
> > This e-mail may contain confidential and/or privileged 
> information for 
> > the sole use of the intended recipient. Any review or 
> distribution by 
> > anyone other than the person for whom it was originally intended is 
> > strictly prohibited. If you have received this e-mail in 
> error, please 
> > contact the sender and delete all copies. Opinions, conclusions or 
> > other information contained
> > in
> > this e-mail may not be that of the organization.
> > 
> > 
> > 
> > This e-mail may contain confidential and/or privileged 
> information for 
> > the sole use of the intended recipient. Any review or 
> distribution by 
> > anyone other than the person for whom it was originally intended is 
> > strictly prohibited. If you have received this e-mail in 
> error, please 
> > contact the sender and
> > delete all copies. Opinions, conclusions or other information 
> > contained in
> > this e-mail may not be that of the organization.
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf 
> > _______________________________________________
> > Hl7api-devel mailing list
> > Hl7...@li...
> > https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> > 
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
>  
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
>  
> 
> 
> This e-mail may contain confidential and/or privileged information
> for the sole use of the intended recipient. Any review or distribution
> by anyone other than the person for whom it was originally intended is
> strictly
> prohibited. If you have received this e-mail in error, please 
> contact the
> sender and
> delete all copies. Opinions, conclusions or other information 
> contained in
> this e-mail may not be that of the organization.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> 


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

[HAPI-devel] RE: message database

[Guevara, A. <Ale...@uh...>]

That sounds good as an initial aprox. !!!

It comes to my mind that adding support for the Visitor pattern to the hapi
message classes will help a lot in this message logging project and any
other project that required the traversal of the message tree ... Any
thought ?

alex6

-----Original Message-----
From: Tripp, Bryan 
Sent: April 28, 2003 3:46 PM
To: Guevara, Alexei; 'hl7...@li...'
Subject: RE: message database


Hi Alex & Alexei, 

I'm inclined to agree.  Actually it's starting to look like a relatively
small step to generalize beyond the message -> persistent storage cases.
How about something along these lines (these are interfaces) ... 

DatumLocation 
+getSpec() : String

DataSource
+pull(loc: DatumLocation) : String     <-- gets a value 
+makeLocation(spec : String) : DatumLocation      

DataSink
+push(loc: DatumLocation, value: String)  <-- sets a value
+makeLocation(spec : String) : DatumLocation

** Note: spec is a source-specific string that defines an item or set of
data to be extracted (e.g. "MSH-9-2", a regular expression like
"^PID(?:|.*?){5}(.*)|", an XPath, a method name on an EJB, etc.).

DataSource
|-RDBSource    
|-EJBSource
|-XMLSource
|-StringSource
|-ParsedMessageSource
|-UnparsedMessageSource

DataSink
... similar to sources.  

Just wanted to throw something out there ... I'm sure it can be improved ...
any ideas?  

Bryan 


> -----Original Message-----
> From: Guevara, Alexei [mailto:Ale...@uh...]
> Sent: April 28, 2003 2:53 PM
> To: 'hl7...@li...'
> Subject: RE: [HAPI-devel] message database
> 
> 
> JDO is a very good replacement for entity beans and there are a couple
> of open source impl. available (castor and hibernate). Most
> people prefer to
> use Hybernate (theoretically it's better). Besides JDO could map to a
> relational DB or to LDAP (under the covers).
> 
> Personally I'll prefer to create a simple framework to encapsulate the 
> mapping of HL7Msgs --> Data Repository. (simple means: no ejbs, no 
> jdo, no jdbc). The framework will provide extension points (through
> interfaces) to
> accomodate such low level behavior)
> 
> 
> alex6
> 
> -----Original Message-----
> From: Tripp, Bryan
> To: 'Alex Harvey'; Hapi
> Sent: 28/04/2003 1:25 PM
> Subject: RE: [HAPI-devel] message database
> 
> Hi Alex,
>  
> Mapping from message -> EJB just seems to me like a distinct but
> similar task, compared to mapping from message -> RDB.  You could use
> a similar
> approach, but if you're using EJBs I would just ignore the fact that
> there is a RBD underneath (it could be LDAP in 6 months).  
>  
> Bryan
> -----Original Message-----
> From: Alex Harvey [mailto:al...@9p...]
> Sent: April 28, 2003 12:55 PM
> To: Hapi
> Subject: RE: [HAPI-devel] message database
> 
> 
> This is pretty much what I had in mind. I thought I would make a few 
> generic lookup JSP pages based on those types of fields and have a 
> simple Struts war to deploy.
>  
> One question though: Database access. Should the interface class use
> EJB or not? Our requirement is that all database access goes through 
> EJB's in our environment. Is that too heavy handed for something
> like this or
> maybe there's a way to abstract that out and allow a replacement class
> that uses some JDBC.
>  
> -----Original Message-----
> From: Tripp, Bryan [mailto:Bry...@uh...]
> Sent: Monday, April 28, 2003 11:45 AM
> To: 'Alex Harvey'; Hapi
> Subject: RE: [HAPI-devel] message database
>  
> Hi Alex,
>  
> Sounds like a great idea.  I think Abe Tio may have been working on 
> something like this.  Did you make any progress Abe?
>  
> This isn't really on my radar, but I do have some thoughts on the
> matter ... If you want a way to write arbitrary fields to arbitrary
> tables, for
> a variety of incoming messages, I think it would be nice to just
> configure your tool with a map of message paths to DB fields.  For
> example a map might contain these entries: 
>  
> MSH-7  ->  PatientMessages.Date
> PID-3  ->  PatientMessage.MRN
> TEXT  ->  PatientMessages.WholeText   
>  
> ... in which case your system would write MSH-7 to the Date field in
> the PatientMessages table, etc. ("TEXT" is just meant to indicate
> a special
> value that gets the complete text of the message).  I think that would
> be really general and handy.  
>  
> Of course this is just a special case of the more general need for 
> mapping from HL7 data sources to HL7 data sinks.  Ideally we should 
> treat HL7 messages, databases, text files, XML documents, etc. as 
> sources and sinks, formalize a datum path in each case (e.g. Terser 
> path, table.field, regular expression, XPath), take over the world, 
> etc., but message -> database is probably a very good place to start.
>  
> Bryan
> -----Original Message-----
> From: Alex Harvey [mailto:al...@9p...]
> Sent: April 28, 2003 11:49 AM
> To: Hapi
> Subject: [HAPI-devel] message database
> Has anyone ever considered making a generic database to track incoming
> HL7 messages? I've been considering doing something like this for A 
> messages to be able to easily refer back to a complete message history 
> received for a given patient. Is there anyone that would be interested 
> in collaborating on this?
>  
> -Alex
> 
> 
> This e-mail may contain confidential and/or privileged information for 
> the sole use of the intended recipient. Any review or distribution by 
> anyone other than the person for whom it was originally intended is 
> strictly prohibited. If you have received this e-mail in error, please 
> contact the sender and delete all copies. Opinions, conclusions or 
> other information contained
> in
> this e-mail may not be that of the organization.
> 
> 
> 
> This e-mail may contain confidential and/or privileged information for 
> the sole use of the intended recipient. Any review or distribution by 
> anyone other than the person for whom it was originally intended is 
> strictly prohibited. If you have received this e-mail in error, please 
> contact the sender and delete all copies. Opinions, conclusions or 
> other information contained
> in
> this e-mail may not be that of the organization.
> 
> 
> 
> This e-mail may contain confidential and/or privileged information for 
> the sole use of the intended recipient. Any review or distribution by 
> anyone other than the person for whom it was originally intended is 
> strictly prohibited. If you have received this e-mail in error, please 
> contact the sender and
> delete all copies. Opinions, conclusions or other information 
> contained in
> this e-mail may not be that of the organization.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf 
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> 

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
 


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

RE: [HAPI-devel] message database

[Tripp, B. <Bry...@uh...>]

Hi Alex & Alexei, 

I'm inclined to agree.  Actually it's starting to look like a relatively
small step to generalize beyond the message -> persistent storage cases.
How about something along these lines (these are interfaces) ... 

DatumLocation 
+getSpec() : String

DataSource
+pull(loc: DatumLocation) : String     <-- gets a value 
+makeLocation(spec : String) : DatumLocation      

DataSink
+push(loc: DatumLocation, value: String)  <-- sets a value 
+makeLocation(spec : String) : DatumLocation 

** Note: spec is a source-specific string that defines an item or set of
data to be extracted (e.g. "MSH-9-2", a regular expression like
"^PID(?:|.*?){5}(.*)|", an XPath, a method name on an EJB, etc.).

DataSource
|-RDBSource    
|-EJBSource
|-XMLSource
|-StringSource
|-ParsedMessageSource
|-UnparsedMessageSource

DataSink
... similar to sources.  

Just wanted to throw something out there ... I'm sure it can be improved ...
any ideas?  

Bryan 


> -----Original Message-----
> From: Guevara, Alexei [mailto:Ale...@uh...]
> Sent: April 28, 2003 2:53 PM
> To: 'hl7...@li...'
> Subject: RE: [HAPI-devel] message database
> 
> 
> JDO is a very good replacement for entity beans and there are 
> a couple of
> open source impl. available (castor and hibernate). Most 
> people prefer to
> use Hybernate (theoretically it's better). Besides JDO could map to a
> relational DB or to LDAP (under the covers).
> 
> Personally I'll prefer to create a simple framework to encapsulate the
> mapping of HL7Msgs --> Data Repository. (simple means: no 
> ejbs, no jdo, no
> jdbc). The framework will provide extension points (through 
> interfaces) to
> accomodate such low level behavior)
> 
> 
> alex6
> 
> -----Original Message-----
> From: Tripp, Bryan
> To: 'Alex Harvey'; Hapi
> Sent: 28/04/2003 1:25 PM
> Subject: RE: [HAPI-devel] message database
> 
> Hi Alex, 
>  
> Mapping from message -> EJB just seems to me like a distinct 
> but similar
> task, compared to mapping from message -> RDB.  You could use 
> a similar
> approach, but if you're using EJBs I would just ignore the fact that
> there is a RBD underneath (it could be LDAP in 6 months).  
>  
> Bryan 
> -----Original Message-----
> From: Alex Harvey [mailto:al...@9p...]
> Sent: April 28, 2003 12:55 PM
> To: Hapi
> Subject: RE: [HAPI-devel] message database
> 
> 
> This is pretty much what I had in mind. I thought I would make a few
> generic lookup JSP pages based on those types of fields and have a
> simple Struts war to deploy.
>  
> One question though: Database access. Should the interface 
> class use EJB
> or not? Our requirement is that all database access goes through EJB's
> in our environment. Is that too heavy handed for something 
> like this or
> maybe there's a way to abstract that out and allow a replacement class
> that uses some JDBC.
>  
> -----Original Message-----
> From: Tripp, Bryan [mailto:Bry...@uh...]
> Sent: Monday, April 28, 2003 11:45 AM
> To: 'Alex Harvey'; Hapi
> Subject: RE: [HAPI-devel] message database
>  
> Hi Alex, 
>  
> Sounds like a great idea.  I think Abe Tio may have been working on
> something like this.  Did you make any progress Abe?  
>  
> This isn't really on my radar, but I do have some thoughts on 
> the matter
> ... If you want a way to write arbitrary fields to arbitrary 
> tables, for
> a variety of incoming messages, I think it would be nice to just
> configure your tool with a map of message paths to DB fields.  For
> example a map might contain these entries: 
>  
> MSH-7  ->  PatientMessages.Date
> PID-3  ->  PatientMessage.MRN
> TEXT  ->  PatientMessages.WholeText   
>  
> ... in which case your system would write MSH-7 to the Date 
> field in the
> PatientMessages table, etc. ("TEXT" is just meant to indicate 
> a special
> value that gets the complete text of the message).  I think that would
> be really general and handy.  
>  
> Of course this is just a special case of the more general need for
> mapping from HL7 data sources to HL7 data sinks.  Ideally we should
> treat HL7 messages, databases, text files, XML documents, etc. as
> sources and sinks, formalize a datum path in each case (e.g. Terser
> path, table.field, regular expression, XPath), take over the world,
> etc., but message -> database is probably a very good place 
> to start.  
>  
> Bryan 
> -----Original Message-----
> From: Alex Harvey [mailto:al...@9p...]
> Sent: April 28, 2003 11:49 AM
> To: Hapi
> Subject: [HAPI-devel] message database
> Has anyone ever considered making a generic database to track incoming
> HL7 messages? I've been considering doing something like this for A
> messages to be able to easily refer back to a complete message history
> received for a given patient. Is there anyone that would be interested
> in collaborating on this?
>  
> -Alex
> 
> 
> This e-mail may contain confidential and/or privileged information
> for the sole use of the intended recipient. Any review or distribution
> by anyone other than the person for whom it was originally intended is
> strictly
> prohibited. If you have received this e-mail in error, please contact
> the sender and
> delete all copies. Opinions, conclusions or other information 
> contained
> in
> this e-mail may not be that of the organization.
> 
> 
> 
> This e-mail may contain confidential and/or privileged information
> for the sole use of the intended recipient. Any review or distribution
> by anyone other than the person for whom it was originally intended is
> strictly
> prohibited. If you have received this e-mail in error, please contact
> the sender and
> delete all copies. Opinions, conclusions or other information 
> contained
> in
> this e-mail may not be that of the organization.
> 
> 
> 
> This e-mail may contain confidential and/or privileged information
> for the sole use of the intended recipient. Any review or distribution
> by anyone other than the person for whom it was originally intended is
> strictly
> prohibited. If you have received this e-mail in error, please 
> contact the
> sender and
> delete all copies. Opinions, conclusions or other information 
> contained in
> this e-mail may not be that of the organization.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> 


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

RE: [HAPI-devel] message database

[Guevara, A. <Ale...@uh...>]

JDO is a very good replacement for entity beans and there are a couple of
open source impl. available (castor and hibernate). Most people prefer to
use Hybernate (theoretically it's better). Besides JDO could map to a
relational DB or to LDAP (under the covers).

Personally I'll prefer to create a simple framework to encapsulate the
mapping of HL7Msgs --> Data Repository. (simple means: no ejbs, no jdo, no
jdbc). The framework will provide extension points (through interfaces) to
accomodate such low level behavior)


alex6

-----Original Message-----
From: Tripp, Bryan
To: 'Alex Harvey'; Hapi
Sent: 28/04/2003 1:25 PM
Subject: RE: [HAPI-devel] message database

Hi Alex, 
 
Mapping from message -> EJB just seems to me like a distinct but similar
task, compared to mapping from message -> RDB.  You could use a similar
approach, but if you're using EJBs I would just ignore the fact that
there is a RBD underneath (it could be LDAP in 6 months).  
 
Bryan 
-----Original Message-----
From: Alex Harvey [mailto:al...@9p...]
Sent: April 28, 2003 12:55 PM
To: Hapi
Subject: RE: [HAPI-devel] message database


This is pretty much what I had in mind. I thought I would make a few
generic lookup JSP pages based on those types of fields and have a
simple Struts war to deploy.
 
One question though: Database access. Should the interface class use EJB
or not? Our requirement is that all database access goes through EJB's
in our environment. Is that too heavy handed for something like this or
maybe there's a way to abstract that out and allow a replacement class
that uses some JDBC.
 
-----Original Message-----
From: Tripp, Bryan [mailto:Bry...@uh...]
Sent: Monday, April 28, 2003 11:45 AM
To: 'Alex Harvey'; Hapi
Subject: RE: [HAPI-devel] message database
 
Hi Alex, 
 
Sounds like a great idea.  I think Abe Tio may have been working on
something like this.  Did you make any progress Abe?  
 
This isn't really on my radar, but I do have some thoughts on the matter
... If you want a way to write arbitrary fields to arbitrary tables, for
a variety of incoming messages, I think it would be nice to just
configure your tool with a map of message paths to DB fields.  For
example a map might contain these entries: 
 
MSH-7  ->  PatientMessages.Date
PID-3  ->  PatientMessage.MRN
TEXT  ->  PatientMessages.WholeText   
 
... in which case your system would write MSH-7 to the Date field in the
PatientMessages table, etc. ("TEXT" is just meant to indicate a special
value that gets the complete text of the message).  I think that would
be really general and handy.  
 
Of course this is just a special case of the more general need for
mapping from HL7 data sources to HL7 data sinks.  Ideally we should
treat HL7 messages, databases, text files, XML documents, etc. as
sources and sinks, formalize a datum path in each case (e.g. Terser
path, table.field, regular expression, XPath), take over the world,
etc., but message -> database is probably a very good place to start.  
 
Bryan 
-----Original Message-----
From: Alex Harvey [mailto:al...@9p...]
Sent: April 28, 2003 11:49 AM
To: Hapi
Subject: [HAPI-devel] message database
Has anyone ever considered making a generic database to track incoming
HL7 messages? I've been considering doing something like this for A
messages to be able to easily refer back to a complete message history
received for a given patient. Is there anyone that would be interested
in collaborating on this?
 
-Alex


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact
the sender and
delete all copies. Opinions, conclusions or other information contained
in
this e-mail may not be that of the organization.



This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact
the sender and
delete all copies. Opinions, conclusions or other information contained
in
this e-mail may not be that of the organization.



This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

RE: [HAPI-devel] message database

[Tripp, B. <Bry...@uh...>]

Hi Alex, 
 
Mapping from message -> EJB just seems to me like a distinct but similar
task, compared to mapping from message -> RDB.  You could use a similar
approach, but if you're using EJBs I would just ignore the fact that there
is a RBD underneath (it could be LDAP in 6 months).  
 
Bryan 
-----Original Message-----
From: Alex Harvey [mailto:al...@9p...]
Sent: April 28, 2003 12:55 PM
To: Hapi
Subject: RE: [HAPI-devel] message database


This is pretty much what I had in mind. I thought I would make a few generic
lookup JSP pages based on those types of fields and have a simple Struts war
to deploy.
 
One question though: Database access. Should the interface class use EJB or
not? Our requirement is that all database access goes through EJB's in our
environment. Is that too heavy handed for something like this or maybe
there's a way to abstract that out and allow a replacement class that uses
some JDBC.
 
-----Original Message-----
From: Tripp, Bryan [mailto:Bry...@uh...]
Sent: Monday, April 28, 2003 11:45 AM
To: 'Alex Harvey'; Hapi
Subject: RE: [HAPI-devel] message database
 
Hi Alex, 
 
Sounds like a great idea.  I think Abe Tio may have been working on
something like this.  Did you make any progress Abe?  
 
This isn't really on my radar, but I do have some thoughts on the matter ...
If you want a way to write arbitrary fields to arbitrary tables, for a
variety of incoming messages, I think it would be nice to just configure
your tool with a map of message paths to DB fields.  For example a map might
contain these entries: 
 
MSH-7  ->  PatientMessages.Date
PID-3  ->  PatientMessage.MRN
TEXT  ->  PatientMessages.WholeText   
 
... in which case your system would write MSH-7 to the Date field in the
PatientMessages table, etc. ("TEXT" is just meant to indicate a special
value that gets the complete text of the message).  I think that would be
really general and handy.  
 
Of course this is just a special case of the more general need for mapping
from HL7 data sources to HL7 data sinks.  Ideally we should treat HL7
messages, databases, text files, XML documents, etc. as sources and sinks,
formalize a datum path in each case (e.g. Terser path, table.field, regular
expression, XPath), take over the world, etc., but message -> database is
probably a very good place to start.  
 
Bryan 
-----Original Message-----
From: Alex Harvey [mailto:al...@9p...]
Sent: April 28, 2003 11:49 AM
To: Hapi
Subject: [HAPI-devel] message database
Has anyone ever considered making a generic database to track incoming HL7
messages? I've been considering doing something like this for A messages to
be able to easily refer back to a complete message history received for a
given patient. Is there anyone that would be interested in collaborating on
this?
 
-Alex


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.



This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

RE: [HAPI-devel] message database

[Alex H. <al...@9p...>]

This is pretty much what I had in mind. I thought I would make a few generic
lookup JSP pages based on those types of fields and have a simple Struts war
to deploy.

One question though: Database access. Should the interface class use EJB or
not? Our requirement is that all database access goes through EJB’s in our
environment. Is that too heavy handed for something like this or maybe there
’s a way to abstract that out and allow a replacement class that uses some
JDBC.

-----Original Message-----
From: Tripp, Bryan [mailto:Bry...@uh...]
Sent: Monday, April 28, 2003 11:45 AM
To: 'Alex Harvey'; Hapi
Subject: RE: [HAPI-devel] message database

Hi Alex,

Sounds like a great idea.  I think Abe Tio may have been working on
something like this.  Did you make any progress Abe?

This isn't really on my radar, but I do have some thoughts on the matter ...
If you want a way to write arbitrary fields to arbitrary tables, for a
variety of incoming messages, I think it would be nice to just configure
your tool with a map of message paths to DB fields.  For example a map might
contain these entries:

MSH-7  ->  PatientMessages.Date
PID-3  ->  PatientMessage.MRN
TEXT  ->  PatientMessages.WholeText

... in which case your system would write MSH-7 to the Date field in the
PatientMessages table, etc. ("TEXT" is just meant to indicate a special
value that gets the complete text of the message).  I think that would be
really general and handy.

Of course this is just a special case of the more general need for mapping
from HL7 data sources to HL7 data sinks.  Ideally we should treat HL7
messages, databases, text files, XML documents, etc. as sources and sinks,
formalize a datum path in each case (e.g. Terser path, table.field, regular
expression, XPath), take over the world, etc., but message -> database is
probably a very good place to start.

Bryan
-----Original Message-----
From: Alex Harvey [mailto:al...@9p...]
Sent: April 28, 2003 11:49 AM
To: Hapi
Subject: [HAPI-devel] message database
Has anyone ever considered making a generic database to track incoming HL7
messages? I’ve been considering doing something like this for A messages to
be able to easily refer back to a complete message history received for a
given patient. Is there anyone that would be interested in collaborating on
this?

-Alex


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

RE: [HAPI-devel] message database

[Tripp, B. <Bry...@uh...>]

Hi Alex, 
 
Sounds like a great idea.  I think Abe Tio may have been working on
something like this.  Did you make any progress Abe?  
 
This isn't really on my radar, but I do have some thoughts on the matter ...
If you want a way to write arbitrary fields to arbitrary tables, for a
variety of incoming messages, I think it would be nice to just configure
your tool with a map of message paths to DB fields.  For example a map might
contain these entries: 
 
MSH-7  ->  PatientMessages.Date
PID-3  ->  PatientMessage.MRN
TEXT  ->  PatientMessages.WholeText   
 
... in which case your system would write MSH-7 to the Date field in the
PatientMessages table, etc. ("TEXT" is just meant to indicate a special
value that gets the complete text of the message).  I think that would be
really general and handy.  
 
Of course this is just a special case of the more general need for mapping
from HL7 data sources to HL7 data sinks.  Ideally we should treat HL7
messages, databases, text files, XML documents, etc. as sources and sinks,
formalize a datum path in each case (e.g. Terser path, table.field, regular
expression, XPath), take over the world, etc., but message -> database is
probably a very good place to start.  
 
Bryan 
-----Original Message-----
From: Alex Harvey [mailto:al...@9p...]
Sent: April 28, 2003 11:49 AM
To: Hapi
Subject: [HAPI-devel] message database


Has anyone ever considered making a generic database to track incoming HL7
messages? I've been considering doing something like this for A messages to
be able to easily refer back to a complete message history received for a
given patient. Is there anyone that would be interested in collaborating on
this?
 
-Alex


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

[HAPI-devel] message database

[Alex H. <al...@9p...>]

Has anyone ever considered making a generic database to track incoming HL7
messages? I’ve been considering doing something like this for A messages to
be able to easily refer back to a complete message history received for a
given patient. Is there anyone that would be interested in collaborating on
this?

-Alex

RE: [HAPI-devel] RE: HAPI

[Tripp, B. <Bry...@uh...>]

Hi Ester, 
 
Sorry you waited so long for a response!  There was a mistake in my address
the first time, so I never got the message.  
 
RDT is a strange little wart in HL7.  As Alexei said, you can deal with it
using a custom message definition.  Or if you can wait, then HAPI 0.4, which
should be out in May, will handle it automatically. 
 
Thanks, 
Bryan 

-----Original Message-----
From: Guevara, Alexei [mailto:Ale...@uh...]
Sent: April 24, 2003 6:23 PM
To: 'hl7...@li...'
Subject: [HAPI-devel] RE: HAPI


Hi Ester
 
HAPI supports the overriding standard messages definitions (it looks like
that's what you need to the problem). To find out how to do it, you can
check the javadoc of the method Parser.findMessageClass.
 
aLeX6
 

-----Original Message-----
From: Ester Cohen [mailto:ES...@co...] 
Sent: April 24, 2003 5:53 PM
To: 'agu...@us...'; 'tbr...@us...';
'da...@us...'; 'jaz...@us...';
'leu...@us...'; 'lm...@us...';
'nac...@us...'; 'hl7...@li...'
Subject: FW: HAPI


Please someone response 
 
-----Original Message-----
From: Thomas J Lukasik [mailto:tlu...@da...] 
Sent: Thursday, April 24, 2003 6:10 PM
To: Ester Cohen
Subject: Fw: HAPI


 
----- Original Message ----- 
From: Tom <mailto:tlu...@da...>  
To: bry...@so... <mailto:bry...@so...>  
Cc: Ester Cohen <mailto:ES...@co...>  
Sent: Wednesday, February 05, 2003 11:41 PM
Subject: HAPI

Bryan,
 
I've run into a serious problem with HAPI and wondered if you might be
willing to help.  
 
Specifically, HAPI doesn't appear to parse RDT segments correctly; only the
first "column value" is displayed.  HAPI rejects all of the remaining column
values as "unexpected fields".  Here is an example of the HL7 message:
 
MSH|^~\&|SA1|SF1|RA1|RA2|20030205|SEC|TBR^R08^TBR_R08|MSG99001|P|2.4
MSA|AA|MSG00001
QAK|TAG0001|OK
RDF|12|acc.number^ST^20~name^ST^30~admit.date^ST^8~sex^ST^1~pat.street^ST^30
~pat.street2^ST^30~pat.city^ST^20~pat.state^ST^2~pat.zip^ST^9~soc.sec.number
^ST^11~urn^ST^20
RDT|12345678|SYSTEMS,IATRIC|20021215|F|81920|105 Maple
St.||Lancaster|PA|19786|156-96-2542|23
RDT|36377281|I AM,SAM|20021105|M|381992|166 Norwood
Ln.||Hershey|PA|19987|765-58-4615|783
RDT|36735546|MAN,SPIDER|20021201|F|83719|15 Elmwood Ct.|Apt.
15|Gap|PA|19724|58-96-7619|119
RDT|18292938|BUNNY,BUGS|20021225|M|8837|903 Diane
Circle||Phoenixville|PA|19460|156-96-2542|324
  
I've concluded that the problem is rooted in the fact that the HL7 folks
decided to use a "single, repeating field" to represent "n" columns of data
rather than a true single field as they do to represent "n" columns of
metadata in an RDF segment.   
 
I've been trying for two days to figure out how to best correct this but
unfortunately I don't know enough about the code yet to do so with
confidence - I certainly don't want to hack it and break your code.  So.. if
you could give me some direction, or even a hint as to where I might
concentrate my efforts, I'd be glad to revise the code and send you the
results.  TIA!
 
Regards,
Tom Lukasik
Chief Architect
DataGlider, Inc.
905-707-4214
  



MailFiler <http://www.mailfiler.com>  [EC-16BKUR2] 



This e-mail may contain confidential and/or privileged information

for the sole use of the intended recipient. Any review or distribution

by anyone other than the person for whom it was originally intended is
strictly

prohibited. If you have received this e-mail in error, please contact the
sender and

delete all copies. Opinions, conclusions or other information contained in

this e-mail may not be that of the organization.




This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

[HAPI-devel] RE: HAPI

[Guevara, A. <Ale...@uh...>]

Hi Ester
 
HAPI supports the overriding standard messages definitions (it looks like
that's what you need to the problem). To find out how to do it, you can
check the javadoc of the method Parser.findMessageClass.
 
aLeX6
 

-----Original Message-----
From: Ester Cohen [mailto:ES...@co...] 
Sent: April 24, 2003 5:53 PM
To: 'agu...@us...'; 'tbr...@us...';
'da...@us...'; 'jaz...@us...';
'leu...@us...'; 'lm...@us...';
'nac...@us...'; 'hl7...@li...'
Subject: FW: HAPI


Please someone response 
 
-----Original Message-----
From: Thomas J Lukasik [mailto:tlu...@da...] 
Sent: Thursday, April 24, 2003 6:10 PM
To: Ester Cohen
Subject: Fw: HAPI


 
----- Original Message ----- 
From: Tom <mailto:tlu...@da...>  
To: bry...@so... <mailto:bry...@so...>  
Cc: Ester Cohen <mailto:ES...@co...>  
Sent: Wednesday, February 05, 2003 11:41 PM
Subject: HAPI

Bryan,
 
I've run into a serious problem with HAPI and wondered if you might be
willing to help.  
 
Specifically, HAPI doesn't appear to parse RDT segments correctly; only the
first "column value" is displayed.  HAPI rejects all of the remaining column
values as "unexpected fields".  Here is an example of the HL7 message:
 
MSH|^~\&|SA1|SF1|RA1|RA2|20030205|SEC|TBR^R08^TBR_R08|MSG99001|P|2.4
MSA|AA|MSG00001
QAK|TAG0001|OK
RDF|12|acc.number^ST^20~name^ST^30~admit.date^ST^8~sex^ST^1~pat.street^ST^30
~pat.street2^ST^30~pat.city^ST^20~pat.state^ST^2~pat.zip^ST^9~soc.sec.number
^ST^11~urn^ST^20
RDT|12345678|SYSTEMS,IATRIC|20021215|F|81920|105 Maple
St.||Lancaster|PA|19786|156-96-2542|23
RDT|36377281|I AM,SAM|20021105|M|381992|166 Norwood
Ln.||Hershey|PA|19987|765-58-4615|783
RDT|36735546|MAN,SPIDER|20021201|F|83719|15 Elmwood Ct.|Apt.
15|Gap|PA|19724|58-96-7619|119
RDT|18292938|BUNNY,BUGS|20021225|M|8837|903 Diane
Circle||Phoenixville|PA|19460|156-96-2542|324
  
I've concluded that the problem is rooted in the fact that the HL7 folks
decided to use a "single, repeating field" to represent "n" columns of data
rather than a true single field as they do to represent "n" columns of
metadata in an RDF segment.   
 
I've been trying for two days to figure out how to best correct this but
unfortunately I don't know enough about the code yet to do so with
confidence - I certainly don't want to hack it and break your code.  So.. if
you could give me some direction, or even a hint as to where I might
concentrate my efforts, I'd be glad to revise the code and send you the
results.  TIA!
 
Regards,
Tom Lukasik
Chief Architect
DataGlider, Inc.
905-707-4214
  

MailFiler <http://www.mailfiler.com>  [EC-16BKUR2]


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

[HAPI-devel] FW: HAPI

[Ester C. <ES...@co...>]

Please someone response 
 
-----Original Message-----
From: Thomas J Lukasik [mailto:tlu...@da...] 
Sent: Thursday, April 24, 2003 6:10 PM
To: Ester Cohen
Subject: Fw: HAPI


 
----- Original Message ----- 
From: Tom <mailto:tlu...@da...>  
To: bry...@so... <mailto:bry...@so...>  
Cc: Ester Cohen <mailto:ES...@co...>  
Sent: Wednesday, February 05, 2003 11:41 PM
Subject: HAPI

Bryan,
 
I've run into a serious problem with HAPI and wondered if you might be
willing to help.  
 
Specifically, HAPI doesn't appear to parse RDT segments correctly; only the
first "column value" is displayed.  HAPI rejects all of the remaining column
values as "unexpected fields".  Here is an example of the HL7 message:
 
MSH|^~\&|SA1|SF1|RA1|RA2|20030205|SEC|TBR^R08^TBR_R08|MSG99001|P|2.4
MSA|AA|MSG00001
QAK|TAG0001|OK
RDF|12|acc.number^ST^20~name^ST^30~admit.date^ST^8~sex^ST^1~pat.street^ST^30
~pat.street2^ST^30~pat.city^ST^20~pat.state^ST^2~pat.zip^ST^9~soc.sec.number
^ST^11~urn^ST^20
RDT|12345678|SYSTEMS,IATRIC|20021215|F|81920|105 Maple
St.||Lancaster|PA|19786|156-96-2542|23
RDT|36377281|I AM,SAM|20021105|M|381992|166 Norwood
Ln.||Hershey|PA|19987|765-58-4615|783
RDT|36735546|MAN,SPIDER|20021201|F|83719|15 Elmwood Ct.|Apt.
15|Gap|PA|19724|58-96-7619|119
RDT|18292938|BUNNY,BUGS|20021225|M|8837|903 Diane
Circle||Phoenixville|PA|19460|156-96-2542|324
  
I've concluded that the problem is rooted in the fact that the HL7 folks
decided to use a "single, repeating field" to represent "n" columns of data
rather than a true single field as they do to represent "n" columns of
metadata in an RDF segment.   
 
I've been trying for two days to figure out how to best correct this but
unfortunately I don't know enough about the code yet to do so with
confidence - I certainly don't want to hack it and break your code.  So.. if
you could give me some direction, or even a hint as to where I might
concentrate my efforts, I'd be glad to revise the code and send you the
results.  TIA!
 
Regards,
Tom Lukasik
Chief Architect
DataGlider, Inc.
905-707-4214
  

RE: [HAPI-devel] Custom OBX Segment Problem

[Naylor, C. <Chr...@uh...>]

Hi Bryan,

I think Alexei took a quick look but hadn't started anything (correct me if
I'm wrong Alexei), and I haven't done any work on it and won't be able to
for the next copule weeks.  There isn't a big hurry for me (copying the
datatypes works as a temporary workaround), but if you'd like to take care
of it, by all means!

Thanks,
Chris

-----Original Message-----
From: Tripp, Bryan
To: HAPI Developers (E-mail)
Sent: 22/04/2003 2:57 PM
Subject: RE: [HAPI-devel] Custom OBX Segment Problem

Some more comments on this ... 

1) AbstractMessage.getVersion() just inspects its own class name, so you
have to override it for custom messages.  
2) Message.getVersion() is new since HAPI 0.3, so unfortunately patching
this is going to be a bit of a nuisance.  

Bryan 

> -----Original Message-----
> From: Tripp, Bryan [mailto:Bry...@uh...]
> Sent: April 22, 2003 2:42 PM
> To: Naylor, Chris; HAPI Developers (E-mail)
> Subject: RE: [HAPI-devel] Custom OBX Segment Problem
> 
> 
> Hi Chris, 
> 
> Yep, this is definitely a bug.  Hopefully not too hard to fix.
> Parser.findClass() could easily be extended to support Types.  Then in
> fixOBX5(), findClass could be called like this: 
> findClass(obx2.getValue(),
> segment.getMessage().getVersion(), "type").  I can do this, 
> unless you or
> Alexei have already started.  Let me know.  
> 
> Bryan 
> 
> > -----Original Message-----
> > From: Naylor, Chris [mailto:Chr...@uh...]
> > Sent: April 22, 2003 2:23 PM
> > To: HAPI Developers (E-mail)
> > Subject: [HAPI-devel] Custom OBX Segment Problem
> > 
> > 
> > Hello all,
> > 
> > I'm using version 0.3 with Alexei's default class patch and 
> > primarily 2.2
> > messages.  I'm trying to parse a custom message that 
> includes a custom
> > segment and am having one problem.  I'm still getting my feet 
> > wet here, so
> > please forgive any indiscretions.
> > 
> > My custom message type is working fine except for an 
> > exception on the one
> > custom segment.  I've setup the custom segment the same way 
> > as the custom
> > message - within my custom_packages files.  So my custom 
> message is in
> > org.project.server.message and segment is in 
> > org.project.server.segment.
> > Instead of creating a new segment type, I am just overriding 
> > the OBX type.
> > All of this is according to the instructions in Parser, and I 
> > am pretty sure
> > it is all working fine.
> > 
> > The problem comes because I am processing an OBX segment.  At 
> > the end of
> > PipeParser's (and other parser's?) parse function, it calls 
> > Varies.fixOBX5
> > in order to set the datatype of the 5th field.  This function 
> > tries to set
> > the field type using the name of the segment class name.
> > 
> > In my case, the custom segment class is 
> > org.project.server.sgement.OBX.  The
> > function then looks for the datatype by cutting the first 
> > part of the class
> > name and adding the datatype to the end.  So it takes 
> > org.project.server and
> > adds the datatype, for example ST, to the end.
> > 
> >     String className = segment.getClass().getName();
> >     String versionPackageName = className.substring(0,
> > className.indexOf(".segment.OBX"));
> >     String newClassName = versionPackageName + ".datatype." +
> > obx2.getValue();
> > 
> > Because I am not making any changes to the datatypes, I don't 
> > even have a
> > package called org.project.server.datatype, and so I get a 
> > classNotFound
> > exception.
> > 
> > If I wanted this to work, I would have to copy all the 
> > datatypes from the
> > standard version types into a custom datatype package.  I've 
> > tried this and
> > it works, but doesn't seem right.  Similar to the way the 
> > custom segments
> > are setup, I would think that when looking for a datatype, 
> > the custom ones
> > should be searched first, and if a match is not found, should 
> > proceed to the
> > standard datatypes.  
> > 
> > From talking with Alexei, it sounds like a patch is required, 
> > but I wasn't
> > sure whether to post this as a bug or just to the list.  Hope 
> > the above is
> > clear.
> > 
> > Thanks!
> > Chris
> > 
> > 
> > This e-mail may contain confidential and/or privileged information
> > for the sole use of the intended recipient. Any review or 
> distribution
> > by anyone other than the person for whom it was originally 
> intended is
> > strictly
> > prohibited. If you have received this e-mail in error, please 
> > contact the
> > sender and
> > delete all copies. Opinions, conclusions or other information 
> > contained in
> > this e-mail may not be that of the organization.
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Hl7api-devel mailing list
> > Hl7...@li...
> > https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> > 
> 
> 
> This e-mail may contain confidential and/or privileged information
> for the sole use of the intended recipient. Any review or distribution
> by anyone other than the person for whom it was originally intended is
> strictly
> prohibited. If you have received this e-mail in error, please 
> contact the
> sender and
> delete all copies. Opinions, conclusions or other information 
> contained in
> this e-mail may not be that of the organization.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> 


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact
the
sender and
delete all copies. Opinions, conclusions or other information contained
in
this e-mail may not be that of the organization.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Hl7api-devel mailing list
Hl7...@li...
https://lists.sourceforge.net/lists/listinfo/hl7api-devel


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

RE: [HAPI-devel] Custom OBX Segment Problem

[Tripp, B. <Bry...@uh...>]

Some more comments on this ... 

1) AbstractMessage.getVersion() just inspects its own class name, so you
have to override it for custom messages.  
2) Message.getVersion() is new since HAPI 0.3, so unfortunately patching
this is going to be a bit of a nuisance.  

Bryan 

> -----Original Message-----
> From: Tripp, Bryan [mailto:Bry...@uh...]
> Sent: April 22, 2003 2:42 PM
> To: Naylor, Chris; HAPI Developers (E-mail)
> Subject: RE: [HAPI-devel] Custom OBX Segment Problem
> 
> 
> Hi Chris, 
> 
> Yep, this is definitely a bug.  Hopefully not too hard to fix.
> Parser.findClass() could easily be extended to support Types.  Then in
> fixOBX5(), findClass could be called like this: 
> findClass(obx2.getValue(),
> segment.getMessage().getVersion(), "type").  I can do this, 
> unless you or
> Alexei have already started.  Let me know.  
> 
> Bryan 
> 
> > -----Original Message-----
> > From: Naylor, Chris [mailto:Chr...@uh...]
> > Sent: April 22, 2003 2:23 PM
> > To: HAPI Developers (E-mail)
> > Subject: [HAPI-devel] Custom OBX Segment Problem
> > 
> > 
> > Hello all,
> > 
> > I'm using version 0.3 with Alexei's default class patch and 
> > primarily 2.2
> > messages.  I'm trying to parse a custom message that 
> includes a custom
> > segment and am having one problem.  I'm still getting my feet 
> > wet here, so
> > please forgive any indiscretions.
> > 
> > My custom message type is working fine except for an 
> > exception on the one
> > custom segment.  I've setup the custom segment the same way 
> > as the custom
> > message - within my custom_packages files.  So my custom 
> message is in
> > org.project.server.message and segment is in 
> > org.project.server.segment.
> > Instead of creating a new segment type, I am just overriding 
> > the OBX type.
> > All of this is according to the instructions in Parser, and I 
> > am pretty sure
> > it is all working fine.
> > 
> > The problem comes because I am processing an OBX segment.  At 
> > the end of
> > PipeParser's (and other parser's?) parse function, it calls 
> > Varies.fixOBX5
> > in order to set the datatype of the 5th field.  This function 
> > tries to set
> > the field type using the name of the segment class name.
> > 
> > In my case, the custom segment class is 
> > org.project.server.sgement.OBX.  The
> > function then looks for the datatype by cutting the first 
> > part of the class
> > name and adding the datatype to the end.  So it takes 
> > org.project.server and
> > adds the datatype, for example ST, to the end.
> > 
> >     String className = segment.getClass().getName();
> >     String versionPackageName = className.substring(0,
> > className.indexOf(".segment.OBX"));
> >     String newClassName = versionPackageName + ".datatype." +
> > obx2.getValue();
> > 
> > Because I am not making any changes to the datatypes, I don't 
> > even have a
> > package called org.project.server.datatype, and so I get a 
> > classNotFound
> > exception.
> > 
> > If I wanted this to work, I would have to copy all the 
> > datatypes from the
> > standard version types into a custom datatype package.  I've 
> > tried this and
> > it works, but doesn't seem right.  Similar to the way the 
> > custom segments
> > are setup, I would think that when looking for a datatype, 
> > the custom ones
> > should be searched first, and if a match is not found, should 
> > proceed to the
> > standard datatypes.  
> > 
> > From talking with Alexei, it sounds like a patch is required, 
> > but I wasn't
> > sure whether to post this as a bug or just to the list.  Hope 
> > the above is
> > clear.
> > 
> > Thanks!
> > Chris
> > 
> > 
> > This e-mail may contain confidential and/or privileged information
> > for the sole use of the intended recipient. Any review or 
> distribution
> > by anyone other than the person for whom it was originally 
> intended is
> > strictly
> > prohibited. If you have received this e-mail in error, please 
> > contact the
> > sender and
> > delete all copies. Opinions, conclusions or other information 
> > contained in
> > this e-mail may not be that of the organization.
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Hl7api-devel mailing list
> > Hl7...@li...
> > https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> > 
> 
> 
> This e-mail may contain confidential and/or privileged information
> for the sole use of the intended recipient. Any review or distribution
> by anyone other than the person for whom it was originally intended is
> strictly
> prohibited. If you have received this e-mail in error, please 
> contact the
> sender and
> delete all copies. Opinions, conclusions or other information 
> contained in
> this e-mail may not be that of the organization.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> 


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

RE: [HAPI-devel] Custom OBX Segment Problem

[Tripp, B. <Bry...@uh...>]

Hi Chris, 

Yep, this is definitely a bug.  Hopefully not too hard to fix.
Parser.findClass() could easily be extended to support Types.  Then in
fixOBX5(), findClass could be called like this: findClass(obx2.getValue(),
segment.getMessage().getVersion(), "type").  I can do this, unless you or
Alexei have already started.  Let me know.  

Bryan 

> -----Original Message-----
> From: Naylor, Chris [mailto:Chr...@uh...]
> Sent: April 22, 2003 2:23 PM
> To: HAPI Developers (E-mail)
> Subject: [HAPI-devel] Custom OBX Segment Problem
> 
> 
> Hello all,
> 
> I'm using version 0.3 with Alexei's default class patch and 
> primarily 2.2
> messages.  I'm trying to parse a custom message that includes a custom
> segment and am having one problem.  I'm still getting my feet 
> wet here, so
> please forgive any indiscretions.
> 
> My custom message type is working fine except for an 
> exception on the one
> custom segment.  I've setup the custom segment the same way 
> as the custom
> message - within my custom_packages files.  So my custom message is in
> org.project.server.message and segment is in 
> org.project.server.segment.
> Instead of creating a new segment type, I am just overriding 
> the OBX type.
> All of this is according to the instructions in Parser, and I 
> am pretty sure
> it is all working fine.
> 
> The problem comes because I am processing an OBX segment.  At 
> the end of
> PipeParser's (and other parser's?) parse function, it calls 
> Varies.fixOBX5
> in order to set the datatype of the 5th field.  This function 
> tries to set
> the field type using the name of the segment class name.
> 
> In my case, the custom segment class is 
> org.project.server.sgement.OBX.  The
> function then looks for the datatype by cutting the first 
> part of the class
> name and adding the datatype to the end.  So it takes 
> org.project.server and
> adds the datatype, for example ST, to the end.
> 
>     String className = segment.getClass().getName();
>     String versionPackageName = className.substring(0,
> className.indexOf(".segment.OBX"));
>     String newClassName = versionPackageName + ".datatype." +
> obx2.getValue();
> 
> Because I am not making any changes to the datatypes, I don't 
> even have a
> package called org.project.server.datatype, and so I get a 
> classNotFound
> exception.
> 
> If I wanted this to work, I would have to copy all the 
> datatypes from the
> standard version types into a custom datatype package.  I've 
> tried this and
> it works, but doesn't seem right.  Similar to the way the 
> custom segments
> are setup, I would think that when looking for a datatype, 
> the custom ones
> should be searched first, and if a match is not found, should 
> proceed to the
> standard datatypes.  
> 
> From talking with Alexei, it sounds like a patch is required, 
> but I wasn't
> sure whether to post this as a bug or just to the list.  Hope 
> the above is
> clear.
> 
> Thanks!
> Chris
> 
> 
> This e-mail may contain confidential and/or privileged information
> for the sole use of the intended recipient. Any review or distribution
> by anyone other than the person for whom it was originally intended is
> strictly
> prohibited. If you have received this e-mail in error, please 
> contact the
> sender and
> delete all copies. Opinions, conclusions or other information 
> contained in
> this e-mail may not be that of the organization.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> 


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

[HAPI-devel] Custom OBX Segment Problem

[Naylor, C. <Chr...@uh...>]

Hello all,

I'm using version 0.3 with Alexei's default class patch and primarily 2.2
messages.  I'm trying to parse a custom message that includes a custom
segment and am having one problem.  I'm still getting my feet wet here, so
please forgive any indiscretions.

My custom message type is working fine except for an exception on the one
custom segment.  I've setup the custom segment the same way as the custom
message - within my custom_packages files.  So my custom message is in
org.project.server.message and segment is in org.project.server.segment.
Instead of creating a new segment type, I am just overriding the OBX type.
All of this is according to the instructions in Parser, and I am pretty sure
it is all working fine.

The problem comes because I am processing an OBX segment.  At the end of
PipeParser's (and other parser's?) parse function, it calls Varies.fixOBX5
in order to set the datatype of the 5th field.  This function tries to set
the field type using the name of the segment class name.

In my case, the custom segment class is org.project.server.sgement.OBX.  The
function then looks for the datatype by cutting the first part of the class
name and adding the datatype to the end.  So it takes org.project.server and
adds the datatype, for example ST, to the end.

    String className = segment.getClass().getName();
    String versionPackageName = className.substring(0,
className.indexOf(".segment.OBX"));
    String newClassName = versionPackageName + ".datatype." +
obx2.getValue();

Because I am not making any changes to the datatypes, I don't even have a
package called org.project.server.datatype, and so I get a classNotFound
exception.

If I wanted this to work, I would have to copy all the datatypes from the
standard version types into a custom datatype package.  I've tried this and
it works, but doesn't seem right.  Similar to the way the custom segments
are setup, I would think that when looking for a datatype, the custom ones
should be searched first, and if a match is not found, should proceed to the
standard datatypes.  

From talking with Alexei, it sounds like a patch is required, but I wasn't
sure whether to post this as a bug or just to the list.  Hope the above is
clear.

Thanks!
Chris


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

RE: [HAPI-devel] HAPI question

[Tripp, B. <Bry...@uh...>]

Hi Pat, 
 
If you want to move data from message A to message B, you have to copy it.
This is easiest if you use ca.uhn.hl7v2.util.DeepCopy, which copies Types.
I also just added a method for copying whole Segments (I'm surprised no one
asked for this sooner).  You can get the latest version from the CVS, or
just recycle the source for now.  Here it is: 
 
    public static void copy(Segment from, Segment to) throws HL7Exception {
        int n = from.numFields();
        for (int i = 1; i <= n; i++) {
            Type[] reps = from.getField(i);
            for (int j = 0; j < reps.length; j++) {
                ca.uhn.hl7v2.util.DeepCopy.copy(reps[j], to.getField(i, j));
            }
        }
    }
 
Bryan 

-----Original Message-----
From: Pat Stadler [mailto:Pat...@Ac...]
Sent: April 21, 2003 12:19 PM
To: 'hl7...@li...'
Subject: [HAPI-devel] HAPI question



Hi,

 

I am working with version .3 of the parser, using version 2.3.1 messages
with 'VB' encoding and I am trying to do a couple of things.  Is there a
method that I can use to pull out one whole segment from an instantiated
Message class?  What I am trying to do is execute an ADT import and if the
import of some of the required data (required for our system) fails, I want
to pull out that segment to use in rebuilding a new message.  I cannot
figure out how to do it.  Please any help would be appreciated.  

 

Thanks

Pat Stadler 

 



   _____  

The information contained in this message is confidential and is intended
for the addresses only. If you have received this message in error or there
are any problems, please notify the sender immediately. The unauthorized
use, disclosure, copying or alteration of this message is strictly
forbidden. 





This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

[HAPI-devel] HAPI question

[Pat S. <Pat...@Ac...>]

Hi,

 

I am working with version .3 of the parser, using version 2.3.1 messages
with 'VB' encoding and I am trying to do a couple of things.  Is there a
method that I can use to pull out one whole segment from an instantiated
Message class?  What I am trying to do is execute an ADT import and if the
import of some of the required data (required for our system) fails, I want
to pull out that segment to use in rebuilding a new message.  I cannot
figure out how to do it.  Please any help would be appreciated.  

 

Thanks

Pat Stadler 

 



The information contained in this message is confidential and is intended for the addresses only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.

Re[2]: [HAPI-devel] Extending HAPI to support X12

[Aaron B. <aa...@ot...>]

Hello Bryan,

Thanks very much for this information.

OpenEDI is exactly what I have been looking for.

Good luck with your own project!

Aaron


Friday, April 18, 2003, 2:44:27 PM, you wrote:

TB> Hi Aaron,  

TB> There was a review of open-source X12 products on the openhealth list today.
TB> I know nothing about this area, but OpenEDI (http://openedi.sourceforge.net)
TB> was mentioned as a good candidate.  Browsing through their CVS it looks like
TB> they have lots of X12 code:
TB> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/openedi/openedi/engine/org/op
TB> enedix/message/x12/  My impression is that you would get a better start
TB> there than with HAPI. 

TB> The review should show up here in a few days:
TB> http://www.mail-archive.com/ope...@mi.../maillist.
TB> html#08335

TB> Bryan 

>> -----Original Message-----
>> From: Aaron Boxer [mailto:aa...@ot...]
>> Sent: April 16, 2003 10:38 PM
>> To: hl7...@li....
>> Subject: [HAPI-devel] Extending HAPI to support X12
>> 
>> 
>> Hello HAPI developers,
>> 
>> Is anyone interested in starting a side-project
>> to add X12 support to HAPI?
>> 
>> For those not familiar with X12: it is a standard for electronic
>> exchange of business information.(www.x12.org)
>> 
>> It is used to transmit health insurance claims (the X12N dialect), and
>> is one of the standards used by HIPAA (Health Insurance 
>> Portability and
>> Accountability Act) (www.hipaa.org). 
>> 
>> There is now a standard evolving for translation of X12 to XML.
>> 
>> 
>> There are currently no open source toolkits ( to my knowledge) that
>> handle X12 data.
>> I was thinking of re-using HAPI's HL7 to XML framework for X12 work.
>> 
>> There are deadlines this year for all EMR providers in the US 
>> to comply
>> with HIPAA, so there should be a lot of interest in an X12 toolkit.
>> 
>> Advantages for HAPI would be more developers, and more testing of the
>> toolkit.
>> 
>> Please let me know.
>> 
>> Thanks!
>> 
>> Aaron Boxer
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> Hl7api-devel mailing list
>> Hl7...@li...
>> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>> 


TB> This e-mail may contain confidential and/or privileged information
TB> for the sole use of the intended recipient. Any review or distribution
TB> by anyone other than the person for whom it was originally intended is
TB> strictly
TB> prohibited. If you have received this e-mail in error, please contact the
TB> sender and
TB> delete all copies. Opinions, conclusions or other information contained in
TB> this e-mail may not be that of the organization.



TB> -------------------------------------------------------
TB> This sf.net email is sponsored by:ThinkGeek
TB> Welcome to geek heaven.
TB> http://thinkgeek.com/sf
TB> _______________________________________________
TB> Hl7api-devel mailing list
TB> Hl7...@li...
TB> https://lists.sourceforge.net/lists/listinfo/hl7api-devel



-- 
Best regards,
 Aaron                            mailto:aa...@ot...

RE: [HAPI-devel] Extending HAPI to support X12

[Tripp, B. <Bry...@uh...>]

Hi Aaron,  

There was a review of open-source X12 products on the openhealth list today.
I know nothing about this area, but OpenEDI (http://openedi.sourceforge.net)
was mentioned as a good candidate.  Browsing through their CVS it looks like
they have lots of X12 code:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/openedi/openedi/engine/org/op
enedix/message/x12/  My impression is that you would get a better start
there than with HAPI. 

The review should show up here in a few days:
http://www.mail-archive.com/ope...@mi.../maillist.
html#08335

Bryan 

> -----Original Message-----
> From: Aaron Boxer [mailto:aa...@ot...]
> Sent: April 16, 2003 10:38 PM
> To: hl7...@li....
> Subject: [HAPI-devel] Extending HAPI to support X12
> 
> 
> Hello HAPI developers,
> 
> Is anyone interested in starting a side-project
> to add X12 support to HAPI?
> 
> For those not familiar with X12: it is a standard for electronic
> exchange of business information.(www.x12.org)
> 
> It is used to transmit health insurance claims (the X12N dialect), and
> is one of the standards used by HIPAA (Health Insurance 
> Portability and
> Accountability Act) (www.hipaa.org). 
> 
> There is now a standard evolving for translation of X12 to XML.
> 
> 
> There are currently no open source toolkits ( to my knowledge) that
> handle X12 data.
> I was thinking of re-using HAPI's HL7 to XML framework for X12 work.
> 
> There are deadlines this year for all EMR providers in the US 
> to comply
> with HIPAA, so there should be a lot of interest in an X12 toolkit.
> 
> Advantages for HAPI would be more developers, and more testing of the
> toolkit.
> 
> Please let me know.
> 
> Thanks!
> 
> Aaron Boxer
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> 


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.

[HAPI-devel] Extending HAPI to support X12

[Aaron B. <aa...@ot...>]

Hello HAPI developers,

Is anyone interested in starting a side-project
to add X12 support to HAPI?

For those not familiar with X12: it is a standard for electronic
exchange of business information.(www.x12.org)

It is used to transmit health insurance claims (the X12N dialect), and
is one of the standards used by HIPAA (Health Insurance Portability and
Accountability Act) (www.hipaa.org). 

There is now a standard evolving for translation of X12 to XML.


There are currently no open source toolkits ( to my knowledge) that
handle X12 data.
I was thinking of re-using HAPI's HL7 to XML framework for X12 work.

There are deadlines this year for all EMR providers in the US to comply
with HIPAA, so there should be a lot of interest in an X12 toolkit.

Advantages for HAPI would be more developers, and more testing of the
toolkit.

Please let me know.

Thanks!

Aaron Boxer

RE: [HAPI-devel] hi, patch to load a default class when no messag e-class mapping is found

[Tripp, B. <Bry...@uh...>]

Hey, not bad!  We should definitely include this.  I want to try to finish
the handling of unexpected segments this week.  Once that's done this could
be made even simpler ... just use a constant DefaultHL7Message and any
segments that show up will be handled automatically.  Does that fit with
what you had in mind Alexei?  
 
Also, for times when you just want a few fields from a message (e.g. for
routing, acknowledging every message in a stream), Dan is working on a
preparser that just extracts the specific fields you ask for and puts them
in a Properties object.  This is meant to be really fast, so we can start to
handle higher volumes.  Should be ready today, he says.  
 
Bryan 

-----Original Message-----
From: alexei guevara [mailto:ale...@ho...]
Sent: April 14, 2003 11:39 AM
To: hl7...@li...
Subject: [HAPI-devel] hi, patch to load a default class when no
message-class mapping is found


Hi 
 
I was in need of making hapi parse any kind of HL7 messages (including
custom ones, not kown at deployment time). To accomplish such behavior I've
changed the Parser.findMessageClass, check the javadocs of that method
(included in the attached zip file) for details.
 
alex6
PS: a very simple test case is included in the zip file as well.



MailFiler <http://www.mailfiler.com>  [AG-7IS2CX]



This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.