# future ADL-versions **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2011-03-10 15:48 UTC **Views:** 1 **Replies:** 17 **URL:** https://discourse.openehr.org/t/future-adl-versions/15046 --- ## Post #1 by @system 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 --- ## Post #2 by @thomas.beale 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 --- ## Post #3 by @system 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 --- ## Post #4 by @Seref 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 --- ## Post #5 by @Heath_Frankel3 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 --- ## Post #6 by @yampeku 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 --- ## Post #7 by @Seref 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 --- ## Post #8 by @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 --- ## Post #9 by @yampeku 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 --- ## Post #10 by @system Hi! --- ## Post #11 by @Gavin_Brelstaff > 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 --- ## Post #12 by @system 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: --- ## Post #13 by @system 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: --- ## Post #14 by @thomas.beale 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 --- ## Post #15 by @thomas.beale > ``` > 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 --- ## Post #16 by @system Sounds reasonable, thanks Bert Op 23-03-11 13:00, Thomas Beale schreef: --- ## Post #17 by @Seref 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 --- ## Post #18 by @pablo 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. --- **Canonical:** https://discourse.openehr.org/t/future-adl-versions/15046 **Original content:** https://discourse.openehr.org/t/future-adl-versions/15046