Questions about ADL/AOM 1.5, archetype flattening and operational templates

[pablo pazos]

Hi,
I'm reading this page trying to understand how to implement archetype 
flattening and operational template support to our EHRGen project: 
http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADL%26AOM1.5-TemplatesandSpecialisedArchetypes-Source%2Cflatandoperationalformsofarchetypessupported
 
What I don't get is: when you have a flat archetype (e.g. without slots, 
internal refs and only with the specialized nodes) or an operational template 
(also flat), where is the reference to the original archetype nodes in the 
flattened AOM object for the resolved references (slots, internal refs, etc.)?
For example:
Archetype A: [at] OBS -> [at0001] HISTORY -> [at0002] EVENT (slot to 
archetype B)Archetype B: [at] EVENT -> [at0001] ITEM_TREE -> ...
Flattened: (Archetype A) [at] OBS -> [at0001] HISTORY -> [at0002] EVENT -> 
(Archetype B) [at] EVENT -> [at0001] ITEM_TREE -> ...
If I use the flattened archetype in my application, I would like to know what 
is the original archetype that constrained my EVENT, because could create 
queries based on the paths of that archetype. Maybe there's another way of 
doing the same that I can't see yet.

Thanks a lot!

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrezopenEHR community in spanish: http://openehr.org.es
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120430/ef2a72ac/attachment-0001.html>

Archetype Slots Include - Exclude interpertation

[Thomas Beale]

(Yes, i did notice that part in the text, it will make the
>>> constraint more strict but inserts yet more parsing).
>>>
>>> Is there a single BNF description of ADL 1.5 available from somewhere?
>>> *
>>> *
>>
>> yep, they are here
>> <http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADL%26AOM1.5-TemplatesandSpecialisedArchetypes-Parsergrammars>
>>  
>>
>> - fairly standard .y and .l files.
>>
>> - thomas
>


-- 
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/pipermail/openehr-technical_lists.openehr.org/attachments/20120430/80e07e29/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/pipermail/openehr-technical_lists.openehr.org/attachments/20120430/80e07e29/attachment.jpg>

Archetype Slots Include - Exclude interpertation

[Ian McNicoll]

> On 12/04/2012 17:44, Thomas Beale wrote:
>>
>>> On 12/04/2012 17:20, Athanasios Anastasiou wrote:
>>>
>>>>
>>>>  BTW, these lexical rules are historical, and will be obsoleted one day
>>>>> -
>>>>> I more or less had to construct them after 100s of archetypes that
>>>>> actually assume these rules had been built! You will see further down
>>>>> in
>>>>> the ADL 1.5 text an indication of the future, but for today, we are
>>>>> stuck with the above...
>>>>>
>>>> Oh joy. (Yes, i did notice that part in the text, it will make the
>>>> constraint more strict but inserts yet more parsing).
>>>>
>>>> Is there a single BNF description of ADL 1.5 available from somewhere?
>>>> *
>>>> *
>>>>
>>>
>>> yep, they are here
>>> <http://www.openehr.org/wiki/**pages/viewpage.action?pageId=**
>>> 196633#openEHRADL%26AOM1.5-**TemplatesandSpecialisedArchety**
>>> pes-Parsergrammars<http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADL%26AOM1.5-TemplatesandSpecialisedArchetypes-Parsergrammars>
>>> >
>>>  - fairly standard .y and .l files.
>>>
>>> - thomas
>>>
>>
>> __**_
>> openEHR-technical mailing list
>> openEHR-technical at lists.**openehr.org> lists.openehr.org>
>> http://lists.openehr.org/**mailman/listinfo/openehr-**
>> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
>>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>



-- 
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
Director openEHR Foundation  www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care  www.phcsg.org
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120430/5ce60ae6/attachment-0001.html>

Archetype Slots Include - Exclude interpertation

[Seref Arikan]

rsergrammars<http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADL%26AOM1.5-TemplatesandSpecialisedArchetypes-Parsergrammars>
>> >
>> - fairly standard .y and .l files.
>>
>> - thomas
>>
>
> __**_
> openEHR-technical mailing list
> openEHR-technical at lists.**openehr.org lists.openehr.org>
> http://lists.openehr.org/**mailman/listinfo/openehr-**
> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120430/a52618be/attachment.html>

Archetype Slots Include - Exclude interpertation

[Athanasios Anastasiou]

Dear all

I am coming back to this issue of interpreting and following Archetype 
Slots with a simple (i hope) question.

How are we supposed to handle cyclic references created by Archetype Slots?

There are quite a few places where cycles might come up, first of all, 
getting the RM from the AM, building the GUI and finally even up to the 
complex issue of creating and executing queries.

As we clarified earlier there are mainly two flavours of slot binding: 
a) Formal,
b) Recommendation

My understanding of the "Formal" slot binding is that the slot would 
have to be filled explicitly by one of the archetypes that are 
determined by the include / exclude criteria.

In most of the cases of the archetypes that are available through the 
CKM*, the formal binding does not lead to any cycle formation.

However, it is much easier to create cycles with a "Recommendation" type.

For example, i can specify something like this:
A->B->A

That is, [...an archetype (of some kind A) including a slot that accepts 
a generic archetype (of some kind B) including a slot that can accept...]*

And that's the shortest cycle that would create a problem...It is of 
course possible that longer cycles could emerge unknowingly to authors 
as the archetype creation process proceeds by various teams independently.


Therefore, what i would like to ask is the following:

1) Is there a recommendation for avoiding cycles? (For example, one 
could say that "you can't attach an archetype of the same or higher 
level (of datatype) to a slot". In this way, a CLUSTER would only be 
allowed to reference ELEMENTs. This is guaranteed to lead to a tree but 
reduces the flexibility of the model)

2) Is this kind of reference something to be expected when modelling 
clinical data? (In other words, it's actually a use case and you can't 
prohibit it, so you have to watch for it)

3) While creating the RM / GUI / other artifact, am i expected to follow 
all links exhaustively in order to create a Tree through which i would 
first detect cycles, resolve them and THEN create the final version of 
the RM?

(Please note, "fudging" this, by resolving slots lazily is not an option 
:-). For example, i could create a GUI with all available information 
and a "Fill This Slot" button at the slot. Once you click the button 
another form is created which collects the data for the attached 
archetype. In this case, the algorithm did not hit a "loop" but the user 
eventually will because "new buttons" for filling in data will keep 
coming up in new forms.)

Looking forward to hearing from you
Athanasios Anastasiou

*: My XML parser (built out of the openEHR XSDs) kept complaining about 
the structure of a few XML files downloaded from the CKM, therefore, it 
was not possible to include all of them to this "cycles" investigation.








On 12/04/2012 17:44, Thomas Beale wrote:
> On 12/04/2012 17:20, Athanasios Anastasiou wrote:
>>
>>> BTW, these lexical rules are historical, and will be obsoleted one day -
>>> I more or less had to construct them after 100s of archetypes that
>>> actually assume these rules had been built! You will see further down in
>>> the ADL 1.5 text an indication of the future, but for today, we are
>>> stuck with the above...
>> Oh joy. (Yes, i did notice that part in the text, it will make the
>> constraint more strict but inserts yet more parsing).
>>
>> Is there a single BNF description of ADL 1.5 available from somewhere?
>> *
>> *
>
> yep, they are here
> 
> - fairly standard .y and .l files.
>
> - thomas