Attendees: Hans, Craig, Andrea, Kathy, Riki, Dan

20171031_LabUSrealm_Notes

LRI-156:

Feedback from the email thread:

Quest / Freida: I favor Option 2 over Option 1

Jay Lyle: 1. I'm afraid I don't understand why a change is needed.

Is the question, if the test result is not available (OBX-11 = X), what should be put in the value (OBX-5)? And is the problem that, if you put a null code there, systems that expect numbers choke? 2.5 - 2.8 have OBX-5 as conditional, which seems to answer the requirement. Why do the functional requirements suggest changing this? (I’m not seeing a specification of the conditions; I assume they are OBX-11 = X or N) Option 1 suggests adding 11.9: it's not clear why. Option 2 suggests adding an absent reason; again, is there some suggestion that "Results cannot be obtained for this observation" is insufficient?

2. The main lesson of the negation project is that "negation" is a treacherous word. We need to distinguish between the absence of some clinical phenomenon (e.g., a negative test interpretation), the absence of information (which I think is a null, possibly with an additional conceptual reason for absence), actions that were not performed (represented here by the status), and the refutation of a proposition (not germane here). From my perspective, the correct value for OBX-5 is either blank or NULL, OBX-11 can be used to provide some limited context of why it's null, and if there is more information needed about why it's null I don't see it in the discussion.

Dan Rutz, Epic: I also prefer Option 2, as it’s both less disruptive to current functionality (at least in OBX- 11) and also more actionable for the recipient (a new field with specific data absent reason, preferably CWE with recommended coded values, is easier to validate or act upon programmatically).

However, I do have a few points to consider as well: A. The requirement on the new field should be when OBX-11 = X (and likely D and, and maybe W, I’m flexible on that), and not on OBX-5 being empty. B. In general blank OBX-5s should be allowed if: a. A data absent reason is included in the new field b. An interpretation code is still sent in OBX-8 c. OBX-11 has another appropriate reason (like N, perhaps I) d. Also, in typical usage it can indicate a blank line in a textual report or have a subsequent comment which is relevant to still file (I don’t exactly like either of these and I know it’s not recommended, but it happens often enough I’d rather not fight with it here).

Diego Lopez: I also prefer option 2 and second Freida’s and Daniel’s feedback below.

Allow a blank OBX.5 if one of the reasons B-a through B-c is met. The new ‘absence reason’ CWE field could have a recommended coded value to mitigate B-d below. Clem: Agree with dan

Discussion on the call: Motion to leave as described in the FR document

Discrete micro results where when no results are available for SN just sending ‘=’ is not helpful, so good to allow empty OBX-5; in susceptibility testing can send either the numeric or structured numeric the coded interpretations in OBX-5 – ok to use the same LOINC code for that

The LOINC scale allows this change – question is that at time of definition or at time of transaction

Changing datatype for a particular OBX may determine where the data is being stored

When data is absent, may not need to change the data type to allow communication of reason for absence into the OBX-5 element.

Limiting the interpretation for susceptibilities to just be used in OBX-8 may be a solution.

If OBX-5 is blank, then MUST have either OBX-8 or new element of absent reason filled out Must consider how to handle OBX-2 and update the underlying standard depending of what solution we have

Motion to keep as is – allow change in datatype and OBX-5 MUST always be populated – Kathy

Hans to respond to email and outline the option – give it a try net week

LRI-165: CNE datatype – per base is code Required AND value set is closed Also we would need to compare how we differentiate between our CWE flavors with defined value set In IGAMT tool NIST can be specific about specific LOINC in OBX-3 as well as the format to be used in OBX-5 and the value set binding and extensibility

LRI-202: Riki to write up the derived specimen issue – need to have the AP example written up (organ to tissue to slide); also needed for isolate submissions, where you need to have information about the collected specimen

LRI-206: The categories may be helpful if we can figure out where the boundaries are for these micro related categories

Discrete organism ID – as far as it got identified – species vs genus vs gram negative cocci

How to handle the no growth – put that in NOT micro related category

Attributes of the bugs may be a category

One for quantity of organism or level of growth Organism name Organism attribute / stain etc

Or do we need to re-structure the micro reporting in order and make the OBX-3 value more prescriptive

Options: Use LOINC to be more specific – that is a lot of work and we don’t want to wait for that Leave as is and mark as for future use and ignore for this round Clarify some of the codes – or deprecate the ambiguous elements and provide a list of replacement codes that are more useful = that sounds the most reasonable approach Drop OBX-30 down to Optional Full set of 0937: AOE Ask at Order Entry ASC Ask at Specimen Collection UNSP Unspecified SUP Supplemental Result SUR Susceptibility Related MIRM Micro Isolate Related Modifier MNIR Micro Non-Isolate Related MIR Micro Isolate Related

To update MIRM, MNIR and MIR

MOD = Micro Other descriptor MSQ = Micro specimen quality (White blood cells – only in gram stains;

MCS = Micro culture status (no growth, normal flora, not isolated when used with an organism specific culture OBX-3)

MIN = Micro Isolate name (species, genus) MIGQ = Micro Isolate growth quantity (<10, 100 – 300, >300) MIGC = Micro Isolate growth category MIA = Micro Isolate attributes – gram stain, enzyme function (Catalase, beta-hemolysis status) = identify the organism, without a name MID = Micro Isolate descriptor (text)

Send to ord list based on the email from Thursday

Other domain – blood bank – transfusion status, barcodes identifier – Dan is about to submit codes for that

Motion to accept this as draft proposal for harmonization – Riki, Dan, no further discussion, against: 0, abstain: 1, in favor: 4

Next call on Thursday 11/2/2017