|
|
| (101 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.jpg]]
| |
| − | | |
| − | ==== 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 use of all 3 attributes on ANY are controlled by flags in the modelling process. They are defined on ANY, but may only be used when they have not been constrained by the use of OCL or schematron statements in the XUM\’s that make the modelling flags explicit.
| |
| − | | |
| − | | |
| − | '''Attribute 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.
| |
| − | | |
| − | '''Attribute 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
| |
| − | | |
| − | '''Attribute history : HXIT''': Allows the changes to an individual attribute or
| |
| − | 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
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | == OLD SOURCE ==
| |
| − | | |
| − | =Conformance=
| |
| − | | |
| − | Applications are conformant to this specification if the XML instances if they ….. (produce instances that pass the schema validation). Also have to be conformant to the abstract data specification?
| |
| − | | |
| − | | |
| − | =Implementation Considerations=
| |
| − | Instances that comply completely with the schemas or models may still not be fully conformant with HL7 V3. The UML ITS may not enforce all the known rules in either the UML or XML Schema representations.
| |
| − | | |
| − | | |
| − | ==Representing Domains and Valuesets as Enumerations==
| |
| − | | |
| − | A subset of HL7 V3 valuesets are represented as simple UML or XML Schema enumerations. The valuesets or domains have been chosen based on their use in contexts where simple enumerations, without a nullFlavor feature, are appropriate representations of the abstract concepts. This is generally confined to some of the domains in the datatypes and the structural domains such as classCode, moodCode, etc.
| |
| − | | |
| − | Both UML and XML Schema support simple lists of enumerations, and this is how these value sets have been represented. However the HL7 value sets are poly-hierarchical terminologies, and any conceptual analysis, including equality testing, should be performed in consideration of the full meaning of the terms as defined in the V3 Vocabulary definitions.
| |
| − | | |
| − | ==Data type Specialisation==
| |
| − | | |
| − | This specification allows specialisation within the datatypes according to normal object orientated rules. If class B has class A as a generalisation, then class B may always be used in place of class A. However HL7 makes strict rules about which specialisations may be made at run time, and implementations must not try to represent data that is in violation of existing HL7 rules.
| |
| − | | |
| − | ==Data type Localisation==
| |
| − | | |
| − | | |
| − | | |
| − | =Enumerations=
| |
| − | | |
| − | ==NullFlavor ==
| |
| − | Valueset "NullFlavor" oid: 2.16.840.1.113883.6.9
| |
| − | | |
| − | {|
| |
| − | |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)
| |
| − | |-
| |
| − | |NAV||temporarily unavailable||Information is not available at this time but it is expected that it will be available later
| |
| − | |-
| |
| − | |NASK||not asked||This information has not been sought (e.g., patient was not asked)
| |
| − | |-
| |
| − | |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.Note: 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
| |
| − | |-
| |
| − | |NA||not applicable||No proper value is applicable in this context (e.g., last menstrual period for a male)
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | Some of the Abstract data types have been handled differently in this ITS. This table summarizes these null flavours
| |
| − | | |
| − | {|
| |
| − | |OTH||OTH is explicitly modelled on CD and derived data types now
| |
| − | |-
| |
| − | |PINF, NINF||These concepts do not arise in clinical medicine & health administration. They were mostly included in order to model intervals. Here, intervals are modelled differently and NINF and PINF are not defined. This may be revised if use cases are presented
| |
| − | |-
| |
| − | |QS, TRC||These are modelled directly as a feature of PQ
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==UpdateMode==
| |
| − | Valueset "UpdateMode" oid: 2.16.840.1.113883.5.57
| |
| − | | |
| − | {|
| |
| − | |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)
| |
| − | |-
| |
| − | |R||Replace||The item existed previously and has (or is to be) revised.
| |
| − | |-
| |
| − | |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.)
| |
| − | |-
| |
| − | |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.
| |
| − | |-
| |
| − | |U||Unknown||It\’s not specified whether the item was (or is to be) added, revised, or not changed
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==CompressionAlgorithm==
| |
| − | Valueset "CompressionAlgorithm" OID: 2.16.840.1.113883.11.10620
| |
| − | | |
| − | {|
| |
| − | |DF ||deflate ||The deflate compressed data format as specified in RFC 1951 \[http://www.ietf.org/rfc/rfc1951.txt\]
| |
| − | |-
| |
| − | |GZ ||gzip ||A compressed data format that is compatible with the widely used GZIP utility as specified in RFC 1952 \[http://www.ietf.org/rfc/rfc1952.txt\] (uses the deflate algorithm).
| |
| − | |-
| |
| − | |ZL ||zlib ||A compressed data format that also uses the deflate algorithm. Specified as RFC 1950 \[http://www.ietf.org/rfc/rfc1952.txt\]
| |
| − | |-
| |
| − | |Z ||compress ||Original UNIX compress algorithm and file format using the LZC algorithm (a variant of LZW). Patent encumbered and less efficient than deflate
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==IntegrityCheckAlgorithm==
| |
| − | Valueset "IntegrityCheckAlgorithm" OID: 2.16.840.1.113883
| |
| − | | |
| − | {|
| |
| − | |SHA1||secure hash algorithm - 1||This algorithm is defined in FIPS PUB 180-1: Secure Hash Standard. As of April 17, 1995
| |
| − | |-
| |
| − | |SHA256||secure hash algorithm - 256||secure hash algorithm - 256 This algorithm is defined in FIPS PUB 180-2: Secure Hash Standard
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ==IdentifierUse==
| |
| − | Valueset "IdentifierUse" OID: tba
| |
| − | | |
| − | {|
| |
| − | |Issued||||
| |
| − | |-
| |
| − | |Verified||||
| |
| − | |-
| |
| − | |Used||||
| |
| − | |-
| |
| − | |NonPlayer||||
| |
| − | |-
| |
| − | |RealWorld||||
| |
| − | |-
| |
| − | |Record||||
| |
| − | |-
| |
| − | |Version||||
| |
| − | |-
| |
| − | |View||||
| |
| − | |-
| |
| − | |Reference||||
| |
| − | |-
| |
| − | |Definitional||||
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==TelecommunicationAddressUse==
| |
| − | Valueset "TelecommunicationAddressUse" OID: 2.16.840.1.113883.5.1011
| |
| − | | |
| − | {|
| |
| − | |H||home address||A communication address at a home, attempted contacts for business purposes might intrude privacy and chances are one will contact family or other household members instead of the person one wishes to call. Typically used with urgent cases, or if no other contacts are available.
| |
| − | |-
| |
| − | |HP||primary home||The primary home, to reach a person after business hours
| |
| − | |-
| |
| − | |HV||vacation home||A vacation home, to reach a person while on vacation
| |
| − | |-
| |
| − | |WP||work place||An office address. First choice for business related contacts during business hours
| |
| − | |-
| |
| − | |DIR||Direct||Indicates a work place address or telecommunication address that reaches the individual or organization directly without intermediaries. For phones, often referred to as a \’private line\’
| |
| − | |-
| |
| − | |PUB||Public||Indicates a work place address or telecommunication address that is a \’standard\’ address which may reach a reception service, mail-room, or other intermediary prior to the target entity
| |
| − | |-
| |
| − | |BAD||bad address||A flag indicating that the address is bad, in fact, useless
| |
| − | |-
| |
| − | |TMP||temporary address||A temporary address, may be good for visit or mailing. Note that an address history can provide more detailed information
| |
| − | |-
| |
| − | |AS||answering service||An automated answering machine used for less urgent cases and if the main purpose of contact is to leave a message or access an automated announcement.
| |
| − | |-
| |
| − | |EC||emergency contact||A contact specifically designated to be used for emergencies. This is the first choice in emergencies, independent of any other use codes
| |
| − | |-
| |
| − | |MC||mobile contact||A telecommunication device that moves and stays with its owner. May have characteristics of all other use codes, suitable for urgent matters, not the first choice for routine business
| |
| − | |-
| |
| − | |PG||pager||A paging device suitable to solicit a callback or to leave a very short message
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==AddressPartType==
| |
| − | Valueset "AddressPartType" OID: 2.16.840.1.113883.5.16
| |
| − | | |
| − | {|
| |
| − | |ADL||additional locator||This can be a unit designator, such as apartment number, suite number, or floor. There may be several unit designators in an address (e.g., "3rd floor, Appt. 342"). This can also be a designator pointing away from the location, rather than specifying a smaller location within some larger one (e.g., Dutch "t.o." means "opposite to" for house boats located across the street facing houses).
| |
| − | |-
| |
| − | |UNID||unit identifier||The number or name of a specific unit contained within a building or complex, as assigned by that building or complex.
| |
| − | |-
| |
| − | |UNIT||unit designator||Indicates the type of specific unit contained within a building or complex. E.g. Appartment, Floor
| |
| − | |-
| |
| − | |DAL||delivery address line||A delivery address line is frequently used instead of breaking out delivery mode, delivery installation, etc. An address generally has only a delivery address line or a street address line, but not both.
| |
| − | |-
| |
| − | |DINST||delivery installation type||Indicates the type of delivery installation (the facility to which the mail will be delivered prior to final shipping via the delivery mode.) Example: post office, letter carrier depot, community mail center, station, etc.
| |
| − | |-
| |
| − | |DINSTA||delivery installation area||The location of the delivery installation, usually a town or city, and is only required if the area is different from the municipality. Area to which mail delivery service is provided from any postal facility or service such as an individual letter carrier, rural route, or postal route.
| |
| − | |-
| |
| − | |DINSTQ||delivery installation qualifier||A number, letter or name identifying a delivery installation. E.g., for Station A, the delivery installation qualifier would be \’A\’.
| |
| − | |-
| |
| − | |DMOD||delivery mode||Indicates the type of service offered, method of delivery. For example: post office box, rural route, general delivery, etc.
| |
| − | |-
| |
| − | |DMODID||delivery mode identifier||Represents the routing information such as a letter carrier route number. It is the identifying number of the designator (the box number or rural route number).
| |
| − | |-
| |
| − | |SAL||street address line||
| |
| − | |-
| |
| − | |BNR||building number||The number of a building, house or lot alongside the street. Also known as "primary street number". This does not number the street but rather the building.
| |
| − | | |
| − | |-
| |
| − | |BNN||building number numeric||The numeric portion of a building number
| |
| − | |-
| |
| − | |BNS||building number suffix||Any alphabetic character, fraction or other text that may appear after the numeric portion of a building number
| |
| − | |-
| |
| − | |STR||street name||
| |
| − | |-
| |
| − | |STB||street name base||The base name of a roadway or artery recognized by a municipality (excluding street type and direction)
| |
| − | |-
| |
| − | |STTYP||street type||The designation given to the street. (e.g. Street, Avenue, Crescent, etc.)
| |
| − | |-
| |
| − | |DIR||direction||Direction (e.g., N, S, W, E)
| |
| − | |-
| |
| − | |AR||care of ||The name of the party who will take receipt at the specified address, and will take on responsibility for ensuring delivery to the target recipient
| |
| − | |-
| |
| − | |CEN||census tract||A geographic sub-unit delineated for demographic purposes
| |
| − | |-
| |
| − | |CNT||country||Country
| |
| − | |-
| |
| − | |CPA||county or parish||A sub-unit of a state or province. (49 of the United States of America use the term "county;" Louisiana uses the term "parish".)
| |
| − | |-
| |
| − | |CTY||municipality||The name of the city, town, village, or other community or delivery center
| |
| − | |-
| |
| − | |DEL||delimiter||Delimiters are printed without framing white space. If no value component is provided, the delimiter appears as a line break.
| |
| − | |-
| |
| − | |POB||post box||A numbered box located in a post station
| |
| − | |-
| |
| − | |PRE||precinct||A subsection of a municipality
| |
| − | |-
| |
| − | |STA||state or province||A sub-unit of a country with limited sovereignty in a federally organized country.
| |
| − | |-
| |
| − | |ZIP||postal code||A postal code designating a region defined by the postal service.
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==PostalAddressUse==
| |
| − | Valueset "PostalAddressUse" OID: 2.16.840.1.113883.5.1012
| |
| − | | |
| − | {|
| |
| − | |H||home address||A communication address at a home, attempted contacts for business purposes might intrude privacy and chances are one will contact family or other household members instead of the person one wishes to call. Typically used with urgent cases, or if no other contacts are available.
| |
| − | |-
| |
| − | |HP||primary home||The primary home, to reach a person after business hours
| |
| − | |-
| |
| − | |HV||vacation home||A vacation home, to reach a person while on vacation
| |
| − | |-
| |
| − | |WP||work place||An office address. First choice for business related contacts during business hours
| |
| − | |-
| |
| − | |DIR||Direct||Indicates a work place address or telecommunication address that reaches the individual or organization directly without intermediaries. For phones, often referred to as a \’private line\’
| |
| − | |-
| |
| − | |PUB||Public||Indicates a work place address or telecommunication address that is a \’standard\’ address which may reach a reception service, mail-room, or other intermediary prior to the target entity
| |
| − | |-
| |
| − | |BAD||bad address||A flag indicating that the address is bad, in fact, useless
| |
| − | |-
| |
| − | |TMP||temporary address||A temporary address, may be good for visit or mailing. Note that an address history can provide more detailed information.
| |
| − | Identifies the different representations of a name. The representation may affect how the name is used. (E.g. use of Ideographic for formal communications.)
| |
| − | |-
| |
| − | |ABC||Alphabetic||Alphabetic transcription of name (Japanese: romaji)
| |
| − | |-
| |
| − | |IDE||Ideographic||Ideographic representation of name (e.g., Japanese kanji, Chinese characters)
| |
| − | |-
| |
| − | |SYL||Syllabic||Syllabic transcription of name (e.g., Japanese kana, Korean hangul)
| |
| − | |-
| |
| − | |PHYS||physical visit address||Used primarily to visit an address.
| |
| − | |-
| |
| − | |PST||postal address||Used to send mail.
| |
| − | |-
| |
| − | |}
| |
| − |
| |
| − | | |
| − | | |
| − | ==EntityNamePartType==
| |
| − | Valueset "EntityNamePartType" OID: 2.16.840.1.113883.5.44
| |
| − | | |
| − | {|
| |
| − | |FAM||family||Family name, this is the name that links to the genealogy. In some cultures (e.g. Eritrea) the family name of a son is the first name of his father.
| |
| − | |-
| |
| − | |GIV||given||Given name (don\’t call it "first name" since this given names do not always come first)
| |
| − | |-
| |
| − | |PFX||prefix||A prefix has a strong association to the immediately following name part. A prefix has no implicit trailing white space (it has implicit leading white space though). Note that prefixes can be inverted
| |
| − | |-
| |
| − | |SFX||suffix||A suffix has a strong association to the immediately preceding name part. A prefix has no implicit leading white space (it has implicit trailing white space though). Suffices can not be inverted
| |
| − | |-
| |
| − | |DEL||delimiter||A delimiter has no meaning other than being literally printed in this name representation. A delimiter has no implicit leading and trailing white space.
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==EntityNamePartQualifier==
| |
| − | Valueset "EntityNamePartQualifier" OID: 2.16.840.1.113883.5.43
| |
| − | | |
| − | {|
| |
| − | |LS||Legal status||For organizations a suffix indicating the legal status, e.g., "Inc.", "Co.", "AG", "GmbH", "B.V." "S.A.", "Ltd." etc.
| |
| − | |-
| |
| − | |AC||academic||Indicates that a prefix like "Dr." or a suffix like "M.D." or "Ph.D." is an academic title
| |
| − | |-
| |
| − | |NB||nobility||In Europe and Asia, there are still people with nobility titles (aristocrats). German "von" is generally a nobility title, not a mere voorvoegsel. Others are "Earl of" or "His Majesty King of..." etc. Rarely used nowadays, but some systems do keep track of this
| |
| − | |-
| |
| − | |PR||professional||Primarily in the British Imperial culture people tend to have an abbreviation of their professional organization as part of their credential suffices
| |
| − | |-
| |
| − | |VV||voorvoegsel||A Dutch "voorvoegsel" is something like "van" or "de" that might have indicated nobility in the past but no longer so. Similar prefixes exist in other languages such as Spanish, French or Portugese
| |
| − | |-
| |
| − | |AD||adopted||The name the person was given at the time of adoption
| |
| − | |-
| |
| − | |BR||birth||A name that a person had shortly after being born. Usually for family names but may be used to mark given names at birth that may have changed later.
| |
| − | |-
| |
| − | |SP||spouse||The name assumed from the partner in a marital relationship (hence the "M"). Usually the spouse\’s family name. Note that no inference about gender can be made from the existence of spouse names.
| |
| − | |-
| |
| − | |CL||callme||A callme name is (usually a given name) that is preferred when a person is directly addressed
| |
| − | |-
| |
| − | |IN||initial||Indicates that a name part is just an initial. Initials do not imply a trailing period since this would not work with non-Latin scripts. Initials may consist of more than one letter, e.g., "Ph." could stand for "Philippe" or "Th." for "Thomas".
| |
| − | |-
| |
| − | |TITLE||title||Indicates that a prefix or a suffix is a title that applies to the whole name, not just the adjacent name part.
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==EntityNameUse==
| |
| − | Valueset "EntityNameUse" OID: 2.16.840.1.113883.5.45
| |
| − | | |
| − | {|
| |
| − | |C||License||As recorded on a license, record, certificate, etc. (only if different from legal name)
| |
| − | |-
| |
| − | |I||Indigenous/Tribal||e.g. Chief Red Cloud
| |
| − | |-
| |
| − | |L||Legal||Known as/conventional/the one you use
| |
| − | |-
| |
| − | |P||pseudonym||A self asserted name that the person is using or has used
| |
| − | |-
| |
| − | |A||Artist/Stage||Includes writer\’s pseudonym, stage name, etc
| |
| − | |-
| |
| − | |R||Religious||e.g. Sister Mary Francis, Brother John
| |
| − | |-
| |
| − | |SRCH||search ||A name intended for use in searching or matching.
| |
| − | |-
| |
| − | |PHON||phonetic||A name spelled phonetically
| |
| − | |-
| |
| − | |SNDX||Soundex||A name spelled according to the SoundEx algorithm
| |
| − | |-
| |
| − | |ABC||Alphabetic||Alphabetic transcription of name (Japanese: romaji)
| |
| − | |-
| |
| − | |SYL||Syllabic||Syllabic transcription of name (e.g., Japanese kana, Korean hangul)
| |
| − | |-
| |
| − | |IDE||Ideographic||Ideographic representation of name (e.g., Japanese kanji, Chinese characters)
| |
| − | |-
| |
| − | |}
| |
| − |
| |
| − | | |
| − | ==CalendarCycle==
| |
| − | Valueset "CalendarCycle" OID: ?
| |
| − | | |
| − | {|
| |
| − | |CY ||condition year ||
| |
| − | |-
| |
| − | |MY ||month of the year ||
| |
| − | |-
| |
| − | |CM ||month (continuous) ||
| |
| − | |-
| |
| − | |CW ||week (continuous) ||
| |
| − | |-
| |
| − | |WY ||week of the year||
| |
| − | |-
| |
| − | |DM ||day of the month||
| |
| − | |-
| |
| − | |CD ||day (continuous)||
| |
| − | |-
| |
| − | |DY ||day of the year ||
| |
| − | |-
| |
| − | |DW ||day of the week ||(begins with Monday)
| |
| − | |-
| |
| − | |HD ||hour of the day ||
| |
| − | |-
| |
| − | |CH ||hour (continuous) ||
| |
| − | |-
| |
| − | |NH ||minute of the hour ||
| |
| − | |-
| |
| − | |CN ||minute (continuous) ||
| |
| − | |-
| |
| − | |SN ||second of the minute||
| |
| − | |-
| |
| − | |CS ||second (continuous) ||
| |
| − | |-
| |
| − | |}
| |
| − |
| |
| − | | |
| − | ==TimingEvent==
| |
| − | Valueset "TimingEvent" OID: ?
| |
| − | | |
| − | {|
| |
| − | |AC ||AC ||before meal (from lat. ante cibus)||
| |
| − | |-
| |
| − | |ACD ||ACT ||before lunch (from lat. ante cibus diurnus)||
| |
| − | |-
| |
| − | |ACM ||ACM ||before breakfast (from lat. ante cibus matutinus)||
| |
| − | |-
| |
| − | |ACV ||ACV ||before dinner (from lat. ante cibus vespertinus)||
| |
| − | |-
| |
| − | |HS ||HS ||the hour of sleep||
| |
| − | |-
| |
| − | |IC ||IC ||between meals (from lat. inter cibus)||
| |
| − | |-
| |
| − | |ICD ||ICD ||between lunch and dinner||
| |
| − | |-
| |
| − | |ICM ||ICM ||between breakfast and lunch||
| |
| − | |-
| |
| − | |ICV ||ICV ||between dinner and the hour of sleep||
| |
| − | |-
| |
| − | |PC ||PC ||after meal (from lat. post cibus)||
| |
| − | |-
| |
| − | |PCD ||PCD ||after lunch (from lat. post cibus diurnus)||
| |
| − | |-
| |
| − | |PCM ||PCM ||after breakfast (from lat. post cibus matutinus)||
| |
| − | |-
| |
| − | |PCV ||PCV ||after dinner (from lat. post cibus vespertinus)||
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==EncodingType==
| |
| − | This is an ITS specific enumeration
| |
| − | | |
| − | {|
| |
| − | |RAW||Raw||Data is presented in it\’s raw form||
| |
| − | |-
| |
| − | |BASE64||Base 64||Data is encoded using the base 64 algorithm||
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | =Data Types - Summary=
| |
| − | | |
| − | | |
| − | ==Summary Diagram==
| |
| − | | |
| − |
| |
| − | | |
| − | =Simple Supporting Data Types=
| |
| − |
| |
| − |
| |
| − | | |
| − | | |
| − | ==Octet ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Definition: This is introduced solely to allow for a technically correct definition of Binary in the UML, as there is no appropriate type for this in the UML or the OCL kernel. This type has no other use, and would not normally be implemented.
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |Octet Value ||0 <= value < 256
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==Binary ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Definition: This is defined to allow rules to be made about binary content. The UML Kernel does not have a built in type for handling binary content, so the Binary stereotype should denote to code generation devices to map the Binary type to some suitable Binary type such as a buffer or a stream.
| |
| − | | |
| − | ===Attributes===
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details
| |
| − | |-
| |
| − | |Content||Sequence(Octet)||The actual content of the Binary||In order to make some invariants
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |binary cannot be empty||If the Binary exists, it must have at least one byte of content
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==Code==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Definition: A simple string that holds a coded value from a simple domain defined outside HL7.
| |
| − | | |
| − | | |
| − | ==Uid==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Definition: A string that represents an identifier. May be either an OID, a UUID, or a RUID.
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |Patterns ||The content must match one of the patterns for either OID, UUID, or RUID.
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ==Uri ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Definition: A Uri. Defined to assist code generation software which may have a special type for this concept.
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |Pattern ||Should be a valid URI (but the correct regex pattern is a little uncertain)
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | ''Note: The schemas and UML models use the pattern ''
| |
| − | ''((\[a-zA-Z\]\[0-9a-zA-Z+\-\.\]\*:)?/\{0,2\}\[0-9a-zA-Z;/?:@&=+$\.\-_!\~\*\’()%\]+)?(\#\[0-9a-zA-Z;/?:@&=+$\.\-_!\~\*\’()%\]+)?''
| |
| − | ''but this is known to not always be correct.''
| |
| − | | |
| − | | |
| − | = Basic Data Types =
| |
| − |
| |
| − | | |
| − | | |
| − | ==ANY (DataValue)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | 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.
| |
| − | | |
| − | OpenEHR: Direct equivalent of Data_Value
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |nullFlavor||NullFlavor||Indicates that a value is an exceptional value, or a NULL-value. A null value means that the information does not exist, is not available or cannot be expressed in the data type\’s normal value set. ||If a value is an exceptional value (NULL-value), this specifies in what way and why proper information is missing. Every data element has either a proper value or it is considered NULL. If (and only if) it is NULL, the NullFlavor provides more detail as to in what way or why no proper value is supplied. If nullFlavor itself is null, the value is not null and appropriate information as specified must be provided.||This is equivalent to ELEMENT.null_flavor. Where null flavors are used on locations other than ELEMENT, the attribute has no equivalent and must be dropped if data is being converted.
| |
| − | |-
| |
| − | |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||From the HDF Appendix A describing the updateMode functionality||No equivalent. If a V3 instance has any elements containing updateMode codes D (or U?), translation cannot proceed, otherwise the field should be ignored.
| |
| − | |-
| |
| − | |history||HXIT||Allows the changes to an individual attribute or association to be associated with the ControlAct that changed it. The ControlAct can be used to convey such information as event time, author, authoring organization, data-enterer, reason, and any other accountability information deemed to be important.||From the HDF Appendix A describing the Audit functionality||OpenEHR handles update history rather differently, and this information should not be mapped
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |No UpdateMode on Null||Update Mode is not allowed for null values.
| |
| − | |-
| |
| − | |No History on Null||History is not allowed for null values.
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | There is no discussion at the abstract level concerning the use of these attributes with null values. It is disallowed until use cases for it\’s support are accepted by HL7.
| |
| − | | |
| − | The use of all 3 attributes on ANY are controlled by flags in the modelling process. They are defined on ANY, but may only be used when they have not been constrained by the use of OCL or schematron statements in the XUM\’s that make the modelling flags explicit.
| |
| − | | |
| − | | |
| − | ==HXIT (History Item)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Definition: tags a time range to any data value of data type ANY. The time range is the time in which the information represented by the value is (was) valid.
| |
| − | | |
| − | In the abstract specification, this is a mix-in. However in the interests of implementation, this is treated as a property of ANY in this specification. Refer to discussion for ANY.
| |
| − |
| |
| − | OpenEHR: No Equivalent
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |validTime||IVL(TS)||The time interval during which the given information was, is, or is expected to be valid||||N/A
| |
| − | |-
| |
| − | |controlActIdRef||II||The identifier of the ControlAct associated with setting the datatype to its specified value.||By referencing a particular ControlAct, the property links to all of the information surrounding that ControlAct, such as who made the change, when it was made, why it was made, what system originated the change, etc||N/A
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |must have a valid time||The HXIT must have a valid time
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ==BL (Boolean) ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | 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.
| |
| − | | |
| − | 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
| |
| − | | |
| − | OpenEHR: Direct equivalent of DV_Boolean
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |value||Boolean||The value of the BL if non Null||Boolean is the UML Kernel Boolean type||DV_Boolean.value
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |No value if null||Either the BL has a value of a nullFlavor
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ==BN (Boolean Non Null) ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes BL
| |
| − | | |
| − | Definition: ''BN'' constrains the boolean type so that the value may not be NULL. This type is created for use within the data types specification where it is not appropriate for a null value to be used.
| |
| − | | |
| − | Since this is a private type to the data types specification and it is not used in this specification, there is no implementation for BN
| |
| − | | |
| − | | |
| − | =Text And Content Data Types=
| |
| − | | |
| − |
| |
| − | | |
| − | | |
| − | ==Content ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | | |
| − | Definition: Content is an abstract type introduced as a common type for the definition of language.
| |
| − | | |
| − | OpenEHR: No direct equivalent; implementing types will map to DV_MULTIMEDIA or DV_TEXT
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |language||Code||The human language of the content||Valid codes are taken from the Internet standard RFC 3066 \[http://www.ietf.org/rfc/rfc3066.txt\]. The HL7 OID for this domain is 2.16.840.1.113883.5.57||DV_ENCAPSULATED.language or DV_TEXT.language
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |no language if null||If the Content is null, no language can be specified
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==Data ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes Content
| |
| − | | |
| − | Definition: Data is an abstract type introduced as a common type for the definition of properties shared between ED and ED.thumbnail.
| |
| − | | |
| − | OpenEHR: No direct equivalent; implementing types will map to DV_MULTIMEDIA
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |value||Binary||The human language of the content||The Binary type should be mapped to an appropriate type for the platform||DV_MULTIMEDIA.data
| |
| − | |-
| |
| − | |charset||Code||For character-based encoding types, this property specifies the character set and character encoding used in the value that contains the content of the ED||The charset shall be identified by an Internet Assigned Numbers Authority (IANA) Charset Registration \[http://www.iana.org/assignments/character-sets\] in accordance with RFC 2978 \[http://www.ietf.org/rfc/rfc2978.txt\]. The charset property needs to be known where the data of the ED is character type data in any form. If the data is provided in-line, then the charset must be known. If the data is provided as a reference, and the access method does not provide the charset for the data, typically as a mime header, then the charset must be conveyed as part of the ED.
| |
| − | | |
| − | HL7 assigned OID: 2.16.840.1.113883.5.21||DV_ENCAPSULATED.charset
| |
| − | |-
| |
| − | |compression||Compression||Indicates whether the raw byte data is compressed, and what compression algorithm was used||||DV_MULTIMEDIA.compression_algorithm; openEHR other is equivalent to V3 nullfFlavor "other". FIX THIS
| |
| − | |-
| |
| − | |mediaType||Code||Identifies the type of the encapsulated data and identifies a method to interpret or render the data||The IANA defined domain of media types is established by the Internet standard RFC 2045 \[http://www.ietf.org/rfc/rfc2045.txt\] and 2046 \[http://www.ietf.org/rfc/rfc2046.txt\]. HL7 assigned OID: 2.16.840.1.113883.11.10620||DV_MULTIMEDIA.media_type
| |
| − | |-
| |
| − | |encoding||EncodingType||Identifies the encoding type used in the value content||The content in the value may be either base64Binary content (refer xsd schema), or it may be text||No equivalent; implementations may have to determine this value on the fly from examining the data
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |no data if null||No data can be provided if the value is null
| |
| − | |-
| |
| − | |no charset if null||No charset can be specified if the value is null
| |
| − | |-
| |
| − | |no compression if null||No compression can be specified if the value is null
| |
| − | |-
| |
| − | |No mediaType if null||No mediaType can be specified if the value is null.
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==ED (Encapsulated Data) ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes Data
| |
| − | | |
| − | 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.) 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.
| |
| − | | |
| − | | |
| − | OpenEHR: Equivalent to DV_MULTIMEDIA
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |reference||Ref||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||DV_MULTIMEDIA.uri. uri is a simple uri,so when converting data the use and useablePeriod should be dropped.
| |
| − | |-
| |
| − | |integrityCheck||Binary||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 Binary type should be mapped to an appropriate type for the platform||DV_MULTIMEDIA.
| |
| − | integrity_check
| |
| − | |-
| |
| − | |integrityCheckAlgorithm||IntegrityCheckAlgorithm||Specifies the algorithm used to compute the integrityCheck value||||DV_MULTIMEDIA.
| |
| − | integrity_check_algorithm
| |
| − | |-
| |
| − | |thumbnail||Data||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.||DV_MULTIMEDIA.
| |
| − | thumbnail. DV_MULTIMEDIA can contain recursive thumbnails, but this is a bad idea and not supported by the HL7 datatypes
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |no reference if null||No reference can be provided if the value is null
| |
| − | |-
| |
| − | |no integrityCheck if null||No integrityCheck can be provided if the value is null
| |
| − | |-
| |
| − | |no integrityCheckAlgorithm if null||No integrityCheckAlgorithm can be provided if the value is null
| |
| − | |-
| |
| − | |integrityCheckAlgorithm required||An integrityCheckAlgorithm must be provided if an integrityCheck is provided
| |
| − | |-
| |
| − | |no thumbnail if null||No thumbnail can be provided if the value is null
| |
| − | |-
| |
| − | |reference or data||Either reference or data must be provided if not null
| |
| − | |-
| |
| − | |thumbnail has data||The thumbnail must have data if it is not null
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==ST (Character String) ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes Content
| |
| − | | |
| − | 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.
| |
| − | | |
| − | | |
| − | OpenEHR: Equivalent to DV_TEXT
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |value||String||The actual content of the string||String values are always Unicode. Should map to a primitive type.||DV_TEXT.value
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |no value if null||No value can be provided if the ST is null
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==SC (Coded String) ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ST
| |
| − | | |
| − | Definition: A character string that optionally may have a code attached. The text must always be present if a code is present. The code is often a local code. SC is used in cases where coding is exceptional (e.g., user text messages are essentially text messages, and a printable message is the important content. Yet, sometimes messages come from a catalog of canned messages, which SC allows to reference.
| |
| − | | |
| − | | |
| − | OpenEHR: Equivalent to DV_CODED_TEXT
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |code||String||The plain code symbol defined by the code system.||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 codeSystem. 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).||DV_CODED_TEXT.
| |
| − | defining_code.code_string
| |
| − | |-
| |
| − | |codeSystem||Uid||Specifies the code system that defines the code||Code systems shall be referred to by a UID, which allows unambiguous reference to standard HL7 codes, other standard code systems, as well as local codes. HL7 shall assign a 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.
| |
| − | | |
| − | 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 codeSystem.
| |
| − | ||DV_CODED_TEXT. defining_code.terminologyId
| |
| − | |-
| |
| − | |codeSystemName||String||The common name of the coding system||The code system name has no computational value. The purpose of a code system name is to assist an unaided human interpreter of a code value to interpret codeSystem.||No equivalent
| |
| − | |-
| |
| − | |codeSystemVersion||String||If applicable, a version descriptor defined specifically for the given code system||||Embedded in DV_CODED_TEXT. defining_code.terminologyId
| |
| − | |-
| |
| − | |displayName||ST||A name or title for the code, under which the sending system shows the code value to its users||displayName 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 code.
| |
| − | | |
| − | NOTE: HL7 offers a "print name" in it\’s predefined vocabulary domains. These values are suitable for use in the displayName.
| |
| − | ||No equivalent
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |no code if no value||If there is a code, there must also be some content on the SC (and therefore the SC must not be null)
| |
| − | |-
| |
| − | |codeSystem required||A codesystem is required if a code is provided, or if the nullFlavor is OTH
| |
| − | |-
| |
| − | |codeSystemName only if codeSystem||A codeSystemName can only be provided if a codeSystem is provided
| |
| − | |-
| |
| − | |codeSystemVersion only if codeSystem||A codeSystemVersion can only be provided if a codeSystem is provided
| |
| − | |-
| |
| − | |displayName only if code||A displayName can only be provided if a code is provided
| |
| − | |-
| |
| − | |no updateMode or History||The displayname can\’t have any updateMode or History
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | =Coded Data Types=
| |
| − | | |
| − |
| |
| − | | |
| − | | |
| − | ==Term ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | | |
| − | Definition: Created in the ITS to capture the items shared between a CD and it\’s qualifiers
| |
| − | | |
| − | | |
| − | OpenEHR: No Equivalent. Concrete descendents will be equivalent to DV_CODED_TEXT
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |code||String||The plain code symbol defined by the code system.||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 codeSystem. 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).||DV_CODED_TEXT.
| |
| − | defining_code.code_string
| |
| − | |-
| |
| − | |codeSystem||Uid||Specifies the code system that defines the code||Code systems shall be referred to by a UID, which allows unambiguous reference to standard HL7 codes, other standard code systems, as well as local codes. HL7 shall assign a 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.
| |
| − | | |
| − | 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 codeSystem.
| |
| − | ||DV_CODED_TEXT. defining_code.terminologyId
| |
| − | |-
| |
| − | |codeSystemName||String||The common name of the coding system||The code system name has no computational value. The purpose of a code system name is to assist an unaided human interpreter of a code value to interpret codeSystem.||No equivalent
| |
| − | |-
| |
| − | |codeSystemVersion||String||If applicable, a version descriptor defined specifically for the given code system||||Embedded in DV_CODED_TEXT. defining_code.terminologyId
| |
| − | |-
| |
| − | |displayName||ST||A name or title for the code, under which the sending system shows the code value to its users||displayName 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 code.
| |
| − | | |
| − | NOTE: HL7 offers a "print name" in it\’s predefined vocabulary domains. These values are suitable for use in the displayName.
| |
| − | ||No equivalent
| |
| − | |-
| |
| − | |originalText||ED||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
| |
| − | | |
| − | NOTE: Although post-coding is often performed from free text information, such as documents, scanned images or dictation, multi-media data is explicitly not permitted as original text. Also, the original text property is not meant to be a link into the entire source document. The link between different artifacts of medical information (e.g., document and coded result) is outside the scope of this specification and is maintained elsewhere in the HL7 standards. The original text is an excerpt of the relevant information in the original sources, rather than a pointer or exact reproduction. Thus the original text is to be represented in plain text form.
| |
| − | | |
| − | ||DV_CODED_TEXT. value. Cannot be by reference, though DV_CODED_TEXT does support a URI. So you could put a thumbnail or some abstract representation in value and provide the URI of the originalText is by reference
| |
| − | |-
| |
| − | |qualifier||Sequence(CR)||Specifies additional codes that increase the specificity of the primary code||Qualifiers constrain the meaning of the primary code, but cannot negate it or change it\’s meaning to that of another value in the primary coding system.
| |
| − | | |
| − | Qualifiers can only be used according to well-defined rules of post-coordination. A value of type CD may only have qualifiers if it\’s 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||OpenEHR does not support qualification in the information model. You will need a terminology service to translate the code+qualifiers to a single code phrase.
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |null or code||A code must be provided if not null. If null, no code can be provided
| |
| − | |-
| |
| − | |codeSystem required||A codesystem is required if a code is provided
| |
| − | |-
| |
| − | |codeSystemName only if codeSystem||A codeSystemName can only be provided if a codeSystem is provided
| |
| − | |-
| |
| − | |codeSystemVersion only if codeSystem||A codeSystemVersion can only be provided if a codeSystem is provided
| |
| − | |-
| |
| − | |displayName only if code||A displayName can only be provided if a code is provided
| |
| − | |-
| |
| − | |originalText if OTH or coded||OriginalText can only be provided if not null or the null flavor is OTH
| |
| − | |-
| |
| − | |qualifiers only if code||Qualifiers can only be specified if a code is provided
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ===NullFlavor OTH===
| |
| − | | |
| − | The Abstract specification describes a NullFlavor of OTH. It notes, concerning CD:
| |
| − | | |
| − | Values of type CD may have a non-NULL original text property despite having a NULL code. Any CD value with code of NULL signifies a coding exception. In this case, originalText is a name or description of the concept that was not coded. Such exceptional CD values may also contain translations. Such translations directly encode the concept described in originalText.
| |
| − | | |
| − | In this ITS, there is no explicit representation of OTH. The NullFlavor OTH is implied if the Term has no nullFlavor, and there is no code. In such cases there must be an originalText value.
| |
| − | | |
| − | | |
| − | ==CD (Concept Descriptor) ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes Term
| |
| − | | |
| − | Definition: A CD represents any kind of concept usually by giving a code defined in a code system. A CD 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 CD 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 cases of an exceptional value, the CD need not contain a code but only the original text describing that concept.
| |
| − | | |
| − | OpenEHR: CD is generally equivalent to DV_CODED_TEXT. However there is some lack of clarity here. DV_TEXT may be closer in intent - it depends on context. But the default is DV_CODED_TEXT
| |
| − | | |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |translation||Sequence(CD)||A set of other concept descriptors that translate this concept descriptor into other code systems or into synonyms in the same code system||Each element of the translation set was translated from the first CD. 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.||DV_CODED_TEXT. mappings; note that the mapping facility is much reduced. You must drop inner translations (or flatten them) and the mappings have no facility for originalText or qualifiers (see comments for qualifiers). match should be ? unless specific information to the contrary exists. Purpose <to be clarified>
| |
| − | |-
| |
| − | |}
| |
| − |
| |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {| | |
| − | |translations only if code or OTH||translations can only be provided if not null or the null flavor is OTH
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==CR (Concept Role) ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Definition: A concept qualifier code with optionally named role. Both qualifier role and value codes must be defined by the coding system of the CD containing the concept qualifier. 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. CD 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.)
| |
| − | | |
| − | | |
| − | OpenEHR: No equivalent. Refer to comments for Term.qualifier
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |name||CV||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, name is "has-laterality".||If the parent CD.codeSystem allows postcoordination but no role names (e.g. SNOMED) then name can be NULL||N/A
| |
| − | |-
| |
| − | |value||Term||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, value is "left".||value is of type CD 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.
| |
| − | ||N/A
| |
| − | |-
| |
| − | |inverted||Boolean||Indicates if the sense of 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||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, since if it is NULL, the role cannot be interpreted.||N/A
| |
| − | |-
| |
| − | |}
| |
| − |
| |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |null or value||A value must be provided if the CR is not null, and cannot be provided if it is.
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==CE (Coded With Equivalents) ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes CD
| |
| − | | |
| − | Definition: Coded data that consists of a coded value and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes may exist.
| |
| − | | |
| − | OpenEHR: Has no particular equivalent to CE - use DV_CODED_TEXT. Restrictions to terminology features that may be used can be applied in the archetype
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |no qualifiers||No Qualifiers on a CE
| |
| − | |-
| |
| − | |no qualifiers on translations||The translations are not allowed to contain qualifiers. ''Note : This policy is under review''
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==CV (Coded Value) ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes CE
| |
| − | | |
| − | Definition: Coded data, specifying only a code, code system, and optionally display name and original text. Used only as the type of properties of other data types. CV 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
| |
| − | | |
| − | OpenEHR: Has no particular equivalent to CV - use DV_CODED_TEXT. Restrictions to terminology features that may be used can be applied in the archetype
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |no translations||No translations are allowed
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==CO (Coded Ordinal) ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes CV
| |
| − | | |
| − | Definition: Coded data, where the coding system from which the code comes is ordered. CO adds semantics related to ordering so that models that make use of such domains may introduce model elements that involve statements about the order of the terms in a domain.
| |
| − | | |
| − | OpenEHR: Has no particular equivalent to CO - use DV_CODED_TEXT. Note that this isn\’t equivalent to DV_ORDINAL in spite of some attractive similarities
| |
| − | | |
| − | | |
| − | ===Attributes & Invariants===
| |
| − | There is no extra information to implement for CO, so no new attributes or invariants.
| |
| − | | |
| − | | |
| − | ==CS (Coded Simple Value) ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes CV
| |
| − | | |
| − | Definition: Coded data in its simplest form, where only the code is not predetermined. The code system and code system version are fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set
| |
| − | | |
| − | CS can only be used for structural attributes with fixed HL7 values. In these cases this specification will define enumerations and use them directly. There is no need for a CS data type.
| |
| − | | |
| − | | |
| − | =Miscellaneous Data Types=
| |
| − |
| |
| − | | |
| − | | |
| − | ==II (Instance Identifier) ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | | |
| − | 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.
| |
| − | | |
| − | OpenEHR: Equivalent to DV_IDENTIFIER. DV_IDENTIFIER is specifically for real world identifiers, whereas II is for any kind of identifier. However there is no clear line of distinction between the two concepts, and it may be a matter of context whether an identifier is a real world identifier or not. All II\’s can be mapped to DV_IDENTIFIER, however a proper mapping between an HL7 model and an archetype may relocate some identifiers in II\’s into more infrastructural elements of the OpenEHR infrastructure.
| |
| − | | |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |root||Uid||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.
| |
| − | | |
| − | The root should not be supposed to carry semantic meaning – all it does is ensure global computational uniqueness.
| |
| − | | |
| − | This field can be either a UUID, an OID, or an RUID||Root and extension – if present – may be concatenated and placed in DV_IDENTIFIER.id
| |
| − | |-
| |
| − | |extension||String||A character string as a unique identifier within the scope of the identifier root||The root and extension scheme effectively means that the concatenation of root and extension must be a globally unique identifier for the item that this II value identifies.||Root and extension – if present – may be concatenated and placed in DV_IDENTIFIER.id
| |
| − | |-
| |
| − | |assigningAuthorityName||String||A human readable name or mnemonic for the assigning authority. The Assigning Authority Name has no computational value.||The purpose of a Assigning Authority Name is to assist an unaided human interpreter of an II value to interpret the authority. Note: no automated processing must depend on the assigning authority name to be present in any form||DV_IDENTIFIER.assigner
| |
| − | |-
| |
| − | |displayable||Boolean||Specifies if the identifier is intended for human display and data entry (displayable = true) as opposed to pure machine interoperation (displayable = false)||||No equivalent in OpenEHR; note that if displayable is false, then it probably isn\’t a real world identifier, and there might be some better place for it
| |
| − | |-
| |
| − | |use||Set(IdentifierUse)||Specifies the intent of the use of this II||||No equivalent in OpenEHR. For further review in OpenEHR and HL7
| |
| − | |-
| |
| − | |}
| |
| − |
| |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |root is required||A root must be present if the II is not null, and must not be present if the II is null
| |
| − | |-
| |
| − | |no extension if no root||An extension cannot be present if root is not present
| |
| − | |-
| |
| − | |no assigningAuthorityName if no root||An assigningAuthorityName cannot be present if root is not present
| |
| − | |-
| |
| − | |no isDisplayable if null||IsDisplayable cannot be present if the II is null
| |
| − | |-
| |
| − | |no use if null||Use cannot be present if the II is null
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ==Ref ==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | | |
| − | Definition: Introduced to carry the TEL properties that are shared with ED.reference.
| |
| − | | |
| − | OpenEHR: Equivalent to DV_URI
| |
| − | | |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |details||Uri||A telecommunications address specified according to Internet standard RFC 2396 \[http://www.ietf.org/rfc/rfc2396.txt\].||The URI 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.||DV_URI.value
| |
| − | |-
| |
| − | |useablePeriod||GTS||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.||No equivalent in DV_URI – drop the value
| |
| − | | |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |no details if null||No details can be provided if the Ref is null
| |
| − | |-
| |
| − | |no useablePeriod if null||No useablePeriod can be provided if the Ref is null
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==TEL (Telecommunication Address)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes Ref
| |
| − | | |
| − | 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 in deciding which address to use for a given time and purpose.
| |
| − | | |
| − | OpenEHR: <todo> (archetype)
| |
| − | | |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |use||Set(TelecommunicationAddressUse)||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.
| |
| − | ||<todo>
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |no use if null||No use can be provided if the TEL is null
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | =Names and Addresses=
| |
| − | | |
| − |
| |
| − | | |
| − | | |
| − | ==ADXP (Address Part)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ST
| |
| − | | |
| − | 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)..
| |
| − | | |
| − | OpenEHR: <todo> (archetype)
| |
| − | | |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |type||AddressPartType||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||<todo>
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |no type if null||No type can be provided if the ADXP is null
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==AD (Address)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | | |
| − | Definition: Mailing and home or office addresses. 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.
| |
| − | | |
| − | OpenEHR: <todo> (archetype)
| |
| − | | |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |part||Sequence(ADXP)||A sequence of address parts, such as street or post office Box, city, postal code, country, etc||||<todo>
| |
| − | | |
| − | |-
| |
| − | |use||Set(PostalAddressUse)||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.||<todo>
| |
| − | | |
| − | |-
| |
| − | |useablePeriod||GTS||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 week or year||<todo>
| |
| − | | |
| − | |-
| |
| − | |isNotOrdered||Boolean||A boolean value specifying whether the order of the address parts is known or not||While the address parts are always a Sequence, the order in which they are presented may or may not be known. Where this matters, the isNotOrdered property can be used to convey this information||<todo>
| |
| − | | |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |null or parts||Either the AD is null or it has at least one part
| |
| − | |-
| |
| − | |no use if null||No use can be provided if the AD is null
| |
| − | |-
| |
| − | |no useablePeriod if null||No useablePeriod can be provided if the AD is null
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==ENXP (Entity Name Part)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ST
| |
| − | | |
| − | 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 qualifier code for more detail about the name part type. Typical name parts for person names are given names, and family names, titles, etc.
| |
| − | | |
| − | OpenEHR: <todo> (archetype)
| |
| − | | |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |type||EntityNamePartType||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 given name or which is a last name, or whether Rogan may be a title||<todo>
| |
| − | |-
| |
| − | |qualifier||Set(EntityNamePartQualifier)||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.||||<todo>
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |no type if null||No type can be provided if the ENXP is null
| |
| − | |-
| |
| − | |no qualifier if null||No qualifier can be provided if the ENXP is null
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==EN (Entity Name)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | | |
| − | Definition: A name for a person, organization, place or thing. 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.",
| |
| − | | |
| − | OpenEHR: <todo> (archetype)
| |
| − | | |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |part||Sequence(ENXP)||A sequence of name parts, such as given name or family name, prefix, suffix, etc.||||<todo>
| |
| − | | |
| − | |-
| |
| − | |use||Set(EntityNameUse)||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 name useful for any purpose, but a name with a specific use code would be preferred for that respective purpose.||<todo>
| |
| − | | |
| − | |-
| |
| − | |validTime||IVL(TS)||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||<todo>
| |
| − | | |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |null or parts||Either the EN is null or it has at least one part
| |
| − | |-
| |
| − | |no use if null||No use can be provided if the EN is null
| |
| − | |-
| |
| − | |no validTime if null||No validTime can be provided if the EN is null
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ==TN (Trivial Name)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes EN
| |
| − | | |
| − | Definition: A restriction of entity name that is effectively a simple string used for a simple name for things and places. Trivial names are typically used for places and things, such as Lake Erie or Washington-Reagan National Airport.
| |
| − | | |
| − | OpenEHR: <todo> (archetype)
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |only one part with no type||If the TN is not null, there can only be one part, and it can have no name
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==PN (Person Name)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes EN
| |
| − | | |
| − | Definition: : An EN used when the named Entity is a Person. A sequence of name parts, such as given name or family name, prefix, suffix, etc. A name part is 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.
| |
| − | | |
| − | | |
| − | OpenEHR: <todo> (archetype)
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |no parts are qualified by LS||None of the parts of a persons name can be qualified by the status LS
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==PN (Organization Name)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes EN
| |
| − | | |
| − | Definition: An EN used when the named Entity is an Organization.
| |
| − | | |
| − | | |
| − | OpenEHR: <todo> (archetype)
| |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |no parts are person types||None of the parts of a organisation name can be FAM or GIV
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | =Quantities=
| |
| − | | |
| − |
| |
| − | | |
| − | ==QTY (Quantity)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | | |
| − | 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.
| |
| − | | |
| − | Note that QTY is an abstract type, but is not implemented as an abstract type here because of the way that many of the following types are declared.
| |
| − | | |
| − | OpenEHR: Equivalent to DV_QUANTIFIED
| |
| − | | |
| − | | |
| − | ==INT (Integer)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes QTY
| |
| − | | |
| − | 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.
| |
| − | | |
| − | OpenEHR: Equivalent to DV_COUNT
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |value||Integer||The value of the INT if non Null||Integer is the UML Kernel Integer type. Note that the abstract specification imposes no limitations on the size of integer, but most implementations will map this to a 32 bit integer. ||DV_COUNT.magnitude
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |null or value||If the INT is null, no value can be present. If the INT is not null, a value must be present
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ==REAL (Real)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes QTY
| |
| − | | |
| − | 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.
| |
| − | | |
| − | OpenEHR: maps to DV_QUANTITY with units="1"
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |value||Real||The value of the REAL if non Null||Real is the UML Kernel Real type. Note that the abstract specification imposes no limitations on the size or precision of REAL, but most implementations will map this to a 8 byte Real. More is safer||DV_QUANTITY.magnitude
| |
| − | |-
| |
| − | |precision||Integer||The number of significant digits of the decimal representation.||0 (default value) means nothing is known about the precision||DV_QUANTITY.precision
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |null or value||If the REAL is null, no value can be present. If the REAL is not null, a value must be present
| |
| − | |-
| |
| − | |no precision if null||If the REAL is null, no precision can be present
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ==RTO (Ratio)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes QTY (does it need to? Why do we care in the ITS? We would only care if there was an attribute with type QTY. I\’ve never seen one. Can we specialise any not qty? This was intended to allow QTY to have extra data types, but it\’s not clear that this is useful anymore)
| |
| − | | |
| − | 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.
| |
| − | | |
| − | NOTE: 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. 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.
| |
| − | | |
| − | | |
| − | In the abstract model, RTO is a generic that takes 2 parameters. Many implementation technologies expect generics to be collections, or only have one parameter, so RTO is not implemented as a generic in this specification. Constraints at the point where the RTO is used will define which form of QTY are used
| |
| − | | |
| − | OpenEHR: maps to DV_QUANTITY_RATIO
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |numerator||QTY||The quantity that is being divided in the ratio.||No default value||DV_QUANTITY_RATIO. numerator
| |
| − | |-
| |
| − | |denominator||QTY||The quantity that divides the numerator in the ratio. ||The denominator must not be zero. No default value||DV_QUANTITY_RATIO. denominator
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |numerator and and denominator required||If the RTO is not null, both a numerator and a denominator are required
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==PQ (Physical Quantity)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes QTY
| |
| − | | |
| − | Definition: A dimensioned quantity expressing the result of measuring.
| |
| − | | |
| − | OpenEHR: maps to DV_QUANTITY
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |value||Real||The value of the PQ if non Null||Real is the UML Kernel Real type. Note that the abstract specification imposes no limitations on the size or precision of REAL, but most implementations will map this to a 8 byte Real. More is safer||DV_QUANTITY.magnitude
| |
| − | |-
| |
| − | |precision||Integer||The number of significant digits of the decimal representation.||0 (default value) means nothing is known about the precision||DV_QUANTITY.precision
| |
| − | |-
| |
| − | |Unit||Code||The unit of measure specified in the Unified Code for Units of Measure (UCUM) \[http://aurora.rg.iupui.edu/UCUM\]||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.||DV_QUANTITY.units
| |
| − | |-
| |
| − | |translation||Set(PQR)||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.||||no equivalent - drop translations
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |null or value||If the PQ is null, no value can be present. If the PQ is not null, a value must be present
| |
| − | |-
| |
| − | |no precision if null||If the PQ is null, no precision can be present
| |
| − | |-
| |
| − | |units required||If a value is present, units must be present
| |
| − | |-
| |
| − | |no translation if null||No translations are allowed if the PQ is null
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | == PQR (Physical Quantity Representation)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes CV
| |
| − | | |
| − | Definition: An extension of the coded value data type representing a physical quantity using a unit from any code system. Used to show alternative representation for a physical quantity.
| |
| − | | |
| − | The coded value represents the unit (usually in some other coding system than UCUM)
| |
| − | | |
| − | OpenEHR: No equivalent
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |value||REAL||The value of the PQ if non Null||||N/A
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |null or value||If the PQR is null, no value can be present. If the PQR is not null, a value must be present and not null (or PINF or NINF)
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − |
| |
| − | | |
| − | ==MO (Monetary Amount)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes QTY
| |
| − | | |
| − | Definition: An MO 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 PQ and MO, and the reason why currency units are not physical units
| |
| − | | |
| − | OpenEHR: No Equivalent for MO
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |value||Real||The value of the MO if non Null||MO values are usually precise to 0.01 (one cent, penny, paisa, etc.) For large amounts, it is important not to store MO values in floating point registers, since this may lose precision.
| |
| − | | |
| − | Is the type correct?||N/A
| |
| − | |-
| |
| − | |currency||Code||The currency unit as defined in ISO 4217||Valid codes are taken from ISO 4217. The HL7 OID for this domain is 2.16.840.1.113883.6.9||N/A
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |null or value||If the REAL is null, no value can be present. If the REAL is not null, a value must be present
| |
| − | |-
| |
| − | |currency required||If a value is present, a currency must be defined
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ==TS (Point in Time)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes QTY
| |
| − | | |
| − | Definition: A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression
| |
| − | | |
| − | OpenEHR: Equivalent to DV_DATE_TIME
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |value||String||The value of the TS if non Null||value is an ISO 8601 String, which is the abstract specification literal form||DV_DATE_TIME.value
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |null or value||If the TS is null, no value can be present. If the TS is not null, a value must be present
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | =Collections=
| |
| − | | |
| − |
| |
| − | | |
| − | | |
| − | ==SET (Set)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | Parameter: T : ANY
| |
| − | | |
| − | Definition: A collection that contains other distinct values in no particular order
| |
| − | | |
| − | OpenEHR: ITEM_LIST with a constraint that the values are distinct. ITEM_LIST does not have any equivalence for the ANY features, so these must be dropped or mapping must fail
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |item||Set(T)||The contents of the Set||Set(T) is the UML Kernel Set||ITEM_LIST.items
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |null or not empty||If the SET is null, no items can be contained in the Set. If the SET is not null, at least one item must be present
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==LIST (Sequence)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | Parameter: T : ANY
| |
| − | | |
| − | Definition: A collection that contains other discrete (but not necessarily distinct) values in a defined sequence
| |
| − | | |
| − | OpenEHR: ITEM_LIST. ITEM_LIST does not have any equivalence for the ANY features, so these must be dropped or mapping must fail
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |item||Sequence(T)||The contents of the Sequence||Sequence(T) is the UML Kernel Sequence||ITEM_LIST.items
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==GLIST (Generated Sequence)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | Parameter: T : QTY
| |
| − | | |
| − | 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
| |
| − | | |
| − | In the abstract specification, GLIST is a specialization of LIST. In this specification, GLIST is treated as a specification from which a list can be generated.
| |
| − | | |
| − | OpenEHR: No equivalent
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |head||T||The first item in this sequence||The head is a definitional property for the semantics of the sequence||N/A
| |
| − | |-
| |
| − | |increment||QTY||The difference between one value and its previous 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. QTY will be of type T.diff||N/A
| |
| − | |-
| |
| − | |denominator||Integer||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 denominator is 3.||N/A
| |
| − | |-
| |
| − | |period||Integer||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||N/A
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |required attributes||If the GLIST is not null, all attributes but the period are required
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==SLIST (Sampled Sequence)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | Parameter: T : QTY
| |
| − | | |
| − | Definition: A sequence of sampled values scaled and translated from a list of integer values. Used to specify sampled biosignals.
| |
| − | | |
| − | In the abstract specification, SLIST is a specialization of LIST. In this specification, SLIST is treated as a specification from which a list can be generated.
| |
| − | | |
| − | OpenEHR: No equivalent
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |Origin||T||The origin of the list item value scale||The physical quantity that a zero-digit in the sequence would represent||N/A
| |
| − | |-
| |
| − | |Scale||QTY||A ratio-scale quantity that is factored out of the digit sequence||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 QTY will be of type T.diff||N/A
| |
| − | |-
| |
| − | |Digits||Sequence(INT)||A sequence of raw digits for the sample values. This is typically the raw output of an A/D converter||May be null||N/A
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |required attributes||If the SLIST is not null, an origin and at least one digit is required
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==BAG (Bag)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | Parameter: T : ANY
| |
| − | | |
| − | Definition: An unordered collection of values, where each value can be contained more than once in the collection
| |
| − | | |
| − | OpenEHR: ITEM_LIST. ITEM_LIST does not have any equivalence for the ANY features, so these must be dropped or mapping must fail
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| | |- | | |- |
| − | |item||Bag(T)||The contents of the Bag||Bag(T) is the UML Kernel Bag||ITEM_LIST.items
| + | !Step |
| | + | !Expected Date |
| | + | !Details |
| | |- | | |- |
| − | |} | + | |Ballot Resolution & Editing||Feb 11||HL7 ballot resolution for both Abstract Datatypes and ISO datatypes, followed by editorial updates for these documents. |
| − | | |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |null or not empty||If the BAG is null, no items can be contained in the Set. If the BAG is not null, at least one item must be present | |
| | |- | | |- |
| − | |} | + | |Internal Review||Mid-Feb||Review by ISO & HL7 leads, ITS & WG co-chairs |
| − | | |
| − | | |
| − | ==IVL (Interval)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | Parameter: T : QTY
| |
| − | | |
| − | Definition: A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an IVL; 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 IVL must be elements of a totally ordered subset of the partially ordered data type.
| |
| − | | |
| − | | |
| − | In the abstract specification, IVL is a specialization of SET. In this specification, IVL is treated as a specification from which a set can be generated.
| |
| − | | |
| − | OpenEHR: Partially equivalent to DV_INTERVAL. DV_INTERVAL handles PINF and NINF null flavours directly in the properties lower_unbounded and upper_unbounded. Other nullFlavors must be dropped, but the bounds can still be null in the same way. If the IVL has only a width, it cannot be represented as a DV_INTERVAL, it is equivalent to a DV_DURATION
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |Low||T||This is the low limit||||Interval<T>.lower | |
| − | |- | |
| − | |lowClosed||Boolean||Specifies whether low is included in the IVL (is closed) or excluded from the IVL (is open).||||Interval<T>.lower_included
| |
| − | ''This is an inverse relationship''
| |
| | |- | | |- |
| − | |lowUnbounded||Boolean||There is no lower limit||in the abstract spec this is modelled as NINF||Interval<T>.lower_unbounded | + | |Abstract Datatypes ballot||Mar-Apr||Normal HL7 ballot |
| | |- | | |- |
| − | |High||T||This is the high limit||||Interval<T>.upper | + | |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. |
| | |- | | |- |
| − | |highClosed||Boolean||Specifies whether high is included in the IVL (is closed) or excluded from the IVL (is open).||||Interval<T>.upper_included | + | |CEN/ISO combined meeting||May 30||Time for consideration of datatypes at combined meeting; HL7 editor attends. |
| − | ''This is an inverse relationship''
| |
| | |- | | |- |
| − | |highUnbounded||Boolean||There is no upper limit||in the abstract spec this is modelled as PINF||Interval<T>.upper _unbounded | + | |ISO Datatypes ballot closes||Late Aug||Our provisional date is Aug 29. Editor will triage comments |
| | |- | | |- |
| − | |Width||QTY||The difference between high and low boundary||Width is used when the size of the Interval is known, but the actual start and end points are not known. | + | |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. |
| − | The type of width is T.diff||DV_DURATION
| |
| | |- | | |- |
| | + | |ISO ballot conclusion||Sept-Oct||ISO&CEN conclude their normal ballot processesat Istanbul meeting |
| | |} | | |} |
| | | | |
| − | | + | 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) |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |required attributes||Either the IVL is null, has a width, or has (low and/or high). Width and (low and/or high) cannot be mixed
| |
| − | |-
| |
| − | |Closed attributes only if not width||lowClosed and highClosed can only be used if low or high are used
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | ==HIST (History)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Definition: A set of data values that have a valid-time property and thus conform to the HXIT type. The history information is not limited to the past; expected future values can also appear
| |
| − | | |
| − | This type is defined in the abstract specification, but not needed in this specification. In the context of the UML ITS, a SET is used and ANY.history is allowed.
| |
| − |
| |
| − | OpenEHR: No Equivalent
| |
| − | | |
| − | | |
| − | =Timing Specifications=
| |
| − | | |
| − |
| |
| − | | |
| − | ==PIVL (PeriodicInterval)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | | |
| − | Definition: An interval of time that recurs periodically. PIVL has two properties, phase and period. phase specifies the "interval prototype" that is repeated every ..
| |
| − | | |
| − | In the abstract specification, PIVL is a specialization of SET<TS>. In this specification, PIVL is treated as a specification from which a set<TS> can be generated, and TS is treated as an implicit rather than explicit parameter
| |
| − | | |
| − | OpenEHR: The type DV_TIME_SPECIFICATION provides for the literal representation of this data
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |phase||TS||A prototype of the repeating interval, specifying the duration of each occurrence and anchors the PIVL sequence at a certain point in time||phase also marks the anchor point in time for the entire series of periodically recurring intervals. The recurrence of a PIVL has no beginning or ending, but is infinite in both future and past.||N/A
| |
| − | |-
| |
| − | |period||PQ||A time duration specifying as a reciprocal measure of the frequency at which the PIVL repeats||||N/A
| |
| − | |-
| |
| − | |alignment||CalendarCycle||Specifies if and how the repetitions are aligned to the cycles of the underlying calendar (e.g., to distinguish every 30 days from "the 5th of every month".)||A non-aligned PIVL recurs independently from the calendar. An aligned PIVL is synchronized with the calendar.||N/A
| |
| − | |-
| |
| − | |institutionSpecified||Boolean||Indicates whether the exact timing is up to the party executing the schedule ||e.g., to distinguish "every 8 hours" from "3 times a day".||N/A
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |required attributes||If PIVL is not null, phase and period must be specified
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ==EIVL (Event-Related Periodic Interval of Time)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | | |
| − | Definition: Specifies a periodic interval of time where the recurrence is based on activities of daily living or other important events that are time-related but not fully determined by time. For example, "one hour after breakfast" specifies the beginning of the interval at one hour after breakfast is finished. Breakfast is assumed to occur before lunch but is not determined to occur at any specific time.
| |
| − | | |
| − | In the abstract specification, EIVL is a specialization of SET<TS>. In this specification, EIVL is treated as a specification from which a set<TS> can be generated, and TS is treated as an implicit rather than explicit parameter
| |
| − | | |
| − | OpenEHR: The type DV_TIME_SPECIFICATION provides for the literal representation of this data
| |
| − | | |
| − | '''Attributes'''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |event||TimingEvent||A code for a common (periodical) activity of daily living based on which the event related periodic interval is specified||Such events qualify for being adopted in the domain of this attribute for which all of the following is true:
| |
| − | | |
| − | * the event commonly occurs on a regular basis
| |
| − | * the event is being used for timing activities, and
| |
| − | * the event is not entirely determined by time||N/A
| |
| − | |-
| |
| − | |offset||IVL(TS)||An interval of elapsed time (duration, not absolute point in time) that marks the offsets for the beginning, width and end of the EIVL measured from the time each such event actually occurred.||For example: if the specification is "one hour before breakfast for 10 minutes" IVL.low of offset is 1 h and the IVL.width of offset is 10 min.
| |
| − | ||N/A
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |required attributes||If EIVL is not null, event must be specified
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ==GTS (General Timing Specification)==
| |
| − | | |
| − | | |
| − | ===Information===
| |
| − | | |
| − | Specializes ANY
| |
| − | | |
| − | Definition: Specifies the timing of events and actions and the cyclical validity-patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing closer to the equator during winter and farther from the equator during summer) and office hours
| |
| − | | |
| − | In the abstract specification, GTS is a specialization of SET<TS>. In this specification, GTS is treated as a specification from which a set<TS> can be generated
| |
| − | | |
| − | OpenEHR: DV_TIME_SPECIFICATION is equivalent to GTS
| |
| − | | |
| − | ''''''Attributes''''''
| |
| − | | |
| − | {|
| |
| − | |Name||Type||Definition||Details||OpenEHR Mapping
| |
| − | |-
| |
| − | |literal||String||A literal representation of the GTS. ||Can be used instead of the structural alternatives offered by item, event and period||DV_TIME_SPECIFICATION.value
| |
| − | |-
| |
| − | |item||Sequence(IVL(TS))||A sequence of IVL<TS>||||Convert to literal form and use DV_TIME_SPECIFICATION.value
| |
| − | |-
| |
| − | |period||Sequence(PIVL)||A sequence of periodic intervals||||Convert to literal form and use DV_TIME_SPECIFICATION.value
| |
| − | |-
| |
| − | |event||Sequence(EIVL)||A sequence of event related intervals||||Convert to literal form and use DV_TIME_SPECIFICATION.value
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | | |
| − | | |
| − | ===Invariants===
| |
| − | | |
| − | {|
| |
| − | |required attributes||If GTS is not null, either a literal must be provided, or else some values must be found in item, period or event. Literal cannot be used at the same time as item, period or event.
| |
| − | If the GTS is null, the literal must be null, and item, period and event must all be empty.
| |
| − |
| |
| − | |-
| |
| − | |}
| |
