This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Datatypes R2 Issue 14"

From HL7Wiki
Jump to navigation Jump to search
(revamped proposal to clarify it's intent and focus on it only)
 
Line 1: Line 1:
== Data Types Issue 14: Relax Unit Constraint on PQ ==
+
== Data Types Issue 14: Clarify Measurement Concept for use with PQ ==
  
 
== Introduction ==
 
== Introduction ==
  
Change PQ.unit so that it does not have to a valid UCUM code.
+
It's clear that a physical quantity is a tri-value:
 +
*the number
 +
*the units
 +
*the thing being measured
  
Currently PQ.unit must be a valid UCUM code. There is a few things that you want to do with a PQ where the units you have to express are not UCUM units. Example: 3 tablets
+
In a PQ, we have only modelled the first 2 parts, on the basis that the third comes from the context. There is a few cases where the third element, what is being measured, doesn't come from the context. In this case, people want to encode this information it the unit, and cannot really do that, it is wrong to try. This always causes confusion with dimensionless quantities, where the unit is 1 (the "unity"), but confusion is not limited to dimensionless quantities, for example, 1 m might be a length of a tape or a wave length, which are vastly different measurement concepts.
  
? backward compatible: This element will be semantically backward compatible but will introduce new possible values for the PQ.unit field
+
We need to resolve whether
  
Pharmacy
+
EITHER
  
== Discussion ==
+
*the context should provide the third piece of information and needs to be fixed if it doesn't
  
The unit of measure specified in the Unified Code for Units of Measure (UCUM) or any other unit of measure
+
OR
  
This is a very, very bad idea. Didn't we want to be interoperable? --[[User:Gschadow|Gschadow]] 01:22, 25 Jun 2006 (CDT)
+
*we need to extend PQ to handle the third part.
  
 +
== Discussion ==
  
Grahame Grieve:
+
It is extremely important that it be clear that Observation.code (or Observation.definition) set the context for any PQ in an Observation.value and that whatever attribute is of type PQ define the measurement concept specifically. [[User:Gschadow|Gschadow]]
This proposal is introduced as there was no other proposal made regarding PQ, and this was informally proposed before the call for R2 proposals was released.
 
 
 
I personally do not support this proposal (see below), but we need to discuss this
 
 
 
Grahame:
 
It's clear that a physical quantity is a tri-value:
 
* the number
 
* the units
 
* the thing being measured
 
 
 
In a PQ, we have only modelled the first 2 parts, on the basis that the third comes from the context. There is a few cases where the third element, what is being measured, doesn't come from the context. In this case, people want to call it the unit, but this is wrong. Generally the unit is unity - *but not always*.
 
 
 
I think that we need to resolve whether
 
* the context should provide the third piece of information and 
 
  needs to be fixed if it doesn't
 
or
 
* we need to extend PQ to handle the third part.
 
 
 
Gunther:
 
It is extremely important that it be clear that Observation.code (or Observation.definition) set the context for any PQ in an Observation.value and that whatever attribute is of type PQ define the measurement concept specifically.
 
  
The context (such as the definition of the attribute) in which the PQ is used must define what thing that the PQ is a quantity of. + Add examples + add warnings against being an idiot.
+
The context (such as the definition of the attribute) in which the PQ is used must define what thing that the PQ is a quantity of.  
  
'''(much other correspondence not reproduced here)'''
+
*Add examples
 +
*add warnings against being an idiot.
  
 
== Disposition ==
 
== Disposition ==

Latest revision as of 13:25, 20 June 2007

Data Types Issue 14: Clarify Measurement Concept for use with PQ

Introduction

It's clear that a physical quantity is a tri-value:

  • the number
  • the units
  • the thing being measured

In a PQ, we have only modelled the first 2 parts, on the basis that the third comes from the context. There is a few cases where the third element, what is being measured, doesn't come from the context. In this case, people want to encode this information it the unit, and cannot really do that, it is wrong to try. This always causes confusion with dimensionless quantities, where the unit is 1 (the "unity"), but confusion is not limited to dimensionless quantities, for example, 1 m might be a length of a tape or a wave length, which are vastly different measurement concepts.

We need to resolve whether

EITHER

  • the context should provide the third piece of information and needs to be fixed if it doesn't

OR

  • we need to extend PQ to handle the third part.

Discussion

It is extremely important that it be clear that Observation.code (or Observation.definition) set the context for any PQ in an Observation.value and that whatever attribute is of type PQ define the measurement concept specifically. Gschadow

The context (such as the definition of the attribute) in which the PQ is used must define what thing that the PQ is a quantity of.

  • Add examples
  • add warnings against being an idiot.

Disposition

Grahame added clarification text explaining why UCUM is required.

Status

Proposed

Links

Back to Data Types R2 issues