GUI stuff in AOM/ADL? (Was: future ADL-versions)
Hi guys, If I were to snip in my two cents... The further we (GastrOS team) delve into GUI generation from templates/archetypes, we're increasingly facing the question: where is the line between the domain model and program behaviour? I have a feeling that especially in modern software systems (clinical ones included) there is an increasing expectation for rich user experiences and basically a movement away from rigid CRUD-type interactions (where the choice of GUI elements are effectively driven by the underlying data model) to a more fluid set of interactions that essentially puts the user in charge (so almost every piece of functionality is accessible from another in one or two steps). So what this means in terms of modelling is that often having the domain model defined is nowhere near enough to define the complete set of program behaviour (and hence the working program itself). And often the two (model and behaviour) are intricately linked, especially from the user's perspective. In fact, my experience and intuition is that users nowadays tend to think more in terms of what they want the program to DO, than what the program should HAVE. So things like I want it to pop up a dialog here, when I click this, and when I'm on this form I want to be able to edit this and that. What we have tried to do so far was to effectively include all of this interaction stuff into the template (as annotations) so as to retain the ability to completely and dynamically generate a fully functioning GUI from the model alone. So far we have managed it successfully, largely thanks to the relatively structured and uniform degree of user interaction mechanism that's sufficient for our system requirements. But yes, if we were to try building say a PMS just from our models, that'd be pretty crazy. I do think it's wise to separate the behaviour stuff out of the model, and come up with a solid formalism for expressing it. As Seref and others point out, the more we clutter the model with program-specific concepts, the less reusable they would be across different usage scenarios. But I think we do need to probe deeper into the question of, again, what's the distinction between data model and behaviour? In ADL we already have mechanisms for expressing ceratin kinds of constraints, and there would be a natural expectation for the GUI to filter out the user interactions so as to prevent the model from violating these contraints. E.g. disable an input field at certain times. So is that considered behaviour, or part of model? That's the kind of distinction I'm talking about. I hope I've articulated the issue clearly enough. all the best, Hong Yul On 29/03/2011 4:23 p.m., Koray Atalag wrote: Hi Tom, others I now see all points. I really like the idea of specialised templates used for GUI hints (as well as for other usual purposes) and that we have the usual shared templates without any of this. I am happy to put our contributions and encourage others to do so. The thing is many of the design decision we made were influenced by our lead developer, Dr. Yang, who didn't really know much about openEHR in the beginning. But he ws able to relate many existing software engineering practices and theory to this world. I thing we need to engage more people who are are really objective in this space. Cheers, -koray *From:* openehr-technical-bounces at openehr.org [openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale [thomas.beale at oceaninformatics.com] *Sent:* Saturday, 26 March 2011 2:05 a.m. *To:* openehr-technical at openehr.org *Subject:* Re: GUI stuff in AOM/ADL? (Was: future ADL-versions) On 25/03/2011 03:05, Koray Atalag wrote: Hi Eric, good points...As you may remember we had this discussion on this list not so long ago and I don?t remember any action taken after that. I guess we should take lead and come up with some proposal. Perhaps it?d be good to have a wiki space - but I want to repeat myself: someone from core group must guide the group and provide early feedback whether we are on the right track or not. To all interested in this area: in terms of innovation and ideas, the people in this discussion are the 'core group'. Advice from myself and others historically working on the specifications is as I have already posted, i.e. IMO, stick to the separation of concerns with respect to artefacts. I personally would not include GUI-related hints in templates either, because there will eventually emerge some templates that are widely shared, e.g. national and international (e.g. European) discharge summary, referral, e-prescription etc - but whose GUI models are very unlikely to be shared. On that view of things, you don't want to have to revise such a published resource due to some particular GUI directives buried inside it. This doesn't mean
GUI stuff in AOM/ADL? (Was: future ADL-versions)
Hi Tom, others I now see all points. I really like the idea of specialised templates used for GUI hints (as well as for other usual purposes) and that we have the usual shared templates without any of this. I am happy to put our contributions and encourage others to do so. The thing is many of the design decision we made were influenced by our lead developer, Dr. Yang, who didn't really know much about openEHR in the beginning. But he ws able to relate many existing software engineering practices and theory to this world. I thing we need to engage more people who are are really objective in this space. Cheers, -koray From: openehr-technical-bounces at openehr.org [openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale [thomas.be...@oceaninformatics.com] Sent: Saturday, 26 March 2011 2:05 a.m. To: openehr-technical at openehr.org Subject: Re: GUI stuff in AOM/ADL? (Was: future ADL-versions) On 25/03/2011 03:05, Koray Atalag wrote: Hi Eric, good points...As you may remember we had this discussion on this list not so long ago and I don?t remember any action taken after that. I guess we should take lead and come up with some proposal. Perhaps it?d be good to have a wiki space - but I want to repeat myself: someone from core group must guide the group and provide early feedback whether we are on the right track or not. To all interested in this area: in terms of innovation and ideas, the people in this discussion are the 'core group'. Advice from myself and others historically working on the specifications is as I have already posted, i.e. IMO, stick to the separation of concerns with respect to artefacts. I personally would not include GUI-related hints in templates either, because there will eventually emerge some templates that are widely shared, e.g. national and international (e.g. European) discharge summary, referral, e-prescription etc - but whose GUI models are very unlikely to be shared. On that view of things, you don't want to have to revise such a published resource due to some particular GUI directives buried inside it. This doesn't mean that the ADL (abstract or XML form) formalism can't be used, but I still think a separation of the pieces will make dependency and release management a lot easier. Erik may be right: if the GUI hints can be expressed in a template, then by definition, it can be done in a specialised template, and that can clearly be local. At the moment, we have to consider this area as 'industrial research', and I for one would encourage all experimentation to be published and flagged on this list, as a way of getting us all on the same page with respect to lessons being learned. - thomas beale -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110329/2966f07b/attachment.html
GUI stuff in AOM/ADL? (Was: future ADL-versions)
Hi Koray, I think we are the core group, and if we can agree some basic notation of some basic GUI directives (there are some thoughts of mine on the wiki: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates) and can implement them in a consistent way (we all use heterogeneous technologies), we can lead the definition and improvement of this inside the standard. We have to options: 1. keep waiting for some signal, 2. think outside the box and take the lead. Any one who want #2 and have time to work can drop me a line to coordinate the required work, share experiences and colaborate on this subject. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: k.ata...@auckland.ac.nz To: openehr-technical at openehr.org Date: Fri, 25 Mar 2011 16:05:22 +1300 Subject: RE: GUI stuff in AOM/ADL? (Was: future ADL-versions) Hi Eric, good points...As you may remember we had this discussion on this list not so long ago and I don?t remember any action taken after that. I guess we should take lead and come up with some proposal. Perhaps it?d be good to have a wiki space - but I want to repeat myself: someone from core group must guide the group and provide early feedback whether we are on the right track or not. Cheers, -koray From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Thursday, 24 March 2011 9:06 p.m. To: For openEHR technical discussions Subject: GUI stuff in AOM/ADL? (Was: future ADL-versions) Hi! Yesterday I asked if anybody had any motivated objections to using the openEHR template formalism as a layer to catch some GUI-hints/rules. I bring it up again to get some response :-) The point to have separate concerns in separate artifacts is often good. Regarding GUI-hints it seems reasonable to not have them at the clinical archetype level, and in some cases not at a first clinically focused template level either. But, as we have discussed earlier, through specialisation and/or inclusion it's possible to have several layers of openEHR templates. This means that ADL or some other serialisation format of the archetype object model (that now will include templates) can be used for GUI-related annotations and GUI-related logic in some form. Does anybody have concerns or worries regarding this? You could still have separate artifacts by splitting reusable clinical modeling and use case specific GUI modeling in separate layers of templates. A nice thing with reusing the template formalism for catching GUI stuff is that shared tools and understanding is already in place as opposed to inventing some new purely GUI-related formalism. Also in some cases it's likely that the same groups that are designing archetypes and clinically focused templates will have knowledge of some use cases in which they know what they'd want to happen on the GUI side. Then it would be nice to be able to reuse people, tools, template governance repositories etc. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 P.s. (off topic)I'm not sure it's always optimal to split everything into separate artifacts, especially when it comes boundary problems like terminology bindings. You could argue that the binding should be done in a separate artifact that is neither part of archetypes nor part of terminologies, but I'm not sure that would always make things better. Having the bindings in the archetype forces the archetype authors to revise the bindings at the same time as they revise an archetype and that might be good. On the other hand you could argue that a SNOMED CT refset might be exactly such a third artifact that can be used for managing bindings. But if you would have three different groups maintaining archetypes, refsets and terminology systems then you'd better keep them very well aware of each other's actions... On Wed, Mar 23, 2011 at 21:09, pablo pazos pazospablo at hotmail.com wrote:I agree with Thomas, in order to have a clean design we need to separate the concerns of our artifacts. If we have a solid base to our complete clinical data structures like Archetypes, we can define other upper layer artifacts to model rules, conditions, gui directives, etc. I like this approach because we can solve one problem at a time, instead of having a messy one-fits-all solution. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110325/af79ad43/attachment.html
GUI stuff in AOM/ADL? (Was: future ADL-versions)
Maybe we could use as inspiration all the available XML to GUI efforts that already exist. Mostly to avoid reinventing the wheel 2011/3/25 pablo pazos pazospablo at hotmail.com: Hi Koray, I think we are the core group, and if we can agree some basic notation of some basic GUI directives (there are some thoughts of mine on the wiki: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates) and can implement them in a consistent way (we all use heterogeneous technologies), we can lead the definition and improvement of this inside the standard. We have to options: 1. keep waiting for some signal, 2. think outside the box and take the lead. Any one who want #2 and have time to work can drop me a line to coordinate the required work, share experiences and colaborate on this subject. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: k.atalag at auckland.ac.nz To: openehr-technical at openehr.org Date: Fri, 25 Mar 2011 16:05:22 +1300 Subject: RE: GUI stuff in AOM/ADL? (Was: future ADL-versions) Hi Eric, good points...As you may remember we had this discussion on this list not so long ago and I don?t remember any action taken after that. I guess we should take lead and come up with some proposal. Perhaps it?d be good to have a wiki space ?- but I want to repeat myself: someone from core group must guide the group and provide early feedback whether we are on the right track or not. Cheers, -koray From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Thursday, 24 March 2011 9:06 p.m. To: For openEHR technical discussions Subject: GUI stuff in AOM/ADL? (Was: future ADL-versions) Hi! Yesterday I asked if anybody had any motivated objections to using the openEHR template formalism as a layer to catch some GUI-hints/rules. I bring it up again to get some response :-) The point to have separate concerns in separate artifacts is often good. Regarding GUI-hints it seems reasonable to not have them at the clinical archetype level, and in some cases not at a first clinically focused template level either. But, as we have discussed earlier, through specialisation and/or inclusion it's possible to have several layers of openEHR templates. This means that ADL or some other serialisation format of the archetype object model (that now will include templates) can be used for GUI-related annotations and?GUI-related?logic in some form. Does anybody have concerns or worries regarding this? You could still have separate artifacts by splitting reusable clinical modeling and use case specific GUI modeling in separate layers of templates. A nice thing with reusing the template formalism for catching GUI stuff is that shared tools and understanding is already in place as opposed to inventing some new purely GUI-related formalism. Also?in some cases it's likely that the same groups that are designing archetypes and clinically focused templates will have knowledge of some use cases in which they know what they'd want to happen on the GUI side. Then it would be nice to be able to reuse people, tools, template governance repositories etc. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 P.s. (off topic) I'm not sure it's always optimal to split everything into separate artifacts, especially when it comes boundary problems like terminology bindings. You could argue that the binding should be done in a separate artifact that is neither part of archetypes nor part of terminologies, but I'm not sure that would always make things better. Having the bindings in the archetype forces the archetype authors to revise the bindings at the same time as they revise an archetype and that might be good. On the other hand you could argue that a SNOMED CT refset might be exactly such a third artifact that can be used for managing bindings. But if you would have three different groups maintaining archetypes, refsets and terminology systems then you'd better keep them very well aware of each other's actions... On Wed, Mar 23, 2011 at 21:09, pablo pazos pazospablo at hotmail.com wrote: I agree with Thomas, in order to have a clean design we need to separate the concerns of our artifacts. If we have a solid base to our complete clinical data structures like Archetypes, we can define other upper layer artifacts to model rules, conditions, gui directives, etc. I like this approach because we can solve one problem at a time, instead of having a messy one-fits-all solution. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk
GUI stuff in AOM/ADL? (Was: future ADL-versions)
That's a good starting point. Here is our effort to make usable GUI templates: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates This is developed, documented and working ok. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: yampeku at gmail.com Date: Fri, 25 Mar 2011 14:32:41 +0900 Subject: Re: GUI stuff in AOM/ADL? (Was: future ADL-versions) To: openehr-technical at openehr.org Maybe we could use as inspiration all the available XML to GUI efforts that already exist. Mostly to avoid reinventing the wheel 2011/3/25 pablo pazos pazospablo at hotmail.com: Hi Koray, I think we are the core group, and if we can agree some basic notation of some basic GUI directives (there are some thoughts of mine on the wiki: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates) and can implement them in a consistent way (we all use heterogeneous technologies), we can lead the definition and improvement of this inside the standard. We have to options: 1. keep waiting for some signal, 2. think outside the box and take the lead. Any one who want #2 and have time to work can drop me a line to coordinate the required work, share experiences and colaborate on this subject. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: k.atalag at auckland.ac.nz To: openehr-technical at openehr.org Date: Fri, 25 Mar 2011 16:05:22 +1300 Subject: RE: GUI stuff in AOM/ADL? (Was: future ADL-versions) Hi Eric, good points...As you may remember we had this discussion on this list not so long ago and I don?t remember any action taken after that. I guess we should take lead and come up with some proposal. Perhaps it?d be good to have a wiki space - but I want to repeat myself: someone from core group must guide the group and provide early feedback whether we are on the right track or not. Cheers, -koray From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Thursday, 24 March 2011 9:06 p.m. To: For openEHR technical discussions Subject: GUI stuff in AOM/ADL? (Was: future ADL-versions) Hi! Yesterday I asked if anybody had any motivated objections to using the openEHR template formalism as a layer to catch some GUI-hints/rules. I bring it up again to get some response :-) The point to have separate concerns in separate artifacts is often good. Regarding GUI-hints it seems reasonable to not have them at the clinical archetype level, and in some cases not at a first clinically focused template level either. But, as we have discussed earlier, through specialisation and/or inclusion it's possible to have several layers of openEHR templates. This means that ADL or some other serialisation format of the archetype object model (that now will include templates) can be used for GUI-related annotations and GUI-related logic in some form. Does anybody have concerns or worries regarding this? You could still have separate artifacts by splitting reusable clinical modeling and use case specific GUI modeling in separate layers of templates. A nice thing with reusing the template formalism for catching GUI stuff is that shared tools and understanding is already in place as opposed to inventing some new purely GUI-related formalism. Also in some cases it's likely that the same groups that are designing archetypes and clinically focused templates will have knowledge of some use cases in which they know what they'd want to happen on the GUI side. Then it would be nice to be able to reuse people, tools, template governance repositories etc. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 P.s. (off topic) I'm not sure it's always optimal to split everything into separate artifacts, especially when it comes boundary problems like terminology bindings. You could argue that the binding should be done in a separate artifact that is neither part of archetypes nor part of terminologies, but I'm not sure that would always make things better. Having the bindings in the archetype forces the archetype authors to revise the bindings at the same time as they revise an archetype and that might be good. On the other hand you could argue that a SNOMED CT refset might be exactly such a third artifact that can be used for managing bindings. But if you would have three different groups maintaining archetypes, refsets and terminology systems
GUI stuff in AOM/ADL? (Was: future ADL-versions)
On 25/03/2011 03:05, Koray Atalag wrote: Hi Eric, good points...As you may remember we had this discussion on this list not so long ago and I don't remember any action taken after that. I guess we should take lead and come up with some proposal. Perhaps it'd be good to have a wiki space - but I want to repeat myself: someone from core group must guide the group and provide early feedback whether we are on the right track or not. To all interested in this area: in terms of innovation and ideas, the people in this discussion are the 'core group'. Advice from myself and others historically working on the specifications is as I have already posted, i.e. IMO, stick to the separation of concerns with respect to artefacts. I personally would not include GUI-related hints in templates either, because there will eventually emerge some templates that are widely shared, e.g. national and international (e.g. European) discharge summary, referral, e-prescription etc - but whose GUI models are very unlikely to be shared. On that view of things, you don't want to have to revise such a published resource due to some particular GUI directives buried inside it. This doesn't mean that the ADL (abstract or XML form) formalism can't be used, but I still think a separation of the pieces will make dependency and release management a lot easier. Erik may be right: if the GUI hints can be expressed in a template, then by definition, it can be done in a specialised template, and that can clearly be local. At the moment, we have to consider this area as 'industrial research', and I for one would encourage all experimentation to be published and flagged on this list, as a way of getting us all on the same page with respect to lessons being learned. - thomas beale* * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110325/3ae62633/attachment.html
GUI stuff in AOM/ADL? (Was: future ADL-versions)
Hi! Yesterday I asked if anybody had any motivated objections to using the openEHR template formalism as a layer to catch some GUI-hints/rules. I bring it up again to get some response :-) The point to have separate concerns in separate artifacts is often good. Regarding GUI-hints it seems reasonable to not have them at the clinical archetype level, and in some cases not at a first clinically focused template level either. But, as we have discussed earlier, through specialisation and/or inclusion it's possible to have several layers of openEHR templates. This means that ADL or some other serialisation format of the archetype object model (that now will include templates) can be used for GUI-related annotations and GUI-related logic in some form. Does anybody have concerns or worries regarding this? You could still have separate artifacts by splitting reusable clinical modeling and use case specific GUI modeling in separate layers of templates. A nice thing with reusing the template formalism for catching GUI stuff is that shared tools and understanding is already in place as opposed to inventing some new purely GUI-related formalism. Also in some cases it's likely that the same groups that are designing archetypes and clinically focused templates will have knowledge of some use cases in which they know what they'd want to happen on the GUI side. Then it would be nice to be able to reuse people, tools, template governance repositories etc. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 P.s. (off topic) I'm not sure it's always optimal to split everything into separate artifacts, especially when it comes boundary problems like terminology bindings. You could argue that the binding should be done in a separate artifact that is neither part of archetypes nor part of terminologies, but I'm not sure that would always make things better. Having the bindings in the archetype forces the archetype authors to revise the bindings at the same time as they revise an archetype and that might be good. On the other hand you could argue that a SNOMED CT refset might be exactly such a third artifact that can be used for managing bindings. But if you would have three different groups maintaining archetypes, refsets and terminology systems then you'd better keep them very well aware of each other's actions... On Wed, Mar 23, 2011 at 21:09, pablo pazos pazospablo at hotmail.com wrote: I agree with Thomas, in order to have a clean design we need to separate the concerns of our artifacts. If we have a solid base to our complete clinical data structures like Archetypes, we can define other upper layer artifacts to model rules, conditions, gui directives, etc. I like this approach because we can solve one problem at a time, instead of having a messy one-fits-all solution. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110324/63e8fc42/attachment.html
GUI stuff in AOM/ADL? (Was: future ADL-versions)
Hi Erik, In the past months we have talked about the scope of each artifact. One thing that is clear is that we can have structural templates and GUI templates, that can be defined, shared and used separately, but GUI templates can rely on structural templates, as structural templates rely on archetypes. Here is a reference to the discussion: http://lists.chime.ucl.ac.uk/mailman/private/openehr-technical/2011-January/005787.html -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Thu, 24 Mar 2011 09:05:49 +0100 Subject: GUI stuff in AOM/ADL? (Was: future ADL-versions) From: erik.sundv...@liu.se To: openehr-technical at openehr.org Hi! Yesterday I asked if anybody had any motivated objections to using the openEHR template formalism as a layer to catch some GUI-hints/rules. I bring it up again to get some response :-) The point to have separate concerns in separate artifacts is often good. Regarding GUI-hints it seems reasonable to not have them at the clinical archetype level, and in some cases not at a first clinically focused template level either. But, as we have discussed earlier, through specialisation and/or inclusion it's possible to have several layers of openEHR templates. This means that ADL or some other serialisation format of the archetype object model (that now will include templates) can be used for GUI-related annotations and GUI-related logic in some form. Does anybody have concerns or worries regarding this? You could still have separate artifacts by splitting reusable clinical modeling and use case specific GUI modeling in separate layers of templates. A nice thing with reusing the template formalism for catching GUI stuff is that shared tools and understanding is already in place as opposed to inventing some new purely GUI-related formalism. Also in some cases it's likely that the same groups that are designing archetypes and clinically focused templates will have knowledge of some use cases in which they know what they'd want to happen on the GUI side. Then it would be nice to be able to reuse people, tools, template governance repositories etc. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 P.s. (off topic)I'm not sure it's always optimal to split everything into separate artifacts, especially when it comes boundary problems like terminology bindings. You could argue that the binding should be done in a separate artifact that is neither part of archetypes nor part of terminologies, but I'm not sure that would always make things better. Having the bindings in the archetype forces the archetype authors to revise the bindings at the same time as they revise an archetype and that might be good. On the other hand you could argue that a SNOMED CT refset might be exactly such a third artifact that can be used for managing bindings. But if you would have three different groups maintaining archetypes, refsets and terminology systems then you'd better keep them very well aware of each other's actions... On Wed, Mar 23, 2011 at 21:09, pablo pazos pazospablo at hotmail.com wrote: I agree with Thomas, in order to have a clean design we need to separate the concerns of our artifacts. If we have a solid base to our complete clinical data structures like Archetypes, we can define other upper layer artifacts to model rules, conditions, gui directives, etc. I like this approach because we can solve one problem at a time, instead of having a messy one-fits-all solution. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110324/e3937741/attachment.html
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
future ADL-versions
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
future ADL-versions
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
future ADL-versions
Hi Heath, As long as it is about data, I have no objection to richer semantics via additions to formalism. I've tried to avoid making comments about GUI directives in openEHR specifications in the past, but now that you have mentioned it, I consider those to be at least as evil as inheritence in XML (here we go...) I'd like to see archetypes being about domain data. Just because the formalism is powerful enough to express something, should not mean that we include it in the model for convenience. It may work in some cases, but ADL is supposed to be consumed in so many contexts, in so many technologies. You should never open way to certain things in your design, because if is a well known design error, the size does not matter. People will abuse it, and it'll become a problem which will stick, due to backward compatibility. I know you know all of these, but I am writing this down, due to seeing repeating discussions about pushing aspects of other layers into ADL. Any software design book/course/seminar will tell everyone that it is bad to have gui related stuff in your business logic. We go to great distances to separate layers of software, introduce huge frameworks just for this, and then we forget why we've done that and go back to discussions about having GUI and behaviour in models. It is wrong, and I think it is reaching a frequency that requires some reminding about the bitter experiences of the past. Kind regards Seref On Wed, Mar 23, 2011 at 1:20 AM, Heath Frankel heath.frankel at oceaninformatics.com wrote: 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
future ADL-versions
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
future ADL-versions
Hi! On Wed, Mar 23, 2011 at 11:42, Seref Arikan serefarikan at kurumsalteknoloji.com wrote: 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 Just a clarifying double-check: I assume you wouldn't mind GUI-hints etc in some template layer. Correct? Since ADL can be used for both templates and archetypes it can be good to be clarify. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110323/5cd9fe6e/attachment.html
future ADL-versions
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 Arikanserefarikan 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 Frankelheath.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 Verheesbert.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
future ADL-versions
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 Verheesbert.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 is200, 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
future ADL-versions
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 Verheesbert.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 Verheesbert.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
future ADL-versions
The need to express things like the Barthel sum of scores, or other multi-attribute constraints is already part of ADL. It is not yet well supported in tools, but it is parsed in at least the ADL Workbench. As I said before the language of these expressions is pretty close to Xpath, partly based on work done by the Zilics guys in Sao Paulo. Xpath provides the first order predicate logic operators you need with paths to reference the model elements. ADL 1.5 is adding more power. I thought we had more or less agreed that GUI hints / transformation logic etc would no be in archetypes per se, because it complicates things to make one artefact do 2 jobs (e.g. it would mean published archetypes had to be revisioned when some obscure element of a GUI mapping was changed). So we are still looking for the right formal way to achieve this job. This doesn't mean it should not be done - just that it needs its own artefacts. - thomas On 23/03/2011 11:33, gjb wrote: 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 * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110323/7cf0c4e2/attachment.html
future ADL-versions
On 23/03/2011 11:41, Bert Verhees 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. this kind of thing is a (simple) clinical guideline, and needs its own representation. For one thing, BP and heart rate are in two different archetypes; neither is a sensible place to put the map of value ranges indicating normal / danger etc. This is the job of guideline languages and systems, on which decision support tools are based. Various reasons for this: * consider that today's understanding of the BP/HR interaction leads to a condition of if BP/systolic 140, next year, better science might tell us that in fact the right value for this purpose is 160. We don't want that value buried in archetypes. * the above formula, is a condition + action, and actions may require their own formalisms. They could be done using archetypes actually, based on a reference model of 'action primitives', but they would still be completely distinct from the health data archetypes we use today. - thomas Bert * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110323/11b40169/attachment.html
future ADL-versions
Sounds reasonable, thanks Bert Op 23-03-11 13:00, Thomas Beale schreef: On 23/03/2011 11:41, Bert Verhees 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. this kind of thing is a (simple) clinical guideline, and needs its own representation. For one thing, BP and heart rate are in two different archetypes; neither is a sensible place to put the map of value ranges indicating normal / danger etc. This is the job of guideline languages and systems, on which decision support tools are based. Various reasons for this: * consider that today's understanding of the BP/HR interaction leads to a condition of if BP/systolic 140, next year, better science might tell us that in fact the right value for this purpose is 160. We don't want that value buried in archetypes. * the above formula, is a condition + action, and actions may require their own formalisms. They could be done using archetypes actually, based on a reference model of 'action primitives', but they would still be completely distinct from the health data archetypes we use today. - thomas Bert * * ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110323/21f28bb1/attachment.html
future ADL-versions
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
future ADL-versions
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 * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110316/11d179c4/attachment.html
future ADL-versions
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
