Datatypes R2 Issue 2

Data Types Issue 2: Add DRVQ mixin for Quantity

How does this relate with PQXF An extended form of the PQ data type for simple factors.? The latter was a harmonization proposal that passed. (Raising this doesn't mean I am against this one, just want it to be noted.) Gschadow 21:39, 11 January 2007 (CST)

Grahame:

So, let's asusume that we have just one thing for both these proposals, and let's assume that we call it EXPR instead of DRVQ or PQXF. We may change our minds if it get's too complex, but, well, let' s try for both.

So, let's assume this as a definition: template<QTY T> type Expression<T> alias EXPR<T> specializes T {

  ED  expression;
  CS  language;
  CS  mood;

};

mood: below, Lloyd proposes that the expression may define how the value was calculated, or how it can be calculated. Since it may be ambiguous whether to evaluate the expression at any time, it might be safer to indicate the intention of providing the expression. Possible values:

• UseExpressionAlways
• UseExpressionIfVariablesAvailable (i.e. there is also a default value provided)
• ExpressionForReferenceOnly

language: we have discussed before that you could infer language from mediatype, rather than coding it. Maybe this is possible, and maybe it's an ITS issue. The issues I see with it are that the mediatype is orthogonal to language. text/plain is perfectly suitable for OCL, for instance. And what would you do to fix the the language to OCL? would you have to allow for XMI, to allow OCL? I think it would be better to define language as a primary property of EXPR, but then in the ITS or notes provide some informative mappings to mediaTypes. Alternatively, we could leave it up to the ITS to decide whether to use mediatype as a primary, and make language a derived property. But if language is a CS, is it extensible? what are the extensibility rules?

expression: the direct expression. Obviously ED allows for reference, and that's good. We could invest in banning properties such as translation - but then again, maybe not. Does schematron count as a translation of OCL in terms of ED.translation? depends on the rules of that, which are still open. Expression can't be mandatory, because the model must allow EXPR<T> in case an expression is required.

other issues:

conformance - does the expression change null rules? The answer at the abstract level has to be no - if an expression is provided and the null rules are not met - or maybe whenever relevant, or maybe as guided by moodCode - the expression must be evaluated when evaluating some or all of the properties.

the main question is, how does this work. With what we have described, we could stop there, and say that we have provided the information structures required to make it work. But what we haven't done is explained how it actually works. For each language, we need to define:

• how does the language address information from the context. (this is going to be language

 and ITS dependent)

• how does the expression derive the value - all values are complex types (at least from

 the perspective of any language that is not wholly centered on the RIM and V3 datatypes)
 So how does the language derive a value for nullFlavor, for instance?

So, there is some problems there. We can duck our heads on this, but we couldn't claim that this is serving interoperability.

Finally, which languages do we support? It seems to me that the PQXF proposal is effectively an EXPR with a defined language, and this has the appeal of simplicity and is pretty much ITS independent. So I would propose that we define this language directly as a supported language in EXPR.

other languages we have considered:

• OCL
• MathML
• Xpath
• Gunther and Grahame's smost excellent HPath syntax

Introduction

Add a mixin that allows internal representation of the derivation of the value for a Quantity. The current approach of using derivationExpression requires implementers to look in two different places for the value of an attribute. It is also complex using derivationExpression to express the values of datatype properties.

Backward compatible: We will need to transition from any existing use of derivationExpression. In practice it has been used minimally if at all.

Pharmacy, Orders & Observations

Discussion

Added under Generic Type Extensions: Derived Quantity (DRVQ) specializes T

Definition: A generic data type extension that tags a derivation expression to any quantity datatype or datatype property. The expression provides a formula for how the value of the quantity was or is to be derived based on other parameters conveyed within the instance.

Definition xxx:

template<QUANTITY T>
type DerivedQuantity<T> alias CALC<T> specializes T {
   ST derivationExpression;
};
      

Derivation Expression (derivationExpression : ST)

Definition: The formula by which the value property of the type has been calculated or is to be calculated. <We need to decide what the language for derivationExpression should be>

XML Representation

 <gsd:templatename="DRVQ">
   <gsd:paramname="T" type="QUANTITY" />
   <xsd:complexType>
       <xsd:complexContent>
           <xsd:extension>
               <gsd:attributename="base" type="T" />
               <xsd:sequence>
                   <xsd:elementname="derivationExpression" ... />
               </xsd:sequence>
           </xsd:extension>
       </xsd:complexContent>
   </xsd:complexType>
 </gsd:template> 
   

Derivation Expression: ST

 <xsd:elementname="derivationExpression" minOccurs="0" maxOccurs="1" type=”ST”/>

We need to be able to “cascade” this to properties inside a type. For example, if I have a datatype of DRVQ<GTS>, that should mean I have derivationExpression available for each of the quantity properties inside the GTS. For example if the GTS is implemented via the intersection of IVL<TS> and PIVL, I should be able to put a derivation expression on the lower bound and width of the interval and the frequency of the PIVL.

No clue how best to handle this in UML though. Althernative is to put DRVQ into all internal datatype properties or to create DRVQ variants of all the datatypes with the necessary changes to the properties.

This may be freely used in Observation.value. Anywhere else it is required will necessitate a RIM change. Specific places where it will need to be introduced include:

• SubstanceAdministration.doseQuantity URG<DRVQ<PQ>>
• SubstanceAdministration.rateQuantity URG<DRVQ<RTO<PQ>>>
• SubstanceAdministration.maxDoseQuantity URG<DRVQ<RTO<PQ>>>
• Act.effectiveTime DRVQ<GTS>

Gunther and Grahame discussed this at Orlando. For exactly the same grounds as above, We were going to propose this mixin:

 type EXPR<T>  extends T {
   ED expression; 
   CS expressionLanguage; 
 }

Drop expressionLanguage. Describe supported Mime Types, general language binding information + possibly specific language information. No side effects

ExpressionLanguage would a controlled CS. Valid values we propose as a start are OCL and MathML.

Here’s an example syntax:

 <doseQty expr="250 mg/kg * $bodymass"/> 

 <substanceAdministration> 
   <doseQty xsi:type="EXPT_PQ" value="250" unit="mg/kg" exprLang="mathml"> 
     <expression mediaType="text/xml"> 
       <times ref="$bodymass"/> 
     </expression> 
   </doseQty> 
   <inputParameter> 
     <localVariableName>bodymass</localVariableName> 
     <subset code="MOST_RECENT"> 
     <observation moodCode="DEF"> 
        
     </observation> 
   </inputParamter> 
 </substanceAdministration>

Lloyd: I'm comfortable with this approach, but am not clear how it manages the cascading issue. If I define EXPR<GTS>, how does that propagate to the IVL<TS> or PIVL<TS>, etc. that make up the GTS instance?

Status

Proposed

Links

Back to Data Types R2 issues