...
As part of its 'fresh look' activity, Grahame Grieve at Health Intersections has produced a set of simplified data types that solves a lot of the problems of ISO 21090, and addresses many of the needs of openEHR data types. It may become a new specification within HL7 or elsewhere, and is a candidate data types model for CIMI. These data types are part of a larger piece of work called Fast Health Interoperability Resources (FHIR), which is essentially a library of micro-formats for use in agile web-based and mobile device development. This work is gathering pace in HL7, so it seems a worthwhile point to consider its possible impact on openEHR.
...
openEHR data types | No. times | FHIR data types | Archetyping | Data Representation | Feedback to FHIR |
---|---|---|---|---|---|
DV_BOOLEAN | 56 | boolean | Used widely in archetypes. |
| No FHIR subtype of DataType to accommodate booleans? |
|
|
|
|
|
|
DV_ORDERED |
|
| Would not normally be archetyped, but common in data. |
|
|
DV_QUANTIFIED |
| Quantity | Would not normally be archetyped, but common in data. |
|
|
DV_AMOUNT |
| - | Would not normally be archetyped, but common in data. |
| Likely to be needed in FHIR implementations. |
DV_QUANTITY | 189 | Quantity | Used widely in archetypes. | In FHIR, Quantity accommodates both Integer and Real values. | The FHIR model supports both 'display units' and computable (formal) units. Example: unit=mcg/L and code=ug. |
DV_COUNT | 28 | Quantity |
|
| |
DV_PROPORTION | 40 | Ratio |
|
| |
DV_ORDINAL | 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? | |
DV_INTERVAL<T:DV_QUANTIFIED> | 5 - DV_DATE | Interval | Relatively frequent use in archetypes |
|
|
|
|
|
|
|
|
DV_DATE | 25 | HumanDate | Frequent use in archetypes of all kinds. |
|
|
DV_DATE_TIME | 32 | dateTime | xx |
|
|
DV_TIME | 0 | dateTime | xx |
| dateTime in FHIR would need to be constrained somehow to be only a Time. |
DV_DURATION | 22 | Quantity | Frequent use in archetypes of all kinds. |
|
|
|
|
|
|
|
|
DV_TEXT | 521 | CodeableConcept | 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 for at least one 'coding'. Given the ubiquity of coded data elements in health data, this seems unfortunate. |
DV_CODED_TEXT | 388 | CodeableConcept | 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 | 2 | HumanId |
| 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? |
|
|
|
|
|
|
DV_ENCAPSULATED |
|
|
|
| 'language' would be supported in a FHIR extension. |
DV_MULTIMEDIA | 13 | Attachment |
| 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 | Schedule | 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. | No analysis yet of whether Schedule does everything GTS etc can do. | ||
DV_GENERAL_TIME_SPECIFICATION | 0 | Schedule |
| '' |
|
DV_PERIODIC_TIME_SPECIFICATION | 0 | Schedule |
| '' |
|
- |
| Money |
|
|
|
...