# "state" and  "protocol" structures are mandatory, when defined?

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2010-07-15 15:57 UTC
**Views:** 7
**Replies:** 8
**URL:** https://discourse.openehr.org/t/state-and-protocol-structures-are-mandatory-when-defined/15005

---

## Post #1 by @Leonardo_Moretti

Hi all,
I have a doubt in interpretating the archetype definition when there are
"state" or "protocol" structure\. For example, looking at "Blood
Pressure" in http://openehr.org/knowledge/, I'm wondering if "protocol"
structure is mandatory, as it seems looking at the archetype\. If I don't
know any details about the protocol, do I have to insert an empty tag
<protocol> however?

Best regards
leo

---

## Post #2 by @Alessandro_Torrisi

Leo,

as far as i can see the protocol section is not mandatory :

protocol matches {
ITEM_TREE[at0011] matches { -- lijst structuur
items cardinality matches {0..*; unordered} matches {

as you can see 0..* (means zero times until unbounded times), so not mandatory

Alessandro

---

## Post #3 by @Leonardo_Moretti

Hi Alessandro,
items cardinality matches \{0\.\.\*; unordered\} is referred to "items" elements,
not to "protocol" element

This means we can have something like this:
<observation>
<data>
\.\.\.
</data>
<protocol archetype\_node\_id="at0011" xsi:type="ITEM\_TREE">
    <name>
        <value>\*List\(en\)</value>
    </name>
</protocol>
<observation>

Is the section
<protocol archetype\_node\_id="at0011" xsi:type="ITEM\_TREE">
    <name>
        <value>\*List\(en\)</value>
    </name>
</protocol>
mandatory, even if it doesn't have any items?
Looking at the archetype defintion, so it seems\!

leo

Alessandro Torrisi\-3 wrote:

---

## Post #4 by @Alessandro_Torrisi

Leo,

perhaps you can look to this :

[http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/ehr_im.pdf](http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/ehr_im.pdf)

then section 8.3.3. CARE_ENTRY Class

over there you can see that protocol is 0..1 So never be mandatory

Alessandro

---

## Post #5 by @thomas.beale

In general questions like this can be answered by looking at any of:

- the relevant specifications: [http://www.openehr.org/releases/1.0.2/roadmap.html](http://www.openehr.org/releases/1.0.2/roadmap.html) , in this case, [http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf](http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf)

- the online UML - root link: [http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/architecture/computable/UML/uml_start_view.html](http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/architecture/computable/UML/uml_start_view.html) ; in this case, [http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html)
- the ADL Workbench schema, at [http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/specialisation/apps/adl_workbench/app/rm_schemas/openehr_rm_102.dadl](http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/specialisation/apps/adl_workbench/app/rm_schemas/openehr_rm_102.dadl)
- thomas beale

[details="(attachments)"]

![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg)

[/details]

---

## Post #6 by @Leonardo_Moretti

Thanks Alessandro,
yes you are right, generally protocol is optional in RM, but I'm wondering
if it becomes mandatory when defined in the archetype\.
ADL doesn't explicit the occurrences of protocol \(I imagine the default is
0\.\.1\), but in XML representation of the archetype I find
\.\.\.
<attributes xsi:type="C\_SINGLE\_ATTRIBUTE">
      <existence>
        <lower\_unbounded>false</lower\_unbounded>
        <upper\_unbounded>false</upper\_unbounded>
        <lower>1</lower>
        <upper>1</upper>
      </existence>
      <rm\_attribute\_name>protocol</rm\_attribute\_name>
      <children xsi:type="C\_COMPLEX\_OBJECT">
        <rm\_type\_name>ITEM\_TREE</rm\_type\_name>
        <occurrences>
          <upper\_included>true</upper\_included>
          <lower\_included>true</lower\_included>
          <upper\_unbounded>false</upper\_unbounded>
          <lower\_unbounded>false</lower\_unbounded>
          <upper>1</upper>
          <lower>1</lower>
        </occurrences>
        <node\_id>at0011</node\_id>
\.\.\.

where lower occurences number is 1 and not 0\! Maybe is the XML serialization
wrong\!?

leo

Alessandro Torrisi\-3 wrote:

---

## Post #7 by @Alessandro_Torrisi

Leo,

it is an interseting question.

in general it is 0..1 we agree on that
if it is defined in the archetype i think it is mandatory, so 1..1

however the items inside the ITEM_STRUCTURE (suppose ITEM_TREE) can be set to 0..1

so.. it is requierd, but not the content..

Alessandro

---

## Post #8 by @Leonardo_Moretti

Probably this is another case where the existence attribute creates
ambiguity\.

As stated in
http://www.openehr.org/wiki/display/dev/Existence+of+Attributes+%28AOM,+ADL+and+XML%29
http://www.openehr.org/wiki/display/dev/Existence+of+Attributes+%28AOM,+ADL+and+XML%29
, Java reference adl parser and serializer consider the absence of existence
attribute as \[1\.\.1\] as default\.
I imagine we can consider this as a temporary anomaly and assuming existence
attribute of "protocol" and "state" as \[0\.\.1\]\.

leo

Alessandro Torrisi\-3 wrote:

---

## Post #9 by @thomas.beale

This 1..1 default for existence is an unfortunate error in the ADL 1.4 specification, and is gone in the ADL 1.5 specification. For the most reliable place to validate archetypes, see the new ADL 1.5 Workbench, coming out in a few days.

- thomas beale

[details="(attachments)"]

![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg)

[/details]

---


**Canonical:** https://discourse.openehr.org/t/state-and-protocol-structures-are-mandatory-when-defined/15005
**Original content:** https://discourse.openehr.org/t/state-and-protocol-structures-are-mandatory-when-defined/15005