Datatypes R2 Issue 10

Introduction

URG means "Uncertain Range".

Add an “Uncertain Range” datatype that is a constraint on “Uncertain Value Probabilistic” but which behaves in much the same manner as an interval.

The use case is that now IVL is used for both ranges where all elements are equally valid and for ranges where only one number would be picked, like when I say "come tomorrow between 10 and 11" and of course you will only enter my door at one point in time between 10 and 11.

We often want to represent an uncertain range where the actual value is known to be somewhere between a lower-bound and an upper-bound. However, the distribution of probabilities may not be known, and is frequently quite variable. For example, in the statement “Take 1-3 tablets”, the probabilities of 1 tablet, 2 tablets and 3 tablets are non-zero. There may even be non-zero probabilities for 1.5 tablets and 2.5 tablets. However the probability of 2.37749 tablets is pretty much 0.

This concept differs from the concept of Interval, where the entire range is intended to be true.

For example, “He was in the hospital from January 1 to January 31” represents an IVL<TS>. On the other hand, “He was in the hospital one day between January 1 and January 31” represents a URG<TS>

? backward compatible: While not strictly semantically compatible with existing RIM datatypes, in practice, we’re merely updating the datatype to reflect actual semantic practice. There should be no XML instance changes as a result of this change, with the possible exception of xsi:type values

Pharmacy

Discussion

Basically copy the content of IVL, but derive the type from UVP<T> (or perhaps SET<UVP<T>>?)

Definition: Uncertain range represents a single quantity whose value falls somewhere within a specified boundary and where the probability distribution within that boundary is unknown.

This type is very similar to the Interval datatype. The distinction is that for Interval, the type represents the complete range within the identified boundary. Uncertain range represents a single unknown value drawn from the range.

All properties of IVL apply with the exception of the convex hull.

why not? --GrahameGrieve 20:36, 21 June 2007 (CDT)

invariant(URG<T> x){

 x.probability.isNull;

};

• Should look identical to the IVL expression
• Should add a note to IVL<T> explaining its distinctions from URG<T>
• Change the datatypes of the following RIM attributes from IVL<x> to URG<x>:
• Act.repeatNumber
  • SubstanceAdministration.doseQuantity
  • SubstanceAdministration.rateQuantity

Being a constraint of UVP does not really make sense.

The datatype should best be almost identical with IVL. That way all that changes (particularly in the XML) would be the xsi:type, not anything in the data which people already build and parse today. So, low, center, high, width, etc.

We can say that UVP be a specialization of IVL, which would make it completely backwards compatible.

Logically more correct would be to make it a subtype of PPD.

In my view it should be considered as a confidence interval, and so it should also receive a confidence level, which is almost like a probability (i.e., it is then the same form and almost the same meaning as an UVP<IVL<T>>.)

PPD needs to be fixed also.

--Gschadow 01:20, 25 Jun 2006 (CDT)

BOF: Not a constraint on PPD

URG<T : QTY> extends T {

 range : IVL<T>
 confidenceLevel : REAL ( 0.. 1 )

}

Lloyd: I don't think confidence interval gives what is needed. What is needed is an expression that says for any value less than "low" or greater than "high", the probability is exactly 0. For all values equal to or between low and high, the probability is unknown, with the integral of the probability across the entire range being equal to 1. For example, "Take 2-4 tablets", the probability of 1.5 tablets or 5 tablets is 0. The probability of 2.7331876 tablets is probably also 0 but you don't know for sure. The probability of 2, 2.5, 3, 3.5 and 4 tablets are >0, but you don't know exactly what the probabilities are.

Confidence interval doesn't seem to be reflecting this semantic. (Unless that's what's meant by a 100% confidence interval, and I thought that confidence intervals were dependent on certain types of distributions . . .) --Lmckenzi 09:34, 4 May 2007 (CDT)

But that's exactly what a confidence interval with 100% level means: unknown distribution but integral equals 1. Confidence intervals depend on distributions only if you have less than 100% confidence level. This 100% trick is rather odd, doesn't much occur in the real world. Anyway, all is fine I think. Gschadow 11:14, 27 May 2007 (CDT)

First attempt at Disposition

Motion in INM 2 May 2007:

We approve the addition of the CIVL type based on this definition:

CIVL<T : QTY> specialises T, IVL<T> {
 confidenceLevel : REAL ( 0.. 1 ) 
}

We need to fill this definition out and fix PPD as well. When PPD is fixed, determine if it is appropriate make URG a constraint on PPD.

Gunther / Lee but the motion was tabled.

Disposition

The CIVL proposal above is not acceptable for Lloyd's use case, by virtue of trying to be too clever - cannot do what Lloyd wants because of existing invariants. In fact, it's not possible to resolve this using a mixin - it cannot address the fundamental properties that we are concerned with.

Instead, Lloyd and I propose to define URG<T> as a specialisation of QTY. URG<T> will be defined like IVL<T> low, high, width, and center (though center is of only passing interest). In addition, we will define equals and contains, and discuss these in the context of URG. Also promotion and demotion to T. In addition, there will be a conversion to PPD<T>, though this is, err, funky.

There will be no relationship between URG and IVL - we cannot reuse IVL without having definitional problems with equality.

This is just a promise. The specification is not there to review. I don't see the reason for it not being suitable for Lloyd's use case. Hence I will vote until this is clarified. Also, the status of the proposal says "approved", but what is approved? And what exactly are we voting on today? Gschadow 07:33, 24 September 2007 (CDT)

Vote:
 For: Grahame, Lloyd, charlie
 Against: Gunther
 Abstain:

Disposition #3

CIVL is not URG. CIVL and PPD relationship needs to be clarified. URG is a problem - implementing as a plain generic (like RTO) is a problem because URG<TS> should be an acceptable replacement for TS. But implementing as a mixin is a problem, because a mixin cannot invalidate the underlying invariants of it's base type.

The only way to work around this is to say that URG is a mixin that fixes the base type to null, specifically UNK. This makes sense: a URG<TS> says that the TS value is unknown, but that it may come from a set of valid ranges.

So URG fixes the nullFlavor to UNK. The range may be specified, but either way, the value is unknown.

So defined in the specification for ballot.

Status

closed pending ballot comment.

Links

Back to Data Types R2 issues