|
|
| (92 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| − | == Scope == | + | == Introduction == |
| | | | |
| − | This International Standard specifies the shared semantics for a | + | This is a project under the [[CEN ISO HL7 Joint Initiative]] |
| − | collection of healthcare related datatypes used in a number of health
| |
| − | related information standards. This standard declares these
| |
| − | datatypes using the terminology, notations and datatypes defined in
| |
| − | [[??|11404 rev 2003]]. In addition to defining the datatypes in
| |
| − | these terms, this standard also provides UML definitions of the
| |
| − | same datatypes using the terminology, notation and types defined
| |
| − | in [[??|UML 2.0]].
| |
| | | | |
| − | The purpose of this international standard is to provide an
| + | This is a project page for the ISO datatypes activity led by Grahame Greive for HL7, and Tom Marley for ISO. |
| − | agreed common semantic basis for exchanging basic concepts
| |
| − | that are commonly encountered in healthcare environments.
| |
| − | This standard is based on considerable input from HL7, CEN,
| |
| − | and past ISO work on healthcare datatypes. | |
| | | | |
| − | It is expected that other healthcare information standards
| + | The project is currently in reconciliation activity -- with the work being done on the XML SIG telcons [[XML SIG#Conference_Calls]]. |
| − | and specifications will define mappings for the datatypes
| |
| − | specified herein, though direct reference or a mixture of
| |
| − | direct reference and mappings may also be expected.
| |
| | | | |
| − | === What is a datatype? ===
| + | Note: this page was a full draft of the ISO datatypes document - this is now maintained in the hl7 svn repository, and published in the Ballot pack [http://www.hl7.org/v3ballot/html/infrastructure/its_r2/isodatatypes.htm]. |
| | | | |
| − | There is no clear definition of exactly what is a datatype and
| + | == Project Plan as of Jan 2008 == |
| − | where a more complex structure would be appropriate. Generally
| |
| − | the definitions of the scope of datatypes revolve around one
| |
| − | or more of the following three notions:
| |
| − | * The relationship between equality and identity
| |
| − | * Coherency of a single concept
| |
| | | | |
| − | Since of both of these concepts are inherently a matter of
| + | {| border="1" |
| − | perspective, the selection criteria for the datatypes defined
| |
| − | in this standard is based on the set that has emerged from the
| |
| − | debates held within the various stakeholder standards bodies
| |
| − | that define healthcare information standards. Since healthcare
| |
| − | information standards and specifications are expected to provide
| |
| − | mappings to this standard, the process has been deliberately
| |
| − | inclusive. These other standards may choose to represent these
| |
| − | datatypes with other more complex structures, but should explain
| |
| − | how to interconvert these structures with the datatypes defined
| |
| − | herein.
| |
| − | | |
| − | == Normative References ==
| |
| − | | |
| − | [[11404]]
| |
| − | | |
| − | base types to import from 11404
| |
| − | * Boolean
| |
| − | * State (for CS? - or should this be enumerated?)
| |
| − | * Character - as the basis for String?
| |
| − | * date-and-time? this is 8601 based, but a structured time. if 8601 based, could be used? but not for UML? the problem is that it is not well documented, and it appears that the right parts are not optional
| |
| − | * Integer
| |
| − | * Real
| |
| − | * Class (base for ANY)
| |
| − | * Set
| |
| − | * Bag
| |
| − | * Sequence
| |
| − | * characterstring - but it's not unicode
| |
| − | * Octet + OctetString
| |
| − | * objectidentifier
| |
| − | * Optional for nil?
| |
| − | | |
| − | Reference to UML 2
| |
| − | | |
| − | base types imported from UML 2:
| |
| − | * classifier
| |
| − | * Boolean
| |
| − | * Integer
| |
| − | * Real
| |
| − | * String
| |
| − | * Sequence
| |
| − | * Set
| |
| − | * Bag
| |
| − | | |
| − | == Terms and Definitions ==
| |
| − | | |
| − | '''Should not include anything in 11404 terms and definitions?'''
| |
| − | | |
| − | * HL7
| |
| − | * CEN
| |
| − | * UML required references
| |
| − | | |
| − | == Conformance ==
| |
| − | ??
| |
| − | | |
| − | == Conventions ==
| |
| − | | |
| − | == Datatypes ==
| |
| − | | |
| − | === Summary ===
| |
| − | | |
| − | Each datatype defined in this specification is defined in
| |
| − | two different ways. They are defined in terms of the datatype
| |
| − | specification language defined in ISO 11404. In addition, the
| |
| − | same datatype is defined in UML using primitive types taken
| |
| − | from the UML kernel package. The UML definition is provided to
| |
| − | foster software driven implementation of these datatypes.
| |
| − | | |
| − | [[Image:iso_datatypes_all.gif]]
| |
| − | | |
| − | This UML diagram includes all the types in a single package
| |
| − | for ease of reference. More detailed UML diagrams are
| |
| − | included with the the datatype definitions below.
| |
| − | | |
| − | === Template ===
| |
| − | | |
| − | This section lays out the template that should be generally followed for each type.
| |
| − | | |
| − | Group Name
| |
| − | | |
| − | UML diagram
| |
| − | | |
| − | then for each datatype:
| |
| − | | |
| − | Name
| |
| − | | |
| − | Definition(Intension)
| |
| − | | |
| − | Discussion of scope, usage ([+Extension])
| |
| − | | |
| − | Formal definition in 11404 language
| |
| − | | |
| − | Further discussion about why it is defined the way it is.
| |
| − | | |
| − | Properties
| |
| − | | |
| − | For each property
| |
| − | | |
| − | Name
| |
| − | | |
| − | Definition (+parameters if any)
| |
| − | | |
| − | Discussion of usage
| |
| − | | |
| − | === Basic Datatypes ===
| |
| − | | |
| − | Basic Datatypes that provide infrastructural support for specific datatypes that are defined in subsequent sections.
| |
| − | | |
| − | [[Image:iso_datatypes_basic.gif]]
| |
| − | | |
| − | ==== ANY ====
| |
| − | | |
| − | '''Definition''': Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every public concrete type is a specialization of this general abstract DataValue type.
| |
| − | | |
| − | '''Todo''': Formal definition in 11404 language
| |
| − | | |
| − | The appropriate use of all three of the attributes on ANY is intimately bound to the
| |
| − | implementation specification with which they are used. Generally the environment will
| |
| − | need to establish special ways to control their use.
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | '''nullFlavor : NullFlavor''': Indicates the reason that the value is unknown.
| |
| − | | |
| − | ANY is a nullable type; any instances of descendent types may also be null. Null is
| |
| − | a special value and implementations usually have special logic for handling
| |
| − | this. The nullFlavor attribute carries information describing why the value is null.
| |
| − | An instance of the type ANY with a nullFlavor of NI is semantically equivalent to
| |
| − | a null instance. If the nullFlavor of is not null, then all other attributes must
| |
| − | be null. If the nullFlavor is null, then some of the other properties may be constrained
| |
| − | to be not null; the invariants for the appropriate type specify the
| |
| − | non-null attributes in this case.
| |
| − | | |
| − | Possible Values for nullFlavor:
| |
| − | | |
| − | {| | |
| − | |NI||NoInformation||No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value
| |
| − | |-
| |
| − | | UNK||unknown||A proper value is applicable, but not known
| |
| − | |-
| |
| − | | ASKU||asked but unknown||Information was sought but not found (e.g., patient was asked but didn\’t know)
| |
| − | |-
| |
| − | | NASK||not asked||This information has not been sought (e.g., patient was not asked)
| |
| − | |-
| |
| − | | NAV||temporarily unavailable||Information is not available at this time but it is expected that it will be available later
| |
| | |- | | |- |
| − | | MSK||masked||There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.
| + | !Step |
| − | Warning: Using this null flavor does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
| + | !Expected Date |
| | + | !Details |
| | |- | | |- |
| − | | NA||not applicable||No proper value is applicable in this context (e.g., last menstrual period for a male) | + | |Ballot Resolution & Editing||Feb 11||HL7 ballot resolution for both Abstract Datatypes and ISO datatypes, followed by editorial updates for these documents. |
| | |- | | |- |
| − | |} | + | |Internal Review||Mid-Feb||Review by ISO & HL7 leads, ITS & WG co-chairs |
| − | | |
| − | '''updateMode : UpdateMode''': The principal purpose of UpdateMode is to allow a sending system to identify to a receiving system:
| |
| − | • the changes that have occurred in an object controlled by the sending system; or
| |
| − | • the changes that the sender desires to be made in an object controlled by the receiving system
| |
| − | Possible Values for UpdateMode:
| |
| − | {|
| |
| − | |A ||Add ||The item was (or is to be) added, having not been present immediately before. | |
| | |- | | |- |
| − | |D||Delete||The item was (or is to be) removed (sometimes referred to as deleted) | + | |Abstract Datatypes ballot||Mar-Apr||Normal HL7 ballot |
| | |- | | |- |
| − | |R||Replace||The item existed previously and has (or is to be) revised. | + | |ISO Datatypes ballot Opens||Late Mar||Our provisional date is Mar 29. ISO, CEN, and HL7 will all open and close their own ballots on the document the same day. |
| | |- | | |- |
| − | |AR||Add or Replace||The item was (or is to be) either added or replaced. (This option is included to support one specific case, discussed below. Its general use is discouraged, the preferred methodology is to use the combination of the individual Add and Replace values.) | + | |CEN/ISO combined meeting||May 30||Time for consideration of datatypes at combined meeting; HL7 editor attends. |
| | |- | | |- |
| − | |N||No Change||There was (or is to be) no change to the item.This is primarily used when this element has not changed, but other attributes in the instance have changed. | + | |ISO Datatypes ballot closes||Late Aug||Our provisional date is Aug 29. Editor will triage comments |
| | |- | | |- |
| − | |U||Unknown||It's not specified whether the item was (or is to be) added, revised, or not changed | + | |Joint Disposition Meeting||11&12 Sept||a satellite meeting of the HL7 Vancouver meeting - joint CEN/ISO/HL7 meeting. We encourage all interested parties to attend this meeting. At this meeting, we will resolve the ballot line items. |
| | |- | | |- |
| | + | |ISO ballot conclusion||Sept-Oct||ISO&CEN conclude their normal ballot processesat Istanbul meeting |
| | |} | | |} |
| | | | |
| − | '''history : HXIT''': Allows the changes to an individual attribute or
| + | Note: Feb 11 deadline has been missed by a few days. As of this comment, it should be Feb 16 ish. --[[User:GrahameGrieve|GrahameGrieve]] 00:26, 13 February 2008 (CST) |
| − | association to be associated with an identified event that changed it. The event
| |
| − | may convey such information as event time, author, authoring organization,
| |
| − | data-enterer, reason, and any other accountability information as described by the
| |
| − | environment in which the type is used.
| |
| − | | |
| − | | |
| − | '''Invariants'''
| |
| − | | |
| − | * Update Mode is not allowed for null values.
| |
| − | * History is not allowed for null values.
| |
| − | | |
| − | OCL for invariants:
| |
| − | | |
| − | def: let isNull : Boolean = nullFlavor.oclIsDefined
| |
| − | def: let isNotNull : Boolean = not isNull
| |
| − |
| |
| − | -- these are defined in order to help control updateMode and history
| |
| − | def: let noUpdate : Boolean = updateMode.oclIsUndefined
| |
| − | def: let noHistory : Boolean = history.oclIsUndefined
| |
| − | def: let noUpdateOrHistory : Boolean = noUpdate and noHistory
| |
| − |
| |
| − | -- these 2 assertions are uncharted waters. we disallow use of updateMode and
| |
| − | -- history with null until convincing use cases arise
| |
| − | inv "No UpdateMode on null": isNull implies updateMode.oclIsUndefined
| |
| − | inv "No History on null": isNull implies history.oclIsUndefined
| |
| − | | |
| − | | |
| − | ==== HXIT ====
| |
| − | | |
| − | Protected - not for use outside the datatypes in this specification
| |
| − | | |
| − | '''Definition''': Information about the history of this value: period of
| |
| − | validity and a reference to an identified event that established this value
| |
| − | as valid.
| |
| − | | |
| − | '''Todo''': Formal definition in 11404 language
| |
| − | | |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | '''validTime : IVL(TS)''': The time interval during which the given information was, is, or is expected to be valid.
| |
| − | | |
| − | '''controlActIdRef : II''': The identifier of the event associated with setting the datatype to its specified value. By referencing a particular event, the property links to all of the information surrounding that event, such as who made the change, when it was made, why it was made, what system originated the change, etc, as specified in the implementation specification.
| |
| − |
| |
| − | '''Invariants'''
| |
| − | | |
| − | * The HXIT must have a valid time if it is not null
| |
| − | * The II cannot have a history on an updateMode
| |
| − | | |
| − | OCL for invariants:
| |
| − | | |
| − | -- this constraint is not part of the abstract model. It may be relaxed
| |
| − | -- if a use case presents
| |
| − | inv "must have a valid time": validTime.oclIsDefined and validTime.isNotNull
| |
| − | inv "no updateMode or History": (validTime.oclIsUndefined or validTime.noUpdateOrHistory)
| |
| − | and (controlActIdRef.oclIsUndefined or controlActIdRef.noUpdateOrHistory)
| |
| − | | |
| − | | |
| − | ==== BL ====
| |
| − | | |
| − | Specializes ANY
| |
| − | | |
| − | '''Definition''': BL stands for the values of two-valued logic. A BL value can be either true or false, or, as any other value may be NULL.
| |
| − | | |
| − | '''Todo''': Formal definition in 11404 language
| |
| − | | |
| − | With any data value potentially being NULL, the two-valued logic is effectively extended to a three-valued logic as shown in the following truth tables:
| |
| − | {|
| |
| − | |'''NOT'''||''' '''||||'''AND'''||'''true'''||'''false'''||'''NULL'''||||'''OR'''||'''true'''||'''false'''||'''NULL'''
| |
| − | |-
| |
| − | |'''true'''||false||||'''true'''||true||false||NULL||||'''true'''||true||true||True
| |
| − | |-
| |
| − | |'''false'''||true||||'''false'''||false||false||false||||'''false'''||true||false||NULL
| |
| − | |-
| |
| − | |'''NULL'''||NULL||||'''NULL'''||NULL||false||NULL||||'''NULL'''||true||NULL||NULL
| |
| − | |-
| |
| − | |}
| |
| − | Where a boolean operation is performed upon 2 data types with different nullFlavors, the nullFlavor of the result is the first common ancestor of the 2 different nullFlavors, though conformant applications may also create a result that is any common ancestor (such as NI)
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | '''value: Boolean''': The value of the BL if it is non Null.
| |
| − | | |
| − | '''Invariants'''
| |
| − | | |
| − | * The BL must have a value if it is not null
| |
| − | | |
| − | OCL for invariants:
| |
| − | | |
| − | inv "no value if null": isNull implies value.oclIsUndefined
| |
| − | | |
| − | | |
| − | === Text And Content Data Types ===
| |
| − | | |
| − | Basic Datatypes that provide infrastructural support for specific datatypes that are defined in subsequent sections.
| |
| − | | |
| − | [[Image:iso_datatypes_text.gif]]
| |
