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
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:
/path/to/systolic/pressure/value > /path/to/diastolic/pressure/value- elements in data elsewhere in the same EHR like:
$date_of_birth:ISO8601_DATE ::= query(“ehr”, “date_of_birth”)
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
$current_date
$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
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
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
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
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
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
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
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
Hi!
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
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:
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:
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.
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:
Sounds reasonable,
thanks
Bert
Op 23-03-11 13:00, Thomas Beale schreef:
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 to issues in
maintainability, and its correct use requires a lot of experience.
Imagine having a set of database tables, along with some stored
procedures. In your product/information system you may manage this
combination, while leveraging the benefits of performance. What if you
were using PostgreSql and you decided to share your database design
with others?
Your table design would be expressed in DDL, which would be highly
portable to other databases like Sql Server, or Oracle. Your stored
procedures on the other hand are written in pl/pgsql, which does not
mean anything in Sql server world. It can be ported fairly easily to
Oracle, but that is still porting. It may get worse, since modern
rdms products allow you to plug/in languages to write stored
procedures, so it may be python, C# or java you have in your hands,
that contains behaviour.
This is the problem I'm talking about. Now to the way this is handled
in db world
In this case, you'd be able to carry your table structure to other dbs
(with some help from tools and some tweaking), because the DB domain
keeps table structure and stored procedures separate. Many design
tools will read a db schema from a database, and generate sql
statements to generate the same tables in another db server. They
can't however, transfer the stored procedure code.
If you were to join both table structure statements and stored
procedures in the same formalism, you would not be able to move them
around, unless every db implements every stored procedure
language/runtime.
So the db domain already does what I suggest we do. It keeps data and
behaviour separate. There is DDL and there is stored procedures. Every
time you mix them, you have issues in sharing them with others, which
is what openEHR is all about!
Regards
Seref
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.