The specification website clearly details out about ADL 2 and Operational Templates with ADL 2 artifacts. But I could not find example templates to fiddle with. Where can I find OPT 2 format of templates?
Thanks! 
2 Likes
@pieterbos is the expert here as well as @thomas.beale. I think the opt2 is still not quite there but these guys will advise.
It will help if you can give a bit of background as to what you are trying to do and your skillset.
Ian
1 Like
Thanks for the fast reply!
A while back, I was experimenting with OPT templates with ADL 1.4. I wrote a script to build ArchetypeDefinition from the OPT file. They come handy as they are already flattened . I downloaded some OPT files from the ckm.openehr.org manager.
But I could not find OPT 2 versions of these templates in the ckm manager.
Are there any ADL 2.x template definitions that I could use for test purposes?
Templates are just regular archetypes with the word template above it instead of archetype, and possibly with template overlays added. It is specified in the ADL 2 and AOM 2 specification. We have an editor available, but it is not yet generally available and it’s for advanced users only for now.
From this template - or really from any archetype - you can generate an OPT 2. That is again a regular archetype, but the operations defined in the OPT 2 specifications have been applied to it. It basically means you need only this single artifact, instead of a list of several archetypes, to use it. Useful if for example you want to render a form.
The OPT generating process is automated - you never do this by hand. If you need this, you can use the Archie library, https://github.com/openehr/archie . If you’re not using java, you can still generate the OPT2 using archie, then serialize it to ADL, JSON or XML and parse it again in your own library. It’s the just the archetype object model, so if you can parse that, you can parse OPT 2.
You basically only need the missing parts of the OPT 2 specification if you want to write the conversion from archetypes or templates to OPT 2. The object model itself is just AOM 2, and all you need to actually use the operational templates is in the ADL 2 and AOM 2 specification.
3 Likes
So if you need examples, just pick any archetype, create an OPT 2 and use that 
For templates you’ll have to author your own for now. I’m looking into developing a 1.4 -> 2 template converter, but that is not available yet.
1 Like
Hi Pter in some ways the reverse would be more helpful right now ADL2-> 1.4 .opt as virtually all of the current CDRs are on 1.4 and it will take quite a long time for them to move to .opt2 . Getting the tooling into ADL2 (especially templates) feels like a more tractable path.
Here are some test ones, useful just to look at (browse around in those directories).
@pieterbos probably has more test ones.
In terms of tools to visualise, you can still use the ADL Workbench if you are on Windows (I’ll have a new Linux build up soon too).
Archie is more modern - not sure of the current status on an available front end - @pieterbos?
Since almost every written template is in OPT/OET format, I think we need some way to go to ADL 2 here first. The conversion back is useful, but to migrate to ADL 2 you really need to be able to migrate your existing data.
2 Likes
I think we agree.
- Get onto ADL2 ,for templates especially, so that we can lose ‘.oet’
- A critical part of that will, I think to be able to continue to pump out adl1.4 .opt for existing CDRs
- Essentially we will be in phase of ADL2 in the design space and 1.4 .opt in the CDR space.
That will give us time to iron out issues, start exploiting new features in the design space without having to force implementers to quickly.
At some point there will be features that ADL2 provides that cannot be supported or back-ported to 1.4 .opt and industry will have to decide to make the jump to .opt 2. Of course pioneers like you guys will be ahead of that curve!!
2 Likes
May I add
- Ensure ADL2 can express what oet can, especially finalising the discussion around limit-to-list and more generally extensible coded texts, as well as the (poorly named) hide-on-form.
3 Likes
Yup let’s try to nail this down - can you put the link to your earlier topic - It was good stuff but lousy timing!!
From what I recall these were some of the primary issues that led Better to not fully adopt ADL2 inside AD.
1 Like
Is there any update on this topic, still the same situation?
Am I right to say when it comes to template, it’s still pretty much ADL 1.4?
2 Likes
Hi Rong,
It is all a bit behind the scenes right now but we are making steady progress, I think. The various tooling suppliers have also been putting considerable effort into making sure that the current .oet format, including things like embedded templates is properly supported across the tools. There are still some niggles with MD5 hash handling, which we are working on, though this is not a .oet problem per-se. It is quite tricky to resolve completely but we think we may have found a route, and the latest version of CKM make resolving these mis-matches a but easier.
There is general willingness and enthusiasm across the tooling suppliers to make the move to AOM2 artefacts (like ADL2 or json/xml serialisations), particulary to replace the .oet format for templates.
Better already use a json serialisation of AOM2 under the hood (‘native json’). It is not 100% pure AOM2 , as they identified some gaps and issues in the AOM/ADL2 spec which removed some useful aspects of .oet , particularly around valueset handling. These were discussed at a SEC meeting in Germany some years ago and SEC has been wrking to resolve the issue and update the ADL2 spec.
AFIK these have now all been agreed and we are probably now in a position to jointly explore how to jointly move forward to get AOM2 templates as the preferred format for the template definitions.
The next challenge will be to understand how/if/when we can think about moving to an ADL2/AOM2 .opt format. That is a bigger decision since , of course, right now all of the CDRs (AFAIK) only understand ADL1.4. The good news is that the ADL2->1.4 .opt generation works extremely well.
For me, right now, .opt2 is less important. Getting the design-time layer transitioned provides considerable value and we need to get that bit right first, especially for templates.
So… pretty close to making the jump, for real
4 Likes
Hi Ian,
Thanks for a comprehensive update of the status of ADL2 support, and the roadmap towards full ADL2 support. I am sure others in the community will no double benefit from this insightful summary. Really appreciated!
2 Likes
Since our CDR, and our archetype/template editor at Nedap supports only adl2. And I’m used to reading only adl2 archetypes/templates. I’m really looking forward to the rest of the community moving to adl2.