openEHR data types | No. times
constrained in
CKM archetypes *
| FHIR data types | Archetyping | Data Representation
| Feedback to FHIR
|
|---|
DV_BOOLEAN | 56
| -
| Used widely in archetypes.
| | No FHIR subtype of DataType to accommodate booleans?
No. in FHIR, you would use a a code with values true and false. Where an apparent boolean justifies a nullFlavor, theres's a good chance it's not really a simple yes/no anyway
|
| | | | | |
DV_ORDERED
.normal_status
.normal_range
.other_reference_ranges
| | | | | |
DV_QUANTIFIED
.magnitude_status
| | Quantity
.status
| | | |
DV_AMOUNT
.accuracy
.accuracy_is_percent
| | | | | |
DV_QUANTITY
.magnitude
.units
.precision
| 189
133
161
66
| Quantity
.value
.units
| Used widely in archetypes.
| In FHIR, Quantity accommodates both Integer and Real values.
There is an optional field status that matches openEHR DV_QUANTITY.magnitude_status, but has fewer values.
| The FHIR choice to represent units as a code or a string seems unnecessarily complicated. A UCUM units string should be adequate. There is an example with unit=mcg/L and code=ug. What can this mean?
The meaning is clear: the code for the unit "ug" has a displayName of "mcg". The idea that a physical value data field is only for computation is false. In any context where it is used, it must be displayed to a user at some stage. Even in CDA, where there is a display section, any use of the data value outside the context of the CDA document, it will need display. UCUM units are not suitable for display, and you can't always simply look it up either. Further, many representations of the data are in the context of secondary use; the requirement to record units may be quite problematic, and why have it? For this reason FHIR allows a value, a human readable units, and possibly a code for the units for computation. The code may be UCUM, but UCUM computations are not the only type of computation that can be performed. Hence ISO 639 and Snomed and others are allowed as well. UCUM is encouraged for physical measures, and can be mandated in constraints.
|
DV_COUNT
.magnitude
| 28
| Quantity
|
| | |
DV_PROPORTION
.numerator
.denominator
| 40
| Ratio
|
| | |
DV_ORDINAL
.value
.symbol
| 50
| Choice
|
| | The FHIR type does not seem to accommodate values, only symbols. Test for FHIR: how to represent Apgar or Barthel ordinal value lists?
Not sure what you mean, only values not symbols. You wouldn't use a data type to represent all of Apgar or Barthels? - so the question needs clarification
|
DV_INTERVAL<T:DV_QUANTIFIED> | 5 - DV_DATE
1 - DV_COUNT
1 - DV_QUANTITY
1 - DV_DATE_TIME
| Interval
|
| | |
| | | | | |
DV_DATE | 25
| xx | xx | | |
DV_DATE_TIME | 32
| xx | xx | | |
DV_TIME | 0
| xx | xx | | |
DV_DURATION | 22
| Quantity
| xx | | |
| | | | | |
DV_TEXT
.value
.mappings
.language
.encoding
.hyperlink
.formatting
| 521
| CodeableConcept
.text
.coding (repeats)
| DV_TEXT mostly used in archetyping to simply indicate the field type.
| | In the FHIR type, the value of the 'text' and the 'displayName' fields will be the same. Given the ubiquity of coded data elements in health data, this seems unfortunate.
No way to know what language the text is in?
not sure why they'd be the same. The DV_TEXT data type is a bit weird from a HL7 point of view. It's kind of coded or not. Which is it?
|
DV_CODED_TEXT
.defining_code
| 388
| CodeableConcept
.primary
| Numerous fields in archetypes are constrained to be local codes, and in templates, to external codes or refsets.
| | ''
|
| | | | | |
DV_URI | 6
| uri | xx | | |
DV_EHR_URI | 2
| uri | xx | | |
DV_PARSABLE | 1
| - | xx | | |
DV_IDENTIFIER
.issuer
.id
.assigner
.type
| 2
| HumanId
.identifier.system
.identifier.id
.assigner
.type
.period
| | This should be a near perfect bidirectional transform apart from the FHIR HumanId 'period' attribute.
| We would consider this a risk, because a validity period might be assigned initially, then be changed; should the data be changed? Can this field be reliably set and reasoned about computationally?
It is difficult to compute about the period. But this field is almost impossible to compute with in the general sense - what's the type anyway? Most uses would require local trading partner agreement. Even if you give up on the notion of computing with the period, that doesn't mean that the concept doesn't actually exist.
|
| | | | | |
DV_ENCAPSULATED
.charset
.language
| | | | | |
DV_MULTIMEDIA
.alternate_text
.uri
.media_type
.data
.compression_algorithm
.integrity_check
.integrity_check_algorithm
.size
| 13 | Attachment
.title
.url
.mimeType
.data
[Not compressed]
.hash
[Std Hash]
[derivable]
| | The FHIR type appears to correspond to allow only base64 ASCII-encoded binary, as is done with MIME attachments in email. This alleviates the need for the 'compression' attribute used in DV_MULTIMEDIA. Any openEHR content should be easy to convert to FHIR format; assuming an openEHR system makes sensible local decisions about binary representation of large multimedia objects, Attachment => DV_MULTIMEDIA should also be trouble-free.
| |
DV_TIME_SPECIFICATION
.value: syntax expression with:
&period
&calendar_alignment
&event_alignment
&occurrences
&institution_specified
| n/a
| Schedule
-
.duration/.frequency
.event
.when
.count
-
| n/a
| These openEHR types are taken from HL7, and so far have limited use in openEHR systems. It would appear reasonable to replace the openEHR type with whatever HL7 decides on for this type in the future, which might be this FHIR type.
| |
DV_GENERAL_TIME_SPECIFICATION
.calendar_alignment
.event_alignment
.institution_specified
| 0
| Schedule
| | '' | |
DV_PERIODIC_TIME_SPECIFICATION
| 0
| Schedule | | '' | |
-
| | Money
| | | |