[Top][All Lists]
[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
- Re: [Gnumed-devel] Data pack for ICD-9 :-), Jim Busser, 2011/09/26
- Re: [Gnumed-devel] Data pack for ICD-9 :-), Jim Busser, 2011/09/26
- Re: [Gnumed-devel] Data pack for ICD-9 :-), Karsten Hilbert, 2011/09/26
- Re: [Gnumed-devel] Data pack for ICD-9 :-), Karsten Hilbert, 2011/09/26
- Re: [Gnumed-devel] Data pack for ICD-9 :-), Jim Busser, 2011/09/26
- Re: [Gnumed-devel] Data pack for ICD-9 :-), Karsten Hilbert, 2011/09/27
- Re: [Gnumed-devel] Data pack for ICD-9 :-),
Jim Busser <=
- Re: [Gnumed-devel] Data pack for ICD-9 :-), Karsten Hilbert, 2011/09/27
- Re: [Gnumed-devel] Data pack for ICD-9 :-), Karsten Hilbert, 2011/09/27
- Re: [Gnumed-devel] Data pack for ICD-9 :-), Jim Busser, 2011/09/27
- Re: [Gnumed-devel] Data pack for ICD-9 :-), Karsten Hilbert, 2011/09/27
- Re: [Gnumed-devel] Data pack for ICD-9 :-), Jim Busser, 2011/09/28
- Re: [Gnumed-devel] Data pack for ICD-9 :-), Karsten Hilbert, 2011/09/28
- Re: [Gnumed-devel] Data pack for ICD-9 :-), Jim Busser, 2011/09/28
- Re: [Gnumed-devel] Data pack for ICD-9 :-), Karsten Hilbert, 2011/09/28
Re: [Gnumed-devel] Data pack for ICD-9 :-), Jim Busser, 2011/09/27