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
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
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.
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.
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.)
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:
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.
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
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.
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/
They use a co-ordinated, modeled, set of terms we can use as reference point when we all use our own definitions locally.
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.
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.
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
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.
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
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
…1. 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.
Hypothesis: via the (Differential-) Possible inferred clinical conditions in the patient system are listed..
Summary - optionally a summary can be produced1. 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.
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.1. 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..
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.1. 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 - Epicrisis1. 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.
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.
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.
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.
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.
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.
