If you arrange your custom classes in a package structure for the custom
message (let's use our ORMIS sending system as an example) like this:
xxx.xxx.ormis.group - contains any custom group definitions
OBSERVATION.java
ORMIS_ORDER_OBSERVATION.java
PATIENT.java
VISIT.java
xxx.xxx.ormis.segment - contains any custom segments
ZTD.java
ZWL.java
xxx.xxx.ormis.message - contains the custom message structure and classes named
after the message type(s) you wish to override from the standard
ORMIS_ORU.java
ORU_R01.java
The ORU_R01.java is coded thus:
package au.gov.qld.health.sit.hl7.ormis.message;
import ca.uhn.hl7v2.HL7Exception;
import ca.uhn.hl7v2.parser.ModelClassFactory;
/**
* Enable HAPI to generate an ORU^R01 message implementation of ORMIS_ORU
* based on the values of MSH-9-1 and MSH-9-2.
*/
public class ORU_R01 extends ORMIS_ORU {
public ORU_R01(ModelClassFactory factory) throws HL7Exception {
super(factory);
}
}
To get these picked up when you are throwing messages around you use the
strategy shown in this test case:
package au.gov.qld.health.sit.hl7.ormis;
import au.gov.qld.health.sit.hl7.ormis.message.ORU_R01;
import ca.uhn.hl7v2.DefaultHapiContext;
import ca.uhn.hl7v2.HL7Exception;
import ca.uhn.hl7v2.HapiContext;
import ca.uhn.hl7v2.model.Message;
import ca.uhn.hl7v2.model.Varies;
import ca.uhn.hl7v2.parser.CustomModelClassFactory;
import ca.uhn.hl7v2.parser.GenericParser;
import ca.uhn.hl7v2.validation.builder.support.NoValidationBuilder;
import java.util.HashMap;
import java.util.Map;
import org.junit.Test;
import static org.junit.Assert.assertTrue;
public class CustomMessageParseTest {
private static final HapiContext HAPI_CONTEXT = createHapiContext();
private static final String MSH_FOR_ORU_R01 =
"MSH|^~\\&|MSH-3|MSH-4|MSH-5.1^MSH-5.2|MSH-6|20130605000036|MSH-8|ORU^R01|MSH-10|P|2.3|MSH-13|MSH-14|MSH-15|MSH-16|MSH-17|MSH-18|MSH-19";
@Test
public void testParseCustomORU_R01Message() throws HL7Exception {
Message message = new
GenericParser(HAPI_CONTEXT).parse(MSH_FOR_ORU_R01);
assertTrue("Parse custom ORU_R01 message", message instanceof ORU_R01);
}
private static HapiContext createHapiContext() {
System.setProperty(Varies.DEFAULT_OBX2_TYPE_PROP, "ST");
System.setProperty(Varies.INVALID_OBX2_TYPE_PROP, "ST");
HapiContext hapiContext = new DefaultHapiContext();
Map<String, String[]> hl7VersionPackageNamesMap = new HashMap<String,
String[]>();
String[] packageNames = {"ca.uhn.hl7v2.model.v24",
"au.gov.qld.health.sit.hl7.ormis"};
hl7VersionPackageNamesMap.put("2.3", packageNames);
hl7VersionPackageNamesMap.put("2.3.1", packageNames);
hl7VersionPackageNamesMap.put("2.4", packageNames);
hapiContext.setModelClassFactory(new
CustomModelClassFactory(hl7VersionPackageNamesMap));
hapiContext.setValidationRuleBuilder(new NoValidationBuilder());
return hapiContext;
}
}
Note that this isn't exactly 'non intrusive' and if you want to you can just
instantiate your custom message class directly and parse the message you have
received. However this method works very well where a message stream contains
several message types, of which only a few types have custom implementations.
All other message types will grab the standard version out of the happy library.
Watch for the gotcha when setting the packageNames array. If multiple listed
packages contain an implementation of a particular message type it is the
implementation contained in the LAST package in the list where that type is
found that wins out. NOT the first as we originally assumed when we first tried.
Also note that we have 'forced' messages of various HL7 version to be
implemented against vs 2.4 of the standard HAPI libraries. Mostly we do this
for convenience, and also because senders don't always update the values they
send in the messages when they have updated the structure they use. Overall we
push everything up to 2.4 because all our senders use versions below that. In
your previous posts you look to have been using vs 2.5, so you may not have to
go to these lengths.
Many thanks to Mike and Damian from our team who deep-dived the HAPI source to
work out exactly how this functions.
Hope this helps
Ian
From: Davies, Brian [mailto:[email protected]]
Sent: Friday, 18 December 2015 5:47 AM
To: [email protected]
Subject: [HAPI-devel] Custom Messages
Hi All,
I am aware that in order for custom messages to be loaded by a
CustomModelFactory they need to be registered in the eventmap. However, I am
only able to find the eventmap in ca.uhn.hl7v2.parser.eventmap with the
associated 2.5.properties for version 2.5 say. Does it mean that I would have
to unpack the jar, make the changes in the properties file and then reassemble
the jar? In a nutshell, what is the most non intrusive way of getting HAPI to
recognize custom messages? I was able to create custom segments easily by
simply putting them in a package name ending in mypackage.v25.segment.
Thanks,
Brian Davies
********************************************************************************
This email, including any attachments sent with it, is confidential and for the
sole use of the intended recipient(s). This confidentiality is not waived or
lost, if you receive it and you are not the intended recipient(s), or if it is
transmitted/received in error.
Any unauthorised use, alteration, disclosure, distribution or review of this
email is strictly prohibited. The information contained in this email,
including any attachment sent with it, may be subject to a statutory duty of
confidentiality if it relates to health service matters.
If you are not the intended recipient(s), or if you have received this email in
error, you are asked to immediately notify the sender by telephone collect on
Australia +61 1800 198 175 or by return email. You should also delete this
email, and any copies, from your computer system network and destroy any hard
copies produced.
If not an intended recipient of this email, you must not copy, distribute or
take any action(s) that relies on it; any form of disclosure, modification,
distribution and/or publication of this email is also prohibited.
Although Queensland Health takes all reasonable steps to ensure this email does
not contain malicious software, Queensland Health does not accept
responsibility for the consequences if any person's computer inadvertently
suffers any disruption to services, loss of information, harm or is infected
with a virus, other malicious computer programme or code that may occur as a
consequence of receiving this email.
Unless stated otherwise, this email represents only the views of the sender and
not the views of the Queensland Government.
**********************************************************************************
------------------------------------------------------------------------------
_______________________________________________
Hl7api-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
