Data Types - Abstract Specification

HL7 Version 3 Standard, Copyright Health Level Seven, Inc.© 2002. All Rights Reserved.

This document specifys the HL7 Version 3 Data Types on an abstract layer, independent of representation. By "independent of representation" we mean independent of both abstract syntax as well as implementation in any particular implementation technology.

This document is accompanied by Implementation Technology Specifications (ITS). The ITS documents can serve as a quick compendium to the data types that is more practically oriented toward the representation in that particular implementation technology.

Vocabulary tables within this specification list the current contents of vocabulary domains for ease of reference by the reader. However, at any given time the normative source for these domains is the vocabulary tables in the RIM database. For some large domains, only a sample of possible values is shown. The complete domains can be referenced in the vocabulary tables by looking up the domain name associated with the table in the RIM vocabulary tables.

In the previous ballots of the v3 data types documents there were two ITS-independent specification, called "Part-1" and "Part-2". Since a completely representation-independent data type specification is abstract, Part-1 was supposed to provide an easier read. However, it was also more shallow and at times not correct. Part-1 gave the wrong impression as if HL7 version 3 data types were defined as an abstract syntax which is an incorrect assumptions. For that reason the specification has again been restructured.

The ITS documents now assume the function of a "practical" exposition of this material that is fairly concise and easy to read for those readers who know the respective implementation technology. The ITS documents quote the abstract specification on its concise definitions and possibly on tutorial material (that has been merged back from Part-1 into this abstract specification.)

During the last two ballots, the editorial process of these document has been largely automated to minimize duplication of text and formalize the specification shuch that technical changes to the material can be implemented much more quickly and consistently. The work on document restructuring both regarding document production (i.e., moving from Word processor documents to XML, that was initiated by the HL7 publication committee several ballot cycles ago) as well as the various attempts at restructuring this material, imposed a lot of editorial burden on the editors. We believe that the result to date is a great improvement as future technical ballot comments can be more safely, consistently and easily accomodated.

On the other hand, this editorial work dominated much of the contnet work for the last two ballot preparations. The reader may remember that during the previous ballot the abstract data type specification was added without any changes (neither editorial nor content changes) because all the available resources had been spent on the ITS for XML. During this ballot preparation the abstract specification has been updated regarding the editorial process improvements, but only very few essential content modification had been applied.

The editors therefore want to apologize to all those readers who had previously submitted technical ballot comments that had been agreed to during the reconciliation, as many of those suggestions and agreements are still not reflected in this ballot draft. We would ask the readers to please resubmit their understanding of the prior resolutions to their comments -- however informal this may be -- into their ballot. We understand that a formal resubmission of comments places an extra burden, which is why we will greatly appreciate notes about previous reconciliation agreements submitted as informal material (this would even include handwritten notes that can be sumbitted by FAX to +1-317-630-6962 attn: Gunther Schadow/V3DT.)

This standard is the result of several years of intense work through e-mail, telephone conferences and meeting discussions. Gunther Schadow (Regenstrief Institute for Health Care) chaired this task force, and is the main author of this document. Major contributions are from Mark Tucker (Regenstrief Institute), Paul V. Biron (Kaiser Permanente), Lloyd McKenzie (IBM), George Beeler, and Stan Huff (Intermountain Health Care), as well as Mike Henderson (Kaiser Permanente), Anthony Julian (Mayo), Joann Larson (Kaiser Permanente), Mark Shafarman (Oacis Healthcare Systems), Wes Rishel (Gartner Group), and Robin Zimmerman (Kaiser Permanente). Acknowledgements for their critical review and infusion of ideas go to Bob Dolin (Kaiser Permanente), Clem McDonald (Regenstrief Institute), Kai Heitmann (HL7 Germany), Rob Seliger (Sentillion), and Harold Solbrig (Mayo Clinic). Vital support came from the members of the task force, Laticia Fitzpatrick (Kaiser Permanente), Matt Huges, Randy Marbach (Kaiser Permanente), Larry Reis (Wizdom Systems), Carlos Sanroman (Kaiser Permanente), Greg Thomas (Kaiser Permanente). Thanks James Case (University of California, Davis), Norman Daoust (Partners HealthCare Systems), Irma Jongeneel (HL7 The Netherlands), Michio Kimura (HL7 Japan), John Molina (SMS), Richard Ohlmann (McKessonHBOC), David Rowed (HL7 Australia), and Klaus Veil (Macquarie Health Corp., HL7 Australia), for sharing their expertise in critical questions. This work was made possible by the Regenstrief Institute for Health Care.

Table of contents

Appendices

Every data element has a data type. Data types define the meaning (semantics) of data values that can be assigned to a data element. Meaningful exchange of data requires that we know the definition of values so exchanged. This is true for complex "values" such as business messages as well as for simpler values such as character strings or integer numbers.

According to ISO 11404, a data type is "a set of distinct values, charac terized by properties of those values and by operations on those values." A data type has intension and extension. Intentionally, the data type defines the properties exposed by every data value of that type. Extensionally, data types have a set of data values that are of that type (the type's "value set").

Semantic properties of data types are what ISO 11404 calls "properties of those values and [...] operations on those values." A semantic property of a data type is referred to by a name and has a value for each data value. The value of a data value's property must itself be a value defined by a data type - no data value exists that would not be defined by a data type.

Data types are thus the basic building blocks used to construct any higher order meaning: messages, computerized patient record documents, or business objects and their transactions. What, then, is the difference between a data type and a message, document, or business object? Data type values stand for themselves, the value is all that counts, neither identity nor state or changing of state is defined for a data value. Conversely in business objects, we track state and identity; the properties of an identical object might change between now and later. Not so with data values: a data value and its properties are constant. For example, number 5 is always number 5, there is no difference between this number 5 and that number 5 (no identity distinguished from value), number 5 never changes to number 6 (no change of state). One can think of data values as immutable objects where identity does not matter (identity and equality are the same.)¹

Data values can be represented through various symbols but the data value's meaning is not bound to any particular representation.

For example, cardinal numbers (non-negative integers) are defined - intentionally - as a data type where each value has a successor value, where zero is the successor of no other cardinal value. Based on this definition we can define addition, multiplication, and other mathematical operations. Whatever representation reflects the rules we stated in the intentional definition of the cardinal data type is a valid representation of cardinal numbers. Examples for valid cardinal number representations are decimal digit strings, bags of glass marbles, or scratches on a wall. The number two is represented by the word "five" by the Arabic number "5" or the Roman number "V". The representation does not matter as long as it conforms to the semantic definition of the data type.

Another example, the Boolean data type is defined by its extension, the two distinct values true and false and the rules of negation and combining these values in conjunction and disjunction. The representation of Boolean values can be the words "true" and "false," "yes" and "no," the numbers 0 and 1, any two signs that are distinct from each other. The representation of data types does not matter as long as it conforms to the semantic definition of the data type.

This specification defines the semantics, the meaning of the HL7 data types. This specification is about semantics only, independent from representational and operational concerns or specific implementation technologies. Additional standards for representing the data values defined here are being defined for various technological approaches. These standards are called "Implementable Technology Specification" (ITS.) Those ITS define how values are represented so that they conform to the semantic definitions of this specifications, this may include syntaxes for character or binary representations, and computer procedures to act on the representation of data values. The meaning of these ITS representations communicated, generated, and processed in computer programs, is defined based on this standard, the semantic data type specification.

Data values have properties defined by their data type. The "fields" of "composite data types" are the most common example of such properties. However, more generally one should think of a data value's property as logical predicates or as mathematical functions; in simpler but still correct terms, properties are questions one can ask about a data value to receive another data value as an answer.

A property is referred to by its name. For example, the data type integer may have a property named "sign." A property has a domain, which is the set of possible "answer" values. The set of possible "answer" values is defined by the property's data type, but the domain of a property may be a subset of the data type's value set.

A property may also have arguments, additional information one must supply with a question to get an answer. For example, an important property of an integer number is that one integer plus another integer results in another integer, so the plus property of one integer needs an argument: the other integer.

Whether semantic properties have arguments is not a fundamentally relevant distinction. A data type's semantic property without arguments is not necessarily a "field" of a "composite" data type. For example, for integer values, we can define the property is-zero that has the Boolean value true when the number is zero and false when the number is not zero. This does not mean that is-zero must be an explicit component of any integer representation.

A data type's semantic property with arguments has no specific operational notions such as "procedure call," "passing arguments," "return values," "throwing exceptions," etc. These are all concepts of computer systems implementation of data types - but these operational notions are irrelevant for the semantics of data types.

This specification is about semantics of data types only. Neither is it about value representation syntax (not even an abstract syntax), nor is it about an operational interface to the data values.

Why does this specification make such a big issue about its being abstract from representation syntax as well as operational implementation?

HL7 needs this kind of abstract semantic data type specification for a very practical purpose. One important design feature of HL7 version 3 is its openness towards representation and implementation technologies. All HL7 version 3 specifications are supposed to be done in a form independent from specific representation and implementation technologies. HL7 acknowledges that, while at times some representation and implementation technologies may be more popular than others, technology is going to change - and with changing technology, representations of data values will change. HL7 standards are primarily targeted to healthcare domain information, independent from the technology supporting this information. HL7 expects that specifications defined independent from today's technology will continue to be useful, even after the next technological "paradigm shift".

The issue of data types is closer to implementation technology than most other HL7 information standards - and therein lays a certain danger that we define data types too dependent on current implementation technologies.

The majority of HL7 standards are about complex business objects. Complex business objects with many informational attributes can be specified as abstract syntax, where components are eventually defined in terms of data types. Conversely, defining data types in terms of abstract syntax is of little use because the components of such abstract syntax constructs would still have to have data types.²

Why doesn't this specification define a set of primitive data types based on which composite data types could be defined simply as abstract syntax?

Any concrete implementation of the HL7 standards must ultimately use the built-in data types of their implementation technology. Therefore, we need a very flexible mapping between HL7 abstract data types and those data types built into any specific implementation technology. With a semantic specification, an Implementable Technology Specification (ITS) can conform simply by stating a mapping between the constructs of its technology and the HL7 version 3 data type semantics. Whether a data type is primitive of composite is irrelevant from a semantic perspective, and the answer may be different for different implementation technologies.

For example, this standard specifies a character string as a data type with many properties (e.g., charset, language, etc.) However, in many Implementation Technologies, character strings are primitive first class data types. We encourage that these native data types be used rather than a structure that slavishly represents all the semantic properties as "components." This specification only requires that the properties defined for data values can somehow be inferred from whatever representation is chosen, it does not matter how these values are represented. Whether "primitive" or "composite", with few or many "components", as "fields" or "methods" - this is all irrelevant.

For another example, a decimal representation, a floating-point register and a scaled integer are all possible native representations of real numbers for different implementation technologies. Some of these representations have properties that others do not have. Scaled integers, for instance, have a fixed precision and a relatively small range. Floating-point values have variable precision and a large range, but floating-point values lose any information about precision. Decimal representations are of variable precision and maintain the precision information (yet are slow to processing.) The data type semantics must be independent from all these accidental properties of the various representations, and must define the essential properties that any technology should be able to represent.

Why does HL7 need its own data type standard? Why can't HL7 simply adopt a standard defined by some other body?

As noted in the previous section, all HL7 implementation technologies have some data type system, but there are differences among the data type systems between implementation technologies. In addition, many implementation technologies' data type systems are not powerful enough to express the concepts that matter for the HL7 application layer.

For example, few implementation technologies provide the concepts of physical quantities, precision, ranges, missing information, and uncertainty that are so relevant in scientific and health care computing.

On the other hand, implementation technologies do make distinctions that are not relevant from the abstract semantics viewpoint, e.g., fixed point vs. floating-point real numbers; 8, 16, 32, or 64-bit integers; date vs. timestamp.

A number of data type systems have been used as input to this specification. These include the type systems of many major programming languages, including BASIC, Pascal, MODULA-2, C, C++, JAVA, ADA, LISP and SCHEME. This also includes type systems of language-independent implementation technologies, such as Abstract Syntax Notation One (ASN.1), Object Management Group's (OMG) Interface Definition Language (IDL) and Object Constraint Language (OCL), SQL 92 and SQL 99, the ISO 11404 language independent data types, and XML Schema Part 2 data types. Health care standards related data types have been considered as well, among these HL7 version 2.x, types used by CEN TC 251 messages and Electronic Health Record Architecture (EHCRA) and DICOM.

This specification defines data types in several forms, using textual description, UML diagrams, tables, and a formal definition.

A formal definition of data types is used in order to clarify the semantics of the proposed types as unambiguously as possible. This data type definition language is described in detail in Section 1.3. Formal languages make crisp essential statement and are therefore accessible to some formal argument of proof or rebuttal. However, the terseness of such formal statements may also be difficult to understand by humans. Therefore, all the important inferences from the formal statements are also included as plain English statements.

For a quick overview at the beginning of many data types this specification contains tables listing what is called "primary" properties. "Primary" properties are a somewhat fuzzy notion of those properties that are more likely to be thought of as "fields" when the data type where implemented as a record ("composite data type"). These tables only exist to facilitate an overview of the content and purpose of data types. While their content is part of the normative specification, the fact that a property is or is not listed in these tables has no significance. There is no requirement that the properties listed in these tables be represented as fields, and these tables are not abstract syntax definitions.

Property tables are not shown for all data types. Again, this does not mean that those data types have no properties. It also does not mean that those data types are "primitive" data types as per this specification. The property tables are used as a helpful summary only, and are not used when they would confuse more than they would help.

Each row of the property tables describes one property with the following columns:

1. Name - the name of the property as of the formal definition. For some data types, the name field of the first property may be empty. This may happen in those data types that are defined as extension of other data types and when it is not useful for the summary of the child to show any properties of the parent.



2. Type - the data type of that property.



3. Definition - a short text describing the meaning of the property.

The Unified Modeling Language (UML) is used for a graphical presentation of how data types relate. Data types are shown as UML classes. The name compartment contains the long name of the data type followed by a colon and the standard abbreviation. Properties of types without are all shown in the UML operations compartment. No instance attributes are shown, in accordance with the fact that this abstract specification is not about implementation or concrete representation. Generalization links indicate extension and restriction relationships. Aggregations are an additional representation of properties, when the relation between data types through that property is important. Generic types are shown as UML parameterized classes, with UML realization links relating their instantiations

NOTE: This is not an API specification. While this formal language might resemble some programming language or interface definition language, it is not intended to define the details of programs and other means of implementation. The formal definitions are normative part of this specification, but this particular language needs not be implemented or used in conformant systems; nor need all the semantic properties be implemented or used by conformant systems. The internal working of systems, their way to implement data types, their functionality and services is entirely out of scope of this specification. The formal definition only specifies the meaning of the data values through making statements how one would theoretically expect these values to relate and behave.

This formal data type definition language³ specifies:

• type name and short name;



• named values of a fully enumerated extension;



• semantic properties, unary, binary, and higher order properties;



• invariants, i.e. constraints over the properties.



• allowable type conversions;



• syntax of character string value literals (if any);

Definition of a data type occurs in two steps. First, the data type is declared. The declaration claims a name for a new data type with a list of names, types, and signatures of the new type's semantic properties. This declares, not defines the type. The definition occurs in both logic statements about what is always true about this type's values and their properties (invariant statements.)

Every data type is declared in a form that begins with the keyword type. For example, the following is the header of a declaration for the data type Boolean that has the short name alias BL and extends (specializes) the data type ANY.⁴

type Boolean alias BL extends ANY
    values(true, false)
{
    BL      not;
    BL      and(BL x);
};
      

The Boolean data type declaration also contains a values-clause that declares the Boolean's complete set of values (its extension) as named entities. These named values are also valid character string literals. None of the other data types defined in this specification has a finite value set, which is why the values-clause is unique to the Boolean. In the marked-up formal language, value names use Italics font.

The block in curly braces following the header contains declarations of the semantic properties that hold for every value of the data type. A semicolon terminates each property declaration; and another semicolon after the closing curly brace terminates the data type declaration.

A property declaration mentions from left to right: (1) the data type of the property's value domain, the property name, and (3) an optional argument list. The argument list of a property is enclosed in parentheses containing a sequence of argument declarations. Each argument is declared by the data type name and argument name. Semantic properties without arguments do not use an empty argument list.⁵

The extends-clause has the usual meaning of a specialization relationship known from the object-oriented method.⁶ Specialization means (a) inheritance of properties from the genus to the species, and (b) substitutability of values of the species type for variables of the genus type. In addition, however, this data type definition language specifies two variants of specialization: extension (extends) and restriction (restricts). Extension indicates that additional properties are being defined for the specialized type. Restriction indicates that the inherited properties are being constrained.

An example for inheritance is: when ANY has the property isNull and BL extends ANY then BL also has this property isNull even though isNull is not listed explicitly in the property declaration of BL. An example for substitutability is: when a property is declared as of a data type ANY and BL extends ANY then a value of such property may be of type BL. In other words, substitutability is the same as subsumption of all values of type BL being also values of type ANY.⁷

The type-declaration may be qualified by the keyword abstract and protected. An abstract type is a type where no value can be just of this type without belonging to a concrete specialization of the abstract. A protected type is a type that is used inside this specification but no property outside this specification should be declared of a protected type.⁸ (We also use the qualifier private at one point. Private types are only specified for the sake of formal definition of other types and are not used in any form outside this specification.)

The declaration of semantic properties, their names, data types, and arguments provide only clues as to what the new data type might be about. The true definition lies in the invariant statements. Invariant statements are logical statements that are true at all times.

Throughout this specification, invariant statements are provided in a formal syntax but are also written in plain English. The advantage of the formal syntax is that it can be interpreted unambiguously, and that it is strongly typed. The advantage of plain English statements is that they are more understandable, especially to those untrained in reading formal languages.

The formal syntax does help to sharpen the decisiveness of this specification. In some cases, however, the full semantics of a type are beyond what can be fully expressed in such invariant statements. The combination of both plain and formal language helps to make this specification more clear.

Invariant statements are formed using the invariant keyword that declares one or more variables in the same form as an argument list of a property. The invariant statement can contain a where clause that constrains the arguments for the entire invariant body. The invariant body is enclosed in curly braces. It contains a list of assertions that must all be true.

invariant(BL x) where x.nonNull {
    x.and(true).equals(x);
};
      

The semantics of the invariant statement is a logic predicate with a universal quantifier ("for all").

The above invariant statement can be read in English as "For all Boolean values x, where x is non-NULL it holds that x AND true equals x." All properties should be named such that one can read the assertions like English sentences.⁹

The argument list of an invariant statement need not be specified if no such argument is needed.

invariant {
    true.not.equals(false);
    false.not.equals(true);
};
      

Assertions in invariant statements are expressions built with the semantic properties of defined data types. Assertion expressions must have a Boolean value (true or false.)¹⁰ No primitive data types, or operations, pre-exist the definition of any data type. The only preexisting features of the assertion expression language are:¹¹

• character strings representing utterances in the data type definition language;



• the notion of an assertion being successful (true) or failing (false);



• the invariant statement: invariant(...) where ... {...};



• the universal quantifier expression form forall(...) where ... {...}; synonymous to the invariant statement;



• the existence quantifier expression form exists(...) where ... {...};



• the implicit conjunction (logical AND) between the semicolon-separated assertions: assertion₁; assertion₂; ... ; assertion_n;



• variables and declarations in the invariant argument list;



• the property reference using the period: x.property;



• implicit and explicit type conversion: (T)x;



• parentheses to override the priorities of the conversion and property resolution operators: (T)x.property versus((T)x).property.

Within assertion expressions, nested quantifier statements can be formed similar to invariant statements. In fact, the universal quantifier built using the forall keyword is the same as the invariant statement. The universal quantifier can be used in a nested expression when the complexity of the problem requires it, such as in the following example:

invariant(SET<T> x, y) where x.nonNull {
  x.subset(y).equals(
      forall(T element) where x.contains(element) {
        y.contains(element);
      });
};
        

The existence quantifier has the meaning as in common propositional logic. For example, the following invariant means: "SET values x and y intersect if and only if there exists an element e that is contained in both sets x and y."

invariant(SET x, y) where x.nonNull {
  x.intersects(y).equals(
      exists(T e) {
        x.contains(e);
        y.contains(e);
      });
};
        

The existence quantifier may have a where-clause; however, there is no difference whether an assertion is made as a where-clause or in the body of the existence quantifier. Conversely, for universal quantifiers, the where-clause weakens the assertion since the body now only applies for values that meet the criterion in the where-clause.

This specification defines certain allowable conversions between data types. For example, there is a pair of conversions between the Character String (ST) and Encode Data (ED). This means that if a one expects an ED value but actually has an ST value instead, one can turn the ST value into an ED.¹²

Three kinds of type conversions are defined: promotion, demotion, and character string literals. Type conversions can be implicit or explicit. Implicit type conversion occurs when a certain type is expected (e.g. as an argument to a statement) but a different type is actually provided. If the type provided has a conversion to the type expected the conversion should be done implicitly.

NOTE: an Implementation Technology Specification will have to specify how implicit type conversions are supported. Some technologies support it directly others do not; in any case, processing rules can be set that specify how these conversions are realized.

An explicit conversion can be specified in an assertion expression using the converted-to type name in parenthesis before the converted value. For example the following is an explicit type conversion in the where clause of an invariant statement.

invariant(ED x) where ((ST)x).nonNull { ... };
      

The type conversion has lower priority than the property resolution period. Thus "(T)a.b " converts the value of the property b of variable a to data type T while "((T)a).b " converts the value of variable a to T and then references property b of that converted value.

Implicit type conversions in the assertion expressions are performed where possible. If a property's formal argument is declared of data type T; but the expression used as an actual argument is of type U; and if U does not extend T; and if U defines a conversion to T, that conversion from T to U takes effect.

A demotion is a conversion with a net loss of information. Generally, this means that a more complex type is converted into a simple type.

An example for a demotion is the conversion from Interval (IVL) to a simple Quantity (QTY), e.g. the center of the interval. In the data type definition language, a demotion is declared using the keyword demotion and the data type name to which to demote:

type Interval alias IVL {
  ...
  demotion  QTY;
  ...
};
        

The specification of demotions shall indicate what information is lost and what the major consequences of losing this information are.

A promotion is a conversion where new information is generated. Generally, this means that a simpler type is converted into a more complex type.

For example, we allow any Quantity (QTY) to be converted to an Interval (IVL). However, IVL has more semantic properties than QTY, low and high boundary. Thus, the conversion of QTY to IVL is a promotion. The additional properties of QTY not present in IVL must assume new values, default values, or computed values. The specification of the promotion must indicate what these values are or how they can be generated.

A promoting conversion from type QTY to type IVL is defined as a semantic property of data type QTY using the keyword promotion and the data type name to which to promote:

type Quantity alias QTY {
  ...
  promotion   IVL;
  ...
};
        

Typically, a promotion is defined from a simple type to a more complex type. Also typically, the simple type is declared earlier in this document than a more complex type. Declaring all promotions to complex types in the simple type would thus involve forward references and would be confusing to the reader. Therefore, an alternative syntax allows promotions to be defined in the more complex type. This is indicated by naming the type from which to promote in an argument list behind the type to which to promote.

type Interval alias IVL {
  ...
  promotion   IVL (QTY x);
  ...
};
        

A literal is a character string representation of a data value. Literals are defined for many types. A literal is a type conversion from and to a Character String (ST) with a specially defined syntax.

Not every conversion from and to an ST is a literal conversion, however. A literal for a data type should be able to represent the entire value set of a data type whereas any other conversion to and from ST may only map a smaller subset of the converted data type.

The purpose of having literals is so that one can write down values in a short human readable form. For example, literals for the types integer number (INT) and real number (REAL) are strings of sign, digits, possibly a decimal point, etc. The more important interval types (IVL<REAL>, IVL<PQ>, IVL<TS>) have literal representations that allow one to use, e.g., "<5" to mean "less than 5", which is much more readable than a fully structured form of the interval. For some of the more advanced data types such as intervals, general timing specification, and parametric probability distribution we expect that the literal form may be the only form seen for representing these values until users have become used to the underlying conceptualizations.

Each literal conversion has its own syntax (grammar,) often aligned with what people find intuitive. This syntax may therefore not be completely straightforward from a computer's perspective.¹³

NOTE: Character string based Implementable Technology Specifications (ITS) of these abstract data types may or may not choose the literals defined here as their representations for these data types. We expect that the XML ITS, will use some but not all of the literals defined here.

In the data type definition language we declare a literal form as a property of a data type using the keyword literal followed by the data type name ST, since the literal is a conversion to and from the ST data type.

type IntegerNumber alias INT {
  ...
  literal   ST;
  ...
};
        

The actual definition of the literal form occurs outside the data type declaration body using an attribute grammar. An attribute grammar is a grammar that specifies both syntax and semantics of language structures. The syntax is defined in essentially the Backus-Naur-Form (BNF).¹⁴

For example, consider the following simple definition of a data type for cardinal numbers (positive integers.) This type definition depends only the Boolean data type (BL) and has a character string literal declared:

type CardinalNumber alias CARD {
  BL  isZero;
  BL  equals(CARD x);
  CARD  successor;
  CARD  plus(CARD x);
  CARD  timesTen;
  literal   ST;
};
        

• Syntax Definition

The literal syntax and semantics is first exposed completely and then described in all detail.

CARD.literal ST {
  CARD
  : CARD digit  { $.equals($1.timesTen.plus($2); }
  | digit   { $.equals($1); };

  CARD digit
  : "0"   { $.isZero; }
  | "1"     { $.equals(0.successor); }
  | "2"     { $.equals(1.successor); }
  ...
  | "8"   { $.equals(7.successor); }
  | "9"     { $.equals(8.successor); }
};
        

Every syntactic rule consists of the name of a symbol, a colon and the definition (so called production) of the symbol. A production is a sequence of symbols. These other symbols are also defined in the grammar, or they are terminal symbols. Terminal symbols are character strings written in double quotes or string patterns (called regular expressions.) Thus the form:

CARD : CARD digit | digit;
        

means, that any cardinal number symbol is a cardinal number symbol followed by a digit or just a digit. The vertical bar stands for a disjunction (logical OR.) A syntactic rule ends with a semicolon.

Every symbol has exactly one value of a defined data type. The data type of the symbol's value is declared where the symbol is defined:

CARD digit : "0" | "1" | "2" | ... | "8" | "9";
        

means that the symbol digits has a value of type CARD. The start-symbol is the data type itself and does not need a separate name.

• Semantics Definition

The semantics of the literal expression is specified in semantic rules enclosed in curly braces for each of the defined productions of a symbol:

symbol : production₁ { rule₁ } | production₂ { rule₂ } | ... | production_n { rule_n };

A semantic rule is simply a semicolon-separated list of Boolean assertion expressions of the same kind as those used in invariant statements. However, there are special variables defined in the semantic rule that all begin with a dollar character (e.g., $, $1, $2, $3, ...) The simple $ stands for the value of the currently defined symbol; while $1, $2, $3, etc. stand for the values of the parts of the semantic rule's associated production. For example, in

CARD
: CARD digit  { $.equals($1.timesTen.plus($2); }
| digit   { $.equals($1); };
        

the first production "CARD digit" has a semantic rule that says: the value $ of the defined symbol equals the value $1 of the first symbol CARD times ten plus the value $2 of the second symbol digit.¹⁵

• Terminal Symbols

A terminal symbol can be specified as a string pattern, so-called regular expression. The regular expression syntax used here is the classic syntax invented by Aho and used in AWK, LEX, GREP, and PERL. Regular expressions appear between two slashes /.../. In a regular expression pattern every character except [ ] ^ $ . / : ( ) \ | ? * + { } matches itself. The other characters that are actually used in this specification are defined in Table 4.

Generic data types are incomplete type definitions. This incompleteness is signified by one or more parameters to the type definition. Usually parameters stand for other types. Using parameters, a generic type might declare semantic properties of other not fully specified data types. For example, the generic data type Interval is declared with a parameter T that can stand for any Quantity data type (QTY). The components low and high are declared as being of type T.

template<QTY T>
type Interval<T> alias IVL<T> {
    T low;
  T   high;
};
      

Instantiating a generic type means completing its definition. For example, to instantiate an Interval, one must specify of what base data type the interval should be. This is done by binding the parameter T. To instantiate an Interval of Integer numbers, one would bind the parameter T to the type Integer. Thus, the incomplete data type Interval is completed to the data type Interval of Integer.

For example the following type definition for MyType declares a property named "multiplicity" that is an interval of the cardinal number data type used in the above examples.

type MyType alias MT {
    IVL<CARD> multiplicity;
};
      

Generic data types for collections are being used throughout this specification. The most important of them are

Set (SET<T>.) A set contains elements in no particular order and without duplicate elements. The SET<T> data type requires all elements of a set to be of the same data type.

Sequence (LIST<T>.) A sequence is a collection of values in an arbitrary but particular order. A sequence has a head and a tail, where the head is an element and the tail is the sequence without its head.

Interval (IVL<T>.) An interval is a continuous subset of an ordered type.

These and other generic types are fully defined in Section Error! Reference source not found.. These generic data types and their properties are being used in this specification early on. For the best understanding of this specification knowledge about the set, sequence and interval is important and the reader is advised to refer to Section Error! Reference source not found. when coming across a generic type being used to define another type.

Generic data type extensions are generic types with one parameter type that the generic type extends. In the formal data type definition language, generic type extensions follow the pattern:

template<ANY T> type GenericTypeExtensionName extends T { ... };
        

These generic type extensions inherit properties of their base type and add some specific feature to it. The generic type extension is a specialization of the base type, thus a value of the extension data type can be used instead of its base data type.¹⁶

NOTE: values of extended types can be substituted for their base type. However, an ITS may make some constraints as to what extensions to accommodate. Particularly, extensions need not be defined for those components carrying the values of data value properties. Thus, while any data value can be annotated outside the data type specification, an ITS may not provide for a way to annotate the value of a data value property.

Definition:      A meta-type declared in order to allow the formal definitions to speak about the data type of a value. Any data type defined in this specification is a value of the type DataType.

private type DataType extends DataValue {
    CE  name;
};
      

Definition:      A CE specifying the identifier of the data type. The short alias name, if defined, is the main code value, in which case the long name is an equivalent translation in the CE value.

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 concrete type is a specialization of this general abstract DataValue type.

abstract type DataValue alias ANY {
    DataType  dataType;
    BL  nonNull;
    CS  nullFlavor;
    BL  isNull;
    BL  notApplicable;
    BL  unknown;
    BL  other;
    BL  equals(ANY x);
};
      

Definition:      Represents the fact that every data value implicitly carries information about its own data type. Thus, given a data value one can inquire about its data type.

invariant(ANY x) {
  x.dataType.nonNull;
};
        

Definition:      Indicates that a value is a non-exceptional value of the data type.

invariant(ANY x) {
  x.isNull.equals(x.nonNull.not);
};
        

When a property, RIM attribute, or message field is called mandatory this means that any non-NULL value of the type to which the property belongs has a non-NULL value for that property, in other words, a field may not be NULL, providing that its container (object, segment, etc.) is to have a non-NULL value.

Definition:      Indicates that a value is an exceptional value, or a NULL-value. A null value means that the information does not exists, is not available or cannot be expressed in the data type's normal value set.

Every data element has either a proper value or it is considered NULL. If (and only if) it is NULL, the provides more detail as to in what way or why no proper value is supplied.

Definition:      If a value is an exceptional value (NULL-value), this specifies in what way and why proper information is missing.

invariant(ANY x) {
  x.nonNull.equals(x.nullFlavor.isNull);
};
        

The null flavors are a general domain extension of all normal data types. Note the distinction between value domain of any data type and the vocabulary domain of coded data types. A vocabulary domain is a value domain for coded values, but not all value domains are vocabulary domains.

The null flavor "other" is used whenever the actual value is not in the required value domain, this may be, for example, when the value exceeds some constraints that are defined too restrictive (e.g., age less than 100 years.)

NOTE: NULL-flavors are applicable to any property of a data value or a higher-level object attribute. Where the difference of null flavors is not significant, ITS are not required to represent them. If nothing else is noted in this specification, ITS need not represent general NULL-flavors for data-value properties.

Some of these null flavors are defined as named properties that can be used as simple predicates for all data values. This is done to simplify the formulation of invariants in the remainder of this specification.

Remember the difference between semantic properties and representational "components" of data values. An ITS must only represent those components that are needed to infer the semantic properties. The null-flavor predicates ANY.nonNull, ANY.isNull, ANY.notApplicable, ANY.unknown, and ANY.other can all be inferred from the property.

Definition:      A predicate indicating that this exceptional value is of ANY.nullFlavor not-applicable (NA), i.e., that a proper value is not meaningful in the given context.

invariant(ANY x) {
  x.notApplicable.equals(x.nullFlavor.implies(NA));
};
        

Definition:      A predicate indicating that this exceptional value is of ANY.nullFlavor unknown (UNK).

invariant(ANY x) {
  x.unknown.equals(x.nullFlavor.implies(UNK));
};
        

Definition:      A predicate indicating that this exceptional value is of ANY.nullFlavor other (OTH), i.e., that the required value domain does not contain the appropriate value.

invariant(ANY x) {
  x.other.equals(x.nullFlavor.implies(OTH));
};
        

Definition:      Equality is a reflexive, symmetric, and transitive relation between any two data values. Only proper values can be equal, null values never are equal (even if they have the same null flavor.)

invariant(ANY x, y, z)
  where x.nonNull.and(y.nonNull).and(z.nonNull)
{
  x.equals(x);                                        /* reflexivity */
  x.equals(y).equals(y.equals(x));                    /* symmetry */
  x.equals(y).and(y.equals(z)).implies(x.equals(z))   /* transitivity */
  x.equals(y).implies(x.dataType.equals(y.dataType);
};
        

How equality is determined must be defined for each data type. If nothing else is specified, two data values are equal if they are indistinguishable, that is, if they differ in none of their semantic properties. A data type can "override" this general definition of equality, by specifying its own equals relationship. This overriding of the equality relation can be used to exclude semantic properties from the equality test. If a data type excludes semantic properties from its definition of equality, this implies that certain properties (or aspects of properties) that are not part of the equality test are not essential to the meaning of the value.

For example the physical quantity has the two semantic properties (1) a real number and (2) a coded unit of measure. The equality test, however, must account for the fact that, e.g., 1 meter equals 100 centimeters; independent equality of the two semantic properties is too strong a criterion for the equality test. Therefore, physical quantity must override the equality definition.

NOTE: with data values, no distinction exists between equality and identity. Equality is a static property between two values, and values never change.

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

type Boolean alias BL extends ANY
    values(true, false)
{
            BL  and(BL x);
            BL  not;
  literal   ST;
            BL  or(BL x);
            BL  eor(BL x);
            BL  implies(BL x);
};
    

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:

Definition:      Negation of a Boolean turns true into false and false into true and is NULL for NULL values.

invariant(BL x) {
  true.not.equals(false);
  false.not.equals(true);
  x.isNull.equals(x.not.isNull);
};
      

Definition:      Conjunction (AND) is associative and commutative, with true as a neutral element. False AND any Boolean value is false. These rules hold even if one or both of the operands are NULL. If both operands for AND are NULL, the result is NULL.

invariant(BL x) {
  x.and(true).equals(x);
  x.and(false).equals(false);
  x.isNull.implies(x.and(y).isNull);
};
      

Definition:      The disjunction x OR y is false if and only if x is false and y is false.

invariant(BL x, y) {
  x.or(y).equals(x.not.and(y.not).not);
};
      

Definition:      The exclusive-OR constrains OR such that the two operands may not both be true.

invariant(BL x, y) {
  x.eor(y).equals(x.or(y).and(x.and(y).not));
};
      

Definition:      The logical implication is important to make invariant statements. An implication is a rule of the form IF condition THEN conclusion. Logically the implication is defined as the disjunction of the negated condition and the conclusion, meaning that when the condition is true the conclusion must be true to make the overall statement true.

invariant(BL condition, conclusion) {
  condition.implies(conclusion).equals(condition.not.or(conclusion));
};
      

The implication is not reversible and does not specify what is true when the condition is false (ex falso quodlibet lat. “from false follows anything”).

The literal form of the Boolean is determined by the named values specified in the values clause, i.e., true and false.

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.) Instead of the data itself, an ED may contain only a reference (see TEL.) Note that the ST data type is a specialization of the ED data type when the ED media type is text/plain.

type EncapsulatedData alias ED extends BIN {
  CS   mediaType;
  CS   charset;
  CS   language;
  CS   compression;
  TEL  reference
  BIN  integrityCheck;
  CS   integrityCheckAlgorithm;
  ED   thumbnail;
  BL   equals(ED x);
};
    

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.

Definition:      Binary data is a raw block of bits. Binary data is a protected type that should not be declared outside the data type specification.

A bit is semantically identical with a non-null Boolean value. Thus, all binary data is — semantically — a sequence of non-null Boolean values.

protected type BinaryData alias BIN extends LIST<BL>;
    

NOTE: the representation of arbitrary binary data is the responsibility of an ITS. How the ITS accomplishes this depends on the underlying Implementation Technology (whether it is character-based or binary) and on the so represented data. Semantically character data is represented as binary data, however, a character-based ITS should not convert character data into arbitrary binary data and then represent binary data in a character encoding. Ultimately even character-based implementation technology will communicate binary data.

An empty sequence is not considered binary data but counts as a NULL-value. In other words, non-NULL binary data contains at least one bit. No bit in a non-NULL binary data value can be NULL.

invariant(BIN x) where x.nonNull {
  x.nonEmpty;
  x.length.greaterThan(0);
  x.head.nonNull;
};
      

Definition:      Identifies the encoding of the encapsulated data and identifies a method to interpret or render the data.

The mediaType is a mandatory property, i.e., every non-NULL instance of encapsulated data must have a defined type property.

invariant(ED x) where x.nonNull {
  x.mediaType.nonNull;
};
        

The IANA defined domain of media types is established by the Internet standard RFC 2046 [http://www.isi.edu/in-notes/rfc2046.txt]. RFC 2046 defines the media type to consist of two parts:

1. top level media type, and



2. media subtype.

However, this specification treats the entire media type as one atomic code symbol in the form defined by IANA, i.e., top level type followed by a slash "/" followed by media subtype. Currently defined media types are registered in a database [http://www.isi.edu/in-notes/iana/assignments/media-types] maintained by IANA. Currently more than 160 different MIME media types are defined, with the list growing rapidly. In general, all those types defined by the IANA may be used.

To promote interoperability, this specification prefers certain media types to others. This is to define a greatest common denominator on which interoperability is not only possible, but that is powerful enough to support even advanced multimedia communication needs.

Table 6 below assigns a status to certain MIME media types, where the status means one of the following:

• required Every HL7 application must support at least the required media types if it supports a given kind of media. One required media-type for each kind of media exists. Some media types are required for a specific purpose, which is then indicated as "required for ..."



• recommended Other media types are recommended for a particular purpose. For any given purpose there should be only very few additionally recommended media types and the rationale, conditions and assumptions of such recommendations must be made very clear.



• indifferent This status means, HL7 does neither forbid nor endorse the use of this media type. All media types not mentioned here by default belong into the indifferent category. Since there is one required and several recommended media types for most practically relevant use cases, media types of this status should be used very conservatively.



• deprecated Deprecated media types should not be used, because these media types are flawed, because there are better alternatives, or because of certain risks. Such risks could be security risks, for example, the risk that such a media type could spread computer viruses. Not every flawed media type is marked as deprecated, though. A media type that is not mentioned, and thus considered other by default, may well be flawed.

The set of required media types is very small so that no undue requirements are forced on HL7 applications, especially legacy systems. In general, no HL7 application is forced to support any given kind of media other than written text. For example, many systems just do not want to receive audio data, because those systems can only show written text to their users. It is a matter of application conformance statements to say: "I will not handle audio". Only if a system claims to handle audio media, it must support the required media type for audio.

Definition:      For character-based encoding types, this property specifies the character set and character encoding used. The charset is defined according to Internet RFC 2278, [http://www.isi.edu/in-notes/rfc2278.txt].

The charset domain is maintained by the Internet Assigned Numbers Authority (IANA) [http://www.isi.edu/in-notes/iana/assignments/character-sets]. The IANA source specifies names and multiple aliases for most character sets. For the HL7's purposes, use of multiple alias names is not allowed. The standard name for HL7 is the one marked by IANA as "preferred for MIME." If IANA has not marked one of the aliases as "preferred for MIME" the main name shall be the one used for HL7.

Table 7 lists a few of the IANA defined character sets that are of interest to current HL7 members.

NOTE: The above list is not complete let alone exclusive. In particular, international HL7 affiliates may make special recommendations about charsets to be used in their realm. These recommendations may add additional charsets and may reassign the recommendations status of a listed charset.

Definition:      For character based information the language property specifies the human language of the text.

The need for a language code for text data values is documented in RFC 2277, IETF Policy on Character Sets and Languages [http://www.isi.edu/in-notes/rfc2277.txt]. Further background information can be found in Using International Characters in Internet Mail [http://www.imc.org/mail-i18n.html], a memo by the Internet Mail Consortium.

The principles of the code domain of this attribute are specified by the Internet standard RFC 1766. It is a set of pre-coordinated pairs of one 2-letter ISO 639 language code and one 2-letter ISO 3166 country code.¹⁷

Language tags do not modify the meaning of the characters found in the text; they are only an advice on if and how to present or communicate the text.¹⁸

NOTE: Representation of language tags to text is highly dependent on the ITS. An ITS should use the native way of language tagging provided by its target implementation technology. Some may have language information in a separate component, e.g., XML has the xml:lang tag for strings. Others may rely on language tags as part of the binary character string representation, e.g., ISO 10646 (Unicode) and its "plane-14" language tags.

The language tag should not be mandatory if it is not mandatory in the implementation technology. Semantically, language tagging of strings follows a default-logic. If nothing else is specified the local language is assumed. If a language is set for an entire message or document, that language is the default. If any information element or value that is superior in the syntax hierarchy specifies a language, that language is the default for all subordinate text values.

If language tags are present in the beginning of the encoded binary text (e.g., through Unicode's plane-14 tags) this is the source of the language property of the encapsulated data value.

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

ST may never be compressed.

Definition:      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. The reference must point to the same data as provided inline.

By-reference encapsulated data may not be allowed depending on the attribute or component that is declared encapsulated data. ST must always be inline.

Definition:      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.

The integrity check is calculated according to the ED.integrityCheckAlgorithm. By default, the Secure Hash Algorithm-1 (SHA-1) shall be used. The integrity check is binary encoded according to the rules of the integrity check algorithm.

The integrity check is calculated over the raw binary data that is contained in the data component, or that is accessible through the reference. No transformations are made before the integrity check is calculated. If the data is compressed, the Integrity Check is calculated over the compressed data.

Definition:      Specifies the algorithm used to compute the integrityCheck value.¹⁹

Definition:      A thumbnail is 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.

A thumbnail is 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.

Thumbnails may not be allowed depending on the attribute or component that is declared encapsulated data. ST never have thumbnails, and a thumbnail may not itself contain a thumbnail.

invariant(ED x) where x.thumbnail.nonNull {
  x.thumbnail.thumbnail.isNull;
};
          

NOTE: The ITS should consider the case where the thumbnail and the original both have the same properties of type, charset and compression. In this case, these properties need not be represented explicitly for the thumbnail but might be "inherited" from the main encapsulated data value to its thumbnail.

Two values of type Encapsulated Data are equal if and only if their type and referenced data are equal. For those ED values with compressed data or remote data, only the de-referenced and uncompressed data counts for the equality test. The compression and reference property themselves are excluded from the equality test, as is the thumbnail and the language property. If the ED.mediaType is character based and the charset property is not equal, the charset property must be resolved through mapping of the data between the different character sets.

The integrity check algorithm and integrity check is excluded from the equality test. However, since equality of integrity check value is strong indication for equality of the data, the equality test can be practically based on the integrity check, given equal integrity check algorithm properties.

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.

The character string is a restricted encapsulated data type (ED), whose type property is fixed to text/plain, and whose data must be inlined and not compressed. Thus, the properties compression, reference, integrity check, algorithm, and thumbnail are not applicable. The character string data type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names.

The character string (ST) data type interprets the encapsulated data as character data (as opposed to bits), depending on the charset property of the encapsulated data type.

type CharacterString alias ST restricts ED {
    INT   length;
    ST    head;
    ST    tail;
};

invariant(ST x) where x.nonNull {
  x.mediaType.equals("text/plain");
  x.compression.notApplicable;
  x.reference.notApplicable;
  x.integrityCheck.notApplicable;
  x.integrityCheckAlgorithm.notApplicable;
  x.thumbnail.notApplicable;
}
    

NOTE: Because many of the properties of the encapsulated data are bound to a default value, an ITS need not represent these properties at all. In fact, if the character encoding is also fixed, the ITS only represents the encoded character data.

The character string inherits the properties head, tail, and length from BIN (via ED). These properties head, tail, and length, are redefined so that the character string appears as a sequence of entities each of which uniquely identifies one character from the joint set of all characters known by any language of the world.²¹ The properties head, tail, and length therefore refer to character, string, and character counts respectively, rather than bits and bit counts.

The head of a string is a string of only one character. A character string must at least have one character or else it is NULL. The length of a character string is the number of characters in the string. A zero-length string is an exceptional value (NULL), not a proper character string value.

invariant(ST x) where x.nonNull {
  x.head.nonEmpty;
  x.head.tail.isEmpty;
  x.tail.isEmpty.implies(x.length.equals(1));
  x.tail.nonEmpty.implies(x.length.equals(x.tail.length.successor));
};
    

The length of a string is the number of characters, not the number of encoded bytes. Byte encoding is an ITS issue and is not relevant on the application layer.

Fixed to be "text/plain".

Two variations of character string literals are defined, a token form and a quoted string.²² The token form consists only of the lower case and upper case English alphabet, the ten decimal digits and the underscore. The quoted string can contain any character between double-quotes. The double quotes prevent a character string from being interpreted as some other literal. The token form allows keywords and names to be parsed from the data type specification language.

ST.literal ST {
  ST : /"[^]*"/ { $.equals($1); }   /* quoted string */
     | /[a-zA-Z0-9_]+/  { $.equals($1); };    /* token form */
};
      

NOTE: Since character string literals are so fundamental to implementation technology, most ITS will specify some modified character string literal form. However, ITS designers must be aware of the interaction between the character string literal form and the literal forms defined for other data types. This is particularly critical if the other data type's literal form is structured with major components separated by break-characters (e.g., real number, physical quantity, set, and list literals, etc.)

Definition:      A concept descriptor represents any kind of concept usually by giving a code defined in a code system. A concept descriptor 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 concept descriptor 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 exceptional cases, the concept descriptor need not contain a code but only the original text describing that concept.

type ConceptDescriptor alias CD extends ANY {
            ST    code;
            ST    displayName;
            OID   codeSystem;
            ST    codeSystemName;
            ST    codeSystemVersion;
            ED    originalText;
            LIST<CR>  qualifier;
            SET<CD>   translation;
            BL  equals(CD x);
            BL  implies(CD x);
  demotion  ED;
};
    

The concept descriptor is mostly used in one of its restricted or “profiled” forms, CS, CE, CV.

Definition:      A concept qualifier code with optionally named role. Both qualifier role and value codes must be defined by the coding system. 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. The CD data type 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.)

protected type ConceptRole alias CR extends ANY {
  CV  name;
  BL  inverted;
  CD  value;
};
    

Definition:      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 "has-laterality" is the CR.name.

If a coding system allows postcoordination but no role names (e.g. SNOMED) the name attribute can be NULL.

invariant(CR x) where x.nonNull {
  x.name.qualifier.isNull;
};
      

Definition:      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 "left" is the CR.value.

This property is of type concept descriptor and thus can in turn have qualifiers. This allows 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.

invariant(CR x) where x.nonNull {
  x.value.nonNull;
};
      

Definition:      Indicates if the sense of the role 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.

For example, a code system may define the role relation "causes" besides the concepts "Streptococcus pneumoniae" and "Pneumonia". If that code system allows its roles to be inverted, one can construct the post-coordinated concept "Pneumococcus pneumonia" through "Pneumonia - causes, inverted - Streptococcus pneumoniae."

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, if it is NULL, the role cannot be interpreted.

invariant(CR x) where x.nonNull {
  x.inverted.nonNull;
};
      

NOTE: the property "inverted" should be conveyed in an indicator attribute, whose default value is false. That way the inverted indicator does not have to be sent when the role is not inverted.

Definition:      The plain code symbol defined by the code system. For example, "784.0" is the code symbol of the ICD-9 code "784.0" for headache.

A non-exceptional CD value has a non-NULL code property whose value is a character string that is a symbol defined by the coding system identified by the codeSystem property. Conversely, a CD value without a value for the code property, or with a value that is not from the cited coding system is an exceptional value (NULL of flavor other).

invariant(CD x) where x.nonNull {
  x.code.nonNull;
};
      

Definition:      Specifies the code system that defines the code.

Code systems shall be referred to by Unique Identifier (UID). The UID allows unambiguous reference to standard HL7 codes, other standard code systems, as well as local codes. HL7 shall assign an UID to each of its code tables as well as to external standard coding systems that are being used with HL7. Local sites must use their ISO Object Identifier (OID) to construct a globally unique local coding system identifier.

Under HL7's branch, 2.16.840.1.113883, the sub-branches 5 and 6 contain HL7 standard and external code system identifiers respectively. The HL7 Vocabulary Technical Committee maintains these two branches.

A non-exceptional CD value (i.e. a CD value that has a non-null code property) has a non-NULL code system specifying the system of concepts that defines the code. In other words whenever there is a code there is also a code system.

NOTE: although every non-NULL CD value has a defined code system, in some circumstances, the external representation of the CD value needs not explicitly mention the code system. For example, when the context mandates one and only one code system to be used specifying the code system explicitly would be redundant. However, in that case the code system property assumes that context-specific default value and is not NULL.

invariant(CD x) where x.code.nonNull {
  x.codeSystem.nonNull;
};
      

An exceptional CD of NULL-flavor "other" indicates that a concept could not be coded in the coding system specified. Thus, for these coding exceptions, the code system that did not contain the appropriate concept must be provided in the code system property.

Some code domains are qualified such that they include the portion of any pertinent local coding system that does not simply paraphrase the standard coding system (coded with extensibility, CWE.) If a CWE qualified field actually contains such a local code, the coding system must specify the local coding system from which the local code was taken. However, for CWE domains the local code is a valid member of the domain, so that local codes in CWE domains constitute neither an error nor an exceptional (NULL/other) value in the sense of this specification.

invariant(CD x) where x.other {
  x.code.isNull;
  x.codeSystem.nonNull;
};
      

Definition:      A common name of the coding system.

The code system name is optional and has no function in communication. The purpose of a code system name is to assist an unaided human interpreter of a code value to interpret the code system UID. It is suggested — though not absolutely required — that ITS provide for code system name fields in order to annotate the UID for human comprehension.

HL7 systems must not functionally rely on the code system name. The code system name can never modify the meaning of the code system UID value and cannot exist without the UID value.

invariant(CD x) {
  x.codeSystemName.nonNull.implies(x.codeSystem.nonNull);
};
      

Definition:      If applicable, a version descriptor defined specifically for the given code system

HL7 shall specify how these version strings are formed for each external code system. If HL7 has not specified how version strings are formed for a particular coding system, version designations have no defined meaning for such coding system.

Different versions of one code system must be compatible. Whenever a code system changes in an incompatible way, it will constitute a new code system, not simply a different version, regardless of how the vocabulary publisher calls it.

For example, the publisher of ICD-9 and ICD-10 calls these code systems, "revision 9" and "revision 10" respectively. However, ICD-10 is a complete redesign of the ICD code, not a backward compatible version. Therefore, for the purpose of this data type specification, ICD-9 and ICD-10 are different code systems, not just different versions. By contrast, when LOINC updates from revision "1.0j" to "1.0k", HL7 would consider this to be just another version of LOINC, since LOINC revisions are backwards compatible.

invariant(CD x) {
  x.codeSystemVersion.nonNull.implies(x.codeSystem.nonNull);
};
      

Definition:      A name or title for the code, under which the sending system shows the code value to its users.

The display name 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 the code.

NOTE: display names may not alter the meaning of the code value. Therefore, display names should not be presented to the user on a receiving application system without ascertaining that the display name adequately represents the concept referred to by the code value. Communication must not simply rely on the display name. The display name's main purpose is to support debugging of HL7 protocol data units (e.g., messages.)

invariant(CD x) {
  x.displayName.nonNull.implies(x.code.nonNull);
};
      

Definition:      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.²³

Although the concept descriptor's value property is NULL, original text may still exist for the CD value. Any CD value with the code property of NULL signifies a coding exception. In this case, the text property is a name or description of the concept that was not coded. Such exceptional CD may contain translations. Such translations directly encode the concept described in the original text property.

Neither display name nor original text is part of the information a receiving system must automatically recognize. An information producer is responsible for the proper coding of all information in the value attribute, for any information consumer may safely ignore the display name and original text attributes.

A concept descriptor can be demoted into a character string (ST) value representing only the original text of the CD value.

invariant(CD x) where x.text.nonNull {
  ((ST)x).equals(x.text);
};
      

Definition:      A set of other concept descriptors that translate this concept descriptor into other code systems.

The translation property is a set of other concept descriptors thate each translate the first concept descriptor into different code systems. Each element of the translation set was translated from the first concept descriptor. 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.

NOTE: the translations are quasi-synonyms of one real-world concept. Every translation in the set is supposed to express the same meaning "in other words." However, exact synonymy rarely exists between two structurally different coding systems. For this reason, not all of the translations will be equally exact.

Definition:      Specifies additional codes that increase the specificity of the the primary code.

The primary code and all the qualifiers together make up one concept. A concept descriptor with qualifiers is also called a code phrase.

Qualifiers constrain the meaning of the primary code, but do not shift or even invert the meaning of the primary code. The meaning of the primary code without qualifiers must not be wrong, although less specific.

Qualifiers can only be used according to well-defined rules of post-coordination. A concept descriptor may only have qualifiers if the 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.

For example, SNOMED allows constructing concepts as a combination of multiple codes. SNOMED RT defines a concept "cellulitis (morphologic abnormality)" (M-41650) a role "associated topography" (G-C505) and another concept "left foot (body structure)" (T-D9720). SNOMED-RT allows one to combine these codes in a code phrase:

<observation>
  ...
  <value code="M-41650" codeSystem="&SNM;" displayName="cellulites (morphologic abnormality)"/>
  <qualifier code="T-D9720" display="left foot">
    <name code="G-C505" displayName="associated topography"/>
  </qualifier>
  ...
</observation>
       

In this example, there is one code system, SNOMED-RT that defines all the primary code and the qualifiers and how these are used, which is why in our example representation the codeSystem does not need to be mentioned for the qualifier name and value (the codeSystem is inherited from the primary code.)

Another common example is the U.S. Health Care Financing Administration (HCFA) procedure codes. HCFA procedure codes (HCPCS) are based on CPT-4 and add additional qualifiers to it. For example, the patient with above finding (plus peripheral arterial disease, diabetes mellitus, and a chronic skin lesion at the left great toe) may have an amputation of that toe. The CPT-4 concept is "Amputation, toe metatarsophalangeal joint" (28820) and a HCPCS qualifier needs to be added to indicate "left foot, great toe" (TA). Thus we code:

<procedure>
  ...
  <cd code="28820" codeSystem="&CP4;" displayName="Amputation, toe metatarsophalangeal joint">
    <qualifier code="TA" codeSystem="&HCP;" displayName="left foot, great toe"/>
  </cd>
  ...
</procedure>
       

In this example, the code system of the qualifier (HCPCS) is different than the code system of the primary code (CPT-4.) It is only because there are well-defined rules that define how these codes can be combined, that the qualifier may be used. Note also, that the role name is optional, and for HCPCS codes there are no distinguished role names.

The order of qualifiers is preserved, particularly for the case where the coding system allows post-coordination but defines no role names. (e.g., some ICD-9CM codes, or the old SNOMED "multiaxial" coding.)

The main use of concept descriptors is for the purpose of indexing, querying and decision-making based on a coded value. A semantically unambiguous specification of coded values therefore requires a clear definition of what equality of concept descriptor values means and how CD values should be compared.

The equality of two concept descriptor values is determined solely based upon the code and coding system. The code system version is excluded from the equality test.²⁴ If qualifiers are present, the qualifiers are included in the equality test. Translations are not included in the equality test.²⁵ Exceptional concept descriptor values are not equal even if they have the same NULL-flavor or the same original text.²⁶

invariant(CD x, y) x.nonNull.and(y.nonNull) {
  x.equals(y).equals(x.code.equals(y.code)
                .and(x.codeSystem.equals(y.codingSystem))
                .and(x.qualifier.equals(y.qualifier)));
};
      

Some code systems define certain style options to their code values. For example, the U.S. National Drug Code (NDC) has a dash and a non-dash form. An example for the dash form may be 1234-5678-90 when the non-dash form is 01234567890. Another example for this problem is when certain ISO or ANSI code tables define optional alphanumeric and numeric forms of two or three character lengths all in one standard.

In the case where code systems provide for multiple representations, HL7 shall make a ruling about which is the preferred form. HL7 shall document that ruling where that respective external coding system is recognized. HL7 shall decide upon the preferred form based on criteria of practicality and common use. In absence of clear criteria of practicality and common use, the safest, most extensible, and least stylized (the least decorated) form shall be given preference.²⁷

Definition:      Specifies whether this concept descriptor is a specialization of the operand concept descriptor.

Naturally, concepts can be narrowed and widened to include or exclude other concepts. Many coding systems have an explicit notion of concept specialization and generalization. The HL7 vocabulary principles also provide for concept specialization for HL7 defined value sets. The implies-property is a predicate that compares whether one concept is a specialization of another concept, and therefore implies that other concept.

When writing predicates (e.g., conditional statements) that compare two codes, one should usually test for implication not equality of codes.

For example, in Table 19 the "telecommunication use" concepts: work (W), home (H), primary home (HP), and vacation home (HV) are defined, where both HP and HV imply H. When selecting any home phone number, one should test whether the given use-code cimplies H. Testing for cequals H would only find unspecified home phone numbers, but not the primary home phone number.

Operationally, implication can be evaluated in one of two ways. The code system literals may be designed such that one single hierarchy is reflected in the code literal itself (e.g., ICD-9.) Apart from such special cases, however, a terminological knowledge base and an appropriate subsumption algorithm will be required to evaluate implication statements. For post-coordinated coding systems, designing such a subsumption algorithm is a non-trivial task.²⁸

Specializations of Concept Descriptor (CD)

Use of the full concept descriptor data type is exceptional. It requires a conscious decision and documented rationale. In all other cases, one of the CD restrictions shall be used.²⁹

All CD restrictions constrain certain properties of the CD. Properties may be constraint to the extent that only one value may be allowed for that property, in which case mentioning the property becomes redundant. Constraining a property to one value is referred to as suppressing that property. Although, conceptually a suppressed property is still semantically applicable, it is safe for an HL7 interface to assume the implicit default value without testing.

Definition:      Coded data in its simplest form, where only the code and display name is not predetermined. The code system and code system version is fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set.

type CodedSimpleValue alias CS restricts CD {
  ST    code;
  ST    displayName;
};
    

CS can only be used in either of the following cases:

1. for a coded attribute which has a single HL7-defined code system, and where code additions to that value set require formal HL7 action (such as harmonization.) Such coded attributes that are designated "structural" codes must be assigned the CS restriction.



2. for a technical property in this specification that is assigned to a single code system defined either in this specification or defined outside HL7 by a body that has authority over the concept and the maintenance of that code system.

For example, since the ED type subscribes to the MIME design, it trusts IETF to manage the media type. This includes that this specification subscribes to the extension mechanism built into the MIME media type code (e.g., "application/x-myapp").

For CS values, the designation of the domain qualifier will always be CNE (coded, non-extensible) and the context determines unambiguously which HL7 value set applies.³⁰

invariant(CS x) where x.nonNull {
  x.code.nonNull;
};
      

Every non-NULL CS value has a defined code system. The external representation of the CS needs not explicitly mention the code system, because the context mandates one and only one code system to be used. Specifying the code system explicitly would be redundant. However, the code system property assumes that context-specific default value and is not NULL.

invariant(CS x) where x.code.nonNull {
  x.codeSystem.nonNull;
};
      

invariant(CS x) where x.other {
  x.code.isNull;
  x.codeSystem.nonNull;
};
      

invariant(CS x) {
  x.codeSystem.equals(CONTEXT.codeSystem);
};
      

invariant(CS x) {
  x.codeSystemVersion.equals(CONTEXT.codeSystemVersion);
};
      

invariant(CS x) {
  x.originalText.isNull;
};
      

invariant(CS x) {
  x.translation.isNull;
};
      

invariant(CS x) {
  x.qualifier.notApplicable;
};
      

Definition:      Coded data, specifying only a code, code system, and optionally display name and original text. Used only as the data type for other data types' properties.

type CodedValue alias CV restricts CD {
  ST    code;
  OID   codeSystem;
  ST    codeSystemName;
  ST    codeSystemVersion;
  ST    displayName;
  ST    originalText;
};
    

This type 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.

invariant(CV x) {
  x.translation.isNull;
};
      

invariant(CV x) {
  x.qualifier.notApplicable;
};
      

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

type CodedWithEquivalents alias CE restricts CD {
    ST    code;
    ST    displayName;
    OID   codeSystem;
    ST    codeSystemName;
    ST    codeSystemVersion;
    ED  originalText;
    SET<CV>   translation;
};
    

The CE type is used when the use case indicates that alternative codes may exist and where it is useful to communicate these. The CE type provides for a primary code value, plus a set of alternative or equivalent representations.

invariant(CE x) {
  x.qualifier.notApplicable;
};
      

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.

type InstanceIdentifier alias II extends ANY {
  ST      extension;
  UID     root;
  ST      assigningAuthorityName;
  CV      type;
  IVL<TS> validTime;
  BL      equals(II x);
};
    

Definition:      A unique identifier string is a character string which identifies an object in a globally unique and timeless manner. The allowable formats and values and procedures of this data type are strictly controlled by HL7. At this time, user-assigned identifiers may be certain character representations of ISO Object Identifiers (OID) and DCE Universally Unique Identifiers (UUID). HL7 also reserves the right to assign other forms of UIDs, such as mnemonic identifiers for code systems.

The sole purpose of the UID is to be a globally and timelessly unique identifier. The form of the UID, whether it is an OID, an UUID or any other form is entirely irrelevant. As far as HL7 is concerned, the only thing one can do with a UID is denote to the object for which it stands. Comparison of UIDs is literal, i.e. if two UIDs are literally identical, they are assumed to denote to the same object. If two UIDs are not literally identical they may not denote to the same object (and in general are assumed to denote to different objects.)

type UniqueIdentifierString alias UID extends ST { };
    

No difference in semantics is recognized between the different allowed forms of the UID. The different forms are not distinguished by a component within or aside from the identifier string itself.

Even though this specification recognizes no semantic difference between the different forms of the unique identifier forms, there are differences of how these identifiers are built and managed, which is the sole reason to define subtypes to the UID for each of the variants.

Definition:      A globally unique string representing an ISO Object Identifier (OID) in a form that consists only of numbers and dots (e.g., "2.16.840.1.113883.3.1"). According to ISO, OIDs are paths in a tree structure, with the left-most number representing the root and the right-most number representing a leaf.

Each branch under the root corresponds to an assigning authority. Each of these assigning authorities may, in turn, designate its own set of assigning authorities that work under its auspices, and so on down the line. Eventually, one of these authorities assigns a unique (to it as an assigning authority) number that corresponds to a leaf node on the tree. The leaf may represent an assigning authority (in which case the OID identifies the authority), or an instance of an object. An assigning authority owns a namespace, consisting of its sub-tree.

OIDs are the preferred scheme for unique identifiers. OIDs should always be used except if one of the inclusion criteria for other schemes apply.

ISO/IEC 8824:1990(E) clause 28 defines the Object Identifier as

28.9 The semantics of an object identifier value are defined by reference to an object identifier tree. An object identifier tree is a tree whose root corresponds to [the ISO/IEC 8824 standard] and whose vertices [i.e. nodes] correspond to administrative authorities responsible for allocating arcs [i.e. branches] from that vertex. Each arc from that tree is labeled by an object identifier component, which is [an integer number]. Each information object to be identified is allocated precisely one vertex (normally a leaf) and no other information object (of the same or a different type) is allocated to that same vertex. Thus an information object is uniquely and unambiguously identified by the sequence of [integer numbers] (object identifier components) labeling the arcs in a path from the root to the vertex allocated to the information object.

28.10 An object identifier value is semantically an ordered list of object identifier component values. Starting with the root of the object identifier tree, each object identifier component value identifies an arc in the object identifier tree. The last object identifier component value identifies an arc leading to a vertex to which an information object has been assigned. It is this information object, which is identified by the object identifier value. [...]

type ObjectIdentifier alias OID extends UID, LIST<INT> {
  INT   leaf;
  OID   butLeaf;
  OID value(namespace OID);
  literal ST;
};
    

According to ISO/IEC 8824 an object identifier is a sequence of object identifier component values, which are integer numbers. These component values are ordered such that the root of the object identifier tree is the head of the list followed by all the arcs down to the leaf representing the information object identified by the OID. The fact that OID extends LIST<INT> represents this path of object identifier component values from the root to the leaf.

The leaf and "butLeaf" properties take the opposite view. The leaf is the last object identifier component value in the list, and the "butLeaf" property is all of the OID but the leaf. In a sense, the leaf is the identifier value and all of the OID but the leaf refers to the namespace in which the leaf is unique and meaningful.

However, what part of the OID is considered value and what is namespace may be viewed differently. In general, any OID component sequence to the left can be considered the namespace in which the rest of the sequence to the right is defined as a meaningful and unique identifier value. The value-property with a namespace OID as its argument represents this point of view.³¹

invariant(OID x) x.nonNull {
  x.nonEmpty;
  x.tail.isEmpty.implies(x.leaf.equals(x.tail));
  x.tail.nonEmpty.implies(x.leaf.equals(x.tail.leaf);
  x.tail.isEmpty.implies(x.butLeaf.isNull);
  x.tail.nonEmpty.implies(x.butLeaf.head.equals(x.head)
                     .and(x.butLeaf.tail.equals(x.butLeaf(x.tail))));
  forall(OID v; OID n) where v.equals(x.value(n)) {
    n.isEmpty.implies(v.equals(x));
    n.nonEmpty.implies(v.equals(x.value(n.tail)));
  };
};
    

HL7 shall establish an OID registry and assign OIDs in its branch for HL7 users and vendors upon their request. HL7 shall also assign OIDs to public identifier-assigning authorities both U.S. nationally (e.g., the U.S. State driver license bureaus, U.S. Social Security Administration, HIPAA Provider ID registry, etc.) and internationally (e.g., other countries Social Security Administrations, Citizen ID registries, etc.) The HL7 assigned OIDs must be used for these organizations, regardless whether these organizations have other OIDs assigned from other sources.

When assigning OIDs to third parties or entities, HL7 shall investigate whether an OID is already assigned for such entities through other sources. It this is the case, HL7 shall record such OID in a catalog, but HL7 shall not assign a duplicate OID in the HL7 branch. If possible, HL7 shall notify a third party when an OID is being assigned for that party in the HL7 branch.

Though HL7 shall exercise diligence before assigning an OID in the HL7 branch to third parties, given the lack of a global OID registry mechanism, one cannot make absolutely certain that there is no preexisting OID assignment for such third-party entity. Also, a duplicate assignment can happen in the future through another source. If such cases of supplicate assignment become known to HL7, HL7 shall make efforts to resolve this situation. For continued interoperability in the meantime, the HL7 assigned OID shall be the preferred OID used.

While most owners of an OID will "design" their namespace sub-tree in some meaningful way, there is no way to generally infer any meaning on the parts of an OID. HL7 does not standardize or require any namespace sub-structure. An OID owner, or anyone having knowledge about the logical structure of part of an OID, may still use that knowledge to infer information about the associated object; however, the techniques cannot be generalized.

An HL7 interface must not rely on any knowledge about the substructure of an OID for which it cannot control the assignment policies.

The structured definition of the OID is provided mostly to be faithful to the OID specification. Within HL7, OIDs are used as UID strings only, i.e., the literal string value is the only thing that is communicated and is the only thing that a reciever should have to consider when working with UIDs in the scope of the HL7 specification.

OID.literal ST {
    OID : INT "." OID { $.head.equals($1);
      $.tail.equals($3); }
        | INT   { $.head.equals($1);
      $.tail.isEmpty; }
}
      

For compatibility with the DICOM standard, the literal form of the OID should not exceed 64 characters. (see DICOM part 5, section 9).

Definition:      A globally unique string representing a DCE Universal Unique Identifier (UUID) in the common UUID format that consists of 5 hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4, and 12 places respectively.

Both the UUID and its string representation are defined by the Open Group, CDE 1.1 Remote Procedure Call specification, Appendix A.

UUIDs are assigned based on Ethernet MAC addresses, the point in time of creation and some random component. This mix is believed to generate sufficiently unique identifiers without any organizational policy for identifier assignment (in fact this piggy-backs on the organization of MAC address assignment.)

UUIDs are not the preferred identifier scheme for use as HL7 UIDs. UUIDs may be used when identifiers are issued to objects representing individuals (e.g., entity instance identifiers, act event identifiers, etc.) For objects describing classes of things or events (e.g., catalog items), OIDs are the preferred identifier scheme.

type UniversalUniqueIdentifier alias UUID extends UID {
  INT timeLow;
  INT timeMid;
  INT timeHighAndVersion;
  INT clockSequence;
  INT node;
}
    

The structured definition of the UUID is provided mostly to be faithful to the UUID specification. Within HL7, UUIDs are used as UID strings only, i.e., the literal string value is the only thing that is communicated and is the only thing that a reciever should have to consider when working with UIDs in the scope of the HL7 specification.

The literal form for the UUID is defined according to the original specification of the UUID. However, because the HL7 UIDs are case sensitive, for use with HL7, the hexadecimal digits A-F in UUIDs must be converted to upper case.

UUID.literal ST {
  UUID : hex8 "-" hex4 "-" hex4 "-" hex4 "-" hex12 {
          $.timeLow.equals($1);
          $.timeMid.equals($3);
          $.timeHighAndVersion.equals($5);
          $.clockSequence.equals($7);
          $.node.equals($9);
  }

  INT hex4 :  hexDigit hexDigit hexDigit hexDigit {
          $.equals($1.times(16).plus($2)
	             .times(16).plus($3)
		     .times(16).plus($4);
  }

  INT hex8 :  hexDigit hexDigit hexDigit hexDigit
              hexDigit hexDigit hexDigit hexDigit {
          $.equals($1.times(16).plus($2)
	             .times(16).plus($3)
		     .times(16).plus($4)
	             .times(16).plus($5)
		     .times(16).plus($6)
	             .times(16).plus($7)
		     .times(16).plus($8);
  }

  INT hex12 : hexDigit hexDigit hexDigit hexDigit
              hexDigit hexDigit hexDigit hexDigit
              hexDigit hexDigit hexDigit hexDigit {
          $.equals($1.times(16).plus($2)
	             .times(16).plus($3)
		     .times(16).plus($4)
	             .times(16).plus($5)
		     .times(16).plus($6)
	             .times(16).plus($7)
		     .times(16).plus($8)
		     .times(16).plus($9)
	             .times(16).plus($10)
		     .times(16).plus($11)
		     .times(16).plus($12);
  }

  INT hexDigit
  : "0" { $.equals(0); }
  | "1" { $.equals(1); }
  | "2" { $.equals(2); }
  | "3" { $.equals(3); }
  | "4" { $.equals(4); }
  | "5" { $.equals(5); }
  | "6" { $.equals(6); }
  | "7" { $.equals(7); }
  | "8" { $.equals(8); }
  | "9" { $.equals(9); }
  | "A" { $.equals(10); }
  | "B" { $.equals(11); }
  | "C" { $.equals(12); }
  | "D" { $.equals(13); }
  | "E" { $.equals(14); }
  | "F" { $.equals(15); }
}
      

NOTE: The output of UUID related programs and functions may use all sorts of forms, upper case, lower case, and with or without the hyphens that group the digits. This variate output must be postprocessed to conform to the HL7 specification, i.e., the hyphens must be inserted for the 8-4-4-4-12 grouping and all hexadecimal digits must be converted to upper case.

Definition:      A globally unique string defined exclusively by HL7. Identifiers in this scheme are only defined by balloted HL7 specifications. Local communities or systems must never use such reserved identifiers based on bilateral negotiations.

HL7 reserved identifiers are strings that consist only of (US-ASCII) letters, digits and hyphens, where the first character must be a letter. HL7 may assign these reserved identifiers as mnemonic identifiers for major concepts of interest to HL7.

Definition:      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 "assigning 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.³²

invariant(II x) where x.nonNull {
  root.nonNull;
};
      

Definition:      A character string as a unique identifier within the scope of the identifier root.

The extension is a character string that is unique in the namespace designated by the root. If a non-NULL extension is exists, the root specifies a namespace (sometimes called "assigning authority" or "identifier type".) The extension property may be NULL in which case the root OID is the complete unique identifier.

It is recommended that systems use the OID scheme for external identifiers of their communicated objects. The extension property is mainly provided to accommodate legacy alphanumeric identifier schemes.

Some identifier schemes define certain style options to their code values. For example, the U.S. Social Security Number (SSN) is normally written with dashes that group the digits into a pattern "123-12-1234". However, the dashes are not meaningful and a SSN can just as well be represented as "123121234" without the dashes.

In the case where identifier schemes provide for multiple representations, HL7 shall make a ruling about which is the preferred form. HL7 shall document that ruling where that respective external identifier scheme is recognized. HL7 shall decide upon the preferred form based on criteria of practicality and common use. In absence of clear criteria of practicality and common use, the safest, most extensible, and least stylized (the least decorated) form shall be given preference.³³

HL7 may also decide to map common external identifiers to the value portion of the II.root OID. For example, the U.S. SSN could be represented as 2.16.840.1.113883.4.1.123121234. The criteria of practicality and common use will guide HL7's decision on each individual case.

Definition:      A human readable name or mnemonic for the assigning authority. This name may be provided solely for the convenience of unaided humans interpreting an II value. Note: no automated processing must depend on the assigning authority name to be present in any form.

NOTE: no automated processing must depend on the assigning authority name to be present in any form.

The assigning authority name is not the name for the individually identified object, but for the namespace, that immediately contains that object identifier. Two cases exist.

1. If the extension property is non-NULL, the root OID identifies the assigning authority; hence the assigning authority name is a name or mnemonic for the entire root OID.



2. If the extension is NULL, the assigning authority name is the name or mnemonic of the namespace property of the OID value.

Definition:      Specifies if the identifier's extension is intendended for human display and data entry (displayable = true) as opposed to pure machine interoperation (displayable = false).

Definition:      If applicable, specifies during what time the identifier is valid. By default, the identifier is valid indefinitely. Any specific interval may be undefined on either side indicating unknown effective or expiry time. Note: identifiers for information objects in computer systems should not have restricted valid times, but should be globally unique at all times. The identifier valid time is provided mainly for real-world identifiers, whose maintenance policy may include expiry (e.g., credit card numbers.)

NOTE: identifiers for information objects in computer systems should not have restricted valid times, but should be globally unique at all times. The identifier valid time is provided mainly for real-world identifiers, whose maintenance policy may include expiry (e.g., credit card numbers).

The II type conforms to the history item data type extension (Section 0). This means that the data types HXIT<II> and II are the same.

Two instance identifiers are equal if and only if their root and extension properties are equal.

invariant(II x, y) where x.nonNull.and(y.nonNull) {
  x.equals(y).equals(x.root.equals(y.root)
                .and(x.extension.equals(y.extension)));
}
      

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 deciding which address to use for a given time and purpose.

The semantics of a telecommunication address is that a communicating entity (the responder) listens and responds to that address, and therefore can be contacted by an other communicating entity (the initiator.)

The responder of a telecommunication address may be an automatic service that can respond with information (e.g., FTP or HTTP services.) In such case a telecommunication address is a reference to that information accessible through that address. A telecommunication address value can thus be resolved to some information (in the form of encapsulated data, ED.)

type TelecommunicationAddress alias TEL extends URL {
  GTS   validTime;
  SET<CS>   use;
  BL  equals(TEL x);
};
    

The telecommunication address is an extension of the Universal Resource Locator (URL) specified as an Internet standard RFC 1738 [http://www.isi.edu/in-notes/rfc1738.txt]. The URL specifies the protocol and the contact point defined by that protocol for the resource. Notable use cases for the telecommunication address data type are for telephone and fax numbers, e-mail addresses, Hypertext references, FTP references, etc.

Definition:      A telecommunications address specified according to Internet standard RFC 1738 [http://www.isi.edu/in-notes/rfc1738.txt]. The URL 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.

The Internet standard RFC 1738 [http://www.isi.edu/in-notes/rfc1738.txt] defines URL as follows:

Just as there are many different methods of access to resources, there are several schemes for describing the location of such resources.

The generic syntax for URLs provides a framework for new schemes to be established using protocols other than those defined in this document.

URLs are used to "locate" resources, by providing an abstract identification of the resource location. Having located a resource, a system may perform a variety of operations on the resource, as might be characterized by such words as "access", "update", "replace", "find attributes". In general, only the "access" method needs to be specified for any URL scheme.

protected type UniversalResourceLocator alias URL extends ANY {
  CS  scheme;
  ST  address;
  literal ST;
};
    

Definition:      Identifies the protocol used to interpret the address string and to access the resource so addressed.

Some URL schemes are registered by the Internet Assigned Numbers Authority (IANA) [http://www.iana.org], however IANA only registers URL schemes that are defined in Internet RFC documents. In fact there are a number of URL schemes defined outside RFC documents, part of which are registered with the World Wide Web Consortium (W3C).³⁴

Similar to the ED.mediaType, HL7 makes suggestions about . classifying them as required, recommended, other, and deprecated. Any scheme not mentioned has status other.

Note that this specification explicitly limits itself to URLs. Universal Resource Names (URN) are not covered by this specification. URNs are a kind of identifier scheme for other than accessible resources. This specification, however, is only concerned with accessible resources, which belong into the URL category.

Definition:      The address is a character string whose format is entirely defined by the URL.scheme.

While conceptually URL has the properties scheme and address, the common appearance of a URL is as a string literal formed according to the Internet standard. The general syntax of the URL literal is:

URL.literal ST {
  URL : /[a-z0-9+.-]+/ ":" ST { $.scheme.equals($1);
                                $.address.equals($3); }
};
      

Note that there is no special data type for telephone numbers, telephone numbers are TEL and are specified as URL.

The telephone number URL is defined in Internet RFC 2806 [http://www.isi.edu/in-notes/rfc2806.txt]. Its definition is summarized in this subsection. This summary does not override or change any of the Internet specification's rulings.

The voice telephone URLs begin with "tel:" and fax URLs begin with "fax:"

The URL.address is the telephone number in accordance with ITU-T E.123 Telephone Network and ISDN Operation, Numbering, Routing and Mobile Service: Notation for National and International Telephone Numbers (1993). While HL7 does not add or withdraw from the URL specification, the preferred subset of the URL.address address syntax is given as follows:

proctected type TelephoneURL restricts URL {
  literal ST {
    URL : /(tel)|(fax)/ ":" address   { $.scheme.equals($1);
                  $.address.equals($3); };
    ST address : "+" phoneDigits
    ST phoneDigits : digitOrSeparator phoneDigits | digitOrSeparator
    ST digitOrSeparator : digit | separator;
    ST digit : /[0..9]/;
    ST separator : /[().-]/;
  };
};
      

The global absolute telephone numbers starting with the "+" and country code are preferred. Separator characters serve as decoration but have no bearing on the meaning of the telephone number. For example: "tel:+13176307960" and "tel:+1(317)630-7960" are both the same telephone number; "fax:+49308101724" and "fax:+49(30)8101-724" are both the same fax number.

Definition:      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.

The TEL data type where is constrained to a simple interval of time (IVL<TS>) conforms to the history item data type extension (HXIT). Thus, HXIT<TEL> is a simple restriction of TEL.

Definition:      One or more codes advising a 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.

Two telecommunication address values are considered equal if both their URLs are equal. Use code and valid time are excluded from the equality test.

invariant(TEL x, y) x.nonNull.and(y.nonNull) {
  x.equals(y).equals(((URL)x).equals((URL)y));
}
      

Definition:      Mailing and home or office addresses. A sequence of address parts, such as street or post office Box, city, postal code, country, etc.

The AD is primarily used to communicate data that will allow printing mail labels, 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 is captured by other, more appropriate HL7 elements.

Addresses are conceptualized as text with added logical mark-up. The mark-up may break the address into lines and may describe in detail the role of each address part if it is known. Address parts occur in the address in the order in which they would be printed on a mailing label. The approach is similar to HTML or XML markup of text (but it is not technically limited to XML representations.)

Addresses are essentially sequences of address parts, but add a "use" code and a valid time range for information about if and when the address can be used for a given purpose.

type PostalAddress alias AD extends LIST<ADXP> {
  SET<CS>   use;
  GTS validTime;
  BL  equals(AD x);
  ST  formatted;
};
    

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 are indicated by special line-breaking delimiter elements (e.g., DEL).

protected type AddressPart alias ADXP extends ST {
  CS  type;
};
    

Definition:      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.

Definition:      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.

Definition:      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 year or to refer to historical addresses.

The AD where is constrained to a simple interval of time (IVL<TS>) conforms to the history item data type extension (HXIT). Thus, HXIT<AD> is a simple restriction of AD.

Two address values are considered equal if both contain the same address parts, independent of ordering. Use code and valid time are excluded from the equality test.

invariant(AD x, y) x.nonNull.and(y.nonNull) {
  x.equals(y).equals((
        forall(ADXP p) where x.contains(p) {
	  y.contains(p);
	}).and.(
        forall(ADXP p) where x.contains(p) {
	  y.contains(p);
	}));
};
      

Definition:      A character string value with the address formatted in lines and with proper spacing. This is only a semantic property to define the function of some of the address part types.³⁵

The AD data type's main purpose is to capture postal addresses, such that one can visit that address or send mail to it. Humans will look at addresses in printed form, such as on a mailing label. The AD data type defines precise rules of how its data is formatted.³⁶

Addresses are ordered lists of address parts. Each address part is printed in the order of the list from left to right and top to bottom (or in any other language-specific reading direction, which to determine is outside the scope of this specification.) Every address part value is printed. Most address parts are framed by white space. The following six rules govern the setting of white space.

1. White space never accumulates, i.e. two subsequent spaces are the same as one. Subsequent line breaks can be reduced to one. White space around a line break is not significant.



2. Literals may contain explicit white space, subject to the same white space reduction rules. There is no notion of a literal line break within the text of a single address part.



3. Leading and trailing explicit white space is insignificant in all address parts, except for delimiter (DEL) address parts.



4. By default, an address part is surrounded by implicit white space.



5. Delimiter (DEL) address parts are not surrounded by any implicit white space.



6. Leading and trailing explicit white space is significant in delimiter (DEL) address parts.

This means that all address parts are generally surrounded by white space, but white space does never accumulate. Delimiters are never surrounded by implicit white space and every white space contributed by preceding or succeeding address parts is discarded, whether it was implicit or explicit.

The following shows examples of addresses in the XML ITS form.

1050 W Wishard Blvd,
RG 5th floor,
Indianapolis, IN 46240.

Can be encoded in any of the following forms:³⁷

The first form would result from a system that only stores addresses as free text or in a list of fields line1, line2, etc.:

<addr use="WP">
  1050 W Wishard Blvd,
  RG 5th floor,
  Indianapolis, IN 46240
</addr>
 

The second form is more specific about the role of the address parts than the first one:

<addr use="WP">
  <streetAddressLine>1050 W Wishard Blvd</streetAddressLine>,
  <streetAddressLine>RG 5th floor</streetAddressLine>,
  <city>Indianapolis</city>, <state>IN</state> <postalCode>46240</postalCode>
</addr>
 

This form is the typical form seen in the U.S., where street address is sometimes separated, and city, state and ZIP code are always separated.

The third is even more specific:

<addr use="WP">
  <houseNumber>1050</houseNumber> <direction>W</direction> <streetName>Wishard Blvd</streetName>,
  <additionalLocator>RG 5th floor</additionalLocator>,
  <city>Indianapolis</city>, <state>IN</state> <postalCode>46240</postalCode>
</addr>
 

The latter form above is not used in the USA. However, it is useful in Germany, where many systems keep house number as a distinct field. For example, the German address:

Windsteiner Weg 54a,
D-14165 Berlin

would most likely be encoded as follows:³⁸

<addr use="HP">
  <streetName>Windsteiner Weg</streetName> <houseNumber>45a</houseNumber>,
  <country>D</country>-<postalCode>14165</postalCode> <CTY>Berlin</CTY>
</addr>
 

Definition:      A name for a person, organization, place or thing. A sequence of name parts, such as first name or family name, prefix, suffix, etc. 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.", "Lake" and "Tahoe".

Entity names are conceptualized as text with added logical mark-up. Name parts occur in a natural order in which they would be displayed, as opposed to in a order detemined by name part. The ordeing of the name parts is significant a feature that replaces the need for a separate "display name" property. Applications may change that ordering of name parts to account for their user's customary ordering of name parts. The approach is similar to HTML or XML markup of text (but it is not technically limited to XML representations.)

Entity names are essentially sequences of entity name parts, but add a "use" code and a valid time range for information about when the name was used and how to choose between multiple aliases that may be valid at the same point in time.

type EntityName alias EN extends LIST<PNXP> {
  SET<CS> use;
  IVL<TS> validTime;
  BL  equals(AD x);
  ST  formatted;
};
    

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 a qualifyer code for more detail about the name part type. Typical name parts for person names are given names, and family names, titles, etc.

protected type EntityNamePart alias ENXP extends ST {
  CS  type;
  SET<CS>   qualifier;
};
    

Definition:      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 first name or which is a last name, or whether Rogan may be a title.

Entity names are conceptualized as text with added mark-up. The mark-up may break the address into lines and may describe in detail the role of each name part if it is known. Name parts occur in the order in which they would be printed on a mailing label. The model is similar to HTML or XML markup of text.

Applications are not required to preserve the ordering of the name parts.

Definition:      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

Definition:      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 address useful for any purpose, but an address with a specific use code would be preferred for that respective purpose.

Definition:      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.

The EN conforms to the history item data type extension (HXIT).

Two name values are considered equal if both conatain the same name parts, independent of ordering. Use code and valid time are excluded from the equality test.

invariant(EN x, y) x.nonNull.and(y.nonNull) {
  x.equals(y).equals((
        forall(ENXP p) where x.contains(p) {
	  y.contains(p);
	}).and.(
        forall(ENXP p) where x.contains(p) {
	  y.contains(p);
	}));
      

Definition:      A character string value with the entity name formatted with proper spacing. This is only a semantic property to define the function of some of the name part types.³⁹

The EN data type's main purpose is to capture names of people, places, and things (entities), so that one can address and refer to these entities in speech and writing. Humans will look at names in printed form, such as on a mailing label. The EN data type therefore defines precise rules of how its data is formatted.⁴⁰

Entity names are ordered lists of entity name parts. Each entity name part is printed in the order of the list from left to right (or in any other language-specific reading direction.) Every entity name part (except for those marked "invisible") is printed. Most entity name parts are framed by whitespace. The following six rules govern the setting of whitespace.

1. White space never accumulates, i.e. two subsequent spaces are the same as one.



2. Literals may contain explicit white space subject to the same white space reduction rules.



3. Except for prefix, suffix and delimiter name parts, every name part is surrounded by implicit white space. Leading and trailing explicit whitespace is insignificant in all those name parts.



4. Delimiter name parts are not surrounded by any implicit white space. Leading and trailing explicit whitespace is significant in delimiter name parts.



5. Prefix name parts only have implicit leading white space but no implicit trailing white space. Trailing explicit whitespace is significant in prefix name parts.



6. Suffix name parts only have implicit trailing white space but no implicit leading white space. Leading explicit whitespace is significant in suffix name parts.



7. This means that all entity name parts are generally surrounded by whitespace, but whitespace does never accumulate. Delimiters are never surrounded by implicit white space, prefixes are not followed by implicit white space and suffixes are not preceded by implicit white space. Every whitespace contributed by preceding or succeeding name parts around those special name parts is discarded, whether it was implicit or explicit.

Specializations of Entity Name (EN)

Three restrictions to Entity Name are defined in order to allow making specific constraints for certain kinds of entities, trivial name (TN), person name (PN), and organization name (ON).

Definition:      A restriction of entity name that is effectively a simple string used for a simple name for things and places.

The TN is a EN that consists of only one name part without any name part type or qualifier. The TN, and its single name part are therefore equivalent to a simple character string. This equivalence is expressed by a defined demotion to ST and promotion from ST.

type TrivialName alias TN extends LIST<ST> {
  SET<CS> use;
  IVL<TS> validTime;
  BL  equals(AD x);
  ST  formatted;
 demotion ST;
 promotion  TN  (ST x);
};

invariant(TN x) where x.nonNull {
  x.head.nonNull;
  x.tail.isEmpty;
  x.formatted.equals(x.head);
};

invariant(ST x) {
  ((TN)x).head.equals(x);
};
    

Trivial names are typically used for places and things, such as Lake Erie or Reagan National Airport:

<name>Lake Erie</name>
<name>Washington National Airport</name>
     

Definition:      A name for a person. A sequence of name parts, such as first name or family name, prefix, suffix, etc.

Since most of the functionality of entity name is in support of person names, the person name (PN) is only a very minor restriction on the entity name part qualifier.

type PersonName alias PN extends LIST<PNXP> {
  SET<CS> use;
  IVL<TS> validTime;
  BL  equals(AD x);
  ST  formatted;
};
    

A very simple encoding of "John W. Doe" would be:

<name>
  <given>John</given> <given>W.</given> <family>Doe</family>
</name>
       

None of the special qualifiers need to be mentioned if they are unknown or irrelevant. The next example shows extensive use of multiple given names, prefixes, suffixes, for academic degrees, nobility titles, vorvoegsels ("van"), and professional designations.

<name>
  <prefix qualifier="AC">Dr. phil. </prefix>
  <given>Regina</given>
  <given>Johanna</given>
  <given>Maria</given>
  <prefix qualifier="NB">Gräfin </prefix>
  <prefix qualifier="VV">von </prefix>
  <family qualifier="BR">Hochheim</family>-<family qualifier="SP">Weilenfels</family>
  <suffix qualifier="PR">NCFSA</suffix>
</name>
       

The next example is an organization name, "Health Level Seven, Inc." in simple string form:

<name>Health Level Seven, Inc.</name>
 

and as a fully parsed name

<name>Health Level Seven, <suffix qualifier="LS">Inc.</suffix></name>
 

The following example shows a Japanese name in the three forms: ideographic (Kanji), syllabic (Hiragana), and alphabetic (Romaji).

<name use="IDE"><family>木村</family> <given>道男</given></name>
<name use="SYL"><family>きもら</family> <given>みちお</given></name>
<name use="ABC"><family>KIMURA</family> <given>MICHIO</given></name>
 

Definition:      A restriction of 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.

protected type PersonNamePart alias PNXP extends ST {
  CS  type;
  SET<CS>   qualifier;
};

invariant(PNXP x) where x.nonNull {
  x.qualifier.contains("LS").not;
};
    

Definition:      A name for an organization. A sequence of name parts.

A name for an organization, such as "Health Level Seven, Inc." An organization name consists only of untyped name parts, prefixes, suffixes, and delimiters.

type OrganizationName alias ON extends LIST<ONXP> {
  SET<CS> use;
  IVL<TS> validTime;
  BL  equals(AD x);
  ST  formatted;
};
    

The following is the organization name, "Health Level Seven, Inc." in a simple string form:

<name>Health Level Seven, Inc.</name>;
 

And with the legal status "Inc." as a distinguished name part:

<name>Health Level Seven, <suffix qualifier="L">Inc.</suffix></name>
 

Definition:      A restriction of entity name part that only allows those entity name parts qualifiers applicable to organization names.

protected type PersonNamePart alias ONXP extends ST {
  CS  type;
  SET<CS>   qualifier;
};

invariant(ONXP x) where x.nonNull {
  x.partType.implies("FAM").not;
  x.partType.implies("GIV").not;
};
    

Definition:      The quantity data type is an abstract generalization for all data types (1) whose value set has an order relation (less-or-equal) and (2) 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.

abstract type Quantity alias QTY extends ANY {
  BL   lessOrEqual(QTY x);
  BL   compares(QTY x);
  type QTY diff;
  diff minus(QTY x);
  QTY  plus(diff x);
  BL   isZero;
  BL   lessThan(QTY x);
  BL   greaterOrEqual(QTY x);
  BL   greaterThan(QTY x);
};
    

Definition:      A predicate expressing an order relation that is reflexive, asymmetric and transitive, between this quantitity and another quantity.

The relation is defined on any totally ordered partition of the quantity data type. A totally ordered partition is a subset of the data types's defined values where all elements have a defined order (e.g., the integer and real numbers are totally ordered.)

By contrast, a partially ordered set is a set where some, but not all pairs of elements are comparable through the order relation (e.g., a tree structure or the set of physical quantities is a partially ordered set.) Two data values x and y of an ordered type are comparable (x.compares(y)) if the less-or-equal relation holds in either way (x ≤ y or y ≤ x).

A partial order relation generates totally ordered subsets whose union is the entire set (e.g., the set of all length is a totally ordered subset of the set of all physical quantities.)

For example, a tree structure is partially ordered, where the root is considered less or equal to a leaf, but there may not be an order among the leafs. Also, physical quantities are partially ordered, since an order exists only among quantities of the same dimension (e.g., between two lengths, but not between a length and a time.) A totally ordered subset of a tree is a path that transitively connects a leaf to the root. The physical dimension of time is a totally ordered subset of physical quantities.

invariant (QTY x, y, z)
    where x.nonNull.and(y.nonNull).and(z.nonNull) {
  x.lessOrEqual(x);                         /* reflexive */
  x.lessOrEqual(y)                          /* asymmetric */
     .implies(y.lessOrEqual(x)).not();
  x.lessOrEqual(y).and(y.lessOrEqual(z))    /* transitive */
     .implies(x.lessOrEqual(z))
};
      

Definition:      A predicate indicating if this value and the operand can be compared as to which is greater than the other.

Two quantities are comparable if they are both elements of a common totally ordered partition of their data types' value space. The definition is based on QTY.lessOrEqual.

invariant (QTY x, y, z)
    where x.nonNull.and(y.nonNull).and(z.nonNull) {
  x.compares(y).equals(x.lessOrEqual(y).or(y.lessOrEqual(x)));
};
      

Definition:      A quantity expressing the "distance" of this quantity from the operand quantity, that must be comparable. The data type of the difference quantity is related to the operand quantities but need not be the same.

A difference is defined in an ordered set if it is semantically meaningful to state that Δ is the difference between the values x and y. This difference Δ must be meaningful independently from the values x and y. This independence exists if for all values u one can meaningfully derive a value v such that Δ would also be the difference between u and v. The judgment for what is meaningful cannot be defined formally.⁴¹

The has a data type that can express the difference between two values for which the ordering relation is defined (i.e., two elements of a common totally ordered subset.) For example, the difference data type of integer number is integer number, but the difference type of point in time is a physical quantity in the dimension of time. A difference data type is a totally ordered data type.

The difference between two values x minus y must be defined for all x and y in a common totally ordered subset of the data type's value set. Zero is the difference between a value and itself.

invariant(QTY x, y) where x.compares(y) {
  x.minus(y).nonNull;
  x.minus(x).isZero;
};
      

Definition:      The sum of this quantity and its operand. The operand must be of a data type that can express the difference between two values of this quantity's data type.

invariant(QTY x, y) where x.compares(y) {
  x.plus(y.minus(x)).equals(y);
};
      

Definition:      The neutral element in the difference and addition operations, i.e., if a quantity is zero, addition to, or subtraction from any other comparable quantity will result in that other quantity.

invariant(QTY x, y) where x.compares(y) {
  x.minus(x).isZero;
};
      

Definition:      A predicate expressing an order relation that is asymmetric and transitive, between this quantitity and another quantity. The ordering is the same as QTY.lessOrEqual, but irreflexive.

invariant (QTY x, y, z)
    where x.nonNull.and(y.nonNull).and(z.nonNull) {
  x.lessThan(y).equals(x.lessOrEqual(y).and(x.equals(y).not));
};
      

Definition:      A predicate expressing an order relation that is reflexive, asymmetric and transitive, between this quantitity and another quantity. This is the inverse order of QTY.lessOrEqual.

invariant (QTY x, y, z)
    where x.nonNull.and(y.nonNull).and(z.nonNull) {
  x.greaterOrEqual(y).equals(y.lessOrEqual(x));
};
      

Definition:      A predicate expressing an order relation that is asymmetric and transitive, between this quantitity and another quantity. This is the invese of QTY.lessThan.

invariant (QTY x, y, z)
    where x.nonNull.and(y.nonNull).and(z.nonNull) {
  x.greaterThan(y).equals(y.lessThan(x));
};
      

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. Two NULL flavors are defined for the positive and negative infinity.

type IntegerNumber alias INT extends QTY {
          INT   successor;
          INT   plus(diff x);
          INT   times(INT x);
  type    INT   diff;
          diff  minus(INT x);
          INT   predecessor;
          INT   negated;
          BL    isNegative;
          BL    nonNegative;
          INT   dividedBy(INT x);
          INT   remainder(INT y);
  literal ST;
};
    

The difference between two INT values is also a INT value.

Since the integer number data type includes all of the semantics of the mathematical integer number concept, the basic operations plus (addition) and times (multiplication) are defined. These operations are defined here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification, namely the semantics of the literal form.

The traditional recursive definitions of addition and multiplication are due to Grassmann, and use the notion of INT.successor.⁴²

invariant(INT x, o, i) where x.nonNull.and(o.isZero()) {
  x.lessThan(x.successor);
  x.plus(o).equals(x);
  x.plus(y.successor).equals(x.plus(y).successor);
  x.times(o).equals(o);
  x.times(y.successor).equals(x.times(y)).plus(x);
};
    

Definition:      The INT value that is greater than this INT value but where no INT value exists between this value and its successor.

invariant(INT x, y) where x.successor(y) {
  x.lessThan(y).and.not(exists(INT z) {
      x.lessThan(z);
      z.lessThan(y);
    });
};
      

invariant(INT x, y, o) where x.nonNull.and(y.nonNull).and(o.isZero) {
  x.plus(o).equals(x);
  x.plus(y.successor).equals(x.plus(y).successor);
};
      

Definition:      The result of multiplying this integer with the operand, equivalent to repeated additions of this integer.

invariant(REAL x, y, o) where x.compares(y).and(o.isZero) {
  x.times(o).equals(o);
  x.times(y.successor).equals(x.times(y)).plus(x);
};
      

Definition:      The inverse of INT.successor.

invariant(INT x, y) where x.successor(y) {
  x.successor.predecessor.equals(x);
};
      

Definition:      The inverse element of the INT value, another INT value, which, when added to that value yields zero (the neutral element.)

invariant(INT x) where x.nonNull {
  x.plus(x.negated).isZero;
};
      

Definition:      A predicate indicating whether the INT zero (neutral element) is less or equal to this INT.

invariant(INT x, o) where x.nonNull.and(o.isZero) {
  x.nonNegative.equals(o.lessOrEqual(x));
};
      

Definition:      A predicate indicating whether this INT is less than zero (not non-negative.)

invariant(INT x) where x.nonNull {
  x.isNegative.equals(x.nonNegative.not);
};
      

Definition:      The integer division operation of this integer (dividend) with another integer (divisor) is the integer number of times the divisor fits into the dividend.

invariant(INT dividend, divisor, o, i) 
    where divisor.isZero.not
     .and(o.isZero) {
  dividend.isZero
    .implies(dividend.dividedBy(divisor).equals(o));
  dividend.isZero.not
    .implies(dividend.dividedBy(divisor).equals(
                  absolute(dividend).minus(absolute(divisor))
       .dividedBy(absolute(divisor))
          .successor.times(sign(dividend).times(sign(divisor)))));
};
      

Definition:      The remainder of the integer division.

invariant(INT x, y) where x.nonNull.and(y.nonNull) {
  x.reminder(y).equals(x.minus(x.dividedBy(z).times(y)));
};
      

This definition of the remainder matches the C and Java programming languages.

The literal form of an integer is a simple decimal number, i.e. a string of decimal digits.

INT.literal ST {
  INT digit : "0"         { $.isZero; }
            | "1"         { $.equals(0.successor); }
            | "2"         { $.equals(1.successor); }
            | "3"         { $.equals(2.successor); }
            | "4"         { $.equals(3.successor); }
            | "5"         { $.equals(4.successor); }
            | "6"         { $.equals(5.successor); }
            | "7"         { $.equals(6.successor); }
            | "8"         { $.equals(7.successor); }
            | "9"         { $.equals(8.successor); };

  INT uint : digit        { $.equals($1); }
           | uint digit   { $.equals($1.times(9.successor).plus($2)); };

  INT : uint              { $.equals($1); }
      | "+" uint          { $.equals($2); }
      | "-" uint          { $.equals($2.negated); };
};
      

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.

The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers that would include irrational numbers such as ρ, Euler's number, etc.⁴³

NOTE: This specification defines the real number data type in the broadest sense possible. However, it does not imply that any conforming ITS or implementation must be able to represent the full range of Real numbers, which would not be possible in any finite implementation. HL7's current use cases for the Real number data type are measured and estimated quantities and monetary amounts. These use cases can be handled with a restricted Real value space, rational numbers, and even just very limited decimals (scaled integers.) However, we declare the representations of the real value space as floating point, rational, scaled integer, or digit string, and their various limitations to be out of the scope of this specification.

This specification offers two choices for a number data type. The choice is made as follows: Any number attribute is a real if it is not known for sure that it is an integer. A number is an integer if it is always counted, typically representing an ordinal number. If there are conceivable use cases where such a number would be estimated or averaged, it is not always an integer and thus should use the Real data type.

type RealNumber alias REAL extends QTY {
  type      REAL  diff;
            diff  minus(REAL x);
            REAL  plus(diff x);
            REAL  negated;
            REAL  times(REAL x);
            REAL  inverted;
            REAL  power(REAL x);
  literal   ST;
            INT   precision;
  demotion  INT;
  promotion REAL  (INT x);
  promotion PQ;
  promotion RTO;
};
    

The algebraic operations are specified here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification.

Unlike the integer numbers, the real numbers semantics are not inductively constructed but only intuitively described by their axioms of their algebraic properties. The completeness axioms are intentionally left out so as to make no statement about irrational numbers.

The value set of REAL is totally ordered.

invariant(REAL x, y)
    where x.nonNull.and(y.nonNull){
  x.compares(y);
}
      

invariant(REAL x, y, z, o)
    where x.nonNull.and(y.nonNull).and(z.nonNull).and(o.isZero) {
  x.plus(o).equals(x)                             /* neutral element */
  x.plus(y).plus(z).equals(x.plus(y.plus(z)));    /* associative */
  x.plus(y).equals(y.plus(x))                     /* commutative */

  z.lessOrEqual(x).and(z.lessOrEqual(y).implies(z.lessOrEqual(x.plus(y));
  x.lessOrEqual(y).implies(x.plus(z).lessOrEqual(y.plus(z)));
};
      

Definition:      A REAL value, which, when added to another REAL value yields zero (the neutral element of addition.)

invariant(INT x) where x.nonNull {
  x.plus(x.negated).isZero;
};
      

Definition:      A predicate indicating if this value is the number one, i.e., the neutral element of multiplication. There is exactly one real number that has this property.

invariant(REAL x, y) where x.nonNull.and(y.nonNull) {
  x.isOne.and(y.isOne).implies(x.equals(y));
  x.isOne.and(y.isZero).implies(x.equals(y).not);
};
      

Definition:      An operation in REAL that forms an abelian group and is related to addition by the law of distribution.

invariant(REAL x, y, z, i, o)
    where x.nonNull.and(y.nonNull).and(z.nonNull)
     .and(i.isOne).and(o.isZero) {
  x.times(o).equals(o);
  x.times(i).equals(x);                           /* neutral element */
  x.times(y).times(z).equals(x.times(y.times(z)));/* associative */
  x.times(y).equals(y.times(x));                  /* commutative */

  x.times(y.plus(z))                              /* distributive */
    .equals(x.times(y).plus(x.times(z));

  o.lessOrEqual(x).and(o.lessOrEqual(y).implies(o.lessOrEqual(x.times(y));
};
      

Definition:      A REAL value, which, when muliplied with another REAL value yields one (the neutral element of multiplication). Zero (the neutral element of addition) has no inverse element.

invariant(REAL x, i) where x.isZero.not.and(i.isOne) {
  x.times(x.inverted).equals(i);
};
      

The INT and REAL data types are related by a homomorphism that maps every value in INT to a value in REAL whereby the algebraic properties of INT are preserved. This means, an integer can be promoted to a real and a real can be demoted to an integer by means of rounding off the fractional part.

invariant(INT n, m) where n.nonNull.and(m.nonNull) {
  ((REAL)n.plus(m)).equals(((REAL)n).plus((REAL)m));
  ((REAL)n.times(m)).equals(((REAL)n).times((REAL)m));
};
      

Definition:      The basis of exponentiation is the iterative multiplication of a real number, and extended to rational exponents as the inverse operation.

We only list certain common properties of exponentiation.

invariant(REAL x, y, z, o, i)
    where x.nonNull.and(y.nonNull).and(z.nonNull)
     .and(o.isZero).and.(i.isOne) {
  forall(INT n) where n.nonNull {
    n.greaterThan(o).implies(
       x.power(n).equals(x.times(x.power(n.predecessor))));
    n.lessThan(o).implies(
       x.power(n).equals(x.power(n.negated).inverted);
  }
  x.power(o).equals(i);
  x.power(i).equals(x);
  x.power(y).power(z).equals(x.power(y.times(z)));
  x.power(y).times(x.power(z)).equals(x.power(y.plus(z)));
  x.power(y).inverted.equals(x.power(y.negated));
  x.power(y).power(y.inverted).equals(x);
};
      

The literal form of an integer is a string of decimal digits with optional leading "+" or "-" sign, and optional decimal point, and optional exponential notation using a case insensitive "e" between the mantissa and the exponent. The number of significant digits must conform to the precision property.

REAL.literal ST {
  REAL : mantissa                   { $.equals($1); }
       | mantissa /[eE]/ INT        { $.equals($1
                                         .times(10.power($3)); };

  REAL mantissa
       : /0*/ 0                     { $.isZero; $.precision.equals(1); }
       | /0*/ "." /0*/              { $.isZero; $.precision.equals(
                                                  $3.length.successor); }
       | /0*/ "." /0*/ fractional   { $.equals($4);
                                      $.precision.equals($4.precision); }
       | integer                    { $.equals($1); }
       | integer "." fractional     { $.equals($1.plus($2));
                                      $.precision.equals($1.precision
                                        .plus($3.precision)); };

  REAL integer
       : uintval                    { $.equals($2); }
       | "+" uintval                { $.equals($1.times($2)); }
       | "-" uintval                { $.equals($1.times($2).negated); };

  REAL uintval : /0*/ uint          { $.equals($2); };

  REAL uint : digit                 { $.equals($1);
                                      $.precision.equals(1); }
            | uint digit            { $.equals($1.times(10).plus($2));
                                      $.precision.equals(
                                        $1.precision.successor; };

  REAL fractional
       : digit                      { $.equals($1.times(10.inverted));
                                      $.precision.equals(1); }
       | digit fractional           { $.equals(
                                        $1.plus($2.times(10.inverted));
                                      $.precision.equals(
                                        $1.precision.successor); };

  INT digit : /[0-9]/               { $.equals($1); }
};
      

Examples of real literals for two thousand are 2000, 2000., 2e3, 2.0e+3, +2.0e+3.

Note that the literal form does not carry type information. For example, "2000" is a valid representation of both a real number and an integer number. No trailing decimal point is used to disambiguate from integer numbers. An ITS that uses this literal form must recover the type information from other sources.

Definition:      The number of significant digits of the decimal representation.

Precision is formally defined based on the REAL.literal

The precision attribute is only the precision of a decimal digit representation, not the accuracy of the real number value.

The purpose of the precision property for the real number data type is to faithfully capture the whole information presented to humans in a number. The amount of decimal digits shown conveys information about the uncertainty (i.e., precision and accuracy) of a measured value.

NOTE: the precision of the representation is independent from uncertainty (precision accuracy) of a measurement result. If the uncertainty of a measurement result is important, one should specify uncertain values as PPD

The rules for what digits are significant are as follows:

1. All non-zero digits are significant.



2. All zeroes to the right of a significant digit are significant.



3. When all digits in the number are zero the zero-digit immediately left to the decimal point is significant (and because of rule 2, all following zeroes are thus significant too.)

NOTE: these rules of significance differ slightly from the more casual rules taught in school. Notably trailing zeroes before the decimal point are consistently regarded significant here. Elsewhere, e.g., 2000 is ambiguous as to whether the zeroes are significant. This deviation from the common custom is warranted for the purpose of unambiguous communication.

The precision of the representation should match the uncertainty of the value. However, precision of the representation and uncertainty of the value are separate independent concepts. Refer to Section 4.4.2 for details about uncertain real numbers.

For example "0.123" has 3 significant digits in the representation, but the uncertainty of the value may be in any digit shown or not shown, i.e., the uncertainty may be 0.123±0.0005, 0.123±0.005 or 0.123±0.00005, etc. Note that external representations should adjust their representational precision with the uncertainty of the value. However, since the precision in the digit string is granular to 0.5 the least significant digit, while uncertainty may be anywhere between these "grid lines", 0.123±0.005 would also be an adequate representation for the value between 0.118 and 0.128.

NOTE: on a character based Implementation Technology the ITS need not represent the precision as an explicit attribute if numbers are represented as decimal digit strings. In that case, the ITS must abide by the rules of an unambiguous determination of significant digits. A number representation must not produce more or less significant digits than were originally in that number. Conformance can be tested through round-trip encoding — decoding — encoding.

Equality of real numbers is determined based on the value and precision. The value with a higher precision is rounded to the precision of the other value and then the comparison made.

NOTE: a raw equality test on real numbers is unreasonable for most practical purposes, since infinitesimal equality is rarely meaningful in practice but may lead to false negatives. This definition of equality is designed to be reasonably useful for simple cases. For more sophisticated cases it is recommended to compare decimal numbers based on intervals, that is, to test whether a real value falls within a certain range (interval).

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. In many cases the REAL should be used instead of the RTO.

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.

NOTE: 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.

type Ratio<QTY N, QTY D> alias RTO extends QTY {
  N numerator;
  D denominator;
  demotion  REAL;
  demotion  PQ;
};
    

The default value for both numerator and denominator is the integer number 1 (one.) The denominator may not be zero.

NOTE: This data type is defined as a generic data type but discussed in the context of the other quantity-related data types. The reason for defining RTO as a generic data type is so that it can be constrained precisely as to what the numerator and denominator types should be. (§ )

Definition:      The quantity that is being devided in the ratio. The default is the integer number 1 (one.)

Definition:      The quantity that devides the numerator in the ratio. The default is the integer number 1 (one.) The denominator must not be zero.

invariant(RTO x) where x.nonNull {
  x.denominator.isZero.not;
};
      

A ratio literal form exists for all ratios where both numerator and denominators have literal forms. A ratio is simply the numerator literal a colon as separator followed by the denominator literal. When the colon and denominator are missing, the integer number 1 is assumed as the denominator.

RTO.literal ST {
  RTO : QTY                 { $.numerator.equals($1);
                              $.denominator.equals((INT)1); };
      | QTY ":" QTY         { $.numerator.equals($1);
                              $.denominator.equals($3); };
};
     

For example, the rubella virus antibody titer value 1:64 could be represented using the literal "1:64".

Definition:      A dimensioned quantity expressing the result of measuring.

type PhysicalQuantity alias PQ extends QTY {
            REAL  value;
            CS    unit;
            BL    equals(PQ x)
            BL    lessOrEqual(PQ x);
            BL    compares(PQ x);
            PQ    canonical;
	    SET<PQR> translation;

  type      PQ    diff
            diff  minus(PQ x);
            PQ    plus(diff x);
            PQ    negated;
            PQ    times(REAL x);
            PQ    times(PQ x);
            PQ    inverted;
            PQ    power(INT x);

  literal   ST;
  demotion  REAL;

            REAL  originalValue;
            CV    originalUnit;
};
    

Definition:      An extension of the coded value data type representating a physical quantity using a unit from any code system. Used to show alternative representation for a physical quantity.

type PhysicalQuantityRepresentation alias PQR extends CV {
  REAL value;
}
    

Definition:      The magnitude of the measurement value in terms of the unit specified by this code.

Definition:      The magnitude of the quantity measured in terms of the unit.

Definition:      The unit of measure specified in the Unified Code for Units of Measure (UCUM) [http://aurora.rg.iupui.edu/UCUM].

NOTE: 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 provide automated conversion between different comparable units.

Definition:      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.

Physical quantities semantically are the results of measurement acts. Although physical quantities are represented as pairs of value and unit, semantically, a physical quantity is more than that. To find out whether two physical quantities are equal, it is not enough to compare equality of their two values and units independently. For example, 100 cm equals 1 m although neither values nor units are equal. To define equality we introduce the notion of a canonical form.

Definition:      A physical quantity expressed in a canonical unit. In any given unit system has every physical dimension can be assigned one canonical unit Defining the canonical unit is not subject of this specification, only asserting that such a canonical unit exists (and can be arbitrarily chosen) for every physical quantity. An abstract physical quantity is equal to its canonical form.

invariant(PQ x, y) where x.nonNull.and(y.nonNull) {
  x.canonical.equals(x);
};
      

For example, for a unit system based on the Système International (SI) one can define the canonical form as (a) the product of only the base units; (b) without prefixes; where (c) only multiplication and exponents are used (no division operation); and (d) where the seven base units appear in a defined ordering (e.g., m, s, g...) Thus, 1 mm Hg would be expressed as 133322 m^-1 s^-2. As can be seen, the rules how to build the canonical form of units may be quite complex. However, for the semantic specification it doesn't matter how the canonical form is built, nor what specific canonical form is chosen, only that some canonical form could be defined.

Two physical quantities are equal if each their values and their units of their canonical forms are equal.

invariant(PQ x, y) where x.nonNull.and(y.nonNull) {
  x.equals(y).equals(x.canonical.value.equals(y.canonical.value)
                .and(x.canonical.unit.equals(y.canonical.unit)));
};
      

Two physical quantities compare each other (and have an ordering and difference) if the units of their canonical forms are equal.

invariant(PQ x, y) where x.nonNull.and(y.nonNull) {
  x.compares(y).equals(x.canonical.unit.equals(y.canonical.unit));
};
      

Definition:      A predicate indicating if this value is the number one, i.e., the neutral element of multiplication. There is exactly one physical quantity that has this property and is called the unity.

invariant(PQ x, y) where x.nonNull.and(y.nonNull) {
  x.isOne.and(y.isOne).implies(x.equals(y));
  x.isOne.and(y.isZero).implies(x.equals(y).not);
};
      

Algebraic operations are defined for physical quantities because they are characterizing operations in the sense of ISO 11404 and because this specification makes use of them when defining the literal form.

Definition:      The product of two physical quantities is the product of their values times the product of their units.

invariant(PQ x, y, z, i, o)
    where x.nonNull.and(y.nonNull).and(z.nonNull)
     .and(o.isZero).and(i.isOne) {
  x.times(o).equals(o);
  x.times(i).equals(x);                           /* neutral element */
  x.times(y).times(z).equals(x.times(y.times(z)));/* associative */
  x.times(y).equals(y.times(x));                  /* commutative */

  o.lessOrEqual(x).and(o.lessOrEqual(y).implies(o.lessOrEqual(x.times(y));
};
      

Definition:      A PQ value, which, when muliplied with another PQ value yields one (the neutral element of multiplication). Zero (the neutral element of addition) has no inverse element. The quotient of two comparable quantities is comparable to the unity (the unit 1).

invariant(PQ x, y, i)
    where x.nonNull.and(y.nonNull).and(i.isOne) {
  x.times(x.inverted).equals(1);
  x.compares(y).implies(x.times(y.inverted).compares(1));
};
      

Definition:      Multiplication with a real number forms a scaled quantity. A scaled quantity is comparable to its original quantity.

If two quantities Q₁ and Q₂ compare each other, there exists a real number r such that r1 = Q₁ / Q₂.

invariant(PQ x; REAL r)
    where x.nonNull.and(r.nonNull) {
  x.times(r).value.equals(x.value.times(r));
  x.times(r).compares(x);
};
      

A REAL value can be converted to a PQ value with the unity, i.e. the unit 1 (one). Likewise, a physical quantity that compares the unity can be converted to a real number.

invariant(PQ x, unity) 
    where x.nonNull.and.unity.isOne
     .and(x.compares(unity)) {
  unity.times((REAL)x).equals(x);
};
      

Definition:      A physical quantity can be raised to an integer power.

invariant (PQ x, i; INT n, o) 
    where x.nonNull.and(i.isOne)
     .and(n.nonNull.and(o.isZero) {
  x.power(o).equals(i);
  n.greaterThan(o).implies(
      x.power(n).equals(x.times(x.power(n.predecessor))));
  n.lessThan(o).implies(
      x.power(n).equals(x.power(n.negated).inverted);
}
      

Definition:      Two physical quantities that compare each other can be added.

invariant (PQ x, y)
    where x.compares(y) {
  x.canonical.plus(y.canonical).value
     .equals(x.canonical.value.plus(y.canonical.value));
};
      

The literal form for a physical quantity is a real number literal followed by optional white space and a character string representing a valid code in the Unified Code for Units of Measure (UCUM) [http://aurora.rg.iupui.edu/UCUM].

PQ.literal ST {
  PQ : REAL unit    { $.value.equals($1);
                      $.unit.equals($2); }
  CS unit : ST      { $.value.equals($1);
                      $.codeSystem.equals(2.16.840.1.113883.6.8); };
};
      

For example 20 minutes is "20 min".

Definition:      A monetary amount 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 physical quantity and monetary amounts, and the reason why currency units are not physical units.

type MonetaryAmount alias MO extends QTY {
          REAL value;
          CS   currency;
  type    MO   diff
          MO   plus(diff x);
          diff minus(MO x);
          MO   negated;
          MO   times(REAL x);
  literal ST;
};
    

Definition:      The magnitude of the monetary amount in terms of the currency unit.

NOTE: monetary amounts are usually precise to 0.01 (one cent, penny, paisa, etc.) For large amounts, it is important not to store monetary amounts in floating point registers, since this may lose precision. However, this specification does not define the internal storage of real numbers as fixed or floating point numbers.

The precision attribute of the real number type is the precision of the decimal representation, not the precision of the value. The real number type has no notion of uncertainty or accuracy. For example, "1.99 USD" (precision 3) times 7 is "13.93 USD" (precision 4) and should not be rounded to "13.9" to keep the precision constant.

Definition:      The currency unit as defined in ISO 4217.

Two MO values are equal if each their values and their currency units are equal.

invariant(MO x, y) where x.nonNull.and(y.nonNull) {
  x.equals(y).equals(x.value.equals(y.value)
                .and(x.unit.equals(y.unit)));
};
      

Two MO values compare each other (and have an ordering and difference) if their currency units are equal.

If the currencies are not equal, the amounts cannot be compared. Conversion between the currencies is outside the scope of this specification. In practice, foreign exchange rates are highly variable not only over long and short amounts of time, but also depending on location and access to currency trade markets.

invariant(MO x, y) where x.nonNull.and(y.nonNull) {
  x.compares.equals(x.currency.equals(y.currency));
};
      

Definition:      Two monetary amounts can be added if they are denominated in the same currency.

invariant (MO x, y)
    where x.currency.equals(y.currency) {
  x.plus(y).currency.equals(x.currency);
  x.plus(y).value.equals(x.value.plus(y.value));
};
      

Definition:      Multiplication with a real number to forms a scaled quantity. A scaled quantity is comparable to its original quantity.

invariant(MO x; REAL r) where x.nonNull.and(r.nonNull) {
  x.times(r).value.equals(x.value.times(r));
  x.times(r).currency.equals(x.currency);
};
      

The literal form for a monetary amount consists of the currency code string, optional white space, and REAL literal amount.

MO.literal ST {
  MO : currency value     { $.currency.equals($1); }
                            $.value.equals($2);
  CS currency : ST        { $.currency.value.equals($1);
                            $.currency.codeSystem
                               .equals(2.16.840.1.113883.6.9); }
  REAL value : REAL       { $.value.equals($1); }
};
      

For example, "USD189.95" is the literal for 189.95 U.S. Dollar.

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

Semantically, however, time is independent from calendars and best described by its relationship to elapsed time (measured as a physical quantity in the dimension of time.) A point in time plus an elapsed time yields another point in time. Inversely, a point in time minus another point in time yields an elapsed time.

As nobody knows when time began, a point in time is conceptualized as the amount of time that has elapsed from some arbitrary zero-point, called an epoch. Because there is no absolute zero-point on the time axis natural time is a difference-scale quantity, where only differences are defined but no ratios. (For example, no point in time is — absolutely speaking — "twice as late" as another point in time.)

Given some arbitrary zero-point, one can express any point in time as an elapsed time measured from that offset. Such an arbitrary zero-point is called an epoch. This epoch-offset form is used as a semantic representation here, without implying that any system would have to implement the TS data type in that way. Systems that do not need to compute distances between points in time will not need any other representation than a calendar expression literal.

type PointInTime alias TS extends QTY {
            PQ  offset;
            CS  calendar;
            INT precision;
            PQ  timezone;
            BL  equals(TS x);
            TS  plus(PQ x);
            PQ  minus(TS x);
  literal   ST;
  type      PQ  diff;
};
    

Definition:      The elapsed time since any constant epoch, measured as a physical quantity in the dimension of time (i.e., comparable to one second.)

invariant(TS x) where x.nonNull {
  x.offset.compares(1 s);
};
      

It is not necessary for this specification to define a canonical epoch; the semantics is the same for any epoch, as long as the epoch is constant.

NOTE: the offset property may be treated as a purely semantic property that is not represented in any way other than the calendar literal expression. However, an ITS may just as well choose to define a constant epoch and represent point-in-time values as elapsed time offsets relative to that epoch. However, an ITS using an epoch-offset representation would still need to communicate the calendar code and the precision of a calendar representation once other calendars are supported.

Two point-in-time values are equal if and only if their offsets (relative to the same epoch) are equal.

invariant(TS x, y) where x.nonNull.and(y.nonNull) {
  x.equals(y).equals(x.offset.equals(y.offset));
};
      

Definition:      A code specifying the calendar used in the literal representation of this point in time.⁴⁴

The purpose of this property is mainly to faithfully convey what has been entered or seen by a user in a system originating such a point-in-time value. The calendar property also advises any system rendering a point-in-time value into a literal form of which calendar to use. However, this is only advice; any system that renders point-in-time values to users may choose to use the calendar and literal form demanded by its users rather than the calendar mentioned in the calendar property. Hence, the calendar property is not constant in communication between systems, the calendar is not part of the equality test.

For the purpose of defining the relationship between calendar expression and epoch/offset form, two private data types, Calendar (CAL) and CalendarCycle (CLCY,) are defined. These calendar data types exist only for defining this specification. These private data types may not be used at all outside this specification.

Definition:      The number of significant digits of the calendar expression representation.

Precision is formally defined based on the TS.literal

The precision attribute is only the precision of a decimal digit representation, not the accuracy of the point in time value.

The purpose of the precision property for the point in time data type is to faithfully capture the whole information presented to humans in a calendar expression. The number of digits shown conveys information about the uncertainty (i.e., precision and accuracy) of a measured point in time.

NOTE: the precision of the representation is independent from uncertainty (precision accuracy) of a measurement result. If the uncertainty of a measurement result is important, one should specify uncertain values as PPD

The precision property is dependent on the calendar. A given precision value relative to one calendar does not mean the same in another calendar with different periods.

For example "20000403" has 8 significant digits in the representation, but the uncertainty of the value may be in any digit shown or not shown, i.e., the uncertainty may be to the day, to the week, or to the hour. Note that external representations should adjust their representational precision with the uncertainty of the value. However, since the precision in the digit string depends on the calendar and is granular to the calendar periods, uncertainty may not fall into that grid (e.g., 2000040317 is an adequate representation for the value between 2000040305 and 2000040405.)

NOTE: For a character based Implementation Technology the ITS need not represent the precision as an explicit attribute if point in time values are represented as literal calendar expressions. A point in time representation must not produce more or less significant digits than were originally in that value. Conformance can be tested through round-trip encoding - decoding - encoding.

Definition:      The difference between the local time in that time zone and Universal Coordinated Time (UTC, formerly called Greenwich Mean Time, GMT). The time zone is a physical quantity in the dimension of time (i.e., comparable to one second.) A zero time zone value specifies UTC. The time zone value does not permit conclusions about the geographical longitude or a conventional time zone name.

For example, 200005121800-0500 may be eastern standard time (EST) in Indianapolis, IN, or central daylight savings time (CDT) in Decatur, IL. Furthermore in other countries having other latitude the time zones may be named differently.

invariant(TS x, y) where x.nonNull.and(y.nonNull) {
  x.timezone.compares(1 s);
};
      

When the time zone is NULL (unknown), "local time" is assumed. However, "local time" is always local to some place, and without knowledge of that place, the time zone is unknown. Hence, a local time cannot be converted into UTC. The time zone should be specified for all point in time values in order to avoid a significant loss of precision when points in time are compared. The difference of two local times where the locality is unknown has an error of ±12 hours.

In administrative data context, some time values do not carry a time zone. For a date of birth in administrative data, for example, it would be incorrect to specify a time zone, since this may effectively change the date of birth when converted into other time zones. For such administrative data the time zone is NULL (not applicable.)

Definition:      A point in time plus an elapsed time (i.e., physical quantity in the dimension of time) is a point in time.

invariant(TS x, PQ t)
    where x.nonNull.and(t.compares(1 s)) {
  x.plus(t).offset.equals(x.offset.plus(t));
};
      

Definition:      The difference between two points in time is an elapsed time.

invariant(TS x) where x.nonNull {
  x.minus(y).offset.equals(x.offset.plus(y.offset.negated));
};
      

Point-in-time literals are simple calendar expressions, as defined by the calendar definition table. By default, the western (Gregorian) calendar shall be used (Table 37).

For the default Gregorian calendar the calendar expression literals of this specification conform to the constrained ISO 8601 that is defined in ISO 8824 (ASN.1) under clause 32 (generalized time) and to the HL7 version 2 TS data format.

Calendar expression literals are sequences of integer numbers ordered according to the "Counter/ord." column of Table 37. Periods with lower order numbers stand to the left of periods with higher order numbers. Periods with no assigned order number cannot occur in the calendar expression for points in time.

The "Counter/digits" column of Table 37 specifies the exact number of digits for the counter number for any period.

Thus, Table 37 specifies that western calendar expressions begin with the 4-digit year (beginning counting at zero); followed by the 2-digit month of the year (beginning counting at one); followed by the 2-digit day of the month (beginning with one); followed by the 2-digit hour of the day (beginning with zero); and so forth. For example, "200004010315" is a valid expression for April 1, 2000, 3:15 am.

A calendar expression can be of variable precision, omitting parts from the right.

For example, "20000401" is precise only to the day of the month.

The least defined calendar period may be written as a real number, with the number of integer digits specified, followed by the decimal point and any number of fractional digits.

For example, "20000401031520.34" means April 1, 2000, 3:15 and 20.34 seconds.

When other calendars will be used in the future, a prefix "GREG:" can be placed before the western (Gregorian) calendar expression to disambiguate from other calendars. Each calendar shall have its own prefix. However, the western calendar is the default if no prefix is present.

In the modern Gregorian calendars (and all calendars where time of day is based on UTC,) the calendar expression may contain a time zone suffix. The time zone suffix begins with a plus (+) or minus (() followed by digits for the hour and minute cycles. UTC is designated as offset "+00" or "-00"; the ISO 8601 and ISO 8824 suffix "Z" for UTC is not permitted.

TS.literal ST {
  TS : cal timestamp($1)              { $.equals($2); }
     | timestamp(GREG)                { $.equals($1); };

  TS timestamp(Calendar C)
  : cycles(C.head, C.epoch) zone(C)   { $.equals($1.minus($2)); }
                                        $.timezone.equals($2); }
  | cycles(C.head, C.epoch)           { $.equals($1);
                                        $.timezone.unknown; };
  Calendar cal
  : /[a-zA-Z_][a-zA-Z0-9_]*:/         { $.equals($1); };
  TS cycles(CalendarCycle c, TS t)
  : cycle(c, t) cycles(c.next, $1)    { $.equals($2); }
  | cycle(c, t) "." REAL.fractional   { $.equals(c.sum($1, $3));
                                        $.precision.equals(
                                          t.precision.plus($3.precision)); }
  | cycle(c, t)                       { $.equals($1); };
  TS cycle(CalendarCycle c, TS t)
  : /[0-9]{c.ndigits}/                { $.equals(c.sum(t, $1));
                                        $.precision.equals(
                                          t.precision.plus(c.ndigits)); };
  PQ zone(Calendar C)
  : "+" cycles(C.zonehead, C.epoch)   { $.equals($2.minus(C.epoch)); }
  | "-" cycles(C.zonehead, C.epoch)   { $.equals(C.epoch.minus($2)); };
}
      

Definition:      A calendar is a concept of measuring time in various cycles. Such cycles are years, months, days, hours, minutes, seconds, and weeks. Some of these cycles are synchronized and some are not (e.g., weeks and months are not synchronized.)

After "rolling the time axis" into these cycles (See ) a calendar expresses a point in time as a sequence of integer counts of cycles, e.g., for year, month, day, hour, etc. The calendar is rooted in some conventional start point, called the "epoch."

Calendar is defined as a set of calendar cycles, and has a name and a code. The head of the Calendar is the largest CalendarCycle appearing right most in the calendar expression. The epoch is the beginning of that calendar, i.e., the point in time where all calendar cycles are zero.

private type Calendar alias CAL extends SET<CLCY>  {
  CV   name;
  CLCY head;
  TS   epoch;
};

invariant(CAL c) where c.nonNull {
  c.name.nonNull;
  c.contains(c.head);
};
      

The calendar definition can be shown as in Table 37 for the modern Gregorian calendar. The calendar definition table lists a calendar cycle in each row. The calendar units are dependent on each other and defined in the value column. The sequence column shows the relationship through the next property. The other columns are as in the formal calendar cycle definition.⁴⁵

Definition:      A calendar cycle defines one group of decimal digits in the calendar expression. Examples for calendar cycles are year, month, day, hour, minute, second, and week.

A calendar cycle has a name and two codes, a one-letter code and a two-letter code. The property ndigits is the number of decimal digits occupied in the calendar expression. The property start specifies where counting starts (i.e., at 0 or 1.) The next property is the next lower cycle in the order of the calendar expression. The max(t) property is the maximum number of cycles at time t (max depends on the time t to account for leap years and leap seconds.) The property value(t) is the integer number of cycles shown in the calendar expression of time t. The property sum(t, n) is the sum of n calendar cycles added to the time t.

private type CalendarCycle alias CALCY extends ANY {
  CE    name;
  INT   ndigits;
  INT   start;
  CALCY next;
  INT   max(TS);
  TS    sum(TS t, REAL r);
  INT   value(TS t);
};

invariant(CALCY c) where c.nonNull {
  c.name.nonNull;
  c.start.equals(0).or(c.start.equals(1));
  c.digits.greaterThan(0);
};
      

This section defines data types that can "collect" other data values, Set, Sequence, Bag and Interval.⁴⁶ These collection types are defined as generic (parameterized) types. The concept of generic types is described in (§ ).

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

template<ANY T>
type Set<T> alias SET<T> extends ANY {
            BL      contains(T element);
            BL      isEmpty;
            BL      nonEmpty;
            BL      contains(SET<T> subset);
            INT     cardinality;
            SET<T>  union(SET<T> otherset);
            SET<T>  except(T element);
            SET<T>  except(SET<T> otherset);
            SET<T>  intersection(SET<T> otherset);
  literal   ST;
  promotion SET<T>  (T x);
            IVL<T>  hull;
};
    

Definition:      A relation of the set with its elements, true if the given value is an element of the set.

This is the primitive semantic property of a set, based on which all other properties are defined.

A set may only contain distinct non-NULL elements. Exceptional values (NULL-values) cannot be elements of a set.

invariant(SET<T> s, T n) where s.nonNull.and(n.isNull) {
  s.contains(n).not;
};
        

Definition:      The relation between a set and its subsets, where each element in the subset is also an element of the superset.

invariant(SET<T> superset, subset) 
    where superset.nonNull.and(subset.nonNull)
  superset.contains(subset).equals(
         forall(T element) where subset.contains(element) {
	   superset.contains(element);      
	 });
};
      

This implies that the empty set is a subset of every set including itself.

Definition:      A predicate indicating that this set contains elements.

invariant(SET<T> set) where set.nonNull {
  set.nonEmpty.equals(exists(T element) { set.contains(element); });
};
      

Definition:      A predicate indicating that this set has no elements (negation of the SET.nonEmpty. The empty set is a proper set value, not an exceptional (NULL) value.

invariant(SET<T> set) where set.nonNull {
  set.isEmpty.equals(nonEmpty.not);
};
      

Definition:      The cardinality of a set is the number of distinct elements in the set.

invariant(SET<T> set) where set.nonNull {
  exists(T element) where set.contains(element) {
    set.cardinality.equals(set.except(element).cardinality.successor);
  };
};
      

The cardinality definition is not sufficient since it doesn't converge for uncountably infinite sets (REAL, PQ, etc.) and it doesn't terminate for infinite sets. In addition, the definition of integer number type in this specification is incomplete for these cases, as it doesn't account for infinities. Finally the cardinality value is an example where it would be necessary to distinguish the cardinality ℵ₀ (aleph₀) of countably infinite sets (e.g., INT) from ℵ₁ (aleph₁), the cardinality of uncountable sets (e.g., REAL, PQ).

Definition:      A union of two sets (component sets) is a set where each of the union's elements also is an element of either one component set.

invariant(SET<T> x, y, z)
    where x.nonNull.and(y.nonNull).and(z.nonNull) {
  x.union(y).equals(z)
    .equals(forall(T e) {
              z.contains(e).equals(x.contains(e).or(y.contains(e)));
            });
};
      

Definition:      A union of a set and an element.

invariant(SET<T> set, singletonset, T element)
    where set.nonNull
     .and(element.nonNull)
     .and(singletonset.cardinality.isOne)
     .and(singletonset.contains(element)) {
  set.union(element).equals(set.union(singleton));
};
      

Definition:      The difference of this set and its subtracting set is the set that contains all elements of this set that are not elements of the subtracting set.

invariant(SET<T> x, y, z)
    where x.nonNull.and(y.nonNull).and(z.nonNull) {
  x.except(y).equals(z)
    .equals(forall(T e) {
              z.contains(e).equals(x.contains(e).and(y.contains(e).not));
            });
};
      

Definition:      The difference between this set and an element value is the set that contains all elements of this set except for the subtracting element value. If the element value is not contained in this set, the difference is equal to this set.

invariant(SET<T> x, z; T d)
    where z.nonNull.and(z.nonNull).and(d.nonNull) {
  x.except(d).equals(z)
    .equals(forall(T e) {
              z.contains(e).equals(x.contains(e).and(d.equals(e).not));
            });
};
      

Definition:      The intersection between two sets is a set containing all and only those elements that are contained in both of the operand sets.

invariant(SET<T> x, y, z)
    where x.nonNull.and(y.nonNull).and(z.nonNull) {
  x.intersection(y).equals(z)
    .equals(forall(T e) {
              z.contains(e).equals(x.contains(e).and(y.contains(e)));
            });
};
      

When the element type T has a literal form, the set of T elements has a literal form, wherein the elements of the set are enumerated within curly braces and separated by semicolon characters.

SET<T>.literal ST {
  SET<T> : "{" elements "}"   { $.equals($2); };
  SET<T> elements
        : elements ";" T      { $.except($2).equals($1); }
        | T                   { $.contains($1);
                                $.except($1).isEmpty; };
};
      

NOTE: this literal form for sets is only practical for relatively small enumerable sets; this does not mean, however, that all sets are relatively small enumerations of elements.

NOTE: a character-based ITS should choose a different literal form for sets if the Implementation Technology has a more native literal form for such collections.

A data value of type T can be promoted into a trivial set of T with that data value as its only element.

invariant(T x) {
  ((SET<T>)x).contains(x);
  ((SET<T>)x).except(x).isEmpty;
};
      

Sets of quantities may be totally ordered sets when there is an order relationship defined between any two elements in the set. Note that "ordered set" does not mean the same as Sequence (LIST). For example, the set {3; 2; 4; 88; 1} is an ordered set. The ordering of the elements in the set notation is still irrelevant, but elements can be compared to establish an order (1; 2; 4; 88).

Totally ordered sets have convex hull. A convex hull of a totally ordered set S is the smallest interval that is a superset of S. This concept is going to be important later on.

type Set<QTY> alias SET<QTY> {
            BL      totallyOrdered;
            IVL<T>  hull;
};

invariant(SET<QTY> s) where s.nonNull {
  s.totallyOrdered.equals(forall(QTY x, y) where s.contains(x)
                                             .and(s.contains(y)) {
                            x.compares(y); });
};

invariant(SET<QTY> s) where s.totallyOrdered {
  s.hull.contains(s);
  forall(T e) where s.contains(e) {
    s.hull.low.lessOrEqual(e);
    e.lessOrEqual(s.hull.high);
  };
};
      

Note that hull is defined if and only if the actual set is a totally ordered set. The data type of the elements itself need not be totally ordered. For example, the data type PQ is only partially ordered (since only quantities of the same kind can be compared), but a SET<PQ> may still be totally ordered (if it contains only comparable quantities.) For example, the convex hull of {4 s, 20 s, 55 s} is [4 s;55 s]; the convex hull of {"apples"; "oranges"; "bananas"} is undefined because the elements have no order relationship among them; and the convex hull of {2 m; 4 m; 8 s} is likewise undefined, because it is not totally ordered (seconds are not comparable with meters.)

Definition:      A value that contains other discrete values in a defined sequence.

template<ANY T>
type Sequence<T> alias LIST<T> extends ANY {
            T         head;
            LIST<T>   tail;
            BL        isEmpty;
            BL        nonEmpty;
	    T         item(INT index);
            BL        contains(T item);
            INT       length;
  literal   ST;
  promotion LIST<T>   (T x);
};
    

A sequence may contain NULL values as items.

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

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

Definition:      A predicate that is true if this sequence is an empty sequence, i.e., if it contains no items.

Notice the difference between empty-sequence and NULL: an empty sequence is a proper sequence, not a null-value.

invariant(LIST<T> x) where x.isEmpty {
  x.head.isNull;
  x.tail.isNull;
};
      

Notice that head and tail being NULL is only a necessary condition but not sufficient for determining an empty list, since a sequence may contain NULL-values as items, this condition can mean that this list has only a head item that happens to be NULL.

Definition:      A predicate that is true if this sequence is non-empty. Negation of LIST.isEmpty.

invariant(LIST<T> x) where x.nonNull {
  x.nonEmpty.equals(x.isEmpty.not);
};
      

Definition:      The item at the given sequential position (index) in the sequence. The index zero refers to the first element (head) of the sequence.

invariant(LIST<T> list; INT index) 
     where list.nonNull.and(index.nonNegative) {
  list.isEmpty
    .implies(list.item(index).isNull);
  list.nonEmpty.and(index.isZero)
    .implies(list.item(index).equals(list.head));
  list.nonEmpty.and(index.nonZero)
    .implies(list.item(index).equals(list.tail.item(index.predecessor)));
};
      

Definition:      A predicate that is true if this sequence contains the given item value.

invariant(LIST<T> list; T item) 
     where list.nonNull {
  list.isEmpty
    .implies(list.contains(item).not);
  list.nonEmpty.and(item.nonNull)
    .implies(list.contains(item).euqals(    list.head.equals(item)
                                       .or(list.tail.contains(item))));
  list.nonEmpty.and(item.isNull)
    .implies(list.contains(item).equals(    list.head.isNull
                                       .or(list.tail.contains(item)));
};
      

Definition:      The number of elements in the sequence. NULL elements are counted as regular sequence elements.

invariant(LIST<T> list) where x.nonNull {
  list.isEmpty.equals(list.length.isZero);
  list.nonEmpty.equals(list.length.equals(list.tail.length.successor));
};
      

Two lists are equal if and only if they are both empty, or if both their head and their tail are equal.

invariant(LIST<T> x, y) where x.nonNull.and(y.nonNull) {
  x.isEmpty.and(y.isEmpty)
     .implies(x.equals(y));
  x.nonEmpty.and(y.nonEmpty).and(x.head.nonNull)
     .implies(x.equals(y).equals(     x.head.equals(y.head)
                                 .and(x.tail.equals(y.tail))));
  x.nonEmpty.and(y.nonEmpty).and(x.head.isNull)
     .implies(x.equals(y).equals(     y.heas.isNull
                                 .and(x.tail.equals(y.tail))));
};
      

When the element type T has a literal form, the sequence LIST<T> has a literal form. List elements are enumerated, separated by semicolon, and enclosed in parentheses.

LIST<T>.literal ST {
  LIST<T>
  : "(" elements ")"        { $.equals($2); }
  | "(" ")"         { $.isEmpty; };
  LIST<T> elements
         : T ";" elements     { $.head.equals($1);
            $.tail.equals($3); }
         | T          { $.head.equals($1);
            $.tail.isEmpty; };
};
      

NOTE: a character-based ITS should choose a different literal form for sequences if the Implementation Technology has a more native literal form for such collections.

A data value of type T can be promoted into a trivial sequence of T with that data value as its only item.

invariant(T x) {
  ((LIST<T>)x).head.equals(x);
  ((LIST<T>)x).tail.isEmpty;
};
      

Specializations of Sequence (LIST)

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.

type GeneratedSequence<QTY T> alias GLIST restricts LIST<T> {
        T       head;
        T.diff  increment;
        INT     period;
	INT     denominator;
};
    

The item at a certain index in the list is calculated by performing an integer division on the index (i) with the GLIST.denominator (d) and then take that value's remainder with the GLIST.period (p). Multiply this value with the GLIST.increment (Δx) and add to the GLIST.head (x₀.)

x_i = x₀ + Δx × (i/d) mod p

invariant(GLIST<T> list, INT index) 
      where list.nonNull
       .and(index.nonNull)

  list.period.nonNull
    .implies(list.item(index)
              .equals(      list.head
                      .plus(item.dividedBy(list.increment.denominator)
                              .remainder(list.period))
                         .times(increment)));
  list.period.isNull
    .implies(list.item(index)
              .equals(      list.head
                      .plus(item.dividedBy(list.increment.denominator))
                         .times(increment)));
};
    

This is the start-value of the generated list.

Definition:      The difference between one value and its pervious 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.

Definition:      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.

The period allows to repeatedly sample the same sample space. The "waveform" of this periodic generator is always a "saw", just like the x-function of your oscilloscope.⁴⁷

Definition:      The 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 is 3.

The use of the denominator is to allow multiple generated sequences to periodically scan a multidimensional space. For example, an (abstract) TV screen uses 2 such generators for the columns and rows of pixels. For instance, if there are 200 scan lines and 320 raster colunmns, the column-generator would have denominator 1 and the line-generator would have denominator 320.

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

type SampledSequence<QTY T> alias SLIST extends LIST<T> {
  T         origin;
  T.diff    scale;
  LIST<INT> digits;
}
    

The item at a certain index (i) in the list is calculated by multiplying the item at the same index in the SLIST.digits sequence (d_i) with the SLIST.scale (s) and then add that value to the SLIST.origin (x_o ).

x_i = x_o + s × d_i

invariant(SLIST<T> list, INT index) 
    where list.nonNull.and(index.nonNegative)
{
  list.item(index).equals(      list.scale.times(digits.item(index))
                          .plus(list.origin));
}
    

Definition:      The origin of the list item value scale.

Definition:      A ratio quantity that is factored out of the digit sequence.

Definition:      A sequence of raw digits for the sample values. This is typically the raw output of an A/D converter.

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

template<ANY T>
type Bag<T> alias BAG<T> extends ANY {
            INT     contains(T kind);
            BL      isEmpty;
	    BL	    nonEmpty;
            BAG<T>  plus(BAG<T>);
            BAG<T>  minus(BAG<T>);
  promotion BAG<T>  (T x);
};
    

NOTE: a bag can be represented in two ways. Either as a simple enumeration of elements, including repeated elements, or as a "compressed bag" whereby the content of the bag is listed in pairs of element value and number. A histogram showing absolute frequencies is a bag represented in compressed form. The bag is therefore useful to communicate raw statistical data samples.

Definition:      The number of items in this bag with the given item value.

This is the primitive semantic property of a bag, based on which all other properties are defined.

invariant(BAG<T> bag; T item) 
     where bag.nonNull.and(item.nonNull) {
  bag.contains(item).nonNegative;
  bag.isEmpty.equals(bag.contains(item).isZero);
};
      

Definition:      A predicate indicating that this bag contains item.

invariant(BAG<T> bag) where bag.nonNull {
  bag.nonEmpty.equals(exists(T item) { bag.contains(item); });
};
      

Definition:      A predicate indicating that this bag has no elements (negation of the BAG.nonEmpty predicate. The empty bag is a proper set value, not an exceptional (NULL) value.

invariant(BAG<T> bag) where bag.nonNull {
  bag.isEmpty.equals(nonEmpty.not);
};
      

Definition:      A bag that contains all items of the operand bags, i.e. the number of items of each item value are added.

invariant(BAG<T> x, y, z) where x.nonNull.and(y.nonNull) {
  x.plus(y).equals(z)
    .equals(forall(T e) where e.nonNull {
              z.contains(e).equals(x.contains(e).plus(y.contains(e)));
            });
};
      

Definition:      A bags that contains all items of this bag (minuend) diminished by the items in the other bag (subtrahend). Bags cannot carry deficits. When the subtrahend contains more items of one value than the minuend, the difference contais zero items of that value.

invariant(BAG<T> x, y, z) where x.nonNull.and(y.nonNull) {
  x.minus(y).equals(z)
    .equals(forall(T e) where e.nonNull {
              exists(INT n)
                  where n.equals(x.contains(e).minus(y.contains(e)) {
                n.nonNegative.equals(z.contains(e));
                n.isNegative.equals(z.contains(e).isZero);
              };
            });
};
      

A data value of type T can be promoted into a trivial bag of type T with that data value as its only item.

invariant(T x) {
  ((BAG<T>)x).contains(x).equals(1);
  forall(T y) { ((BAG<T>)x).contains(y).implies(x.equals(y)) };
};
      

Definition:      A set of consecutive values of an ordered base data type.

Any ordered type can be the basis of an interval; 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 interval must be elements of a totally ordered subset of the partially ordered data type.

For example, physical quantities are considered ordered. However the ordering of physical quantities is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension.) While intervals between 2 and 4 meter exists, there is no interval between 2 meters and 4 seconds.

Intervals are sets and have all the properties of sets. However, union and differences of intervals may not be intervals any more, since the elements of these union and difference sets might not be contiguous. Intersections of intervals are always intervals.

template<QTY T>
type Interval<T> alias IVL<T> extends SET<T> {
            T       low;
            BL      lowClosed;
            T       high;
            BL      highClosed;
            T.diff  width;
            T       center;
            IVL<T>  hull(IVL<T> x);
  literal   ST;
  promotion IVL<T>  (T x);
  demotion  T;
};
    

Definition:      This is the low limit of the interval.

invariant(IVL<T> x; T e) where x.nonNull.and(x.contains(e)) {
  x.low.lessOrEqual(e);
};
      

Definition:      This is the high limit of the interval.

invariant(IVL<T> x; T e) where x.nonNull.and(x.contains(e)) {
  e.lessOrEqual(x.high);
};
      

Definition:      The difference between high and low boundary. The purpose of distinguishing a width property is to handle all cases of incomplete information symmetrically. In any interval representation only two of the three properties high, low, and width need to be stated and the third can be derived.

When both boundaries are known, width can be derived as high minus low. When one boundary and the width is known, the other boundary is also known. When no boundary is known, the width may still be known. For example, one knows that an activity takes about 30 minutes, but one may not yet know when that activity is started.

Note that the data type of the width is not always the same as for the boundaries. For ratio scale quantities (REAL, PQ, MO) it is the same. For difference scale quantities (e.g., TS) is is the data type of the difference (e.g., PQ in the dimension of time for TS). For discrete elements (INT) the width may be a REAL indicating the number of elements in the interval divided by 2.

invariant(IVL<T> x) {
  x.low.lessOrEqual(x.high);
  x.width.equals(x.high.minus(x.low));
};
      

Definition:      The arithmetic mean of the interval (low plus high divided by 2). The purpose of distinguishing the center as a semantic property is for conversions of intervals from and to point values.

Note that a center doesn't always exist for every interval. Notably intervals that are infinite on one side do not have a center. Also intervals of discrete base types with an even number of elements do not have a center. If an interval is unknown on one (or both) boundaries, the center can still be asserted. In fact, the main use case for the center is to be asserted when no boundary is known.

invariant(IVL<T> x) where x.low.nonNull.and(x.high.nonNull) {
  x.center.equals(x.low.plus(x.width.times(0.5))));
};
invariant(IVL<T> x) where x.low.isNull.or(x.high.isNull) {
  x.center.notApplicable;
};
      

Definition:      Specifies whether the low limit is included in the interval (interval is closed) or excluded from the interval (interval is open).

invariant(IVL<T> x) where x.nonNull {
  x.low.nonNull.implies(x.lowClosed.equals(x.contains(x.low)));
  x.low.isNull.implies(x.lowClosed.not);
};
      

Definition:      Specifies whether the high limit is included in the interval (interval is closed) or excluded from the interval (interval is open).

invariant(IVL<T> x) where x.nonNull {
  x.high.nonNull.implies(x.highClosed.equals(x.contains(x.high)));
  x.high.isNull.implies(x.highClosed.not);
};
      

The literal form for the interval data type is defined such that it is as intuitive to humans as possible. Five different forms are defined:⁴⁸

1. the interval form using square brackets, e.g., "[3.5; 5.5[";



2. the dash-form, e.g., "3.5-5.5";



3. the "comparator" form, using relational operator symbols, e.g., "<5.5";



4. the center-width form, e.g., "4.5[2.0[".



5. the width-only form using square brackets, e.g., "[2.0[".

IVL<T>.literal ST {
  IVL<T> range
  : interval                { $.equals($1); }
  | dash                    { $.equals($1); }
  | comparator              { $.equals($1); }
  | center_width            { $.equals($1); }
  | width                   { $.equals($1); };

  IVL<T> interval
  : open T ";" T close;     { $.low.equals($2);
                              $.high.equals($4);
                              $.lowClosed.equals($1);
                              $.highClosed.equals($5); };
  BL open : "["             { $.equals(true); }
          | "]"             { $.equals(false); };
  BL close : "]"            { $.equals(true); }
           | "["            { $.equals(false); };
  IVL<T> width
  : open T.diff close       { $.width.equals($2);
                              $.lowClosed.equals($1);
                              $.highClosed.equals($3); };
  IVL<T> center_width
  : T width                 { $.center.equals($1);
                              $.width.equals($2.width);
                              $.lowClosed.equals($2.lowClosed);
                              $.highClosed.equals($2.highClosed); };
  IVL<T> dash : T "-" T;    { $.low.equals($2);
                              $.high.equals($4);
                              $.lowClosed.equals(true);
                              $.highClosed.equals(true); };
  IVL<TS> comparator
  : "<"  T                  { $.high.equals(T);
                              $.high.closed(false);
                              $.low.negativelyInfinite; }
  | ">"  T                  { $.low.equals(T);
                              $.low.closed(false);
                              $.high.positivelyInfinite; }
  | "<=" T                  { $.high.equals(T);
                              $.high.closed(true);
                              $.low.negativelyInfinite; }
  | ">=" T                  { $.low.equals(T);
                              $.low.closed(true);
                            $.high.positivelyInfinite; };
};
      

A quantity of type T can be promoted into a trivial interval of T where low and high boundaries are equal and boundaries closed.

invariant(T x) {
  ((IVL<T>)x).low.equals(x);
  ((IVL<T>)x).high.equals(x);
  ((IVL<T>)x).highClosed;
  ((IVL<T>)x).lowClosed;
};
      

An interval of T can be demoted to a simple quantity of type T that is representative for the whole interval. If both boundaries are finite, this is the IVL.center. If one boundary is infinite, the representative value is the other boundary. If both boundaries are infinite, the conversion to a point value is not applicable.

invariant(IVL<T> x) where x.nonNull {
  x.low.nonNull.and(x.high.nonNull).implies(((T)x).equals(x.center));
  x.high.nonNull.and(x.low.isNull).implies(((T)x).equals(x.high));
  x.low.nonNull.and(x.high.isNull).implies(((T)x).equals(x.low));
  x.low.isNull.and(x.high.isNull).implies(((T)x).notApplicable);
};