This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Datatypes R2 Issue 2"

From HL7Wiki
Jump to navigation Jump to search
 
Line 3: Line 3:
 
== Introduction ==
 
== 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
  
? backward compatible.
 
  
 
== Discussion ==
 
== 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>
 +
  <... code="MOST_RECENT">
 +
  <Observation moodCode="DEF">
 +
    <code code="/bodymasss/" .../>
 +
  </Observation>
 +
</inputParamter>
 +
</substanceAdministration>
 +
 +
== Disposition ==
 +
 +
 +
== Status ==
 +
 +
Proposed
  
 
== Links ==
 
== Links ==
 
Back to [[Data Types R2 issues]]
 
Back to [[Data Types R2 issues]]

Revision as of 02:58, 12 January 2007

Data Types Issue 2: Add DRVQ mixin for Quantity

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> 
  <... code="MOST_RECENT"> 
  <Observation moodCode="DEF"> 
     
  </Observation> 
</inputParamter> 

</substanceAdministration>

Disposition

Status

Proposed

Links

Back to Data Types R2 issues