OpenEHR datatypes mapping

Basic Package

DATA_VALUE

Maps to ANY. 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 the attribute if possible, or else the information should be dropped.

DV_BOOLEAN

Maps directly to BL

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. 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?

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)

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_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 (not)
• upper_unbounded -> lowUnbounded (not)
• 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_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.