I’ve been recently messing around with ADL-designer, and thinking more about how to do application building with templates. A few things are becoming clearer to me. Firstly, templates based on COMPOSITION (or PARTY, PERSON etc, for demographics) are potentially good for data capture, but don’t in general make sense for data retrieval.
For a retrieval data set, e.g. a screen containing a combination of demographics, EHR clinical, other info, we need another kind of container. Let’s call this DATA_SET for the moment, and assume it is defined as follows:
class DATA_SET inherit LOCATABLE
content: LOCATABLE [*]
end
Then an archetype of this could be built for a screen, and it could insert SECTIONS purely for display purposes. Maybe it could include style information. So let’s imagine that instead of just SECTIONs we could use something a bit smarter, like DATA_GROUP. We could then create a template like the following (each included archetype is actually an overlay based on an underlying archetype):
DATA_SET[id1] matches {
content matches {
DATA_GROUP[id2] matches {
name matches {[at20]} -- "Patient details"
style matches {1} -- area; from an enumeration of tabs|menu|area|etc
items matches {
use_archetype PERSON[id3, openEHR-EHR-PERSON.ovl_patient_details_1.v1]
}
}
DATA_GROUP[id4] matches {
name matches {[at21]} -- "Clinical"
style matches {1} -- area; from an enumeration of tabs|menu|area|etc
items matches {
DATA_GROUP[id6] matches {
name matches {[at22]} -- "First trimester"
style matches {0} -- tabs
items matches {
use_archetype OBSERVATION [id7, openEHR-EHR-OBERVATION.ovl_first_trimester_summary_1.v1]
}
}
DATA_GROUP[id8] matches {
name matches {[at23]} -- "Second trimester"
style matches {0} -- tabs
items matches {
use_archetype OBSERVATION [id9, openEHR-EHR-OBERVATION.ovl_second_trimester_summary_1.v1]
}
}
DATA_GROUP[id10] matches {
name matches {[at24]} -- "Third trimester, first part"
style matches {0} -- tabs
items matches {
use_archetype OBSERVATION [id11, openEHR-EHR-OBERVATION.ovl_third_trimester_summary_1.v1] -- overlay 1
}
}
DATA_GROUP[id12] matches {
name matches {[at25]} -- "Third trimester, last month"
style matches {0} -- tabs
items matches {
use_archetype OBSERVATION [id13, openEHR-EHR-OBERVATION.ovl_first_trimester_summary_2.v1] -- overlay 2
}
}
}
}
}
}
``
Notice that now we have demographic data (magenta) and EHR data (blue) easily mixed in; we have a rough screen layout defined, something like two HBOX areas, with the second one having tabs inside for the various pregnancy trimesters.
In this construction, the only real data are the included archetypes; the outer DATA_SET and DATA_GROUPs are just defined structures that are created on the fly by a screen renderer. Different types of DATA_GROUP could be used to provide the UI hints we often talk about - use tabs, use a box with a name, and so on - people familiar with the typical UI elements like HBOX, VBOX, TREE, MENU, MENU_ITEM, DATE_FIELD, TEXT_FIELD (the names differ across UI toolkits) will see that this approach could be used to more or less fully define whole screens. A similar thing could be done to define messages or documents.
Paths through such a structure would effectively be paths to parts of a form (or a message), and could be referenced in other sections of the template to control visualisation.
We could embed the generating queries as well for example:
DATA_SET[id1] matches {
content matches {
DATA_GROUP[id2] matches {
name matches {[at20]} -- first trimester
query matches {
**"SELECT obs**
**FROM**
**EHR[$ehr_id] CONTAINS**
**summary** **COMPOSITION[openEHR-EHR-COMPOSITION.pregnancy_summary.v1]**
**WHERE**
**summary/context/start_dat****e** **>** ``<b>$current_date - P1Y</b>
**"**
}
style matches {0} -- tabs; from an enumeration of tabs|menu|etc
items matches {
use_archetype OBSERVATION [id3, openEHR-EHR-OBERVATION.ovl_first_trimester_summary_1.v1]
}
}
etc
}
}
Doing the above requires adding some new classes to the RM, or a Presentation Model part of openEHR. It seems to me it would make application software development much easier, and substantially more automatable.
I am aware that other people with far more app/UI experience than I have worked intensively on specifying UI forms, application elements and so on, and have some very smart tools for such purposes. I am therefore not really claiming anything new here, just considering ways to formalise such ideas in a way that would make use of existing tools and formalisms that we have.
thoughts?
- thomas
