Yet another OBSERVATION vs. EVALUATION issue
gfrer at luna.nl
Sun Aug 19 08:07:06 EDT 2012
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.
gfrer at luna.nl
6.5- Concept: Documentation of the Care process
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
With numerous possible sub-divisions
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.
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:
>> 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 lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-clinical