This page is part of the FHIR Specification (v0.05: DSTU 1 Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions
This specification describes the use of the dataAbsentReason attribute, which is used throughout the content models on elements of any type to indicate missing data. The dataAbsentReason attribute "may appear on any element in a resource other than those marked mandatory".
In Object-Orientated paradigms, the dataAbsentReason is a mixin. The definition of a mix-in is that it is an abstract class that provides functionality that is not inherited by specialization but rather by collecting functionality. A mixin can be thought of as a generic class that specializes its parameter class:
This shows a mixin called "DataQualityAspect" which expresses the attribute "dataAbsentReason". The two derived classes, DataQualityAspectQuantity which inherits both Quantity and DataQualityAspect and DataQualityAspect(Quantity), which binds Quantity to the parameter T on the DataQualityAspect mixin both have the same semantics (are identical other than their type derivation).
The problem with this approach is that not only is the <<mixin>> stereotype not a recognised standard UML syntax, but most mainstream programming languages cannot implement multiple inheritance in this form. There are two alternative approaches for implementing mixins in object-oriented platforms. The first is using a wrapper class:
The problem with this variation is that Quantity and DataQualityAspect(Quantity) are no longer both types of Quantity, as with a pure mixin and this will have a series of effects on implementations. The other alternative is simply to make DataQualityAspect a base class:
This is the simplest approach, but has the disadvantage that all instances of the Quantity data type carry the dataAbsentReason attribute, whether it is appropriate or not.
Implementers that use these objects in an environment where mixins are not supported must choose one of these two approaches. For simplicity, the object models defined in this specification simply bind the target type directly to the specified data type, and ignore the issue of the dataAbsentReason mixin.
Note that the dataAbsentReason may also be associated with primitive types as well so use of one of these mixin mechanisms will be required there as well.
This is an old version of FHIR retained for archive purposes. Do not use for anything else
Implementers are welcome to experiment with the content defined here, but should note that the contents are subject to change without prior notice.
© HL7.org 2011 - 2012. FHIR v0.05 generated on Sun, Sep 9, 2012 03:28+1000. License