Applications, Retrieve Data sets and Bindings

Problem

All applications, application forms, as well as particular kinds of application like Task Planning and GDL require ‘subject data sets’ to do their work. At the application level, these data sets usually consist of a number of typed data items, that are usually logically atomic but may be internally structured. These items may be located within another structure, such as a visual form structure.

There is a general problem for specifying such data sets, since each item in the data set may differ in the following attributes:

• source data group: come from different committed data, e.g. one element is a vital sign, another is a date of birth, another is a Boolean representing patient diabetic status

• currency: need to be refreshed at different rates, e.g. vital signs need refeshing at minutes / seconds time domain, patient weight on days/weeks basis, and date of birth never;

• retrieval method: some items in the data set may be the result of running a query, others may require a certain kind of API call; or a more general view is that all retrieval is API calls, but to differing APIs, and therefore according to different rules, type systems etc.

Other factors complicating a simple model of retrieval:

• naming and typing may need to be transformed on the way from the back-end to the front-end;

• application data set items are typically buried inside larger structures that were committed to the back-end systems;

• the data source might not be openEHR - it might be HL7 messages, FHIR, or some other kind of data, e.g. MPI query result.

Further, we need to be able to deal with things like:

• unavailable (null) data

• possible need for looking at effective (clinical) time of a data item, e.g. a diagnosis.

The Challenge

The question raised here is how to define re-usable data sets in a coherent way for application forms, Task Planning, GDL3 and other uses.

A Model of Retrieval

The following diagram illustrates a possible model of data retrieval.

Open

In the above, some useful practical subtypes of DATA_SET_ITEM have been provided, addressing:

• single value

• list of values

• time-series of values, i.e. series of time-stamped values

To get an idea of the data in a real system using this model of data retrieval, the following provides a simple example:

Open

In the above, the ‘application data set’ for a Task Plan or GDL3 guideline is shown on the left. The intermediate representation of the systolic_bp and diastolic_bp variables within an application data set (blue, centre) and in the retrieval structure of the data set (orange, right) is shown.

In order to be able to create re-usable application modules, e.g. Task Plans, GDL guidelines, UI forms etc, these latter cannot directly contain the meta-data needed to enable the data retrieval to work for particular back-end systems.

A Specification Model

Rough ideas on specifying a binding using the above model.