...
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:
| Code Block | ||
|---|---|---|
| ||
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):
| Code Block | ||
|---|---|---|
| ||
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.
...
We could embed the generating queries as well for example:
| Code Block | ||
|---|---|---|
| ||
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_ |
...
date > $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.
...
Existing Data-set / Visualisation Models
TBD