Assumed values etc.

Implementers (archive)
1

Hi,

I have found some issues which concerns the Ocean Archetype Editor.
When editing the person state, it is possible to set assumed values
for C_DOMAIN_TYPE data types. However, I haven't found it is possible
to specify assumed values for these data types when I looked through
the openEHR archetype profile specification. The only data types it
should be possible to set assumed values for are C_PRIMITIVE data
types. This seems to be an error in the editor, so if we need assumed
values for the domain type data types the specifications need to be
updated.

Another error I saw, is that the DV_CODED_TEXT created with the editor
has the attribute 'code' instead of 'defining_code' which is in the
specs. The duration constraint also seems to have some bug, because
the values you specifiy aren't outputted to the ADL file, only
'PYMWDTHMS'.

The interval data types which you can create in the editor are also
not following the specifications, for example:

INTERVAL_COUNT matches {
  absolute_limits matches {
    COUNT matches {
      magnitude matches {|0..2|}
    }
  }
}

which should be:

INTERVAL matches {
  lower matches {
    COUNT matches {
      magnitude matches {|0..2|}
    }
  }
  upper matches {
    COUNT matches {
      magnitude matches {|0..2|}
    }
  }
}

-- Generic type could also be specified if it's supported by the
parser, i.e. INTERVAL<COUNT>

So there are some issues to solve. Particularily all the data types
should be carefully checked for conformance to the reference model. I
would like this to happen rather quickly because I don't like the idea
that an archetype editor can create illegal archetypes. People are
likely to start using archetypes more and more in the future and then
there is a need for reliable tools. Archetype authors shouldn't have
to worry if the archetype they created with an archetype editor is
conforming to the reference model. The more correct archetypes an
editor produces, the more people are willing to start using or testing
them in their systems, but if people keep on running into problems
caused by archetypes they assumed were correct (since they were
created by an editor) they might loose interest in the openEHR
approach and turn to something else...

Just some thoughts,

Mattias

2

Mattias Forss wrote:

Hi,

I have found some issues which concerns the Ocean Archetype Editor.
When editing the person state, it is possible to set assumed values
for C_DOMAIN_TYPE data types. However, I haven't found it is possible
to specify assumed values for these data types when I looked through
the openEHR archetype profile specification. The only data types it
should be possible to set assumed values for are C_PRIMITIVE data
types. This seems to be an error in the editor, so if we need assumed
values for the domain type data types the specifications need to be
updated.
  

that is true. Rong and I have already (independently) determined that
this change needs to be made, and I was debating whether to include it
in 1.0.1 or not, but you have clarified for me that we need to see this
as an error that needs to be fixed. The correct model will have some new
classes in the inheritance hierarchy, and moves the assumed_value
fnctions & data to a new class that I have called C_LEAF_OBJECT, which
is a new parent of C_PRIMITIVE and C_DOMAIN_TYPE, thus achieving the
effect we require.

Another error I saw, is that the DV_CODED_TEXT created with the editor
has the attribute 'code' instead of 'defining_code' which is in the
specs.

ok - this has to be fixed.

The duration constraint also seems to have some bug, because
the values you specifiy aren't outputted to the ADL file, only
'PYMWDTHMS'.
  

This must be some simple bug in the editor, because the parser test
cases show this works fine...

The interval data types which you can create in the editor are also
not following the specifications, for example:

INTERVAL_COUNT matches {
  absolute_limits matches {
    COUNT matches {
      magnitude matches {|0..2|}
    }
  }
}

which should be:

INTERVAL matches {
  lower matches {
    COUNT matches {
      magnitude matches {|0..2|}
    }
  }
  upper matches {
    COUNT matches {
      magnitude matches {|0..2|}
    }
  }
}

-- Generic type could also be specified if it's supported by the
parser, i.e. INTERVAL<COUNT>
  

This is already on the CR list;-)

So there are some issues to solve. Particularily all the data types
should be carefully checked for conformance to the reference model. I
  

Our strategy here is to use a generic model checker component, which has
not yet been built, but should be soon.

would like this to happen rather quickly because I don't like the idea
that an archetype editor can create illegal archetypes. People are
likely to start using archetypes more and more in the future and then
there is a need for reliable tools. Archetype authors shouldn't have
to worry if the archetype they created with an archetype editor is
conforming to the reference model. The more correct archetypes an
editor produces, the more people are willing to start using or testing
them in their systems, but if people keep on running into problems
caused by archetypes they assumed were correct (since they were
created by an editor) they might loose interest in the openEHR
approach and turn to something else...
  

agree with all that - we are working absolutely flat-out on all these
things, as well as everything else (that gets us paid;-)

- thomas beale

3

Hi Tom and Mattias

With regard duration constraints: what is the syntax for a constraint like 5-10 weeks in a duration, or >6 months? Is this feature available in the parser?

Sam

Thomas Beale wrote:

4

Hi Sam,

The syntax for intervals, i.e. 5-10 weeks should be like this: |P5W..P10W|

The syntax for less than or greater than, i.e. greater than 6 months
should be like this: |>P6M|

Both kinds of syntaxes should be supported by the parsers, but I know
that the Java parser doesn't support this yet, but it probably will
soon.

Mattias