Action-based vs. result-based properties of Observations
This page documents an Open MnM Hot Topic, i.e. a methodology issue requiring a resolution from Modeling and Methodology.
Introduction
During the disambiguation of negationInd we dealt with the duality between action and statement about the action that is inherent in every HL7v3 Act. It was then noted that the Observation class has not only action (object-level) and statement (meta-level) properties, but also properties describing the action (question, investigation method) and its result (answer). It became clear that for some attributes (most notably negationInd again), but also for associations with other classes, it is necessary to clarify whether it relates to the action itself or to the result.
Background
In HL7 v2 and early versions of the v3 RIM (v0084 of 1998) today's Observation class was split over PatientServiceEvent and ClinicalObservation. Then, ClinicalObservation was not a Service (Act) but just that, an Observation. This distinction roots in HL7 v2's distinction of the observation request/report segment (OBR) and the observation result segment (OBX). Beginning 1999, Observation was understood as a kind of service action, explicitly carrying the notions of an activity (to observe) performed by someone at some time and place, and the result value or information product of this observation.
The motivation for discussing these basic concepts is an MnM discussion in 2008, where a proposal was made for a new attribute of Observation, value_negationInd, that would specifically negate the result of the Observation, and not the Observation as a whole (i.e., it wouldn't say that the Observation didn't take place, but that it's result was NOT X).
Similar discussions around Act.negationInd had motivated a review of Inert vs. descriptive properties of Acts, which discusses that a communicated action carries both moments of action per se (propositional content, object language) and statement about the action (carrying illocutionary properties, or meta language, e.g., mood). Now with Observations, there appear to be 4 moments. For example, take the observation: "I certify that I have determined that this patient has diabetes mellitus."
- observation-act as action (object-language): "I certify that ..."
- statement about the observation-act (meta-language): "... I have determined ..."
- statement about the subject which the observation makes (predication) "... this patient has ..."
- phenomenon whose presence is being predicated (especially finding observations) "... diabetes mellitus"
When a "negationInd" attribute appears on an Observation class combining all these 4 moments, we need to be sure to know what is being negated. Which is it: (1) "I do not certify that ..." , (2) "... I have not determined ...", (3) "... this patient does not have ...", or (4) "... something other than diabetes mellitus"? Given that the negationInd is defined to be a descriptive or object-language property, we know that it is not the first option. But since all of the other (2), (3), and (4) are all object-language related part of the observation action, it seemed appropriate to propose this second attribute named "value_negationInd" such that the Act.negationInd would negate (2) and the value negation indicator would negate (3) or (4).
We have the same issue with some associated dependent statements, most notably Severity, that is commonly modeled as an Observation of sorts, an observation about the primary observation [1] The severity is not a statement about the observation action (I haven't "severely observed"), but about what the observation predicates ("severe headache").
Discussion
The observation action and the predication that it yields (result) are inextricably linked. But we will have to talk about the different ways that observation is used and abused. Once that is cleared up (realistically clearing this up is as nice to have as it is impossible), we might say that there are two stages in an Observation:
- an action to find an answer
- the answer found through the action.
The action defines what you can find. If you read a meter you find numbers. If you ask a yes-no-question you find yes or no. If you ask an open question you find free text. If you look at this text finding features you find features in the answer. If you look for shapes under a microscope you find shapes.
There is no statement of a result that can stand without also saying what was done to get that result. Do heights not exist without people measuring them? They may or may not, we don't need the scholastic dispute, but what matters is that if you speak about height, you have to say what height and at least roughly how it was measured. You cannot even think of an abstract height without considering how you would measure it. Metrology tells us that measured properties are to be defined in an operational manner (operational is just a synonym for actionable, i.e., no property without the possibility of a measurement act.)
Alternative solutions
- Write into the definition of every property and every dependent Observation.code whether it is dependent and on which of the multiple levels of its subject Observation it focuses.
- Write into the definition of every ActRelationship type whether it refers to the action itself or to the result of the Observation.
- Specialize type codes that can may be used ambiguously in different contexts, to be able to choose the one that matches it purpose more precisely.
- Add an extra attribute to ActRelationship that can be set to specify the distinction.
This is clearly not different from something like context conduction, which is also usually clear from context, but has a specific attribute to allow (or even enforce) setting it explicitly. I don't see why we should treat it any differently...
In the case of Severity though, I actually feel we would still benefit from a separate attribute on the Observation, just like a new attribute was proposed to negate the value. Again, I don't see why we should treat these any differently...
By the way, there is still the alternative option
4) We separate the action and the result into two separate classes, so that any association explicitly refers to either one with no extra effort. It's radical, but it's also neat.
- ↑ before throwing in the popular term "meta-observation" one should be aware that this would just confuse the use of the meta word.
