Gerard Freriks +31 620 34 70 88 +31 182 22 59 46 gf...@luna.nl
Kattensingel 20 2801 CA Gouda the Netherlands > On 29 Nov 2018, at 11:47, Thomas Beale <thomas.be...@openehr.org> wrote: > > On 28/11/2018 17:56, Pablo Pazos wrote: >> Do we need the user in the middle? > we could, although I learned a long time ago to only include relevant > elements, and the point of this diagram is just one thing: where the models > of information are made, and how they relate to the built system. > What is needed is the last linking pin: the standardised Archetype patterns that are used to create libraries used to produce (local) Templates. The RM allows too many degrees of freedom to model things. We need a set of Modelling rules to create the set of standardised Archetype Patterns. Patterns that provide models/metadata for living and non-living things (such as: buildings/rooms, devices, medicinal products, …) Patterns that provide models/metadata for the documentation of medical Care processes: Observation, Evaluation, Planning, Ordering, Execution. Patterns that support co-operation, scheduling, etc. Patterns that define absolute/relative times and locations Patterns that define possible results in a quantifiable, semi-quantifiable or qualifiable way Patterns that … >> >> Another point, I always thought that diagram lacks some management, for >> instance the developer is not who manages the IT aspects of the system >> running in production, makes deployments, updates, etc. > well then we are into the cycle of software management, I'm not trying to > represent any of that, just to show in a relatively simple way how the models > relate to the system. > >> >> And thinking about this, there are at least two main flows: one is >> design-development-use, and the other is maintenance-evolution. I think the >> second one might be even more important than the first one, where domain >> experts get feedback from the users, and the IT team gets feedback from >> users and domain experts, for instance to make changes or create more >> reports or add UI elements. IMO this second flow is what gives openEHR a lot >> of value. > also true - but I would make a second diagram to show UI / UX feedback loop > and evolution. > >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
