OPT version, schema & document

That’s the problem - the only candidate that anyone could identify is the old version that Pablo has. It is out of date but the new aspects have mostly been in place for a long time - that version just needs updated to reflect what is actually a high degree of alignment in .opt.

I don’t think we need to “support” but to start “tracking” changes. Support means maintaining old versions, what I was referring to was to detect changes between versions and assign a version number to each one, then keep maintaining the last one, but have all the XSD versions under one versioned environment.

This is very easy thing to do, and I can do it, we just need the XSDs each provider is using, I can merge the XSDs into one file (http://www.strategicdevelopment.io/tools/SchemaLightener.php) then do a diff comparing 2 by 2 and noting the changes. The file with most changes will be the latest version, and I guess the one I have imported in 2015 is the first version.

Also this comparison will let us know if there are any incompatibilities between the XSDs out there, that is a more difficult thing to solve since different implementations might rely on different rules. That is why we can’t just keep track of the latest version only: implementations using incompatible XSDs will be forced to adapt and that might not be possible. Incompatible means some element is required by the new schema but was optional or didn’t exist on a previous one.

Would it be possible to get the XSDs from Better and Ocean?

1 Like

BTW the one I have is a merge from the multiple modular XSDs I found back in 2015, just because working with one file is easier than working with many. But I might have the original files somewhere on an old VM.

I have asked for any current XSDs from Ocean and Better

@ian.mcnicoll I tried to upload the OPT Template.xsd here but it looks like there is a limit on the file types that can be uploaded here so i will email it to you.
In short, the OPT schema was updated back in 2010 to support annotations.
In Aug 2012 there were some changes made relating to annotations that may have introduced some inconsistencies, these we reverted in Mar/Apr 2015 and the OPTs generated by CKM and Ocean Template Designer should be compatible with the original 2010 XSD.

Just to reiterate, the only changes and possible inconsistencies between some versions of the Ocean Template Designer is related to Annotations, nothing else has changed since 2010.

1 Like

Can you zip them or share via drive/ Dropbox?

Heath has emailed me the Ocean xsd - Better do not use one. So basically we need to test he xsd against bteer and Marand current .opt generation anyone else @yampeku @pieterbos - do you make use of the .op 1.4 xsd or genrrate 1.4 .opt?

LinkEHR can import/export OPT, in principle follows the format TD can export/read

1 Like

Ok - I have spoken to Pieter @Pablo.

  1. Nedap do not use .opt 1.4
  2. linkEHR just tracks Ocean
  3. Better do not have an internal XSD and have made a tweak or two from the Ocean .opt format
  4. The Ocean XSD that Heath has sent over is probably the ‘gold standard’ for now

I suggest we run a few text examples from Ocean TD, CKM and Better AD past this and see what falls over.

1 Like

I cannot recall why we don’t have the OPT XSD on github.
Once you get the final OPT XDS, I will worked it out into ITS-XML repo.

@ian.mcnicoll I’m checking differences between the XSD I have (CaboLabs) and the one provided by @heath.frankel (Ocean)

  1. CaboLabs XSD has a DEFAULT_VALUE type and types extending that:


All those “DEFAULT_” types are not defined in Ocean’s XSD.

Those are used in the C_ARCHETYPE_ROOT.default_values element, which is not defined in Ocean’s XSD.

  1. Ocean XSD has these elemets that are not in the CaboLabs’s XSD

OPERATIONAL_TEMPLATE.component_ontologies *

* both have type FLAT_ARCHETYPE_ONTOLOGY which is also not included in CaboLabs’ XSD. FLAT_ARCHETYPE_ONTOLOGY is an extension of ARCHETYPE_ONTOLOGY that adds an archetype_id attribute to the ARCHETYPE_ONTOLOGY.

  1. OPERATIONAL_TEMPLATE.view seems to be in conflict:


  • has OPERATIONAL_TEMPLATE.view with type T_VIEW
  • has OPERATIONAL_TEMPLATE.constraints with type T_CONSTRAINT


  • has OPERATIONAL_TEMPLATE.view with an inline type (not explicit T_VIEW),
  • the inline type has an optional ‘id’ attribute, which is mandatory in Ocean XSD. Also ‘path’ is optional in CaboLabs XSD but required in Ocean’s XSD.
  • doesn’t have OPERATIONAL_TEMPLATE.constraints element.
  1. CaboLabs XSD has PROPORTION_KIND type which is not present in Ocean’s XSD.

I think that one is missing because there is one missing XSD from the Ocean ones, basetypes.xsd (and anything included there). Without all the dependencies I might find more missing types, so I’ll stop here until we get the complete set.


I can’t upload here - - see slack.

I was able to add the missing XSD to the flat file and recheck, yes the PROPORTION_KIND is defined in Ocean XSD, so we are good for point 4.

  1. AUTHORED_RESOURCE is abstract in CaboLabs XSD, but is not in the Ocean’s XSD.


<xs:complexType name="AUTHORED_RESOURCE" abstract="true">


<xs:complexType name="AUTHORED_RESOURCE">

  1. RESOURCE_DESCRIPTION.details minOccurs = 1 in CaboLabs XSD but is 0 in Ocean’s XSD.


<xs:element name="details" type="RESOURCE_DESCRIPTION_ITEM" maxOccurs="unbounded"/>


<xs:element name="details" type="RESOURCE_DESCRIPTION_ITEM" minOccurs="0" maxOccurs="unbounded"/>

  1. DV_IDENTIFIER elements are optional in Ocean’s XSD while mandatory in CaboLabs XSD.


<xs:element name="issuer" type="xs:string"/>
 <xs:element name="assigner" type="xs:string"/>
 <xs:element name="id" type="xs:string"/>
 <xs:element name="type" type="xs:string"/>


<xs:element name="issuer" type="xs:string" minOccurs="0"/>
<xs:element name="assigner" type="xs:string" minOccurs="0"/>
<xs:element name="id" type="xs:string"/>
<xs:element name="type" type="xs:string" minOccurs="0"/>

Ocean is compliant with RM 1.0.4, and CaboLabs with RM 1.0.2:

  1. Modification done to the CaboLabs XSD: OBJECT_ID

Added constraint to OBJECT_ID.value to be a non empty string, to comply with the RM:


<xs:element name="value" type="xs:token"/>


<xs:element name="value" type="NotEmptyToken"/>

<xs:simpleType name="NotEmptyToken">
     <xs:restriction base="xs:token">
       <xs:minLength value="1" />

Check the modification history: https://github.com/ppazos/cabolabs-ehrserver/commit/1c1a453ad8b01315bbfe26272f82c7e21cbd7b55#diff-1bb01a8b3db81ef3b88ee42fac41d6ba

  1. Modification done to the CaboLabs XSD: OBJECT_VERSION_ID

Added a constraint over the format of OBJECT_VERSION_ID.value, because didn’t have any constraint on the original OPT.


<xs:complexType name="OBJECT_VERSION_ID">
            <xs:extension base="UID_BASED_ID"/>


<xs:complexType name="OBJECT_VERSION_ID">
              <xs:restriction base="UID_BASED_ID">
                      <xs:element name="value" type="OBJECT_VERSION_ID_VALUE_FORMAT"/>

<!-- https://github.com/ppazos/cabolabs-ehrserver/issues/913 -->
  <xs:simpleType name="OBJECT_VERSION_ID_VALUE_FORMAT">
     <xs:restriction base="NotEmptyToken">
        <xs:pattern value="[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}::(\w.*)::([0-9]+[0-9]*(\.[0-9]+[0-9]*(\.[0-9]+[0-9]*)?)?)"/>
  1. Modification done to the CaboLabs XSD: view element was not generated by the Template Designer.

Added a minOccurs=0 to the view element. Change and associated issue here: https://github.com/ppazos/cabolabs-ehrserver/commit/989147f3956b754b5b0b624d4cc3deb5d25da0a7#diff-1bb01a8b3db81ef3b88ee42fac41d6ba

  1. REVISION_HISTORY_ITEM audit vs audits:


I guess this is a typo in “audits” and should be “audit”, need to check the RM.

  1. Optional vs. mandatory PARTICIPATION.mode

CaboLabs: mode is mandatory

<xs:element name="mode" type="DV_CODED_TEXT"/>

Ocean: mode is optional

<xs:element name="mode" type="DV_CODED_TEXT" minOccurs="0"/>

In the RM 1.0.4, PARTICIPATION.mode is optional, but in RM 1.0.2 mode is required. This makes me think we also need to release XSDs for each RM version.

That’s all I can find.

IMO, the Ocean one was updated recently, at least for RM 1.0.4 and CaboLabs keeps compliance with RM 1.0.2.


@pablo , it looks like you have a very old version of the OPT that was authored way back in 2007.
The XSD I provided has been used by the Template Designer since 2010, including version 2.6 and above.

All the default values where removed as it was deemed that these should not be included in an OPT, they are only relevant to archetypes.

@heath.frankel The one I have is compliant with what the Template Designer 2.8.beta is exporting as OPT. We are using that and RM 1.0.2 for the EHRServer.

This is indeed an incompatibility issue that should be addressed.
For example, the OPTs in the directory “opts” of the EHRServer’s GitHub repository couldn’t be opened by Ocean Template Designer (v3.0.169) due to Schema validation problems, such as the root element “template”.

As an intrim workaround, an older version of Ocean Template Designer could be recommended on the github Readme page. And some older versions should also be available for this purpose.

The template designer only opens OET files, not OPTs, OPT is an exported file while the OET is the source. I guess you are trying to edit an OPT file and that is not the correct way of editing templates. That is why it gives you the validation errors. Those are different formats!

1 Like

Pablo, Thank you so much. Exactly, you are right :slight_smile:

Just in case you are using the EHRServer and want to edit the templates, I tried to maintain the source files under this repo https://github.com/ppazos/knowledge

Might be out of date, just in case you need some OET in particular and it’s not in that repo, I can look for it on my local test data sets.

1 Like

Wow, that would be great!