hl7api-devel — developer list

[HAPI-devel] HL7 approves release of standard message library for HAPI

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

Some of you have been waiting to find out whether we can release the source
code for all the standard HL7 messages with HAPI.  This has been an open
question for several months.  The decision rested with those who hold the
copyright for the database that HAPI uses to generate the source code
(namely HL7 and HL7 Germany).  

A favorable decision was reached on Sunday.  This means that purchasing the
database is no longer a prerequisite for serious use of HAPI.  Hopefully
this will encourage people to use it and correspondingly increase the
developer base, resulting in higher quality code.  I should point out that
the HL7 database remains a useful tool for many other reasons, the most
compelling of which, in the context of HAPI, is that it contains the
standard code tables.   

In terms of releasing this code, I suggest that we release a new version of
HAPI in early June, including the full message library.  This should allow
enough time to include several other features that are currently in progress
(e.g. support for the XML encoding), and hopefully to incorporate the new
segment group names that are supposed to be available from HL7 any time now.
If you need the library in the mean time let me know and I will send it to
you (without the new segment group names).  

A big "thank you" to all those to participated in these disussions,
particularly Laura Sato from HL7 Canada who represented our interests in the
Atlanta meeting, Frank Oemig and Joachim Dudeck from HL7 Germany, and Wes
Rishel and Karen VanHentenryck from HL7 HQ for their interest and support.  

Bryan 

RE: [HAPI-devel] Beginners question

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

Hi Alex, Everyone, 

As you may know, you can do this for top-level segments (i.e. those not
within a segment group).  The Group interface (from which Message inherits)
has methods for returning message segments that it contains, by name.  So
you can do things like this: 

Message m;
// ... assign an actual message to m ... 

NTE nte = (NTE) m.get("NTE"); 	//returns 1st rep of NTE segment
nte = (NTE) m.get("NTE", 2); 		//returns 2nd rep of NTE segment
NTE[] nteReps = (NTE[]) m.getAll();  //returns all reps of NTE segment

(... sorry if this doesn't jump out from the API ... we really do need a set
of tutorials)

However, using this method you can't get a segment that is nested within a
group using a single command.  For example, if the NTE was part of GROUP_X,
you would have to do this: 

NTE nte = (NTE) ((GROUP_X) m.get("GROUP_X")).get("NTE"); 

... which isn't very pretty.  We could certainly make a utility that handles
this more cleanly.  

The first thing that comes to my mind is to have some static methods
somewhere that will parse a segment "path" and look up the correct segment
in a given message.  For example, one method signature could look like this:


public Segment getSegment(Message m, String segmentPath);

... and you would call it something like this: 

NTE nte = ProposedTool.getSegment(m, "GROUP_X:NTE");


Alex, would that meet your needs?  Does anyone else have another suggestion?


Thanks, 
Bryan 



-----Original Message-----
From: Alex Harvey [mailto:al...@9p...]
Sent: April 9, 2002 4:24 PM
To: hl7...@li...
Subject: RE: [HAPI-devel] Beginners question


I'm working on a project that is using HAPI and am doing things highly
similar to what Bryan describes. The difference is that I'm using session
and entity beans to encapsulate the database access rather than use JDBC
directly.

I have a class that acts to do the work of processing HL7 messages and then
create value objects and shipping them off to the session bean.

In working with the A-type messages for demographics, I've found that I've
written some redundant code to pull out the demographics segments from the
contents of the A messages. I have a series of functions that are
type-specific to each message type. These functions extract segments like
PID, NK1, etc. and use generic helper functions to populate my value object.

One strategy I though of was to implement some type of common interface by
which client code could query a generic message class and ask it for a
particular segment. If the segment was not available from the concrete
message, NULL would be returned. Something like this would eliminate the
need to write lots and lots of message type specific code.

Thoughts on putting more in the Message class to support stuff like this?

Its good to see some posts on this list!

-Alex

-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...]On Behalf Of Tripp, Bryan
Sent: Monday, April 08, 2002 7:56 PM
To: 'Tumkur, Priyadarshan'; 'hl7...@li...'
Subject: RE: [HAPI-devel] Beginners question

Hi Darshan,

The straightforward way to do this is to read data from a message object and
use it to build the necessary SQL statements.

By the way, has anyone else developed a more elegant method yet?

I'll try to walk you through a simple example to get you started.  We'll use
a v2.4 ACK message because it's simple and because it comes with the HAPI
distribution.  We'll make a class that accepts a JDBC connection in the
constructor, and has a method that writes a few message fields to a table,
like this ...

import java.sql.*;
import ca.uhn.hl7v2.model.v24.ACK;

public class DBWriteDemo {

        private static Connection conn;

        public DBWriteDemo(Connection c) {
                this.conn = c;
        }

        public void storeData(ACK message) throws SQLException {
                // ...
        }

}

Within the "storeData" method you would just read data from the incoming
message, build an SQL insert statement, and execute it.  To keep things
simple, let's imagine you have a table called "message_times" and you want
to insert two fields into it - the message time stamp ("time") and the
message ID ("ID").  You could do something like this:

    public void storeData(ACK message) throws SQLException {
          //the HAPI part ...
        String messageTime =
message.getMSH().getDateTimeOfMessage().getValue();
        String messageID =
message.getMSH().getMessageControlID().getValue();

          //the JDBC part ...
        StringBuffer sql = new StringBuffer();
        sql.append("insert into message_times (time, ID) values ('");
        sql.append(messageTime);
        sql.append("', '");
        sql.append(messageID);
        sql.append("')");
        Statement s = conn.createStatement();
        s.execute(sql.toString());
        s.close();
    }


For testing purposes, an easy way to get an ACK object would be to put an
ACK message in a file, read it into a String, and parse it.  To try it out,
you could make a main() along the following lines:

    public static void main(String args[]) {
        try {
                //PipeParser is HAPI's main HL7 parser for the traditional
HL7 encoding
            PipeParser parser = new PipeParser();

                //read the file ...
            File messageFile = new File(args[0]);
            FileReader r = new FileReader(messageFile);
            char[] cbuf = new char[(int)messageFile.length()];
                r.read(cbuf);
            r.close();
            String messString = String.valueOf(cbuf);

                //parse the message into an ACK message object ...
            ACK message = (ACK) parser.parse(messString);

            // ... make sure your JDBC driver is loaded

                //store the message data
            DBWriteDemo demo = new
DBWriteDemo(DriverManager.getConnection(/* ... database URL ... */));
            demo.storeData(message);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

To obtain real messages in your production app you could use the
ca.uhn.hl7v2.app.SimpleServer class to listen for messages (assuming you are
receiving messages over a socket).  For more detail, please see the JavaDocs
for this class as well as Application, MessageTypeRouter, and Responder in
the same package.  In a nutshell, you would configure the server to route
the messages you are interested in to an implementation of the Application
interface that you create.  Application has the following method:

public Message processMessage(Message in);

... your implementation of this would be very similar to the "storeData()"
method above.  If this isn't clear, let me know and I can explain further.

About the HL7 Access database ... you need this because HAPI needs a
specific Java class for every message structure.  For example, to handle
ADT_A01 messages, you need an ADT_A01 class.  These classes are generated
automatically using the Access database.

I would rather just give you the necessary message classes than make you buy
the database.  The reason I can't do that, yet, is because of HL7's
copyright on the database, which covers derived materials.  We are
discussing with HL7 the possibility of releasing the message classes so that
people don't need the database.  So far HL7 has been very receptive, but we
won't have a final answer before the Atlanta working group meeting at the
end of the month.  I'll post a message to the list as soon as I hear
something definitive.  In the mean time, the only thing to do is buy the
database.

Good luck, I hope this helps.

Regards,
Bryan


-----Original Message-----
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tumkur, Priyadarshan [mailto:Pri...@Mc...]
Sent: April 8, 2002 5:15 PM
To: 'hl7...@li...'
Subject: [HAPI-devel] Beginners question


Hi ,

I am new to the HL7 structure and has been assigned to write a Parser to
extract the Patient Demographic Data (PID) info from the HL7 messages. I
bumped into your tool and wanted some basic information for using HAPI.

We are interested in extracting Patient information and store in the DB. Can
you tell me how I can start off to do that using your tools. I am really not
getting the point of Access Database which
we are supposed to buy for generation of different modules. Please update
the best way as to how I can implement my requirement using HAPI.

Thanks,

Darshan



___________________________________________________________________________
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information.  Any unauthorized review, use, disclosure or
distribution is prohibited.  If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.

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

Sponsored by http://www.ThinkGeek.com/

Sponsored by http://www.ThinkGeek.com/

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



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

RE: [HAPI-devel] Beginners question

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

I'm working on a project that is using HAPI and am doing things highly
similar to what Bryan describes. The difference is that I'm using session
and entity beans to encapsulate the database access rather than use JDBC
directly.

I have a class that acts to do the work of processing HL7 messages and then
create value objects and shipping them off to the session bean.

In working with the A-type messages for demographics, I've found that I've
written some redundant code to pull out the demographics segments from the
contents of the A messages. I have a series of functions that are
type-specific to each message type. These functions extract segments like
PID, NK1, etc. and use generic helper functions to populate my value object.

One strategy I though of was to implement some type of common interface by
which client code could query a generic message class and ask it for a
particular segment. If the segment was not available from the concrete
message, NULL would be returned. Something like this would eliminate the
need to write lots and lots of message type specific code.

Thoughts on putting more in the Message class to support stuff like this?

Its good to see some posts on this list!

-Alex

-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...]On Behalf Of Tripp, Bryan
Sent: Monday, April 08, 2002 7:56 PM
To: 'Tumkur, Priyadarshan'; 'hl7...@li...'
Subject: RE: [HAPI-devel] Beginners question

Hi Darshan,

The straightforward way to do this is to read data from a message object and
use it to build the necessary SQL statements.

By the way, has anyone else developed a more elegant method yet?

I'll try to walk you through a simple example to get you started.  We'll use
a v2.4 ACK message because it's simple and because it comes with the HAPI
distribution.  We'll make a class that accepts a JDBC connection in the
constructor, and has a method that writes a few message fields to a table,
like this ...

import java.sql.*;
import ca.uhn.hl7v2.model.v24.ACK;

public class DBWriteDemo {

        private static Connection conn;

        public DBWriteDemo(Connection c) {
                this.conn = c;
        }

        public void storeData(ACK message) throws SQLException {
                // ...
        }

}

Within the "storeData" method you would just read data from the incoming
message, build an SQL insert statement, and execute it.  To keep things
simple, let's imagine you have a table called "message_times" and you want
to insert two fields into it - the message time stamp ("time") and the
message ID ("ID").  You could do something like this:

    public void storeData(ACK message) throws SQLException {
          //the HAPI part ...
        String messageTime =
message.getMSH().getDateTimeOfMessage().getValue();
        String messageID =
message.getMSH().getMessageControlID().getValue();

          //the JDBC part ...
        StringBuffer sql = new StringBuffer();
        sql.append("insert into message_times (time, ID) values ('");
        sql.append(messageTime);
        sql.append("', '");
        sql.append(messageID);
        sql.append("')");
        Statement s = conn.createStatement();
        s.execute(sql.toString());
        s.close();
    }


For testing purposes, an easy way to get an ACK object would be to put an
ACK message in a file, read it into a String, and parse it.  To try it out,
you could make a main() along the following lines:

    public static void main(String args[]) {
        try {
                //PipeParser is HAPI's main HL7 parser for the traditional
HL7 encoding
            PipeParser parser = new PipeParser();

                //read the file ...
            File messageFile = new File(args[0]);
            FileReader r = new FileReader(messageFile);
            char[] cbuf = new char[(int)messageFile.length()];
                r.read(cbuf);
            r.close();
            String messString = String.valueOf(cbuf);

                //parse the message into an ACK message object ...
            ACK message = (ACK) parser.parse(messString);

            // ... make sure your JDBC driver is loaded

                //store the message data
            DBWriteDemo demo = new
DBWriteDemo(DriverManager.getConnection(/* ... database URL ... */));
            demo.storeData(message);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

To obtain real messages in your production app you could use the
ca.uhn.hl7v2.app.SimpleServer class to listen for messages (assuming you are
receiving messages over a socket).  For more detail, please see the JavaDocs
for this class as well as Application, MessageTypeRouter, and Responder in
the same package.  In a nutshell, you would configure the server to route
the messages you are interested in to an implementation of the Application
interface that you create.  Application has the following method:

public Message processMessage(Message in);

... your implementation of this would be very similar to the "storeData()"
method above.  If this isn't clear, let me know and I can explain further.

About the HL7 Access database ... you need this because HAPI needs a
specific Java class for every message structure.  For example, to handle
ADT_A01 messages, you need an ADT_A01 class.  These classes are generated
automatically using the Access database.

I would rather just give you the necessary message classes than make you buy
the database.  The reason I can't do that, yet, is because of HL7's
copyright on the database, which covers derived materials.  We are
discussing with HL7 the possibility of releasing the message classes so that
people don't need the database.  So far HL7 has been very receptive, but we
won't have a final answer before the Atlanta working group meeting at the
end of the month.  I'll post a message to the list as soon as I hear
something definitive.  In the mean time, the only thing to do is buy the
database.

Good luck, I hope this helps.

Regards,
Bryan


-----Original Message-----
From: Tumkur, Priyadarshan [mailto:Pri...@Mc...]
Sent: April 8, 2002 5:15 PM
To: 'hl7...@li...'
Subject: [HAPI-devel] Beginners question


Hi ,

I am new to the HL7 structure and has been assigned to write a Parser to
extract the Patient Demographic Data (PID) info from the HL7 messages. I
bumped into your tool and wanted some basic information for using HAPI.

We are interested in extracting Patient information and store in the DB. Can
you tell me how I can start off to do that using your tools. I am really not
getting the point of Access Database which
we are supposed to buy for generation of different modules. Please update
the best way as to how I can implement my requirement using HAPI.

Thanks,

Darshan



___________________________________________________________________________
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information.  Any unauthorized review, use, disclosure or
distribution is prohibited.  If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.

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

Sponsored by http://www.ThinkGeek.com/

Sponsored by http://www.ThinkGeek.com/

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

RE: [HAPI-devel] Beginners question

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

Hi Darshan, 

The straightforward way to do this is to read data from a message object and
use it to build the necessary SQL statements.  

By the way, has anyone else developed a more elegant method yet?  

I'll try to walk you through a simple example to get you started.  We'll use
a v2.4 ACK message because it's simple and because it comes with the HAPI
distribution.  We'll make a class that accepts a JDBC connection in the
constructor, and has a method that writes a few message fields to a table,
like this ... 

import java.sql.*;
import ca.uhn.hl7v2.model.v24.ACK;

public class DBWriteDemo {

	private static Connection conn;

	public DBWriteDemo(Connection c) {
		this.conn = c;
	}

	public void storeData(ACK message) throws SQLException {
		// ... 
	}

}

Within the "storeData" method you would just read data from the incoming
message, build an SQL insert statement, and execute it.  To keep things
simple, let's imagine you have a table called "message_times" and you want
to insert two fields into it - the message time stamp ("time") and the
message ID ("ID").  You could do something like this: 

    public void storeData(ACK message) throws SQLException {
	  //the HAPI part ... 
        String messageTime =
message.getMSH().getDateTimeOfMessage().getValue();
        String messageID =
message.getMSH().getMessageControlID().getValue();

	  //the JDBC part ... 
        StringBuffer sql = new StringBuffer();
        sql.append("insert into message_times (time, ID) values ('");
        sql.append(messageTime);
        sql.append("', '");
        sql.append(messageID);
        sql.append("')");
        Statement s = conn.createStatement();
        s.execute(sql.toString());
        s.close();
    }


For testing purposes, an easy way to get an ACK object would be to put an
ACK message in a file, read it into a String, and parse it.  To try it out,
you could make a main() along the following lines: 

    public static void main(String args[]) {
        try {            
	 	//PipeParser is HAPI's main HL7 parser for the traditional
HL7 encoding
            PipeParser parser = new PipeParser();  

		//read the file ... 
            File messageFile = new File(args[0]);
            FileReader r = new FileReader(messageFile);
            char[] cbuf = new char[(int)messageFile.length()];
		r.read(cbuf);
            r.close();
            String messString = String.valueOf(cbuf);

		//parse the message into an ACK message object ... 
            ACK message = (ACK) parser.parse(messString);
            
            // ... make sure your JDBC driver is loaded 
            
		//store the message data
            DBWriteDemo demo = new
DBWriteDemo(DriverManager.getConnection(/* ... database URL ... */));
            demo.storeData(message);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

To obtain real messages in your production app you could use the
ca.uhn.hl7v2.app.SimpleServer class to listen for messages (assuming you are
receiving messages over a socket).  For more detail, please see the JavaDocs
for this class as well as Application, MessageTypeRouter, and Responder in
the same package.  In a nutshell, you would configure the server to route
the messages you are interested in to an implementation of the Application
interface that you create.  Application has the following method: 

public Message processMessage(Message in); 

... your implementation of this would be very similar to the "storeData()"
method above.  If this isn't clear, let me know and I can explain further.  

About the HL7 Access database ... you need this because HAPI needs a
specific Java class for every message structure.  For example, to handle
ADT_A01 messages, you need an ADT_A01 class.  These classes are generated
automatically using the Access database.  

I would rather just give you the necessary message classes than make you buy
the database.  The reason I can't do that, yet, is because of HL7's
copyright on the database, which covers derived materials.  We are
discussing with HL7 the possibility of releasing the message classes so that
people don't need the database.  So far HL7 has been very receptive, but we
won't have a final answer before the Atlanta working group meeting at the
end of the month.  I'll post a message to the list as soon as I hear
something definitive.  In the mean time, the only thing to do is buy the
database.  

Good luck, I hope this helps.  

Regards, 
Bryan 


-----Original Message-----
From: Tumkur, Priyadarshan [mailto:Pri...@Mc...]
Sent: April 8, 2002 5:15 PM
To: 'hl7...@li...'
Subject: [HAPI-devel] Beginners question


Hi ,

I am new to the HL7 structure and has been assigned to write a Parser to
extract the Patient Demographic Data (PID) info from the HL7 messages. I
bumped into your tool and wanted some basic information for using HAPI.

We are interested in extracting Patient information and store in the DB. Can
you tell me how I can start off to do that using your tools. I am really not
getting the point of Access Database which 
we are supposed to buy for generation of different modules. Please update
the best way as to how I can implement my requirement using HAPI.

Thanks,

Darshan 
 
 
 
___________________________________________________________________________
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
for the sole use of the intended recipient(s) and may contain confidential 
and privileged information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.

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

Sponsored by http://www.ThinkGeek.com/

[HAPI-devel] Beginners question

[Tumkur, P. <Pri...@Mc...>]

Hi ,

I am new to the HL7 structure and has been assigned to write a Parser to
extract the Patient Demographic Data (PID) info from the HL7 messages. I
bumped into your tool and wanted some basic information for using HAPI.

We are interested in extracting Patient information and store in the DB. Can
you tell me how I can start off to do that using your tools. I am really not
getting the point of Access Database which 
we are supposed to buy for generation of different modules. Please update
the best way as to how I can implement my requirement using HAPI.

Thanks,

Darshan 
 
 
 
___________________________________________________________________________
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
for the sole use of the intended recipient(s) and may contain confidential 
and privileged information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.

[HAPI-devel] HAPI release 0.2

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

Hi Everyone, 

After a slight delay (attributable to me, my flaky hard drive, and my
drawn-out academic career), I posted version 0.2 on Friday.  Thanks to those
who contributed.  Thanks also to those who are in the process of
contributing.  And a friendly nod to the rest of you.  Stay tuned for
version 0.3.  

Bryan

[HAPI-devel] publicity

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

Good news ... HL7 is thinking of announcing HAPI in their newsletter and
maybe on their web site.  I'll let you know when I get any more details.  

[HAPI-devel] getting ready for release 0.2

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

Hi Everyone, 

I want to release a new HAPI version in about 2 weeks, so if you have any
suggestions, bug reports, or code to contribute, the sooner the better. 

This release will include some bug fixes and some new functionality
including some basic lower layer protocol support, some message processing
logic, generation of ERR segments from HL7Exceptions, and a basic server for
TCP/IP connections. There are some other things on the way as well (which
might be included depending on timing) including the deep copy function and
a UI for the source code generator. 

Once these features are in place, I propose we focus on the following areas:


1. XML support
2. Conformance profile support
3. Testing 

Our XML guy has become otherwise occupied, so all of these are wide open if
you want to work on them.  

Comments?  Volunteers?  

Thanks, 
Bryan 

RE: [HAPI-devel] deep copy functionality

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

Yep, or instead of: 

HL7API.Toolbox.copyInto(obj, obj, int x, String name);

could have: 

HL7API.Toolbox.copyInto(seg, seg);
HL7API.Toolbox.copyInto(message, message);
etc. 

Of course the trade-off with the separate utility is that it makes it more
awkward to implement an optimized (or otherwise specialized) copy for a
particular implementation of segment, message, etc., if you wanted to do
that.  

But I can't see any major problems either way.   

Bryan 


-----Original Message-----
From: Abraham Tio [mailto:ti...@ta...]
Sent: Friday, December 14, 2001 11:57 AM
To: 'Tripp, Bryan'; 'Glock'; hl7...@li...
Subject: RE: [HAPI-devel] deep copy functionality


So many choices.. good luck in your decision, i'm partial to this one
you suggest, 

define, for example, Segment.copyInto(Segment
otherSegment) and then implement it in AbstractSegment.

, implementable in all relevant abstract classes.

But depending on the direction of the project, you might want to
consider this one : 

One other alternative which i've employed in some of the xml-ish stuff
i've done is to have a utility-class that has a family of static methods
for manipulating commonly manipulated objects... like segments.  This
would work if we could make a fundamental toolbox-class that people
wouldn't forget to import when using the rest of the package.

HL7API.Toolbox.copyInto(obj, obj, int x, String name);
Where x is one of :
Toolbox.SEGMENT
Toolbox.MESSAGE
Toolbox.<other element>

And name is the name of the element.  If we're trying to copy the msh
segment we'd use Toolbox.SEGMENT, name="MSH".

An advantage here is that we wouldn't break people's code with revisions
of an abstract class, just because we found yet another thing we like to
do with message elements in general.  It's a pretty common way of doing
things. The Graphics class is an example, the Math class another, even
String has a couple of methods like the ones we're considering : 

static String copyValueOf(char[] data) 
          Returns a String that is equivalent to the specified character
array. 
static String copyValueOf(char[] data, int offset, int count) 
          Returns a String that is equivalent to the specified character
array.


Abraham Tio
MD, Chief Technologist
Tacteon LTD.
http://www.tacteonltd.com


-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...] On Behalf Of Tripp,
Bryan
Sent: Friday, December 14, 2001 11:40 AM
To: 'Abraham Tio'; 'Glock'; hl7...@li...
Subject: RE: [HAPI-devel] deep copy functionality

Hi Abe, 

Excellent advice, as always.  We could use something similar to clone(),
except that it wouldn't create a new object (so it would be copy(Object)
:
void, instead of clone() : Object).  On the other hand why not define
type-specific copy methods for Message, Segment, and Type?  Would we
want to
copy anything else?  You could define, for example,
Segment.copyInto(Segment
otherSegment) and then implement it in AbstractSegment.  I guess it's a
trade-off between genericness and type checking (?). 

The only annoying thing is that if somebody had a Segment that didn't
inherit from AbstractSegment, they could have to implement copyInto
again.
But this would be a small percentage of the total work, and they could
always cut and paste.  

Bryan 

-----Original Message-----
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Abraham Tio [mailto:ti...@ta...]
Sent: Friday, December 14, 2001 10:09 AM
To: 'Abraham Tio'; 'Glock'; hl7...@li...
Subject: RE: [HAPI-devel] deep copy functionality


In further thought, how about an interface for all things copiable ?
Or add an abstract method to the base class common to all classes ? 

Abraham Tio
MD, Chief Technologist
Tacteon LTD.
http://www.tacteonltd.com


-----Original Message-----
X-Sybari-Trust: 7d7eeda1 81a61286 eef0cdc1 00000004
From: hl7...@li...
[mailto:hl7...@li...] On Behalf Of Abraham
Tio
Sent: Friday, December 14, 2001 10:00 AM
To: 'Glock'; hl7...@li...
Subject: RE: [HAPI-devel] deep copy functionality

I would do both, and use the implementation as a pattern for copying
just about everything else that needs to be copied.  Today we're
thinking about deep copy for the purposes of echoing segments and
messages. Tomorrow, who knows why we'll be copying.  Much like the
clone() method in many java class interfaces, the uses are varied and
many.  

Does the pretense of the clone() method apply to hl7 message components
?

Abraham Tio
MD, Chief Technologist
Tacteon LTD.
http://www.tacteonltd.com


-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...] On Behalf Of Glock
Sent: Friday, December 14, 2001 8:02 AM
To: hl7...@li...
Subject: [HAPI-devel] deep copy functionality

All:

I'm working on the deep copy functionality (task 42332) and am seeking
feedback on where this should be implemented. I'm leaning toward making
it part of the Message interface since it must act on an entire segment
in addition to select fields.  Another option is to simply view the
segment as comprised of "all fields" and make it part of Segment
interface.

Thanks,
John Glock--


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

????????????????????????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????
??????


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


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

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

RE: [HAPI-devel] deep copy functionality

[Abraham T. <ti...@ta...>]

So many choices.. good luck in your decision, i'm partial to this one
you suggest, 

define, for example, Segment.copyInto(Segment
otherSegment) and then implement it in AbstractSegment.

, implementable in all relevant abstract classes.

But depending on the direction of the project, you might want to
consider this one : 

One other alternative which i've employed in some of the xml-ish stuff
i've done is to have a utility-class that has a family of static methods
for manipulating commonly manipulated objects... like segments.  This
would work if we could make a fundamental toolbox-class that people
wouldn't forget to import when using the rest of the package.

HL7API.Toolbox.copyInto(obj, obj, int x, String name);
Where x is one of :
Toolbox.SEGMENT
Toolbox.MESSAGE
Toolbox.<other element>

And name is the name of the element.  If we're trying to copy the msh
segment we'd use Toolbox.SEGMENT, name="MSH".

An advantage here is that we wouldn't break people's code with revisions
of an abstract class, just because we found yet another thing we like to
do with message elements in general.  It's a pretty common way of doing
things. The Graphics class is an example, the Math class another, even
String has a couple of methods like the ones we're considering : 

static String copyValueOf(char[] data) 
          Returns a String that is equivalent to the specified character
array. 
static String copyValueOf(char[] data, int offset, int count) 
          Returns a String that is equivalent to the specified character
array.


Abraham Tio
MD, Chief Technologist
Tacteon LTD.
http://www.tacteonltd.com


-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...] On Behalf Of Tripp,
Bryan
Sent: Friday, December 14, 2001 11:40 AM
To: 'Abraham Tio'; 'Glock'; hl7...@li...
Subject: RE: [HAPI-devel] deep copy functionality

Hi Abe, 

Excellent advice, as always.  We could use something similar to clone(),
except that it wouldn't create a new object (so it would be copy(Object)
:
void, instead of clone() : Object).  On the other hand why not define
type-specific copy methods for Message, Segment, and Type?  Would we
want to
copy anything else?  You could define, for example,
Segment.copyInto(Segment
otherSegment) and then implement it in AbstractSegment.  I guess it's a
trade-off between genericness and type checking (?). 

The only annoying thing is that if somebody had a Segment that didn't
inherit from AbstractSegment, they could have to implement copyInto
again.
But this would be a small percentage of the total work, and they could
always cut and paste.  

Bryan 

-----Original Message-----
From: Abraham Tio [mailto:ti...@ta...]
Sent: Friday, December 14, 2001 10:09 AM
To: 'Abraham Tio'; 'Glock'; hl7...@li...
Subject: RE: [HAPI-devel] deep copy functionality


In further thought, how about an interface for all things copiable ?
Or add an abstract method to the base class common to all classes ? 

Abraham Tio
MD, Chief Technologist
Tacteon LTD.
http://www.tacteonltd.com


-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...] On Behalf Of Abraham
Tio
Sent: Friday, December 14, 2001 10:00 AM
To: 'Glock'; hl7...@li...
Subject: RE: [HAPI-devel] deep copy functionality

I would do both, and use the implementation as a pattern for copying
just about everything else that needs to be copied.  Today we're
thinking about deep copy for the purposes of echoing segments and
messages. Tomorrow, who knows why we'll be copying.  Much like the
clone() method in many java class interfaces, the uses are varied and
many.  

Does the pretense of the clone() method apply to hl7 message components
?

Abraham Tio
MD, Chief Technologist
Tacteon LTD.
http://www.tacteonltd.com


-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...] On Behalf Of Glock
Sent: Friday, December 14, 2001 8:02 AM
To: hl7...@li...
Subject: [HAPI-devel] deep copy functionality

All:

I'm working on the deep copy functionality (task 42332) and am seeking
feedback on where this should be implemented. I'm leaning toward making
it part of the Message interface since it must act on an entire segment
in addition to select fields.  Another option is to simply view the
segment as comprised of "all fields" and make it part of Segment
interface.

Thanks,
John Glock--


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

????????????????????????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????
??????


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


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

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

RE: [HAPI-devel] deep copy functionality

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

Hi Abe, 

Excellent advice, as always.  We could use something similar to clone(),
except that it wouldn't create a new object (so it would be copy(Object) :
void, instead of clone() : Object).  On the other hand why not define
type-specific copy methods for Message, Segment, and Type?  Would we want to
copy anything else?  You could define, for example, Segment.copyInto(Segment
otherSegment) and then implement it in AbstractSegment.  I guess it's a
trade-off between genericness and type checking (?). 

The only annoying thing is that if somebody had a Segment that didn't
inherit from AbstractSegment, they could have to implement copyInto again.
But this would be a small percentage of the total work, and they could
always cut and paste.  

Bryan 

-----Original Message-----
From: Abraham Tio [mailto:ti...@ta...]
Sent: Friday, December 14, 2001 10:09 AM
To: 'Abraham Tio'; 'Glock'; hl7...@li...
Subject: RE: [HAPI-devel] deep copy functionality


In further thought, how about an interface for all things copiable ?
Or add an abstract method to the base class common to all classes ? 

Abraham Tio
MD, Chief Technologist
Tacteon LTD.
http://www.tacteonltd.com


-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...] On Behalf Of Abraham
Tio
Sent: Friday, December 14, 2001 10:00 AM
To: 'Glock'; hl7...@li...
Subject: RE: [HAPI-devel] deep copy functionality

I would do both, and use the implementation as a pattern for copying
just about everything else that needs to be copied.  Today we're
thinking about deep copy for the purposes of echoing segments and
messages. Tomorrow, who knows why we'll be copying.  Much like the
clone() method in many java class interfaces, the uses are varied and
many.  

Does the pretense of the clone() method apply to hl7 message components
?

Abraham Tio
MD, Chief Technologist
Tacteon LTD.
http://www.tacteonltd.com


-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...] On Behalf Of Glock
Sent: Friday, December 14, 2001 8:02 AM
To: hl7...@li...
Subject: [HAPI-devel] deep copy functionality

All:

I'm working on the deep copy functionality (task 42332) and am seeking
feedback on where this should be implemented. I'm leaning toward making
it part of the Message interface since it must act on an entire segment
in addition to select fields.  Another option is to simply view the
segment as comprised of "all fields" and make it part of Segment
interface.

Thanks,
John Glock--


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

????????????????????????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????
??????


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


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

RE: [HAPI-devel] deep copy functionality

[Abraham T. <ti...@ta...>]

In further thought, how about an interface for all things copiable ?
Or add an abstract method to the base class common to all classes ? 

Abraham Tio
MD, Chief Technologist
Tacteon LTD.
http://www.tacteonltd.com


-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...] On Behalf Of Abraham
Tio
Sent: Friday, December 14, 2001 10:00 AM
To: 'Glock'; hl7...@li...
Subject: RE: [HAPI-devel] deep copy functionality

I would do both, and use the implementation as a pattern for copying
just about everything else that needs to be copied.  Today we're
thinking about deep copy for the purposes of echoing segments and
messages. Tomorrow, who knows why we'll be copying.  Much like the
clone() method in many java class interfaces, the uses are varied and
many.  

Does the pretense of the clone() method apply to hl7 message components
?

Abraham Tio
MD, Chief Technologist
Tacteon LTD.
http://www.tacteonltd.com


-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...] On Behalf Of Glock
Sent: Friday, December 14, 2001 8:02 AM
To: hl7...@li...
Subject: [HAPI-devel] deep copy functionality

All:

I'm working on the deep copy functionality (task 42332) and am seeking
feedback on where this should be implemented. I'm leaning toward making
it part of the Message interface since it must act on an entire segment
in addition to select fields.  Another option is to simply view the
segment as comprised of "all fields" and make it part of Segment
interface.

Thanks,
John Glock--


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

????????????????????????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????
??????


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

RE: [HAPI-devel] deep copy functionality

[Abraham T. <ti...@ta...>]

I would do both, and use the implementation as a pattern for copying
just about everything else that needs to be copied.  Today we're
thinking about deep copy for the purposes of echoing segments and
messages. Tomorrow, who knows why we'll be copying.  Much like the
clone() method in many java class interfaces, the uses are varied and
many.  

Does the pretense of the clone() method apply to hl7 message components
?

Abraham Tio
MD, Chief Technologist
Tacteon LTD.
http://www.tacteonltd.com


-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...] On Behalf Of Glock
Sent: Friday, December 14, 2001 8:02 AM
To: hl7...@li...
Subject: [HAPI-devel] deep copy functionality

All:

I'm working on the deep copy functionality (task 42332) and am seeking
feedback on where this should be implemented. I'm leaning toward making
it part of the Message interface since it must act on an entire segment
in addition to select fields.  Another option is to simply view the
segment as comprised of "all fields" and make it part of Segment
interface.

Thanks,
John Glock--


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

????????????????????????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????
??????

[HAPI-devel] deep copy functionality

[Glock <gl...@tc...>]

All:

I'm working on the deep copy functionality (task 42332) and am seeking
feedback on where this should be implemented. I'm leaning toward making
it part of the Message interface since it must act on an entire segment
in addition to select fields.  Another option is to simply view the
segment as comprised of "all fields" and make it part of Segment
interface.

Thanks,
John Glock--

[HAPI-devel] HL7 documentation

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

Good news ... for those without HL7 memberships, you can download the
next-to-latest version (2.3.1) from http://www.hl7.org/Library/standards.cfm
- scroll about two fifths of the way down the page and look for "HL7
Standard Version 2.3.1 -- Draft Version in zip".  If you are interested in
Lower Layer Protocols you need to look at appendix C of the Implementation
Guide, for which you have to scroll about three fifths of the way down the
page and look for "Version 2.3 Implementation Guide in PDF format"

Changes between 2.3.1 and 2.4 (the current version) are pretty minor, so
this is probably all you need for quite a while.  I think the vast majority
of production systems are still using 2.3.1 or earlier anyway.  

Bryan

[HAPI-devel] Version 0.1 ready

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

I just uploaded the first release of HAPI.  Please check it out and let me
know of any problems, bugs, etc.  

Probably the easiest way to get HAPI to do something is to give it an HL7
message to parse and display in a UI.  The only complete message class
included with the release is ACK.  If anyone has the HL7 normative DB you
can generate source for all the other classes (using
ca.uhn.hl7v2.sourcegen.SourceGenerator), but otherwise start with ACK.  Here
is a little ACK message you can parse: 

MSH|^~\&|Fake Sending App|Fake Sending Facility||Fake Receiving
Facility|200108151718||ACK^A01^ACK|20|P|2.3
MSA|AA

You can see this message in a JTree by saving it in a file (let's call it
"ack.txt") and running TreePanel from the command line, like this: 

java -classpath hapi.jar ca.uhn.hl7v2.view.TreePanel ack.txt

This should open up a window and show the message in a tree.  This is much
more exciting with a bigger message, but you get the idea.    

Some of you have mentioned parts that you want to work on.  Of course,
everyone is welcome to work on whatever they want, but if you want to avoid
overlap let me know what you are doing and I will try to keep track.  

I'll be filling up the task list and the CVS repository soon.  Let me know
if you run into trouble or have any questions.  

Bryan

[HAPI-devel] HL7 specs

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

Hi guys, 

I promise I'll post some code tomorrow ... 

We have a documentation issue.  At the moment only Neal and I belong to an
organization that has legitimate access to HL7 documentation (through UHN's
membership).  Two new guys emailed me today to express an interest in
contributing to HAPI ... if they work out, there will be six of us, four
without HL7 documentation.  

It seems to me like the simplest way to fix this would be to incorporate
HAPI and join HL7 Canada as an organization.  This way we would be free to
distribute the specs amongst ourselves.  I think this costs about $300 USD.
I am perfectly willing to donate this, but I'll see if UHN would like to
make a donation as well.  

Does this make sense?  Anyone want to do footwork in terms of incorporation,
getting a domain name, getting an HL7 membership, etc.?  

Bryan