HL7 documentation/tutorials for programmers ?

HL7 documentation/tutorials for programmers ?


Hello,

I spoke with someone about handling HL7 files. I have searched the web
but have not found any documentation that is geared mainly twards
programmers. I'm not sure I need to understand all the high level
details of why it was designed the way it was all that it can do for
doctors and so on. I just need to know some of the lower level
technical and architectural details of the tools available, file
formats, typical data flow between client and server machines and
things of that nature. What I have seen looks very complex with a high
level explanation that may be of some interest to me at some point, but
initially I need a technical description of the system as it applies to
programmers etc.

I would appreciate it if any one could point me to some web istes with
some documentaion of this sort.

Thanks

Re: HL7 documentation/tutorials for programmers ?

Here's the skinny.
HL7 is a protocol for communicating healthcare information. It is
based on the idea of "events" that occur within the framework of a
healthcare institution's "encounter" with a patient. You can imagine
the scenario. Patient presents to the ER and is registered (an event).
The doctor orders some lab tests (events). He gets back some results
(events). He decides to admit the patient to the hospital (another
event). They tranfer him to ward 2b in room 2047 bed 1 (an event).
They order aspirin for him (You guessed it...). He feels much better,
the doctor discharges him (an event). You get the picture.
These "events" are represented by "transactions" that are routed
throughout the hospital (or to a group, clinic, or RHIO (later)).
These transactions are blocks of text that communicate the information
required for everyone to be informed of the event. The text blocks are
sent (usually) by using a block level protocol over TCP or serial.
This protocol is called the MLLP or Minimal Lower Level Protocol. MLLP
is defined as a byte stream that starts with the byte 0b hex. There is
then the block of text, followed by 1c and 0d hex. That provides the
"framing" characters that define where a message starts and where it
ends.
There will potentially be an "Ack" message sent back in the other
direction that is a block of text that is an application level
acknowledgement that the information was received. Don't confuse an
HL7 "ack" with the "ack/nak" that sometimes occurs in ASTM data
streams. The HL7 ack is a full text message in the same protocol,
following the same rules.
Now, deeper into it. The HL7 message is a number of lines of text
that are terminated with 0d hex (CR). The end of the message is marked
with CRLF (0d0a). These "lines" are called "segments". The message is
constructed of a number of these segments, which individually
communicate a particular aspect of the event. Remember from school?
Who, What, When, Where, Why? That's what segments are. The message
always starts with an MSH. This is the "MeSsageHeader" segment. The
byte right after the MSH is the "field seperator" byte. This byte is
used throughout the message to delimit the fields in the segment. The
entire message can be broken down as positional in nature. If I tell
you that the Patient name is stored in PID[5], that means that you use
the field seperator to break the PID segment into fields, and the 5th
field (zero based), is the name. (The characters PID in the segment
are field 0.) In the MSH, the fourth character is the field sep char.
The 5, 6, 7, and 8 bytes are the "Component Separator", "SubComponent
Seperator", the "Repetition Seperator", and the "Escape Character".
Use of these defined bytes in the message are defined at
* w w w .medinfo.rochester.edu/hl7/v2.3/ch200019.htm#I23 .
As we go beyond this point, we would be starting a book. I would
recommend that you study the "Rochester" links below for the message
definitions. Stick with the v2.3 definition while you are starting
out, as I don't think that anyone has really implemented v3 yet. It
will be important for you to get examples of all the transaction types
that you intend to work with, and realize that each vendor interprets
and implements the messaging a little differently. Many healthcare
organizations use an HL7 "messaging engine" to translate these vendor
halucinations (Why would they ever want to do THAT?) to or from
someting a bit more sane. You might want to look at the Mirth project
if you are interested in an engine. If you have specific questions,
you can ask me at Terry (add a K here) at (dont send spam) thml dot
com ...




* w w w .7scan . com /
* hl7api.sourceforge . net /
* w w w .medinfo.rochester.edu/hl7/v2.3/httoc.htm
* w w w .medinfo.rochester.edu/hl7/v3.0/mdf_toc.htm
* nule.org/wp/?page_id=62
* aurora.regenstrief.org/
* sourceforge . net /projects/hl7inspector
* w w w .hl7.org.au/HL7-Tools.htm
* w w w .mirthproject.org/index.php?option=com_frontpage&Itemid=1


wbsurfver@yahoo . com wrote:
> Hello,
>
> I spoke with someone about handling HL7 files. I have searched the web
> but have not found any documentation that is geared mainly twards
> programmers. I'm not sure I need to understand all the high level
> details of why it was designed the way it was all that it can do for
> doctors and so on. I just need to know some of the lower level
> technical and architectural details of the tools available, file
> formats, typical data flow between client and server machines and
> things of that nature. What I have seen looks very complex with a high
> level explanation that may be of some interest to me at some point, but
> initially I need a technical description of the system as it applies to
> programmers etc.
>
> I would appreciate it if any one could point me to some web istes with
> some documentaion of this sort.
>
> Thanks

Re: HL7 documentation/tutorials for programmers ?

Thanks for all that information. Do you know if the Perl HL7 toolkit is
good for this ? I am concerned because I have read the standard is
confusing and some claim not that well put togther/ I wonder if some
set of tools I might use may not be able to handle some of the
transactions because of too much flexibility in the standard for
instance causes the tool to croak on certain messages for instance.


Isn't there some kind of HL7 xml format ? I found some xml files on
the internet and some other web sites that seem to discuss that.

Here is a smaller file I found that looks like xml and I can get a
Perl XML parser to parse it with very few changes. The name space near
the top refers to "hl7" as well.

<?xml version="1.0" encoding="UTF-8" ?>
<!-- The element below is the content of the first payload
container -->
<PRSC_IN080000UK06 xmlns="urn:hl7-org:v3"
xmlns:fo= " * w w w .w3.org/1999/XSL/Format"
xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi=" * w w w .w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:hl7-org:v3../Schemas/PRSC_IN080000UK06.xsd">
<id root="A6C66142-1DD1-11B2-9062-8F5E91AA2DD7"/>
<creationTime value="20040913030014" />
<versionCode code="V3NPfIT2.0" />
<interactionId root="2.16.840.1.113883.2.1.3.2.4.12"
extension="PRSC_IN080000UK06" />
<processingCode code="P" />
<processingModeCode code="T" />
<acceptAckCode code="NE" />
<communicationFunctionRcv>
<device>
<id root="2.16.840.1.113883.2.1.3.2.4.10" extension="RJR-0000217" />
</device>
</communicationFunctionRcv>
<communicationFunctionSnd>
<device>
<id root="2.16.840.1.113883.2.1.3.2.4.10" extension="T141A-0000202" />
</device>
</communicationFunctionSnd>
<ControlActEvent>
<subject>
<RequestAvailableSlots classCode="SPLY" moodCode="RQO">
<id root="A6C66142-1DD1-11B2-9062-8F5E91AA2DD7" />
<effectiveTime>
<low value="200411090000" inclusive="true" />
<high value="200412100000" inclusive="false" />
</effectiveTime>
<location typeCode="LOC">
<clinic classCode="SDLOC">
<id root="2.16.840.1.113883.2.1.3.2.4.2" extension="DAVID"
displayable="true" />
</clinic>
</location>
</RequestAvailableSlots>
</subject>
</ControlActEvent>
</PRSC_IN080000UK06>


Medbob wrote:
> Here's the skinny.
> HL7 is a protocol for communicating healthcare information. It is
> based on the idea of "events" that occur within the framework of a
> healthcare institution's "encounter" with a patient. You can imagine
> the scenario. Patient presents to the ER and is registered (an event).
> The doctor orders some lab tests (events). He gets back some results
> (events). He decides to admit the patient to the hospital (another
> event). They tranfer him to ward 2b in room 2047 bed 1 (an event).
> They order aspirin for him (You guessed it...). He feels much better,
> the doctor discharges him (an event). You get the picture.
> These "events" are represented by "transactions" that are routed
> throughout the hospital (or to a group, clinic, or RHIO (later)).
> These transactions are blocks of text that communicate the information
> required for everyone to be informed of the event. The text blocks are
> sent (usually) by using a block level protocol over TCP or serial.
> This protocol is called the MLLP or Minimal Lower Level Protocol. MLLP
> is defined as a byte stream that starts with the byte 0b hex. There is
> then the block of text, followed by 1c and 0d hex. That provides the
> "framing" characters that define where a message starts and where it
> ends.
> There will potentially be an "Ack" message sent back in the other
> direction that is a block of text that is an application level
> acknowledgement that the information was received. Don't confuse an
> HL7 "ack" with the "ack/nak" that sometimes occurs in ASTM data
> streams. The HL7 ack is a full text message in the same protocol,
> following the same rules.
> Now, deeper into it. The HL7 message is a number of lines of text
> that are terminated with 0d hex (CR). The end of the message is marked
> with CRLF (0d0a). These "lines" are called "segments". The message is
> constructed of a number of these segments, which individually
> communicate a particular aspect of the event. Remember from school?
> Who, What, When, Where, Why? That's what segments are. The message
> always starts with an MSH. This is the "MeSsageHeader" segment. The
> byte right after the MSH is the "field seperator" byte. This byte is
> used throughout the message to delimit the fields in the segment. The
> entire message can be broken down as positional in nature. If I tell
> you that the Patient name is stored in PID[5], that means that you use
> the field seperator to break the PID segment into fields, and the 5th
> field (zero based), is the name. (The characters PID in the segment
> are field 0.) In the MSH, the fourth character is the field sep char.
> The 5, 6, 7, and 8 bytes are the "Component Separator", "SubComponent
> Seperator", the "Repetition Seperator", and the "Escape Character".
> Use of these defined bytes in the message are defined at
> * w w w .medinfo.rochester.edu/hl7/v2.3/ch200019.htm#I23 .
> As we go beyond this point, we would be starting a book. I would
> recommend that you study the "Rochester" links below for the message
> definitions. Stick with the v2.3 definition while you are starting
> out, as I don't think that anyone has really implemented v3 yet. It
> will be important for you to get examples of all the transaction types
> that you intend to work with, and realize that each vendor interprets
> and implements the messaging a little differently. Many healthcare
> organizations use an HL7 "messaging engine" to translate these vendor
> halucinations (Why would they ever want to do THAT?) to or from
> someting a bit more sane. You might want to look at the Mirth project
> if you are interested in an engine. If you have specific questions,
> you can ask me at Terry (add a K here) at (dont send spam) thml dot
> com ...
>
>
>
>
> * w w w .7scan . com /
> * hl7api.sourceforge . net /
> * w w w .medinfo.rochester.edu/hl7/v2.3/httoc.htm
> * w w w .medinfo.rochester.edu/hl7/v3.0/mdf_toc.htm
> * nule.org/wp/?page_id=62
> * aurora.regenstrief.org/
> * sourceforge . net /projects/hl7inspector
> * w w w .hl7.org.au/HL7-Tools.htm
> * w w w .mirthproject.org/index.php?option=com_frontpage&Itemid=1
>
>
> wbsurfver@yahoo . com wrote:
> > Hello,
> >
> > I spoke with someone about handling HL7 files. I have searched the web
> > but have not found any documentation that is geared mainly twards
> > programmers. I'm not sure I need to understand all the high level
> > details of why it was designed the way it was all that it can do for
> > doctors and so on. I just need to know some of the lower level
> > technical and architectural details of the tools available, file
> > formats, typical data flow between client and server machines and
> > things of that nature. What I have seen looks very complex with a high
> > level explanation that may be of some interest to me at some point, but
> > initially I need a technical description of the system as it applies to
> > programmers etc.
> >
> > I would appreciate it if any one could point me to some web istes with
> > some documentaion of this sort.
> >
> > Thanks

Re: HL7 documentation/tutorials for programmers ?

Thanks for all that information. Do you know if the Perl HL7 toolkit is
good for this ? I am concerned because I have read the standard is
confusing and some claim not that well put togther/ I wonder if some
set of tools I might use may not be able to handle some of the
transactions because of too much flexibility in the standard for
instance causes the tool to croak on certain messages for instance.


Isn't there some kind of HL7 xml format ? I found some xml files on
the internet and some other web sites that seem to discuss that.

Here is a smaller file I found that looks like xml and I can get a
Perl XML parser to parse it with very few changes. The name space near
the top refers to "hl7" as well.

<?xml version="1.0" encoding="UTF-8" ?>
<!-- The element below is the content of the first payload
container -->
<PRSC_IN080000UK06 xmlns="urn:hl7-org:v3"
xmlns:fo= " * w w w .w3.org/1999/XSL/Format"
xmlns:voc="urn:hl7-org:v3/voc"
xmlns:xsi=" * w w w .w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:hl7-org:v3../Schemas/PRSC_IN080000UK06.xsd">
<id root="A6C66142-1DD1-11B2-9062-8F5E91AA2DD7"/>
<creationTime value="20040913030014" />
<versionCode code="V3NPfIT2.0" />
<interactionId root="2.16.840.1.113883.2.1.3.2.4.12"
extension="PRSC_IN080000UK06" />
<processingCode code="P" />
<processingModeCode code="T" />
<acceptAckCode code="NE" />
<communicationFunctionRcv>
<device>
<id root="2.16.840.1.113883.2.1.3.2.4.10" extension="RJR-0000217" />
</device>
</communicationFunctionRcv>
<communicationFunctionSnd>
<device>
<id root="2.16.840.1.113883.2.1.3.2.4.10" extension="T141A-0000202" />
</device>
</communicationFunctionSnd>
<ControlActEvent>
<subject>
<RequestAvailableSlots classCode="SPLY" moodCode="RQO">
<id root="A6C66142-1DD1-11B2-9062-8F5E91AA2DD7" />
<effectiveTime>
<low value="200411090000" inclusive="true" />
<high value="200412100000" inclusive="false" />
</effectiveTime>
<location typeCode="LOC">
<clinic classCode="SDLOC">
<id root="2.16.840.1.113883.2.1.3.2.4.2" extension="DAVID"
displayable="true" />
</clinic>
</location>
</RequestAvailableSlots>
</subject>
</ControlActEvent>
</PRSC_IN080000UK06>



Medbob wrote:
> Here's the skinny.
> HL7 is a protocol for communicating healthcare information. It is
> based on the idea of "events" that occur within the framework of a
> healthcare institution's "encounter" with a patient. You can imagine
> the scenario. Patient presents to the ER and is registered (an event).
> The doctor orders some lab tests (events). He gets back some results
> (events). He decides to admit the patient to the hospital (another
> event). They tranfer him to ward 2b in room 2047 bed 1 (an event).
> They order aspirin for him (You guessed it...). He feels much better,
> the doctor discharges him (an event). You get the picture.
> These "events" are represented by "transactions" that are routed
> throughout the hospital (or to a group, clinic, or RHIO (later)).
> These transactions are blocks of text that communicate the information
> required for everyone to be informed of the event. The text blocks are
> sent (usually) by using a block level protocol over TCP or serial.
> This protocol is called the MLLP or Minimal Lower Level Protocol. MLLP
> is defined as a byte stream that starts with the byte 0b hex. There is
> then the block of text, followed by 1c and 0d hex. That provides the
> "framing" characters that define where a message starts and where it
> ends.
> There will potentially be an "Ack" message sent back in the other
> direction that is a block of text that is an application level
> acknowledgement that the information was received. Don't confuse an
> HL7 "ack" with the "ack/nak" that sometimes occurs in ASTM data
> streams. The HL7 ack is a full text message in the same protocol,
> following the same rules.
> Now, deeper into it. The HL7 message is a number of lines of text
> that are terminated with 0d hex (CR). The end of the message is marked
> with CRLF (0d0a). These "lines" are called "segments". The message is
> constructed of a number of these segments, which individually
> communicate a particular aspect of the event. Remember from school?
> Who, What, When, Where, Why? That's what segments are. The message
> always starts with an MSH. This is the "MeSsageHeader" segment. The
> byte right after the MSH is the "field seperator" byte. This byte is
> used throughout the message to delimit the fields in the segment. The
> entire message can be broken down as positional in nature. If I tell
> you that the Patient name is stored in PID[5], that means that you use
> the field seperator to break the PID segment into fields, and the 5th
> field (zero based), is the name. (The characters PID in the segment
> are field 0.) In the MSH, the fourth character is the field sep char.
> The 5, 6, 7, and 8 bytes are the "Component Separator", "SubComponent
> Seperator", the "Repetition Seperator", and the "Escape Character".
> Use of these defined bytes in the message are defined at
> * w w w .medinfo.rochester.edu/hl7/v2.3/ch200019.htm#I23 .
> As we go beyond this point, we would be starting a book. I would
> recommend that you study the "Rochester" links below for the message
> definitions. Stick with the v2.3 definition while you are starting
> out, as I don't think that anyone has really implemented v3 yet. It
> will be important for you to get examples of all the transaction types
> that you intend to work with, and realize that each vendor interprets
> and implements the messaging a little differently. Many healthcare
> organizations use an HL7 "messaging engine" to translate these vendor
> halucinations (Why would they ever want to do THAT?) to or from
> someting a bit more sane. You might want to look at the Mirth project
> if you are interested in an engine. If you have specific questions,
> you can ask me at Terry (add a K here) at (dont send spam) thml dot
> com ...
>
>
>
>
> * w w w .7scan . com /
> * hl7api.sourceforge . net /
> * w w w .medinfo.rochester.edu/hl7/v2.3/httoc.htm
> * w w w .medinfo.rochester.edu/hl7/v3.0/mdf_toc.htm
> * nule.org/wp/?page_id=62
> * aurora.regenstrief.org/
> * sourceforge . net /projects/hl7inspector
> * w w w .hl7.org.au/HL7-Tools.htm
> * w w w .mirthproject.org/index.php?option=com_frontpage&Itemid=1
>
>
> wbsurfver@yahoo . com wrote:
> > Hello,
> >
> > I spoke with someone about handling HL7 files. I have searched the web
> > but have not found any documentation that is geared mainly twards
> > programmers. I'm not sure I need to understand all the high level
> > details of why it was designed the way it was all that it can do for
> > doctors and so on. I just need to know some of the lower level
> > technical and architectural details of the tools available, file
> > formats, typical data flow between client and server machines and
> > things of that nature. What I have seen looks very complex with a high
> > level explanation that may be of some interest to me at some point, but
> > initially I need a technical description of the system as it applies to
> > programmers etc.
> >
> > I would appreciate it if any one could point me to some web istes with
> > some documentaion of this sort.
> >
> > Thanks

Re: HL7 documentation/tutorials for programmers ?

What you have there, my friend, looks like HL7 v3. My advise to you is
that if you have to parse this bucket of stuff, you need to pony up the
$1500 to become a member of HL7.
There is nothing in v2 HL7 that will help you with this type of
message, because all of the rules have changed. v3 Is not in any way
shape or form related to v2. They took out a clean sheet of paper on
this one. There may be some similarities, but they are only based on
the fact that v2 and v3 are describing some of the same processes.
While I have not worked with v3 yet, and it is a huge black box to me,
it seems to me to be too big, complicated, and dense to be practical
right now. If you can push your project toward v2, I would put my
money on that. If it is v3 or bust, you will need an HL7 membership,
Rational Rose, and several other commercial packages to work with it.
I don't know of any Open Source project that is working with v3...
(Don't know about Mirth, take a look)
If you are working with v2, the perl toolkit looks like a good package,
but you'll need to grok it. It is a truism that the v2 standard is
really more of a suggestion. Vendors interpret it in all sorts of
silly ways. It does not surprise me that some would say that "Toolkit
A does not handle all types of messages" because vendors do all sorts
of things. If you have a specific application in mind, you will need
to get, what are known in the business as "Interface Specifications" or
HL7 Specs for the particular vendor endpoint. These specs specify what
messages are used, which subset of fields are valued, and what is sent
and expected. Any vendor that you wish to work with will be able to
provide an interface spec for you.
If you just want to throw an "HL7 Interface" on your Acme Widget, you
will need to be able to draw on a deep understanding of both HL7 and
the Healthcare Domain to be successful.

My bottom line, "Good Luck, You will need it!"


wbsurfver@yahoo . com wrote:
> Thanks for all that information. Do you know if the Perl HL7 toolkit is
> good for this ? I am concerned because I have read the standard is
> confusing and some claim not that well put togther/ I wonder if some
> set of tools I might use may not be able to handle some of the
> transactions because of too much flexibility in the standard for
> instance causes the tool to croak on certain messages for instance.
>
>
> Isn't there some kind of HL7 xml format ? I found some xml files on
> the internet and some other web sites that seem to discuss that.
>
> Here is a smaller file I found that looks like xml and I can get a
> Perl XML parser to parse it with very few changes. The name space near
> the top refers to "hl7" as well.
>
> <?xml version="1.0" encoding="UTF-8" ?>
> <!-- The element below is the content of the first payload
> container -->
> <PRSC_IN080000UK06 xmlns="urn:hl7-org:v3"
> xmlns:fo= " * w w w .w3.org/1999/XSL/Format"
> xmlns:voc="urn:hl7-org:v3/voc"
> xmlns:xsi=" * w w w .w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:hl7-org:v3../Schemas/PRSC_IN080000UK06.xsd">
> <id root="A6C66142-1DD1-11B2-9062-8F5E91AA2DD7"/>
> <creationTime value="20040913030014" />
> <versionCode code="V3NPfIT2.0" />
> <interactionId root="2.16.840.1.113883.2.1.3.2.4.12"
> extension="PRSC_IN080000UK06" />
> <processingCode code="P" />
> <processingModeCode code="T" />
> <acceptAckCode code="NE" />
> <communicationFunctionRcv>
> <device>
> <id root="2.16.840.1.113883.2.1.3.2.4.10" extension="RJR-0000217" />
> </device>
> </communicationFunctionRcv>
> <communicationFunctionSnd>
> <device>
> <id root="2.16.840.1.113883.2.1.3.2.4.10" extension="T141A-0000202" />
> </device>
> </communicationFunctionSnd>
> <ControlActEvent>
> <subject>
> <RequestAvailableSlots classCode="SPLY" moodCode="RQO">
> <id root="A6C66142-1DD1-11B2-9062-8F5E91AA2DD7" />
> <effectiveTime>
> <low value="200411090000" inclusive="true" />
> <high value="200412100000" inclusive="false" />
> </effectiveTime>
> <location typeCode="LOC">
> <clinic classCode="SDLOC">
> <id root="2.16.840.1.113883.2.1.3.2.4.2" extension="DAVID"
> displayable="true" />
> </clinic>
> </location>
> </RequestAvailableSlots>
> </subject>
> </ControlActEvent>
> </PRSC_IN080000UK06>
>
>
>
> Medbob wrote:
> > Here's the skinny.
> > HL7 is a protocol for communicating healthcare information. It is
> > based on the idea of "events" that occur within the framework of a
> > healthcare institution's "encounter" with a patient. You can imagine
> > the scenario. Patient presents to the ER and is registered (an event).
> > The doctor orders some lab tests (events). He gets back some results
> > (events). He decides to admit the patient to the hospital (another
> > event). They tranfer him to ward 2b in room 2047 bed 1 (an event).
> > They order aspirin for him (You guessed it...). He feels much better,
> > the doctor discharges him (an event). You get the picture.
> > These "events" are represented by "transactions" that are routed
> > throughout the hospital (or to a group, clinic, or RHIO (later)).
> > These transactions are blocks of text that communicate the information
> > required for everyone to be informed of the event. The text blocks are
> > sent (usually) by using a block level protocol over TCP or serial.
> > This protocol is called the MLLP or Minimal Lower Level Protocol. MLLP
> > is defined as a byte stream that starts with the byte 0b hex. There is
> > then the block of text, followed by 1c and 0d hex. That provides the
> > "framing" characters that define where a message starts and where it
> > ends.
> > There will potentially be an "Ack" message sent back in the other
> > direction that is a block of text that is an application level
> > acknowledgement that the information was received. Don't confuse an
> > HL7 "ack" with the "ack/nak" that sometimes occurs in ASTM data
> > streams. The HL7 ack is a full text message in the same protocol,
> > following the same rules.
> > Now, deeper into it. The HL7 message is a number of lines of text
> > that are terminated with 0d hex (CR). The end of the message is marked
> > with CRLF (0d0a). These "lines" are called "segments". The message is
> > constructed of a number of these segments, which individually
> > communicate a particular aspect of the event. Remember from school?
> > Who, What, When, Where, Why? That's what segments are. The message
> > always starts with an MSH. This is the "MeSsageHeader" segment. The
> > byte right after the MSH is the "field seperator" byte. This byte is
> > used throughout the message to delimit the fields in the segment. The
> > entire message can be broken down as positional in nature. If I tell
> > you that the Patient name is stored in PID[5], that means that you use
> > the field seperator to break the PID segment into fields, and the 5th
> > field (zero based), is the name. (The characters PID in the segment
> > are field 0.) In the MSH, the fourth character is the field sep char.
> > The 5, 6, 7, and 8 bytes are the "Component Separator", "SubComponent
> > Seperator", the "Repetition Seperator", and the "Escape Character".
> > Use of these defined bytes in the message are defined at
> > * w w w .medinfo.rochester.edu/hl7/v2.3/ch200019.htm#I23 .
> > As we go beyond this point, we would be starting a book. I would
> > recommend that you study the "Rochester" links below for the message
> > definitions. Stick with the v2.3 definition while you are starting
> > out, as I don't think that anyone has really implemented v3 yet. It
> > will be important for you to get examples of all the transaction types
> > that you intend to work with, and realize that each vendor interprets
> > and implements the messaging a little differently. Many healthcare
> > organizations use an HL7 "messaging engine" to translate these vendor
> > halucinations (Why would they ever want to do THAT?) to or from
> > someting a bit more sane. You might want to look at the Mirth project
> > if you are interested in an engine. If you have specific questions,
> > you can ask me at Terry (add a K here) at (dont send spam) thml dot
> > com ...
> >
> >
> >
> >
> > * w w w .7scan . com /
> > * hl7api.sourceforge . net /
> > * w w w .medinfo.rochester.edu/hl7/v2.3/httoc.htm
> > * w w w .medinfo.rochester.edu/hl7/v3.0/mdf_toc.htm
> > * nule.org/wp/?page_id=62
> > * aurora.regenstrief.org/
> > * sourceforge . net /projects/hl7inspector
> > * w w w .hl7.org.au/HL7-Tools.htm
> > * w w w .mirthproject.org/index.php?option=com_frontpage&Itemid=1
> >
> >
> > wbsurfver@yahoo . com wrote:
> > > Hello,
> > >
> > > I spoke with someone about handling HL7 files. I have searched the web
> > > but have not found any documentation that is geared mainly twards
> > > programmers. I'm not sure I need to understand all the high level
> > > details of why it was designed the way it was all that it can do for
> > > doctors and so on. I just need to know some of the lower level
> > > technical and architectural details of the tools available, file
> > > formats, typical data flow between client and server machines and
> > > things of that nature. What I have seen looks very complex with a high
> > > level explanation that may be of some interest to me at some point, but
> > > initially I need a technical description of the system as it applies to
> > > programmers etc.
> > >
> > > I would appreciate it if any one could point me to some web istes with
> > > some documentaion of this sort.
> > >
> > > Thanks