There is a HL7 test server, to which you can send HL7 messages via
e-mail. The server is an application of
ProtoGen/HL7,
an HL7
Implementation generator, which is driven by the actual HL7 standard
definition itself. Therefore it is highly compliant to the
standard. And, in terms of messages/events, it implements the complete
HL7 standard. Thus it seems just to regard this as a -- though
inofficial -- reference implementation. You can now test your HL7
messages and my implementation :-) by sending a HL7 message within an
e-mail to the following address:
This service does now comply to the umpcoming internet standard RFC 1767 - MIME Encapsulation of EDI Objects. You can send single- or multi-part messages of the following content types:
If you send MIME EDI messages, you can do this with any transfer encoding, including 7bit, base64, and x-uue. The server will allways reply MIME style with ``Application/EDI-HL7'' content type. Transfer encoding to MIME requests will be ``quoted-printable''. MIME replies to non-MIME requests will be sent in 7bit, thus, the non-MIME function is as usual.
If you send text/plain (or unclassified non-MIME) mail, then just put your message into the mail with no leading or trailing text! Even signatures are a problem! Blank lines will be skipped. Segment delimiters can be CR or LF. Don't break lines in the middle of segments!
Here is an example transaction:
From: gusw (Gunther Schadow) To: hl7@uks3p.ukbf.fu-berlin.de Subject: HL7 test MSH|^~\&|RADIS1||DMCRES||19940502161633||ORU|19940502161633|D|2.2|964||AL|AL PID|||N00803||RADIOLOGY^INPATIENT^SIX||19520606|F||A||||||||003555 PV1||I|N77^7714^01|||||||OB OBR|1|003555.0015.001^DMCRES|0000000566^RADIS1|37953^CT CHEST^L|||199405021545|||||||||||||0000763||||CT|P||||||R/O TUMOR|202300^BAKER^MARK^E|||01^LOCHLEAR, JUDY OBX||TX|FIND^FINDINGS^L|1|This is a test on 05/02/94. OBX||TX|FIND^FINDINGS^L|2|This is a test for the CRR. OBX||TX|FIND^FINDINGS^L|3|This is a test result to generate multiple obr's to check the cost OBX||TX|FIND^FINDINGS^L|4|display for multiple exams. OBX||TX|FIND^FINDINGS^L|5|APPROVING MD: OBR|2|^DMCRES|0000000567^RADIS1|37956^CT ABDOMEN^L|||199405021550|||||||||||||0000763|||||P||||||R/O TUMOR|202300^BAKER^MARK^E|||01^LOCHLEAR, JUDY OBR|3|^DMCRES|0000000568^RADIS1|37881^CT PELVIS (LIMITED)^L|||199405021551|||||||||||||0000763|||||P||||||R/O TUMOR|202300^BAKER^MARK^E|||01^LOCHLEAR, JUDY
Return-Path: <hl7@uks3p.ukbf.fu-berlin.de>
Received: by fub46.zedat.fu-berlin.de (Smail3.1.29.1)
from uks3p.ukbf.fu-berlin.de (160.45.175.3) with smtp
id <m0tZ5Nr-000dToC>; Mon, 8 Jan 96 01:24:19 +0100 (MET)
Message-Id: <m0tZ5Nr-000dToC@fub46.zedat.fu-berlin.de>
Received: by uks3p.ukbf.fu-berlin.de
(1.37.109.16/16.2) id AA260350708; Mon, 8 Jan 1996 01:25:08 +0100
Date: Mon, 8 Jan 1996 01:25:08 +0100
From: HL7 test service <hl7@uks3p.ukbf.fu-berlin.de>
MIME-Version: 1.0
To: gunther@aurora.rg.iupui.edu
Subject: Re: HL7 test
Content-type: application/edi-hl7
Content-Description: An object packed by metasend
Content-Transfer-Encoding: 7bit
MSH|^~\&|HL7TEST||RADIS1||19961003020407+0100^S||ACK^|RES16024|P|2.2|||||
MSA|AA|19940502161633|message accepted|||
ERR|^5^^&WARNING: undefined segment `CHE'&&&&^ORU.2[1].2[1].3~^6^^&WARNING: undefined segment `TUM'&&&&^ORU.2[1].2[1].3~OBX^7^11^&WARNING: missing required field 10 `observ result status'&&&&^ORU.2[1].2[1].4[1].1.OBX[11]("observ result status")~OBX^8^11^&WARNING: missing required field 10 `observ result status'&&&&^ORU.2[1].2[1].4[2].1.OBX[11]("observ result status")~OBX^9^11^&WARNING: missing required field 10 `observ result status'&&&&^ORU.2[1].2[1].4[3].1.OBX[11]("observ result status")~^10^^&WARNING: undefined segment `obr'&&&&^ORU.2[1].2[1].4[3].2~^11^^&WARNING: undefined segment `che'&&&&^ORU.2[1].2[1].4[3].2~OBX^12^11^&WARNING: missing required field 10 `observ result status'&&&&^ORU.2[1].2[1].4[4].1.OBX[11]("observ result status")~OBX^13^11^&WARNING: missing required field 10 `observ result status'&&&&^ORU.2[1].2[1].4[5].1.OBX[11]("observ result status")~^15^^&WARNING: undefined segment `ABD'&&&&^ORU.2[1].2[2].3~^16^^&WARNING: undefined segment `TUM'&&&&^ORU.2[1].2[2].3~^18^^&WARN
ING: undefined segment `(LI'&&&&^ORU.2[1].2[3].3~^19^^&WARNING: undefined segment `TUM'&&&&^ORU.2[1].2[3].3
The ERR segment contains a repeated field with the "error code and location" type. This is a composite, with the following components:
ST segment id NM sequence NM field position CE code identifying error ST full path
The `sequence' is the absolute number of the segment in the message counting from 1. The `field position' gives the field number counting from 1. The `code identifying error' has just the `text' component filled out, no error codes are submitted. This text field contains a human readable message. The component named `full path' is an extension to the HL7 suggestion of the `error code and location' type. It exactly references the path into the message structure that is being built. This field has the following form:
<message/event type>
{ '.' <place> [ '[' <repeatition> ']' ] }
. <segment type> '[' <field number> ']'
This means that there are items separated by dots ('.'). The first item is the message/event type. The second and following items is the path to the segment within the message structure. The last item is the segment type and again the field number within brackets ('[]').
Each step of the path into the message structure consists of at least one number, which indicates the "place" number (counted from 1) of the structure. If this place allows for repeatition, the number of repeatition (counted from 1) is set within a pair of brackets. To understand this notation you have to consider the message definition. For the above example of an ORU message, take the following definition:
ORU Level 0 Level 1 Level 2 Level 3
--------------------------------------------------
MSH <----- Place 1
{ <----- Place 2
[ <------------- Place 1
PID <------------------- Place 1
[{NTE}] <------------------- Place 2
[PV1] <------------------- Place 3
]
{ <------------- Place 2
[ORC] <------------------- Place 1
OBR <------------------- Place 2
[{NTE}] <------------------- Place 3
[{ <------------------- Place 4
OBX <------------------------ Place 1
[{NTE}] <------------------------ Place 2
}]
}
}
[DSC] <----- Place 3
The example above results in the following warnings:
OBX^5^11^&WARNING: missing required field 10 `observ result
status'&&&&^ORU.2[1].2[1].4[1].1.OBX[11]("observ result status")<ID>
OBX^6^11^&WARNING: missing required field 10 `observ result
status'&&&&^ORU.2[1].2[1].4[2].1.OBX[11]("observ result status")<ID>
OBX^7^11^&WARNING: missing required field 10 `observ result
status'&&&&^ORU.2[1].2[1].4[3].1.OBX[11]("observ result status")<ID>
OBX^8^11^&WARNING: missing required field 10 `observ result
status'&&&&^ORU.2[1].2[1].4[4].1.OBX[11]("observ result status")<ID>
OBX^9^11^&WARNING: missing required field 10 `observ result
status'&&&&^ORU.2[1].2[1].4[5].1.OBX[11]("observ result status")<ID>
This means that the segments number 5, 6, 7, 8 and 9 which are all OBX segments are missing the required field 11. The text message says 10, because it counts from 0. This inconsistency will be fixed some day. Anyway, tha field position component says 11. Now the paths: The fourth place (.4[1]) of the second place (.2[1]) of the second place (.2[1]) is the OBX group which has the OBX segments in the first place of any of it's repeatitions 4[1].1 -- 4[5].1.
Now feel free to treat the server with the most weird messages that you have.
regards
-Gunther Schadow
http://userpage.fu-berlin.de/~gusw
PS: But please note that the continuation message and segment (ADD segment) is not supported. Any message must be sent as one. IMHO there is no reason to split a message on the application layer, since `length' of a message or segment is only a valid term on the transport layer.