Skip to Navigation | Skip to Content

openEHR-Technical mailing list archives

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: "state" and "protocol" structures are mandatory, when defined?



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

On 16/07/2010 13:09, Leonardo Moretti wrote:
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:
  
Leo,

perhaps you can look to this :

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


On 16 July 2010 11:47, Leonardo Moretti <lmoretti@noemalife.com> wrote:

    
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:
      
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


On 15 July 2010 17:57, Moretti Leonardo <lmoretti@noemalife.com> wrote:

        
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

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

          


--
Alessandro Torrisi

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


        
--
View this message in context:
http://old.nabble.com/%22state%22-and--%22protocol%22-structures-are-mandatory%2C-when-defined--tp29174701p29181878.html
Sent from the openehr-technical mailing list archive at Nabble.com.

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

      


-- 
Alessandro Torrisi

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


    
  


--
Ocean Informatics Thomas Beale
Chief Technology Officer, Ocean Informatics


Chair Architectural Review Board, openEHR Foundation
Honorary Research Fellow, University College London
Chartered IT Professional Fellow, BCS, British Computer Society
Health IT blog


_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical