gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Data pack for ICD-9 :-)


From: Jim Busser
Subject: Re: [Gnumed-devel] Data pack for ICD-9 :-)
Date: Tue, 27 Sep 2011 07:52:57 -0700

On 2011-09-27, at 4:16 AM, Karsten Hilbert wrote:

>> and maybe the indices in ref.data_source bear reviewing because
>> [...] maybe each of the middle two warrant the insertion [...] of
>>      , lang
> 
> .lang is only intended to be descriptive (rather than definitory).

We then need some other 'definitory' way to distinguish, within a single coding 
system (e.g. ICD-9), terms which get multiply defined -- in that there will end 
up one-to many relationships between a code which has a distinct health-related 
meaning (e.g. 401) and the multiple terms which will end up matching that code.

I can see some value to permitting / supporting such a one-to-many, because if 
we are going to allow, within a single GNUmed praxis, the co-existence of codes 
in more than one language

ref.data_source r.d_s
------------------------------
pk      name_short
1       ICD-9
2       ICD-9

where in ref.icd9 we would have
-----------------------------------------------------------------------
r_ds.pk=1       401     Essential hypertension
r_ds.pk=2       401     Hypertension artérielle essentielle

then we can foresee

1) that in some cases, patients and clinicians might together attach onto that 
patient's record the english code, whereas other pairings of patient and doctor 
might apply the french code. We now have codes in two different language for 
the same health condition.

2) when we want to identify patients in the praxis with essential hypertension, 
whether for descriptive statistics or to benefit from computational decision 
support, it will be helpful to be able to search on

        code2patient (whether encounter or episode)
        where the value of the code is '410' and
                (via ref.coding_system_root) the name_short
                keyed through ref.data_source.pk
                matches 'ICD-9'

but surely, for any one language, we don't want the same code and term to exist 
in the *reference* tables multiple times.

Distinctness could be maintained under the existing key 
"data_source_version_key1" UNIQUE, btree (version, name_short) by the convention

ref.data_source r.d_s
-------------------------------------------
pk      version         name_short
1       1975_en         ICD-9
2       1975_fr         ICD-9

however when you now say ".lang is only intended to be descriptive" do you 
imply it is *not* intended to be used computationally in which case (if 
definition must be managed inside version combined with name_short) we may as 
well drop the column 'lang'

??

-- Jim


reply via email to

[Prev in Thread] Current Thread [Next in Thread]