# Link between goals and other clinical concepts **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2014-06-13 19:21 UTC **Views:** 2 **Replies:** 43 **URL:** https://discourse.openehr.org/t/link-between-goals-and-other-clinical-concepts/15050 --- ## Post #1 by @pablo Hi, if I want to establish a goal for body weight, I think there's a need of linking the goal concept with the body weight concept, but the body weight archetype is for measuring the weight not to specify a goal for it. I understand the difference between a goal (what you want to achieve, fixed value) and the measures (to control your progress and compare with the goal, variable value through time). Also, I think the target measurement from the goal archetype will depend on the specific concept I'm creating a goal for (body weight), I mean the magnitude and units constraints should be inherited someway from the concept I'm measuring (body weight) into the goal archetype. Does anyone has an idea of how will be a good way of modeling a goal related to another concept like weight or BP? Thanks! --- ## Post #2 by @pablo Hi all, does my previous message make sense? --- ## Post #3 by @Hugh_Leslie1 Hi Pablo, I think that you need a higher level model to link the two things together\. openEHR is about modelling the clinical content at the level of what do we want to record in our systems\. When we start thinking about workflow, careplans, etc, we need to utilise data within a higher level construct that manages these things\. At the moment, openEHR doesn't have these kind of higher level models but may go there at some stage\. We have done a lot of work in care planning and have a system that enables problems with a list of goals and targets\. These are all archetyped and captured in compositions based on templates that are constructed from the base archetypes\. This gives us a way of recording the data points we need, however the workflow and management of these things is done in software\. Hope that helps\. Regards Hugh --- ## Post #4 by @Dr_Marivan_Santiago Pablo, It does make sense, but one should consider a third concept - psychology - that keeps off the goal concept from empiric ground and fosters the body weight concept to a real target measurement.

Hi all, does my previous message make sense? --- ## Post #5 by @heather.leslie Hi Pablo, Is it safe to assume that you’ve seen the current archetype for Goal? It is here: [http://www.openehr.org/ckm/#showArchetype_1013.1.124](http://www.openehr.org/ckm/#showArchetype_1013.1.124) In it we have a data element that specifically identifies the archetype and path of the specific node that should be used to capture the actual measurement, eg the weight or height or systolic blood pressure. This combination of the EVALUATION.goal archetype with various target OBSERVATIONs for recording the actual data is being used in implementations in Australia as part of a personalised care plan, as Hugh has indicated. The correlation with magnitude and unit constraints would be nice to have, but is not currently easy to achieve. Regards Heather --- ## Post #6 by @pablo Hi Heather! Yes, I was evaluating the goal archetype. Great, now I get what the "Target archetype node" is for. About that I have a question, what's the role of the "Target measurement"? My understanding was that's the value set for the goal (e.g. target body weight), not the measurement to be evaluated against the goal (e.g. current body weight). If that value is the measurement, where should the value for the goal be set? Or the idea is not to set a value like quantity but set a text in "Target". My question was focused on the relationship between the value set for the target goal and the archetype used to record the measurements to be compared with the value of the goal. Because the goal and the measurements should comply the same constraints (magnitude, units, etc) Also, what about when you have a goal for the BP and you need to specify a value for systolic and diastolic? Should I create two instances of the goal? (One for systolic and one for diastolic). Thanks! --- ## Post #7 by @pablo Hi Marivan, I don't fully understand your comment, can you elaborate? Thanks! [details="(attachments)"] ![image002.gif|150x93](upload://5p4OY0MKZ8BHwMKFVOz9BAbpQ9W.gif) [/details] --- ## Post #8 by @pablo Hey Hugh! How are you? I was afraid to reach that conclusion and hoping to an openEHR native solution. One thing I was thinking of was to specialize the current goal archetype to create, lets say, a body weight goal, is that a valid approach? About what you do in your care planning app, that's exactly what we need to do in a small mobile app. I will publish the outcomes later. Thanks! --- ## Post #9 by @heather.leslie Hi Pablo, Comments inline Heather --- ## Post #10 by @Mark_Leaning Hi Pablo In cardiovascular decision support for critical care, we found that we needed to define a goal or target zone defined by upper and lower limits for both arterial blood pressure and cardiac output. You might like to consider this sort of situation as well as you develop your openEHR constructs. Best wishes Mark --- ## Post #11 by @pablo Hi Mark, good catch. Yes, we already have ranges for each individual goal and also time frames + versioning, because the goal can change in time and you want to save previous values set for the same goal type (BP, weight, ...) to be compared with previously recorded values in different time frames. Thanks! --- ## Post #12 by @thomas.beale there will be one sooner rather than later, or at least the serious conversations to define it - this comes under the rubric of 'second order' clinical structures. Some work has been done on this already, and needs to be brought into the open - I'm going to try to do that in the next little while. - thomas --- ## Post #13 by @thomas.beale another thing to note - there are thoughts of how we might add a proper 'epistemic status' field to the reference model, which would allow any observation data based on archetype X (e.g. BMI, BP etc) to be marked as 'actual', 'planned', 'target', etc etc. I've been working on and off on an , which may provide some ideas. - thomas --- ## Post #14 by @pablo Hi Thomas, is that status similar to the mood idea of HL7 v3 / CDA in Acts? About the values, I see "actual" and "target" as something useful, but what's "planned" for? It seems to overlap a little with the concept of INSTRUCTION to be something to do in the future. Thanks! --- ## Post #15 by @thomas.beale that's true - and the existence of Observation / Evaluation / Instruction / Action deals with the coarse grained intentionality & epistemic status. However, at some point a somewhat more precise notion of epistemic status will be needed. E.g. to distinguish between the following for procedures: --- ## Post #16 by @ian.mcnicoll Hi Pablo, You can see an example of the Goal archetype in\-use via the SHN Heart Failure template at http://www.openehr.org/ckm/#showTemplate_1013.26.14 This was my interpretation, which I think aligns with Heather's but others may vary\! To answer Mark's point, I think the archetpye does support defining a range of values via the Interval datatypes\. As Thomas has said, this is the subject of some discussion in the CIMI world\. Although some sort of epistemic status flag/mood code seems attractive, it works very badly for Goal/Target\. It is pretty obvious that the contents of an archetype for Target Blood pressure is very different for that ob the measurement itself\. The only part of the highly complex blood pressure measurement archetype which has any value in the blood pressure target archetype are the systolic, diastolic and perhaps MAP datapoints and even at that level the original observation data point is a single value , whereas the target is likely to be an interval\. To make an epistemic flag work we would need to model the original measurement as an interval, which is entirely possible technically but requires us to further constrain the measurement archetype at template level to make it useable\. As Heather has pointed out, it might be possible to re\-model every key data point as an individual cluster or even element archetype but that imposes a very significant burden on the modelling work, particularly clinical review, where we would again effectively have to re\-create the existing blood pressure measurement archetype as a template with all of the additional constraints and aggregation\. I don't think the CIMI group have really taken this on\-board\. In a sense, at least for the 'Target/Goal' scenario, all that we want to do is to re\-use the datatype and units from the original 'measurement' archetype\. We probably need to use different SNOMED bindings and convert the data type to its INTERVAL equivalent\. So I would question whether there is any real value in re\-using the original constraint pattern\. Arguably the only attribute which is actually copied intact is the unit\. I think it might actually be more sensible to use the current approach where an existing archetype node is pointed to for information but that this is then used by tools to replicate/adapt the original constraints\. i\.e this is re\-use via copy/paste/edit rather than direct re\-use/inheritance\.aggregation\. I suppose it all comes down to the value of direct re\-use\. At least for the Target/Goal scenario, I suspect the overhead of doing this far outweighs any benefit, and I think may be another example of informaticians trying to construct ontologically pure and elegant solutions which actually just get in the way of implementation\. The eHealth record is fundamentally anti\-pattern\. Ian Ian --- ## Post #17 by @pablo Hi Ian / Thomas / Heather, That's weird, I didn't received Heathers' response email :) I think the idea of reusing CLUSTERs is cleaner and simpler than my idea of specializing the goal archetype. What's nice about that is if we add a slot in the current Body Weight archetype to a CLUSTER to hold the measurement record, the paths in the B.W. archetype may not change. About Thomas proposal, I see a lot of overlapping between the Epistemic Status and OBSERVATIONs / INSTRUCTIONs, and also with the INSTRUCTION state-machine states. So, I'm not 100% sure if we need add that, maybe if we find some use cases that can't be modeled otherwise, that would help. About using intervals for the measurements, I think that's overkill. A better idea would be just to reuse the constraints for units, magnitude and precision (if the target is DV_QUANTITY). So, if the archetype for the measurement defines constraints for those data fields, in the goal archetype I would set references to those constraints of each limit of the interval defined as goal. I don't really know if that reference can be done via SLOTs because the reference is not only to an archetype, is to a specific/fine grained part of that archetype, so we might need the path in the SLOT. Can this be done in ADL 1.4? Is planned to add this kind of fine-grained SLOTs to ADL 1.5? About goals like "Reduce BP", I think goals like that have implicit numeric semantics, and what we need are numeric values to be compared with measurements. When we specify "reduce" or "increase", the next questions is how much? So we need a number. Also, if we set an x..y interval for a goal and the current measurement is z, if z > y, the goal is to "reduce", but if z < x, the goal is to "increase" (that's the implicit semantics I mentioned above). I fact to have "reduce/increase" goals was a requirement in a current project and when I mentioned the implicit semantics they removed that requirement, now we have just intervals and first measurement to now if the goal is to increase or reduce. In general, and because this goal/measurement is really a pattern all over healthcare, I would like to find / define a "best practice" of modeling this using openEHR (maybe just a guide for ADL 1.4 but for ADL 1.5 we might propose some model changes for the IM or AOM to support this pattern as it support the HISTORY pattern and the INSTRUCTION/ACTION pattern to track state changes). What do you think about specifying how we all model the goal/measurement today to create a pool of real use cases, and then propose some openEHR friendly way(s) of modeling it? (as you notice I'm trying to avoid Hugh's proposal to use a higher level model to link goal and measurements :) Personally, I have a couple of experiences with this, is not much but is something: one was a complete system design to manage patients with chronic pain and the other a system to manage celiac patients. Both with goals and result tracking. --- ## Post #18 by @ian.mcnicoll Hi Pablo, I have copied Heather's response below\. I will stick with my assertion that changing the basic modelling approach to create CLUSTER or ELEMENT archetypes for every concievable 'targetable' datavalue will create a completely unmanagable set of models\. If the intention is to model data values \+ units \+ precision in a contextless fashion, it would be far more efficient to do this with a terminology like LOINC\. I also don't agree that every goal or even target has or needs a quantifiable reduction\. If you can forgive my stereotyping, that is very much an 'engineering' view of the world, which translates pretty poorly into clinical practice ;\-\) Of course we do sometimes need to specify actual targets but broad goals can be just as important, and often the only thing that can be asserted\. Having said that, I can see the argument for 're\-using' the systolic blood pressure unit/precision/range constraints from an Observation archetype in the context of a goal / target\. I think that can be acheived by treating the source archetype as a reference document/node without the need for a major and very complex/costly use of cluster and element archetypes by using tooling to point to the target archetype and importing the quantity constraints at specialisation or templating time\. There is a broader issue here about abstraction\. We can always get a more sophisticated about our re\-use of generic patterns, in ways that seem elegant and efficient, but in doing so we often leave behind a significant segment of our clinical stakeholders , and indeed dev\. community who are largely outsiders to this strange world\. If you ask us to re\-work every OBSERVATION archetype to use an ELEMENT or CLUSTER to represent each 'key ' data element\. you will force the creation of at least 3 artefacts instead of 1 \- The Observation container, 1 cluster/element for each data point, and a templated archetype so that we can get clinicians to look at 'blood pressure' in a clinically meaningful representation\. Ian Ian --- ## Post #19 by @pablo Hi Ian, Yes, creating CLUSTERs for all the stuff than can be measured and we can potentially define goals is a. a big job, b. will change a lot of currently stable archetypes. In this scenario, maybe the second option is to specialize the goal archetype for each specific measurement. This is a. less work compared to creating CLUSTERs, and b. but will create an implicit dependency to the measurement archetype (if that changes the goal archetype might need to be revised), but I think that is not going to happen too much. About the quantifiable goals, I'm biased by my experience. As I said, I would like to propose the creation of a use case list to see which kinds of goals are more frequent and how different implementations are modeling this. For not quantifiable goals, I don't know if we need a correlation between the archetype of the specification of the goal and the archetype of the measurement. So maybe this discussion only applies to quantifiable goals. For other goals like "low sodium diet" that can't be evaluated directly (the evaluation would be boolean: yes I'm following the diet, no I'm not following), but an indirectly evaluation can be made on a factor that depends on the diet like the BP: if the low sodium diet is followed by the user, the doctor can measure if the BP decreases. So instead of evaluating against the goal, this is evaluating other factors that depends on the goal and the compliance of that goal by the patient. To evaluate this kind of stuff, I agree with Hugh: we need a higher level on modeling, maybe something related to GDL. I think the most important things here are: a) find real use cases to be sure we can model them, b) differentiate quantifiable and not quantifiable goals, c) classify those goals in terms of "they can be modeled in openEHR" or "they need a higher level of modeling" (maybe by specializing the goal archetype, maybe with terminology, etc.). d) create a small modeling guideline just for goals and measurements, maybe just for "quantifiable" and "can be modeled with openEHR" goals. What do you think? --- ## Post #20 by @ian.mcnicoll Hi Pablo, \*\* Yes, creating CLUSTERs for all the stuff than can be measured and we can potentially define goals is a\. a big job, b\. will change a lot of currently stable archetypes\. \*\* Agree but the ongoing maintenance burden is even worse\. Specialisation is certainly a possibility\. The problem is that the potential targets are almost limitless and it would be difficult to know how many common specialisations to build\. The Heart failure template gives several real world examples, including a mix of quantifiable and non\-quantifiable goals\. I have modelled the non\-quantifiable examples as a goal without a target e\.g Goal = "Minimise heart failure related symptoms"\. I like the idea of a modelling guideline document and of identifying exceptions that cannot be handled by the current Goal archetype\. Ian I like the idea of a modelling gui --- ## Post #21 by @system I missed a part of the discussion, but maybe I get the point, or I see my hobbyhorse everywhere\. ;\-\) I have been thinking about this some time, and I started a few times a discussion about this subject\. But I must say, there is not much enthusiasm for this idea on this list\. Let me explain compactly\. Take a look at the EN13606 RM which is already much more generic then OpenEHR\. You can model archetypes for it with the LinkEHR archetype\-editor\. For a developer, it is nice to have a generic reference model, it can help you create generic code in the application/kernel\. For a domain\-modeler \(a medical\-information\-specialist, f\.e\.\) it is nice to have semantics in the reference model\. It helps thinking about how to model an archetype for a specific purpose\. There is a way in between, which can serve both groups: You need to bring order in the chaos of generic CLUSTER\_archetypes\. You can do a lot with archetype\-slots with defined reg\-expressions, so in this way, the generic archetypebase canconsolidate in an information\-model which can be used by the domain\-modeler\. This information\-model needs to be defined, controlled and documented\. Then you reach the area of proprietary\. Domain\-modelers need besides adapting the reference model, conforming to your defined proprietary information model\. And, on second thought, anyway, you need to adapt a good message\-model, because not the whole world will run OpenEHR\. The nice thing about two level modeling is that, this is all possible\. good luck Bert --- ## Post #22 by @Hugh_Leslie1 Hi Bert, I assume you are talking about those types of semantics that are currently in the openEHR reference model like observation and instruction\. This argument has been around for a while\. My issue with this is that if you start to control some way of modelling generic archetypes for these types of semantic structures, then you are in exactly the same space as doing it in the reference model but without the same level of governance or control\. CIMI have also suggested this approach\. This is likely to be more difficult for developers as there is a much higher likelihood of multiple types of instructions/actions/observations that will need to be dealt with rather than one reference model based way of doing it\. I actually would contend that these structures are not domain specific, although they may have domain specific names\. We want the reference model to tell us how to construct compositions and entries as well as a consistent way of defining tables or tree structures so that software can be written once to handle all possibilities\. These openEHR constructs that seem to cause such controversy, just make explicit things that are going to be modelled over and over in the same way as these other things\. If we don't put these things in the reference model, then we will have to accept that there will be an increased variability in the way that they are modelled which is likely to make software more complex\. Its an argument/discussion that we will continue to have I suspect\. Regards Hugh \. \-\-\-\-\-Original Message\-\-\-\-\- --- ## Post #23 by @system Hi Hugh, It is indeed a discussion which runs for several years\. I mentioned 13606 but it can also be done in OpenEHR\. OpenEHR also has lists, trees, clusters, elements, all derived from Locatable, thus archetypeable\. So you can define \(what I call\) an information model, based on the generic structures in OpenEHR\. Say you want to conform to HISA, is that possible in the Composition\-package? I am not sure, I read it once, some years ago, and I saw some problems, say \(imagine\) HISA will conform more in direction of ContSys, how do you handle this in the OpenEHR composition\-package, and we all know, it will not stop there\. It is an illusion to think that an information model will last for ever\. Maybe there are concurring information models, maybe you want a kernel to support more, simultaneously, maybe you want to write an API to a specific information model? Imagine HL7, for example, VMR, based on archetypes? I once did that, for a customer\. I did not write an API for that, just the archetypes, but I could write an API for that\. I am afraid you will find the composition package restrictive\. It represents a good information\-model, as far as I can judge \(it is not my specialty\), but is just AN information model\. There can be more which are good too\. That is why I think, semantics do not belong in the reference model, but in a constructed archetype/template\-based information model\. You could also model the OpenEHR information model, which now resides in the reference model, in such constructed archetype/template\-based information model, using only structure\-based archetypes\. You say that information models will be defined over and over again\. This can happen, but it is, in my opinion, not likely to happen in professional environments where the choice will always be kind of standardized model\. You mention that software will be too complex when a reference model with no semantics is used\. I am softwaredeveloper, I think opposite\. I think a kernel should eat any archetype \(with valid ADL\) and should eat any dataset conforming to an archetype\. So, there is no problem\. There is no change needed in the kernel\. I think an API can be defined conforming to an information model, which is represented in a set of archetypes\. It can do its checks, that is not much of complexity\. I think a screen/report\-generator can be build on base of a trust\-able set of archetypes/templates, and screen\-parts can be used as lego\-blocks And then you find a customer which says: "Yes, we want to do CLEVER\-MEDINFO version 2, an information model and API defined in the University of CleverVille, most famous for medical information\." And three months further, it is ready\. As I say many times when talking about this subject: Let thousand flowers bloom\. And don't forget, OpenEHR is just AN information model, it is not THE information model\. So, you will need a decent message standard anyway for interoperability\. And for the future, we will not be able to stop it\. I think, this what I describe, is going to happen\. Restrictions or Semantics on kernel level will become obsolete for two reasons I can think of now: \- It is not necessary to do that on kernel\-level, because it can be done on archetype level\. \- It is fixed too much, it is very hard to conform to new standards, it does not stimulate innovation\. Best regards Bert Hugh Leslie schreef op 24\-6\-2014 23:22: --- ## Post #24 by @ian.mcnicoll Hi Bert, As ever these are interesting discussions and the 'no semantics' in the reference model approach has some attractions\. I happen to agree with Hugh that it seems that one way or other, there are a set of generic semantic constructs which need to be broadly and tightly adhered to, and controlled at 'reference level' and whether this is done by using reference archetypes or hard\-wired in to the ref\. model is somewhat arbitrary\. One of the advantages, for instance, of using a 'reference\-level' observation date is that vendors can optimise their systems, knowing that this will be universally available\. Whether this is an RM attribute or an element of a reference archetype does not much differ in terms of commitment to stability of that data point\. There is actually very good alignment between Contsys and the openEHR RM\. There are a few places where there is some degree of mismatch and where having a top\-level extension to e\.g COMPOSITION or INSTRUCTION would allow for Contsys\-specific attributes to be handled more easily, but I think this can be simply achieved by adding a top\-level CLUSTER slot to COMPOSITION and ENTRY classes\. That way we can bridge the gaps between different source information models without compromising the overall approach\. Having said all thta, I think the openEHR implementation and real\-world use has reached a level of practical use where these kind of discussions are moot\. It is going to be up to Industry and other real\-world users to tell us if they want the kind of root\-and\-branch' reform that you are advocating\. I think we all recognise that there are gaps in the current RM and things that we can do better but I am not hearing a major push from the implementer community for the kind of radical change in approach that you are advocating\. For most people, my impression is that the existing RM is working pretty well\. Certainly not perfect, but I am not sure that the use of reference archetypes necessarily solves these problem, it just moves them elsewhere\. I agree re messaging, but again I am not sure that this is a significant issue for implementers \(at least in your terms\)\. openEHR systems are talking to a variety of messaging formats\. If someone wanted to build a set of archetypes that mimiced CDISC or HISA or whatever, that could be done using the generic archetype but no\-one has taken that approach so far to my knowledge because openEHR is not trying to build CDISC or HISA EHR systems internally\. It is deliberately optimised for EHR use\. I am also concious that we have hi\-jacked Pablo's original discussion\. Perhaps we should split this into two threads but I will leave that for Pabl / Bert to resolve\! Ian --- ## Post #25 by @Heath_Frankel3 Hi All, Based on our experience working with goals and targets in our Care Planning system in Australia, the use of specialised Goals is not viable option from an implementation perspective\. The specialisation I am talking about is a little different to what has been discussed so far as we were using templates to constrain the generic goal archetype for a specific type of goal\. Therefore, it really relates to the alternative CLUSTER approach also\. This worked fine from a modelling perspective but when it came to implementing it in an app, it was a nightmare\. We had to have specific code to handle each type of goal \(template\) but we wanted a solution where we could easily add a new type of goal without needing to do any further coding\. This may be a result of the way we build our apps since after many years developing real clinical apps deployed in dozens of hospitals, we have chosen not to use a form generated approach as we do not believe this provides the end user with a great user experience or enable enough control over the application workflows\. Perhaps those of you that are smarter have been able to achieve this but I don't think the models should make any assumptions about how one should develop their Application\. What we ended up doing is implementing a generic approach to recording goals and targets that was metadata driven\. The metadata is maintained separately from the goal archetype and drives the way the application presents and captures data about each type of goal \(OK, perhaps we do have a little bit of form generation, but it is separate from the archetype and only were it makes sense\)\. You might say that this metadata should be in the archetype for all to use, but we come back to the usual argument that archetypes is just a model for what can be recorded about a concept, not the business rules specific to a particular use case, application, project or jurisdiction\. As someone suggested, I think this is where GDL starts to kick in and we should stop trying to overload the functionality of archetypes with all this business rule \(guideline\) semantics\. Regards Heath --- ## Post #26 by @heather.leslie Hi all, I'm just going to chip in here because we see a lot of discussion about drawbacks of the openEHR ENTRY types, but not a lot of endorsement\. After 8 years of modelling archetypes, I find that the ENTRY classes work really well, and this is subsequently borne out in implementation\. For example, the ACTIONs are an extremely elegant and practical class, although complex to implement\. The OBSERVATIONs I model, especially related to device capture, can be extremely complicated related to State, Protocol and Events\. It is not very often I find a requirement that cannot be managed within these structures\. They aren't perfect, but every time I have to model a complex archetype the power of the RM plus the ENTRY specific attributes makes the modelling a relative breeze\. I only need to worry about the clinical content itself\. Keep in mind, that I am speaking as a \*non\-technical clinician modeller\*\. And in openEHR, I will always argue that the most appropriate archetypes will be developed by the clinical community\. Models developed by technical modellers are structured quite differently, not necessarily representing the real clinical world and often trying to define abstract patterns that don't exist in the clinical space\. The barrier to entry for non\-technical modellers to a 13606 or CIMI RM is much greater\. We will see the outcome in the archetypes produced, believe me\. So anything that ensures that the RM is represented consistently and allowing consistent modelling approach for clearly identifiable clinical data patterns\. In reality I don't consider the ENTRY classes to carry semantics, and often the names are misleading \- perhaps they should have been named Model A, B, C etc\. My 2c Heather --- ## Post #27 by @ian.mcnicoll Hi Heath, That is very interesting\. Can you give an example of the kind of metadata you are storing externally? I don't see the problem per\-se with having term\-driven models but perhaps that is because a UK perspective is always a bit more comfortable with this approach, but I also understand how that also has a number of limitations once you move away from labellling the goal and any specific targets\. I modelled a few Goals/targets in the SemanticHealthNet Heart failure summary and using SNOMEDCT seemed to work reasonably well but I suspect your requirements were a bit more complex\. http://www.openehr.org/ckm/#showTemplate_1013.26.14 Ian Ian --- ## Post #28 by @Heath_Frankel3 I might need Adam to help with the specifics but from memory, since we implemented a problem oriented care plan, we had a set of goals that may be relevant for a specific problem, the targets relevant to a goal, the type of data representation of the target \(e\.g text, single value, range, less than/greater than\) and the kind of activities \(instructions\) that are relevant to achieving the goal target\. Can't remember if there is a reference to the observation value that would be used to evaluate the target variance\. As you can see this is more than clinical model semantics, but with this we are able to drive the app to capture this data and populate the generic goal archetype data\. Some of this could probably be represented using GDL, but I haven't explored this yet\. Regards Heath --- ## Post #29 by @system > Hi all, > > I'm just going to chip in here because we see a lot of discussion about drawbacks of the openEHR ENTRY types, but not a lot of endorsement\. After 8 years of modelling archetypes, I find that the ENTRY classes work really well, and this is subsequently borne out in implementation\. For example, the ACTIONs are an extremely elegant and practical class, although complex to implement\. The OBSERVATIONs I model, especially related to device capture, can be extremely complicated related to State, Protocol and Events\. It is not very often I find a requirement that cannot be managed within these structures\. > Hi Heather, If you read well I state more then one time that I think that the OpenEHR information model, this includes also the ENTRY\-model, is good\. The discussion is about if the definition of the information model should be in the reference model\. Of course, the reference model will always give a base, so there will always be some semantics in it, but the question is, how much semantics should be in there, and, even more important, which semantics\. It is not about your requirements, I think most medical information models can meet most of your requirements\. The point is that there are more information models, and you cannot use them when you use OpenEHR\. One reason for this is because of the semantic structures openEHR defines on the reference model\. Bert --- ## Post #30 by @system Hi Ian, As I come to think about it, it is a bit different, then I thought yesterday it was\. Because a Reference Model, HISA, or some HL7 document, or OpenEHR, they can be mimicked by a Reference Model without semantics\. But it is only the structure you mimic, and that works fine\. But is you also want to mimic the attribute\-names, then a generic Reference Model will not do\. There are two ways of solving this \- Leave the attribute\-names as they are in the generic Reference Model, and use the ontology\-text to define the attribute\-name from the information model to mimic\. In this case, one generic Reference Model, can mimic almost all possible Reference Model\. The problem is when querying, people writing the query will use the wrong attribute\-names and mapping needs to be done\. \- Have your kernel processing more Reference Models simultaneously\. A Reference Model mostly can be expressed in an XML Schema\. Check archetypes against these XML Schema's In this way, you do not only mimic the structure of a required Reference Model, but also the attribute\-names\. It is, of course, possible to query more Reference Models simultaneously\. Not one to cover the complete medical field, but one for every field\. Bert --- ## Post #31 by @thomas.beale well there are always 'semantics' in an information model, no matter how generic. It's just a question of how specific. The DvQuantity class has some very general semantics, which most people accept, and which can be mostly converted in and out of PQ and other 'competing' types. The Composition class is defined in 13606 and openEHR to do one job - act as a container for data captured during the same health event. It doesn't do all jobs. There is no reason we would not add other classes in the future to openEHR to handle other general categories of data, either at a similar level as Composition, or finer levels - just like we would add a new data type if we need it. well, you could get some way. Developers like the structures in Observation and Action and Instruction, because they can be programmed once in Java, Ruby, Python, C#, ... etc and they just work. No archetypes to worry about there, and yet they take care of a lot of quite complex data like differential time-series, multi-drug orders and so on. If you try to replicate all those details as reference archetypes, you'll get some of it done, but since you can't create generic (templated) types or use multiple inheritance (at this stage, at least) in ADL/AOM, there are going to be limitations. Solving that means upgrading ADL to have the power of a language like C++. I'm not sure if that's what we should be doing. Right now, displaying a time-series of heart rate v treadmill speed over 15 mins is dead simple in openEHR - the data structures are all there. Doing that in even 13606 requires: The one thing we did not do very successfully in openEHR is to preserve the generic form of ENTRY; this is what let's the 'thousand flowers bloom', but doesn't prevent proper reference structures being in the RM either. In the near future we will fix this. - thomas --- ## Post #32 by @system > The Composition class is defined in 13606 and openEHR to do one job - act as a container for data captured during the same health event. It doesn't do all jobs. There is no reason we would not add other classes in the future to openEHR to handle other general categories of data, either at a similar level as Composition, or finer levels - just like we would add a new data type if we need it. This is exactly the problem why I mention it. Because OpenEHR is in the RM, and not in archetypes, people using it, must wait for you or others to add a new class. It makes them dependent. At that moment, they experience an information-lock-in. There is another problem also, because OpenEHR as RM guarantees to remain backwards compatible, it cannot remove classes from the RM. This means there must be some provision to handle redundancy in data-definition which can occur when new classes are added. Redundancy means, more paths to store data of the same semantic meaning. The start of big trouble. I learned a lesson, a long time ago, and I see that this is still a valuable lesson.The lesson was: Never put semantics in the database design, put it in the data. (it is an often made mistake to ignore this lesson) I think more or less it can be applied to this discussion. You can in analogy regard the Reference Model as database-design and the archetypes as semantics to explain the data. The big trouble which can occur in redundancy in data-definition is because of having semantics in database-definition level. I am still not aware of a good reason to create a semantic rich RM, while there are enough possibilities to link the data to the semantics via archetypes. > > You could also model the OpenEHR information model, which now resides in the reference model, in such constructed archetype/template-based information model, using only structure-based archetypes. > > well, you could get some way. Developers like the structures in Observation and Action and Instruction, because they can be programmed once in Java, Ruby, Python, C#, ... etc and they just work. No archetypes to worry about there, and yet they take care of a lot of quite complex data like differential time-series, multi-drug orders and so on. Information must be the purpose of an EHR-definiton, not solving developer-issues. In my case, f.e., I don't even have classes representing a Reference Model. I don't need them. Archetypes are the thing I worry about. Data must conform the constraints in the RM and in the archetypes. For my kernel it is the same if a dataset represents an ItemTable, an Observation or a Person. They are treated the same way, - they are validated on XMLSchema ((RM-validation) f.e. an Observation cannot live on its own) - and on Schematron (archetype-validation) - and stored as XML, - and can be queried by AQL or XPath/XQuery. Maybe this was a problem in the year 2004, in that time we saw all developers mimicking the Reference Model in class-schema's of their favorite language. Me too, but not anymore. So you solved a problem that I do not have. Do other people have this problem? Are they relying on RM-classes to process datasets? > If you try to replicate all those details as reference archetypes, you'll get some of it done, but since you can't create generic (templated) types or use multiple inheritance (at this stage, at least) in ADL/AOM, there are going to be limitations. Solving that means upgrading ADL to have the power of a language like C++. I'm not sure if that's what we should be doing. I am not sure about this, I don't see the multiple inheritance. As I see it on a quick glance (just an idea), there must be base-archetypes, a base archetype would represent the base class structures, as you can find them now in the RM. I think a new attribute would be needed to the CComplexObject-items. It would be the attribute rmtype. Like this ITEM_LIST[archetype_node_id=at0001, rmtype="COMPOSITION"] matches ....... etc etc This is no problem in using attributes because they are easy to query. The kernel now also relies on the attribute archetype_node_id=at0001, without any problem. > Right now, displaying a time-series of heart rate v treadmill speed over 15 mins is dead simple in openEHR - the data structures are all there. Doing that in even 13606 requires: > > - defining reference archetypes for time-series data, where the events can have secondary state i.e. each event has a primary datum like heart rate, and 'state' data like exertion (treadmill speed) > - writing software that knows how to transpose the Cluster/Element structures into a logical time-series, and figure out what is the main datum, what is the state, what are the widths of every event and so on > - remember, there won't be any Java / Ruby / Python /.. classes to do this - you have to do it all manually. I don't understand why you bring up this subject. I stated a few times that OpenEHR is a fine information model, and maybe there are some difficulties in EN13606, that may be true. I also wrote that designing medical information models is not my specialty. So I will not easy say about an medical information model if it is good or bad. I can only judge it on basic-design-rules. The point is that you don't have to choose if you use generic kernel. You can use multiple in archetypes-based reference models to validate and store and query data. You can allow certain parts of an healthcare organization, without any technical provision, to implement new ideas about medical data structures, maybe necessary for specific treatment. As I see the battle-field of medical information model-designers, the war is not over yet, and it will never be. There will be great ideas which need an own Reference Model. Being prepared for that is a good thing. Best regards Bert --- ## Post #33 by @thomas.beale anyone can make a local change, test it, and propose the change to the RM. And anyone can make 'reference archetypes' as you proposed earlier. It's encouraged. I think it all depends on what the new classes are. We aren't likely to add many, and they are all generic, i.e. semantically invariant classes. There are no domain specifics in the RM, only general concepts like the classes you see today. New classes would need to be at the same level of generality. that's the foundational basis of openEHR ;-) there isn't a semantic-rich RM, there is an RM that has only semantics that are general across health, and I would argue much of observational science. As you know, there are no lab results, prescriptions, ECGs or any of the 1000s of other clinical things in the RM - those things are all archetypes. What is there are semantics that appear to be invariant across the domain - 'Observation' and so on. Time seems to have proved this a reasonable choice. well - that depends on what the developer issues are. If a badly designed or too-simple RM causes developers to write software that generates non-interoperable data, then it's a serious data problem. well I guess that means you are using a different category of architecture. But if you are using any archetype specialisations, then you are actually using more or less the same architecture, just one level up. How do you want to solve the problem of having a standard representation of orders, or time-series data, across all countries, so that re-usable software can be written? You can only do that with wide agreement on those semantics, wherever they are specified - in an RM, or in some layer of archetypes. this is certainly possible, but just making easy things needlessly hard in my view. You can do all this, or you can just use the reference model and get it all for free. that's also easy to do with reference models. There are many reference models , to plug into a kernel. sure, but like I said, this is just the same problem moved up one level. At some point, you still have to write classes with the semantics of things like Observation or Composition or whatever. Otherwise you can't get the data on the screen, or compute with it in any meaningful way. - thomas --- ## Post #34 by @thomas.beale What is to stop you using them? I have 5 reference models loaded into the ADL Workbench right now\. Building a kernel to use them wouldn't be hard\. \- thomas --- ## Post #35 by @Hugh_Leslie1 Hi Bert All good points and I think it comes down to what your focus is\. I think you are focussed on one information model that could be used to represent any of the other current information models out there including openEHR\. We are focussed on interoperability of information in the health space and making that as easy and reliable as possible for every situation\. I think it's easy to see that depending on where your focus is, there is going to be a different requirement for the reference model\. Regards Hugh --- ## Post #36 by @system Hi al, Many roads lead to Rome. At the extremes I can envisage: - A Reference Model that makes many recurring patterns part of the RM. Observation, Evaluation, Instruction and Action are examples. And leaving a few details to the archetypes. *(Remember the first (1998) HL7v3 RIM’s where on several square meters of paper one needed magnifying glasses to inspect relationships.)* - A highly abstract Reference Model and leaving all details to archetypes and codes. Why not in the extreme a Terminology that is capable to provide one code that represents the full works of Shakespeare. *(Remember the first EHR standard that CEN/tc251 produced in the 1996)* When communities create any consensus it will work fine. Work fine for that community. Or we come to a solution based on a pragmatic, logical, grounds: **Orthogonal layers** and models in the semantic stack (RM, AOM, Archetypes/Templates, Codes, Ontologies) This means that the scope of the layers are: - the RM: any Document structure, documenting/archiving these components (generic) - the OAM: production of constraints on the RM, meta-data about the archetype/template, exchange format (generic) - Archetypes/Templates: the Semantics - all facilities to safely interpret data (clinical and non-clinical semantics) - Coding system: provide codes and meaning like any dictionary (clinical and non-clinical) - Ontology: expression of Knowledge helping to define all codes/meanings (words) in the dictionary/coding system (clinical and non-clinical) Each layer its own function. No overlap of features between the RM and the Archetypes/Templates No overlap of features between Structures (archetypes/templates) and SNOMED with its pre- and post co-ordination. The 'boundary problem’. Overlaps always create problems. All layers intersect, but will not overlap. They intersect at the Archetype/Template layer. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #37 by @system > > The point is that you don't have to choose if you use generic kernel. > > that's also easy to do with reference models. There are many reference models [right here](https://github.com/openEHR/reference-models/tree/master/models), to plug into a kernel. Ah, I did not know about this. I am very pleased to see it. It fits in the kernel-design philosophy I favor. Thanks for the good work. I found, that there are still some basic rules to which a Reference Model must apply. One of the basic structural ideas of the kernel is that it must be patient/EHR (say Subject)) centric. Honouring this basic idea avoids having to write Reference Model-specific base structure code. > > You can use multiple in archetypes-based reference models to validate and store and query data. You can allow certain parts of an healthcare organization, without any technical provision, to implement new ideas about medical data structures, maybe necessary for specific treatment. > > sure, but like I said, this is just the same problem moved up one level. At some point, you still have to write classes with the semantics of things like Observation or Composition or whatever. Otherwise you can't get the data on the screen, or compute with it in any meaningful way. I think this can be solved with templates and information which can be in the archetype-meta-data. Don't you agree? What am I missing? Bert --- ## Post #38 by @system > What is to stop you using them? I have 5 reference models loaded into the ADL Workbench right now\. Building a kernel to use them wouldn't be hard\. This is about what I advocate, multiple, interchangeable, simultaneously usable Reference Models\. I realized it by having multiple XMLSchema's in the kernel\. Archetypes can be checked against them\. After this discussion, I think, now, it is the best way to go\. Thanks for your comments\. Bert --- ## Post #39 by @system I agree Hugh, thanks for your comments\. My answer to Thomas, this morning, can as well be applied to your message\. Bert --- ## Post #40 by @thomas.beale example: is inside an openEHR OBSERVATION, and most implementations use full Java/C#/other implementations of these classes. That enables you to do things like handle openEHR OBSERVATION data representing time series from a device natively, including varying periodicity, varying sample widths, and varying math functions (max, min, ave etc). This makes it very easy for an implementer to get time-based data from an EHR and populate a screen graph widget. Without any of this built in, e.g. as in 13606, CDA, or other models, you have no guarantee that this kind of data (very common you will appreciate) is even represented in a standard way, nor do you have any classes to process it with. You have to assume that each CDA or 13606 data source has its own representation of such data, and build N implementations to deal with it. For openEHR implementers, openEHR is the target data, so we convert data into openEHR, which is a higher-fidelity format, and the problems go away. You could potentially convert them into a sort of standardised 13606, representing the same thing but then you'd still have to build your own classes to implement time-based data rather than re-use the standard classes everyone else uses. I don't see the point. Especially as openEHR has AQL. Now, there are things that are not actually in openEHR, that you might want. So you can take the 'reference archetype' approach to that, and build local classes. But you might as well still use openEHR as 13606 or CDA as the basis, since you will get more for free - if you make your local native format something completely custom, then there is no community or software you can use - you have to build everything yourself. - thomas --- ## Post #41 by @yampeku Well, I would say that deciding what's in and what's out of the reference model can be tricky sometimes\. If we assume that clinical knowledge evolves \(one of the basis of dual model approach\) isn't safe to say that the less clinical knowledge we put in the reference model the better? You can always define reusable patterns to be applied over the archetypes, but these patterns itself can be evolved \(just in case you feel that some day event series could be represented in any other way, for example\)\. At the end, an Observation is an specialization of Entry class with some structures already available for you to use\. --- ## Post #42 by @thomas.beale the problem with this dictum is that it doesn't work as an Occam's razor, which is what you need - i.e. objective criteria for making the decision. The criterion I developed in 2000 or so, to determine what should be in an RM underpinning archetypes was: --- ## Post #43 by @system Sorry to respond so late, it was my birthday, yesterday. I leave that to the client-developers. If they want classes to create graphs, that is fine for me. The kernel I focus on does not much more but validating, data-storage and data-retrieval, and it offers some templates for specific GUI-purposes. And for that purpose I don't need classes which represent the RM. And what they do on the client side, I doubt if they ever create RM-classes, they have RAD-like ways of software developing and often they mix GUI-interface-code with functional code. We have agreed two different interface formats for posting and retrieving data, and that is how far my concern goes. thanks, Bert --- ## Post #44 by @system > Well, I would say that deciding what's in and what's out of the > reference model can be tricky sometimes\. If we assume that clinical > knowledge evolves \(one of the basis of dual model approach\) isn't safe > to say that the less clinical knowledge we put in the reference model > the better? Hi Diego, I tend to agree on this\. Because if you want a stable data\-definition, you must be prepared for changes in thinking\. There will, however, always be some basic structures left\. A medical information model must be patient/EHR centric\. All data must belong to a patient\. This is typical for an information system for storing medical data\. 13606 was not such a system\. 13606 is, in my opinion, in fact Composition\-centric \(and a not archetypeable demographic section, I don't understand the purpose of that\)\. 13606 was a message format, and demographic data \(if medical relevant to a specific Composition\) should be an entry of a Composition\. The patient, a number in the EHR\-Extract was just a carrier of related medical circumstances\. An EHR\-message was, per definition limited in scope\. The scope was a medical circumstance that was wished to communicate, together with the patientID in which this circumstance lived\. I believe, I have heard, this is going to change\. 13606 will become an information system for storing medical data with a minimalistic structure\. Since quite some time, I implemented a multiple RM\-kernel\. Now I see, it is also because it can be used to serve several different medical information structure philosophies, as long as they are Patient Centric\. 13606 will have a more important role because of its minimalistic structure\. Organizations which want to implement information\-standards now have tooling and a minimalistic Reference Model to do so\. For some ideas, 13606 will not fit, and a new Reference Model will need to be written\. I think that the Reference Model will loose some of its status\. Was it before the foundation of a software\-structure, with a lot of classes to support, it now becomes more and more just an interchangeable information definition\. Now the LinkEHR editor change to RM\-pluggable editor, and we have a complete new medical information use\. The customer, not depending on the vendor, can create or choose an information model\. We'll see if this is true, and if, where it ends\. Bert --- **Canonical:** https://discourse.openehr.org/t/link-between-goals-and-other-clinical-concepts/15050 **Original content:** https://discourse.openehr.org/t/link-between-goals-and-other-clinical-concepts/15050