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
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 :
> Hi Seref,
> I agree with you sediments regarding Arch
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 XM
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
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 s
ists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110323/5cd9fe6e/attachment.html>
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 oth
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
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
I
> 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>
ld 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>
;> 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>
Sure,
First, let me use this example to demonstrate the problem I'm trying
to point out, and then I'll explain point out to details of the
principles I'm recommending in the db domain.
Including behaviour in database is a choice given to you by most of
the product vendors. It may or may not lead t
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110323/1fdb0b61/attachment.html>
14 matches
Mail list logo
