Some people I work with ask for this feature, I find it hard to explain why this should not be done.
Can you compare it with Stored Procedures in database-applications which have the risk of bringing software-logic (f.e. from business-tier) to the database-tier, and there for often is regarded as bad design because requirements/concepts get mixed up? Although from performance point of view, stored procedures are often the best performing modules in an application. Anyway, most RDB's support stored procedures. Why would that be? I hope not to encourage bad design? Am I coming close to understanding of your criticism? Bert Op 23-03-11 12:07, Seref Arikan schreef: > Also look at heartbeat is the problem here. My criticism stands, for > every case your rules/guidelines go beyond data. > > Best Regards > Seref > > > On Wed, Mar 23, 2011 at 11:05 AM, Bert Verhees<bert.verhees at rosa.nl> > wrote: >> The idea is to implement guideline/rules etc in Archetypes. >> In this way you can force software to look at some conditions if some other >> conditions are met. >> >> As I gave an example: If bloodpressure> value -->> also look at heartbeat. >> >> Bert >> >> >> Op 23-03-11 00:32, Seref Arikan schreef: >>> 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 >>>> >> >
