Re: [Gnumed-devel] About systems of codification

[Jim Busser]

On 2011-09-29, at 2:02 AM, Karsten Hilbert wrote:

> On Thu, Sep 29, 2011 at 10:32:10AM +0200, Karsten Hilbert wrote:
> 
>> A coding system can never replace free text in the EMR. It
>> can only serve precisely defined secondary purposes.
> 
> Now, there's a fine line to observe here between a
> classification and a terminology.
> 
> The latter at least attempts (but typically fails) to
> represent narrative (while the former quite purposely does
> not even attempt that).
> 
> Both need different approaches for support in an EMR. Coding
> is add-on while terminology should be pervasive and
> permeating.
> 
> Terminology STILL suffers from miscoding, especially in
> Primary Care where patients differ ever so slightly (but
> significantly) and where conditions aren't so well defined
> (which is why GNUmed offers support for established levels
> of certainty on conditions).

Agreed. Picking up from the various points in the thread, let me untangle some 
of what I was trying to say

codify = to make computable

classify = to assign as a member of a group based on whatever purpose, 
perspective and criteria serves the interest to the classifier (employer/ 
client / customer) - think ICD-9

free text = text which is not coded (despite that it *could* be *codifiable* - 
think string searches)

Assertions:

- we are most *clinically* interested to employ *terminology*
- we are also interested to identify, understand, and deliver care to clinical 
groups of patients
- this makes the basis of the grouping extremely important
- where a terminology has been sufficiently structured, the lexical coding can 
provide an 'auto' (built-in) grouping… however, at that point, the question 
becomes the suitability of the grouping semantic to the thing that is wanted to 
be understood

Moving on to EMR …

A medical nomenclature, to be clinically useful, *must* be able to accurately 
and adequately describe, document, and inform about the clinical problems and 
diagnoses of at least *some* patients

TO THE EXTENT that a term fully and sufficiently accurately captures any one 
patient's clinical problem, it can be unnecessary to add anything more in 'free 
text' <--- this is what I meant about making free text unnecessary.

NOT that it is or will ever be dispensable to have free text *available* (which 
it must be), because every patient can have one or more conditions whose 
description cannot be adequately captured by a term. This can be because no 
suitable term exists, or because the clinician did not locate and select the 
preferred term on account of design or performance issues.

That is all I was saying. That it *can* be the case, for a particular problem, 
for a particular patient, that a term does in fact FULLY SATISFACTORILY capture 
a patient's problem or diagnosis. I cannot yet see that there can be any 
disagreement on the point, nor on the point that, where the aforementioned 
applied, any requirement to ALSO enter free text reflects only the 
inadequacy-at-that-time of the EMR design or implementation.

I still maintain it can be entirely appropriate that a user with access to a 
highly suitable medico-clinical nomenclature should want the first or primary 
field in a problem widget to be a phrasewheel for the nomenclature, 
supplemented by some kind of workflow helpers as might include
        - do you mean <alternate spelling>
        - commonest conditions in your personal praxis
        - commonest conditions in this praxis
        - commonest conditions in this locale 

and that it would be to the right of (or below) the phrasewheel field that a 
free text field should be provided and used (only) as necessary.

What the GUI would show is:

- in the case where a coded term was entered, display that term (concatenated 
to any free text)
- in the case where no coded term was entered, display the free text
- where more than one term was coded to a problem, display the set of terms in 
a tooltip

Perhaps, in any one praxis (or in the case of any one user) there could be a 
preference dictating whether what the UI shows is

        term (if exists) concatenated to free text (if exists)

vs

        free text (if exists) concatenated to term (if exists)

This could be done even in a GNUmed-next and would save me time and trouble in 
the cases where it did turn out that a code fully ENOUGH satisfies the 
description of a patient's problem. That way, while I am using ICD-9, I would 
be able to keep such a preference set per default to

        free text (if exists) concatenated to term (if exists)

 and yet benefit, in the case of some patients, from faster yet adequate data 
entry. As soon as I could obtain SNOMED and as soon as I would be satisfied 
that it will justify, I could change my setting to

        term (if exists) concatenated to free text (if exists)

Now it is true that as soon as I do that, all patient problems that were dually 
ICD-9 and free text will display with the less helpful ICD-9 with free text on 
the end. However, for any patient in whom it is justified, I could substitute a 
suitable SNOMED term. I suppose it might require to 'delete' (send into the 
audit table) the ICD-9 term, unless we would granularize the database to 
distinguish primary from secondary code or distinguish computationally, before 
delivering into the GUI,  terminology codes as opposed to classification codes.

-- Jim