You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(4) |
May
(5) |
Jun
(6) |
Jul
(3) |
Aug
(13) |
Sep
(28) |
Oct
(33) |
Nov
(8) |
Dec
(1) |
2003 |
Jan
(6) |
Feb
(2) |
Mar
|
Apr
(25) |
May
(21) |
Jun
(13) |
Jul
(12) |
Aug
(14) |
Sep
(6) |
Oct
(6) |
Nov
(16) |
Dec
(6) |
2004 |
Jan
(5) |
Feb
(7) |
Mar
(13) |
Apr
(17) |
May
(24) |
Jun
(14) |
Jul
(14) |
Aug
(8) |
Sep
(3) |
Oct
(8) |
Nov
(14) |
Dec
(26) |
2005 |
Jan
(18) |
Feb
(12) |
Mar
(29) |
Apr
(9) |
May
(4) |
Jun
(12) |
Jul
(17) |
Aug
(9) |
Sep
(12) |
Oct
|
Nov
(12) |
Dec
|
2006 |
Jan
(46) |
Feb
(18) |
Mar
(11) |
Apr
(13) |
May
(12) |
Jun
(27) |
Jul
(34) |
Aug
(45) |
Sep
(27) |
Oct
(13) |
Nov
(26) |
Dec
(22) |
2007 |
Jan
(21) |
Feb
(29) |
Mar
(32) |
Apr
(6) |
May
(11) |
Jun
(13) |
Jul
(14) |
Aug
(11) |
Sep
(15) |
Oct
(7) |
Nov
(30) |
Dec
(16) |
2008 |
Jan
(11) |
Feb
(14) |
Mar
(5) |
Apr
(18) |
May
(12) |
Jun
(11) |
Jul
(5) |
Aug
(12) |
Sep
(3) |
Oct
(2) |
Nov
(15) |
Dec
(2) |
2009 |
Jan
(18) |
Feb
(6) |
Mar
(9) |
Apr
(10) |
May
(29) |
Jun
(16) |
Jul
(44) |
Aug
(49) |
Sep
(14) |
Oct
(21) |
Nov
(11) |
Dec
(22) |
2010 |
Jan
(12) |
Feb
(13) |
Mar
(5) |
Apr
(6) |
May
(15) |
Jun
(15) |
Jul
(14) |
Aug
(20) |
Sep
(17) |
Oct
(36) |
Nov
(19) |
Dec
(7) |
2011 |
Jan
(8) |
Feb
(14) |
Mar
(21) |
Apr
(12) |
May
(6) |
Jun
(12) |
Jul
(17) |
Aug
(6) |
Sep
(13) |
Oct
(15) |
Nov
(26) |
Dec
(9) |
2012 |
Jan
(25) |
Feb
(13) |
Mar
(31) |
Apr
(10) |
May
(16) |
Jun
(21) |
Jul
(61) |
Aug
(38) |
Sep
(16) |
Oct
(13) |
Nov
(37) |
Dec
(26) |
2013 |
Jan
(20) |
Feb
(26) |
Mar
(34) |
Apr
(32) |
May
(27) |
Jun
(56) |
Jul
(16) |
Aug
(38) |
Sep
(35) |
Oct
(17) |
Nov
(11) |
Dec
(7) |
2014 |
Jan
(36) |
Feb
(13) |
Mar
(25) |
Apr
|
May
(27) |
Jun
(33) |
Jul
(34) |
Aug
|
Sep
(4) |
Oct
(11) |
Nov
(42) |
Dec
(2) |
2015 |
Jan
(5) |
Feb
(6) |
Mar
(11) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
(5) |
Oct
(5) |
Nov
(8) |
Dec
(19) |
2016 |
Jan
(8) |
Feb
(12) |
Mar
(6) |
Apr
(5) |
May
(5) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
(9) |
Oct
(1) |
Nov
(2) |
Dec
(5) |
2017 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(6) |
May
(8) |
Jun
(7) |
Jul
(14) |
Aug
(10) |
Sep
(6) |
Oct
(2) |
Nov
|
Dec
|
2018 |
Jan
|
Feb
(9) |
Mar
(2) |
Apr
(3) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(8) |
Sep
(4) |
Oct
(3) |
Nov
(1) |
Dec
(1) |
2019 |
Jan
(10) |
Feb
(2) |
Mar
(6) |
Apr
(1) |
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
2020 |
Jan
(9) |
Feb
|
Mar
|
Apr
(6) |
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(9) |
Oct
(1) |
Nov
(11) |
Dec
|
2021 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(7) |
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2023 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(2) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
(7) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
From: Guevara, A. <Ale...@uh...> - 2003-06-11 17:49:53
|
> there a read-only instance of this DB somewhere that one > could connect > to? Or is it identical to what you get if you purchase the HL7 spec >>Worse ... it's sold separately (for $1200 USD!) Dave you could parse the generated source code using javacc/jtb or javacc/jtree, and work with the generated tree instead of the HL7 tables ... It's a lot more work, but well, it's a choice ... alex6 This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. |
From: Guevara, A. <Ale...@uh...> - 2003-06-11 17:44:16
|
Well like somebody said, "examples are the best way to convey an idea", here they go: Message msg = parser.parse(msgText); Segment mshSegment = (Segment) msg.get("MSH"); Segment pidSegment = (Segment) msg.get("PID"); Segment pv1Segment = (Segment) msg.get("PV1"); String messageType = (String) PropertyUtils.getProperty(mshSegment, "messageType.messageType.value"); String triggerEvent = (String) PropertyUtils.getProperty(mshSegment, "messageType.triggerEvent.value"); String mrn = (String) PropertyUtils.getProperty(pidSegment, "patientIDInternalID[0].patientID.value"); String admissionType = (String) PropertyUtils.getProperty(pv1Segment, "admissionType.value"); String patientClass = (String) PropertyUtils.getProperty(pv1Segment, "patientClass.value"); String assignedKlinik = (String) PropertyUtils.getProperty(pv1Segment, "assignedPatientLocation.klinik.value"); String priorKlinik = (String) PropertyUtils.getProperty(pv1Segment, "priorPatientLocation.klinik.value"); All this works pretty well because hapi follows the java beans pattern, good stuff! alex6 PS: this will solve problems that arise when processing hl7 message with different versions. And it's a work around for hapi-0.3 users who do not have access to the terser utility. This could help Mike as well. This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. |
From: <Shi...@ng...> - 2003-06-05 21:57:17
|
QWxleCwgDQogDQpZb3UgY2FuIHVzZSB0aGUgZ2V0SEw3T2JqZWN0IHRvIGdldCB0aGUgb2JqZWN0 IHRoZW4gd29yayBvZmYgZWFjaCBpbmRpdmR1YWwgcGllY2VzLiBJIHB1bGxlZCBvdXQgYSBmdW5j dGlvbiBvZiBteSBhcHBsaWNhdGlvbiwgeW91IG1pZ2h0IHdhbnQgdG8gdGFrZSBhIGxvb2sgYW5k IHNlZSBpZiBpdCBoZWxwcy4gIE9yIHdlIGNhbiB0YWxrIGFib3V0IGl0IGEgYml0IG1vcmUuDQog DQpTaGluLg0KIA0KICAgIHByaXZhdGUgdm9pZCBoYW5kbGVITDdHcm91cChtc2dUcmVlTm9kZSBu b2RlLCBib29sZWFuIGlzTXNnUmVhZE9wKSB7DQogICAgICAgIFN0cmluZyBncm91cE5hbWVzW10g PW51bGw7DQogICAgICAgIFN0cmluZyBncm91cE5hbWUgPW51bGw7DQogICAgICAgIEFic3RyYWN0 TWVzc2FnZSAgICAgdE1lc3NhZ2UgPSBudWxsOw0KICAgICAgICBBYnN0cmFjdEdyb3VwICAgICAg IHRHcm91cCAgID0gbnVsbDsNCiAgICAgICAgU2VnbWVudCAgICAgICAgICAgICB0U2VnbWVudCA9 IG51bGw7DQogICAgICAgIGJ1Zi5hcHBlbmQoIlx0WyBDYWxsaW5nIGhhbmRsZUhMN0dyb3VwIF1c biIpOw0KICAgICAgICB0cnkgew0KICAgICAgICAgICAgbXNnR3JvdXBfaW5zdCA9IChtc2dHcm91 cClub2RlLmdldEN1c3RvbU9iamVjdCgpOw0KICAgICAgICAgICAgbXNnVHJlZU5vZGUgcGFyZW50 ID0gKG1zZ1RyZWVOb2RlKW5vZGUuZ2V0UGFyZW50KCk7DQogICAgICAgICAgICBpZiAoIHBhcmVu dC5ub2RlVHlwZSA9PSBtc2dDb25zdC5MRVZFTF9NU0cgKSB7DQogICAgICAgICAgICAgICAgU3lz dGVtLm91dC5wcmludGxuKG5vZGUudG9TdHJpbmcoKSArICIgcGFyZW50IGlzIE1TRyAgIik7DQog ICAgICAgICAgICAgICAgdE1lc3NhZ2UgPSAoQWJzdHJhY3RNZXNzYWdlKXBhcmVudC5nZXRITDdP YmplY3QoKTsNCiAgICAgICAgICAgICAgICBpZiAoaXNNc2dSZWFkT3AgJiYgKHRNZXNzYWdlPT1u dWxsKSkgcmV0dXJuOw0KICAgICAgICAgICAgICAgIGdyb3VwTmFtZXMgPSB0TWVzc2FnZS5nZXRO YW1lcygpOw0KICAgICAgICAgICAgICAgIGdyb3VwTmFtZSA9IGdyb3VwTmFtZXNbSW50ZWdlci5w YXJzZUludChtc2dHcm91cF9pbnN0LmdldEluZHgoKSkgXTsNCiAgICAgICAgICAgICAgICB0R3Jv dXAgPSAoQWJzdHJhY3RHcm91cCl0TWVzc2FnZS5nZXQoZ3JvdXBOYW1lLCBub2RlLm1fckluZGV4 KTsNCiAgICAgICAgICAgICAgICBub2RlLnNldEhMN09iamVjdCh0R3JvdXApOw0KICAgICAgICAg ICAgfQ0KICAgICAgICAgICAgaWYgKCBwYXJlbnQubm9kZVR5cGUgPT0gbXNnQ29uc3QuTEVWRUxf R1JPVVApIHsNCiAgICAgICAgICAgICAgICBTeXN0ZW0ub3V0LnByaW50bG4obm9kZS50b1N0cmlu ZygpICsgIiBwYXJlbnQgaXMgR3JvdXAgICIgKTsNCiAgICAgICAgICAgICAgICB0R3JvdXAgICA9 IChBYnN0cmFjdEdyb3VwKXBhcmVudC5nZXRITDdPYmplY3QoKTsNCiAgICAgICAgICAgICAgICBp ZiAoaXNNc2dSZWFkT3AgJiYgKHRHcm91cD09bnVsbCkpIHJldHVybjsNCiAgICAgICAgICAgICAg ICBncm91cE5hbWVzID0gdEdyb3VwLmdldE5hbWVzKCk7DQogICAgICAgICAgICAgICAgZ3JvdXBO YW1lID0gZ3JvdXBOYW1lc1tJbnRlZ2VyLnBhcnNlSW50KG1zZ0dyb3VwX2luc3QuZ2V0SW5keCgp KSBdOw0KICAgICAgICAgICAgICAgIHRHcm91cCA9IChBYnN0cmFjdEdyb3VwKXRHcm91cC5nZXQo Z3JvdXBOYW1lLCBub2RlLm1fckluZGV4KTsNCiAgICAgICAgICAgICAgICBub2RlLnNldEhMN09i amVjdCh0R3JvdXApOw0KICAgICAgICAgICAgfQ0KICAgICAgICAgICAgYnVmLmFwcGVuZCgiXHRH cm91cDogIiArIGdyb3VwTmFtZSArIlxuIik7DQogICAgICAgIH0gY2F0Y2ggKEV4Y2VwdGlvbiBl KSB7DQogICAgICAgICAgICBTeXN0ZW0ub3V0LnByaW50bG4obm9kZS50b1N0cmluZygpICsgIiAg IiArIGUudG9TdHJpbmcoKSk7DQogICAgICAgIH0NCiAgICB9DQoNCgktLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLSANCglGcm9tOiBBbGV4IEhhcnZleSBbbWFpbHRvOmFsZXhAOXBvdW5kaGFtbWVy LmNvbV0gDQoJU2VudDogVGh1IDYvNS8yMDAzIDQ6MjAgUE0gDQoJVG86IEhhcGkgDQoJQ2M6IA0K CVN1YmplY3Q6IFtIQVBJLWRldmVsXSBBYnN0cmFjdCBtZXNzYWdlcw0KCQ0KCQ0KCUlzIHRoZXJl IGFuIGFic3RyYWN0IG1lYW5zIG9mIGRlYWxpbmcgd2l0aCBtZXNzYWdlcyBhbmQgc2VnbWVudHM/ IEZvciBpbnN0YW5jZSBpZiBJIGtub3cgSSBhbSBkZWFsaW5nIHdpdGggQSB0eXBlIG1lc3NhZ2Vz IGFuZCBJIHdhbnQgdG8gZXh0cmFjdCBhIFBJRCBzZWdtZW50IHJlZ2FyZGxlc3Mgb2YgdGhlIGNv bmNyZXRlIG1lc3NhZ2UgdHlwZS4gSXMgdGhlcmUgYSB3YXkgdG8gZG8gdGhpcyBpbiBIQVBJPw0K CSANCglJIGFwb2xvZ2l6ZSBpZiB0aGlzIGhhcyBiZWVuIGFza2VkIGJlZm9yZS4NCgkgDQoJVGhh bmtzLA0KCSANCgktQWxleA0K |
From: Tripp, B. <Bry...@uh...> - 2003-06-05 20:36:08
|
Hi Alex, There are basically two options ... use: PID pid = (PID) msg.get("PID"); ... or go for specific fields with a Terser (ca.uhn.hl7v2.util.Terser). Does that do it or do you need something else? Bryan -----Original Message----- From: Alex Harvey [mailto:al...@9p...] Sent: June 5, 2003 4:21 PM To: Hapi Subject: [HAPI-devel] Abstract messages Is there an abstract means of dealing with messages and segments? For instance if I know I am dealing with A type messages and I want to extract a PID segment regardless of the concrete message type. Is there a way to do this in HAPI? I apologize if this has been asked before. Thanks, -Alex This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. |
From: Alex H. <al...@9p...> - 2003-06-05 20:20:42
|
Is there an abstract means of dealing with messages and segments? For instance if I know I am dealing with A type messages and I want to extract a PID segment regardless of the concrete message type. Is there a way to do this in HAPI? I apologize if this has been asked before. Thanks, -Alex |
From: Tripp, B. <Bry...@uh...> - 2003-06-03 16:21:59
|
Hi Terry, Yes, sorry, it looks like a bug that was fixed some time ago, but we haven't had a release since then. I'm going to try to get a beta of version 0.4 out by the end of next week. In the mean time, the fix is available in the CVS repository. Hope things are going well over at KGH. Bryan > -----Original Message----- > From: Waldron, Terry [mailto:wal...@KG...] > Sent: June 3, 2003 12:01 PM > To: hl7...@li... > Subject: [HAPI-devel] XMLParser Problem? > > > Hi, > I'm trying to use the XMLParser in TestPanel and in the > ParserDemo but I keep getting exceptions. See Below. > > java.io.UnsupportedEncodingException: > at > org.apache.xml.serialize.Encodings.getEncodingInfo(Unknown Source) > at > org.apache.xml.serialize.OutputFormat.getEncodingInfo(Unknown Source) > at > org.apache.xml.serialize.BaseMarkupSerializer.prepare(Unknown Source) > at > org.apache.xml.serialize.BaseMarkupSerializer.serialize(Unknow > n Source) > at ca.uhn.hl7v2.parser.XMLParser.encode(XMLParser.java:179) > at ParserDemo.main(ParserDemo.java:31) > > I have installed Xerces 2.4.0 and the jars are in the classpath. > > Anybody have any ideas? > > Terry Waldron > wal...@kg... > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Hl7api-devel mailing list > Hl7...@li... > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. |
From: Waldron, T. <wal...@KG...> - 2003-06-03 16:01:57
|
Hi, I'm trying to use the XMLParser in TestPanel and in the ParserDemo but I ke= ep getting exceptions. See Below. java.io.UnsupportedEncodingException:=20 at org.apache.xml.serialize.Encodings.getEncodingInfo(Unknown Source) at org.apache.xml.serialize.OutputFormat.getEncodingInfo(Unknown Source) at org.apache.xml.serialize.BaseMarkupSerializer.prepare(Unknown Source) at org.apache.xml.serialize.BaseMarkupSerializer.serialize(Unknown Source) at ca.uhn.hl7v2.parser.XMLParser.encode(XMLParser.java:179) at ParserDemo.main(ParserDemo.java:31) I have installed Xerces 2.4.0 and the jars are in the classpath. Anybody have any ideas? Terry Waldron wal...@kg... |
From: Phillip E. T. <pt...@tr...> - 2003-05-28 21:13:23
|
Bryan, Thanks for the reply -- this is the information I needed. I just discovered section 2.17.3 of the HL7 2.4 standard :). On another note, I am also interested in contributing to the project. If interested, let me know how to proceed. Phil ----- Original Message ----- From: "Tripp, Bryan" <Bry...@uh...> To: "'Phillip E. Trewhella'" <pt...@tr...>; <hl7...@li...> Sent: Wednesday, May 28, 2003 1:29 PM Subject: RE: [HAPI-devel] Missing ADT in Generated 2.4 Model? > > Hi Phil, > > > > > 0.3 release is missing some ADT messages (such as A04). > > > > The A04 trigger uses the A01 message structure, so you would > > just code against the ADT_A01 class. > > > > If you are receiving messages, the parser doesn't have a > > place to look up which structures are shared by which > > triggers, so MSH-9-3 must be populated. For A04, MSH-9 > > should be "ADT^A04^ADT_A01". > > > > Hope that helps. > > > > Bryan > > > > > This e-mail may contain confidential and/or privileged information > for the sole use of the intended recipient. Any review or distribution > by anyone other than the person for whom it was originally intended is > strictly > prohibited. If you have received this e-mail in error, please contact the > sender and > delete all copies. Opinions, conclusions or other information contained in > this e-mail may not be that of the organization. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Hl7api-devel mailing list > Hl7...@li... > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > |
From: Tripp, B. <Bry...@uh...> - 2003-05-28 20:30:01
|
> Hi Phil, > > > 0.3 release is missing some ADT messages (such as A04). > > The A04 trigger uses the A01 message structure, so you would > just code against the ADT_A01 class. > > If you are receiving messages, the parser doesn't have a > place to look up which structures are shared by which > triggers, so MSH-9-3 must be populated. For A04, MSH-9 > should be "ADT^A04^ADT_A01". > > Hope that helps. > > Bryan > This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. |
From: Phillip E. T. <pt...@tr...> - 2003-05-28 17:06:39
|
I saw an earlier post with no reply. The generated 2.4 model in the 0.3 release is missing some ADT messages (such as A04). What's up with that? Thanks. Phil |
From: Tripp, B. <Bry...@uh...> - 2003-05-27 22:01:01
|
Hi Mike, Thanks, this does seem like a good way to handle new fields that are introduced at the end of a segment. I don't think it would work so well when components are added to a field, or segments to a group. For example if a field changes from ID to CE, you would need accessors for both, which wouldn't be too much better than what we have now. I want to make sure you're aware of ca.uhn.hl7v2.util.Terser. It provides a string syntax for accessing primitives in a version-independent manner -- maybe this is what you mentioned for primitives in the current CVS code. You retrieve data with address strings like "MSH-9-3" and it will account for version-related differences. This is how the core HAPI classes deal with this problem. If Terser doesn't meet your needs and you don't mind the above limitations, then you're more than welcome to give it a shot and I'll try to be of assistance. > there a read-only instance of this DB somewhere that one > could connect > to? Or is it identical to what you get if you purchase the HL7 spec Worse ... it's sold separately (for $1200 USD!) Bryan This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. |
From: Michael H. <mh...@st...> - 2003-05-27 21:29:55
|
Hi. I'm playing around with HAPI, assessing it's suitability for an experimental project our group is working on. So far I am impressed. But there is an issue that I'd like to ask about (and offer to contribute some hacking if there is interest). I'm writing handlers for different message types. I find it a bit cumbersome, though maybe I'm missing something obvious. Here's my issue. Suppose I want to process messages of type ADT_A01. Hapi, version 0.3, uses namespaces to segregate the v2.2, 2.3, 2.3.1 and 2.4 versions of classes of this type. They all have various helper functions like "getPV1()", but because the only commonality between the different versions of the class is that they all extend AbstractMessage, one can't really use these helper functions in a message handler if you want to handle messages of varying versions, unless you do an awful lot of ugly, non-object-oriented testing and casting. And the PV1 object they all return also has no overlap between versions; so repeat the above problem, all the way down to the primitive types. I could just do a bunch of calls like get("PV1"), but that results in a lot of ugly syntax too, because the "get" method always returns (and creates) what you ask for, whether it was in the message or not, so you have to really drill down to see if an optional segment (like PDA or PV2) actually was in the message or not. Furthermore, if I wanted to make generic handlers for segments like PDA, those have to be invoked lexically, not at the object level. Like, I do get("PDA"), then call my processPDA handler with that blind Segment, and hope I don't have a typo somewhere (like, mistakenly calling "blah=get("PDA")" then calling "processPV2(blah)", or whatever). Very un-object-oriented. How about this: the sourcegen module scans all versions for a particular message type, and constructs a superset of all segments and groups it contains, and spits out a generic class of that type.. say, an ADT_A01 class with getXXX methods for all possible segments and groups, all of which for that class return null. That class could extend AbstractMessage or whatever. Then, instead of having the different hl7 versions segregated by namespace, have sourcegen spit out classes like ADT_A01_V23 and so on, which extend the ADT_A01 superclass, and override the getXXX things as appropriate. Then do the same for segments, groups, compound and primitive datatypes. Then, my ADT_A01 handler could simply cast the incoming message to an ADT_A01 object, call getPDA(), and if it isn't there because the message is version 2.2 and hence isn't defined, I get a null and ignore that segment; if it's a message for version 2.4 but isn't in the message, I still get a null, and again ignore it. That way I don't have to care (unless I want to) what version the messages come from. Same procedure with processing groups, segments, and datatypes; have a generic PV1 class, with PV1_v23 subclasses, and so on. My handlers can then process segments like PV1 or PDA and have the bindings done by the compiler. I notice that the CVS repository for the newer versions does something like this already for the primitive types. Great start. How about turtles all the way down? I could take a stab at this, if there's interest. But the sourcegen module wants to connect to a database to draw out it's definitions. Is there a read-only instance of this DB somewhere that one could connect to? Or is it identical to what you get if you purchase the HL7 spec from hl7.org? In other words, how can I get my hands on the data definitions and geek around with sourcegen? Or is there a much more obvious and clean way to access the segments (and from there, datatypes) in a message processor that I'm missing? Thanks for any feedback, and apologies if these are silly questions/ideas. Dicom is my bread and butter; I'm a relative novice at hl7. Cheers, Mike Harm Stanford University School of Medicine mh...@st... ------------------------------------------------------------------------ ------ 'What should you do,' the author asked rhetorically, 'if you are in a situation where there is a strong wind, and a lee shore, and your boat doesn't have an auxiliary engine?' Reply: 'Look, JUST STAY OUT of situations where there's a strong wind and a lee shore and your boat doesn't have an auxiliary engine.' - Jerry Fodor, "The Elm and the Expert" |
From: Tripp, B. <Bry...@uh...> - 2003-05-23 21:03:18
|
Hi Rob, Apologies for this -- it's a bug that was fixed in October, but we haven't done a release since then. You can pick up the fix from the CVS. Hope to get version 0.4 out soon. Bryan -----Original Message----- From: Rob Summitt [mailto:ro...@bl...] Sent: May 23, 2003 1:42 AM To: hl7...@li... Subject: [HAPI-devel] error I'm getting serialization errors when I attempt to run the ParserDemo.java example. Outputting status messages to standard out. ca.uhn.hl7v2.util.Status: Standard status messages will be output. 23/21/2003 1:38:9.437 Parsing msg of class ca.uhn.hl7v2.model.v24.message.ACK 23/21/2003 1:38:9.984 Setting current log date to May 23, 2003 FileLog: logging exception ca.uhn.hl7v2.HL7Exception: IOException serializing XML document to string: at ca.uhn.hl7v2.parser.XMLParser.encode(XMLParser.java:182) at ParserDemo.main(ParserDemo.java:30) Here is the source.. import ca.uhn.hl7v2.parser.*; import ca.uhn.hl7v2.model.Message; import ca.uhn.hl7v2.model.v24.message.ACK; public class ParserDemo { public static void main(String args[]) { //for demo purposes, we just declare a literal message string String ackMessageString = "MSH|^~\\&|foo|foo||foo|200108151718||ACK^A01^ACK|1|D|2.4|\rMSA|AA\r"; //instantiate a PipeParser, which handles the "traditional encoding" PipeParser pipeParser = new PipeParser(); try { //parse the message string into a Message object Message message = pipeParser.parse(ackMessageString); //if it is an ACK message (as we know it is), cast it to an // ACK object so that it is easier to work with, and change a value if (message instanceof ACK) { ACK ack = (ACK) message; ack.getMSH().getProcessingID().getProcessingMode().setValue("P"); } //instantiate an XML parser XMLParser xmlParser = new DefaultXMLParser(); //encode message in XML String ackMessageInXML = xmlParser.encode(message); //print XML-encoded message to standard out System.out.println(ackMessageInXML); } catch (Exception e) { e.printStackTrace(); } } } Thanks for any help. Rob ro...@bl... <mailto:ro...@bl...> This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. |
From: Libros D. <si...@si...> - 2003-05-23 15:01:31
|
<html> <head> <title>mail2</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <!-- Fireworks 4.0 Dreamweaver 4.0 target. Created Sat Mar 08 05:14:12 GMT-0600 (Hora estándar de México) 2003--> <script language="JavaScript"> <!-- function MM_reloadPage(init) { //reloads the window if Nav4 resized if (init==true) with (navigator) {if ((appName=="Netscape")&&(parseInt(appVersion)==4)) { document.MM_pgW=innerWidth; document.MM_pgH=innerHeight; onresize=MM_reloadPage; }} else if (innerWidth!=document.MM_pgW || innerHeight!=document.MM_pgH) location.reload(); } MM_reloadPage(true); // --> </script> </head> <body bgcolor="#ECE9D8"> <div id="Layer1" style="position:absolute; left:12px; top:201px; width:103px; height:15px; z-index:1"><font size="2"><a href="http://www.sindns.com/listado.htm"><font size="3">Bajar listado </font></a></font></div> <div id="Layer2" style="position:absolute; left:152px; top:202px; width:204px; height:20px; z-index:2"> <a href="mailto:li...@si...?Subject=Pedido%202345%20Libros%20Digitales&body=Estos%20son%20mis%20datos:%0D%0A%0D%0ANombre:%0D%0AApellido:%0D%0ADomicilio:%0D%0AC.Postal:%0D%0ALocalidad:%0D%0AProvincia:%0A%0AEmail%20"><font face="V erdana" size="3"><b><font size="2">CLIC AQUÍ PARA COMPRAR</font></b></font></a> </div> <div id="Layer3" style="position:absolute; left:402px; top:202px; width:91px; height:18px; z-index:3"><a href="http://www.sindns.com/"><font size="2" face="Tahoma">Nuestra www</font> </a></div> <!-- fwtable fwsrc="mail2.png" fwbase="mail2" fwstyle="Dreamweaver" fwdocid = "742308039" fwnested="0" --> <div id="Layer4" style="position:absolute; left:9px; top:12px; width:481px; height:61px; z-index:4"> <div align="center"><img src="http://personal.telefonica.terra.es/web/xline/titulo.gif" width="279" height="37"></div> </div> <div id="Layer5" style="position:absolute; left:11px; top:98px; width:496px; height:95px; z-index:5"><font face="Verdana, Arial, Helvetica, sans-serif" size="2"> Costo del CD <font color="#FF0000">35€</font></font> <font face="Verdana, Arial, Helvetica, sans-serif" size="1">(gastos de envio incluidos)</font><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><br> <br> El CD se envía a través del Correo por Contrareembolso.<br> <br> El tiempo de entrega 72 hs. desde que confirmamos la compra.</font><b> </b> </div> <div id="Layer6" style="position:absolute; left:129px; top:59px; width:267px; height:27px; z-index:6"><b><font face="Verdana, Arial, Helvetica, sans-serif" size="3" color="#0000CC"> </font></b><font face="Tahoma" size="4" color="#0000CC"><b>2435 Libros en un solo CD</b></font></div> <div id="Layer7" style="position:absolute; left:403px; top:83px; width:92px; height:34px; z-index:7"><img src="http://personal.telefonica.terra.es/web/xline/acrobat.gif" width="88" height="31"></div> <div id="Layer8" style="position:absolute; left:393px; top:107px; width:118px; height:22px; z-index:8"> <div align="center"><font face="Verdana"><font color="#000000" size="1" face="Verdana, Arial, Helvetica, sans-serif"><br> Software</font></font><font size="1" face="Verdana, Arial, Helvetica, sans-serif" color="#000000"> de Lectura</font></div> </div> <div id="Layer3" style="position:absolute; left:1px; top:238px; width:534px; height:14px; z-index:3; background-color: #FFFFCC; layer-background-color: #FFFFCC; border: 1px none #000000"> <div align="center"><font face="Verdana, Arial, Helvetica, sans-serif" size="1" color="#FF3300">Entrega en todo España sin gastos de envio</font></div> </div> <div id="Layer9" style="position:absolute; left:8px; top:10px; width:100px; height:53px; z-index:9; background-color: #ECE9D8; layer-background-color: #ECE9D8; border: 1px none #000000;"></div> </body> </html> yoykswpjjwgkfgywvhubnauaaiirymbeq |
From: Alex H. <al...@9p...> - 2003-05-23 13:23:31
|
Alexei, Any progress on adding the status messages to log4j? We have incorporated your exception logging into our latest build. Thanks, -Alex -----Original Message----- From: hl7...@li... [mailto:hl7...@li...]On Behalf Of Guevara, Alexei Sent: Wednesday, May 07, 2003 8:16 PM To: 'hl7...@li...' Subject: [HAPI-devel] logging task progress I've done some progress in replacing the hapi home grown logging mechanism with the jakarta-commons-logging framework. DONE: - All references to the hapi Log interface has been removed and the Log interface itselft, plus related classes have been marked as deprecated. - package ca.uhn.log has been added. - interface HapiLog, and classes HapiLogImpl and HapiLogFactory have been added to pachake ca.uhn.log. - the javadoc of the class HapiLog contains information about how to use the new logging framework. - exception classes have been changed to contain the cause of the exception. - in all places where the an error is being logged and an exception is being propagated have been modified to only propagate the exception-and the cause of it (to avoid having the same problem logged twince) NOTE that now hapi depends on the jakarta-commons-logging framework. TODO - look into replacing the class Status with well known patterns of jakarta-logging usage. Meaning that if want to output status information, the underlying logging framework must be used, by invoking the log.info( ... ) method. - create a std hapi log4j cinfiguration file. - ... This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. ------------------------------------------------------- Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara The only event dedicated to issues related to Linux enterprise solutions www.enterpriselinuxforum.com _______________________________________________ Hl7api-devel mailing list Hl7...@li... https://lists.sourceforge.net/lists/listinfo/hl7api-devel |
From: Rob S. <ro...@bl...> - 2003-05-23 05:41:52
|
I'm getting serialization errors when I attempt to run the ParserDemo.java example. Outputting status messages to standard out. ca.uhn.hl7v2.util.Status: Standard status messages will be output. 23/21/2003 1:38:9.437 Parsing msg of class ca.uhn.hl7v2.model.v24.message.ACK 23/21/2003 1:38:9.984 Setting current log date to May 23, 2003 FileLog: logging exception ca.uhn.hl7v2.HL7Exception: IOException serializing XML document to string: at ca.uhn.hl7v2.parser.XMLParser.encode(XMLParser.java:182) at ParserDemo.main(ParserDemo.java:30) Here is the source.. import ca.uhn.hl7v2.parser.*; import ca.uhn.hl7v2.model.Message; import ca.uhn.hl7v2.model.v24.message.ACK; public class ParserDemo { public static void main(String args[]) { //for demo purposes, we just declare a literal message string String ackMessageString = "MSH|^~\\&|foo|foo||foo|200108151718||ACK^A01^ACK|1|D|2.4|\rMSA|AA\r"; //instantiate a PipeParser, which handles the "traditional encoding" PipeParser pipeParser = new PipeParser(); try { //parse the message string into a Message object Message message = pipeParser.parse(ackMessageString); //if it is an ACK message (as we know it is), cast it to an // ACK object so that it is easier to work with, and change a value if (message instanceof ACK) { ACK ack = (ACK) message; ack.getMSH().getProcessingID().getProcessingMode().setValue("P"); } //instantiate an XML parser XMLParser xmlParser = new DefaultXMLParser(); //encode message in XML String ackMessageInXML = xmlParser.encode(message); //print XML-encoded message to standard out System.out.println(ackMessageInXML); } catch (Exception e) { e.printStackTrace(); } } } Thanks for any help. Rob ro...@bl... |
From: David F. <dw...@la...> - 2003-05-17 04:01:16
|
Noticed two minor problems in the current CVS tree. The build requires the jakarta commons-logging library and the build then fails do to a missing build/gen directory. Creating a build/gen directory then allows the compilation to complete without error. You may be aware of both of these, but I thought I would let you know. thanks, Dave |
From: Guevara, A. <Ale...@uh...> - 2003-05-09 16:33:01
|
in green now, I guess I'm in a sort of ecological mood today = ... =20 and I=92d like to emphasize that this is a core feature of = all parsers, error recovery. =20 My understanding of error recovery in language parsers is that they = only exist so that additional errors can be correctly identified (e.g. so = you can produce a whole list of compile errors rather than just one). Correct = me if I'm wrong about this. What you are proposing allows passing erroneous = input by changing it in some way. To me this seems analogous to a Java = parser that finds !+ and decides what was probably meant was !=3D, and then = compiles, setting a flag somewhere that the code was changed. That's the part I = was objecting to anyway -- if I've misunderstood please let me know. =20 =20 In the long term, error recovery would be great, but I think it should = only be used to create a complete list of problems that can be returned to = the sending system in the rejection message.=20 =20 In the short term, I agree that we do need a way to work around the = problem you identified, and your proposal will certainly do it. =20 =20 that is definitely the way error recovery is implemented in most parsers, in this case we have particular situation. One that is very = similar to the one happening in eclipse, they have an incremental = parser/compiler, meaning that even when there are errors in some methods in a class, the parser/compiler will still parse the whole source file and will = generate bytecodes for whichever methods are correct. In the case of HAPI, we = have a known lack of compliance with the HL7 std. by many products, and it = will be a real shame to stop the whole parsing process only because of one = promitive type was not valid ..... mmmmmmmm, actually now I see your point = clearly, maybe we should just let the parser continue and mark that component as Unable To Parse (maybe we can have an impl. of Primitive specifically created for this). Actually this was my original idea, but I guess I = got "too flexible" ;) =20 we should include it as soon as we can, maybe right after the 0.4 release, in some sort of 0.4.1 version .. bla bla bla ;) =20 =20 Perfect, let's come back to this right after the 0.4 release. =20 =20 sounds like the best way to go! =20 =20 Bryan=20 =20 This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact = the sender and delete all copies. Opinions, conclusions or other information contained = in this e-mail may not be that of the organization. --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003 HYPERLINK "http://www.mailfiler.com"MailFiler [HAPI-devel] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003 =20 This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact = the sender and delete all copies. Opinions, conclusions or other information contained = in this e-mail may not be that of the organization. |
From: Tripp, B. <Bry...@uh...> - 2003-05-09 15:46:24
|
Hi Alexei, Lots of good points! Always a pleasure. incurring into the risk of introducing errors. Keep in mind that the validation code will still be respected by the recovery handler (when the setValue method is called from within it) meaning that the user won't be able to assign arbitrary values to the parsed component. And I very much think that introducing this sort of feature early, will I'm not worried about that at all ... I just want to minimize the number of places in which message content can be changed. Right now we have one (i.e. explicit calls on the message object). (and I'd like to emphasize that this is a core feature of all parsers, error recovery). My understanding of error recovery in language parsers is that they only exist so that additional errors can be correctly identified (e.g. so you can produce a whole list of compile errors rather than just one). Correct me if I'm wrong about this. What you are proposing allows passing erroneous input by changing it in some way. To me this seems analogous to a Java parser that finds !+ and decides what was probably meant was !=, and then compiles, setting a flag somewhere that the code was changed. That's the part I was objecting to anyway -- if I've misunderstood please let me know. In the long term, error recovery would be great, but I think it should only be used to create a complete list of problems that can be returned to the sending system in the rejection message. In the short term, I agree that we do need a way to work around the problem you identified, and your proposal will certainly do it. we should include it as soon as we can, maybe right after the 0.4 release, in some sort of 0.4.1 version .. bla bla bla ;) Perfect, let's come back to this right after the 0.4 release. Bryan This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. |
From: alexei g. <ale...@ho...> - 2003-05-08 18:12:44
|
[Bryan] I want to move all validation to a separate process that is much more configurable (i.e. not perform any validation when values are set, which would fix this problem and others). However, this is a = substantial change. We have lots of new features that should be consolidated into a stable release (0.4) before starting something new, so let's just get = 0.4 done and then we can turn our attention here. =20 =20 [Alexei] Yes, I remember that we talked about this issue some time ago = and you said you=92ll be working on it in the future. I think that the = framework you proposed to build for validation will take a long time to implement, = on the other side, the change I=92m proposing is very easy to incorporate = into hapi without incurring into the risk of introducing errors. Keep in mind that the validation code will still be respected by the recovery handler (when the setValue method is called from within it) meaning that the = user won=92t be able to assign arbitrary values to the parsed component. And = I very much think that introducing this sort of feature early, will help to increase the user base of hapi. (and I=92d like to emphasize that this = is a core feature of all parsers, error recovery). The point I=92m trying to = make is that, maybe we should include it as soon as we can, maybe right after = the 0.4 release, in some sort of 0.4.1 version .. bla bla bla ;) =20 alex6 =20 =20 =20 =20 =20 -----Original Message----- From: alexei guevara [mailto:ale...@ho...] Sent: May 8, 2003 11:37 AM To: hl7...@li... Subject: [HAPI-devel] new feature (making the PipeParser able to recover from errors) We are using HAPI to parse ADT and ORDER messages at UHN, and because of some "lack of std. compliance" by our HIS, we are getting invalid = messages (not at the message structure level, but at the primitive level). For = ex.: some components that are meant to be numeric are alphanumeric. =20 My proposal is simple and easy to implement. We'll be adding an event handler to the parser to be invoked whenever such parsing error occurs, = and the code in the event will try to recover from that error, by marking = the parsed component as recovered and assigning a valid value to it. =20 Right now this functionality will have to be added at the PipeParser = level, I propose to perform some refactoring in the future, such a way we can = make this sort of functionality common to all parser impls. =20 Some pseudo-code implementing the described feature. =20 class PipeParser { =20 boolean parse( Type destination,=20 String data,=20 EncodingCharacters encodingChars,=20 boolean subComponents) { =20 ... else if (destination instanceof Primitive) { Primitive prim =3D (Primitive) destination; try { prim.setValue( Escape.unescape(data, encodingChars) ); } catch (DataTypeException e) { //try to recover boolean recovered =3D invokeRecoveryHandler( data, destination, e = ); if (recovered=3D=3Dtrue) { //we must change the primitive intf. a bit prim.setRecovered( true ); } else { throw e; } } =20 isLeaf =3D true; } =20 ... =20 } =20 } HYPERLINK "http://www.mailfiler.com"MailFiler [AG-JU4UEF4] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003 =20 =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003 This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact = the sender and delete all copies. Opinions, conclusions or other information contained = in this e-mail may not be that of the organization. --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003 =20 |
From: Tripp, B. <Bry...@uh...> - 2003-05-08 17:24:05
|
Hi Alexei, Good idea, and I'm sure lots of other people are suffering from the same problem, but I have to ask you to keep this change local to UHN. Changing a message value quietly could be dangerous, and we can't count on people to be aware of the new "recovered" flag. I want to move all validation to a separate process that is much more configurable (i.e. not perform any validation when values are set, which would fix this problem and others). However, this is a substantial change. We have lots of new features that should be consolidated into a stable release (0.4) before starting something new, so let's just get 0.4 done and then we can turn our attention here. Bryan -----Original Message----- From: alexei guevara [mailto:ale...@ho...] Sent: May 8, 2003 11:37 AM To: hl7...@li... Subject: [HAPI-devel] new feature (making the PipeParser able to recover from errors) We are using HAPI to parse ADT and ORDER messages at UHN, and because of some "lack of std. compliance" by our HIS, we are getting invalid messages (not at the message structure level, but at the primitive level). For ex.: some components that are meant to be numeric are alphanumeric. My proposal is simple and easy to implement. We'll be adding an event handler to the parser to be invoked whenever such parsing error occurs, and the code in the event will try to recover from that error, by marking the parsed component as recovered and assigning a valid value to it. Right now this functionality will have to be added at the PipeParser level, I propose to perform some refactoring in the future, such a way we can make this sort of functionality common to all parser impls. Some pseudo-code implementing the described feature. class PipeParser { boolean parse( Type destination, String data, EncodingCharacters encodingChars, boolean subComponents) { ... else if (destination instanceof Primitive) { Primitive prim = (Primitive) destination; try { prim.setValue( Escape.unescape(data, encodingChars) ); } catch (DataTypeException e) { //try to recover boolean recovered = invokeRecoveryHandler( data, destination, e ); if (recovered==true) { //we must change the primitive intf. a bit prim.setRecovered( true ); } else { throw e; } } isLeaf = true; } ... } } MailFiler <http://www.mailfiler.com> [AG-JU4UEF4] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003 This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. |
From: Guevara, A. <Ale...@uh...> - 2003-05-08 16:27:06
|
Yes, totally. You can log your messages to a jdbc db, xml file, email, syslog ... Check then log4j docs, they have good samples. alex6 -----Original Message----- From: Alex Harvey [mailto:al...@9p...] Sent: May 8, 2003 11:53 AM To: Guevara, Alexei Subject: RE: logging task progress I don't know much about log4j so I have a question for you. Is it possible to obtain an appender that can log to JDBC? I know it is silly to log to a database but this would be a straightforward route for me to log my messages into a relational database in my test environment. Do you know anything about an appender for JDBC? Thanks, -Alex -----Original Message----- From: hl7...@li... [mailto:hl7...@li...]On Behalf Of Guevara, Alexei Sent: Wednesday, May 07, 2003 8:16 PM To: 'hl7...@li...' Subject: [HAPI-devel] logging task progress I've done some progress in replacing the hapi home grown logging mechanism with the jakarta-commons-logging framework. DONE: - All references to the hapi Log interface has been removed and the Log interface itselft, plus related classes have been marked as deprecated. - package ca.uhn.log has been added. - interface HapiLog, and classes HapiLogImpl and HapiLogFactory have been added to pachake ca.uhn.log. - the javadoc of the class HapiLog contains information about how to use the new logging framework. - exception classes have been changed to contain the cause of the exception. - in all places where the an error is being logged and an exception is being propagated have been modified to only propagate the exception-and the cause of it (to avoid having the same problem logged twince) NOTE that now hapi depends on the jakarta-commons-logging framework. TODO - look into replacing the class Status with well known patterns of jakarta-logging usage. Meaning that if want to output status information, the underlying logging framework must be used, by invoking the log.info( ... ) method. - create a std hapi log4j cinfiguration file. - ... This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. ------------------------------------------------------- Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara The only event dedicated to issues related to Linux enterprise solutions www.enterpriselinuxforum.com _______________________________________________ Hl7api-devel mailing list Hl7...@li... https://lists.sourceforge.net/lists/listinfo/hl7api-devel --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003 This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. |
From: alexei g. <ale...@ho...> - 2003-05-08 15:37:12
|
We are using HAPI to parse ADT and ORDER messages at UHN, and because of some "lack of std. compliance" by our HIS, we are getting invalid messages (not at the message structure level, but at the primitive level). For ex.: some components that are meant to be numeric are alphanumeric. My proposal is simple and easy to implement. We'll be adding an event handler to the parser to be invoked whenever such parsing error occurs, and the code in the event will try to recover from that error, by marking the parsed component as recovered and assigning a valid value to it. Right now this functionality will have to be added at the PipeParser level, I propose to perform some refactoring in the future, such a way we can make this sort of functionality common to all parser impls. Some pseudo-code implementing the described feature. class PipeParser { boolean parse( Type destination, String data, EncodingCharacters encodingChars, boolean subComponents) { ... else if (destination instanceof Primitive) { Primitive prim = (Primitive) destination; try { prim.setValue( Escape.unescape(data, encodingChars) ); } catch (DataTypeException e) { //try to recover boolean recovered = invokeRecoveryHandler( data, destination, e ); if (recovered==true) { //we must change the primitive intf. a bit prim.setRecovered( true ); } else { throw e; } } isLeaf = true; } ... } } MailFiler <http://www.mailfiler.com> [AG-JU4UEF4] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003 |
From: Guevara, A. <Ale...@uh...> - 2003-05-08 01:16:45
|
I've done some progress in replacing the hapi home grown logging mechanism with the jakarta-commons-logging framework. DONE: - All references to the hapi Log interface has been removed and the Log interface itselft, plus related classes have been marked as deprecated. - package ca.uhn.log has been added. - interface HapiLog, and classes HapiLogImpl and HapiLogFactory have been added to pachake ca.uhn.log. - the javadoc of the class HapiLog contains information about how to use the new logging framework. - exception classes have been changed to contain the cause of the exception. - in all places where the an error is being logged and an exception is being propagated have been modified to only propagate the exception-and the cause of it (to avoid having the same problem logged twince) NOTE that now hapi depends on the jakarta-commons-logging framework. TODO - look into replacing the class Status with well known patterns of jakarta-logging usage. Meaning that if want to output status information, the underlying logging framework must be used, by invoking the log.info( ... ) method. - create a std hapi log4j cinfiguration file. - ... This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. |
From: Tripp, B. <Bry...@uh...> - 2003-05-06 17:32:11
|
My replies to a recent volunteer came back undelivered. If you volunteered last week, and didn't hear from me, and are from Beijing, and are named Vito Zhang, please send me an alternate email address. Thanks, Bryan This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. |