Archetype Slots Include - Exclude interpertation
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 http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADL%26AOM1.5-TemplatesandSpecialisedArchetypes-Parsergrammars - fairly standard .y and .l files. - thomas
Archetype Slots Include - Exclude interpertation
Hi Athanasios, I have a feeling that you're facing a problem due to your particular implementation approach. I can't fully understand your problem, but it sounds like you're doing everything based on archetypes. Remember that you also have templates. Almost everybody instinctively writes code that walks archetypes and creates GUI during runtime, when they first start working with openEHR. It almost sounds like you're doing something like this. If you can explain the specifics of your problem with a little bit more detail, it would be easier to help. Kind regards Seref On Mon, Apr 30, 2012 at 4:51 PM, Athanasios Anastasiou athanasios.anastasiou at plymouth.ac.uk wrote: 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 http://www.openehr.org/wiki/**pages/viewpage.action?pageId=** 196633#openEHRADL%26AOM1.5-**TemplatesandSpecialisedArchety** pes-Parsergrammarshttp://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.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://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
Archetype Slots Include - Exclude interpertation
-TemplatesandSpecialisedArchetypes-Parsergrammars - fairly standard .y and .l files. - thomas __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://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
://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
Questions about ADL/AOM 1.5, archetype flattening and operational templates
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
