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

[Karsten Hilbert]

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
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346