The harmonized datatypes ontology provides a semantic model representing the harmonized datatype definitions for exchanging basic concepts that are commonly encountered in healthcare environments in support of information exchange in the healthcare environment. It is derived from and largely conforms with the ISO 21090:2011 Health informatics - Harmonized data types for information interchange specification, which in turn is compliant with and uses the terminology, notations and datatypes defined in ISO/IEC 11404. The implementation of ISO 21090 included herein is an OWL 2 DL compliant representation of the datatypes defined in the ISO specification. This means that it is not a perfect match for the UML (Unified Modeling Language) representation given in the standard, as there is not a one-to-one alignment between UML and OWL. For details on mapping UML to OWL, please refer to the Object Management Group (OMG) specifications for (1) the Ontology Definition Metamode (ODM), available at https://www.omg.org/spec/ODM/, and (2) MOF to RDF Mapping (MOF2RDF), available at https://www.omg.org/spec/MOF2RDF/. As a consequence, this ontology is an indirectly conforming implementation that provides mappings to the XML Schema Datatypes that are supported in OWL 2 for some ISO 21090 datatypes, and encodes others in a manner that is OWL 2 DL compliant. References to ISO 11179 with respect to the representation of codes and code sets are faithful to the 3rd edition of 11179 as well as to revisions to that standard that are part of emerging work in the ISO JTC 1 SC32 WG2 working group to the degree possible. For more information on the ontologies on which this ontology depends, please refer to the Object Management Group (OMG) specifications for (1) the Commons Ontology Library (Commons) specification, available at https://www.omg.org/spec/COMMONS/, (2) the Languages, Countries and Codes (LCC) specification, available at https://www.omg.org/spec/LCC/, and (3) the Multiple Vocabulary Facility (MVF) specification, available at https://www.omg.org/spec/MVF/.
The IDMP MVP version of this ontology is incomplete, and covers only the parts of the ISO 21090 standard required to support the MVP use cases.
The https://spec.pistoiaalliance.org/idmp/ontology/ISO/ISO21090-HarmonizedDatatypes.rdf version of this ontology was augmented to include XP and ENXP datatypes, required to represent fragments of medicinal product names and to incorporate revisions to the Commons 1.2 ontologies.
The https://spec.pistoiaalliance.org/idmp/ontology/ISO/ISO21090-HarmonizedDatatypes.rdf version of this ontology was modified to clean up URIs that had an erroneous final slash.
The https://spec.pistoiaalliance.org/idmp/ontology/ISO/ISO21090-HarmonizedDatatypes.rdf version of this ontology was modified to incorporate the Multiple Vocabulary Facility (MVF) for consistent representation of controlled vocabularies and code systems, and to align representations of URI-related properties (IDMP-636).
The https://spec.pistoiaalliance.org/idmp/ontology/ISO/ISO21090-HarmonizedDatatypes.rdf version of this ontology was modified to make hasBooleanValue and hasIntegerValue non-functional properties.
The https://spec.pistoiaalliance.org/idmp/ontology/ISO/ISO21090-HarmonizedDatatypes.rdf version of this ontology was modified to make hasIntegerValue and hasLevelInHierarchy subproperties of hasNumericValue.
Copyright (c) 2022-2024 EDM Council, Inc.
Copyright (c) 2022-2024 Pistoia Alliance, Inc.
The harmonized datatypes ontology provides a set of codes for datatypes and classes used in other standards in the health informatics family of standards, including those published by HL7. These codes need to be referenced via an annotation in the context of the IDMP ontologies due to the fact that any other approach would result in punning.
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 3.4
managed collection of concept identifiers, usually codes, but sometimes more complex sets of rules and references
They are often described as collections of uniquely identifiable concepts with associated representations, designations, associations and meanings.
ISO 21090 does not explicitly define a datatype called CD.CodeSystem (or codeSystem, or codeSystem: Uid, depending on the reference), which is referenced in some of the IDMP standards. The relationship 'is member of' some code system, which is a property of every code element, corresponds to CD.CodeSystem, however, and, the UID/OID for the relevant system can be retrieved via SPARQL.
The restriction, isIdentifiedBy exactly 1 Identifier corresponds to the 'codeSystem : Uid' attribute given in ISO 21090. ISO 21090 requires the code system name to be associated with every code; in this ontology, the name is associated with the code system and a code is a member of that system, thus one can retrieve the code system name via SPARQL. The 'codeSystem : String' corresponds with the hasVersion property, and again can be retrieved for any code using SPARQL to query through to the definition of the code system of which it is a member. Both the name and version are inherited from CodeSet.
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.5.2.4.3
The purpose of a code system name is to assist an unaided human interpreter of a code value to understand which code system is referenced.
ISO 21090 does not explicitly define a datatype called CD.CodeSystemName (or codeSystemName), which is referenced in some of the IDMP standards. The relationship 'has name' some code system name, which is a property of every code set, corresponds to CD.CodeSystemName, however. This element can be retrieved by using SPARQL from any code to the code system of which it is a member.
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.5.2.4.10
code element that indicates a reason why a particular CD has been provided, either as the root concept or as one of the translations.
A code is deemed to be post-coded if the user does not assign the code when they first enter the data. codingRationale is not expected to act as a quality review marker on the quality of the coding or the translation processes.
A code is required when it is present in the instance to meet some constraints imposed on the instance by the context of use. Information Processing Entities shall not be required to mark a particular translation as required even though it is required by the context of use, but may do so. Information processing entities shall not reject instances because of the presence or absence of the codingRationale flag.
If populated, the value contained in this attribute shall be taken from this enumeration, composed from the HL7 CodingRationale code system.
code indicating that the code descriptor represents the originally produced code
code indicating that the code descriptor is an originally produced code and is required by the specification describing the use of the coded concept
code indicating that the code descriptor was post-coded from free text source
code indicating that the code descriptor is post-coded from free text source and is required by the specification describing the use of the coded concept
code indicating that the code descriptor is required by the specification describing the use of the coded concept
The exact form of the requirement is not specified here; it may be required by the specification directly, or it may arise as an indirect result of other conformance tools. More than one different requirement may exist simultaneously, so more than one code in a CD complex may be required.
controlled vocabulary representing the enumeration for coding rationale as specified in ISO 21090
controlled vocabulary representing the enumeration for coding rationale
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.4.2.3.8
code element that identifies an algorithm, if any, used to compress the raw byte data
If populated, the value of this attribute shall be taken from the HL7 CompressionAlgorithm code system.
If the attribute is null, the data are not compressed. Compression only applies to the binary form of the content.
code indicating the bzip-2 compression format. See [http://www.bzip.org/] for more information.
code indicating the deflate compressed data format as specified in IETF RFC 1951
code indicating a compressed data format that is compatible with the widely used GZIP utility as specified in IETF RFC 1952 (uses the deflate algorithm)
code indicating the original UNIX compress algorithm and file format using the LZC algorithm (a variant of LZW). Patent encumbered and less efficient than deflate
code indicating the 7z compression file format. See [http://www.7-zip.org/7z.html] for more information.
code indicating a compressed data format that also uses the deflate algorithm. Specified as IETF RFC 1950
controlled vocabulary representing the enumeration for compression algorithms as specified in ISO 21090
finite set of values that represent the only allowed values for a data item
The allowed values can be codes, text or numeric.
ISO 11238:2018 Health informatics - Identification of medicinal products (IDMP) - Data elements and structures for the unique identification and exchange of regulated information on substances, clause 3.18
ISO 11240:2012 Health informatics - Identification of medicinal products - Data elements and structures for the unique identification and exchange of units of measurement, clause 3.1.5
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.3.3.3.2
code representing the most basic, non-private datatype in the ISO 21090 datatype classification hierarchy
This code typically denotes an xsd:boolean value.
code for a boolean datatype for which a value is required
This code typically denotes a complex concept that is a class that has inherent relationships and attributes.
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.4.2
This code may link to some external resource or denote a complex concept that is a class that has inherent relationships and attributes.
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.7.6
This code denotes a name expressed as an xsd:string or rdf:langString, or a reified name that is an individual of type cmns-dsg:Name or of a subclass of cmns-dsg:Name such as a composite person name, organizational name, or other contextual name that may include provenance details such as the date such a name was last verified in addition to possible components of a name.
code representing a part of a name that may have a type code signifying the role of the part in the whole entity name, and qualifier codes for more detail about the name part type
Typical name parts for person names are given names, and family names, titles, etc.
code representing the top-level datatype in the ISO 21090 datatype classification hierarchy
This code typically denotes a complex concept, i.e., a named individual of type identifier that has inherent relationships and attributes, such as a named individual of type cmns-id:Individual or a subclass thereof.
This code denotes a name expressed as an xsd:string or rdf:langString, or a reified name that is an individual of type cmns-dsg:Name.
This code denotes a complex concept, i.e., a named individual of type cmns-qtu:ScalarQuantityValue that has an inherent unit of measure and numeric value.
This code denotes a real number typically expressed as an xsd:decimal, xsd:float, owl:rational, or owl:real datatype.
This code denotes either an xsd:string or rdf:langString.
code for a datatype representing the condition of something as of some point in time
This code denotes either a reified time instant (cmns:TimeInstant) or individual that is a member of a subclass of time instant, or an instance of cmns-dt:CombinedDateTime.
code representing an abstract, private datatype in the ISO 21090 datatype classification hierarchy
A part of a name or address. Each part is a character string that may be coded, and that also may have a nullFlavor. The string content shall always be provided whether a code is provided or not.
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 6.7.6
code element that describes a common constraint pattern on a datatype
Datatype flavors cannot introduce new attributes, new codes, default values, or any new definitional material. Datatype flavors may only make rules about what or how existing features of a class may be used.
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.7.5.3.1
code element that identifies a component of a name
If populated, the value of this attribute shall be taken from the HL7 EntityNamePartType2 code system.
Not every name part shall have a type code, if the type code is unknown, not applicable, or simply undefined this is expressed by a null value (type.isNull).
code indicating a delimiter, which has no meaning other than being literally printed in this name representation
A delimiter has no implicitleading and trailing white space.
code indicating a 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.
Family name, this is the name that links to the genealogy
Not to be called 'first name' since given names do not always come first.
code indicating a part of the name that is acquired as a title due to academic, legal, employment or nobility status, etc.
Title name parts include name parts that come after the name, such as qualifications
controlled vocabulary representing the enumeration for entity name parts as specified in ISO 21090
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.7.2
classifier that defines the basic properties of an abstract type used for representing parts of other datatypes, including names and addresses
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.3.3
classifier that defines the basic properties of every data value
However exceptional values (nullFlavored values) may be of type ANY, except for the exceptional values that imply the NullFlavor INV, since this requires a type to be meaningful. Not all NullFlavors may be used with the type ANY.
This is conceptually an abstract type, meaning that no proper 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.
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.3.4
classifier that stands for the values of two-valued logic
A BL value can be either true or false, or may have a nullFlavor, which makes this classifier essentially three-valued.
classifier that stands for the values of two-valued logic, for which a value is required
BL.NONNULL is a constrained instance of BL that cannot have a nullFlavor. By implication, a null can never be used in the place of a BL.NONNULL, though this is not a rule that can be enforced by this International Standard.
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.4.6
classifier that stands for text data, primarily intended for machine processing (e.g. sorting, querying, indexing, etc.) or direct display
A ST shall have at least one character or else have a nullFlavor
set of codes for harmonized datatypes defined in the ISO 21090 specification
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.5.2
classifier that provides a reference to a concept defined in an external code system, terminology or ontology
A CD may contain a simple code – that is, a reference to a concept defined directly by the referenced code system, or it may contain an expression in some syntax defined by the referenced code system that can be meaningfully evaluated, e.g. the concept of a 'left foot' as a postcoordinated term built from the primary code 'FOOT' and the qualifier 'LEFT'.
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 3.7, 7.3.2
classifier that provides the top-level, abstract definition of a datatype, which is set of distinct values, characterized by properties of those values, and by operations on those values, according to the ISO 20190 specification
Because of the way that the types are defined, a number of attributes of the datatypes have values with a type derived from HXIT (i.e., from this abstract class definition corresponding to HXIT). In these cases the HXIT attributes are constrained to null. The only case where the HXIT attributes are allowed within a datatype is on items in a collection (DSET, LIST, BAG, HIST). The use of these attributes is generally subject to further constraints in the specifications that make use of these types.
This concept corresponds to the HXIT datatype, which is abstract and private from a UML perspective - this datatype is not for use outside the datatypes in this International Standard.
Together, the root and extension identify a particular record of a real world event that may supply additional information about the value such as who made the change, when it was made, why it was made, what system originated the change. These attributes exist because sometimes this information is required, but the value is being represented in an external context that does not contain a proper relationship to the control information for the value itself. The record need not be directly or easily resolvable. Conformance statements may make additional statements about these two properties, or about how such a reference should be resolved. If a hasControlInformationExtension value is provided, a ControlInformationRoot shall also be provided.
classifier that stands for data that are primarily intended for human interpretation or for further machine processing outside the scope of the ISO 21090 International Standard
The three representations of the ED data - as a sequence of characters, as a sequence of bytes, or as XML in a native XML format - are mutually incompatible and could also have been implemented as three specializations of an abstract ED supertype. However, doing so would complicate definition and implementation of the ED flavors and complicate the associated XML format (the additional of a mandatory xsi:type attribute) without significantly simplifying the overall implementation of ED.
This includes unformatted or formatted written language, multimedia data, or structured information as defined by a different standard (e.g. XML-signatures).
designation by which someone, some place, or something is known in the context of ISO 21090
From an ISO 21090 perspective, entity names may be simple names or include sequences of entity name parts. They add a 'use' code and a valid time range for information about when the name was used and how to choose between multiple aliases that may be valid at the same time.
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.7.5
classifier that defines the basic properties of component of an entity name
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.4.2.3.10
code element that identifies the algorithm used to compute the IntegrityCheckAlgorithm value
If populated, the value of this attribute shall be taken from the HL7 IntegrityCheckAlgorithm code system.
code indicating the algorithm defined in FIPS PUB 180-1: Secure Hash Standard, As of April 17, 1995
code indicating the algorithm defined in FIPS PUB 180-2: Secure Hash Standard
controlled vocabulary representing the enumeration for integrity check algorithms as specified in ISO 21090
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.1.4
code element that provides a general framework for handling incomplete data which is often encountered in healthcare information collection, use and analysis
Some of the Null flavors are not generally applicable to all datatypes. The NullFlavors NINF, PINF, QS, and TRC shall only be used in association with QTY types. The NullFlavor UNC shall only be used with any type that has an hasOriginalText value, and when UNC is used the hasOriginalText property shall be populated. When the NullFlavor DER is used, an expression shall be provided.
The nullFlavor property may also play a special role in conformance frameworks in specifications that make use of these types.
code for a value for which information was sought but not found (e.g. patient was asked but did not know).
code for value for which no attempt has been made to encode the information correctly but the raw source information is represented (usually in hasOriginalText property)
code for a value as represented in the instance that is not a member of the set of permitted data values in the constrained value domain of a variable
code for a value for which there is information 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.
Warning: Using this Nullflavor does provide information that may be a breach of confidentiality, even though no detailed data are 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.
code for a value for which no proper value is applicable in this context (e.g. last menstrual period for a male)
code for a value for which information has not been sought (e.g. patient was not asked)
code for a value for which information is not available at this time but it is expected that it would be available later
code for a value that is exceptional (missing, omitted, incomplete, improper)
No information as to the reason for being an exceptional value is provided. This is the most general exceptional value. It is also the default exceptional value.
code for a value that is part of a value domain including a negative infinity of numbers
code for an actual value that is not a member of the set of permitted data values in the constrained value domain of a variable (e.g. concept not provided by required code system)
code for a value that is part of a value domain including a positive infinity of numbers
code for a value for which a specific quantity is not known, but is known to be non-zero and is not specified because it makes up the bulk of the material
'Add 10 mg of ingredient X, 50 mg of ingredient Y, and sufficient quantity of water to 100 ml.' The null flavor would be used to express the quantity of water.
code for a value for which content is greater than zero, but too small to be quantified
code for a value for which an actual value may exist, but it must be derived from the information provided (usually an expression is provided directly)
code for a value for which proper value is applicable, but not known
controlled vocabulary representing the enumeration for null flavor codes as specified in ISO 21090
null flavor enumeration object identifier
object identifier for the null flavor enumeration
compression algorithm enumeration object identifier
object identifier for the compression algorithm enumeration
integrity check algorithm enumeration object identifier
object identifier for the integrity check algorithm enumeration
coding rationale enumeration object identifier
object identifier for the coding rationale enumeration
entity name part type enumeration object identifier
object identifier for the entity name part type enumeration
update mode enumeration object identifier
object identifier for the update mode enumeration
globally unique identifier of a data object as defined in ISO/IEC 8824-2
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 4
An object identifier (OID) is a unique alphanumeric/numeric identifier registered under the ISO/IEC 8824-2 registration standard to reference a specific object or object class.
code element that allows a sending system to identify the role that the attribute plays in processing the instance that is being represented
If populated, the value of this attribute shall be taken from the HL7 UpdateMode code system.
code indicating that an item was (or is to be) added, having not been present immediately before
If it is already present, this may be treated as an error condition.
code indicating that an item was (or is to be) either added or replaced
No assertion is made as to whether the item previously existed.
code indicating that an item item was (or is to be) removed (sometimes referred to as deleted)
If the item is part of a collection, delete any matching items.
code indicating that the item is part of the identifying information for the object that contains it
code indicating that 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.
code indicating that an item existed previously and has been (or is to be) revised
If an item does not already exist, this may be treated as an error condition.
code indicating that it is not specified whether or what kind of change has occurred to the item, or whether the item is present as a reference or identifying property
controlled vocabulary representing the enumeration for update mode codes as specified in ISO 21090
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.5.2.4.5
ISO/IEC 11179-3 Information technology - Metadata registries (MDR) - Part 3: Registry metamodel and basic attributes, Third edition, 2013-02-15
The permissible values may either be enumerated or expressed via a description.
The value domain provides representation, but has no implication as to what data element concept the values might be associated with nor what the values mean.
identifier that allows unambiguous reference to a value set
Where either ISO or HL7 have assigned an identifying name to a value set, then that name shall be used.
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.4.2.3.2
indicates a simple sequence of byte values that contains the content
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.3.4.3.1
identifies an Internet Assigned Numbers Authority (IANA) Charset Registered character set and character encoding for character-based encoding types
Whenever the content of the ED is character type data in any form, the charset property needs to be known. If the content is provided directly in the value attribute, then the charset shall be a known character set consistent with the String Character Set. If the content is provided as a reference, and the access method does not provide the charset for the content (such as by a mime header), then the charset shall be conveyed as part of the ED.
indicates the algorithm, if any, used on the raw byte data for compression purposes
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.3.2.3.4
indicates the extension of the identifier of the event associated with setting the datatype to its specified value
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.3.2.3.3
indicates the root of the identifier of the event associated with setting the datatype to its specified value
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.5.2.4.7
indicates a name, title, or representation for the code or expression as it exists in the code system
If populated, the hasDisplayName shall be a valid human readable representation of the concept as defined by the code system at the time of data entry.
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.3.3.3.1
indicates the reason if a value is not proper
Signals the imposition of one or more sets of constraints on the datatype. The sole purpose of specifying that a constraint that has been used to further constrain the datatype is to support validation of the instance: a validation engine can look up the rules expressed for the specified flavors and confirm that the instance conforms to the rules for the flavor. No other processing should depend on the content of the flavor attribute. No other semantic or computational use shall depend on the value of this property. If this value is populated,the datatype flavor(s) shall be a valid constraint on the type of value.
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.8.3.3
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.4.2.3.9
indicates a checksum calculated over the binary data
The purpose of this property, when communicated with a reference is for anyone to validate later whether or not the reference still resolved to the same content that the reference resolved to when the encapsulated data value with reference was created. If the attribute is null, there is no IntegrityCheckAlgorithm. It is an error if the data resolved through the reference does not match the integrity check.
indicates the algorithm used to compute the IntegrityCheckAlgorithm value
indicates the human language of the content
Valid codes are taken from the IETF RFC 3066. If this attribute is null, the language may be inferred from elsewhere, either from the context or from unicode language tags, for example. Conformance profiles should define defaulting rules for language for a given usage environment of this International Standard. While language tags usually alter the meaning of the text, the language does not alter the meaning of the characters in the text.
indicates a position of the concept with respect to the hierarchy of the terminology
All concepts marked with the same level and not separated by a concept with a level of less numerical magnitude are siblings, and all concepts that follow after another concept with a higher level value are children of that concept.
The hierarchy in the enumeration is an important part of the specification. Although the enumerations are defined as linear lists within ISO/IEC 11404 and the UML definitions, any information processing entity that asserts direct or indirect conformance with this International Standard shall conform to the relationships when evaluating meaning (implication) within the enumeration. In addition, this International Standard occasionally refers to the relationships within the narrative when defining the outcome of some operations.
identifies the type of the encapsulated data and can be used to determine a method to interpret or render the content
If the content is compressed using a specified compression algorithm, the mediaType shall refer the mediaType of the uncompressed data, whether the data are accessed by reference or not.
The IANA defined domain of media types is established by the IETF RFCs 2045 and 2046. mediaType has a default value of text/plain and cannot be null. If the media type is different to text/plain, the mediaType attribute shall be populated.
indicates the text as seen and/or selected by the user who entered the data which represents the intended meaning of the user
Local implementations might influence what is required to represent that original text.
The original text shall be an excerpt of the relevant information in the original sources, rather than a pointer or exact reproduction. Thus the original text shall be represented in plain text form. In specific circumstances, when the context of use is clearly described, the hasOriginalText value may be a reference to some other text artefact for which the resolution scope is clearly described.
indicates a date and time associated with the publication of something, such as a particular version of a value set
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.4.2.3.4
indicates a URL the target of which provides the binary content
indicates a reference to the CD that was the source of this translation, if this CD was created by translating it from another CD
This property is a reference. The source to which the reference points shall be provided within the scope of this CD's root CD and translations; that is, another representation of the same concept in the same attribute.
indicates an abbreviated rendition of the full content
A thumbnail requires significantly fewer resources than the full content, while still maintaining some distinctive similarity with the full content. A thumbnail is typically used with by-reference encapsulated data. It allows a user to select the appropriate content more efficiently before actually downloading through the reference. Originally, the term thumbnail refers to an image in a lower resolution (or smaller size) than another image. However, the thumbnail concept can be metaphorically used for media types other than images. For example a movie may be represented by a shorter clip; an audio-clip may be represented by another audio-clip that is shorter, has a lower sampling rate, or a glossy compression; or an abstract provided for a long document. A thumbnail itself shall not contain a thumbnail.
indicates an alternate rendition of the same content translated into a different language
Translations may not contain translations. The translations shall convey the same information, but in a different language. The translations do not take part in the test for equality, so shall not introduce any new semantics to the value.
allows a sending system to to identify the role that the attribute plays in processing the instance that is being represented
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.3.2.3.2
indicates the time that the given information ceased or will cease to be correct
Both hasValidTimeLow and hasValidTimeHigh shall be valid timestamps using the format described in 7.8.13.3.1 (TS.value).
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 7.3.2.3.1
indicates the time that the given information became or will become valid
This is not the time that any system first observed the value, but the time that the actual value became correct (i.e. when a patient changes their name).
provides a version descriptor for the source
For the purposes of ISO 21090, versions of a given resource must be backwards compatible.
Whenever a code system changes in an incompatible way, it constitutes a new code system, not simply a different version, regardless of how the vocabulary publisher calls it. For example, the publisher of ICD-9 and ICD-10 calls these code systems, 'revision 9' and 'revision 10' respectively. However, ICD-10 is a complete redesign of the ICD code, not a backward compatible version. Therefore, for the purposes of this datatype International Standard, ICD-9 and ICD-10 are different code systems, not just different versions. By contrast, when LOINC updates from revision '1.0j' to '1.0k', this would be considered as just another version of LOINC, since LOINC revisions are backwards compatible.
indicates content represented in plain XML form
assigns an ISO 21090 datatype to an XML Scheme Datatype or more complex concept corresponding to the notion of an ISO 21090 datatype
ISO 21090:2011 Health informatics - Harmonized data types for information interchange, clause 3.3
A code element is a concept representation published by the author of a code system as part of the code system, being an entity of that code system.
A code system is a managed collection of concept identifiers, usually codes, but sometimes more complex sets of rules and references.