I was saying that because some of the conditions Thomas said are really clinical knowledge. I want to be able to express that one value should be always greater than another, or that a score value of a scale (norton, barthel...) is the addition of other parts of the archetype. That's what I think should be put on the archetype.
I agree with you that GUI should not be on the archetype 2011/3/23 Seref Arikan <serefarikan at kurumsalteknoloji.com>: > Hi Diego, > Ignoring a section of an archetype/template does not mean that the > formalism is now extending its scope beyond data. It does not matter > that I ignore it. If it is there, someone will use it, and send that > to my system, saying that I've used this feature, so you need to do > the same if you want to achieve the intended result. > Every change, every addition in ADL space is reflected to multiple > dimensions. I'll repeat it again, if someone is interested in > developing a formalism using constraint based expressions of ADL, to > model GUI/behaviour/etc, there is nothing wrong with that. Just do it > out of the archetype, link that artefact to an archetype, and > share/use it with the archetype. This way, everything stays clean, and > everyone gets what they want. > > Regards > Seref > > > On Wed, Mar 23, 2011 at 1:30 AM, Diego Bosc? <yampeku at gmail.com> wrote: >> 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 >>> >> >> _______________________________________________ >> 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 >
