Difference between revisions of "OpenEHR datatypes mapping"
| Line 1: | Line 1: | ||
== mappings between openEHR datatypes and ISO datatypes == | == mappings between openEHR datatypes and ISO datatypes == | ||
| − | == DATA_VALUE == | + | == Basic Package == |
| + | |||
| + | === DATA_VALUE === | ||
Maps to ANY. in openEHR, null flavor is a property of the holder | Maps to ANY. in openEHR, null flavor is a property of the holder | ||
| Line 9: | Line 11: | ||
| − | == DV_BOOLEAN == | + | === DV_BOOLEAN === |
Maps directly to BL | Maps directly to BL | ||
| − | == DV_STATE == | + | === DV_STATE === |
State is a coded value with a boolean flag for whether the | State is a coded value with a boolean flag for whether the | ||
| Line 20: | Line 22: | ||
DV_STATE, but it can be mapped to CD | DV_STATE, but it can be mapped to CD | ||
| − | == DV_IDENTIFIER == | + | === DV_IDENTIFIER === |
DV_IDENTIFIER contains assigner, issuer, id and type, all string. | DV_IDENTIFIER contains assigner, issuer, id and type, all string. | ||
| Line 40: | Line 42: | ||
'''TODO: should we add a type:CS to II?''' | '''TODO: should we add a type:CS to II?''' | ||
| − | == | + | == Text Package == |
| − | + | These might be called the "narrative" datatypes - they support | |
| − | "narrative" datatypes - they support the idea of a narrative | + | the idea of a narrative consisting of a sequence of text with |
| − | consisting of a sequence of text with mark up (format, hyperlinks | + | mark up (format, hyperlinks and terminology). Currently, the |
| − | and terminology). Currently, the concept of narratives and the | + | concept of narratives and the supporting datatypes is out of |
| − | supporting datatypes is out of scope for the ISO datatypes. | + | scope for the ISO datatypes. |
'''TODO: should we extend the ISO datatypes to include narrative? (suggest for phase II)''' | '''TODO: should we extend the ISO datatypes to include narrative? (suggest for phase II)''' | ||
| + | |||
| + | === DV_PARAGRAPH === | ||
Since there is no concept of narratives in the iso datatypes, there | Since there is no concept of narratives in the iso datatypes, there | ||
| Line 55: | Line 59: | ||
the translation is occurring. | the translation is occurring. | ||
| − | + | === DV_TEXT === | |
| − | == DV_TEXT == | ||
Much of DV_TEXT is rooted in the narrative concept. The nearest | Much of DV_TEXT is rooted in the narrative concept. The nearest | ||
| Line 69: | Line 72: | ||
* DV_TEXT has encoding which may be used when converting to and from Unicode strings in the ISO datatypes | * DV_TEXT has encoding which may be used when converting to and from Unicode strings in the ISO datatypes | ||
| − | == TERM_MAPPING == | + | === TERM_MAPPING === |
no equivalent (contained within other types and not required as a direct mapping) | no equivalent (contained within other types and not required as a direct mapping) | ||
| − | == CODE_PHRASE == | + | === CODE_PHRASE === |
no equivalent (contained within other types and not required as a direct mapping) | no equivalent (contained within other types and not required as a direct mapping) | ||
| − | == DV_CODED_TEXT == | + | === DV_CODED_TEXT === |
The direct equivalent of this is CD. CD is not quite the same - there is still the | The direct equivalent of this is CD. CD is not quite the same - there is still the | ||
| Line 93: | Line 96: | ||
* DV_CODED_TEXT has formatting which is a narrative concept | * 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 has encoding which may be used when converting to and from Unicode strings in the ISO datatypes | ||
| + | |||
| + | == 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_COUNT === | ||
| + | |||
| + | Matches INT. magnitude matches int.value | ||
| + | |||
| + | === DV_QUANTITY === | ||
| + | |||
| + | matches PQ. | ||
| + | === DV_ORDINAL === | ||
| + | |||
| + | === DV_PROPERTION === | ||
| + | |||
| + | === DV_INTERVAL === | ||
| + | |||
| + | == Date Time package == | ||
| + | |||
| + | === DV_DATE === | ||
| + | |||
| + | === DV_DURATION === | ||
Revision as of 08:06, 5 February 2007
Contents
mappings between openEHR datatypes and ISO datatypes
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_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.
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
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_COUNT
Matches INT. magnitude matches int.value
DV_QUANTITY
matches PQ.
