# Yet another OBSERVATION vs. EVALUATION issue **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2012-08-14 04:28 UTC **Views:** 4 **Replies:** 61 **URL:** https://discourse.openehr.org/t/yet-another-observation-vs-evaluation-issue/14579 --- ## Post #1 by @Koray_Atalag Hi, There's a CVD risk assessment tool I’m working on which prepopulates clinical info from GP software. This includes diagnoses, smoking status and checklist for certain medications. Note that some of the underlying info might be coming from previous visits (e.g. problem list type) but also can be newly entered as a result of GP’s assessment. Now, regardless of what happens in GP software, when it is transferred onto this tool (whether automatically prepopulating and/or manual entry) are these Observations or Evaluations? Note that the GP does not make any further clinical judgement here, just rephrase existing data for a different purpose. My gut feeling is the former (Observation). I know this is tricky and has been brought to this list many times here but thoughts? Masters? Cheers, -koray --- ## Post #2 by @PPOUDEL Good afternoon, I use MedTech32 almost everyday\. The recent CVD risk assessment is incorporated with diabetes risk assessment but not 3 month diabetic check\-up one\. CVD risk assessment actually adjust risk and recall patient for 3 monthly, 6 monthly, annual or every 5 yrs, best on the data that we input in this new form \(observation data\)\. Few old things are automatically populates \(such as previous BP the most recent one and medication information\)\. The other blood test factors \(HDL, LDL, total cholesterol and more are new results and we enter at the time of patient assessment\. It again adjust risk for recall\. There are wizard to enter data automatically, while referral patient to other provider\. We can do more modification it looks though\. Regards, Pratima --- ## Post #3 by @system In our book any risk assessment is an Evaluation. Because it is a statement about an inference about characteristics of a possible ongoing process inside the patient system. And not a state in a process that can be observed via our senses at a point in time. E.g. The measured/observed systolic blood pressure is a state of a cardio-vascular process inside the patient system. The measurement of the systolic blood pressure is an Action type archetype. Both the blood pressure Action and Observation are linked and each have a state model attached to it. An inference about a process inside the patient system is modelled using the Evaluation pattern. We can not observe a process in principle, only states at a point in time when we perceive observables and record the observation. Evaluation is about inferences about characteristics in general of the process and risk is one of the characteristics we can attach to that process and make inferences about. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #4 by @system Hi Koray, I think it would be a composition with observation and evaluation archetypes\. In my experience on surveillance program, your form could be built up these items\. \* OBSERVATION History of medication, smoking \* EVALUATION Diagnosis, GP assessment status \(INSTRUCTION/ACTION\) Medication\(GP prescribed/prescribing\) However, I am not sure which should be\. Shinji --- ## Post #5 by @system Yep, Gerard is right, even though done with an aid of a tool, in this case a risk assessment one, there's definitely an evaluation. Enviado via iPad --- ## Post #6 by @thomas.beale My favourite question.... the two criteria you can always use to decide are: --- ## Post #7 by @system The risk itself is an Evaluation and can be used to store data about the risk\. The procedure/method to do the calculation is not an artefact that will be stored, but referred to in the Evaluation\. Using a RM and an AOM it must be possible to specify in a Composition type of artefact the components \(queries\) and the procedure/method/algorithm/calculation, etc\. Provided we have a standardised way to express the needed logical operations, calculations, etc\. Gerard Freriks \+31 620347088 gfrer@luna\.nl --- ## Post #8 by @Stefan_Sauermann Just out of the Risk analysis box see eg\. ISO 14971: Took me some time to figure it out, so I share it just in case: Risk consists of: \- A hazard \- a probability that this hazard will typically occur \- the severity of the harm that this hazard will cause on humans or non\-human subjects \- probability together with severity will describe the risk some parts of this may well be observations, others will be evaluations Greetings from Vienna, Stefan Sauermann Program Director Biomedical Engineering Sciences \(Master\) University of Applied Sciences Technikum Wien Hoechstaedtplatz 5, 1200 Vienna, Austria P: \+43 1 333 40 77 \- 988 M: \+43 664 6192555 E: stefan\.sauermann@technikum\-wien\.at I: www\.technikum\-wien\.at/mbe I: www\.technikum\-wien\.at/ibmt I: www\.healthy\-interoperability\.at --- ## Post #9 by @system > Risk consists of: > - A hazard > - a probability that this hazard will typically occur > - the severity of the harm that this hazard will cause on humans or non-human subjects > - probability together with severity will describe the risk Should we add the temporal factor? E.g. the chances in a defined period of time. When you mean that the constituting elements of a RISK are Observations and Evaluations, you are right.The RISK itself is documented by these components. E.g. RISK= High Risk of Something to occur in a certain time period. The composite is an Evaluation. The result expressed in the Evaluation is a semi-quantitative result consisting of the constituting Observations and Evaluations. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #10 by @Stefan_Sauermann HIGH RISK= High probability of Something to occur in a certain time period and causing a severe harm to persons or other subjects LOW RISK = something will never occur and even if it does it will not harm anyone or anything Greetings, Stefan Sauermann Program Director Biomedical Engineering Sciences \(Master\) University of Applied Sciences Technikum Wien Hoechstaedtplatz 5, 1200 Vienna, Austria P: \+43 1 333 40 77 \- 988 M: \+43 664 6192555 E: stefan\.sauermann@technikum\-wien\.at I: www\.technikum\-wien\.at/mbe I: www\.technikum\-wien\.at/ibmt I: www\.healthy\-interoperability\.at --- ## Post #11 by @thomas.beale Hi Stefan, whenever you assess someone as having a risk, you are doing something similar to diagnosing: i.e. you are comparing some input data items about the patient (high BPs over last 3 months, smoker, 55years old etc) to some knowledge base that says that these things taken together constitute a risk for hypertension, due to some population studies. Any probability etc is derived from that knowledge base. So these are all evaluations. - thomas --- ## Post #12 by @heather.leslie Hi Koray, Some of the latest versions of existing archetypes might suit your purpose – the most recent are currently on the NEHTA CKM and we are looking to transport them across to the openEHR CKM. More details below… --- ## Post #13 by @system RISK is a complex thing\. Read: http://en.wikipedia.org/wiki/Risk#ISO31000:2009_Risk_Management_Standard Only looking at temporal aspects: The risk to die within 10 years when you are 100 years old is HIGH The risk to die within 10 years when you are 30 years old is LOW The risk to die within 100 years for each average person is HIGH The risk to die within one day for the average person is LOW The risk to have prostate cancer until 40 years of age LOW The risk to have prostate cancer after 70 years is HIGH Adding severity: The risk to die of prostate cancer after 70 years is LOW \(Most man have prostate cancer at this age but most never die because of it\) How is RISK used in healthcare? Almost never it is calculated with mathematical precision\. It is expressed in a semi\-quantitative way: Low, Normal, High, etc\. It would be nice when archetypes can express that in a sensible way\. It will be impossible to use the DV\-Data Type for this\. Reason? It is not expressive enough because the semi\-quantitative result needs to document more\. It needs inclusion and exclusion criteria because there is no generic definition of Low, Normal, High\. Each context is unique and opinions change over time\. Each and everybody has to define the criteria in the local context\. \(Speciality, organisation, disease/condition, healthcare provider even patient specific at one point in time\) Gerard Freriks \+31 620347088 gfrer@luna\.nl --- ## Post #14 by @system Hi Gerald, Completely agree with controversy in RISK evaluation\. I have similar experience on SEVERITY evaluation\. openEHR\-EHR\-problem\-diagnosis archetype has severity metrics, but it does not fit for various evaluation criteria\. I specialized to have a 'severity detail' slot to apply various severity criteria for many diseases\. As Risk evaluation depends on cases, we need to develop cluster to express such risk evaluation models on demand\. Regards, Shinji --- ## Post #15 by @Koray_Atalag Hi Heather, all others – many thanks for your responses. I agree that risk is an evaluation – no question with that. However I reckon I couldn’t explain the issue I had clearly: My question was when documenting a patient’s health information at a point in time base on past diagnoses, medications and smoking status not necessarily assessed by the same physician, should these be observations or evaluation? I’m not really asking about risk assessment – in that case the physician (or decision support tool) is considering past observations etc. against a knowledgebase and making a clinical judgement. That should clearly be an evaluation To give an example: a medical student is reading problem list, medication list and smoking status from patient’s EHR and putting on a form to present to a physician – is the stuff on that form Observation of Evaluation? Heather I take your point that in order to reuse data it is best to stay faithful to original models... So that makes me think whether we find a smarter way of dealing with Observation vs. Evaluation types. Kind of multiple inheritance where, depending on a particular usage, they can inherit contextual parts of either Observation or Evaluation. I can see this will save a lot of hassle and still enable us to reason using the ontological Clinical_Entry classes. Probably same is true for Instruction/Action types as well.... Anyway this is probably even a bigger discussion! --- ## Post #16 by @system Dear Koray, In EN13606 Association we think that all artefacts must be derived from (specialised) from one generic pattern. The draft document SIAMS defines this, plus more. All artefacts inherit this generic pattern. It is just one change of one attribute in the pattern that changes it from constraints on the generic ENTRY class used as Observation to one that is an Action or Instruction or Evaluation. And all use the same generic pattern, but depending on different requirements they use other combinations of possibilities in the pattern. What they have in common, will not change. An other attribute defines the usage of the artefact for either documentation, querying, presentation. Read more: [http://www.en13606.org/wiki/index.php?title=Detailed_Clinical_Models_and_Archetype_Modeling_-_PDF](http://www.en13606.org/wiki/index.php?title=Detailed_Clinical_Models_and_Archetype_Modeling_-_PDF) Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #17 by @Stef_Verlinden1 Hi Shinji, This brings back flashbacks to the 'data quality' discussion we had on this list about 5 years ago\. The conclusion then was that we first had to learn to walk before we could run\. Hopefully today we're learning to run\.\.\.\. \(can't wait untill we're learning to fly:\-\) \)\. Personallly i still think that any RISK or SEVERITY evaluation if completely worthless unless that evaluation AT contains a detailed protocol describing the criteria \(preferably based on evidence based literature\) on which that evalution is made\. To come back to Gerard remarks, that also would mean that it decribes that the outcome high means that the risk for the event x in that particular situation is greater that y%\. Just my 2 cents\. Cheers, Stef --- ## Post #18 by @Karsten_Hilbert > Personallly i still think that any RISK or SEVERITY > evaluation is completely worthless You may want to define "worth" to put this into context\. > unless that evaluation AT > contains a detailed protocol describing the criteria > \(preferably based on evidence based literature\) on which > that evalution is made\. To come back to Gerard remarks, that > also would mean that it decribes that the outcome high means > that the risk for the event x in that particular situation > is greater that y%\. Statistician's wet dreams, not clinical reality\. It typically doesn't apply to a specific patient just so\. Karsten --- ## Post #19 by @heather.leslie One comment… --- ## Post #20 by @system Shinji, In the EN13606 Association in our SIAMS document we developed a generic semantic patterns that drives all artefacts, One of the sub-patterns is to document a semi-quantitative result. This semi-quantitative result is to document all 'severity' type of things. Always these semi-quantitative things (Severities) are defined in a specific context. So each semi-quantitative semantic sub-pattern allows one to include inclusion and exclusion criteria for each entry in the semantic ordinal sub-pattern. See: *[http://www.en13606.org/wiki/index.php?title=File:Artefact_SubPattern-Semantic_Ordinal_v1.png](http://www.en13606.org/wiki/index.php?title=File:Artefact_SubPattern-Semantic_Ordinal_v1.png)* And yes, these sub-patterns always are Cluster Models. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #21 by @Stefan_Sauermann Ad "quantification" of Risk: EN ISO 14971 / 15\.12\.2009 \(Application fo risk management to medical devices\) has an informative annex \(D\) "Risk concepts \.\.\. " this suggests two basic levels of risk: \- not acceptable \(immediate show stopper, flare red lights, everybody freeze, \.\.\. \) \- acceptable \(this is OK, something will happen but seldom and harmless enough for us to bear\) Additionally there may be a additional category: "we need to investigate further risk reduction" In this appendix D we also find concepts for describing hazards, harm and probability of occurrence\. The ongoing discussion circles around basics\. It may help to use the existing concepts and definitions\. Hope this helps, greetings from Vienna, Stefan Stefan Sauermann Program Director Biomedical Engineering Sciences \(Master\) University of Applied Sciences Technikum Wien Hoechstaedtplatz 5, 1200 Vienna, Austria P: \+43 1 333 40 77 \- 988 M: \+43 664 6192555 E: stefan\.sauermann@technikum\-wien\.at I: www\.technikum\-wien\.at/mbe I: www\.technikum\-wien\.at/ibmt I: www\.healthy\-interoperability\.at --- ## Post #22 by @Stefan_Sauermann This is deeply philosophic, but if you want it you get it: ;\) The fact that a smoker within a given population develops cancer is an observation\. The fact that n smokers within a given population develop cancer is an observation\. So: some elements used for risk evaluation are observations\. I would agree that "Risk" as a whole is an evaluation\. Decisions of medical users do not depend on the fact that an item is classified as "observation" or "evaluation"\. Users need to know how the content they see on the screen was generated\. Systems need to be able to tell the story of every item of information they show on screens\. A single "label" on an element within an archetype does not provide this story\. There need to be additional measures\. I guess it makes sense to focus on these\. Hope this helps, greetings from Vienna, Stefan Stefan Sauermann Program Director Biomedical Engineering Sciences \(Master\) University of Applied Sciences Technikum Wien Hoechstaedtplatz 5, 1200 Vienna, Austria P: \+43 1 333 40 77 \- 988 M: \+43 664 6192555 E: stefan\.sauermann@technikum\-wien\.at I: www\.technikum\-wien\.at/mbe I: www\.technikum\-wien\.at/ibmt I: www\.healthy\-interoperability\.at --- ## Post #23 by @system I think we agree. Read below. Gerard > This is deeply philosophic, but if you want it you get it: > ;) :-) > The fact that a smoker within a given population develops cancer is an observation. But not in the context of the documentation of the care provided. Based on these facts that are read the Healthcare provider gets knowledge that he uses to interpret the risks for the patient he is caring for, He makes a statement about the risks for that patient based on his information inside his head. Optionally he might refer to this knowledge via semantic links indicating why he is of that opinion. > The fact that n smokers within a given population develop cancer is an observation. > So: some elements used for risk evaluation are observations. > I would agree that "Risk" as a whole is an evaluation. That is correct because it is an inference about the patient system based on facts. > Decisions of medical users do not depend on the fact that an item is classified as "observation" or "evaluation". Correct. Any thing that might be of relevenace is OK > Users need to know how the content they see on the screen was generated. That is why via semantic links ('because of ...') he is able to document his reasons. > Systems need to be able to tell the story of every item of information they show on screens. A single "label" on an element within an archetype does not provide this story. There need to be additional measures. I guess it makes sense to focus on these. The patient story is the collection of facts/events that were documented with all the semantic links. Like in ontologies it is 'the graph' that tells the story. --- ## Post #24 by @thomas.beale Hi Stefan, > This is deeply philosophic, but if you want it you get it: > ;\) > > The fact that a smoker within a given population develops cancer is an observation\. > The fact that n smokers within a given population develop cancer is an observation\. > So: some elements used for risk evaluation are observations\. > I would agree that "Risk" as a whole is an evaluation\. agree with all that \- in general all assessments are based on some evidence base \(the facts\) and some knowledge base \(maybe expressed as a diagnostic protocol\)\. > Decisions of medical users do not depend on the fact that an item is classified as "observation" or "evaluation"\. maybe not so much on how it is classified, but on whether it can be trusted or not\. Erroneous conclusions can be drawn from evidence by mis\-diagnosis, and diagnoses often have to be revisited in difficult cases\. Observations might sometimes be declared faulty, but it is much less often the case, and the kinds of errors are generally less problematic than errors of diagnosis\. > Users need to know how the content they see on the screen was generated\. > > Systems need to be able to tell the story of every item of information they show on screens\. A single "label" on an element within an archetype does not provide this story\. There need to be additional measures\. I guess it makes sense to focus on these\. well there is of course much more structure, labels, terminology connections to tell us the meaning of everything\. \- thomas --- ## Post #25 by @system 20 something years of medical practice learned me to be humble and do not use the word Diagnosis too lightly: - facts (e.g. measured things like lab results,or interventions/operations, etc.) are trusted much better than opinions/evaluations/inferences - inferences are highly personal and context dependent. (e.g. there are opinions be peers that one generally can trust more than others. Some are never trusted. Even in the case of peers that are trusted, each time the healthcare provider must be able to create his own opinion and make his own judgement. Personally I distrust all Diagnosis statements in the record. Even my own statements. Diagnosis is always an inference about a (disease) process inside the patient system. These processes we can no see; the only thing we can perceive are the results of that process. It is much more realistic to record in the EHR **Reasons for** Diagnostics and Reasons for Treatment than fuzzy things such as 'Diagnosis'. The draft EN13606 Association **SIAMS** document (Chapter 6) is about topics like these. Before we can start to standardise how archetypes are produced we will have to agree on a number of notions/concepts. Example: I know that within one day I suspected the patient to have shortness of breath because of: asthma, pulmonary infection, cardiac failure and panic attacks/hyper ventilation. These were my inferences about the process inside the patient system. Only one was true and had to found out via trial and error diagnostics and trial treatments. I fear that the best we can do in most circumstances (as GP) is to code 'Reasons for ..' and do not use the word diagnosis too often. A fact to think about was an scientific article where 'Diagnosis' made in an academic hospital setting were compared with the autopsy findings. In 25% of all cases the diagnosis was missed completely. The inferences and resulting treatments were wrong and sometimes dangerous. I have known too many patients that were in that category. By the way: The '**Reason for ..**' artefacts are EVALUATIONS that will result in the start of a Procedure or Clinical pathway via an INSTRUCTION.) [http://www.en13606.org](http://www.en13606.org) [http://www.en13606.org/wiki/images/1/1c/ERS_SIAMS_%28most_recent_version%29.pdf](http://www.en13606.org/wiki/images/1/1c/ERS_SIAMS_%28most_recent_version%29.pdf) Gerard --- ## Post #26 by @system Hi Stefan The scope of openEHR is the health record\. With that in mind things are a little simpler\.\.\.\. > This is deeply philosophic, but if you want it you get it: > ;\) > > The fact that a smoker within a given population develops cancer is an observation\. This may appear in a person's health record but not in this form \- rather the smoking record and the diagnosis > The fact that n smokers within a given population develop cancer is an observation\. This will not form part of a person's health record but it is knowledge that is useful in risk assessment > So: some elements used for risk evaluation are observations\. I dont think this is true within a health record \- it is always a risk to start to feel that you are modelling health and healthcare\. Cheers, Sam --- ## Post #27 by @Karsten_Hilbert > 20 something years of medical practice learned me to be humble and do not > use the word Diagnosis too lightly: \.\.\. > Example: I know that within one day I suspected the patient to have > shortness of breath because of: asthma, pulmonary infection, cardiac failure and > panic attacks/hyper ventilation\. These were my inferences about the process > inside the patient system\. > Only one was true and had to found out via trial and error diagnostics and > trial treatments\. I fear that the best we can do in most circumstances \(as > GP\) is to code 'Reasons for \.\.' and do not use the word diagnosis too > often\. That's why in GNUmed there isn't even a field labelled "Diagnosis"\. We offer that field under "Assessment" \(as from SOAP\) and "Episode" \(under which SOAP notes are stored\)\. Regarding Episodes \(and Health issues\) clinical certainties thereof can be recorded: \- sign \- cluster of signs \- syndromic diagnosis \- scientifically proven diagnosis Karsten --- ## Post #28 by @system Good. lets ditch the term 'Diagnosis' completely. Or use it only when we are -as you write- scientifically certain. And use other terms. We (EN13606 Association) prefer the 'Reasons for ...' type of terms, because that is what they do in real life. They are the excuses to do something (or nothing); they are the cost drivers in healthcare; they must be documented. Words like 'symptom', 'sign', 'syndrome', 'diagnosis', are fuzzy terms that can mean too many things. We need well defined terms in our systems and standards as points of reference we agree on. Locally all users must be allowed to use their own fuzzy terms as long as they are mapped to (and used in accordance with) the reference terms. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #29 by @Karsten_Hilbert > lets ditch the term 'Diagnosis' completely\. > Or use it only when we are \-as you write\- scientifically certain\. > And use other terms\. We \(EN13606 Association\) prefer the 'Reasons for \.\.\.' > type of terms, because that is what they do in real life\. > They are the excuses to do something \(or nothing\); they are the cost > drivers in healthcare; they must be documented\. > > Words like 'symptom', 'sign', 'syndrome', 'diagnosis', are fuzzy terms > that can mean too many things\. They do have intuitive clinical meanings though: symptom/sign: a \*single\* "thing" related to a patient's health deemed clinically relevant by the provider cluster of symptoms/signs: a group of probably related symptoms/signs happening at the same time, suggestive to the provider to be of common origin syndromic diagnosis: cluster\(s\) of signs/symptoms which incur sufficient confidence in the provider to "call this" a certain affliction \- IOW a clinical diagnosis, differential diagnosis, considered diagnosis Those definitions work quite well in GP land\. Karsten --- ## Post #30 by @system Yet we use this term a lot, as a hypothese or as a differential diagnosis, or even as a past diagnose, not forget to billing purposes and DRG calculus. Don't know how you could avoid it here in Brazil, where ICD 10 is used to code everything, actually it is the only classification used in large scale in Brazil, where even CIAP isn't used by the primary care doctors. All analytics of health status and conditions as well decisions support tools in Brazil use ICD as the clinical vocabulary, and you know what happens if you retrieve those codes without having the context. I used to work with record linkage and know how inaccurate can it be to do a query using ICD and was for that reason that we began to seek for modeling information, because it's essential to give context wherever the ICD is used. The ontologic based openEHR RM was found by experts here the model that is closer to our need. I think not only us, as international experts gathered at CIMI just came to the same opinion. Talking on the difference of evaluation and observation, I thought we're talking on modeling not on the value of using any concept or entry. If most clinicians don't trust diagnosis or inferences, they do it everyday, because it's our jobs to make inferences! There are them which lead to the instructions we give. Regards Jussara Rotzsch Enviado via iPad --- ## Post #31 by @system It must be clear that one is able to define these terms. But others do the same and do it differently. Examples: *Symptom*: *1- an observable as percieved and communicated by a patient* *2- an observable fact about the patient (system)* *3- an observable fact about the patient system deemed relevant by a healthcare provider* *4- the prototypical phenomenon that can be observed and belongs to a set of possible phenomena caused by a particular disease* These are paraphrased definitions hat I remember. So what to do? All 4 are defined but not the same. This is why CEN/ISO Concepts for Continuity of Care defines many of the terms we need in healthcare. [http://www.datadictionary.nhs.uk/contsys/](http://www.datadictionary.nhs.uk/contsys/) They use a co-ordinated, modeled, set of terms we can use as reference point when we all use our own definitions locally. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #32 by @system Diagnosis is a fuzzy term. It is used and mis-used and creates a lot of confusions. A 'diagnosis' many time does not describe a disease process inside the patient system, but is a way to collect or spend money or to explain a next round of diagnostics or treatments. All terms like these need to be formally defined: [http://www.datadictionary.nhs.uk/contsys/](http://www.datadictionary.nhs.uk/contsys/) Gerard Freriks +31 620347088 gfrer@luna.nl --- ## Post #33 by @thomas.beale We can't just ditch the word 'diagnosis' \- it's not up to any standards community to do that\. The diagnosis concept, which I agree can be weak/ambiguous in general practice, certainly isn't in the acute sector\. I don't have a problem with philosophical arguments that question the meaning of the 'diagnosis' concept, but it's not our job in a place like openEHR to dictate a new philosophy of medicine to the sector\. We need instead to reflect the needs of what actually goes on\. If 'diagnosis' is clearly used in acute care, but only weakly in general practice, we need to reflect that\. This is one of the reasons for having a 'problem' archetype and a 'diagnosis' archetype, as has been done in openEHR\. It becomes an optional extra to actually call the assessment a 'diagnosis', to code it, and to give it a status \('working' or whatever\)\. There may be better ways to do that, but I don't think throwing out 'diagnosis' as an archetype concept is useful\. \- thomas --- ## Post #34 by @Karsten_Hilbert > It must be clear that one is able to define these terms\. > But others do the same and do it differently\. > > Examples: > Symptom: > 1\- an observable as percieved and communicated by a patient > 2\- an observable fact about the patient \(system\) > 3\- an observable fact about the patient system deemed relevant by a healthcare provider > 4\- the prototypical phenomenon that can be observed and belongs to a set of possible phenomena caused by a particular disease > > These are paraphrased definitions hat I remember\. > > So what to do? > All 4 are defined but not the same\. I agree\. I would think the unifying properties would be \- \(considered\-to\-be\-\)\*singular\* "thing" \(fact, phenomenon, \.\.\.\) \- about the patient \(system\) \- deemed relevant in care for said patient at said moment > This is why CEN/ISO Concepts for Continuity of Care defines many of the terms we need in healthcare\. > http://www.datadictionary.nhs.uk/contsys/ I'll have a look\. Karsten --- ## Post #35 by @system Lets disagree. On one hand people always will use the word diagnosis. We can not and do not want prevent that to happen. On the other hand when we want to have semantic interoperability we must define exactly what we mean when we standardise what is documented about a concept such as DIAGNOSIS. We must disentangle all the uses of the word DIAGNOSIS by providing a rich and well documented set of standardised concepts. So when the DIAGNOSIS archetype is used we know what we mean, that we know the semantics of it. You apparently accept to create and support semantic interoperability problems. I advocate to ditch the word DIAGNOSIS in the context of names for standardised archetypes, because it has too many meanings and functions in the domain of Archetypes. Local communities can use the words they like but select from a set of standardised terms what fits best their use of the word DIAGNOSIS. Even in acute care the word DIAGNOSIS is nothing more that a way to collect money (DRG) or spend money on more diagnostics and treatment. Each 'diagnosis' is an inference that is true until refuted and they are refuted many times even in academic acute care. In the archetype we can be more precise when we use the 'Reason for ...' artefacts instead of the overvalued, misused, DIAGNOSIS term. See the example below, where the DIAGNOSIS is NOT used to document the care provided to a patient. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) 6.5- Concept: Documentation of the Care process Introduction This section will help define the standardised names associated with classes in the [Target Reference Model](http://www.en13606.org/wiki/index.php?title=Target_Reference_Model) of SIAMS . The ideal typical phases are depicted in the figure. - Red: Typical phases in the care delivery process - Blue: Standardised names of the Entry classes in the [Target Reference Model](http://www.en13606.org/wiki/index.php?title=Target_Reference_Model) - Green: Associated concepts in the CEN/ISO 13940-1 (System of concepts to support Continuity of Care) - Grey: Possible other names for Artefacts Care process Treatment Phases 1. **Reason for Encounter:** [Action](http://www.en13606.org/wiki/index.php?title=Action)/[Observation](http://www.en13606.org/wiki/index.php?title=Observation) - the patient most often has a reason to ask medical advice. Sometimes it is a request for a service. A referral by an other Healthcare Provider equally (HcP) can be a Reason for Encounter. The CEN/ISO standard ContSys 1. labels this a a [Health Issue](http://www.en13606.org/wiki/index.php?title=Health_Issue). 1. **Anamnesis**: [Action](http://www.en13606.org/wiki/index.php?title=Action)/[Observation](http://www.en13606.org/wiki/index.php?title=Observation) - the patient explains his complaints/questions. The HcP will ask more detailed questions. Some examples are provided. 1. History Present Illness (HPI) / Chief medical complaint 1. Personal anamnesis With numerous possible sub-divisions 1. Family anamnesi 1. ...1. **Physical exam**: [Action](http://www.en13606.org/wiki/index.php?title=Action)/[Observation](http://www.en13606.org/wiki/index.php?title=Observation) - the patient is investigated. Eventually more questions will be asked by the HcP as the result of this examiniation. 1. **Review 1**: [Evaluation](http://www.en13606.org/wiki/index.php?title=Evaluation) - the obtained facts are documented and evaluated. 1. Progress Note: In this case this is a follow-up consultation, this Decursis will document the progress. 1. [Cumulative Episode of Care](http://www.en13606.org/wiki/index.php?title=Cumulative_Episode_of_Care) Lists all [Episodes of Care](http://www.en13606.org/wiki/index.php?title=Episode_of_Care). Several Episodes of Care can be linked in a [Health Issue Thread](http://www.en13606.org/wiki/index.php?title=Health_Issue_Thread). Each [Episode of Care](http://www.en13606.org/wiki/index.php?title=Episode_of_Care) addresses one [Health Issue](http://www.en13606.org/wiki/index.php?title=Health_Issue). 1. Hypothesis: via the (Differential-) Possible inferred clinical conditions in the patient system are listed.. 1. Summary - optionally a summary can be produced1. **Reason for Encounter as perceived by the HcP**: [Evaluation](http://www.en13606.org/wiki/index.php?title=Evaluation)- based on the obtained observations the HcP might formulate his own opinion. This Reason for Encounter is not necessarily the same as that as expressed by the patient. 1. **Planning:** [Instruction](http://www.en13606.org/wiki/index.php?title=Instruction) - [Clinical Guidelines](http://www.en13606.org/wiki/index.php?title=Clinical_Guideline) are planned specifications. If executed they give rise to a [Programme of Care](http://www.en13606.org/wiki/index.php?title=Programme_of_Care). That is linked to a [Health Issue](http://www.en13606.org/wiki/index.php?title=Health_Issue), that in turn consist of [Protocols](http://www.en13606.org/wiki/index.php?title=Protocol) to be executed. A collection of these [Protocols](http://www.en13606.org/wiki/index.php?title=Protocol) to be executed is called a [Care Plan](http://www.en13606.org/wiki/index.php?title=Care_Plan). The execution of a protocol is a series of [Actions](http://www.en13606.org/wiki/index.php?title=Action). In general they are documented. 1. **Reasons for Investigations**: [Evaluation](http://www.en13606.org/wiki/index.php?title=Evaluation) - there must be a rationale behind the ordering of additional tests to prove or disprove hypotheses / differential diagnoses about the disease process in the patient system. A possible Goal (that what is attempted to be proven of disroven) can be formulated and documented in this phase. 1. **Additional Investigations**: [Action](http://www.en13606.org/wiki/index.php?title=Action)/[Observation](http://www.en13606.org/wiki/index.php?title=Observation) - additional tests are ordered that help reduce the number of possible 'Differential Diagnosis'. 1. **Anamnesis**: Sometimes more elaborate or specialised questions need to asked; questionnaires to be filled. 1. Additional Physical exam 1. Test: Such as: Chemistry, Haematology, Vital signs, Bacteriology, Virology, Pathology, Imaging, Physiology, etc. 1. Trial Treatment: It is not unlikely that as a test a trial form of treatment is started.1. **Review 2**: [Evaluation](http://www.en13606.org/wiki/index.php?title=Evaluation) - as in the first Review the situation can be documented in a Progress Note/Summary and analyzed in terms of (Differential-) Inferred health Issues, etc.. 1. **Reasons for Treatment**: [Evaluation](http://www.en13606.org/wiki/index.php?title=Evaluation) 1. **Planning 1**: [Instruction](http://www.en13606.org/wiki/index.php?title=Instruction) 1. **Treatment**: [Action](http://www.en13606.org/wiki/index.php?title=Action) - various types of treatments are possible. 1. Medication can be described or administered 1. Procedures: such as surgery, counselling, etc.. 1. Referral: to a third party or back to the referring healthcare provider to handle other specific problems/situations, co-treatment.1. **Review 3**: [Evaluation](http://www.en13606.org/wiki/index.php?title=Evaluation) - treatment is evaluated and documented; possible next steps will be planned. 1. Progress Note/Decursus 1. Updating of Episode of Care, Health Issue Thread, Health Issue. 1. Hypothesis: via the (Differential-) health issues the list of possible pathological states and processes in the patient system are listed. 1. Patient Summary - Epicrisis1. **Planning 2**: [Instruction](http://www.en13606.org/wiki/index.php?title=Instruction) - leading to planning of the follow-up. Several possible trajectories will be possible: Continuation, with the planning next contact, Referral to an other HcP, Discharge or, the Death of the patient. --- ## Post #36 by @ian.mcnicoll I am following this discussion intermittently as I am on holiday and supposed to be "openEHR\-free"\. This wiki page http://www.openehr.org/wiki/display/healthmod/Problem%2C+Issue%2C+Diagnosis+and+Concern that was constructed some time ago comes to very similar conclusions to that which Gerard has posted\. Unsurprising since both have a basis within the excellent Contsys work\. I would agree with Thomas though that while this sort of analysis is useful, we need to be careful not to be seen as imposing a model of care and care records which seems unfamiliar or inappropriate\. Secondary \(episodic\) care does function differently from the kind of longitudinal model that we work to in primary care, and though the two do need better integration, we must be careful not to try to impose this model to aspects of secondary care that require a different approach\. An good example of state of the art in secondary care thinking, at least in the UK, is the 'headings' work done the the UK RCP http://www.rcplondon.ac.uk/projects/standards-core-clinical-information The Problem/Diagnosis archetype developed for NEHTA reflects, \(and which is likely to be adopted for the openEHR CKM\) I think reflects a current view that Problem and Diagnosis are structurally indistinguishable but in actual use may be labelled 'diagnosis', 'problem' or 'issue' depending on the clinical circumstance\. http://dcm.nehta.org.au/ckm/OKM.html#showarchetype_1013.1.896 To come back to Koray's original question, as I understand it the issue is how to handle 'diagnosis' information as it is passed from one system/application to another where it is no longer part of the active clinical 'diagnostic' process but evidence for a new 'risk assessment' process, and may have been collected or re\-stated by e\.g a med student or junior nurse\. Ultimately this is a data quality issue \- do you want these records to be retrieved when you do a search for previous diagnoses, perhaps for some other decision support reason? Does someone else vet records entered by junior staff? Do you use maintained problem lists / concern lists to manage the 'truth' of a patient's current medical history? \- in Contsys terms a Heath issue thread, which is continually updated to reflect current understanding of the patient's problems and not just a simple query into all historical records\. Now back to the holiday :\-\) Ian --- ## Post #37 by @thomas.beale In a way, having a 'diagnosis' archetype \(whatever it is today, and whatever it evolves into\) does do away with trying to define diagnosis \- by providing its own extensional definition of data points that some clinical modellers have agreed are useful to collect\. The 'meaning' of the word 'diagnosis' may continue to be debated forever, it won't affect anything material\. I would call this a good example of practical interoperability\. \- thomas --- ## Post #38 by @Stefan_Sauermann Agree. We can't ditch "diagnosis". We may be unable to define it once and for all. However this is a problem of our group. We do not (can not, do not want to) represent all these grups who will populate and use the archetype in thousands of diverse environments and contexts. I agree with Tom in that we need to provide "free space" (very widely defined archetypes e.g. "diagnosis", "problem", ... ) where others can further restrict, code, detail, ... what they want to have. At the moment we have to live with the fact that there still are subgroups who will have contradictory content within their detailed definitions and therefore no interoperability. Over time this will become better. Greetings from Vienna, --- ## Post #39 by @Koray_Atalag Hi Ian, happy holidays \(if you can with all this\!\) Thanks that you revisited my original question \- but I couldn't get your conclusion\. So is it still an evaluation or observation? Oh and thanks to all of you for such an enlightening discussion\.\.\.I really appreciate that\. Cheers, \-koray --- ## Post #40 by @Stef_Verlinden1 Isn't that what we call 'differential diagnosis'? Anyhow. I agree that these DD or reasons for should be seperated and clearly distinctable from the 'final' diangosis, preferably based on facts and deduction. Cheers, Stef --- ## Post #41 by @system As I said it´s a matter of context. Jussara Rötzsch Md, MSc Director, OpenEHR Foundation Owner, Giant Global Graph ehealth Solutions [](http://www.giantglobalgraph.com.br) --- ## Post #42 by @Stef_Verlinden1 I agree that we need a practical solution and that we can't change \(at least not overnight\) what has been going on for ages\. As an intermediate solution, it would be great if it is possible to see on which facts a diagnosis is based \(or a differential diagnose is rejected\) and which protocol is used in order to get to that diagnosis\. As we discussed some time ago, a diagnoses \(for example 'rheumatoid arthitis'\) isn't a 'hard' diagnosis\. Differerent hospitals/ groups of doctors/ regions/ etc\. use different protocols containing different criteria to come to the diagnosis RA\. So one RA diagnosis can't be directly compared to another RA diagnosis unless they're based on the same criteria\. Cheers, Stef --- ## Post #43 by @Stefan_Sauermann Hello\! Agree to practical solutions, and to not change but support what is going on in medicine\. Is this a "general purpose" diagnosis archetype or is there any limit at least to some area? The discussion will be much easier and to the point if there is a usecase\. Diagnosis is very different in places and I do not see a simple "one fits all" archetype soon\. A "general purpose" diagnosis archetype in all bloom will not provide detailed interoperability\. It will only be able to serve as search target, and readers will have to parse the content similar to free text\. The Austrian hospital discharge summaries have very few and simple fields in the diagnosis part, some basic diagnostic codes and mostly free text\. This made everybody happy for discharge management\. However this will not support a group that is in the middel of developing a diagnosis\. Therefore: What is your usecase? Greetings, Stefan Sauermann Program Director Biomedical Engineering Sciences \(Master\) University of Applied Sciences Technikum Wien Hoechstaedtplatz 5, 1200 Vienna, Austria P: \+43 1 333 40 77 \- 988 M: \+43 664 6192555 E: stefan\.sauermann@technikum\-wien\.at I: www\.technikum\-wien\.at/mbe I: www\.technikum\-wien\.at/ibmt I: www\.healthy\-interoperability\.at --- ## Post #44 by @Karsten_Hilbert > and panic attacks/hyper ventilation\. These were my inferences about the > process inside the patient system\. > > Only one was true and had to found out via trial and error diagnostics > and trial treatments\. I fear that the best we can do in most circumstances > \(as GP\) is to code 'Reasons for \.\.' and do not use the word diagnosis too > often\. > > Isn't that what we call 'differential diagnosis'? > > Anyhow\. I agree that these DD or reasons for should be seperated and > clearly distinctable from the 'final' diangosis, preferably based on facts and > deduction\. "final" diagnoses mainly exist with the field of pathology/the coroners office\. Karsten --- ## Post #45 by @system But what to do with the rest of the world that continues to use the term diagnosis meaning something else? Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #46 by @Stefan_Sauermann Hello! If you want to be interoperable to "the rest of the world", you will have to sit together with all of them, agree on the information you want to share in which situation, on how it is packed for communication and write this up in an agreement. Before that day, there will be no safe interoperability without human brains checking each exchange thoroughly, asking back in case of doubt. There will only be interoperability with those who agreed beforehand. Hope this helps, greetings from Vienna, Stefan --- ## Post #47 by @system Hello, that´s what CKM and the openEHR community are for! Regards Jussara Rötzsch Md, MSc Director, OpenEHR Foundation Owner, Giant Global Graph ehealth Solutions [](http://www.giantglobalgraph.com.br) --- ## Post #48 by @Stef_Verlinden1 > Hello, > that´s what CKM and the openEHR community are for! > Regards Exactly. At least that should be the purpose. Why else would we bother and put time in this openEHR effort. Cheers, Stef --- ## Post #49 by @system Hi Stefan You are now getting to the nub of what we are trying to do in openEHR. Actually the modelling of clinical content is a change agent itself. Our hope is to do this on CKM or the like and not need the sitting part. Cheers, Sam --- ## Post #50 by @system Have 'all' sit together? 'All' never write one good novel. 'All' do not invent E=MC2 'All' do not design and fill a coding system such as SNOMED with all the codes 'All' will use semantic interoperability artefacts such as SNOMED 'All' by using it will validate and maintain the codes in for example SNOMED 'All' will not design the machinery behind SNOMED with which the SNOMED lemma's are defined 'All' will use semantic interoperability artefacts such as Archetypes 'All' by using it will validate and maintain the archetypes 'All' will not design the machinery behind Archetypes with which the Archetypes are defined and standardised. Those that are not-'All' in the standardisation world must be aware that healthcare is using fuzzy words as 'Diagnosis'. And that when we produce semantic interoperability artefacts we have to cater to the healthcare world that is using these fuzzy words. But when we - in our machinery- do not define words/concepts in a rigorous way, we never get generic semantic interoperability. Inside our machinery we had better use new words, one new one for each aspect that is associated with the inflated word 'Diagnosis'. It is the opinion of the EN13606 Association that the concepts as used and defined by System of Concepts for Continuity of Care (ContSys) defines these new words that we can (must) use inside our machinery. 'All' in the world can make archetypes to their hearts delight and use their own 'slang' or dialect, as long as we -inside the artefact- use the ContSys terms that are not fuzzy. As long as each user is making artefacts for his own local domain, precise and generally shared definitions are not important. Slowly in the standards world we start to think on how to create a wider more generic semantic interoperability instead of catering for the small closed domains, that we were/are doing until now. In this context my words must be interpreted. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #51 by @Stefan_Sauermann Dear Sam, all, I am fully aware of the openEHR efforts, CKM etc. I agree that these are platforms are required !!! to get the work done. My point is that interoperability will only work for users / systems who are represented in the discussions. Those who engage and agree on harmonised solutions will have interoperability. "The rest of the world" are not represented, they do not discuss. We cannot solve their problems for them. The "rest of the world" will therefore not have interoperability (with us) without further work. Limiting the scope to a certain user group and a use case will make harmonisation crisp and easier. We can focus on solutions for those who are represented in the discussions and get those going. We can then prove and disseminate to "the rest of the world" that this works elegantly with little effort for a certain purpose in a certain community. Our experience in Austria is that "the rest of the world" will notice and jump on the train. The train needs to be there before anybody will jump on. (I do admit that we do not see the complete "rest of the world" on our Austrian trains. But there is an audience and there is international cooperation with relevant groups elsewhere.) (Online tools are fine. In my experience however harmonisation work is successful if you have at least a few face to face meetings at the start, but that is another story, does not belong here.) Greetings from Vienna, --- ## Post #52 by @Stefan_Sauermann Dear Karsten, all, We are at the moment running a working group that defines a "pathology report" for Austria, as a means to exchange results across organisations\. We explicitly do not cover the detailed workflows that lead to the report\. Tomorrow there will be a meeting on this topic in Germany as well\. Austria will be represented and there will be cooperation\. If this group \(anybody individually\) wishes to join these discussions please let me know\. We had a face to face meeting yesterday \(vendors, users\) and touched the topic of "final diagnosis" for patients \(not from the coroners office but for contributing to treatment\)\. The group decided that there is something like a "final diagnosis"\. \(Detailed definition still to come\)\. I agree to your point that things will always change for living beings\. However our group decided that it makes sense to exchange results once all reasonable considerations have been done according to good clinical practice\. We are learning a lot and I am more than happy to share and hear experiences from this group\. Please accept that I believe in limiting this exchange to pathology reports and related issues in the first place\. We do not have time nor resources to discuss solutions for all "the rest of the world"\. Hope this helps, greetings from Vienna, Stefan Sauermann Program Director Biomedical Engineering Sciences \(Master\) University of Applied Sciences Technikum Wien Hoechstaedtplatz 5, 1200 Vienna, Austria P: \+43 1 333 40 77 \- 988 M: \+43 664 6192555 E: stefan\.sauermann@technikum\-wien\.at I: www\.technikum\-wien\.at/mbe I: www\.technikum\-wien\.at/ibmt I: www\.healthy\-interoperability\.at --- ## Post #53 by @thomas.beale It takes this community to do that \- and people in it to make it grow, and change it as is needed\. If we see the situation like software tools, its like putting out a new tool that initially only a small community uses \(think GIT in the early days\)\. You have to get it going and show its value, and then more people will come\. And then the next increment will be based on the thoughts of more users\. And so on\. \- thomas --- ## Post #54 by @Stefan_Sauermann Agree. My preception is that the people in this community share a common vision of doing this on the openEHR platform, within CKM. That is fine and there is hope. I have the feeling, that the people in this community think in many different usecases. We seem to be talking about different flavours of similar things without explicitly stating which flavour is actually meant. This makes harmonisation very hard. Would it be reasonable to establish usecases in order to promote more focussed sub-discussions? I am happy to engage in a "pathology report content" use case effort, should anybody wish to join. On behalf of the national EHR effort we are running a group of users and vendors, so we get heavy, national scale engagement from very high ranking experts. I also have a contracted team here, supporting and documenting the discussion into a guideline document. I would have to check with the bosses, but I guess they might be nudged to agree that we could also capture the results of our discussion into the tools you suggest (if the effort is manageable). Austria is using CDA as transport format but that is another issue. It does not keep us from a useful technology-independent content discussion in this community. Of course we would need help from others who are more experienced in the tools and philosophy of archetypes. This may also generate some input into the 13606 revision that is on the move. So: Volunteers, lets hear from you! Greetings from Vienna, looking forward, Stefan --- ## Post #55 by @system Stefan, why don´t you join us in september? Jussara Rötzsch Md, MSc Director, OpenEHR Foundation Owner, Giant Global Graph ehealth Solutions [](http://www.giantglobalgraph.com.br) --- ## Post #56 by @Stefan_Sauermann Where exactly? If you mean ISO / CEN in Vienna, I will OF COURSE be there!! We are preparing the social program, be aware of a dinner on Monday after the conference cocktail, and a city walk / dinner combination on Tuesday. Should anybody be around on Sunday evening, we could also have a smaller, more focused meeting. Greetings from Vienna, Stefan --- ## Post #57 by @thomas.beale yes. I am looking into upgrading the wiki so it is better organised, and we can create a place to describe or refer to use cases. hopefully! - thomas --- ## Post #58 by @Heath_Frankel3 Hi Stefan, Are you aware of the NEHTA Pathology DCMs done in Australia. These should be close to going into CKM if not already, otherwise you may find in the NEHTA CKM. Heath --- ## Post #59 by @heather.leslie Hi Stefan, The latest NEHTA Pathology Test Result DCM can be found here: [http://dcm.nehta.org.au/ckm/OKM.html#showarchetype_1013.1.839](http://dcm.nehta.org.au/ckm/OKM.html#showarchetype_1013.1.839) I will be attending MIE, Semantic Health Net meetings and ISO in the next few weeks, so hope we can catch up and have a chat F2F Regards Heather --- ## Post #60 by @Stefan_Sauermann hello! I am MIE as well, arriving Monday. You can find me at Bernd Blobels's Workshop EHRs, Mobile Technologies and Policies on the Move to Pervasive Care, Session: T05-WS: Health and Patient Record, Room:Master Monday, 14h45-18h30 or call me on mobile, M: below. I do have an ancient mobile number of yours, will try that and see if it works. And then probably ISO / Vienna. Greetings from there, see you soon, looking forward --- ## Post #61 by @Stefan_Sauermann Beautiful\! Let me know if anything appears\. greetings from Vienna, Stefan Sauermann Program Director Biomedical Engineering Sciences \(Master\) University of Applied Sciences Technikum Wien Hoechstaedtplatz 5, 1200 Vienna, Austria P: \+43 1 333 40 77 \- 988 M: \+43 664 6192555 E: stefan\.sauermann@technikum\-wien\.at I: www\.technikum\-wien\.at/mbe I: www\.technikum\-wien\.at/ibmt I: www\.healthy\-interoperability\.at --- ## Post #62 by @Gunnar_Klein Dear Gerard, Hope to see you in Pisa tomorrow- Many things going on in parallel but I would like to attend the 1306 session. Can you add me to a list? Cheers Gunnar --- **Canonical:** https://discourse.openehr.org/t/yet-another-observation-vs-evaluation-issue/14579 **Original content:** https://discourse.openehr.org/t/yet-another-observation-vs-evaluation-issue/14579