Yet another OBSERVATION vs. EVALUATION issue

Koray Atalag k.atalag at
Mon Aug 20 07:29:40 EDT 2012

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.



-----Original Message-----
From: openehr-clinical-bounces at [mailto:openehr-clinical-bounces at] On Behalf Of Ian McNicoll
Sent: Monday, 20 August 2012 5:07 a.m.
To: For openEHR clinical discussions
Subject: Re: Yet another OBSERVATION vs. EVALUATION issue

I am following this discussion intermittently as I am on holiday and supposed to be "openEHR-free".

This wiki page

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

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.

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 :-)

On 19 August 2012 13:07, Gerard Freriks <gfrer at> wrote:
> 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 at
> 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 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
> 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
> Reason for Encounter: Action/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  labels this a
> a Health Issue.
> Anamnesis: Action/Observation - the patient explains his
> complaints/questions. The HcP will ask more detailed questions. Some
> examples are provided.
> History Present Illness (HPI) / Chief medical complaint Personal
> anamnesis With numerous possible sub-divisions
> Family anamnesi
> ...
> Physical exam: Action/Observation - the patient is investigated.
> Eventually more questions will be asked by the HcP as the result of this examiniation.
> Review 1: Evaluation - the obtained facts are documented and evaluated.
> Progress Note: In this case this is a follow-up consultation, this
> Decursis will document the progress.
> Cumulative Episode of Care Lists all Episodes of Care. Several
> Episodes of Care can be linked in a Health Issue Thread. Each Episode
> of Care addresses one Health Issue.
> Hypothesis: via the (Differential-) Possible inferred clinical
> conditions in the patient system are listed..
> Summary - optionally a summary can be produced
> Reason for Encounter as perceived by the HcP: 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.
> Planning: Instruction - Clinical Guidelines are planned
> specifications. If executed they give rise to a Programme of Care.
> That is linked to a Health Issue, that in turn consist of Protocols to
> be executed. A collection of these Protocols to be executed is called
> a Care Plan. The execution of a protocol is a series of Actions. In general they are documented.
> Reasons for Investigations: 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.
> Additional Investigations: Action/Observation - additional tests are
> ordered that help reduce the number of possible 'Differential Diagnosis'.
> Anamnesis: Sometimes more elaborate or specialised questions need to
> asked; questionnaires to be filled.
> Additional Physical exam
> Test: Such as: Chemistry, Haematology, Vital signs, Bacteriology,
> Virology, Pathology, Imaging, Physiology, etc.
> Trial Treatment: It is not unlikely that as a test a trial form of
> treatment is started.
> Review 2: 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..
> Reasons for Treatment: Evaluation
> Planning 1: Instruction
> Treatment: Action - various types of treatments are possible.
> Medication can be described or administered
> Procedures: such as surgery, counselling, etc..
> Referral: to a third party or back to the referring healthcare
> provider to handle other specific problems/situations, co-treatment.
> Review 3: Evaluation - treatment is evaluated and documented; possible
> next steps will be planned.
> Progress Note/Decursus
> Updating of Episode of Care, Health Issue Thread, Health Issue.
> Hypothesis: via the (Differential-) health issues the list of possible
> pathological states and processes in the patient system are listed.
> Patient Summary - Epicrisis
> Planning 2: 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.
> On 19 Aug 2012, at 13:24, Thomas Beale wrote:
> 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
> On 18/08/2012 12:10, Gerard Freriks wrote:
> 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.
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at

Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care

openEHR-clinical mailing list
openEHR-clinical at

__________ Information from ESET NOD32 Antivirus, version of virus signature database 7400 (20120820) __________

The message was checked by ESET NOD32 Antivirus.

__________ Information from ESET NOD32 Antivirus, version of virus signature database 7400 (20120820) __________

The message was checked by ESET NOD32 Antivirus.

More information about the openEHR-clinical mailing list