OPT 2 templates in ckm

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! :slightly_smiling_face:


@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.


1 Like

For reference, the OPT2 spec - which is not complete, and needs some work - is here.

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.


So if you need examples, just pick any archetype, create an OPT 2 and use that :slight_smile:

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.

1 Like

I think we agree.

  1. Get onto ADL2 ,for templates especially, so that we can lose ‘.oet’
  2. A critical part of that will, I think to be able to continue to pump out adl1.4 .opt for existing CDRs
  3. 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!!

May I add

  1. 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.

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