On 05/05/2011 13:49, Diego Bosc? wrote:
> And again, why 'closed' and not occurrences {0}? Is really needed to
> include a new reserved word when you already have the way of
> expressing this?

because the intention is not to set occurrences to 0, the intention is 
to prevent any further fillers at run time. But the total occurrences 
could be any number, 'closed' just means that all fillers have to be 
specified in the template before it is deployed; 'open' means that more 
fillers can be added at runtime. I must admit I took some time to find a 
simple syntax approach to try and indicate this. Maybe you have a better 
suggestion, but it would not be to do with occurrences, because as I 
say, the occurrences could already be any range, and closing the 
interval doesn't mean zero-ing out the occurrences.

> When you resolve a use_archetype while generating the instance you
> will put the data, not a reference to it. On the other hand, the model
> tells you that it has to be a reference (X_VERSIONED_OBJECT or
> LOCATABLE). Am I missing something here?

well the Extract generator will include an X_VERSIONED_OBJECT. You can 
see from the definition of that class that it might or might not 
ultimately contain content - that is one of the features of the openEHR 
Extract - you could ask for X_VERSIONED_OBJECTs containing just version 
information, or else with full content. Maybe I am not understanding the 
question here....

> what is the big difference in using use_archetype and use_template if
> both are archetypes (with the same AOM and using ADL 1.5)?

none really; it is just to make it obvious that a template is being 
re-used, and to make it easier for tooling to distinguish, because from 
a design point of view, re-using a template is different from 'using' an 
archetype for the first time in a template. This is the current thinking 
in the draft. I know there is always a balance to be struck between 
simplicity and expressiveness; here I was trying to make life easier for 
tool builders (otherwise they have to do more work to infer that a 
template has been 'used' rather than an archetype).

- thomas

> 2011/5/5 Thomas Beale<thomas.beale at oceaninformatics.com>
>> On 05/05/2011 11:26, Diego Bosc? wrote:
>>
>> Hello Thomas,
>>
>> Some questions about the example available at the SVN
>> (http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/openEHR_examples/ehr_extract_template/Working/Templates/ehr_extract/openEHR-EHR_EXTRACT-EXTRACT.t_basic_acute.v1.adls)
>>
>> - What does the next snippet mean?
>>
>> use_archetype COMPOSITION[at0103, 
>> openEHR-EHR-COMPOSITION.t_clinical_info_ds.v1]
>> allow_archetype COMPOSITION[at0103.1] closed
>>
>>
>> from the ADL 1.5 draft, pg 113:
>>
>> In addition to or instead of specifying slot fillers, it is possible in a 
>> slot specialisation to narrow the
>> slot definition, or to close it. If fillers are specified, closing the slot 
>> as well is typical. The latter is
>> done by including an overridden version of the archetype slot object itself, 
>> with the ?closed? constraint
>> set, as in the following example:
>>
>> use_archetype 
>> SECTION[org.openehr::openEHR-EHRSECTION.history_medical_surgical.v1] matches 
>> {
>>      /items matches {
>>          use_archetype EVALUATION[at0002 = openEHR-EHR-EVALUATION.problem.v1]
>>          allow_archetype EVALUATION[at0002.1] closed
>>      }
>> }
>>
>> Narrowing the slot is done with a replacement allow_archetype statement 
>> containing a narrowed
>> set of match criteria. Since narrowing or closing is a change in definition, 
>> the node identifier needs to
>> be specialised, if there is one.
>>
>> Note that in the software the syntax has changed slightly from the '=' to a 
>> comma; the PDF needs to be updated for this.
>>
>> In the first case... that's a big archetype node identifier! Is that a
>> simplification of the includes syntax?
>>
>> have a look at the t_* source template examples here in the SVN repo, e.g.
>>
>>      EXTRACT[at0000.1] matches {     -- Discharge summary
>>              /chapters[at0002]/items[at0003]/item matches {
>>                      use_archetype PERSON[at0100, 
>> openEHR-DEMOGRAPHIC-PERSON.t_patient_ds.v1]
>>                      allow_archetype PERSON[at0100.1] closed
>>              }
>>              /chapters[at0002]/items[at0004]/item matches {
>>                      use_archetype ORGANISATION[at0101, 
>> openEHR-DEMOGRAPHIC-ORGANISATION.healthcare_establishment.v1]
>>                      allow_archetype ORGANISATION[at0101.1] closed
>>              }
>>              /chapters[at0002]/items[at0005]/item matches {  
>>                      use_archetype PERSON[at0102, 
>> openEHR-DEMOGRAPHIC-PERSON.healthcare_professional.v1]
>>                      allow_archetype PERSON[at0102.1] closed
>>              }
>>              /chapters[at0001]/items matches {       
>>                      GENERIC_CONTENT_ITEM[at0006.1] matches {
>>                              version_set_id existence matches {1}
>>                              item_status existence matches {1}
>>                              item_type existence matches {1}
>>                              item_type_version existence matches {1}
>>                              creation_time existence matches {1}
>>                              author existence matches {1}
>>                      }
>>              }
>>              /chapters[at0001]/items[at0006]/item matches {  
>>                      use_archetype COMPOSITION[at0103, 
>> openEHR-EHR-COMPOSITION.t_clinical_info_ds.v1]
>>                      allow_archetype COMPOSITION[at0103.1] closed
>>              }
>>      }
>>
>> This is how archetype slot filling is done in ADL 1.5.
>>
>> In the second one, what does 'closed' mean? Is the same that putting
>> the occurrences to 0..0?
>> If I remember correctly, use_archetype and allow_archetype are
>> equivalent in ADL 1.4. what is the difference between them? By the
>> way, isn't 'use_archetype' deprecated in ADL 1.5 (as can be seen on
>> page 42 of current draft)?
>>
>> allow_archetype defines a slot. If you see it in a template, it means that 
>> the slot definition is being specialised (i.e. redefined in a conformant way)
>> use_archetype means: 'fill this slot with this archetype'
>>
>> - All content seems to be included by value now at the EXTRACT.
>>
>> top level objects are included by value in their respective chapters. The 
>> demographic chapter typically contains some objects like HCP, HCF, Patient 
>> etc. These are referenced from clinical data, which is found in a clinical 
>> chapter. Including demographic data in the Extract is only necessary if 
>> there is no agreed shared / central place to resolve identifiers found in 
>> clinical information. If there is, it is not needed. I don't think the 
>> reference / by-value semantics are different from that shown in the 
>> screenshot below though.
>>
>> Following current (and I suppose outdated) Extract XSD schemas (as you
>> can see here http://prntscr.com/1tydt) everything is referenced. On
>> the specifications I see that there is 'item' of 'Any' type. Does that
>> mean that can be an object or a reference?
>>
>> probably you mean EXTRACT_CONTENT_ITEM.item : Any. This class is specialised 
>> depending on the kind of Extract, into:
>>
>> OPENEHR_CONTENT_ITEM (openEHR extracts) where item is of type 
>> X_VERSIONED_OBJECT and
>> GENERIC_CONTENT_ITEM (13606, CDA, other) where item is of type LOCATABLE
>>
>> - What is the difference between an EXTRACT_CHAPTER and a common FOLDER?
>>
>>
>> Chapters of type EXTRACT_CHAPTER are used to explicitly organise top-level 
>> chunks of content in the Extract; the meaning of each chapter is 
>> archetype/template-defined. EXTRACT_FOLDERs are there to represent FOLDER or 
>> similar structures from the source system, i.e. to preserve such structures 
>> in the Extract. So EXTRACT_CHAPTER is an artefact of an Extract, FOLDER is 
>> (usually) an artefact of data being extracted. I think 13606 mixes these 
>> functions up in one FOLDER class, which makes it difficult to say what a 
>> Folder actually is in a 13606 Extract.
>>
>> - thomas
>>
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>


-- 
Ocean Informatics       *Thomas Beale
Chief Technology Officer, Ocean Informatics 
<http://www.oceaninformatics.com/>*

Chair Architectural Review Board, /open/EHR Foundation 
<http://www.openehr.org/>
Honorary Research Fellow, University College London 
<http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org.uk/>
Health IT blog <http://www.wolandscat.net/>


*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110505/a2651038/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110505/a2651038/attachment.jpg>

Reply via email to