If it was to me to design, I would not change the RM. In fact, I think the
RM has already classes which do not belong there in my opinion.
I think of AuthoredResources, TranslationDetails, they belong in the AOM.
The RM should not be a myriad of classes used left/right in the OpenEhr
system.
We should leave the idea of OpenEhr being a single system. It is an
anti-pattern in the microservices paradigm.
Too many dependencies, too much code replication, the monolithic kernel
paradigm should be left.
So I favour an AOM with no shared dependencies with the EHR RM. The same
idea for the Form classes. Have an own class system with no dependencies
outside the system.
But the idea of a Form RM / template I think is very good, and can be a
great help for software designers when tooling supports it.
I will study the specs tomorrow, this was what came to mind when I saw your
post
Best regards
Bert
Op 17 feb. 2018 20:07 schreef "Thomas Beale" <thomas.be...@openehr.org>:
> 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
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
