Yesterday I asked if anybody had any motivated objections to using the openEHR template formalism as a layer to catch some GUI-hints/rules. I bring it up again to get some response
The point to have separate concerns in separate artifacts is often good. Regarding GUI-hints it seems reasonable to not have them at the clinical archetype level, and in some cases not at a first clinically focused template level either. But, as we have discussed earlier, through specialisation and/or inclusion it’s possible to have several layers of openEHR templates.
This means that ADL or some other serialisation format of the archetype object model (that now will include templates) can be used for GUI-related annotations and GUI-related logic in some form. Does anybody have concerns or worries regarding this?
You could still have separate artifacts by splitting reusable clinical modeling and use case specific GUI modeling in separate layers of templates.
A nice thing with reusing the template formalism for catching GUI stuff is that shared tools and understanding is already in place as opposed to inventing some new purely GUI-related formalism. Also in some cases it’s likely that the same groups that are designing archetypes and clinically focused templates will have knowledge of some use cases in which they know what they’d want to happen on the GUI side. Then it would be nice to be able to reuse people, tools, template governance repositories etc.
P.s. (off topic)
I’m not sure it’s always optimal to split everything into separate artifacts, especially when it comes boundary problems like terminology bindings. You could argue that the binding should be done in a separate artifact that is neither part of archetypes nor part of terminologies, but I’m not sure that would always make things better. Having the bindings in the archetype forces the archetype authors to revise the bindings at the same time as they revise an archetype and that might be good.
On the other hand you could argue that a SNOMED CT refset might be exactly such a third artifact that can be used for managing bindings. But if you would have three different groups maintaining archetypes, refsets and terminology systems then you’d better keep them very well aware of each other’s actions…
In the past months we have talked about the scope of each artifact. One thing that is clear is that we can have structural templates and GUI templates, that can be defined, shared and used separately, but GUI templates can rely on structural templates, as structural templates rely on archetypes.
Hi Eric, good points…As you may remember we had this discussion on this list not so long ago and I don’t remember any action taken after that. I guess we should take lead and come up with some proposal. Perhaps it’d be good to have a wiki space - but I want to repeat myself: someone from core group must guide the group and provide early feedback whether we are on the right track or not.
I think we are the core group, and if we can agree some basic notation of some basic GUI directives (there are some thoughts of mine on the wiki: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates) and can implement them in a consistent way (we all use heterogeneous technologies), we can lead the definition and improvement of this inside the standard.
We have to options: 1. keep waiting for some “signal”, 2. think outside the box and take the lead.
Any one who want #2 and have time to work can drop me a line to coordinate the required work, share experiences and colaborate on this subject.
Hi Eric, good points…As you may remember we had this discussion on this list not so long ago and I don’t remember any action taken after that. I guess we should take lead and come up with some proposal. Perhaps it’d be good to have a wiki space - but I want to repeat myself: someone from core group must guide the group and provide early feedback whether we are on the right track or not.
Hi Eric, good points…As you may remember we had this discussion on this list not so long ago and I don’t remember any action taken after that. I guess we should take lead and come up with some proposal. Perhaps it’d be good to have a wiki space - but I want to repeat myself: someone from core group must guide the group and provide early feedback whether we are on the right track or not.
The further we (GastrOS team) delve into GUI generation from templates/archetypes, we’re increasingly facing the question: “where is the line between the domain model and program behaviour?” I have a feeling that especially in modern software systems (clinical ones included) there is an increasing expectation for rich user experiences and basically a movement away from rigid CRUD-type interactions (where the choice of GUI elements are effectively driven by the underlying data model) to a more fluid set of interactions that essentially puts the user in charge (so almost every piece of functionality is accessible from another in one or two steps).
So what this means in terms of modelling is that often having the domain model defined is nowhere near enough to define the complete set of program behaviour (and hence the working program itself). And often the two (model and behaviour) are intricately linked, especially from the user’s perspective. In fact, my experience and intuition is that users nowadays tend to think more in terms of what they want the program to DO, than what the program should HAVE. So things like “I want it to pop up a dialog here, when I click this, and when I’m on this form I want to be able to edit this and that”.
What we have tried to do so far was to effectively include all of this “interaction” stuff into the template (as annotations) so as to retain the ability to completely and dynamically generate a fully functioning GUI from the model alone. So far we have managed it successfully, largely thanks to the relatively structured and uniform degree of user interaction mechanism that’s sufficient for our system requirements. But yes, if we were to try building say a PMS just from our models, that’d be pretty crazy.
I do think it’s wise to separate the “behaviour” stuff out of the model, and come up with a solid formalism for expressing it. As Seref and others point out, the more we clutter the model with program-specific concepts, the less reusable they would be across different usage scenarios. But I think we do need to probe deeper into the question of, again, what’s the distinction between data model and behaviour? In ADL we already have mechanisms for expressing ceratin kinds of constraints, and there would be a natural expectation for the GUI to filter out the user interactions so as to prevent the model from violating these contraints. E.g. disable an input field at certain times. So is that considered behaviour, or part of model? That’s the kind of distinction I’m talking about.
I hope I’ve articulated the issue clearly enough.
