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 question raised here is how to define re-usable data sets in a coherent way for application forms, Task Planning, GDL3 and other uses.
The following diagram illustrates a possible model of data retrieval.
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:
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.
Rough ideas on specifying a binding using the above model.
DATA_SET antenatal_1.v1.0.3
items
SINGLE
name = "date_of_birth"
type = "Date"
value = Result
SINGLE
name = "systolic_bp"
type = "Quantity"
currency = "PT2m"
value = Result
SINGLE
name = "diastolic_bp"
type = "Quantity"
currency = "PT2m"
value = Result
SINGLE
name = "is_type1_diabetic"
type = "Boolean"
value = ???
binding["env_A"]
data_set = antenatal_1.v1.0.3
DATA_RETRIEVE_FRAME
frame_id = "basic_admin"
method
QUERY_CALL
system_id = pas3.nhs.org.uk
call_name = fhir_admin_request
parameters
"xxxx = abc"
"yyyy" = "def"
bindings
"date_of_birth" = "/path/to/dob"
DATA_RETRIEVE_FRAME
frame_id = "bp_obs"
method
QUERY_CALL
system_id = ehr1.nhs.org.uk
call_name = aql_execute
query_text = "xxxx"
bindings
"systolic_bp" = "/data[id2]/events[id7]/data[id4]/items[id5]"
"distolic_bp" = "/data[id2]/events[id7]/data[id4]/items[id6]"
DATA_RETRIEVE_FRAME
frame_id = "is_type1_diabetic"
method
QUERY_CALL
system_id = ehr1.nhs.org.uk
call_name = aql_execute
query_text = "xxxx"
bindings
"is_type1_diabetic" = "/data[id2]/items[id3]"
|