This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Datatypes R2 Issue 51"

From HL7Wiki
Jump to navigation Jump to search
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
== Data Types Issue 51: CO numeric value ==
+
== Data Types Issue 51: Support for Likert scales ==
  
 
== Introduction ==
 
== Introduction ==
Line 37: Line 37:
 
[[User:DanR|DanR]] 10:46, 17 May 2006 (CDT)
 
[[User:DanR|DanR]] 10:46, 17 May 2006 (CDT)
  
Dan Russler asks for an extension of CO where you could actually
+
Backwards compatibility: this would be backwards compatible
have a numeric value as in  
+
 
 +
== Discussion ==
 +
 
 +
'''Grahame''': regarding the original proposal, to extend CO so you could actually
 +
have a numeric value as in <value xsi:type="CO" value="2" code="xyz" codeSystem="..." displayName="eye opening to pain"/>, this is counter to the whole point of designing CO the way it has been designed. It was deliberately designed this way to avoid the trap of explicitly representing the order in a non-manageable fashion, and delegating the order to the CTS.
  
<value xsi:type="CO" value="2" code="xyz" codeSystem="..." displayName="eye opening to pain"/>
+
type CodedOrdinal alias CO specializes CV {
 +
  REAL value;
 +
  BL  lessOrEqual(CO o);
 +
  BL  lessThan(CO o);
 +
  BL  greaterThan(CO o);
 +
  BL  greaterOrEqual(CO o);
 +
};
  
and then also he wants translations, so CO would have to extend
+
If the value is null, the relative order of CO values need not be independently obvious in their literal representation. It is expected that an application will look up the ordering of these values from some table.  
CE rather than CV.
 
  
We'd also have to add an operation
+
If the value is not null, the relative order of the CO values is defined by the value of the value property.  
INT plus(CO)
 
to the abstract definition of CO.
 
  
Backwards compatibility: this would be backwards compatible
+
word smith comments about relationship between values and null values and math functions.
  
== Discussion ==
+
Motion: Accept the disposition that we add REAL value to CO. (Grahame/Sandy) Vote 18-1-3
  
'''Grahame''': This is counter to the whole point of designing CO the way it has been designed. It was deliberately designed this way to avoid the trap of explicitly representing the order in a non-manageable fashion, and delgating the order to the CTS -> invite Dan to contribute.
+
Note: Subsequent discussion: define addition and subtraction properties
 +
:That's not right. You can't add an ordinal to anything. And why is this REAL and not INT? BTW, I think arguments about "CTS" things are entirely unrelated, because data type semantics is not about software architecture. [[User:Gschadow|Gschadow]] 17:50, 5 May 2007 (CDT)
  
 
== Links ==
 
== Links ==
 
Back to [[Data Types R2 issues]]
 
Back to [[Data Types R2 issues]]

Latest revision as of 22:50, 5 May 2007

Data Types Issue 51: Support for Likert scales

Introduction

Supporting Likert Scales:

Many clinical findings are derived from arithmetic calculations from Likert Scales, e.g. Apgar scores, Barthel Index.

To make the link to HL7 Vocabulary Tooling...

Likert scales are often published as value sets for a particular question or test:

Value Set for Agreement Scale:

a) Strongly Agree : 1

b) Agree : 2

c) Neither Agree nor Disagree : 3

d) Disagree : 4

e) Strongly Disagree : 5

Often, multiple individual Likert scores are added together to produce a composite score, e.g. Agree X 3 = score of 6.

If we refer to the formating in the value set above as "Original Text" : "Corresponding Value," we can imagine that we would like to communicate observation results that support both the Original Text and the Corresponding Value in the same communication. These would both be communicated as the result for a single question, i.e. one is not more important than the other.

One could also imagine that "Original Text" might be coded by a coding system like SNOMED. Unlikely, but also possible, is that the Corresponding Value coding could be changed from arabic base10 to some other arithmetically equivalent expression.

Although many people have tried to model the communication solution using multiple observations or by sticking the Corresponding Value in a numeric data type (in observation.value) and the coded Original Text in a coded datatype (in observation.interpretationCode), these solutions are awkward.

The proposal is that a datatype solution be considered rather than the specific "CO extension" noted below.

Thanks

DanR 10:46, 17 May 2006 (CDT)

Backwards compatibility: this would be backwards compatible

Discussion

Grahame: regarding the original proposal, to extend CO so you could actually have a numeric value as in <value xsi:type="CO" value="2" code="xyz" codeSystem="..." displayName="eye opening to pain"/>, this is counter to the whole point of designing CO the way it has been designed. It was deliberately designed this way to avoid the trap of explicitly representing the order in a non-manageable fashion, and delegating the order to the CTS.

type CodedOrdinal alias CO specializes CV {

  REAL value;
  BL  lessOrEqual(CO o);
  BL  lessThan(CO o);
  BL  greaterThan(CO o);
  BL  greaterOrEqual(CO o);

};

If the value is null, the relative order of CO values need not be independently obvious in their literal representation. It is expected that an application will look up the ordering of these values from some table.

If the value is not null, the relative order of the CO values is defined by the value of the value property.

word smith comments about relationship between values and null values and math functions.

Motion: Accept the disposition that we add REAL value to CO. (Grahame/Sandy) Vote 18-1-3

Note: Subsequent discussion: define addition and subtraction properties

That's not right. You can't add an ordinal to anything. And why is this REAL and not INT? BTW, I think arguments about "CTS" things are entirely unrelated, because data type semantics is not about software architecture. Gschadow 17:50, 5 May 2007 (CDT)

Links

Back to Data Types R2 issues