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.
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
(attachments)
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
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
Do we need the user in the middle?
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.
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.
My 2 cents.
(attachments)
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 <https://github.com/openEHR/specifications-BASE/blob/master/docs/architecture_overview/diagrams/multi_level_modelling.xml>\.
- t
Gerard Freriks
+31 620 34 70 88
+31 182 22 59 46
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
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 …