FHIR - openEHR Data Types cross-analysis

Introduction

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.

There are two types of analysis we can do on the FHIR data types. The obvious one is to do with information representation needs, i.e. a gap analysis of the FHIR data types versus the openEHR data types. This is a relatively detailed analysis to carry out, and will take some time. It is needed to determine how to convert FHIR-based data (e.g. HL7 messages of the future) in and out of openEHR data.

The second kind of analysis is to do with archetyping. We ask the question: could FHIR data types satisfy the requirements met by the current openEHR data types (DV_CODED_TEXT, DV_QUANTITY, and friends), remembering that archetyping needs are generally a subset of information persistence and communication needs. To give a simple example: the data type DV_QUANTITY in openEHR has a precision attribute, but not one of the 250+ CKM archetypes mentions it. This analysis is easier to perform, and its outcome enables us to know if FHIR data types could be used for archetyping purposes.

Analysis

The tables below present a gap analysis of openEHR v FHIR data types, seen both from the perspectives of information representation and archetype needs. In the tables below, statistics generated from the CKM archetypes as at 06 Jun 2011 are provided in the second column. Obviously things change, but these numbers are understood to be broadly representative.

Primitive types

Of all of the available primitive types defined in the openEHR Support IM specification, only a few are relevant to archetyping.

Other than for date/time types, openEHR does not define primitive types as such, since it assumes the existence of primitive types from implementation technologies. But since such types are mentioned ubiquitously in specifications, it provides a set of partial class definitions expressing what is assumed. For example, there is a String type, and in the specifications, some kind of 'empty' function is often needed e.g. for assertions like 'not code_string.is_empty'. So the openEHR Support IM assumed_types package defines String and a few functions, including is_empty() on it.

The date/time types are more fully defined since these are typically less standardised. In openEHR a collection of types based on ISO 8601 were therefore added.

openEHR data types

No. times
constrained
in CKM *

FHIR data types

Archetype Requirements

Information Representation Requirements

Feedback to FHIR

Octet

0

-

 

 

 

Character

0

-

 

 

 

-

-

base64binary

 

 

 

Boolean

62

boolean

-

 

 

Integer

50

integer (32 bit)
decimal (integer values >32 bit)

Integer appears in the DV_COUNT openEHR type. Currently there is no way (and as far as we know, no demand) to constrain an integer field to be of a certain size such as 64 bit or 32 bit.

The current assumption as to the size of 'Integer' in an openEHR system is that a) the size is decided by the implementation and that b) normal conversion rules would apply to enable typical integer values (i.e. relatively small numbers) stored in 64-bit words to be correctly converted to 32-bit or smaller integers.

 

Real

57

-

Real is used in DV_QUANTITY and is the type of most lab and many other quantities.

 

 

String

7

string

Strings are rarely directly constrained other than for force them to be non-empty, since any particular constraint might be language specific.

In FHIR, all atomic identifiers (Oids, UUIDs etc) are considered subtypes of String, with special constraints on the string pattern.

 

ISO8601_DATE

3

-

Used in DV_DATE type.

 

 

ISO8601_DATE_TIME

5

-

Used in DV_DATE_TIME type.

 

 

ISO8601_TIME

0

-

Used in DV_TIME type.

 

 

ISO8601_DURATION

13

-


 

 

Array<T>

-

-

 

 

 

List<T>

-

-

 

 

 

Set<T>

-

-

 

 

 

Hash<T,U>

-

-

 

 

 

Interval<T>

-

-

 

 

 

Id types

The following types are not 'data types' as such in the openEHR RM, but are used ubiquitously as identifiers throughout the model. The identifier type that can be used within archetyped structures is DV_IDENTIFIER (see below). DV_URI is also available for referencing resources.

openEHR data types

FHIR data types

Comments

Feedback to FHIR

OBJECT_REF

-

xx

 

OBJECT_ID

-

xx

 

INTERNET_ID

-

xx

 

UUID

uuid

xx

 

ISO_OID

oid

xx

 

LOCATABLE_REF

-

xx

 

TERMINOLOGY_ID

sid

In openEHR, strings of the form 'name(ver)' are used, where the 'ver' part is optional. In FHIR, the sid primitive type appears to have values from the left column of this table.

 

ARCHETYPE_ID

-

xx

 

OBJECT_VERSION_ID

-

xx

 

HIER_OBJECT_ID

-

xx

 

GENERIC_ID

Identifier

 

 

Complex Types

The following types are descendants of the DATA_VALUE type, which is the statically declared type of ELEMENT.value. This is how most 'clinical data' are expressed in openEHR, also in ISO 13606. See UML here.

openEHR data types

No. times
constrained in
CKM archetypes *

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?

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

 

 

Would not normally be archetyped, but common in data.

 

 

DV_QUANTIFIED
.magnitude_status

 

Quantity
.status

Would not normally be archetyped, but common in data.

 

 

DV_AMOUNT
.accuracy
.accuracy_is_percent

 

-

Would not normally be archetyped, but common in data.

 

Likely to be needed in FHIR implementations.

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 model supports both 'display units' and computable (formal) units.  Example: unit=mcg/L and code=ug.

GG: 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
.numerator
.denominator


 

 

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>
.lower
.upper

5 - DV_DATE
1 - DV_COUNT
1 - DV_QUANTITY
1 - DV_DATE_TIME

Interval
.low
.high

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
.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 for at least one 'coding'. 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

 


Assume base64 txt
-

 

 

'language' would be supported in a FHIR extension.

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


Schedule
-
.duration/.frequency
.event
.when
.count
-


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
.calendar_alignment
.event_alignment
.institution_specified

0

Schedule

 

''

 

DV_PERIODIC_TIME_SPECIFICATION

0

Schedule

 

''

 

-

 

Money

 

 

 

Possible Changes to openEHR

Identifiers

  • DV_IDENTIFIER: we could add a 'validity_period' attribute that indicates the intended validity of this id as specified by its assigner.

Text / Coded text types

  • we could remove DV_TEXT.hyperlink & formatting; also encoding if a given encoding can be assumed.

Quantity types

  • units: currently openEHR has only one 'units' attribute, which doesn't properly accommodate the difference between 'display units' and 'formal units' (e.g. UCUM).
  • null_flavours: review of code set; possibly add new unknown types 'error' (meaning system error on data creator side) and 'unsupported' (source system can't supply this info). See FHIR dataAbsentReason here.

Time Specification types

  • replace DV_*_TIME_SPECIFICATION types with FHIR Schedule type? Rich enough semantics?