# Export Template in ADL2 format **Category:** [ADL](https://discourse.openehr.org/c/adl/40) **Created:** 2023-02-15 11:23 UTC **Views:** 1151 **Replies:** 28 **URL:** https://discourse.openehr.org/t/export-template-in-adl2-format/3572 --- ## Post #1 by @n0gg1n Is it possible to export a template in ADL2 format? --- ## Post #2 by @birger.haarbrandt Hi @n0gg1n, 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: https://discourse.openehr.org/t/archie-1-0-0-released-openehr-java-library/1599 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. --- ## Post #3 by @n0gg1n Hi @birger.haarbrandt, thank you for your quick reply. In the specification of [ADL2](https://specifications.openehr.org/releases/AM/latest/ADL2.html#_templates) 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. --- ## Post #4 by @ian.mcnicoll Hi Jannik, 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. --- ## Post #5 by @n0gg1n Hi Ian, 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](https://www.ash-hq.org/). 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. --- ## Post #6 by @ian.mcnicoll 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 https://github.com/freshehr/wt2doc https://docs.medblocks.org/medblocks-ui/concepts @pieterbos at NEDAP is the master of all things ADL2 but most folks are still working with ADL1.4 formats --- ## Post #7 by @n0gg1n What speaks against using ADL2? And is there any reason templates aren't exportable in that format yet? --- ## Post #8 by @ian.mcnicoll 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. --- ## Post #9 by @n0gg1n I will look into it, thanks for the advice :slight_smile: --- ## Post #10 by @thomas.beale [quote="n0gg1n, post:3, topic:3572"] Template with either https://tools.openehr.org/ or CKM there was no option to export those templates in ADL2 format. [/quote] Archetype Designer can do it, I've seen the results. It might not be exposed in the UI at the moment. [quote="n0gg1n, post:5, topic:3572"] I need an easy starting point and I thought automatically generating the domain model in Elixir/Ash from the ADL2 format would be great. [/quote] You might want to look at the code generation work that @borut.jures has done. [quote="n0gg1n, post:5, topic:3572"] I want to build a new tooling based on Elixir and the great [Ash Framework ](https://www.ash-hq.org/). 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. [/quote] If you want to build new tooling, you definitely want to use ADL2 natively, not ADL1.4. [Archie](https://github.com/openehr/archie#readme) 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 If you like weird languages, you can also look at the [original ADL2 code](https://github.com/openEHR/adl-tools) that I wrote, in Eiffel, which is the language in which the [ADL Workbench](https://openehr.github.io/adl-tools/adl_workbench_guide.html) is written. [quote="ian.mcnicoll, post:8, topic:3572"] Most of the benefits are on the design-time tooling side, and not on the CDR [/quote] 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](https://openehr.atlassian.net/wiki/spaces/ADL/pages/1278438/Evolution+from+ADL+1.4) by the way is here. Some [ADL1.4 problems described here](https://openehr.atlassian.net/wiki/spaces/ADL/pages/386007133/Common+ADL+1.4+Archetype+Bugs?focusedCommentId=393248773). [quote="ian.mcnicoll, post:8, topic:3572"] 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. [/quote] 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. --- ## Post #11 by @n0gg1n wow, thank you for taking your time! This sounds really exciting! --- ## Post #12 by @thomas.beale Forgot to mention [this doc](https://specifications.openehr.org/releases/ITS-REST/latest/simplified_data_template.html). 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. --- ## Post #13 by @damoca I can agree with both @ian.mcnicoll and @thomas.beale 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. --- ## Post #14 by @n0gg1n [quote="thomas.beale, post:10, topic:3572"] Archetype Designer can do it, I’ve seen the results. It might not be exposed in the UI at the moment. [/quote] Any reasons for that? I need some ADL2 template examples. --- ## Post #15 by @joostholslag 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.) --- ## Post #16 by @thomas.beale [quote="n0gg1n, post:14, topic:3572"] Any reasons for that? I need some ADL2 template examples. [/quote] There are [some here](https://github.com/openEHR/adl-archetypes/tree/master/Example/openEHR/single_file_template). See particularly [this one](https://github.com/openEHR/adl-archetypes/blob/master/Example/openEHR/single_file_template/templates/openEHR-EHR-COMPOSITION.t_clinical_info_ds_sf.v1.0.0.adls). 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. --- ## Post #17 by @erik.sundvall 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 https://github.com/openEHR (@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? Background: 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. --- ## Post #18 by @sebastian.garde 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. CKM-mirror * local * archetypes * cluster * composition * ... * archetypes-adl2 *(e.g)* * cluster * composition * ... * templates * ... * remote * ... --- ## Post #19 by @erik.sundvall 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 --- ## Post #20 by @thomas.beale I would possibly suggest making the format the top-level branch, i.e. this: * adl1.4 * local * etc * remote * etc * adl2 * local * etc * remote * etc 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. --- ## Post #21 by @erik.sundvall HI! I believe many may have set up tooling seetings, pipelines and are working git-forks+branches using the current directory structure of CKM mirror, so it would be quite disruptive to rearrange directory structure. Are there any drawbacks at all with the alternative idea to just start another parallel sibling Github-repo (named "CKM-mirror2" or similar) with exactly the same directory structure as the current CKM-mirror , but with the difference that all content is based on ADL2 instead of ADL 1.4? I believe most organisations will use either ADL1.4 or ADL2 for any specific modeling session/task, with two repos you just pick the one you prefer for the session/task at hand. --- ## Post #22 by @thomas.beale That's the obviously better version of what I suggested ;) --- ## Post #23 by @sebastian.garde Yes, I would not want to rearrange the current directory structure without giving it a lot of thought first for the reason Erik has given. Regarding one or two repositories: I would much prefer to have the CKM export in one git repository. Use cases will differ and I guess you could easily point to the path within a git repository if required. --- ## Post #24 by @erik.sundvall [quote="sebastian.garde, post:23, topic:3572"] Regarding one or two repositories: I would much prefer to have the CKM export in one git repository. [/quote] Could you elaborate a bit on why one repo would be prefrerable to two? (I'm just curious and trying to understand.) Remember that we are now discussing a complete converted copy of all the ADL1.4 assets turned into ADL2 variants. --- ## Post #25 by @thomas.beale The same effect could be achieved by having and ADL1.4 to ADL2 converter run on a server that is triggered by a CKM-mirror webhook, and performs the conversion and commits the changes to a CKM-ADL2-mirror. The Archie code to do that (or even my old Eiffel code) could be built as a command-line tool to do only that, so probably not that hard. But I would have thought that if the ADL2 conversion is running routinely inside CKM anyway, a second commit to another repo would not be problematic. --- ## Post #26 by @sebastian.garde To me it seems the most flexible and also easiest approach, just take what you need. If someone really needs an adl2 only repo because a downstream tool cannot deal with it otherwise: I would imagine that a trigger that simply copies the adl2 directory to a separate repository would be a lot easier to implement than doing the conversion as well outside ckm: One problem with doing the conversion outside CKM is the conversion log which you need to make consistent decisions across the archetype revisions about synthesised node ids. --- ## Post #27 by @joostholslag Be careful that the archie algo makes arbitrary assumptions when converting. (Adding at codes in 9000 range). so different algorithms for conversion probably result in different archetypes with different paths. This is a potential nightmare. For now I suggest using archie only for (CKM) conversions. And ideally we specify the algorithm in such a way that the results for any conversion are equal. --- ## Post #28 by @erik.sundvall @sebastian.garde's suggestion of triggering a partial (ADL-version specific) copy sounds excellent, then all conversions are made by the CKM and the risks described by @joostholslag above can be handled there in one place in a more controlled manner. So what about something like this: * CKM-mirror will contain the mix suggested by @sebastian.garde (new directories added and exsisting ones not changed) * CKM-mirror2 could contain only ADL2 variants * CKM-mirror1 could contain only ADL1.4 variants For tools (and pipelines) that read the content of all subfolders under a specific root, either the CKM-mirror1 or CKM-mirror2 can be chosen to work from (depending on your version preferences) in order to avoid getting confused by two instances of every archetype. --- ## Post #29 by @borut.fabjan Hi all, just to confirm, AD supports ADL2. ![Screenshot 2023-04-17 at 08.30.01|690x370](upload://59BN7KIHG8X3NgJPEcVTNlISRHx.png) It might be a bit rough over some edges, but you can import, edit, create ADL2 archetypes. --- **Canonical:** https://discourse.openehr.org/t/export-template-in-adl2-format/3572 **Original content:** https://discourse.openehr.org/t/export-template-in-adl2-format/3572