Product DT

Product Brief - Data Types: Abstract Specification

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.

Implementations/ Case Studies (Actual Users)

• Every Actual User of another V3 Product - CDA, Messaging or Services

Resources

Work Groups

Modeling and Methodology

Education

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

Relationship to/ Dependencies on, other standards

• RIM
• Vocabulary

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