Re: [Gnumed-devel] How within GNUmed to use coding e.g. capturing the fact and state of current pregnancies (?)

[Jim Busser]

On 2011-09-25, at 2:45 PM, Karsten Hilbert wrote:

>>> I don't understand the problem.
>> 
>> The problem of having to enumerate all of the
>> potentially-applicable codes under which clinical states of
>> interest might have to be queried if they are to be
>> successfully resulted, when these are not in fact (not
>> always) clinical states but instead
>> 
>>      clinical state - health system interactions
>> 
>> and also the potential for multiple coding systems (or a
>> change in coding systems) to be applicable even within a
>> single praxis.
> 
> OK, I now better understand the need - but I still fail to
> recognize the exact perceived problem with it as regards
> GNUmed ?

Some of this 'problem' -- in terms of how to operationalize coding within 
GNUmed -- is touched upon in my last screenshot in this thread, which 
acknowledges that within GNUmed we can identify multiple attributes (reasons 
for encounters, summaries of encounters, summaries of episodes) which can each 
be coded.

I seem to recall some discussion of being able to use only a single coding 
system (at any one time) within any one GNUmed praxis?

So far in v16 database, I have found the appended.

Questions arising:

1. At the moment (ATM), searching within the Notes plugin (field Purpose Codes) 
will search only among LOINC but I cannot tell if that is because it is only 
the LOINC which have been pre-loaded into my GNUmed or whether --- even after I 
might import ICD9 or ICD10 --- only one coding system will be searched, and how 
related settings or configuration should be done in GNUmed.

2. For the table ref.coding_system_root, do the non-null values (and even the 
.comment value) get created automatically (i.e. do they auto-propagate) as a 
consequence of creating any rows in any inheriting tables (ICD9 etc)?

3. When (in future) building queries to look for various patients characterized 
by various codes, is there any importance (or even value) to incorporating 
columns from the root table into the queries?

4. In the course of developing 'data packs' to import / create rows into (say) 
ICD9 or ICD10, is it sufficient to check existence of codes inside the 
respective tables or is there a need to reference the root table in the data 
pack queries?

******************************************************
ref.coding_system_root (Base table for coding system tables providing common 
fields.)

This table is to serve as the root (in common, parent) table for each of 
several specific-coding-system tables like icd9, icd10, loinc, icpc where the 
coding system is identifiable via

        ref.data_source.pk

******************************************************

Inheriting tables:

ref.icd10
ref.icd9
ref.icpc (found a nice chart, by the way, at 
http://www.globalfamilydoctor.com/wicc/pagers/english.pdf)
ref.loinc
ref.ops - holds OPS (German ICPM-CM) codes http://en.wikipedia.org/wiki/OPS-301

******************************************************

Accessory tables:

ref.icpc_chapter
ref.icpc_component
ref.icpc_thesaurus
ref.loinc_staging  <--- maybe needing to be deprecated / dropped from the 
schema?
ref.other_code

******************************************************

Link tables:

a variety of clin.lnk_code2<various>


-- Jim