It truly does help. I will try this out. My message is of an entirely new type ORM_QO1 from a third party application and so I will be extending the AbstractMessage class. I take it this should be no problem as long as I utilize the HapiContext as you've indicated. Again many thanks for your help.
Brian Davies. From: Ian Vowles [mailto:ian.vow...@health.qld.gov.au] Sent: Thursday, December 17, 2015 3:49 PM To: hl7api-devel@lists.sourceforge.net Subject: Re: [HAPI-devel] Custom Messages 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:brian.dav...@mckesson.com] Sent: Friday, 18 December 2015 5:47 AM To: hl7api-devel@lists.sourceforge.net<mailto:hl7api-devel@lists.sourceforge.net> 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 Hl7api-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hl7api-devel
