|
|
Class steward is Orders/Observation
Interested committees Patient Care
Observations are actions performed in order to determine an answer or result value. Observation result values are specific information about the observed object. The type and constraints of result values depend on the kind of action performed.
The observation action and observation result are modeled as being the two aspects of the same concept, just like the two faces of a coin are not separable from each other. Most other published healthcare models, including earlier HL7 RIM versions, separate the activity of observing and the observation result into different classes. These models label the kind of action in one class and the kind of observation result in the other. In most cases, however, the test name is a label for both activity and observation result. So, in merging action with the result, the two codes are now only one.
Derived observations can be defined through association with other observations using relationships of derivation type (Service_relationship.type_cd = derivation.) For example, to define a derived observation for Mean Corpuscular Hemoglobin (MCH) one will associate the MCH observation with an Hemoglobin (HGB) observation (Service_relationship.sequence_nmb = 1) and a Red Blood cell Count (RBC) observation (Service_relationship.sequence_nmb = 2) Since MCH = HGB / RBC, the value of the derivation expression would be “$1 / $2”.
The derivation expression is a character string with a simple syntax similar to that of the UNIX "expr" utility, or the expression subset of the PERL or TCL language. All observations that are cited in the formula must be associated with the derived observation through links of type derivation with a unique Service_relationship.sequence_nmb. Such observation values are referred to by that sequence number preceded by a dollar sign ($).
Defined operators are addition (+), subtraction (?), multiplication (*) and division (/). Parentheses can be used to overcome the usual precedence (left to right, multiplication before addition.) In addition to the basic arithmetic operations the usual mathematical functions are defined.
OpenIssue: The definition of this field's syntax needs to be completed.
The result value of an observation action. As was true with HL7 v2, this value can be of any data type. However, there are clearly more or less reasonable choices of data types as indicated in the table below.
Kind of observation Data type Notes Quantitative measurements PQ Physical quantity (real number with unit.) This is the most usual choice. Note that numeric values must not be communicated as a simple character string (ST.) Titer (e.g., 1:64) and other ratios (e.g. 1 out of 1000) RTO A ratio of two integer numbers (e.g., 1:128.) Sometimes by local conventions titers are reported as just the denominator (e.g., 32 instead of 1/32) Such conventions are confusing and should not be followed in HL7 messages. Index (number without unit) REAL When a quantity does not have a proper unit, one can just send the number as a real number. Alternatively one can use a PQ with a dimensionless unit (e.g., 1 or %). An integer number should only be sent when the measurement is by definition an integer, which is an extremely rare case and then is most likely an ordinal (see below.) Ranges (e.g., < 3; 12-20) IVL<PQ> Interval of physical quantity. Note that sometimes such intervals are used to report the uncertainty of measurement value. For uncertainty there are dedicated data type extensions available. Ordinals (e.g., stage "IIa") CV, INT At this point, ordinals should be reported either as code values, (e.g., +, ++, +++; or I, IIa, IIb, III, IV) or as integers. In the future ordinals may be addressed by a separate data type. Nominal results, "taxons" (e.g. organism type.) CD The Concept Descriptor (CD) is the most common data type to use for categorical results (e.g., diagnosis, complaint, color.) Such qualitative results are rarely simple Code Values (CV) if there is a tightly defined code system which everyone uses. Image (still, movie) ED The encapsulated data type allows one to send an image (e.g., chest X-ray) or a movie (e.g., coronary angiography, cardiac echo.) Waveform Waveforms can be sent using the waveform template developed by the Automated Data SIG for version 2.3. A mapping onto version 3 is shown farther below. In addition one can use the Encapsulated Data (ED) type to send waveforms in other formats. Formalized expressions ST The character string data type may exceptionally be used to convey formalized expressions that do not fit in any of the existing data types. However, use of the string data type is not allowed if the meaning can be represented by one of the existing data types. Note that many of the data types do have character string literal expressions too, so the field in the message can be formatted using character string literals and still have a distinct data type. Bulk text reports ED A detailed procedure report should normally be sent in the attribute Service.descr. The Observation.value should be reserved for computer interpretable or automatically generated information. Note that the Encapsulated Data type (ED) can accommodate formatted text in such common formats as HTML, PDF, or Word Processor formats. The ED data type can also carry dictation that is not yet transcribed. We strongly discourage to send formatted text as result values. At the very least, the formatted text should be broken down into sections, one per sub-service object.