# OPT 1.4 Specification **Category:** [ADL](https://discourse.openehr.org/c/adl/40) **Created:** 2019-11-08 14:41 UTC **Views:** 1907 **Replies:** 26 **URL:** https://discourse.openehr.org/t/opt-1-4-specification/105 --- ## Post #1 by @johannes.oehm Does anybody know about the whereabouts of the OPT1.4 specification? When I click the link on [https://specifications.openehr.org/](https://specifications.openehr.org/),I always get directed back to the same page. --- ## Post #2 by @thomas.beale 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. --- ## Post #3 by @Seref 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? --- ## Post #4 by @johannes.oehm 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? --- ## Post #5 by @Seref 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). --- ## Post #6 by @sebastian.garde 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. --- ## Post #7 by @pieterbos @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. --- ## Post #8 by @johannes.oehm 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](https://github.com/openEHR/java-libs/blob/master/oet-parser/src/main/xsd/Template.xsd), while the OET-file is specified as [CompositionTemplate.xsd](https://github.com/openEHR/java-libs/blob/master/oet-parser/src/main/xsd/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... --- ## Post #9 by @Seref 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? --- ## Post #10 by @ian.mcnicoll 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. --- ## Post #11 by @johannes.oehm 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. --- ## Post #12 by @ian.mcnicoll 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. --- ## Post #13 by @pablo 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/ --- ## Post #14 by @Seref Thanks @pablo , whom I cannot thank with less than 20 characters due to discourse settings... --- ## Post #15 by @yampeku [quote="johannes.oehm, post:11, topic:105"] that generates archetypes for ODM StudyEvents, Forms and ItemGroups and generates a template containing all of them. [/quote] 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. --- ## Post #16 by @damoca 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: https://es.slideshare.net/damoca/clinical-trials-powered-by-electronic-health-records-26743967 --- ## Post #17 by @johannes.oehm 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? --- ## Post #18 by @yampeku 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 --- ## Post #19 by @johannes.oehm 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? --- ## Post #20 by @birger.haarbrandt 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. --- ## Post #21 by @pablo I guess you still need to do some RM mapping in order to map the metadata/definitions, because metadata instances (e.g. specific OPTs) depend on a specific RM. On the other hand, you can go up in the semantic hierarchy and want to map the metadata models, which are (in the case of openEHR) independent from the underlying RM. --- ## Post #22 by @johannes.oehm @birger.haarbrandt The use-case is using the MDM-Portal for storing meta data as ODM as an alternative for the Archetypes/Templates, since the ODM meta data in theory can be used for many different things, not only study data. @pablo Yes, I know. I thought of mapping the StudyEvent to a Composition or maybe an Observation, and putting the Forms into the as a cluster of clusters of ItemGroups. Let me know if you would recommend a different approach. --- ## Post #23 by @pablo I don't know the ODM model. But it seems your approach is mapping reference models, not their metadata. That is how I proceed when I need to map HL7v2/CDA/FHIR to openEHR RM. The approach is not generic, but works. --- ## Post #24 by @johannes.oehm I think there is a misunderstanding: By metadata, I mean the "structural metadata" as which datafields are available, how many occurences they may have (like a XSD) and not the "administrative metadata" like who has created an resource at which point in time. In ODM, the structural metadata is stored in a tag called "MetaDataVersion", this is why I'm talking about metadata all the time. As far as I understood, openEHR has multiple stages of describing the structural metadata of the final "composition" resource (correct me if I'm wrong): * BMM, which is used to describe the RM, a set of basic classes * ADL/AOM, which is used to constrain classes of the RM * OPT, which puts multiple of those constrained classes together for a specific use-case What I don't want is to create a new version of the RM. As far as I can see, most RM classes are just containers for the very generic ITEM_STRUCTURE. The ITEM_STRUCTURE is constrained by AOM from a technical point of view, but in my eyes, it is less of constraining but more of specifiying the actual XSD for the information, which is stored in that Archetype. Mapping the "administrative metadata" like creation time, copyright etc. to the corresponding fields in the RM would be just a bonus, my focus is on having a field for each Item the ODM allows in the final OPT. --- ## Post #25 by @yampeku it is constraining in the sense that whatever you don't specify in the archetype is assumed to come as is from the reference model. You actually can't specify constraints on sharing typing nodes in XML Schema (e.g. two different ELEMENTs), that's why another artifact, such as ADL, is needed --- ## Post #26 by @thomas.beale [quote="johannes.oehm, post:19, topic:105, full:true"] 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? [/quote] I have looked at this general issue before w.r.t. generic SDTM representation, CDISC BRIDG and so on, and my previous conclusion was that it would probably be worth adding some classes to the openEHR RM to accommodate 'study data' structures generally. The reason to do so would be to provide two data pathways that could potentially be useful: * a pathway for existing SDTM data e.g. BRIDG, ODM etc to be imported in a relatively straighforward fashion * a known transformation pathway for openEHR native EHR data, including collected during a clinical trial, to be converted into an SDTM like form that is trial- and data-set- centric rather than patient centric. This additional modelling would take advantage of the openEHR versioning, audit, and other context attributes as much as possible. This doesn't help you in the immediate short term, but I'd be interested to see an effort materialise in this area in openEHR to provide more direct model and tool support for clinical trial and other 'study' data. --- ## Post #27 by @pablo [quote="pablo, post:13, topic:105"] Our toolset also might be useful to work with OPTs http://server001.cloudehrserver.com/cot/ [/quote] BTW the openEHR toolkit is now here https://toolkit.cabolabs.com/ --- **Canonical:** https://discourse.openehr.org/t/opt-1-4-specification/105 **Original content:** https://discourse.openehr.org/t/opt-1-4-specification/105