This wiki has undergone a migration to Confluence found Here

Difference between revisions of "ISO Datatypes"

From HL7Wiki
Jump to navigation Jump to search
Line 461: Line 461:
  
  
==Term ==
+
====Term ====
  
 
Specializes ANY. Protected - not for use outside the datatypes in this specification
 
Specializes ANY. Protected - not for use outside the datatypes in this specification
Line 1,032: Line 1,032:
 
OCL for Invariants:
 
OCL for Invariants:
 
   inv "only one part with no type": isNotNull implies (part->size = 1 and part->first.type.oclIsUndefined)
 
   inv "only one part with no type": isNotNull implies (part->size = 1 and part->first.type.oclIsUndefined)
 
  
 
==PN (Person Name)==
 
==PN (Person Name)==

Revision as of 04:48, 19 February 2007

Scope

This International Standard specifies the shared semantics for a collection of healthcare related datatypes used in a number of health related information standards. This standard declares these datatypes using the terminology, notations and datatypes defined in 11404 rev 2003. In addition to defining the datatypes in these terms, this standard also provides UML definitions of the same datatypes using the terminology, notation and types defined in UML 2.0.

The purpose of this international standard is to provide an agreed common semantic basis for exchanging basic concepts that are commonly encountered in healthcare environments. This standard is based on considerable input from HL7, CEN, and past ISO work on healthcare datatypes.

It is expected that other healthcare information standards and specifications will define mappings for the datatypes specified herein, though direct reference or a mixture of direct reference and mappings may also be expected.

What is a datatype?

There is no clear definition of exactly what is a datatype and where a more complex structure would be appropriate. Generally the definitions of the scope of datatypes revolve around one or more of the following three notions:

  • The relationship between equality and identity
  • Coherency of a single concept

Since of both of these concepts are inherently a matter of perspective, the selection criteria for the datatypes defined in this standard is based on the set that has emerged from the debates held within the various stakeholder standards bodies that define healthcare information standards. Since healthcare information standards and specifications are expected to provide mappings to this standard, the process has been deliberately inclusive. These other standards may choose to represent these datatypes with other more complex structures, but should explain how to interconvert these structures with the datatypes defined herein.

TODO: namespace issues

Normative References

11404

base types to import from 11404

  • Boolean
  • State (for CS? - or should this be enumerated?)
  • Character - as the basis for String?
  • date-and-time? this is 8601 based, but a structured time. if 8601 based, could be used? but not for UML? the problem is that it is not well documented, and it appears that the right parts are not optional
  • Integer
  • Real
  • Class (base for ANY)
  • Set
  • Bag
  • Sequence
  • characterstring - but it's not unicode
  • Octet + OctetString
  • objectidentifier
  • Optional for nil?

Reference to UML 2

base types imported from UML 2:

  • classifier
  • Boolean
  • Integer
  • Real
  • String
  • Sequence
  • Set
  • Bag

Terms and Definitions

Should not include anything in 11404 terms and definitions?

  • HL7
  • CEN
  • UML required references

Conformance

??

Conventions

Datatypes

Summary

Each datatype defined in this specification is defined in two different ways. They are defined in terms of the datatype specification language defined in ISO 11404. In addition, the same datatype is defined in UML using primitive types taken from the UML kernel package. The UML definition is provided to foster software driven implementation of these datatypes.

Iso datatypes all.gif

This UML diagram includes all the types in a single package for ease of reference. More detailed UML diagrams are included with the the datatype definitions below.

Template

This section lays out the template that should be generally followed for each type.

Group Name

UML diagram

then for each datatype:

Name

Definition(Intension)

Discussion of scope, usage ([+Extension])

Formal definition in 11404 language

Further discussion about why it is defined the way it is.

Properties

For each property

 Name
 Definition (+parameters if any)
 Discussion of usage

Basic Datatypes

Basic Datatypes that provide infrastructural support for specific datatypes that are defined in subsequent sections.

Iso datatypes basic.gif

ANY

Definition: Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every public concrete type is a specialization of this general abstract DataValue type.

Todo: Formal definition in 11404 language

The appropriate use of all three of the attributes on ANY is intimately bound to the implementation specification with which they are used. Generally the environment will need to establish special ways to control their use.

Attributes

nullFlavor : NullFlavor: Indicates the reason that the value is unknown.

ANY is a nullable type; any instances of descendent types may also be null. Null is a special value and implementations usually have special logic for handling this. The nullFlavor attribute carries information describing why the value is null. An instance of the type ANY with a nullFlavor of NI is semantically equivalent to a null instance. If the nullFlavor of is not null, then all other attributes must be null. If the nullFlavor is null, then some of the other properties may be constrained to be not null; the invariants for the appropriate type specify the non-null attributes in this case.

Possible Values for nullFlavor:

NI NoInformation No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value
UNK unknown A proper value is applicable, but not known
ASKU asked but unknown Information was sought but not found (e.g., patient was asked but didn\’t know)
NASK not asked This information has not been sought (e.g., patient was not asked)
NAV temporarily unavailable Information is not available at this time but it is expected that it will be available later
MSK masked There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.

Warning: Using this null flavor does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.

NA not applicable No proper value is applicable in this context (e.g., last menstrual period for a male)

updateMode : UpdateMode: The principal purpose of UpdateMode is to allow a sending system to identify to a receiving system: • the changes that have occurred in an object controlled by the sending system; or • the changes that the sender desires to be made in an object controlled by the receiving system Possible Values for UpdateMode:

A Add The item was (or is to be) added, having not been present immediately before.
D Delete The item was (or is to be) removed (sometimes referred to as deleted)
R Replace The item existed previously and has (or is to be) revised.
AR Add or Replace The item was (or is to be) either added or replaced. (This option is included to support one specific case, discussed below. Its general use is discouraged, the preferred methodology is to use the combination of the individual Add and Replace values.)
N No Change There was (or is to be) no change to the item.This is primarily used when this element has not changed, but other attributes in the instance have changed.
U Unknown It's not specified whether the item was (or is to be) added, revised, or not changed

history : HXIT: Allows the changes to an individual attribute or association to be associated with an identified event that changed it. The event may convey such information as event time, author, authoring organization, data-enterer, reason, and any other accountability information as described by the environment in which the type is used.


Invariants

  • Update Mode is not allowed for null values.
  • History is not allowed for null values.

OCL for invariants:

 def: let isNull : Boolean = nullFlavor.oclIsDefined
 def: let isNotNull : Boolean = not isNull
 
 -- these are defined in order to help control updateMode and history
 def: let noUpdate : Boolean = updateMode.oclIsUndefined
 def: let noHistory : Boolean = history.oclIsUndefined
 def: let noUpdateOrHistory : Boolean = noUpdate and noHistory
 -- these 2 assertions are uncharted waters. we disallow use of updateMode and
 -- history with null until convincing use cases arise
 inv "No UpdateMode on null": isNull implies updateMode.oclIsUndefined
 inv "No History on null": isNull implies history.oclIsUndefined


HXIT

Protected - not for use outside the datatypes in this specification

Definition: Information about the history of this value: period of validity and a reference to an identified event that established this value as valid.

Todo: Formal definition in 11404 language


Attributes

validTime : IVL(TS): The time interval during which the given information was, is, or is expected to be valid.

controlActIdRef : II: The identifier of the event associated with setting the datatype to its specified value. By referencing a particular event, the property links to all of the information surrounding that event, such as who made the change, when it was made, why it was made, what system originated the change, etc, as specified in the implementation specification.

Invariants

  • The HXIT must have a valid time if it is not null
  • The II cannot have a history on an updateMode

OCL for invariants:

 -- this constraint is not part of the abstract model. It may be relaxed
 -- if a use case presents
 inv "must have a valid time": validTime.oclIsDefined and validTime.isNotNull
 inv "no updateMode or History": (validTime.oclIsUndefined or validTime.noUpdateOrHistory)
      and (controlActIdRef.oclIsUndefined or controlActIdRef.noUpdateOrHistory)


BL

Specializes ANY

Definition: BL stands for the values of two-valued logic. A BL value can be either true or false, or, as any other value may be NULL.

Todo: Formal definition in 11404 language

With any data value potentially being NULL, the two-valued logic is effectively extended to a three-valued logic as shown in the following truth tables:

NOT AND true false NULL OR true false NULL
true false true true false NULL true true true True
false true false false false false false true false NULL
NULL NULL NULL NULL false NULL NULL true NULL NULL

Where a boolean operation is performed upon 2 data types with different nullFlavors, the nullFlavor of the result is the first common ancestor of the 2 different nullFlavors, though conformant applications may also create a result that is any common ancestor (such as NI)

Attributes

value: Boolean: The value of the BL if it is non Null.

Invariants

  • The BL must have a value if it is not null

OCL for invariants:

 inv "value required if not null": isNotNull implies value.oclIsDefined
 -- nullFlavor invariants
 inv "no value if null": isNull implies value.oclIsUndefined


Text And Content Data Types

Basic Datatypes that provide infrastructural support for specific datatypes that are defined in subsequent sections.

Iso datatypes text.gif

Content

Specializes ANY. This is a protected type - it cannot be used outside of this specification

Definition: Content is an abstract type introduced to define of language

Todo: Formal definition in 11404 language

Attributes

language: Code: The human language of the content||Valid codes are taken from the Internet standard RFC 3066 (http://www.ietf.org/rfc/rfc3066.txt). The HL7 OID for this domain is 2.16.840.1.113883.5.57.

Invariants


OCL for invariants:

 -- nullFlavor invariants
 inv "no language if null": isNull implies langauge.oclIsUndefined

Data

Specializes Content. This is a protected type - it cannot be used outside of this specification.

Definition: Data is an abstract type introduced as a common type for the definition of properties shared between ED and ED.thumbnail.

Todo: Formal definition in 11404 language


Attributes

value : Binary: The human language of the content

charset : Code: For character-based encoding types, this property specifies the character set and character encoding used in the value that contains the content of the ED. The charset shall be identified by an Internet Assigned Numbers Authority (IANA) Charset Registration [1] in accordance with http://www.ietf.org/rfc/rfc2978.txt (http://www.ietf.org/rfc/rfc2978.txt). The charset property needs to be known where the data of the ED is character type data in any form. If the data is provided directly in the value attribute, then the charset must be known. If the data is provided as a reference, and the access method does not provide the charset for the data (such as by a mime header), then the charset must be conveyed as part of the ED.

compression : Compression: Indicates whether the raw byte data is compressed, and what compression algorithm was used

mediaType : Code: Identifies the type of the encapsulated data and identifies a method to interpret or render the data. The IANA defined domain of media types is established by the Internet standard http://www.ietf.org/rfc/rfc2045.txt (http://www.ietf.org/rfc/rfc2045.txt) and http://www.ietf.org/rfc/rfc2046.txt (http://www.ietf.org/rfc/rfc2046.txt).

encoding : EncodingType: Identifies the encoding type used in the value content. The content in the value may be either base64Binary content (refer xml schema defintiion (todo)), or it may be unencoded

Invariants

OCL for invariants:

 -- nullFlavor invariants:
 inv "no value if null": isNull implies value.oclIsUndefined
 inv "no charset if null": isNull implies charset.oclIsUndefined
 inv "no compression if null": isNull implies compression.oclIsUndefined
 inv "no mediaType if null": isNull implies mediaType.oclIsUndefined


ED

Specializes Data

Definition: Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard (e.g., XML-signatures.) Encapsulated data can be present in two forms, inline or by reference. Inline data is communicated or moved as part of the encapsulated data value, whereas by-reference data may reside at a different (remote) location. The data is the same whether it is located inline or remote.

Todo: Formal definition in 11404 language

Attributes

reference : URI : A telecommunication address (TEL), such as a URL for HTTP or FTP, which will resolve to precisely the same binary data that could as well have been provided as inline data. The semantic value of an encapsulated data value is the same, regardless whether the data is present inline data or just by-reference. However, an encapsulated data value without inline data behaves differently, since any attempt to examine the data requires the data to be downloaded from the reference. An encapsulated data value may have both inline data and a reference

integrityCheck : Binary: The integrity check is a short binary value representing a cryptographically strong checksum that is calculated over the binary data. The purpose of this property, when communicated with a reference is for anyone to validate later whether the reference still resolved to the same data that the reference resolved to when the encapsulated data value with reference was created.

integrityCheckAlgorithm : IntegrityCheckAlgorithm: Specifies the algorithm used to compute the integrityCheck value

thumbnail : Data: An abbreviated rendition of the full data. A thumbnail requires significantly fewer resources than the full data, while still maintaining some distinctive similarity with the full data. A thumbnail is typically used with by-reference encapsulated data. It allows a user to select data more efficiently before actually downloading through the reference.

Invariants

  • An integrityCheckAlgorithm must be provided if an integrityCheck is provided
  • Either reference or data must be provided if not null

OCL for invariants:

 inv "integrityCheckAlgorithm required": integrityCheck.oclIsDefined implies integrityCheckAlgorithm.oclIsDefined
 inv "reference or value": isNotNull implies ((reference.oclIsDefined and reference.isNotNull) or value.oclIsDefined)
 -- nullFlavor invariants
 inv "no reference if null": isNull implies reference.oclIsUndefined
 inv "no integrityCheck if null": isNull implies integrityCheck.oclIsUndefined
 inv "no integrityCheckAlgorithm if null": isNull implies integrityCheckAlgorithm.oclIsUndefined
 inv "no thumbnail if null": isNull implies (thumbnail.oclIsUndefined or thumbnail.isNull)
 inv "thumbnail has value": thumbnail.oclIsDefined and thumbnail.isNotNull implies thumbnail.value.oclIsDefined


ST (Character String)

Specializes Content

Definition: The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions.

Attributes

value : String: The actual content of the string. String values are always Unicode.

Invariants

OCL for invariants:

 -- nullFlavor invariants
 inv "null or content" : isNull xor (value.oclIsDefined and value.size > 0)

SC (Coded String)

Specializes ST

Definition: A character string that optionally may have a code attached. The text must always be present if a code is present. The code is often a local code. SC is used in cases where coding is exceptional (e.g., user text messages are essentially text messages, and a printable message is the important content. Yet, sometimes messages come from a catalog of canned messages, which SC allows to reference.

Attributes

code : Term: The coded value associated with the string.


Invariants

  • If there is a code, there must also be some content on the SC (and therefore the SC must not be null)

OCL for invariants:

 inv "no code if no value" : code.notNull implies isNotNull
 inv "no updateMode or History": (code.oclIsUndefined or code.noUpdateOrHistory)

Coded Data Types (Terminology)

These datatypes provide support for use of codes and terms from terminologies and classifications.

Iso datatypes terms.gif

Content

Term

Specializes ANY. Protected - not for use outside the datatypes in this specification

Definition: Represents a term taken from some defined codesystem or terminology. This is a private class. One of the specialisations should be used for actually representing concepts in practice.

Attributes

code : String: The plain code symbol defined by the code system. if the code value is empty or null, then there is no code in the code system that represents the concept.

codeSystem : Uid: Specifies the code system that defines the code, or code System in which no code was found. Code systems shall be referred to by a UID, which allows unambiguous reference to standard code systems and other local codesystems. Where either ISO or HL7 have assigned UID to code Systems, then these UIDs shall be used. Local sites must use their ISO Object Identifier (OID) to construct a globally unique local coding system identifier.

codeSystemName : String: The common name of the coding system. The code system name has no computational value. The purpose of a code system name is to assist an unaided human interpreter of a code value to interpret codeSystem.

codeSystemVersion : String: If applicable, a version descriptor defined specifically for the given code system.

displayName : ST: A name or title for the code, under which the sending system shows the code value to its users. displayName is included both as a courtesy to an unaided human interpreter of a code value and as a documentation of the name used to display the concept to the user. The display name has no functional meaning; it can never exist without a code; and it can never modify the meaning of code.

originalText : ED: The text or phrase used as the basis for the coding. The original text exists in a scenario where an originator of the information does not assign a code, but where the code is assigned later by a coder (post-coding.) In the production of a concept descriptor, original text may thus exist without a code.

NOTE: Although post-coding is often performed from free text information, such as documents, scanned images or dictation, multi-media data is explicitly not permitted as original text. Also, the original text property is not meant to be a link into the entire source document. The original text is an excerpt of the relevant information in the original sources, rather than a pointer or exact reproduction. Thus the original text is to be represented in plain text form.

NOTE: The details of the link between different artifacts of medical information (e.g., document and coded result) is outside the scope of this specification and may be further proscribed in specifications that use this specification.

qualifier : Sequence(CR): Specifies additional codes that increase the specificity of the primary code. Qualifiers constrain the meaning of the primary code, but cannot negate it or change it’s meaning to that of another value in the primary coding system. Qualifiers can only be used according to well-defined rules of post-coordination. A value of type CD may only have qualifiers if it’s code system defines the use of such qualifiers or if there is a third code system that specifies how other code systems may be combined

Invariants

  • A codesystem is required if not null
  • codeSystemName must be null if codeSystem is null
  • codeSystemVersion must be null if codeSystem is null
  • Qualifiers can only be specified if a code is provided

OCL for invariants:

 def: let hasOriginalText : Boolean = originalText.oclIsDefined and originalText.isNotNull
 def: let hasCode : Boolean = code.oclIsDefined
 def: let hasCodeSystem : Boolean = codeSystem.oclIsDefined
 inv "null or code and/or originalText": notNull implies (hasCode or hasOriginalText or hasCodeSystem)
 inv "qualifiers only if code": qualifier->size > 0 implies code.oclIsDefined
 inv "code only if codeSystem": code.oclIsDefined implies codeSystem.oclIsDefined
 inv "codeSystemName only if codeSystem": codeSystemName.oclIsDefined implies codeSystem.oclIsDefined
 inv "codeSystemVersion only if codeSystem": codeSystemVersion.oclIsDefined implies codeSystem.oclIsDefined
 inv "displayName only if code": displayName.oclIsDefined implies code.oclIsDefined
 inv "no updateMode or History": (displayName.oclIsUndefined or displayName.noUpdateOrHistory) and
      (originalText.oclIsUndefined or originalText.noUpdateOrHistory)
 -- nullFlavor invariants
 inv "no code if null": isNull implies code.oclIsUndefined
 inv "no codeSystem if null": isNull implies codeSystem.oclIsUndefined
 inv "no codeSystemName if null": isNull implies codeSystemName.oclIsUndefined
 inv "no codeSystemVersion if null": isNull implies codeSystemVersion.oclIsUndefined
 inv "no displayName if null": isNull implies displayName.oclIsUndefined
 inv "no originalText if null": isNull implies originalText.oclIsUndefined
 inv "no qualifier if null": isNull implies qualifier.oclIsUndefinedCR)


CD (Concept Descriptor)

Specializes Term

Definition: A CD represents any kind of concept usually by giving a code defined in a code system. A CD can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A CD can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In cases of an exceptional value, the CD need not contain a code but only the original text describing that concept.

Attributes

translation : Sequence(Translation): A set of other concept descriptors that translate this concept descriptor into other code systems or into synonyms in the same code system. Each element of the translation set was translated from the containg CD. Each translation may, however, also contain translations. Thus, when a code is translated multiple times the information about which code served as the input to which translation will be preserved.

Invariants

OCL for invariants:

 -- so you can make constraints ffrom outside that the term or on of it's translations belongs to the specified codeSystem
 def: let fromCodeSystem(system : Uid) : Boolean = codeSystem = system or translation->select(t | t.fromCodeSystem(system))->size > 0
 inv "no updateMode or History": translation->forAll(t | t.oclIsDefined and t.noUpdateOrHistory)
 -- nullFlavor invariants
 inv "no translations if null": isNull implies translations->size() = 0


CR (Concept Role)

Definition: A concept qualifier code with optionally named role. Both qualifier role and value codes must be defined by the coding system of the CD containing the concept qualifier. For example, if SNOMED RT defines a concept "leg", a role relation "has-laterality", and another concept "left", the concept role relation allows to add the qualifier "has-laterality: left" to a primary code "leg" to construct the meaning "left leg". The use of qualifiers is strictly governed by the code system used. CD does not permit using code qualifiers with code systems that do not provide for qualifiers (e.g. pre-coordinated systems, such as LOINC, ICD-10 PCS.)

TODO: this definition is a problem

Attributes

name : CV: Specifies the manner in which the concept role value contributes to the meaning of a code phrase. For example, if SNOMED RT defines a concept "leg", a role relation "has-laterality", and another concept "left", the concept role relation allows to add the qualifier "has-laterality: left" to a primary code "leg" to construct the meaning "left leg". In this example, name is "has-laterality". If the parent CD.codeSystem allows postcoordination but no role names (e.g. SNOMED) then name can be null

value : Term: The concept that modifies the primary code of a code phrase through the role relation. For example, if SNOMED RT defines a concept "leg", a role relation "has-laterality", and another concept "left", the concept role relation allows adding the qualifier "has-laterality: left" to a primary code "leg" to construct the meaning "left leg". In this example, value is "left". value is of type Term and thus can in turn have qualifiers, allowing qualifiers to nest. Qualifiers can only be used as far as the underlying code system defines them. It is not allowed to use any kind of qualifiers for code systems that do not explicitly allow and regulate such use of qualifiers.

inverted : Boolean: Indicates if the sense of name is inverted. This can be used in cases where the underlying code system defines inversion but does not provide reciprocal pairs of role names. By default, inverted is false. Roles may only be inverted if the underlying coding system allows such inversion. Notably, if a coding system defines roles in inverse pairs or intentionally does not define certain inversions, the appropriate role code (e.g. "caused-by") must be used rather than inversion. It must be known whether the inverted property is true or false, since if it is null, the role cannot be interpreted.

Invariants

  • A value must be provided if the CR is not null

OCL for invariants:

 inv "null or value": notNull implies value.oclIsDefined and value.isNotNull
 inv "no updateMode or History": (name.oclIsUndefined or name.noUpdateOrHistory)
     and (value.oclIsUndefined or value.noUpdateOrHistory)


CE (Coded With Equivalents)

Specializes CD

Definition: Coded data that consists of a coded value and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes may exist, but post coordination is not appropriate.

Invariants

  • No Qualifiers on a CE
  • The translations are not allowed to contain qualifiers. Note : This policy is under review

OCL for invariants:

 inv "no qualifiers": qualifier.size = 0
 -- this is a little controversial
 inv "no qualifiers on translations": translation->forAll(t | t.qualifier->size = 0)


CV (Coded Value)

Specializes CE

Definition: Coded data, specifying only a code, code system, and optionally display name and original text. Used only as the type of properties of other data types. CV is used when any reasonable use case will require only a single code value to be sent. Thus, it should not be used in circumstances where multiple alternative codes for a given value are desired. This type may be used with both the CNE (coded, non-extensible) and the CWE (coded, with extensibility) domain qualifiers

Invariants

  • No translations are allowed

OCL for invariants:

 inv "no translations": translation.size = 0


CO (Coded Ordinal)

Specializes CV

Definition: Coded data, where the coding system from which the code comes is ordered. CO adds semantics related to ordering so that models that make use of such domains may introduce model elements that involve statements about the order of the terms in a domain.

Attributes

value : Integer: a numerical value associated with the coded ordinal value.

Invariants

OCL for invariants:

 inv "no value if null": isNull implies value.isNull


CS (Coded Simple Value)

Specializes ANY

Definition: Coded data in its simplest form, where only the code is not predetermined. The code system and code system version are implied and fixed by the context in which the CS value occurs. Due to it's highly restricted functionality, CS can only be used for simple structural attributes with highly controlled and stable value sets.

Attributes

code : String: The plain code symbol defined by the code system. if the code value is empty or null, then there is no code in the code system that represents the concept.

Invariants

OCL for invariants:

 -- nullFlavor invariants
 inv "no code if null": isNull implies code.oclIsUndefined

Identification Data Types

These datatypes provide support for various identifiers and URIs.

Iso datatypes misc.gif



II (Instance Identifier)

Specializes ANY

Definition: An identifier that uniquely identifies a thing or object. Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, Vehicle Identification Number (VIN), etc. Instance identifiers are defined based on ISO object identifiers.

Attributes

root : Uid: A unique identifier that guarantees the global uniqueness of the instance identifier. The root alone may be the entire instance identifier. In the presence of a non-null extension, the root is commonly interpreted as the "issuing authority", that is, it is supposed that the root somehow refers to an organization that assigns identifiers sent in the extension. However, the root does not have to be an organizational UID, it can also be a UID specifically registered for an identifier scheme. This field can be either a UUID, an OID, or a special identifier taken from lists that may be published by ISO or HL7.

Note: The root should not be supposed to carry semantic meaning – all it does is ensure global computational uniqueness.

extension: String: A character string as a unique identifier within the scope of the identifier root. The root and extension scheme effectively means that the concatenation of root and extension must be a globally unique identifier for the item that this II value identifies.

assigningAuthorityName : String: A human readable name or mnemonic for the assigning authority. The Assigning Authority Name has no computational value. The purpose of a Assigning Authority Name is to assist an unaided human interpreter of an II value to interpret the authority. Note: no automated processing must depend on the assigning authority name to be present in any form

displayable : Boolean: Specifies if the identifier is intended for human display and data entry (displayable = true) as opposed to pure machine interoperation (displayable = false).

use : Set(IdentifierUse): Specifies the intent of the scope or use of this II

type: IdentifierType: Specifies the type of the identifier. The type has no computational value. The purpose of a type is to assist an unaided human interpreter of an II value to interpret the authority. Note: no automated processing must depend on the type to be present in any form


Invariants

  • A root must be present if the II is not null

OCL Invariants:

 inv "root is required": notNull implies root.oclIsDefined
 -- nullFlavor invariants
 inv "no root if null": isNull implies root.oclIsUndefined
 inv "no extension if null": isNull implies extension.oclIsUndefined
 inv "no assigningAuthorityName if null": isNull implies assigningAuthorityName.oclIsUndefined
 inv "no displayable if null": isNull implies displayable.oclIsUndefined
 inv "no use if null": isNull implies use->size= 0
 inv "no type if null": isNull implies type.oclIsUndefined


URI

Specializes ANY

Definition: Defines a resource that is identified by a URI, and introduces the notion that the resource may have a limited availability.

Attributes

details : Uri: A telecommunications address specified according to Internet standard RFC 2396 [[2]]. The URI specifies the protocol and the contact point defined by that protocol for the resource. Notable uses of the telecommunication address data type are for telephone and telefax numbers, e-mail addresses, Hypertext references, FTP references, etc.

useablePeriod: GTS: Specifies the periods of time during which the telecommunication address can be used. For a telephone number, this can indicate the time of day in which the party can be reached on that telephone. For a web address, it may specify a time range in which the web content is promised to be available under the given address.

Invariants

OCL for Invariants:

 inv "no updateMode or History": (useablePeriod.oclIsUndefined or useablePeriod.noUpdateOrHistory)
 -- nullflavor invariants:
 inv "no details if null": isNull implies details.oclIsUndefined
 inv "no useablePeriod if null": isNull implies (useablePeriod.oclIsUndefined or useablePeriod.isNull)


TEL (Telecommunication Address)

Specializes URI

Definition: A telephone number (voice or fax), e-mail address, or other locator for a resource mediated by telecommunication equipment. The address is specified as a Universal Resource Locator (URL) qualified by time specification and use codes that help in deciding which address to use for a given time and purpose.

Attributes

use : Set(TelecommunicationAddressUse): One or more codes advising system or user which telecommunication address in a set of like addresses to select for a given telecommunication need. The telecommunication use code is not a complete classification for equipment types or locations. Its main purpose is to suggest or discourage the use of a particular telecommunication address. There are no easily defined rules that govern the selection of a telecommunication address.

Invariants

OCL for Invariants:

 -- nullflavor invariants:
 inv "no use if null": isNull implies use->size = 0


Name and Address Data Types

These datatypes provide support for various identifiers and URIs.

Iso datatypes names.gif


ADXP (Address Part)

Specializes ST

Definition: A character string that may have a type-tag signifying its role in the address. Typical parts that exist in about every address are street, house number, or post box, postal code, city, country but other roles may be defined regionally, nationally, or on an enterprise level (e.g. in military addresses). Addresses are usually broken up into lines, which may be indicated by special line-breaking delimiter elements (e.g., DEL).

Attributes

type : AddressPartType: Specifies whether an address part names the street, city, country, postal code, post box, etc. If the type is NULL the address part is unclassified and would simply appear on an address label as is

Invariants

OCL for Invariants:

 -- nullflavor invariants:
 inv "no type if null": isNull implies type.oclIsUndefined
 inv "no updateMode or History": noUpdateOrHistory


AD (Address)

Specializes ANY

Definition: Mailing and home or office addresses. AD is primarily used to communicate data that will allow printing mail labels, or that will allow a person to physically visit that address. The postal address data type is not supposed to be a container for additional information that might be useful for finding geographic locations (e.g., GPS coordinates) or for performing epidemiological studies. Such additional information should be captured by other, more appropriate data structures.

Attributes


part : Sequence(ADXP): A sequence of address parts, such as street or post office Box, city, postal code, country, etc

use : Set(PostalAddressUse): A set of codes advising a system or user which address in a set of like addresses to select for a given purpose. An address without specific use code might be a default address useful for any purpose, but an address with a specific use code would be preferred for that respective purpose.

useablePeriod : GTS: A General Timing Specification (GTS) specifying the periods of time during which the address can be used. This is used to specify different addresses for different times of the week or year

isNotOrdered : Boolean: A boolean value specifying whether the order of the address parts is known or not. While the address parts are always a Sequence, the order in which they are presented may or may not be known. Where this matters, the isNotOrdered property can be used to convey this information.

Invariants

  • Either the AD is null or it has at least one part

OCL for Invariants:

 inv "null or parts": isNull xor part->size = 0
 -- nullflavor invariants:
 inv "no use if null": isNull implies use->size = 0 -- is this true?
 inv "no useablePeriod if null": isNull implies (useablePeriod.oclIsUndefined or useablePeriod.isNull)
 inv "no updateMode or History": (useablePeriod.oclIsUndefined or useablePeriod.noUpdateOrHistory)


ENXP (Entity Name Part)

Specializes ST

Definition: A character string token representing a part of a name. May have a type code signifying the role of the part in the whole entity name, and qualifier codes for more detail about the name part type. Typical name parts for person names are given names, and family names, titles, etc.

Attributes

type : EntityNamePartType: Indicates whether the name part is a given name, family name, prefix, suffix, etc. Not every name part must have a type code, if the type code is unknown, not applicable, or simply undefined this is expressed by a NULL value (type.isNull). For example, a name may be "Rogan Sulma" and it may not be clear which one is a given name or which is a last name, or whether Rogan may be a title

qualifier : Set(EntityNamePartQualifier): The qualifier is a set of codes each of which specifies a certain subcategory of the name part in addition to the main name part type. For example, a given name may be flagged as a nickname, a family name may be a pseudonym or a name of public records.

Invariants

OCL for Invariants:

 -- nullflavor invariants:
 inv "no qualifier if null": isNull implies qualifier->size = 0
 inv "no updateMode or History": noUpdateOrHistory


EN (Entity Name)

Specializes ANY

Definition: A name for a person, organization, place or thing. Examples for entity name values are "Jim Bob Walton, Jr.", "Health Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple as a character string or may consist of several entity name parts, such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and "Inc.",

Attributes

part : Sequence(ENXP): A sequence of name parts, such as given name or family name, prefix, suffix, etc.

use : Set(EntityNameUse): A set of codes advising a system or user which name in a set of names to select for a given purpose. A name without specific use code might be a default name useful for any purpose, but a name with a specific use code would be preferred for that respective purpose.

validTime : IVL(TS): An interval of time specifying the time during which the name is or was used for the entity. This accomodates the fact that people change names for people, places and things.

Invariants

  • Either the EN is null or it has at least one part

OCL for Invariants:

 inv "null or parts": isNull xor part->size = 0
 -- nullflavor invariants:
 inv "no use if null": isNull implies use->size = 0 -- is this true?
 inv "no validTime if null": isNull implies (validTime.oclIsUndefined )-- or validTime.isNull)
 inv "no updateMode or History": (validTime.oclIsUndefined or validTime.noUpdateOrHistory)


TN (Trivial Name)

Specializes EN

Definition: A restriction of entity name that is effectively a simple string used for a simple name for things and places. Trivial names are typically used for places and things, such as Lake Erie or Washington-Reagan National Airport.

Invariants

  • If the TN is not null, there can only be one part, and it can have no name

OCL for Invariants:

 inv "only one part with no type": isNotNull implies (part->size = 1 and part->first.type.oclIsUndefined)

PN (Person Name)

Specializes EN

Definition: An EN used when the named Entity is a Person. A sequence of name parts, such as given name or family name, prefix, suffix, etc. A name part is a restriction on entity name part that only allows those entity name parts qualifiers applicable to person names. Since the structure of entity name is mostly determined by the requirements of person name, the restriction is very minor.

Invariants

  • None of the parts of a persons name can be qualified by the status LS

OCL for Invariants:

 inv "no parts are qualified by LS": part->forAll(p | not p.qualifier->includes(EntityNamePartQualifier.LS))

ON (Organization Name)

Specializes EN

Definition: An EN used when the named Entity is an Organization.

Invariants

  • None of the parts of a organisation name can be FAM or GIV

OCL for Invariants:

 inv "no parts are person types": part->forAll(p | not (p.type = EntityNamePartType.FAM or p.type = EntityNamePartType.GIV))


Quantity Data Types

These datatypes provide support for Quantitative values.

Iso datatypes qty.gif


QTY (Quantity)

Specializes ANY

Definition: The quantity data type is an abstract generalization for all data types whose value set has an order relation (less-or-equal) and where difference is defined in all of the data type’s totally ordered value subsets. The quantity type abstraction is needed in defining certain other types, such as the interval and the probability distribution.

Note that QTY is an abstract type, but is not declared as an abstract type here because of the way that many of the following types are declared.


INT (Integer)

Specializes QTY

Definition: Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers.

Attributes

value : Integer: The value of the INT if not null. Note that this specification imposes no limitations on the size of integer, but most implementations will map this to a 32 bit integer.

Invariants

  • a value must be provided if not null

OCL for Invariants:

 inv "null or value": isNull xor value.oclIsDefined


REAL (Real)

Specializes QTY

Definition: Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision.

Attributes

value : Real: The value of the REAL if non Null. Real is the UML Kernel Real type. Note that the abstract specification imposes no limitations on the size or precision of REAL, but most implementations will map this to a 8 byte Real.

precision : Integer: The number of significant digits of the decimal representation. 0 (default value) means nothing is known about the precision

Invariants

  • a value must be provided if not null

OCL for Invariants:

 inv "null or value": isNull xor value.oclIsDefined
 -- nullFlavor invariants
 inv "no precision if null": isNull implies precision.oclIsUndefined


RTO (Ratio)

Specializes QTY

Note: (does it need to? Why do we care in the ITS? We would only care if there was an attribute with type QTY. I\’ve never seen one. Can we specialise any not qty? This was intended to allow QTY to have extra data types, but it\’s not clear that this is useful anymore)

Definition: A quantity constructed as the quotient of a numerator quantity divided by a denominator quantity. Common factors in the numerator and denominator are not automatically cancelled out. The RTO data type supports titers (e.g., "1:128") and other quantities produced by laboratories that truly represent ratios. Ratios are not simply "structured numerics", particularly blood pressure measurements (e.g. "120/60") are not ratios.

Note: Ratios are different from rational numbers, i.e., in ratios common factors in the numerator and denominator never cancel out. A ratio of two real or integer numbers is not automatically reduced to a real number. This data type is not defined to generally represent rational numbers. It is used only if common factors in numerator and denominator are not supposed to cancel out. This is only rarely the case. For observation values, ratios occur almost exclusively with titers. In most other cases, REAL should be used instead of the RTO.

Note: Since many implementation technologies expect generics to be collections, or only have one parameter, RTO is not implemented as a generic in this specification. Constraints at the point where the RTO is used will define which form of QTY are used

Attributes

numerator : QTY: The quantity that is being divided in the ratio.

denominator : QTY: The quantity that divides the numerator in the ratio. The denominator must not be zero.

Invariants

  • If the RTO is not null, both a numerator and a denominator are required

OCL for Invariants:

 inv "numerator and and denominator required": isNull xor ( (numerator.oclIsDefined and numerator.isNotNull)
      and (denominator.oclIsDefined and denominator.isNotNull) )
 inv "no updateMode or History": (numerator.oclIsUndefined or numerator.noUpdateOrHistory) and
      (denominator.oclIsUndefined or denominator.noUpdateOrHistory)


PQ (Physical Quantity)

Specializes QTY

Definition: A dimensioned quantity expressing the result of measuring.

Attributes

value : Real: The value of the PQ if non Null. Note that this specification imposes no limitations on the size or precision of REAL, but most implementations will map this to a 8 byte Real

precision : Integer: The number of significant digits of the decimal representation. 0 (default value) means nothing is known about the precision

unit : Code: The unit of measure specified in the Unified Code for Units of Measure (UCUM) [[3]. Equality of physical quantities does not require the values and units to be equal independently. Value and unit is only how we represent physical quantities. For example, 1 m equals 100 cm. Although the units are different and the values are different, the physical quantities are equal. Therefore one should never expect a particular unit for a physical quantity but instead allow for automated conversion between different comparable units.

translation : Set(PQR): An alternative representation of the same physical quantity expressed in a different unit, of a different unit code system and possibly with a different value.

specialValue: SpecialPhysicalQuantity': Alternative special value for physical quantities that have no literal value.

Invariants

  • If the PQ is not null, a value must be present
  • If a value is present, units must be present

OCL for Invariants:

 def: let hasValue : Boolean = value.oclIsDefined or specialValue.oclIsDefined
 inv "value or specialValue": value.oclIsDefined xor specialValue.oclIsDefined
 inv "null or value": isNull xor hasValue
 inv "units required": value.oclIsDefined implies units.oclIsDefined -- do not need to have units if a special value is provided
 -- nullFlavor invariants
 inv "no precision if null": isNull implies precision.oclIsUndefined
 inv "no translation if null": isNull implies translation->size = 0 -- ?


PQR (Physical Quantity Representation)

Specializes CV

Definition: An extension of the coded value data type representing a physical quantity using a unit from any code system. Used to show alternative representation for a physical quantity. The coded value represents the unit (usually in some other coding system than UCUM)

Attributes

value : REAL: The value of the PQ if non Null

precision : Integer: The number of significant digits of the decimal representation. 0 (default value) means nothing is known about the precision

Invariants

  • If the PQR is not null, a value must be present and not null

OCL for Invariants:

 inv "null or value": isNull xor value.oclIsDefined
 -- nullFlavor invariants
 inv "no updateMode or History": noUpdateOrHistory
 inv "no precision if null": isNull implies precision.oclIsUndefined


MO (Monetary Amount)

Specializes QTY

Definition: An MO is a quantity expressing the amount of money in some currency. Currencies are the units in which monetary amounts are denominated in different economic regions. While the monetary amount is a single kind of quantity (money) the exchange rates between the different units are variable. This is the principle difference between PQ and MO, and the reason why currency units are not physical units

Attributes

value : Real The value of the MO if non Null. MO values are usually precise to 0.01 (one cent, penny, paisa, etc.) For large amounts, it is important not to store MO values in floating point registers, since this may lose precision.

currency : Code: The currency unit as defined in ISO 4217.

Invariants

  • If not null, a value must be present
  • If not null, a currency must be defined

OCL for Invariants:

 inv "null or value": isNull xor value.oclIsDefined
 inv "null or currency": isNull xor currency.oclIsDefined


TS (Point in Time)

Specializes QTY

Definition: A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression

Attributes

value : String: The value of the TS if non Null. value is an ISO 8601 String, to the degree of precision that is appropriate.

Invariants

  • If the TS is not null, a value must be present

OCL for Invariants:

 inv "null or value": isNull xor value.oclIsDefined

Collection Data Types

These datatypes provide support for collections of data.

Iso datatypes collections.gif


SET (Set)

Specializes ANY

Parameter: T : ANY

Definition: A collection that contains other distinct values in no particular order

Attributes

item : Set(T): The contents of the Set.

Invariants

  • If the SET is null, no items can be contained in the Set. If the SET is not null, at least one item must be present

OCL for Invariants:

 inv "null or not empty": isNull xor item->size > 0


LIST (Sequence)

Specializes ANY

Parameter: T : ANY

Definition: A collection that contains other discrete (but not necessarily distinct) values in a defined sequence


Attributes

item : Sequence(T): The contents of the Sequence

Invariants


OCL for Invariants:

 inv "null or not empty": isNull implies item->size = 0

GLIST (Generated Sequence)

Specializes ANY

Parameter: T : QTY

Definition: A periodic or monotone sequence of values generated from a few parameters, rather than being enumerated. Used to specify regular sampling points for biosignals

Attributes

head : T: The first item in this sequence. The head is a definitional property for the semantics of the sequence

increment : QTY: The difference between one value and its previous different value. For example, to generate the sequence (1; 4; 7; 10; 13; ...) the increment is 3; likewise to generate the sequence (1; 1; 4; 4; 7; 7; 10; 10; 13; 13; ...) the increment is also 3. The actual type QTY will be dictated by the type of T

denominator : Integer: The integer by which the index for the sequence is divided, effectively the number of times the sequence generates the same sequence item value before incrementing to the next sequence item value. For example, to generate the sequence (1; 1; 1; 2; 2; 2; 3; 3; 3; ...) the denominator is 3.

period : Integer: If non-NULL, specifies that the sequence alternates, i.e., after this many increments, the sequence item values roll over to start from the initial sequence item value. For example, the sequence (1; 2; 3; 1; 2; 3; 1; 2; 3; ...) has period 3; also the sequence (1; 1; 2; 2; 3; 3; 1; 1; 2; 2; 3; 3; ...) has period 3 too.

Invariants

  • If the GLIST is not null, all attributes but the period are required

OCL for Invariants:

 inv "required attributes": isNull xor (head.oclIsDefined and head.isNotNull and
      increment.oclIsDefined and increment.isNotNull and denominator.oclIsDefined)
 inv "no updateMode or History": (head.oclIsUndefined or head.noUpdateOrHistory)
      and (increment.oclIsUndefined or increment.noUpdateOrHistory)


SLIST (Sampled Sequence)

Specializes ANY

Parameter: T : QTY

Definition: A sequence of sampled values scaled and translated from a list of integer values. Used to specify sampled biosignals.

Attributes

Origin : T: The origin of the list item value scale. The physical quantity that a zero-digit in the sequence would represent

Scale : QTY: A ratio-scale quantity that is factored out of the digit sequence. For example, to generate the sequence (1; 4; 7; 10; 13; ...) the increment is 3; likewise to generate the sequence (1; 1; 4; 4; 7; 7; 10; 10; 13; 13; ...) the increment is also 3. The actual type QTY will be dictated by the type of T

Digits : Sequence(INT): A sequence of raw digits for the sample values. This is typically the raw output of an A/D converter. May be null.

Invariants

  • If the SLIST is not null, an origin and at least one digit is required

OCL for Invariants:

 inv "required attributes": isNull xor (origin.oclIsDefined and origin.isNotNull
      and digits->size > 0) -- digits > 0 or null? scale can be null
 inv "no updateMode or History": (origin.oclIsUndefined or origin.noUpdateOrHistory)
      and (scale.oclIsUndefined or scale.noUpdateOrHistory)
      and digits->forAll(d | d.noUpdateOrHistory)


BAG (Bag)

Specializes ANY

Parameter: T : ANY

Definition: An unordered collection of values, where each value can be contained more than once in the collection


Attributes

item : Bag(T): The contents of the Bag.

Invariants

  • If the BAG is null, no items can be contained in the Set. If the BAG is not null, at least one item must be present

OCL for Invariants:

 inv "null or not empty": isNull xor item->size > 0
 -- rules about updateMode or history are applied to item where BAG(T) is used


IVL (Interval)

Specializes ANY

Parameter: T : QTY

Definition: A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an IVL; it does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the IVL must be elements of a totally ordered subset of the partially ordered data type.

Attributes

low : T: This is the low limit

lowClosed : Boolean: Specifies whether low is included in the IVL (is closed) or excluded from the IVL (is open).

lowUnbounded : Boolean: There is no lower limit

high : T: This is the high limit

highClosed : Boolean: Specifies whether high is included in the IVL (is closed) or excluded from the IVL (is open).

highUnbounded : Boolean: There is no upper limit

width : QTY: The difference between high and low boundary. Width is used when the size of the Interval is known, but the actual start and end points are not known.

Invariants

  • Either the IVL is null, has a width, or has (low and/or high). Width and (low and/or high) cannot be mixed
  • lowClosed and highClosed can only be used if low or high are used

OCL for Invariants:

 -- you can have either width or (low and/or high)
 -- you can only have the closed flags if you don't have width. (not sure about this)
 def: let hasWidth : Boolean = width.oclIsDefined and width.isNotNull
 def: let hasLow : Boolean = (low.oclIsDefined and low.isNotNull) or lowUnbounded
 def: let hasHigh : Boolean = (high.oclIsDefined and high.isNotNull) or highUnbounded
 def: let hasBounds : Boolean = hasLow or hasHigh
 inv "required attributes": isNull xor (hasBounds xor hasWidth)
 inv "closed attributes only if not width": (not hasLow implies lowClosed.oclIsUndefined)
      and (not hasHigh implies highClosed.oclIsUndefined)
 inv "no updateMode or History": (low.oclIsUndefined or low.noUpdateOrHistory)
      and (high.oclIsUndefined or high.noUpdateOrHistory) and (width.oclIsUndefined
      or width.noUpdateOrHistory)
 inv "unbounded means no value (low)": lowUnbounded implies low.oclIsUndefined
 inv "unbounded means no value (high)": highUnbounded implies high.oclIsUndefined


Timing Specification Data Types

These datatypes provide support for collections of data.

Iso datatypes timing.gif


PIVL (PeriodicInterval)

Specializes ANY

Definition: An interval of time that recurs periodically. PIVL has two properties, phase and period. phase specifies the "interval prototype" that is repeated every .

Attributes

phase : TS: A prototype of the repeating interval, specifying the duration of each occurrence and anchors the PIVL sequence at a certain point in time. phase also marks the anchor point in time for the entire series of periodically recurring intervals. The recurrence of a PIVL has no beginning or ending, but is infinite in both future and past.

period : PQ: A time duration specifying as a reciprocal measure of thefrequency at which the PIVL repeats

alignment : CalendarCycle: Specifies if and how the repetitions are aligned to the cycles of the underlying calendar (e.g., to distinguish every 30 days from "the 5th of every month".) A non-aligned PIVL recurs independently from the calendar. An aligned PIVL is synchronized with the calendar.

institutionSpecified : Boolean: Indicates whether the exact timing is up to the party executing the schedule e.g., to distinguish "every 8 hours" from "3 times a day".

Invariants

  • If PIVL is not null, phase and period must be specified

OCL for invariants:

 inv "required attributes": isNotNull implies (phase.oclIsDefined and phase.isNotNull
      and period.oclIsDefined and period.isNotNull)
 inv "no updateMode or History": (phase.oclIsUndefined or phase.noUpdateOrHistory)
      and (period.oclIsUndefined or period.noUpdateOrHistory)


EIVL (Event-Related Periodic Interval of Time)

Specializes ANY

Definition: Specifies a periodic interval of time where the recurrence is based on activities of daily living or other important events that are time-related but not fully determined by time. For example, "one hour after breakfast" specifies the beginning of the interval at one hour after breakfast is finished. Breakfast is assumed to occur before lunch but is not determined to occur at any specific time.

Attributes

event : TimingEvent: A code for a common (periodical) activity of daily living based on which the event related periodic interval is specified. Such events qualify for being adopted in the domain of this attribute for which all of the following is true:

  • the event commonly occurs on a regular basis
  • the event is being used for timing activities, and
  • the event is not entirely determined by time||N/A

offset : IVL(TS): An interval of elapsed time (duration, not absolute point in time) that marks the offsets for the beginning, width and end of the EIVL measured from the time each such event actually occurred. For example: if the specification is "one hour before breakfast for 10 minutes" IVL.low of offset is 1 h and the IVL.width of offset is 10 min.

Invariants

  • If EIVL is not null, event must be specified

OCL for invariants:

 inv "required attributes": isNotNull implies (event.oclIsDefined)
 inv "no updateMode or History": (offset.oclIsUndefined or offset.noUpdateOrHistory)

GTS (General Timing Specification)

Specializes ANY

Definition: Specifies the timing of events and actions and the cyclical validity-patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing closer to the equator during winter and farther from the equator during summer) and office hours


'Attributes

literal : String: A literal representation of the GTS. Can be used instead of the structural alternatives offered by item, event and period. Literal cannot be used at the same time as item, period or event.

item : Sequence(IVL(TS)): A sequence of IVL<TS>

period : Sequence(PIVL): A sequence of periodic intervals

event : Sequence(EIVL): A sequence of event related intervals


Invariants

  • If GTS is not null, either a literal must be provided, or else some values must be found in item, period or event.
 def: let hasStructuredContent : Boolean = item->size > 0 or period->size > 0 or event->size > 0
 inv "required attributes": isNotNull xor (literal.oclIsDefined xor hasStructuredContent)
 inv "no updateMode or History": item->forAll(i | i.noUpdateOrHistory) and
      period->forAll(p | p.noUpdateOrHistory) and event->forAll(e | e.noUpdateOrHistory)