At Nedap we created something similar to let a user/customer (people with little to no openEHR knowledge) create (hundreds) of forms for a clinimetrics application. We use:
A (for now) proprietary very simple adl2 editor.
Automatically generated operational templates based on (observation) archetypes.
A react component that renders âallâ elements in a template
It works well for our usecase. But there are very few ways to adjust layout. Only hiding headings based on annotations for now. The webtemplate brings a lot more to the table here. E.g. not rendering an element but still be able to record generated data on it.
I like the webcomponent better then our react component because we would have liked to use our component in Vue and angular applications.
We use the rules section for (most) of what you do with JavaScript functions. And I wondered wether you have tried the same. (I actually think that the rule to calculate GCS should be part of the ckm archetype, since itâs inherent to the clinical concept of GCS)
Hey @joostholslag
Thank you! I am working towards making the ui elements more universal via webcomponents so that they can be used in any framework of choice.
As for the calculation, the rules are not exported in the webtemplate as far as I know. Iâd love to know how to do this though. So for now, Iâm just using javascript functions. Would definately like to see the work youâve done so that we can share knowledge.
If you have a look at this archetype it has a rules section. Where we set the value of an element based on the value of another element.
(donât look too much at the other design choices, it was rushed with pragmatic concerns priorities way over design quality)openEHR-EHR-CLUSTER.covid_vaccin.v1.4.0.adls (6.6 KB)
Yes. I see them in the adls file under the rules section. In fact, this exact suggestion was made by @thomas.beale too. However, I depend upon webtemplates heavily to do any UI work. Especially the context and validation information.
Currently, the problems I face with implementing this:
a) Creating rules is not supported in the Better Archetype Designerâs GUI and needs to be entered manually by editing the ADL. In fact, importing your archetype fails mentioning the Rules section as the reason Import error: Handler dispatch failed; nested exception is java.lang.AssertionError: com.nedap.archie.aom.RulesSection
So I assume the tooling for rules isnât there yet.
b) The exported webtemplate does not include these rules anywhere.
The web template specification must start including these rules somewhere so that other tools can use them.
The webtemplate specifications need to be finalized at least amongst the popular tools. For now, the only tools that export to web template are:
Better Archetype designer - Probably the first to implement, Great support.
EHRBase(@birger.haarbrandt) - Good support, needs to include inContext information.
The specification for ADL rules has not been terribly reliable, although we retrospectively created a BASE release (1.0.4) that contained an older form of Expressions syntax and meta-model.
Nedap implemented this, and LinkEHR I believe implemented it (or close), but other tool support is patchy and probably not that reliable.
In any case, we are discussing how to specify rules in archetypes properly because it is more subtle than one might think on first look (including me, which is why I never got this part of the specification sorted out earlier
If you can live without rules for a while longer I would suggest to do so, and wait till we crystallise a better form of the spec in the short term (feel free to make suggestions on the thread linked above).
To avoid the problems you mention of archetypes failing to parse, we attached the rules as a separate file (.rules). This could also be the solution if we manage to generate the web template format.
We have yet to decide which web template format to support, but probably we will support the generation of both. That or just go to the Archetype designer one.
I think the reason for the missing âinContextâ information is that we did not understand how this can be derived from an OPT. If there is a need and the relationship is clear, we will be happy to add this as well.
Hi @birger.haarbrandt,
The inContext information is very useful to know what to display to the end user for data entry vs what information to infer automatically and not ask the user for.
I donât know how Better does it either. But itâs very important information. Without which proper forms cannot be generated.
@stefanspiska did say that heâll be working on it:
Maybe someone here can help describe how to identify which fields are actually from the archetypes and which are part of the context information? I donât mind doing a client side implement either. If only I can figure out how.
We assume that everything coming from the archetype has an atcode, and if not, it comes from the RM. Thatâs one of the reasons we put atcodes on every single node
