Re: [Gnumed-devel] Past History Comments (was 1.2.3.....)

[Karsten Hilbert]

> My comments below are based on a series of 39622 patient consultations over 7 
> years, with some 12,000 past history items for various patients entered, and 
> I'd hate to think how many archived/changed.
Tell you what, I can't say how much I appreciate having you
around on this.

> The thing about past history is one needs some sort of detail beyond the 
> diagnosis.
Agree.

> A past history being recorded is Not a SOAP note.
You mean cannot simply be recorded just like a SOAP progress note ?

> Here is what I record in my medical records program. Each of these are 
> discrete fields in data_PH table
Let's see if we can fit this into our data model.

> ===========================================
> PastHistory_ID  table key
clin_health_issue.pk

> Consult_ID     key to consults
if there are encounters recorded pertaining to a health issue
they are indirectly linked to that issue via the episode they
occurred in

> Age_Onset     number could be months or years
> Age_onset_Units  key to lu_units table
this we would have to record the following way and I agree
this is ugly:

enter an issue, attach an episode, attach a clin_narrative
soap row, record the age/unit as text in it, attach a type "PH
age" to it

We should perhaps derive a new table from clin_root_item
called past_history that has dedicated age/unit fields.
Entries in that table would then be attached to health issues
which would somewhat clean things up on the backend. Comments
there ?

> Description   eg Hypertension 
clin_health_issue.description

> Notes              eg BP's 190/110, 200/150
Any number of clin_narrative rows can be attached to the
clin_health_issue. The frontend could scan for particular
types of clin_narrative rows and display them as Notes.

> Side_of_Body  key to lu_laterality (0,1,2) ie left,right,both
Given the clin_narrative was declared a diagnosis we would
then have a locality field in the corresponding clin_diag row.

> Ozcode                disease code
Any number of codes can be attached to any of the
clin_narrative rows.

> Date                  date condition noted or recorded
clin_narrative(clin_root_item).clin_when

> Active                if true this is an active problem
clin_health_issue.is_active

> Operation             yes/no true/false whatever you want
> Cause_of_death yes/no
> Confidential      yes/no
see age_onset

> Significant           yes/no  
clin_health_issue.clinically_relevant

> Deleted                       yes/no 
Handled by the auditing mechanism.

> ==========================================
Seems we do need some work but aren't in that bad a shape.

> * a SOAP editor as the list envisages it is not capable of recording this 
> informatiion with this granularity,
Agree.

> *a Popup sub-editor will, such as in in SOAP2.py using the skeletal recall 
> example as a substandard and incomplete, but suggestive visual model, or as 
> in the early gnuMed designs I did. when the PH editing area actually existed.
That's precisely what I would have intended. Have the SOAP
widget pop up the PH editing area when, say, "PHx" is entered
into the soap widget.

> -Laterality is important (if not for the obvious medico-legal reasons!), then 
> for  recalling effects of treatments, progress (when often the patient and 
> yourself forget which side of the body the condition was on).
No kidding !

> What does not work in these examples
> =======================
> 1) The biggest single thing I've found over the 7 years I've been entering 
> data into this is that there is NOT ENOUGH DETAIL in the Notes line and this 
> is a constant source of annoyance to me when entering details of the PH item.
> 
> I allowed 50 characters for this - arbitrary somewhat - dictated somewhat by 
> the screen design. This is adequate for 90% or consultations, but as with any 
> history it is the few percent where you need more detail that really matter. 
Our backend would allow for any length of text (well, within a
few MB). The GUI might want to strip that down on display.
Getting rid of that limit (but perhaps warning on entry when a
threshold is exceeded) will do away with the annoyance of not
being able to fit in that 101st character into a 100 chars
field.

I would appreciate more discussion on how to solve that PH
thing within our framework !

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346