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 Information Resources (FHIR). 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.
openEHR does not define primitive types as such. But since such types are needed ubiquitously in specifications, it provides a set of partial class definitions that it assumes. These definitions support the openEHR specifications. For example, there is a String type, and in the specifications, some kind of 'empty' function is often needed. So the openEHR Support IM assumed_types package defines String and a few functions, including is_empty() on it.
openEHR data types |
No. times |
FHIR data types |
Archetype Requirements |
Information Representation Requirements |
---|---|---|---|---|
Octet |
0 |
- |
|
|
Character |
0 |
- |
|
|
- |
- |
base64binary |
|
|
Boolean |
62 |
boolean |
- |
|
Integer |
50 |
integer (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. |
|
ISO8601_DATE |
3 |
humanDate |
|
|
ISO8601_DATE_TIME |
5 |
datetime |
|
|
ISO8601_TIME |
0 |
- |
|
|
ISO8601_DURATION |
13 |
- |
|
|
Array<T> |
- |
- |
|
|
List<T> |
- |
- |
|
|
Set<T> |
- |
- |
|
|
Hash<T,U> |
- |
- |
|
|
Interval<T> |
- |
- |
|
|
Id types
openEHR data types |
FHIR data types |
Comments |
---|---|---|
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 |
Complex Types
openEHR data types |
No. times |
FHIR data types |
Archetyping |
Data Representation |
---|---|---|---|---|
DV_BOOLEAN |
56 |
xx |
xx |
|
|
|
|
|
|
DV_QUANTITY |
189 |
Quantity |
|
In FHIR, Quantity accommodates both Integer and Real values. |
DV_COUNT |
28 |
Quantity |
|
|
DV_PROPORTION |
40 |
Ratio |
|
|
DV_ORDINAL |
50 |
Choice |
The FHIR type does not seem to accommodate values, only symbols. |
|
DV_INTERVAL<T:DV_QUANTIFIED> |
5 - DV_DATE |
Interval |
|
|
|
|
|
|
|
DV_DATE |
25 |
xx |
xx |
|
DV_DATE_TIME |
32 |
xx |
xx |
|
DV_TIME |
0 |
xx |
xx |
|
DV_DURATION |
22 |
Quantity |
xx |
|
|
|
|
|
|
DV_TEXT |
521 |
CodeableConcept |
xx |
|
DV_CODED_TEXT |
388 |
CodeableConcept |
xx |
|
|
|
|
|
|
DV_URI |
6 |
uri |
xx |
|
DV_EHR_URI |
2 |
uri |
xx |
|
DV_PARSABLE |
1 |
- |
xx |
|
DV_IDENTIFIER |
2 |
HumanId |
xx |
|
|
|
|
|
|
DV_MULTIMEDIA |
13 |
Attachment |
|
|
DV_GENERAL_TIME_SPECIFICATION |
0 |
Schedule |
|
|
DV_PERIODIC_TIME_SPECIFICATION |
0 |
Schedule |
|
|
- |
|
Money |
|
|