This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Product DT"

From HL7Wiki
Jump to navigation Jump to search
(New page: =Product Brief - Data Types: Abstract Specification= __TOC__ back to Main_Page<br/>back to Product_List ==Product Name - Data Types - Abstract Specification == ===Standard Categor...)
 
Line 17: Line 17:
  
 
===Summary===
 
===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.  
+
Every attribute in the [[Product RIM|Reference Information Model]] (RIM) is has a data type. This specification defines the semantics of these data types.
  
 
===Description===
 
===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.  
+
The specification defines the semantics of the datatypes - that is, what they mean, how they behave, and the operations that can be performed on the data types. The data types are defined by a combination of UML diagrams, value tables, formal language statements, and extensive narrative that explains their meaning. The data types can be found throughout HL7 standards where ever the RIM is used. Additionally they may used in other contexts as well.  
  
−
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.
+
The specification is abstract - it is a statement of meaning - and the data types cannot be implemented directly based on the definitions found in this specification. Implementations are provided in [[Product_ITS_DT|the XML implementations] or in the ISO standard "Healthcare Data types" (ISO 21090) (still being finalised)
−
 
 
−
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)===
 
===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.
+
The primary intent of this document is internal to HL7 - to provide an enduring statement of the meaning of the data types that has no dependence on external factors that may change. For implementers of Hl7 standards, the document contains secondary supplemental information that further clarifies the use of the data type beyond that found in the implementations referred to above.
  
 
===Benefits===
 
===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".  
+
[[OMG|http://www.omg.org]]'s Model Driven Architecture (MDA) defines the concept of a Platform Independent Model (PIM), which has the advantage of being able to be implemented across multiple technologies without loss of meaning, thereby protecting the investment of the designer as technologies change. The abstract data types extend this notion in that they are independent of any other language or standard, and therefore their meaning is not changed as other languages, platforms and technologies gradually advance over time. In addition, by defining it's own framework for defining standards, the specification is able to make formal statements of meaning about things that would not otherwise be possible. This means that the fundamental HL7 definitions of the meaning of the data can be preserved and implemented in a variety of language and specification frameworks over time, such as UML, XML, ASN.1, where each include their own data types.
  
−
Why does HL7 need its own data type standard? Why can't HL7 simply adopt a standard defined by some other body?
+
The cost of these things is that it is not possible to implement the standard directly; for this reason HL7 additionally publishes implementation specifications for end-implementers to actually use.
  
−
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)===
  
−
===Implementations/ Case Studies (Actual Users)===
+
The data types are used everywhere any v3 specification is used.
−
* Every '''''Actual User''''' of another V3 Product - CDA, Messaging or Services
 
  
 
===Resources===
 
===Resources===
  
 
====Work Groups====
 
====Work Groups====
 +
 
[http://www.hl7.org/Special/committees/mnm/index.cfm Modeling and Methodology]
 
[http://www.hl7.org/Special/committees/mnm/index.cfm Modeling and Methodology]
  

Revision as of 12:43, 21 January 2010

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 attribute in the Reference Information Model (RIM) is has a data type. This specification defines the semantics of these data types.

Description

The specification defines the semantics of the datatypes - that is, what they mean, how they behave, and the operations that can be performed on the data types. The data types are defined by a combination of UML diagrams, value tables, formal language statements, and extensive narrative that explains their meaning. The data types can be found throughout HL7 standards where ever the RIM is used. Additionally they may used in other contexts as well.

The specification is abstract - it is a statement of meaning - and the data types cannot be implemented directly based on the definitions found in this specification. Implementations are provided in [[Product_ITS_DT|the XML implementations] or in the ISO standard "Healthcare Data types" (ISO 21090) (still being finalised)

Business Case (Intended Use, Customers)

The primary intent of this document is internal to HL7 - to provide an enduring statement of the meaning of the data types that has no dependence on external factors that may change. For implementers of Hl7 standards, the document contains secondary supplemental information that further clarifies the use of the data type beyond that found in the implementations referred to above.

Benefits

http://www.omg.org's Model Driven Architecture (MDA) defines the concept of a Platform Independent Model (PIM), which has the advantage of being able to be implemented across multiple technologies without loss of meaning, thereby protecting the investment of the designer as technologies change. The abstract data types extend this notion in that they are independent of any other language or standard, and therefore their meaning is not changed as other languages, platforms and technologies gradually advance over time. In addition, by defining it's own framework for defining standards, the specification is able to make formal statements of meaning about things that would not otherwise be possible. This means that the fundamental HL7 definitions of the meaning of the data can be preserved and implemented in a variety of language and specification frameworks over time, such as UML, XML, ASN.1, where each include their own data types.

The cost of these things is that it is not possible to implement the standard directly; for this reason HL7 additionally publishes implementation specifications for end-implementers to actually use.

Implementations/ Case Studies (Actual Users)

The data types are used everywhere any v3 specification is used.

Resources

Work Groups

Modeling and Methodology

Education

Presentations

Relationship to/ Dependencies on, other standards

Links to current projects in development

Retrieved from "https://wiki.hl7.org/w/index.php?title=Product_DT&oldid=31832"