Does anybody know about the whereabouts of the OPT1.4 specification? When I click the link on https://specifications.openehr.org/,I always get directed back to the same page.
Johannes,
There is not yet such a thing. We are right now having a discussion on openEHRspecs Slack about getting a (short) specification written and/or modifying an existing specification. For now, I suggest you post your precise questions, there are experts out there who will respond here. @sebastian.iancu knows where all XML resources are, so could probably help.
At some point we had some artefacts I think. Opt 1.4 came to be as a feature of our template designer and it was not specified anywhere as far as I know. I remember talking to Heath about some artefacts but it was a long time ago. @sebastian.garde does it ring a bell?
Thank you for your fast reply 
Iām working on an converter, that shall create multiple archetypes and put them together to a single OPT file.
Currently, Iām trying to use the java-libs implementation (https://github.com/openEHR/java-libs) to create Archetypes.
Iām new to openEHR, so Iām not so sure how to create a Template programmatically or āflattenā these into an .opt file. As far as I can see, there exists already a āFlattenerā class, which apparently takes an XML-Beans object called āTEMPLATEā, which seems to be derived from the OET file specification. For me, it unclear where I can find the specification of this format. The AOM 1.4 specifications are also mentioning a Template Object Model (TOM), is there any documentation on this?
As I said above, the opt is an XML artefact that is generated from the template (oet) by modelling tools. In the beginning it was only our (Ocean) tool that did this and this functionality was not exposed as a library.
Iām not aware of the flattener youāre talking about, but I suspect it was written by the Archie team targeting ADL 2.0. I would not expect that to work for 1.4 @pieterbos would be able to confirm.
I think our implementation used XSLT to go from OET to OPT. I know Better (ex Marand) team implemented this in their own tool but I donāt know if they made it available as a library @matijap would be the person to ask/confirm.
So you may be stuck if your aim is to go from an adl 1.4 template to a 1.4 opt. Sorry to be the bearer of bad news on a friday evening (London time at least).
Best I know is here: http://ckmopt45.azurewebsites.net/operationaltemplatebuilderservice.asmx?WSDL
The main response part of it is pretty much the opt 1.4 definition (syntactically at least):
We do a few things with xslt where the opt is the input (such as generating the various template views in CKM), but the oet -> opt transformation itself is not xslt-based as far as I know.
2 Likes
@Seref There is a flattener in the ADL 1.4 openehr reference implementation, but we did not write it. Itās located at https://github.com/openEHR/java-libs/blob/master/oet-parser/src/main/java/org/openehr/am/template/Flattener.java . Apparently it converts an OET format into the archetype object model.
Now if you want to generate OPT 2, I can help. The Archie library can generate OPT 2 by combining ADL 2 archetypes or templates, or it can even convert ADL 1.4 to ADL 2 then to OPT 2, which can then be serialized into ADL, JSON, XML or even ODIN. But it does not support OPT 1.4, which is very different from OPT 2.
1 Like
Thank you all for your fast responses!
@Seref We actually bought the Better platform, but my contact at Marand told me that this is only implemented inside the Archetype Designer and not exposed as a Java API, so he is not really sure if it is possible with their tools.
@pieterbos Unfortunately, I need OPT 1.4, so I canāt use Archie. I didnāt think that far ahead, but I think youāre right, it looks like there is no way to serialize the flattened Archetype as OPT-file in java-libs. However, the OPT-File seems to contained at Template.xsd, while the OET-file is specified as CompositionTemplate.xsd. So maybe I could write my own serializer based on the flattened Archetype, it looks like it isnāt too different from the ADL-XMLā¦
If my memory is correct, the OPT schema is a very thin wrapper around the ADL schema. BTW @pablo did some work around generating opts in the past I think, at least I seem to remember discussing this in an email thread with him. Pablo? any comments?
Thanks Johannes,
That background is very helpful. If you have access to the Better tools, Iām not sure that I understand the need to develop a separate .oet-?.opt generator. The .oet was never well documented and I know that it is quite challenging to crete reliably. AD now does this very well but it as taken some time.
So Iām just not quite clear on why you want to go down this road? I do understand that we are all going to need 1.4 .opt for some time, and perhaps a .opt2 to .opt 1.4 convertor (or at least ADL2 - > .opt 1.4) would seem to me to have more future value.
I want to create a generic ODM converter, that generates archetypes for ODM StudyEvents, Forms and ItemGroups and generates a template containing all of them. The Better Platform Java tools for developers are as far as I can see only focusing on the work with fixed templates, and I canāt use the ArchetypeDesigner, since I want to generate the templates in Java code.
So is the idea to create archetype that essentially replicate these ODM concepts? If so where do 'normal archetypes fit in?
As I understand it, an .opt is basically a bunch of archetypes serialised in XML with a parent wrapper, so you might be best to work in directly generating the .opt but perhaps I am misunderstanding the requirement.
The OPT has a slightly different model than ADL in 1.4. I did a reverse engineered model in https://github.com/ppazos/openEHR-OPT from the OPT XSDs. Also made some improvements to those XSDs. We need to work on the spec to have the model formally specieied somewhere. Iāll take a look next week, because we also need that for HiGHmed.
Our toolset also might be useful to work with OPTs http://server001.cloudehrserver.com/cot/
2 Likes
Thanks @pablo , whom I cannot thank with less than 20 characters due to discourse settingsā¦
1 Like
By the way, we have actually created CDISC ODM archetypes in LinkEHR editor. Iām not sure if ODM reference model is currently included with the distribution, but I can provide it to you without any problems.
Yes, thatās a work we made in 2012 (!). CDISC ODM is a nearly perfect RM candidate to work with archetypes. We created native ODM archetypes and used them to transform legacy data into ODM instances. An interesting work starting from there would be to map and transform ODM archetypes and instances to openEHR.
You can find a presentation about that work here:
4 Likes
I didnāt consider changing the reference model, but that sounds very interesting. As far as I can tell, it is not contained in the LinkEHR editor. But will these archetypes, which are based on a different RM, work with other tools?
Probably most generic tools like the Archetype Workbench can open them, but probably in general itās a ānoā. We use the ODM archetypes to define target āschemasā of transformations. I assume most of the functionalities such as schematron generation would work.
You can import the CDISC ODM XML Schema in LinkEHR in Managers->Reference Model Manager and there Import RM->From XSD Schemas. In that window, just add CDISC ODM Schemas.
I canāt upload a sample ADL because of discouse file upload limitations, but I have some archetype examples if you are interested
That XSD importer looks like a very nice feature, I wasnāt that there is one. However, I donāt want to transform openEHR to ODM ClinicalData, I want to convert the ODM-MetaData to an OPT file based on the ānormalā openEHR RM. Are those Archetypes based on the normal RM?
Hi Johannes,
the issue with this approach is (I talked about this before with Philipp Bruland) that CDISC ODM does not really have a rich reference model, itās rather weak on semantics. This is why the general approach to export CDISCM ODM forms to openEHR Archetypes did not work. Iām pretty sure the same is true for the FHIR export in MDM. The main issue is that the CDISC models donāt contain necessary information about entry classes, granularity of concepts, archetype slots etc. to automate the translation. The general issue is that CDISC forms are 2-3 layers above the design space where standardization of clinical concepts is sensible (RM --> Archetype --> Template -->Form).
There might be some fixed metadata aspects (e.g. study information) from CDISC that could be transformed, but all the clinical stuff will not result in properly modelled archetypes or FHIR profiles. So the only advantage I can imagine is having data in the same syntax and database that would make them available through AQL. What could work and would be interesting for HiGHmed and beyond is actually to translate Archetypes/Templates into CRFs in open clinica (or other EDC tools) and then integrate documented data from clinical studies back into the patient record.
Maybe I misunderstand the use-case. Would be great if you can clarify your goals.