[HAPI-devel] RE: message database

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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.