Hi,
regarding the two examples mentioned:
1. ADT_A17 in fact is a message structure which contains a duplicated
sequence of segments. The specified abstract message syntax is:
MSH
[ { SFT } ]
EVN
PID
[ PD1 ]
PV1
[ PV2 ]
[ { DB1 } ]
[ { OBX } ]
PID
[ PD1 ]
PV1
[ PV2 ]
[ { DB1 } ]
[ { OBX } ]
The first segment sequence references patient 1, the second sequence
references patient 2.
For a lib like HAPI it's hard to distinguish these segments except for in
fact renaming the segment. IMHO the specification is broken here (same e.g.
with ADT_A24) - there should be two groups (or a repeatable group)
containing the segment sequence so one could properly navigate to the
desired segment.
2. Speaking of groups: as of HL7v2.3.1, message groups are used to solve
problems like the one described above. A group contains substructures
(segments or nested groups), and has its own cardinality (i.e. a group can
be optional or repeating). Mostly for compatibility reasons, you cannot
"see" a group directly in a HL7 text message, but once you parse it, the
created HAPI object graph reflects the specified structure of the message.
So if you want a textual comparison of messages, you need to compare the
text messages (without HAPI). If you want to verify the message against a
custom specification, HL7 conformance profiles might be an option. Maybe you
can be more concrete here for better advise.
cheers
Christian
Ian Vowles wrote:
>
> First, please understand I am far from a HAPI expert. I am learning
> myself, and watch the list for questions that may help me improve my
> understanding.
>
> I suspect that some of what you are seeing is the need to get a java
> language construct to reflect the standard as well as it possibly can,
> but it's hard to be perfect. Some decisions may be made for the
> convenience of people using the tool. Your first point, the use of PID
> and PID2 is possibly an example of naming for convenience of using the
> structure, such that the two PIDs can be easily distinguished.
>
> With regard to you second point, my memory of the structures is
> notoriously bad, so I went to a copy of the 2.3.1 vs I have on hand, and
> the group structure you mention is shown in the standard. So it is
> possible to have repeating PID, PD1, MRG and PV1 group in this message.
> Never seen that happen, but it's permitted.
>
> I'm sorry that this is not really helpful in assisting you sort out the
> validation. Hopefully once you have identified what the HAPI
> implementation is doing with some of the tricky ones, it will be
> possible to identify in the code where this happens, and allow for the
> HAPI implementation differences.
>
> Ian
>
>
>>>> <melissa.ra...@thomsonreuters.com> 26/09/11 23:06 >>>
>
> We are trying to validate the structure of an HL7 message at runtime by
> comparing the Segment names and their respective order with the
> structure implicit the messages corresponding structure. We do this by
> comparing an ordered List of segments derived from a deep call to
> getNames() method of the Message with HAPI*s ReadOnlyMessageIterator
> that collects the actual segments from the message. What we have found
> is that with Merge events the structure names are different than the
> actual segments used in the message.
>
> 2 Examples:
> 1. a HAPI ADT_A17 names it*s 2nd PID as *PID2* while the HL7 spec
> simply has 2 PIDs in the message
> 2. For merge events certain segments are derived from a group,
> such as an A39 which gets the PID from the PATIENT group. The actual HL7
> for an A39 however does not reflect this group structure.
>
> Are there any recommendations for getting around this? Thanks.
>
> ----------------------
> Melissa Rabin | Senior Software Engineer | Healthcare & Science |
> Thomson Reuters| W 215 463 4461 | M 267 271 2227
>
>
> ********************************************************************************
> 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.
> **********************************************************************************
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Hl7api-devel mailing list
> Hl7api-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
>
--
View this message in context:
http://old.nabble.com/Structural-comparison-of-HL7-Messages-tp32540286p32548306.html
Sent from the hl7api-devel mailing list archive at Nabble.com.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Hl7api-devel mailing list
Hl7api-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
