Hello! I’m just learning about OpenEHR and I’m trying to convert one of our existing questionnaires to OpenEHR. One crucial part for us is the ability for make questions “optional”, i.e. if you answer YES to Q1, then show/go-to Q2, if NO show/go-to Q3. Can/how do you model this in OpenEHR? Is it at the Archetype level? Or the Template level?
2 Likes
Hi Håkan! What you’re describing must be implemented at the user interface level. In archetypes/templates, the corresponding data elements/clusters of elements need to be optional (occurrences 0…x) to be able to disregard them at interface level.
Hej Silje!
Thanks for replying. I realise the rendering must be done at the user interface level, but is there no way to model this logic in OpenEHR? How should the UI code know what answer alternatives should toggle which question? If we want to build a UI layer that can render any template we send, this logic has to come from the template. Otherwise we have to code information about each template into the UI layer?
3 Likes
Hi! A template is intended to be a specification for persisting a data composition, not for autogenerating a (user friendly) UI. It’s recommended to add an additional layer for that, which is what several openEHR vendors such as Better and DIPS have done. At the moment this isn’t part of the openEHR specification though.
Thanks again for helping me navigate the openEHR landscape 
.
We have a use case where we want clinical personel to be able to create forms for capturing health data and then we want our software to render these forms to users. To me OpenEHR templates seem a lot like a “form template” and the fact that you can ask EHRBase to give you an “example” template with filled in values kind of confirmed this, but I’m starting to realise perhaps it is not.
So if you are saying that we need “another layer”, I’m having trouble understanding what the intended workflow should be. Let’s say a clinician updates a template and adds another observation archetype. We then cannot just render this template, but instead a developer always has to sit down with the archetype and manually add logic about when to show this question. And since this cannot be stored in OpenEHR format in any way it then cannot be stored in the CDR either, but needs to be stored somewhere else, which feels sad.
I’m starting to think if we could create some kind of “logical gate” archetype, with references to one or more questions, and then the option to add some kind of child Archetype, to model this. But perhaps we are starting to abuse OpenEHR then?
1 Like
There is, but it has not been stable enough for tool builders to include it. But here is the relevant part of he ADL2 specification, current release.
You can see from the current development version what it may look like in the future - with paths removed from the expressions and symbol-path bindings used instead.
2 Likes
Hi @MacL3an we had several discussions about this topic in the past, e.g. Agreeing on optional user interface hints in templates - #3 by pablo
My opinion is to create a GUI spec on top of templates, which includes rules like the ones you mention. In many cases I don’t think the place for those rules is the template. This spec we’ve been working on covers the layout, rendering and binding of GUI elements with openEHR model elements, it doesn’t include the rules model yet https://discourse.openehr.org/uploads/short-url/5635h3NBrDHbY830w93jctgPsBM.pdf
I hope requirements like yours could speed up the elaboration of such models and the approval from openEHR.
1 Like
There’s an implementation of that in the open source Java library Archie (GitHub - openEHR/archie: OpenEHR library implementing ADL 2, AOM 2, BMM, RM 1.0.4 and many tools) . We developed it and we use it to link directly to our form implementation. That means the logic in the templates or archetypes, is applied directly to the form, making it interactive. You do need to have ADL 2 tooling for that implementation to work, and I do not know of an available CDR that currently supports that. There are options of converting the data and/or archetypes to make it work though.
The logic can be in templates, for questionnaires reusing existing archetypes, needing custom logic. Or it can be in the archetypes - some of the archetypes we use are scores, and the calculation of those scores based on the specific question is inherently part of score.
2 Likes
I should have mentioned this, thanks for responding @pieterbos .
I should also mention that we have recently crystallised a version of the spec that Archie implements that can be regarded as stable and correct (+/- final adjustments).
@MacL3an a bit further down in the thread Pablo mentioned there are some suggestions on how to possibly use annotations to encode the kind of conditions you wish to have, see Agreeing on optional user interface hints in templates - #19 by erik.sundvall The annotations can then be transformed into other formalisms, (including into vendor specific form rules/actoins)
At Karolinska University hospital in some multi vendor use-cases we have the same need as you described, and we don’t want to reimplement the same things over again in each vendor’s own form editor etc. We’d prefer to automate at least some of that based on e.g. annotations in templates. Since we need it fairly soon we’d prefer to start by using annotation features of existing template editors rather than first inventing a specific language, new tooling etc.
You could play around with our editor a bit to learn:
https://archetype-editor.nedap.healthcare
There is some rules support in the nice looking UI. Clicking advanced in the bottom right, gives you an autogenerated interface that allows viewing and editing of the ADL generated by the nice looking ui…
2 Likes
Thanks for all the replies! Nice to see OpenEHR is working on some kind of a solution to this.
Like I said before, our main concern is that we would like our clinicians to be able to create new forms without the need to involve a developer every time. Commenting on @pablo’s suggestion about a separate UI layer, adding UI information about how to render an archetype in another layer seems fine, since this is something you likely do once. However, just like @erik.sundvall is talking about, for us modelling the “path” the user takes in a form is not a GUI thing, but has to do with clinical modelling. For us it is at the same time that (and by the same clinician!) you create a form, i.e. choosing what questions (archetypes) do ask, that you also want the ability to chose when to enable certain questions or not. So if our opinion matters in any way, we would like to see a solution where this logic is part of the template.
2 Likes
You need not worry that the question, or even this preference has or will be forgotten. It is understood in the community, and being actively worked on - separately from the various things that are (probably) GUI preferences / config of some sort.
But thanks for raising it - it’s always good to hear the requirement is important, and gives a bit of urgency 
1 Like