On 23/03/2011 11:54, Diego Bosc? wrote: > 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
For me an avenue of clinical knowledge discovery should also be the ideas arriving from UI design - constraints revealed at the UI level may sometimes generalise in unseen ways and so should be able to inform the archetype at some time or another. I share Diego's "disappointment" in that openEHR seems to discourage the activity that many programmers adhere to: looking for generalization in your code and treating them as discovered knowledge about the domain. In practice, there is a natural barrier between archetype and code since ADL is a declarative language unlike most C, Python, Java etc. Trying to express complex co-occurence constraints in ADL is always going to look ugly and be difficult for non-programmer humans to parse/deal with. Nevertheless, for me, this meeting point between archetype and GUI constraint asks to be a fertile area of research - HCI at its most profound IMHO - not to be left to terminology services. [just my 2 cents] Gavin Brelstaff - CRS4 > 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
