# Assumed values etc.

**Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158)
**Created:** 2006-10-11 09:16 UTC
**Views:** 1
**Replies:** 3
**URL:** https://discourse.openehr.org/t/assumed-values-etc/14584

---

## Post #1 by @Mattias_Forss1

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

---

## Post #2 by @thomas.beale

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

---

## Post #3 by @Sam

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:

---

## Post #4 by @Mattias_Forss1

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

---


**Canonical:** https://discourse.openehr.org/t/assumed-values-etc/14584
**Original content:** https://discourse.openehr.org/t/assumed-values-etc/14584