Authors:

Ian McNicoll,

David Jobling

Heidi Koikkalainen

Affiliation: freshEHR

Version: 1.0.0

Date: 21st May 2024

Analysing traditional data-siloed forms

One of the common challenges faced when developing openEHR-based systems is ensuring maximal re-use of data which, in a legacy form-built application, has been locked into individual forms with limited sharing of data between forms.

openEHR-based systems explicitly separate the application from the data layer, which allows more efficient sharing of information across different forms and applications.

This can be seen as an opportunity to go from a ‘tactical’ approach to data capture to something more ‘strategic’.

• Tactical modelling: Build models and forms that meet the immediate needs of the person/team entering the data.
• Strategic modelling: Build models that try to maximise a holistic perspective on the data, beyond the immediate team, so that information is maximally patient-centric and reusable across different forms.
• Strategic data / Tactical forms: Even if the data is modelled strategically, forms should remain tactical, i.e. sympathetic to the data-entry responsibilities and needs of the immediate user.

openEHR Compositions, Templates and Archetypes

When information is stored in the patient’s record in an openEHR datastore (CDR), it is always stored in one or more Compositions.

The structure and content of each Composition is defined in an openEHR template.

The Composition captures the information that is actually stored in the patient’s record, whilst the template defines what is expected to be captured.

Essentially, the template is the underlying ‘recipe’ for a specific type of Composition.

Templates are constructed of individual components called archetypes, which represent discrete clinical and care concepts, such as blood pressure, body weight and communication capability.

<aside> 💡 A ‘Lab report’ Composition stores information in the patient record about the ordered test and associated lab results and specimen details

</aside>

<aside> 💡 A ‘Lab report’ template defines the datapoints to be recorded in a ‘Lab report’ Composition, e.g specimen details, the name of the lab tests and the results of the lab tests

</aside>

<aside> 💡 A ‘Lab report’ template ****definition is constructed from a set of smaller standardised archetype components, e.g. ‘Laboratory test’, ‘Lab result’, ‘Specimen’

</aside>

Forms and Compositions

All openEHR-based applications read and write information to the record via an open API, and the Better Studio Form Builder is an example of an application which also uses openEHR templates to help build the application, which is normally composed of multiple forms.

In simpler applications, a single Form will often match a single openEHR Composition, but in more complex projects, a Form may need to store/read back information to more than one Composition, or several Forms may read/write to the same Composition.

Splitting a complex dataset across Compositions/Templates

The main challenge is in analysing the Forms and overall dataset to understand how best to split that dataset between multiple Templates, minimising the need to re-enter data.

In working with many different types of openEHR projects, colleagues at freshEHR started to recognise a pattern of information, and have developed a framework called ‘CGEM’ to assist this analysis.

The CGEM Framework