Observable Entity

Observable Entity vs. Evaluation Procedure

The observable entity and evaluation procedure hierarchies have some of the same attributes. There is not and should not be a one-to-one correspondence between the two hierarchies.

At this time, SNOMED CT contains some concepts in the evaluation procedure hierarchy which logically belong in the observable entity hierarchy. This is a legacy problem that continues to cause confusion. These concepts will move to the observable entity hierarchy as part of the QI project in the future. In addition, if we identify existing duplicate concepts between the two hierarchies, this will also be corrected. Concepts will not be duplicated between the observable entity hierarchy and procedure hierarchy, and requests for such will not be added. In response to requests for an observable entity concept when the procedure concept exists, create an observable entity concept and inactivate the procedure concept. 

While some users have indicated they want to use a procedure concept for ordering a test and an observable concept for reporting the result, this is not an acceptable use case. An evaluation procedure being ordered implies that there is an expectation that a value, in association with the ordered procedure will be provided. Evaluation procedures, for all intents and purposes, are observables with another semantic tag. The nature of their top level parent (Evaluation procedure) implies that they require a value in order to be assessed. Thus they can be used equivalently with observables.

As for the progression of the completion of an assessment, that is related to the state diagram (i.e., status) of the progression of a procedure and should not be precoordinated, but handled by the information system in which orders are processed (it is dynamic, not static). The information system should be able to capture the status of a procedure (e.g., ordered, in process, completed). We would not expect the terminology to pre-coordinate this.

As an example, LOINC recognizes that there are three different aspects to an observable: 1) those that can serve as both an order and an observation (e.g. blood glucose level); 2) those that can be ordered but not directly resulted (e.g. urinalysis, which is a convenience order for multiple individual observations on urine); and 3) those that can only be resulted and not directly ordered (usually part of an automated system, such as computation of MCHC in hematology). LOINC assigns this aspect with an attribute value. It is not one of the six main LOINC parts typically visible to users, however it is included in the LOINC database.

Use of Observable Entities

Observables entities may be used to:

• Code elements on a checklist or assign values to elements.

For example, color of nail is an observable entity. Gray nails is a finding.

• Code headers on a template

For example, the observable entity, gender, may be used to code a section of a template titled gender. The user would choose masculine, feminine, transgender, etc. which would then constitute a finding such as 703117000 | Masculine gender (finding)| .

Types of Observable Entities

There are four general types of observable entities for use in health care. Each has different representation requirements and patterns, i.e. the set of attributes will vary.

• Quality. A characteristic, feature, or property that is inherent in someone or something.

For example, mass of a person, temperature of internal organs, concentration of sodium in plasma, angle of a joint

• Disposition. A characteristic or feature that is not always realized in full.

For example, antibiotic susceptibility of a certain population

• Function. The ability of a person, some part of a person, or a thing to perform activities or realize processes.

For example, ability to walk

• Process. A process or outcome of a process

For example, secretion rate, heart rate, respiratory rate