I will suggest a new optional section on the ADL, if those conditions end in the archetype tree structure it could really be a mess.
So if you just want to look for the structure you only have to ignore that section 2011/3/23 Heath Frankel <heath.frankel at oceaninformatics.com>: > Hi Seref, > I agree with you sediments regarding Archetypes. ?However, the AOM still > needs to support something like this for templates, in my view this is the > level where we will want to start making conditional statements about data > constraints (and this is still before we get to the GUI, as I may have the > same conditional constraint requirement in an integration scenario). > > Heath > >> -----Original Message----- >> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- >> bounces at openehr.org] On Behalf Of Seref Arikan >> Sent: Wednesday, 23 March 2011 10:03 AM >> To: For openEHR technical discussions >> Subject: Re: future ADL-versions >> >> Greetings, >> I have a single question about this particular requirement/idea: why? >> >> Archetypes are model artefacts. That is it. They are supposed to >> describe domain models in a certain way. Behaviour or software that >> uses those models is a completely different thing. I can understand a >> constraint which references another one for defining a valid interval >> etc, but how on earth something like forcing a user for another entry >> is going to be handled during implementation? How would one express >> this in common formalisms like XML? >> >> I could understand a suggestion to use ADL to express rules regarding >> the archetypes, but that should be a formalism leaving in a separate >> space, which may be linked to archetypes, which >> only-contain-constraints-on-RM-types. >> >> Please keep behaviour our of models in ADL specifications. >> >> Regards >> Seref >> >> >> On Fri, Mar 18, 2011 at 8:10 PM, Bert Verhees <bert.verhees at rosa.nl> >> wrote: >> > Thanks, Thomas, for your reply. There is more to it then I initially >> > thought of. >> > >> > I am not very familiar with XPath. Best is to wait for more >> information >> > on the specs. >> > This is enough for now, to let customers give something to think >> about. >> > >> > Bert >> > >> > On 16-03-11 19:32, Thomas Beale wrote: >> >> >> >> Hi Bert, >> >> >> >> I hope to get back on the spec in the next couple of weeks. With >> respect >> >> to your specific question below, can you be a bit more precise? >> There >> >> are ways to express this kind of thing, but we need to be clear on >> >> distinguishing references to: >> >> >> >> ? ? * elements in the same archetype - as in a rule like: >> >> ? ? ? ? ? o /path/to/systolic/pressure/value > >> >> ? ? ? ? ? ? /path/to/diastolic/pressure/value >> >> ? ? * elements in data elsewhere in the same EHR like: >> >> ? ? ? ? ? o $date_of_birth:ISO8601_DATE ::= query(?ehr?, >> ?date_of_birth?) >> >> ? ? ? ? ? o this is still being finalised, so don't depend on it; >> >> ? ? ? ? ? ? however it is the left hand side that matters, i.e. >> >> ? ? ? ? ? ? $date_of_birth >> >> ? ? * environmental values, like >> >> ? ? ? ? ? o $current_date >> >> ? ? ? ? ? o $current_time >> >> >> >> Some of this is still being finalised, but the general syntax will >> look >> >> like Xpath and the object model will be what you would expect from >> that. >> >> >> >> - thomas >> >> >> >> On 10/03/2011 15:48, Bert Verhees wrote: >> >>> Hi, >> >>> >> >>> I am sorry, but I am to busy to read all the discussions on future >> >>> ADL-versions. >> >>> So, now I have a small question, which possible is already >> explained, >> >>> >> >>> Is it possible to write conditional constraints in future ADL? >> >>> >> >>> The question is about implementing care-protocol into an archetype. >> >>> >> >>> For example, if blood-pressure is> ?200, force to use another >> entry, for >> >>> example also look at heartbeat >> >>> >> >>> Is there any idea when this new specifications will be in final >> version? >> >>> >> >>> Thanks >> >>> Bert >> >>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> > >> > _______________________________________________ >> > 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 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
