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.