Yet another OBSERVATION vs. EVALUATION issue

Ian McNicoll Ian.McNicoll at
Sun Aug 19 13:07:07 EDT 2012

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

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

More information about the openEHR-clinical mailing list