ADL to XML Schema

Heath Frankel wrote:

Dear Sam, etal,

I wonder if the specialised schema approach for archetypes is one that
openEHR should encourage. Not so much discourage the investigation but at
least indicate to those who are going down this route that previous work by
Ocean and DSTC has indicated that the approach is not workable in a dual
layer model approach. Perhaps the more useful task is to find a suitable
schema for ADL if this has not already been done for which archetype
definitions can be validated against, not instances.

an XML-schema for the Archetype Object Model will be available very soon, initially probably as a hand-built one, but with the X-openEHR specification converter, we will be able to generate schemas for the entire RM and AM from that.

Perhaps it should be encouraged to use some existing schema's such as OWL
but again this is representing the archetype definition not the archetype
instance.

OWL I think is still research in this area; it has very weak leaf level semantics (which are known by the OWL community); we are working with the experts including prof Alan Rector and Rahil Qamar at University of Manchester to understand better how to "do archetypes in OWL".

Perhaps, the DSTC approach to represent archetypes using XML with a XML
schema for the Archetype Model should be endorsed by openEHR if this is the
preferred approach so people don't waste their time and develop a
proliferation of approaches which are likely to be incompatible or at least
require translation.

this is indeed the intended view, although I have recently come to the realisation that archetypes (or more properly openEHR templates - particular aggregations of archetypes) can be used to generate XML-schemas as well as XML-instance; the former would be usable as message definitions, for those who love messages. This would actually provide, for the first time, a single source development framework for software, schemas, screen definitions, and messages - all obeying coherent, consistent reference model, archetypes, templates and teminologies.

What would be better use of peoples time would be the investigation of an
archetype instance validating parser that uses the XML document representing
the archetype definition similar to an XML validating parser uses xml schema
(which is also an XML document).

this is indeed one thing that is needed; personaly, I would do it by reading in the archetype and the data from XML form into a DOM-tree and jst using the kernel to do the work.

The reason we need to have an XML document represent the archetype is
because of the dual layer model approach where the XML schema is used at the
reference model level and an xml instance can't have two associated schemas
for validation for each level. However, from my understanding (which is
limited), this is not an issue in some of these other schema systems like
Schematron and RelaxNG, so it might be useful for people to investigate
these if they really want to represent archetypes as XML schema's but
knowing that traditional parsers and XML tools will not support this due to
the dual layer model approach.

I also have suspicions that these other schema types might in fact be better for our purposes than XML-schema, and I hope others might be able to provide expert input on this.

- thomas

Linden H van der (MI) wrote:

Hi,

without much knowledge of Schematron, I believe it is good for
expressing validation rules, but I wonder if it can actually be used to
express calculations, like the BMI or the Barthel Index (sum of the
score of 10 values).

I'm currently looking at XQuery that can do such things.

Bye, Helma

perhaps the group is starting to see why we didn't use any of the XML technologies for archetypes in the first place....

- thomas

Hello,

We have just read the message bellow and honestly we do not understand
anything now. We supposed that EN13606-1 reference model could be used as
reference model for developing archetypes.

You can read in prEN13606-2 (last version February 2005), section 1.3. Communicating archetypes: "It is
the intention of both CEN and HL7 that HL7 Templates and EN13606
archetypes be interoperable". One question arises are these EN13606
archetypes different from OPENEHR archetypes?.

Could you show some examples of clinical concepts that can not be
expressed as archetypes derived from EN13606-1 reference model?.

thanks in advance

On dj, 2005-03-10 at 17:19, Thom

Thomas Beale escribió:

Jose

Hi - this is a difficult time with the 13606 standard about to hit the streets and the technology having been developed in the openEHR space. The openEHR approach is now considerably richer than 13606 and will, we hope, be the development space.

You can do pretty much everything in 13606 that you can do in openEHR, BUT there is no standard way to express many things that have been shown to be worthwhile such as:

A time series - this will be lots of entries in 13606
The state (e.g. patient sitting) and protocol (e.g. used wide cuff) information - this will clutter the data and make display rules difficult
The openEHR work that is going on with instructions - which will allow following a process and linking with workflow and decision support - will have to be done with clusters and elements - and it will not be sure how to do it exactly except to write it down.

So, we are hoping that people will look to the openEHR collaboration as the space to define clinical concepts and then generate 13606 archetypes for use with this standard - rather than everyone going their own way.

Further, collaboration is required in this area - it is difficult to get people working together but Thomas and others have put a huge effort into making this feasible.

I hope this is helpful.....

Sam Heard

Jose Alberto Maldonado wrote:

Hello,

We have just read the message bellow and honestly we do not understand
anything now. We supposed that EN13606-1 reference model could be used as
reference model for developing archetypes.
You can read in prEN13606-2 (last version February 2005), section 1.3. Communicating archetypes: "It is
the intention of both CEN and HL7 that HL7 Templates and EN13606
archetypes be interoperable".

well, this has been stated for a long time, but there is little evidence of it happening. A recent post from the HL7 templates list indicates the current state of play...in short they using something called MIF to do "templates", which are approximately the same as archetypes. But it is complicated in HL7 because there are two ways to create any model of a clinical concept: using a template (presuming they finish defining what they think a template is) and using an RMIM - a message model.

CEN doesn't need archetypes based on its own model, although not everyone in the working realises this yet. However, I had a recent discussion with Dr Gunnar Klein (chair of TC/251) and he now understands the reason why basing archetypes literally on EN13606 does not make a lot of sense. The documents you mention are indeed somewhat confusing as currenly worded and have to be changed; I will be recommending changes at the next CEN meeting.

One question arises are these EN13606
archetypes different from OPENEHR archetypes?.
Could you show some examples of clinical concepts that can not be
expressed as archetypes derived from EN13606-1 reference model?.

Sure....practically every archetype we have built. Have a look at the archetypes either using the adl-workbench or jsut on the web - see http://www.openehr.org/repositories/archetype-dev/latest/index.html. Consider the apgar archetype at http://www.openehr.org/repositories/archetype-dev/latest/adl/archetypes/openehr/ehr/entry/observation/openEHR-EHR-OBSERVATION.apgar.v1.html - you will see it references classes OBSERVATION, HISTORY, EVENT, and LIST, and particular attributes, e.g. OBSERVATION has data, state and protocol (see e.g. blood pressure for example use of these). You can't write any of this using the CEN model because it just doesn't have any of the classes I just mentioned. Instead, you can only write ENTRY, CLUSTER and ELEMENT, which is too limited.

CEN is designed to carry data that has already been archetyped, not to be a model on which archetypes are based.

thanks in advance

------------------------------- HL7 templates list post -----------------

Lloyd McKenzie wrote:

Hi John,

The internal format of all HL7 v3 content is MIF. It is used for persistence, exhange, as well as for definition of what's possible. The MIF also acts as a UML profile expressing what pieces of UML HL7 permits and what stereotypes we require.

The MIF requires that all 'custom' constraints be expressed as OCL, though alternate formal (e.g. Schematron) or free text representations are also supported. (Obviously we're coming up short on OCL representations at present.)

Thus, to a certain extent, the statement of UML + OCL is accurate. We just need to make clear that the UML being referred to is the MIF LIM stereotype.

Also, the format for registration should be MIF XML to allow for easy validation and checking against other models (e.g. RIM, datatypesn etc.)

Hi,

I'm only the convenor of the CEN/TC251 wg1.
For more detailed information you need to read the e-mails by Dipak Kalra, Thomas Beale and Sam Heard.

In the text below soem comments.

Read the text below.

Gerard

Heath Frankel wrote:

Dear Sam, etal,

I wonder if the specialised schema approach for archetypes is one that
openEHR should encourage. Not so much discourage the investigation but at
least indicate to those who are going down this route that previous work by
Ocean and DSTC has indicated that the approach is not workable in a dual
layer model approach. Perhaps the more useful task is to find a suitable
schema for ADL if this has not already been done for which archetype
definitions can be validated against, not instances.

an XML-schema for the Archetype Object Model will be available very soon, initially probably as a hand-built one, but with the X-openEHR specification converter, we will be able to generate schemas for the entire RM and AM from that.

Perhaps it should be encouraged to use some existing schema's such as OWL
but again this is representing the archetype definition not the archetype
instance.

OWL I think is still research in this area; it has very weak leaf level semantics (which are known by the OWL community); we are working with the experts including prof Alan Rector and Rahil Qamar at University of Manchester to understand better how to "do archetypes in OWL".

Perhaps, the DSTC approach to represent archetypes using XML with a XML
schema for the Archetype Model should be endorsed by openEHR if this is the
preferred approach so people don't waste their time and develop a
proliferation of approaches which are likely to be incompatible or at least
require translation.

this is indeed the intended view, although I have recently come to the realisation that archetypes (or more properly openEHR templates - particular aggregations of archetypes) can be used to generate XML-schemas as well as XML-instance; the former would be usable as message definitions, for those who love messages. This would actually provide, for the first time, a single source development framework for software, schemas, screen definitions, and messages - all obeying coherent, consistent reference model, archetypes, templates and teminologies.

What would be better use of peoples time would be the investigation of an
archetype instance validating parser that uses the XML document representing
the archetype definition similar to an XML validating parser uses xml schema
(which is also an XML document).

this is indeed one thing that is needed; personaly, I would do it by reading in the archetype and the data from XML form into a DOM-tree and jst using the kernel to do the work.

The reason we need to have an XML document represent the archetype is
because of the dual layer model approach where the XML schema is used at the
reference model level and an xml instance can't have two associated schemas
for validation for each level. However, from my understanding (which is
limited), this is not an issue in some of these other schema systems like
Schematron and RelaxNG, so it might be useful for people to investigate
these if they really want to represent archetypes as XML schema's but
knowing that traditional parsers and XML tools will not support this due to
the dual layer model approach.

I also have suspicions that these other schema types might in fact be better for our purposes than XML-schema, and I hope others might be able to provide expert input on this.

- thomas

David W. Forslund wrote:

I've been looking at schematron for doing the "equivalent" of archetype in
a more general situation, particularly since there as been no ADL parser
available in Java. Schematron seems to be reasonably popular for
enforcing rules for XML data structures and there is a variety of software
available for using it.

there are currently two parsers in java, hopefully at least one of those will be very soon announced as open source. The reference parser is also java-wrapped, and I will upload both source and .jar ASAP. We are not quite up to speed with automatic building of these, apologies for the inconvenience.

- thomas

Schematron supports at least some calculations, but probably not elaborate ones. I'm not sure what
is needed here. The sume of the score of 10 values is something that it can do:
http://www.zvon.org/xxl/SchematronTutorial/Examples/Example13/example.html
although I'm not sure about floating point (which is added in XSL 2.0, I believe)

Dave
Linden H van der (MI) wrote: