Product ITS DT

Product Brief - Data Types

back to Main_Page
back to Product_List

Product Name - Data Types - Abstract Specification

Standard Category

• Health Information Exchange Standards

Integration Paradigm

• Foundation

Type

Normative, ANSI Standard

Releases

ANSI/HL7 V3 DT, R1-2004; currently balloting HL7 V3 DT R2 - HL7 Version 3 Standard: Data Types - Abstract Specification, Release 2
Normative Ballot 4 - September 2009

Summary

Every data element has a data type. The data type defines the set of valid values that can be assigned to a data element and their meaning (semantics). Meaningful exchange of data requires that we know the definition of values so exchanged. This is true for complex "values" such as timing specifications as well as for simpler values such as character strings or integer numbers. An instance of a data type is a data value.

Description

This standard provides the semantic definitions for the data types used in the creation of HL7 V3 specifications. These "abstract" semantic definitions are also able to be used as constraints in the creation of implementation guides, and implementation technology specifications that enable actual exchange of data are based on these semantic definitions.

The data types defined in this specification are not intended to be implemented based on the details presented herein. For example, this specification does not differentiate between the information that should be represented in a payload and the information that should be derived from the payload. This document corresponds broadly to the RM-ODP informational view. The ISO data types specification is an ITS for these data types that corresponds to the RM-ODP computational view.

According to ISO 11404, a data type is "a set of distinct values, characterized by properties of those values and by operations on those values." A data type can be defined by intension or by extension, or by a combination of these approaches. Intensional definition specifies the properties that the set of valid values must have: e.g. a definition that stipulates that a "string" is "an ordered collection of legible characters from a defined character set." Extensional definition enumerates the values deemed valid: e.g. the assertion that the boolean type consists of the values "true" and "false". While extensional definitions are useful for coded attributes, almost all abstract data types are defined intensionally.

A semantic property of a data type is referred to by a name and can be evaluated for any value of data type. The value of a data value's property must itself be a value defined by a data type - no data value exists that cannot 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).

Business Case (Intended Use, Customers)

The audience for this document is anyone who uses HL7 V3 data types - both implementers and designers of HL7 specifications. For implementers, this document should be treated as secondary supplemental information to the ITS data types, which provide an basis for actual implementation of the data types.

Benefits

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".

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.

Resources

Work Groups

Implementable Technology Specifications

Education

• See more at http://www.hl7.org/implement/training.cfm

Relationship to/ Dependencies on, other standards

• RIM

Links to current projects in development

• Project Insight ID # 484, Health informatics - Harmonized data types for information interchange (ISO Ballot Project)
• Project Insight ID # 455 Complete Balloting of V3 Abstract Data Types R2, by Modeling and Methodology Work Group

Product Name - HL7 V3: Implementation Technology Specification - XML Data Types (and ISO Datatypes, R1)

Standard Category

• Health Information Exchange Standards

Integration Paradigm

• Foundation

Type

Normative, ANSI Standard

Topics

• ISO-Harmonized Data Types, Release 1;
• XML Implementation Technology Specification - Data Types

Releases

• ANSI/HL7 V3 XMLITSDT, R1-2004: HL7 Version 3 Standard: XML Implementation Technology Specification - Data Types, R1; 4/8/2004
• HL7 V3 ISO DT, R1-2009: HL7 Version 3 Standard: XML Implementation Technology Specification R2; ISO-Harmonized Data Types, Release 1

Summary

This standard provides a globally harmonized (ISO/CEN/HL7) set of representations for data used in the presentation and communication of health care information. This standardized set will be an internationally agreed upon, proper sub-set of data types currently adopted by national and trans-national health care standards development organizations. This document provides a UML and XML implementation of the datatypes, and is in effect Release 2 of the XML ITS datatypes. This document is shared and jointly balloted between HL7, CEN, and ISO.

Description

The communication of health information about individuals requires the accurate identification of specific entities and concepts, as well as the expression of complete, frequently complex semantic phrases. Experience has shown that representation of such data requires that a rich set of data types be built upon the primitive types normally specified for computer software. The set to be specified in this standard will provide the structures necessary to meet the basic requirements of health care information communication.

Benefits

The market for and the supply of healthcare software systems is global. There is an increasing demand to be able to communicate health care data between jurisdictions. Following requests from national health informatics programmes, the vendor community and, also, extensive discussion of previous ISO, HL7 and CEN work on data types, an advanced draft of a new International Standard has now been prepared. This standard will promote a common representation that meets these needs and is being advanced as common draft standard in all three communities. 1. updated datatypes for new requirements from HL7 2. simplified technical implementation path as a result of user feedback 3. shared content between HL7, CEN, and ISO.

Resources

Work Groups

Implementable Technology Specifications

Education

• See more at http://www.hl7.org/implement/training.cfm

Relationship to/ Dependencies on, other standards

• ISO 11404

Links to current projects in development

• Project Insight ID # 484, Health informatics - Harmonized data types for information interchange (ISO Ballot Project)

Product Name - HL7 V3: Implementation Technology Specification - UML Data Types

Standard Category

• Health Information Exchange Standards

Integration Paradigm

• Foundation

Type

Normative, ANSI Standard

Releases

• ANSI/HL7 V3 UMLITSDT, R1-2004: HL7 Version 3 Standard: UML Implementation Technology Specification - Data Types, Release 1; 4/23/2004

Summary

The Abstract Data Types specification includes a Unified Modeling Language (UML) diagram that presents the semantic declarations of these data types in a standard UML fashion.

This UML ITS implements the semantics of the Abstract Data Types specification using UML in such a way that HL7 data types are mapped into the core UML and OCL kernel data types where such mappings are appropriate. In addition, this representation uses only established object-orientated formalisms. Since this specification shows how to implement the HL7 data types using the UML core data types and methodology, this specification is an ITS for the data types in UML.

Description

The desired outcomes from this specification include:

• A formally correct UML declaration of the HL7 Data Types
• Enable the use of Computer-Aided Software Engineering (CASE) tools for model validation, code generation, instance validation, etc
• Enable these same outcomes for downstream HL7 UML artifacts such as the RIM and message structures.

Work Groups

Implementable Technology Specifications

Education

• See more at http://www.hl7.org/implement/training.cfm

Links to current projects in development

• None