This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

OO CR106 - Unexpected Values

From HL7Wiki
Revision as of 21:55, 20 November 2012 by Hbuitendijk (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Return to OO Change Requests page.

Submitted by: Ken McCaslin Revision date: <<Revision Date>>
Submitted date: 6 November 2012 Change request ID: OO CR106
Standard/IG: Standard Artifact ID, Name: <<Artifact ID, Name>>

Issue

The original order and how compliant the order is to the requirements of LRI IG can be problematic. This has the potential to create a few problems in constructing a LRI IG compliant result message.

  • ORC/OBR-2 Placer Number. The identifier for Placer Number based on how the Order was provided to the lab may not provide enough detail so that the lab can construct appropriate information for the subfields of the Placer Number including the description of names space ID. When this is the case, what is the best way to manage the subfields of the EI data type?
    • Use MSH.4 if present, use MSH.3 next if MSH.4 is not present, otherwise put in name of sending system in ORC-2.2 OBR-2.2.
    • Motion to accept as proposed and move as errata. Ken McCaslin, Riki Merrick
      • Against: 0; Abstain: 0; In Favor: 5
  • PID-2 and other fields (PID-4, PID-19, PID-20) might be used by some order systems. When moving the data from alternate fields; what is the approriate assumed default identifier for data in those other fields and has it been document some place as the data is moved to PID-3 to be compliant with LRI IG?
    • Is PT universally known as the identifier for what was in PID-2?
    • What is used for PID-4?
    • What is used for PID-18?
    • Everything from PID-2 can be considered PT. PID-19 can be considerd SN. PID-20 can be considered DL. PID-4 use CX-5 (identifier type), but if not present can be considered U.
    • Motion to accept guidance as proposed for errata. Ken McCaslin, Scott Robertson
      • Against: 0; Abstain: 0: In Favor: 5
  • PID-7 Date of Birth, the order may not have complete information, particularly for newborn screens, therefore the lab does not have the appropriate information as defined by LRI IG. Has does the lab message that the data provide was not appropriate or sufficient for the LRI IG?
    • Some people put 3D in this field on the Order. How to echo this back?
    • LRI IG states RE, so in the absences of a valid date this could be kept blank.
    • Motion to consider this out of scope for the IG, where the IG allows a blank field. Riki Merrick, Ken McCaslin.
      • Against: 0; Abstain: 0; In Favor: 9
  • Some fields in the LRI IG have constrained tables that may not be known by the sending system.
    • The Lab Ordering System sends in PID-10 a race identifier that is not supported by the table outlined in LRI IG (Table 0005). Should the lab send the field empty or send the code as sent by the original ordering system back to the system receiving the results?
    • Considering that there are other tables that might be constrained and the order systems may send items that are not consistent LRI IG, how should the labs manage this issue for other fields?
    • Since this is a user defined code set, other values can be agreed on for that implementation. So you can echo back what you got (code, text, other).
    • Motion to accept proposal that since this is a user defined value set, one can echo back what one received. Ken McCaslin, Riki Merrick
      • Against: 0; Abstain: 0; In Favor: 9

Recommendation

Rationale

Discussion

Recommended Action Items

Resolution