Suggestions to model marking an observation as "Abnormal"

Development
41

It doesn’t make sense to me to enter a realistic-appearing number that isn’t actually correct. If I saw that example I would assume that the answer really is 24.

Re “[we] have to put [in] a value” – What number do you enter for a hemolyzed potassium?

Jonathan

42

Currently (until we support obs with exceptions), we are not allowed to have an obs without a value, so we (at AMPATH) came up with two possible workarounds:

(1) LAB ERROR concept + comment

LAB ERROR = Serum Potassium1

1Specimen hemolyzed ← obs comment

(2) Obs group

LAB WITH EXCEPTION     LAB ERROR = Serum Potassum     REASON FOR ERROR = Specimen hemolyzed

The obs group allows for codified exception messages (instead of only free text comments), but is more cumbersome. I believe they’re using the first workaround at AMPATH.

43

So, could we do something similar here, using either method to represent the concepts LESS THAN RANGE and GREATER THAN RANGE rather than an arbitrary number? It will avoid the concept overload that we are discussing here.

Back to the main theme of this thread, I’d support the change to add FHIR < and > to our core list.

44

Burke and I discussed this (what to do when the lab test returns “OUT OF TEST RANGE”) today and reached agreement given his constraints on what is and is not possible:

  1. In the ideal world, the lab value would be a discrete concept, which could be as simple as EXCEPTION for anything – which then would be explained by the interpretation field. This could handle out of range low, out of range high, hemolyzed, sample dropped on floor, insufficient sample, etc.

  2. Burke notes that currently, there must be a numeric answer as the lab value. So, other than calling for #1 to happen ASAP, there apparently has to be some number even if there’s no basis for it. For less than range, I’d suggest “0”; for greater than range (kinda rare), hemolyzed, dropped, I can’t really suggest a value. Maybe one needs to choose some unlikely value like “99999” for everything; there’s no good answer given this constraint.

  3. Regardless of the above, keeping < and > or similar as attributes makes sense.

  4. Otherwise the list of proposed exception flags is as attached above.