Re: [Gnumed-devel] clinician input wanted: how to implement "coding"

[richard terry]

On Friday 04 December 2009 08:42:55 you wrote:

A couple of comments Karsten.

I think coding is very useful and should be enforced in many situations such 
as with health issues, otherwise you've no means to trawl your database for 
information for example pulling out all diabetes with a certain disease, as 
there are multiple different language terms for the diagnosis. Enforcing its 
use is not an encumberance on the user if it is done sensibly.

The advantage of displaying a code is to inform the user that in fact 
something is coded - so for those doctors to whom coding/research is 
important, they know they have entered a coded term even if they don't need to 
know what it is.

If you set up your DB correctly so that all health issues diagnoses are in 
fact coded diagnoses, and in addition allow user-added-terms, then it it not 
too much of a problem.

I personally use a combination of icpc2Plus ( an australianised version of 
icpc from WHO, combined with ICD10, which I can switch on/off at will as per 
the picture.

All dignoses are coded - but the actually health issue term can be a 
descriptive free text, which then becomes linked to the code.

Not sure if this is on-thread or not because I've only just been skimming 
these.

Feel free to post this to the list.

Regards

Richard

> On Wed, Dec 02, 2009 at 10:08:06AM -0800, Jim Busser wrote:
> > if attaching codes could be likened to a task that may not
> > always be done, then the task could be helped by adding
> > functionality that would either filter the EMR tree /
> > problem list (or would provide a popup window, within which
> > is a grid) that would show only the items that had not yet
> > had any codes attached.
> 
> If there's a use case for that ...
> 
> > Even while inputing the detail of one or more codes might
> > be important to add inside the item details (for example the
> > episode and health issue edit window) one might even wonder
> > if there would be value to a distinct coding widget
> 
> I do think so.
> 
> > though
> > it would borrow some of the functionality of things like the
> > EMR tree and notes editor problem list. I am a bit hesitant
> > to suggest it, on account if changes are made to the EMR
> > tree and notes editor problem list the maintenance would get
> > tedious.
> 
> Ah, never mind. There's one more GNUmed design principle we
> might care to identify here (and perhaps document at the top
> of the User Manual ?):
> 
> Codes are *always* secondary in nature to clinical
> narrative.
> 
> I don't see how maintenance of EMR tree and/or problem list
> would get more tedious by starting to support clinical
> narrative ?
> 
> > I am also thinking there can exist more than one code per
> > item even inside a single classification system,
> 
> Absolutely. Not necessarily (but also possible) two
> different codes standing for the very same term but more
> often several codes defining more clearly in combination a
> somewhat more fuzzy narrative. Much like that I may need
> more words in English to explain exactly what I mean by a
> single German word I'd use.
> 
> > let alone
> > across them. Thus I am not sure whether a link table should
> > link each health issue
> 
> Don't fear. I don't think we'll directly link narrative to codes.
> That would probably result in a wild forest of link tables.
> 
> What I'd suggest doing is to store terms/phrases along with
> respective codes for each (clin.coded_phrase). Whenever a
> code is wanted for a particular item of narrative, say, a
> health issue, that table is consulted.
> 
> There may be a need for other ways of connecting codes to
> encounters. Eg, with SOAP notes it may not actually be that
> codes are expected to stand for specific parts of the
> narrative but to rather be *additional* documentation. This
> sort of linking would happen by way of link tables, yes.
> 
> > to a separate table per coding system,
> > or whether the linking should be done in a single
> > link table as coded pairs
> >
> >     ICD10:<value>
> >     READ:<value>
> >     SNOMED:<value>
> >
> > and I am also conscious that these systems can have "versions" so this
> > also needs to be kept in mind.
> 
> That's taken care of. There's a table ref.data_source
> which holds information about sources reference data came
> from. Then there's ref.coding_system_root which holds fields
> common to any (?) coding system linking to ref.data_source.
> Child tables of ref.coding_system_root are ref.atc,
> ref.loinc, ref.icpc2, ref.icd10, etc. By way of
> ref.coding_system_root and ref.data_source they are all
> properly versioned and localized and still searchable across
> systems as one table.
> 
> ref.atc / ref.loinc already exist and are in use, btw
> 
> Karsten
>

coding.png
Description: PNG image