Requirements-Static Model Features

From HL7Wiki
Jump to navigation Jump to search

This section documents requirements that span datatypes and static models or multiple components of static models.

General Features

These requirements apply to static model attributes, static model association ends and datatype properties.

Requirement Class attributes, datatype properties and association ends must have a unique name within their containing structure (class or datatype).
Rationale Names allow the feature to be referenced and are important to most wire formats. They also allow human identification
MIF
  • mif-model-datatype.xsd/Property/@name
  • mif-model-staticBase.xsd/Attribute/@name
  • mif-model-staticBase.xsd/AssociationEndBase/@name
OMG Properties are named elements in UML.


Requirement Class attributes, datatype properties and associations must be able to indicate whether they are allowed to be 'null' values.
Rationale Not all occurrences of an attribute will necessarily have a value. For example, the data might be unknown, be temporarily unavailable, be masked from view for security reasons, etc. In some cases, there's a requirement that the element must be present with a 'real' value. For each attribute, there's a need to know whether that attribute is allowed to be null or not.
MIF mif-model-staticBase.xsd/StructuralFeature/@isMandatory
OMG My understanding is that this is different than just having a minimum multiplicity of zero, so it needs to be included as a tagged value of an HL7 stereotype.


Requirement Class attributes, datatype properties and associations must be able to indicate whether they must be supported by implementers or not, and if not, how they're expected to be treated if present in an instance.
Rationale Because standards may be implemented in a wide variety of environments, it's not possible (or reasonable) to expect that implementers will support each and every feature available in a standard. At the same time, failure of implementers to support certain "essential" features will lead to interoperability issues. There is therefore a need to distinguish within the standard which elements must be supported by everyone and which ones are "optional". Similarly, if an application chooses to not support an element, it needs to be clear whether the element will be considered "not allowed" or will merely be ignored, as this also has implications for interoperability.
Methodology
  • I - Ignored - Implementers receiving this property must not raise an error, but will not perform any useful function with the data.
  • R - Required - All implementers must support this property. I.e. they must be able to transmit, or to receive and usefully handle the concept.
  • NP - Not Permitted - All implementers are prohibited from transmitting this content, and may raise an error if they receive it.
  • U - Undetermined - The conformance expectations for this element have not yet been determined.
MIF mif-model-staticBase.xsd/StructuralFeature/@conformance
OMG Tagged value on a property stereotype.


Requirement Class attributes, datatype properties and association ends must be able to indicate minimum and maximum limits on the number of allowed repetitions.
Rationale Many model components need to be able to repeat. Failure to agree on the allowed number of repetitions can result in interoperability issues. For example, if one system sends 3 repetitions when the receiver can only handle 2, or if the receiver expects a minimum of 4
MIF
  • mif-model-staticBase.xsd/MultiplicityRangeRequired/@minimumMultiplicity
  • mif-model-staticBase.xsd/MultiplicityRangeRequired/@maximumMultiplicity
OMG UML properties have multiplicity with minimum and maximum bounds.


Requirement Class attributes, datatype properties and association ends must be able to indicate a sort order from a "business" perspective.
Rationale The sort order associated with each attribute, association and datatype property is determined at the Reference model and universal datatypes level. This provides consistency of ordering across models within instances. However, it doesn't always result in an ordering that makes sense from a business perspective when presenting to a clinical audience. For example, there's an expectation that dosage information would appear together on a prescription or contact information would appear together on a person. Having a distinct business sort order allows for both types of ordering.
MIF
  • mif-model-staticBase.xsd/AssociationEndBase/@businessSortKey
  • mif-model-staticBase.xsd/Feature/@businessSortKey
OMG Properties in UML can be marked as "ordered", but this does not provide a sort key from a "business" perspective. Therefore, such a key would need to be provided as a tagged value on a property stereotype.


Attribute and Property Features

These requirements do not apply to association ends.

Requirement Class attributes and datatype properties with types convertible to string must be able to identify their default values
Rationale Within the RIM, default values can be omitted from instances. For other static models, default values give guidance to implementers on what is an appropriate default.
MIF Issue In theory there may be a use-case for default values for attributes and properties with types that are not expressible as strings. E.g. CD, ED. It's also possible there could be a use-case for defaults for an association. Neither of these are supported by MIF at present.
MIF mif-model-staticBase.xsd/Attribute/@defaultValue
OMG Attributes in UML can have default values.


Requirement Class attributes and datatype properties with types convertible to string must be able to identify their fixed values
Rationale Fixed values are common constraints on what value an attribute or property may have in an instance, particularly for structural attributes that are often constrained to a fixed value within a given static model.
MIF Issue In theory there may be a use-case for fixed values for attributes with types that are not expressible as strings. E.g. CD, ED.
MIF mif-model-staticBase.xsd/Attribute/@fixedValue
OMG This can be specified either as a tagged value on a property stereotype or as a stereotyped constraint.


Requirement Class attributes and datatype properties with types convertible to string must be able to identify defaults that are determined based on the implementation environment rather than specific values
Rationale Some attributes and properties such as language, realm, country, etc. can be defaulted based the environment in which the instance is being communicated. However, this requires the ability to differentiate between a default that is a "value" vs. a default that is a textual explanation of how the environmental default is determined.
MIF mif-model-staticBase.xsd/Attribute/@defaultFrom
OMG In addition to a literal specification, a default value in UML can be an opaque expression which can include "a textual explanation of how the environmental default is determined".


Requirement Class attributes and datatype properties with types convertible to string must be able to identify constraints on the length of the values expressed.
Rationale Mismatch in support for lengths can result in interoperability issues. For example if the sender sends 50 characters but the receiver can only process 40 characters, information will be lost. Obviously the concept of "length" is not meaningful if the attribute can't be expressed as a string.
MIF
  • mif-model-staticBase.xsd/Attribute/@minimumLength
  • mif-model-staticBase.xsd/Attribute/@maximumLength
OMG Tagged values on a property stereotype. (Or, alternatively, expressed as a constraint.)


Requirement Class attributes and datatype properties with types convertible to string that are not coded datatypes must be able to identify allowed enumeration values.
Rationale It's common for specifications to restrict string, number and similar fields to one of a small list of allowed values.
MIF Issue

Not currently supported by tools and, as yet, no-one's asked for support

MIF mif-model-staticBase.xsd/StructuralFeature/enumerationValue
OMG This could be supported by a tagged value pointing to an enumeration or by a constraint to a specific set of values.


Requirement Class attributes and datatype properties that are derived from QTY need to allow identification of the allowed range of values.
Rationale It's common to constrain numbers and time values to limits. E.g. 0-10, 1990-2010, etc.
MIF Issue

Not presently supported by tools.

MIF mif-model-staticBase.xsd/StructuralFeature/allowedRange
OMG Tagged value on a property stereotype or a constraint.


Requirement Class attributes and datatype properties with coded datatypes (or which can be constrained to coded datatypes, e.g. ANY) need to identify the vocabulary constraints for the element.
Rationale Knowing something is coded without having any idea on the set of codes that can be used doesn't accomplish much.
Methodology Codeable elements can be associated with one of the following:
MIF
  • mif-model-staticBase.xsd/Attribute/vocabulary
  • mif-model-datatype.xsd/DatatypeOperation/vocabularySpecification
OMG Tagged values on a property stereotype.


Class element features

These features apply to association ends and attributes, but not to datatype properties.

Requirement Models must support a mechanism for discrete updates and history rather than require re-transmission of an entire record each time it is revised.
Rationale Some types of models are too large and are updated too frequently for it to be reasonable to send a complete 'snapshot' each time the record changes. As well, the receiver may get updates from multiple sources and is really only interested in what information has been most recently changed. Receiving data that has not recently changed could lead them to replace local data when what they have is actually newer.
Methodology HL7 allows attributes and association ends to have "update modes". Within the model, a set of allowed modes as well as a default mode can be specified. In an instance, a single mode appears indicating the specific type of change that is to happen to that element. The update modes are as follows:
  • A - Add
  • D - Remove
  • R - Replace
  • AR - Add or Replace
  • N - No change
  • U - Unknown
  • K - Key
  • REF - Reference
MIF
  • mif-model-staticBase.xsd/UpdateMode/@updateModeDefault
  • mif-model-staticBase.xsd/UpdateMode/@updateModesAllowed
OMG Update modes could be supported by tagged values on a property stereotype. Pf course, any use of this information would require specific tool support.


Requirement When creating a derived specification, model authors need to be able to identify "extensions" that are not part of the base model.
Rationale While HL7 methodology is centered on a premise of derivation and constraint, reality is that in some realms and implementation, strict constraint is not possible. HL7 therefore allows extensions, provided that they are marked in the instance and can be ignored by the receiver. To allow this, extension attributes and associations obviously need to be distinguished from those which are not extensions.
Methodology Extensions are flagged with the OID that should be used as the namespace for the element in the instance.
MIF
  • mif-model-staticBase.xsd/Extensibility/@extensionOID
  • mif-model-staticBase.xsd/Attribute/@maximumLength
OMG Tagged value on a property stereotype.