openEHR XML Schemas (XSDs) Release 2.0.0 published

openEHR news Releases
, ,
1

In the end of April, the openEHR Specifications Editorial Committee (SEC) has published ITS-XML (XSDs) Release 2.0.0 specification.

The ITS-XML 2.0.0 brings a number of XML Schema additions, corrections, improvements, a new structure that covers several openEHR component releases, as well as a few breaking changes compared to ITS-XML Release 1.0.2. The list of changes includes:

  • SPECITS-55: Sync BASE XML schema with Release 1.2.0
  • SPECITS-54: Fix wrong optional flag for ACTIVITY.action_archetype_id in XML schema
  • SPECITS-53: Fix wrong type on DV_QUANTITY.magnitude in XML schema
  • SPECITS-23: DV_ENCAPSULATED.size attribute is missing
  • SPECITS-22: Enforce an ELEMENT to require choice of value or null_flavour
  • SPECITS-21: Specify constraints of DV_QUANTIFIED.magnitude_status
  • SPECITS-20: Fix archetypeNodeId pattern
  • SPECITS-19: Cleanup AM latest schemas
  • SPECITS-18: Add missing types to XML Schema
  • SPECITS-17: Make type definitions reusable
  • SPECITS-15: Sync XSD with RM release 1.1.0
  • SPECITS-14: Sync XSD with RM release 1.0.4
  • SPECITS-13: Sync XSD with RM release 1.0.3
  • SPECITS-10: VALDITIY_KIND - ambiguous
  • SPECITS-8: Add an XSD for the openEHR demographic RM
  • SPECITS-6: Change ENTRY.work_flow_id to ENTRY.workflow_id
  • SPECITS-5: Allow timezone values like +13, +14
  • SPECITS-4: Make DV_AMOUNT and DV_TEMPORAL abstract in XSD
  • SPECITS-3: Make ISO8601 ‘T’ separator in DATE_TIME type mandatory in XSD as per ISO8601
  • SPECITS-2: Correct XSD constraints to prevent empty values in various types.
  • SPECITS-1: Add EHR_STATUS and EHR_ACCESS to XML schema

This release, together with the earlier published REST Release 1.0.2, and the latest developments on ITS-JSON and on ITS-BMM are now incorporated the ITS - Release 2.0.0, released beginning of May. An overview on all ITS subcomponents can be found at openEHR - Implementation Technologies dedicated specification page.

We would like to thank all the implementers for the feedback that led to this release, as well as the SEC members and others who helped create it.

6 Likes
2

I’ll try to play around with the new schemas next weekend :slight_smile:

2 Likes
3

There is a zip of the schemas in github, but it’s not easily linked from the specs website, should that zip be available there? Seems more useful to having to download each individual file

4

On the component page you can find download links, under Computable expressions
See screenshot:

image
image798×262 12.1 KB

1 Like
5

We saw it, but since it says Trial we were not sure if it was updated.

1 Like
6

In a quick import test of the RM XSDs into LinkEHR Studio, it seems that everything works well :grinning:

Eg.

image
image751×497 33.4 KB

1 Like
7

The new schemas introduced some backwards incompatible changes, therefore it was needed to increase the version number to 2 (both xml namespace as well as spec release). Content wise these schemas may look 99% aligned and compatible with v1 schemas.
As this is a “new” spec (although quite close to v1 spec), not used yet in production or implementation, it is formally considered to be in TRIAL according to https://www.openehr.org/programs/specification/changeprocess. Further no difference comparing to a STABLE spec. We are of course looking forward for feedback and reports of usage of this v2 in practice, and when that happens we will change the status accordingly.

1 Like
8

I tried what changing the namespace would mean for Archie:

  • currently Archie doesn’t output a namespace in XML, uses the default namespace for everything
  • If I bind the java packages to a namespace, it is bound to one specific namespace, it cannot accept two

At the same time, it looks like the changes to the XSDs are so minor that it can be easily parsed and mapped with the exact same code and model.

the alternative is to:

  • just keep ignoring everything namespace in XML in archie
  • implement two models and copy every field over (not a good idea!)
  • preprocessing the XML, changing all namespace references to “http://schemas.openehr.org/v2”

Java code generated from XSDs will have the same problem: it will only accept one of the two formats, requiring lots of manual work to fix, or the same preprocessing solution as above.

Have other vendors checked how easy or hard it is to support a new namespace for the new version? Do people still thin it’s worth it to change the namespace with rather minor changes? Or did I miss a major breaking change?
Should we add a version=“2.0” attribute to the XML instead?

2 Likes
9

There are ways to ignore the namespace when launching xpath, but appart from that xml should contain namespaces if the schema says so