Page Comparison

...

openEHR data types	No. times constrained in CKM *	FHIR data types	Archetype Requirements	Information Representation Requirements
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	humanDate
ISO8601_DATE_TIME	5	datetime
ISO8601_TIME	0	-
ISO8601_DURATION	13 -	see DV_DURATION below.
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
GENERIC_ID	Identifier

Complex Types

openEHR data types	No. times constrained in CKM archetypes *	FHIR data types	Archetyping	Data Representation	Feedback to FHIR
DV_BOOLEAN	56	xx	xx		-	Used widely in archetypes.	No FHIR subtype of DataType to accommodate booleans?

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?
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?
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	xx		.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?
DV_CODED_TEXT .defining_code	388	CodeableConcept xx .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 xx .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?

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

Versions Compared

Old Version 16

New Version 17

Key

Id types

Complex Types