Requirements-Static Model Features

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

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

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

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

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

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

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

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

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

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

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

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: a Concept Domain and an optional set of vocabulary guidance a reference to a Value Set along with a Coding Strength and possibly a value set version id a single fixed code from a particular Code System
MIF	mif-model-staticBase.xsd/Attribute/vocabulary mif-model-datatype.xsd/DatatypeOperation/vocabularySpecification

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

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