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 **> ***$current_date
- * P1Y**
** "*
}
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
--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Team, Intermountain Healthcare
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/>
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
