#8 InvalidCastException trying to set data type of OBX-5

Parser (14)

NHapi.Base.HL7Exception: System.InvalidCastException trying to set data type of OBX-5 ---> System.InvalidCastException: Unable to cast object of type 'NHapi.Model.V21.Datatype.ST' to type 'NHapi.Base.Model.Varies'.
at NHapi.Base.Model.Varies.fixOBX5(ISegment segment, IModelClassFactory factory) in C:\projects\nhapi\NHapi.Base\Model\Varies.cs:line 135

PID|||||LASTNAME^FIRSTNAME^||19590307|F||B|||PHONE|||S| |||||||||| ^^L
OBR|||RC2826-1^REG_LAB|5794^WOUND CULTURE^LCR|||200801101951|||||||200801101949|^^^3992&right&L^4920&ankle&L|||||5794^WOUND CULTURE^LCR~||200801141227|||C|||||||||WNK^^L|
OBX|1|CE|5795^WOUND SMEAR 1^LCR||13620^no organisms seen^L||||||F|
OBX|2|CE|5807^ORG 1^LCR||14416^MRSA^L|||A|||F|
OBX|2|TX|5807^ORG 1^LCR||, FOR MIC, SEE LEFT ANKLE WOUND CULTURE 10-JAN-08 @ 19:49||||||F|
OBX|3|CE|4840^ORG 2^LCR||1490^Proteus mirabilis^L|||A|||F|


  • Mark Nahirny

    Mark Nahirny - 2008-05-29

    Logged In: YES
    Originator: NO

    This bug is due to the OBX segment 5 in the HL7Models NHAPI.Model.V21 project being set to a type ST rather than the type Varies. This is inconsistent with the other HL7 models. The simple fix is to change the NHAPI.Model.V21\Segment\OBX.cs file to:
    public class OBX : AbstractSegment {

    * Creates a OBX (RESULT) segment object that belongs to the given
    * message.
    public OBX(IGroup parent, IModelClassFactory factory) : base(parent,factory) {
    IMessage message = Message;
    try {
    this.add(typeof(SI), false, 1, 4, new System.Object[]{message}, "SET ID - OBSERVATION SIMPLE");
    this.add(typeof(ID), false, 1, 2, new System.Object[]{message, 125}, "VALUE TYPE");
    this.add(typeof(CE), true, 1, 80, new System.Object[]{message}, "OBSERVATION IDENTIFIER");
    this.add(typeof(NM), false, 1, 20, new System.Object[]{message}, "OBSERVATION SUB-ID");
    // this.add(typeof(ST), true, 1, 65, new System.Object[]{message}, "OBSERVATION RESULTS");
    this.add(typeof(Varies), false, 1, 65, new System.Object[] { message }, "OBSERVATION RESULTS");
    this.add(typeof(ID), false, 1, 20, new System.Object[] { message, 0 }, "UNITS");
    this.add(typeof(ST), false, 1, 60, new System.Object[]{message}, "REFERENCES RANGE");
    this.add(typeof(ST), false, 5, 10, new System.Object[]{message}, "ABNORMAL FLAGS");
    this.add(typeof(NM), false, 1, 5, new System.Object[]{message}, "PROBABILITY");
    this.add(typeof(ID), false, 1, 5, new System.Object[]{message, 80}, "NATURE OF ABNORMAL TEST");
    this.add(typeof(ID), false, 1, 2, new System.Object[]{message, 85}, "OBSERV RESULT STATUS");
    this.add(typeof(TS), false, 1, 19, new System.Object[]{message}, "DATE LAST OBS NORMAL VALUES");
    } catch (HL7Exception he) {
    HapiLogFactory.GetHapiLog(GetType()).Error("Can't instantiate " + GetType().Name, he);

  • ChadC

    ChadC - 2008-05-29

    Logged In: YES
    Originator: NO

    I actually don't think this is a bug? According to the HL7 2.1 specification that I have of the OBX segment, OBX-5 is supposed to be an ST and not varies [http://www3.uch.edu/hl7/hl7v21segmOBX.htm]. However, the above comment will fix the issue if you want to recompile.

  • ChadC

    ChadC - 2008-05-29
    • status: open --> pending
  • Mark Nahirny

    Mark Nahirny - 2008-05-30

    Logged In: YES
    Originator: NO

    You're right about the HL7 2.1 spec for OBX segments, and I understand why the OBX class was coded as it is. However, it seems to me that there is an inconsistency in the HL7 2.1 spec in that the OBX-2 (value type) allows for types other than ST. So if a message contains an allowed value type other than ST, a run-time error occurs (InvalidCastException) in the cast in the fixOBX5 function. Since an exception should not occur for a valid HL7 message, either the fixOBX5 function should not be called for version 2.1 messages, or the 2.1 OBX class should be changed. For consistency with the spec, probably the fixOBX function should not be called.

  • SourceForge Robot

    Logged In: YES
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

  • SourceForge Robot

    • status: pending --> closed