/
openEHR Archetypes and FHIR

openEHR Archetypes and FHIR

Owned by Thomas Beale
Last updated: 05-Jul-2014

This page addresses the question of whether ADL/AOM archetyping can be technically used with native FHIR models / definitions, to provide profiling. One idea is to discover whether archetyped detailed openEHR content (i.e. any typical openEHR archetype) could be machine-converted into the 'core' of a FHIR resource(s) whose other parts are already defined by FHIR.

Method

The approach described here was as follows:

  • Treating the FHIR resources, apart from specific clinical content ones as a 'reference model' in the normal archetype sense. 
  • Create a layer of reference archetypes where needed to deal with further Resource specifics not easily represented in normal object models
  • Create clinical archetypes as FHIR profiles, on top of the above two layers
  • Show (or not) how core clinical content definitions from openEHR could be machine converted to form the core part of these archetypes.

Tools and Models

The work reported here was done using a BMM file (openEHR meta-model file) representing the FHIR resources, and the ADL Workbench (beta 11).

Issues & Difficulties

A number of difficulties arise with the fact that FHIR is defined natively in XML schema (with some Schematron invariants). XML schema is not properly object-oriented, and lacks some OO semantics; on the other hand it supports some constructs not easily representable in an OO model.

FHIR Resources as an Archetypable RM

The following problems were encountered when representing the FHIR resources as a formal RM for archetyping.

ProblemDescriptionResolution
Complex versus Primitive data typesLack of parent 'data value' type for complex data types - in FHIR, all data types, primitive and complex, are shown as inheriting from a logical 'Any', concretely an 'Element' pseudo-class (e.g. see here). This prevents any ability to distinguish types representing e.g. native Strings from a logical Text type. In FHIR this doesn't appear to matter, but in an object model it forces complex types like 'coded text' and 'quantity' to be siblings of 'integer' and 'string', e.g. in the definition of Observation.value. 
CodeableConcept

CodeableConcept type: includes multiple Codings, which have no qualifying attributes.

For now, replaced by a definition containing a primary coding and 'other_codings' separately.
Extensional type definitions.In many places, FHIR resources contain type definitions consisting of a list of alternative types, e.g. Observation.value has a 'type' of:
Quantity|CodeableConcept|Attachment|Ratio|Period| SampledData|string
For an object model. this presents a problem because there is no parent type whose children are just this set of types.

Model such fields in the RM as being of the nearest defined parent type available, e.g. Any or Resource.

The type list can potentially be included within a reference archetype, but in fact is unnecessary - non-reference archetypes can simply constrain to the needed types.

Resource Reference target type constraintsIn various places, Resource-to-Resource references are shown as being 'typed' to a specific set of concrete types, but it is unclear how even in XML this could be achieved, since target resource type is not part of the definition of a resource reference. Examples: Observation.subject, Observation.performer. 
   



Related content