Re: Two-level modelling diagram

[GF]

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  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

Re: Two-level modelling diagram

[Thomas Beale]

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.




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.


You can try to make some variations, just use the draw.io source at 
Github 
.


- t


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Two-level modelling diagram

[Thomas Beale]

I was already on it ;) (FWIW, I habitually leave out terminology from 
diagrams only because it's so pervasive that putting it in properly 
would always turn a simple piece of sushi into a bowl of spaghetti...)


For people who want the document context, and another well-known 
diagram, see here in the Architecture Overview 
.


- thomas

On 28/11/2018 13:28, Bakke, Silje Ljosland wrote:


I also like this diagram a lot, big improvement on the old one! 

Would it be relevant to add a cylinder for terminologies in the 
knowledge development environment part (with arrows to archetypes and 
templates), to show explicitly that they’re thought of and highly 
relevant?


Regards,

*Silje*



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Two-level modelling diagram

[Bakke, Silje Ljosland]

I also like this diagram a lot, big improvement on the old one! 

Would it be relevant to add a cylinder for terminologies in the knowledge 
development environment part (with arrows to archetypes and templates), to show 
explicitly that they’re thought of and highly relevant?

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Gunnar Klein
Sent: Wednesday, November 28, 2018 2:22 PM
To: For openEHR technical discussions 
Subject: Re: Two-level modelling diagram

I liked much of the figure but why do you have to cylinders for value sets. 
Should be better with one like for templates.
kind regards
gunnar

Den ons 28 nov. 2018 13:23 skrev Thomas Beale 
mailto:thomas.be...@openehr.org>>:



This diagram 
<https://www.openehr.org/releases/BASE/latest/docs/architecture_overview/diagrams/two_level_engineering.svg>
 (SVG) is a replacement for an old one used in a lot of papers. People who want 
a better diagram might like this one, from a more recent version of the 
Architecture Overview.

[cid:part2.295C89A2.4740AC48@openehr.org]
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto: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

Re: Two-level modelling diagram

[Gunnar Klein]

I liked much of the figure but why do you have to cylinders for value sets.
Should be better with one like for templates.
kind regards
gunnar

Den ons 28 nov. 2018 13:23 skrev Thomas Beale :

>
> This diagram
> (SVG)
> is a replacement for an old one used in a lot of papers. People who want a
> better diagram might like this one, from a more recent version of the
> Architecture Overview.
>
> ___
> 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