Is it possible to export a template in ADL2 format?
assuming that you mean either from Archetype Designer or Clinical Knowledge Manager, this is something that either @borut.fabjan or @sebastian.garde might be able to answer. I have not come across this function, but there might be something I missed.
There is also some conversion in Archie, see here: Archie 1.0.0 released - OpenEHR Java Library
However, it looks like this is on Archetype level only. Maybe others can add their information here. If I misunderstand your question (which is rather short and vague to be honest), please feel free to elaborate.
thank you for your quick reply.
In the specification of ADL2 there is a section “templates”. My understanding was that I could generate Templates based on Archtetypes and describe them in a ADL2 format. Though when I tried to create a Template with either https://tools.openehr.org/ or CKM there was no option to export those templates in ADL2 format.
Archetype Designer uses ADL2 under the hood and the ‘native json’ format export option gives you something quite close to Jsonified- ADL2. However this is essentially a diff format used internally , and does not include the component archetypes ADL2.
However the question is what do you want to do with an ADL2 template? Right now virtually all of the downstream use (CDR validation, documentations, form building etc) are based on ADL1.4 .opt and web template artefacts that AD exposes.
Understanding how you are hoping to use the template will help us best advise you.
again thank you guys for the quick feedback!
Maybe it’s best if I describe my intend. I want to build a new tooling based on Elixir and the great Ash Framework. I know this is a really big project and probably not doable, though I’m convinced openEHR goes really well with Ash and I’m curious to try.
I need an easy starting point and I thought automatically generating the domain model in Elixir/Ash from the ADL2 format would be great. Unfortunately I couldn’t find any templates in ADL2 format and wasn’t sure why Archetypes are defined in ADL2 and templates have their own format, though there is the possibility to define templates in ADL2.
The whole business of ADL1/2 is a long story but my strong suggestion for what you want to do is to work with the ‘Web template’ format exportable from Archetype Designer - this is derived directly from the ADL1.4 .opt format but in a much more digestible format.
You should probably take a look at the work done by @Sidharth_Ramesh
Also this Web template->ascii doc generator might help orientate you GitHub - freshehr/wt2doc: Asciidoc generator for Archetype Designer web templates
@pieterbos at NEDAP is the master of all things ADL2 but most folks are still working with ADL1.4 formats
What speaks against using ADL2? And is there any reason templates aren’t exportable in that format yet?
Briefly … There are still some adjustments being made to ADL2 ,and the related ADL2 .opt format, and only NEDAP AFAIK has really adopted its use in their CDR. Most of the benefits are on the design-time tooling side, and not on the CDR , or e,g. UI artefact generation.
For your purposes, right now, you would see little benefit in jumping to ADL2. If you get your head around the ADL 1.4 Web template format, you will pick up the main principles of how the openEHR RM works and how it interacts with archetypes . Then jumping to ADL2 will be relatively easy.
I will look into it, thanks for the advice
Archetype Designer can do it, I’ve seen the results. It might not be exposed in the UI at the moment.
You might want to look at the code generation work that @NeoEHR has done.
If you want to build new tooling, you definitely want to use ADL2 natively, not ADL1.4. Archie has done this, but in Java, so the codes a decent guide. Treat ADL1.4 as a legacy format, that can be imported and converted. ADL2 is a lot cleaner and easier to code than ADL1.4. Additionally, a ‘template’ is just another kind of archetype in ADL2. ADL2
Well yes and no. Specialisation doesn’t work properly in ADL1.4, so using it as a native authoring formalism means that some broken archetypes end up in systems. ADL 1.4 is easy enough to convert to ADL2 - my original code does it and so does Archie. There are a whole lot of other problems to do with translations of templates that don’t work with the old (.oet) templates. ADL2 templates fix all that.
The change list between ADL1.4 and AD2 by the way is here.
It depends. It’s quite true that if you are looking to engineer for today’s systems, you’ll need to support adl1.4 AND .oet templates (pretty much all today’s tools do this). But if you are looking to write new modelling tools & new code, definitely do not use the ADL1.4 meta-model as the basis for doing that!
Supporting the web template format is very useful practically for app development. But it’s something else - different code.
wow, thank you for taking your time!
This sounds really exciting!
Forgot to mention this doc. We are not doing things quite like it says (maybe one day), but it will give you a better idea of the relationships of the various kinds of ‘templates’.
And one more thing to say: none of this discussion about archetypes, templates and web templates (aka JSON ‘flat templates’) changes at all for any other information models, including from standards or even other industries. It’s a completely generic problem that surprisingly has not been solved elsewhere.
The AOM/ADL 1.4 is probably more practical nowadays, but AOM/ADL 2 is more future-proof. In your case, I would follow Thomas advice.
If brand new tools and implementations do not follow AOM/ADL 2, then who will do? Moreover if your project is for learning and exploring technologies.
Any reasons for that? I need some ADL2 template examples.
Have a look at archetype-editor.Nedap.healthcare. And especially the advanced ui (button on the bottom).
It’s an adl2 only editor for archetypes and templates.
It has many public repositories with mostly archetypes but surely some templates.
(There is no support for this tool btw. But if you have questions I’ll try to answer here.)
There are some here.
See particularly this one.
I have not checked yet, but the Nedap tool that Joost pointed to should process all of these. They can be processed in the ADL workbench as well.
OPT2 generation in ADL2 is really just inheritance-flattening and then a few extra adjustments.
Would it be possible to create a public auto-updating ADL2 variant of CKM-mirror (containing all archetypes of the CKM but in ADL2 form) as a new separate Github repository under openEHR International · GitHub (@thomas.beale)? Perhaps either by adding a new export pipeline from CKM (@sebastian.garde) or some kind of Github hook that runs Archie (@pieterbos) whenever the current (ADL1.4) CKM-mirror updates?
Now after working practically with ADL1.4 templates and embedded templates quite a bit more for real use cases than I had before, I really miss inheritance and the better multilingual support of ADL2. I also forsee a maintenance nightmare if we don’t switch our template modeling at Karolinska to ADL2 before scaling up to many more use cases.
When we do modelling we usually connect Archetype Designer to a project/usecase-specific branch of our fork of CKM-mirror (actually via a national fork). It would be nice to upgrade this way of working to ADL2.
Speaking from a ckm perspective, we could add an export for the adl2 archetypes to a separate directory of the current repository, using the same directory structure underneath as for 1.4 archetypes, e.g.
- archetypes-adl2 (e.g)
That could work nice, provided that tools like Archetype Designer (and others using CKM-mirror) could switch between directories where to look for Archetypes etc. and ignore the rest (perhaps they already can? @borut.fabjan).
Otherwise it can become confusing with two copies (one of each ADL version) of each archetype, and separate repositories might then be easier. Separate repositories could also mean less dead weight in releases for those only using one of the versions.
Also AD startup seems a bit slower when there are more files to read
I would possibly suggest making the format the top-level branch, i.e. this:
but I guess that would break the paths in the current repo - does anyone rely on them? If not, I would have thought it would be clearer this way, since software just goes into adl1.4 or ad2 and then sees the familiar layout.