#50 ORU_R01_OBSERVATION incorrectly defined

closed
None
5
2006-12-14
2005-11-28
Anonymous
No

HL7 specification says that this group has more than
one OBX segment. But in the API seems to have only
one of this kind of segment.

Discussion

  • Charles D. Fisher

    Logged In: YES
    user_id=170594

    This is unlikely to be completely true, because we at the
    New York State Department of Health use HAPI to parse HL7
    2.3 and 2.3.1 ORU_R01 messages with multiple OBX segments
    and it works okay. So it is unclear what problem the
    submitter ran into.

     
  • bmamlin

    bmamlin - 2006-05-13

    Logged In: YES
    user_id=1208332

    This bug exists in v2.5 beta. The ORU_R01_ORDER_OBSERVATION
    group contains ORU_R01_OBSERVATION as a non-repeating member
    when, according to the HL7 specification, the
    ORU_R01_OBSERVATION group can optionally repeat within an
    ORDER_OBSERVATION group.

     
  • Charles D. Fisher

    Logged In: YES
    user_id=170594

    I don't know what I was thinking when I wrote the comment
    below about how this was "unlikely to be completely true."
    What a crock. Now that I have been trying to parse a v2.5
    ORU_R01 message unsuccessfully and I have delved deeper into
    the source code, I think it is completely true.

    In v2.4, the structure diagram for this part of the ORU_R01 was
    "{ ... OBR ... { [OBX] {[NTE]} ... }"
    and the line of code that adds the ORU_R01_OBSERVATION group
    to the ORU_R01_ORDER_OBSERVATION group was
    "this.add(ORU_R01_OBSERVATION.class, true, true);".
    The subgroup as a whole had only the repetition braces
    around it, but not the optionality brackets, therefore the
    group was required and repeating.

    In v2.5 the structure diagram was changed to
    "{ ... OBR ... [{ OBX {[NTE]} }] ... }"
    and the line of code was changed to
    "this.add(ORU_R01_OBSERVATION.class, true, false);".
    The change in this code is exactly backwards. The group
    gained the optionality and retained the repetition. So it
    should be
    "this.add(ORU_R01_OBSERVATION.class, false, true);"

    Since the code was, as I understand it, generated from the
    Access database that defines the standard, either the
    standard is in error or the code generation logic is in
    error. Or I could be in error, if there is some aspect of
    this I do not understand. Unfortunately I do not have a
    copy of the Access database, or I would be able to drill
    down further.

    Can someone confirm or correct my analysis of the situation?

     
  • bmamlin

    bmamlin - 2006-06-27

    Logged In: YES
    user_id=1208332

    Your analysis is correct. I altered the code in my copy
    until the code is re-generated correctly. At the top of
    ca.uhn.hl7v2.model.v25.group.ORU_R01_ORDER_OBSERVATION.java,
    my source now reads as follows (just as you concluded):

    /\*\* 
     \* Creates a new ORU\_R01\_ORDER\_OBSERVATION Group.
     \*/
    public ORU\_R01\_ORDER\_OBSERVATION\(Group parent,
    

    ModelClassFactory factory) {
    super(parent, factory);
    try {
    this.add(ORC.class, false, false);
    this.add(OBR.class, true, false);
    this.add(NTE.class, false, true);
    this.add(ORU_R01_TIMING_QTY.class, true, false);
    this.add(CTD.class, false, false);
    this.add(ORU_R01_OBSERVATION.class, false, true); //
    changed to optional repeating group (Burke Mamlin 5/13/2006)
    this.add(FT1.class, false, true);
    this.add(CTI.class, false, true);
    this.add(ORU_R01_SPECIMEN.class, true, false);
    } catch(HL7Exception e) {

    HapiLogFactory.getHapiLog(this.getClass()).error("Unexpected
    error creating ORU_R01_ORDER_OBSERVATION - this is probably
    a bug in the source code generator.", e);
    }
    }

     
  • James Agnew

    James Agnew - 2006-12-11

    Logged In: YES
    user_id=881509
    Originator: NO

    This is a problem with the sourcegen module. I will be looking at fixing it for the next release.

     
  • James Agnew

    James Agnew - 2006-12-11
    • assigned_to: nobody --> jamesagnew
     
  • James Agnew

    James Agnew - 2006-12-14

    Logged In: YES
    user_id=881509
    Originator: NO

    Ok, problem solved. It was an issue in GroupGenerator#getGroupDef.

    This will be included in the next release.

     
  • James Agnew

    James Agnew - 2006-12-14
    • status: open --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks