Lists all the packages (user-definable) where classes for standard and custom
messages may be found. Each package has subpackages called "message",
"group", "segment", and "datatype" in which classes for these message elements
can be found.
At a minimum, this method returns the standard package for the
given version. For example, for version 2.4, the package list contains
ca.uhn.hl7v2.model.v24
. In addition, user-defined packages may be specified
for custom messages.
If you define custom message classes, and want Parsers to be able to
find them, you must register them as follows (otherwise you will get an exception when
the corresponding messages are parsed). For each HL7 version you want to support, you must
put a text file on your classpath, under the folder /custom_packages, named after the version. For example,
for version 2.4, you might put the file "custom_packages/2.4" in your application JAR. Each line in the
file should name a package to search for message classes of that version. For example, if you
work at foo.org, you might create a v2.4 message structure called "ZFO" and define it in the class
org.foo.hl7.custom.message.ZFO. In order for parsers to find this message
class, you would need to enter the following line in custom_packages/2.4:
org.foo.hl7.custom
Packages are searched in the order specified. The standard package for a given version
is searched last, allowing you to override the default implementation. Please note that
if you create custom classes for messages, segments, etc., their names must correspond exactly
to their names in the message text. For example, if you subclass the QBP segment in order to
add your own fields, your subclass must also be called QBP. although it will obviously be in
a different package. To make sure your class is used instead of the default implementation,
put your package in the package list. User-defined packages are searched first, so yours
will be found first and used.
It is important to note that there can only be one implementation of a particular message
structure (i.e. one class with the message structure name, regardless of its package) among
the packages defined as per the packageList()
method. If there are duplicates
(e.g. two ADT_A01 classes) the first one in the search order will always be used. However,
this restriction only applies to message classes, not segment classes, etc. This is because
classes representing parts of a message are referenced explicitly in the code for the message
class, rather than being looked up (using findMessageClass() ) based on the String value of MSH-9.