OpenEHR datatypes mapping
Contents
mappings between openEHR datatypes and ISO datatypes
Mappings to OpenEHR
This specification includes mappings to OpenEHR data types and structures as this is of great interest to many consumers of this specification for various reasons.
There is 4 different kind of mappings that are of interest when considering the mapping of OpenEHR constructs to UML ITS constructs.
- Converting from an HL7 Model to an OpenEHR archetype
- Converting from an OpenEHR Archetype to an HL7 Model
- Converting from an instance of an HL7 model to an instance of an OpenEHR Archetype
- Converting from an instance of an OpenEHR Archetype to an instance of an HL7 model
This specification addresses the issues involved in mapping from an HL7 model to an OpenEHR Model, and converting instances in either direction.
When converting from an HL7 model to an archetype, most HL7 data types match an OpenEHR equivalent directly, and it is a simple matter to convert. Some HL7 data types map to specially developed archetypes for demographic type information, and some HL7 data types map to OpenEHR structures. Finally, some HL7 data types express constraints on the data that is properly expressed in the archetype itself in OpenEHR. For this reason, converting from HL7 to OpenEHR is not simple matter of replacing data types, the entire model must be translated or transformed. This specification provides detailed equivalence notes for each HL7 data type to their matching OpenEHR constructs to help in this process. Users should be aware that though the result of converting an HL7 Model into an archetype may work, it is unlikely to be an optimally designed archetype.
This specification does not attempt to describe or aid the process of taking an OpenEHR archetype and representing it as an HL7 model. The primary reason is that the only archetypes that can be reasonably represented as HL7 models are likely to be those that were translated and transformed using the reverse process described above, and there seems little point in exercising or describing this path. Normal Archetypes will involve the use of constructs that do not have any equivalence of expression in Hl7 models where the Act/ActRelationship construct dominates the models. Nevertheless the information in this document will be useful for helping with this process.
Given an instance of an HL7 Model and the OpenEHR archetype derived from it, it may be possible, with some computational aid, to automatically convert from one instance to another in either direction. The mapping notes contained in this specification are intended to help with the analysis, design and implementation of this process. It is unlikely to be possible to automatically convert between instances of unrelated archetypes and models.
Some specific issue discussions for the OpenEHR mappings:
NullFlavor: xxxxxxxxxxxx
Basic Package
DATA_VALUE
Maps to ANY.
Conversion Notes: In openEHR, null flavor is a property of the holder of the datatype, not the type itself. When converting data, the nullFlavor may be moved to and from the attribute if possible, or else the information should be dropped.
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: 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: OpenEHR handles update history rather differently, and this information should not be mapped
DV_BOOLEAN
Maps directly to BL
- value -> BL.value
DV_STATE
State is a coded value with a boolean flag for whether the state engine is terminated. This is mixed up - either you know the state engine or you don't. There is no ISO equivalent for DV_STATE, but it can be mapped to CD
DV_IDENTIFIER
DV_IDENTIFIER contains assigner, issuer, id and type, all string. These are all useful attributes to have for a RWE, though there is genuine semantic confusion between assigner and issuer (this is true in HL7, openEHR, and the real world). The real problem with these attributes is that they are simple strings - there is no control over the contents, so they cannot be interpreted computationally, which may be ok within the context of openEHR (though I think it will become a problem), but is not generally useful.
The obvious equivalent of DV_IDENTIFIER is II. For id, this has root and extension. In some uses, root might map to issuer, but not always. assigner maps to AssigningAuthorityName. There is no map for type, so a potential approach to solve this is to add a type:CS attribute and collect the known types from v2?
TODO: should we add a type:CS to II?
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.
||||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
Text Package
These might be called the "narrative" datatypes - they support the idea of a narrative consisting of a sequence of text with mark up (format, hyperlinks and terminology). Currently, the concept of narratives and the supporting datatypes is out of scope for the ISO datatypes.
TODO: should we extend the ISO datatypes to include narrative? (suggest for phase II)
Content.langauge: DV_ENCAPSULATED.language or DV_TEXT.language Data: OpenEHR: No direct equivalent; implementing types will map to DV_MULTIMEDIA Data.value: DV_MULTIMEDIA.data Data.compression: DV_MULTIMEDIA.compression_algorithm; openEHR other is equivalent to V3 nullfFlavor "other". FIX THIS Data.mediatype: DV_MULTIMEDIA.media_type Data.encodingType : No equivalent; implementations may have to determine this value on the fly from examining the data
ED
OpenEHR: Equivalent to DV_MULTIMEDIA
DV_MULTIMEDIA.uri. uri is a simple uri,so when converting data the use and useablePeriod should be dropped. DV_MULTIMEDIA.integrity_check DV_MULTIMEDIA. integrity_check_algorithm DV_MULTIMEDIA. thumbnail. DV_MULTIMEDIA can contain recursive thumbnails, but this is a bad idea and not supported by the HL7 datatypes
DV_TEXT
Much of DV_TEXT is rooted in the narrative concept. The nearest equivalent to DV_TEXT in the ISO datatypes is ST, but there is also some similarity with CD when used without a code.
- DV_TEXT has value which is in ST. Note that in openEHR "No carriage returns, line feeds, or other non-printing characters permitted." whereas these are allowed in the ISO ST (any valid unicode character is allowed)
- DV_TEXT has language which is in ST.
- DV_TEXT has hyperlink which has no equivalent in the ISO datatypes (though there is URL the concept of a hyperlink for text is a narrative-type concept)
- DV_TEXT has mappings. Again, this is a narrative type concept which is not directly part of the ISO datatypes
- DV_TEXT has formatting which is a narrative concept
- DV_TEXT has encoding which may be used when converting to and from Unicode strings in the ISO datatypes
TERM_MAPPING
no equivalent (contained within other types and not required as a direct mapping)
CODE_PHRASE
no equivalent (contained within other types and not required as a direct mapping)
DV_CODED_TEXT
The direct equivalent of this is CD. CD is not quite the same - there is still the narrative concept piece that is missing from the ISO datatypes. Nevertheless in a standalone sense, CD is the nearest mapping.
- DV_CODED_TEXT has defining_code which maps to CD.code and CD.codeSystem.
- DV_CODED_TEXT has value which maps to CD.originalText.value. Note that in openEHR "No carriage returns, line feeds, or other non-printing characters permitted." whereas these are allowed in the ISO ST (any valid unicode character is allowed)
- DV_CODED_TEXT has language which maps to CD.originalText.language.
- DV_CODED_TEXT has hyperlink which has no equivalent in the ISO datatypes (though there is URL the concept of a hyperlink for text is a narrative-type concept)
- DV_CODED_TEXT has mappings which map to translations, though since the purpose and match fields are missing not all translations may be properly represented as mappings
TODO: Should add purpose to CD.translation?
- DV_CODED_TEXT has formatting which is a narrative concept
- DV_CODED_TEXT has encoding which may be used when converting to and from Unicode strings in the ISO datatypes
||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 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.
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
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>
DV_PARAGRAPH
Since there is no concept of narratives in the iso datatypes, there is no direct equivalent for DV_PARAGRAPH. There's no real way to advise on translations without knowledge of the context in which the translation is occurring.
Quantity Package
Heirarchy comments. ISO is flat - there is QTY which matches DV_ORDERED, other stuff is simply flat - this works ok as there is no internal relationships not involving abstract classes in the Quantity Package
DV_ORDERED
This is equivalent to QTY.
normal_status, is_simple, normal range, Reference ranges: There is no equivalence for these things in the ISO datatypes.
DV_INTERVAL
DV_INTERVAL<T> mapes directly to IVL<T>.
- lower -> IVL.lower
- upper -> IVL.uper
- lower_unbounded -> lowUnbounded
- upper_unbounded -> upperUnbounded
- lower_included -> lowClosed (not)
- upper_included -> highClosed (not)
REFERENCE_RANGE
no equivalent (contained within other types and not required as a direct mapping)
DV_ORDINAL
matches CO (change CO inheritance? open the symbol?)
properties are the roughly same - CD with value? Though this one has translations and the HL7 one doesn't - this is probably not significant?
DV_QUANTIFIED
accuracy - this is measurement thing, so belongs on PQ?
magnitude_status - also a measured thing
todo - do this - should these things be in ISO?
DV_MEASURABLE
no ISO equivalent (not needed)
DV_QUANTITY
matches PQ. magnitude matches value and units matches units.
precision - create this?
DV_COUNT
Matches INT. magnitude matches int.value
DV_PROPERTION
matches RTO
- numerator
- denominator
- is_integral
- type
- pk_ratio = default value
- pk_unitary - denominator is explicitly 1 in ISO
- pk_percent - denominator is explicitly 100 in ISO
- pk_fraction - no real equivalent - should be using a REAL?
- pk_integer_fraction - no real equivalent - should be using a REAL? (and how different to pk_fraction?)
- precision - this will be on the numerator and denominator if relevant
Note that the RTO type in ISO allows for units in the numerator and denominator. Many of these kind of uses for RTO are actually formulations in the openEHR context, so shouldn't be mapped to DV_PROPORTION and need to be modelled differently.
PROPORTION_KIND
no equivalent (contained within other types and not required as a direct mapping)
DV_CUSTOMARY_QUANTITY
no equivalent (contained within other types and not required as a direct mapping)
Date Time package
DV_DATE
maps directly to TS with only date
what's the units?
DV_TIME
no mapping - create a type for this in ISO
DV_DATE_TIME
maps directly to TS
DV_DURATION
maps directly to PQ - have to convert the format though
DV_TIME_SPECIFICATION
DV_PERIODIC_TIME_SPECIFICATION
matches either EIVL or PIVL - conversion between forms is required but the features are identical (openEHR is based on the V3 abstract model)
DV_GENERAL_TIME_SPECIFICATION
matches GTS - conversion between forms is required but the features are identical (openEHR is based on the V3 abstract model)
Encapsulated Package
DV_ENCAPSULATED
abstract class. All descendents are mapped to ED.
- charset - maps to ED.charset
- lang - maps to ED.lang
DV_MULTIMEDIA
matches ED
- alternateText - maps to ED.title
- mediaType - maps to ED.mediaType
- compression - maps to ED.compression
- thumbnail = maps to ED.thumbnail - recursive thumbnails (allowed in openEHR) are a bad idea and should be ignored
- uri - maps to ED.reference. time of availability should be dropped
- integrity_check - maps to ED.integrityCheck
- integrity_check_algorithm - maps to ED.integrityCheckAlgorithm
- data - maps to ED.data
DV_PARSABLE
There is no strict equivalent to DV_PARSABLE in the ISO datatypes. The content can be represented as an ED. the formalism field may be represented in the mediatype, but this is not always possible
Uri Package
DV_URI
maps to URL exactly
DV_EHR_URI
maps to URL exactly. The path is reproduced as is.
SET
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
LIST: OpenEHR: ITEM_LIST. ITEM_LIST does not have any equivalence for the ANY features, so these must be dropped or mapping must fail BAG: OpenEHR: ITEM_LIST. ITEM_LIST does not have any equivalence for the ANY features, so these must be dropped or mapping must fail IVL : 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 PIVL : OpenEHR: The type DV_TIME_SPECIFICATION provides for the literal representation of this data EIVL :OpenEHR: The type DV_TIME_SPECIFICATION provides for the literal representation of this data GTS: OpenEHR: DV_TIME_SPECIFICATION is equivalent to GTS