gnumed-devel
[Top][All Lists]
Advanced

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

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


From: Richard Terry
Subject: [Gnumed-devel] Past History Comments (was 1.2.3.....)
Date: Wed, 24 Nov 2004 15:10:43 +1100
User-agent: KMail/1.5.4

Jim has some good points. 

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.

The thing about past history is one needs some sort of detail beyond the 
diagnosis. A past history being recorded is Not a SOAP note. I've used past 
history entry since 1997 for all my patients, and I offer the following 
comments about what does and what does not work with my design.

One mportant question with PH is, just what do you want to capture. I.E as Jim 
has alluded to you need to know just what your needs for data are:

- to support your medical record
- to be able to re-display when needed yourself
- to be able to link to decision support
- to be able to link to progress notes
- to be able to link to scripts, recalls etc
- to be able to pass intelligently on to hospitals/specialists/patient
- to be able to give to the patient (incidentally all my patients get a total 
printout of their medical records each and every time it is updated here)
-to be able to support research SQL or otherwise
- special cases eg psychiatric history may require quite a bit of detail

Here is what I record in my medical records program. Each of these are 
discrete fields in data_PH table

===========================================
PastHistory_ID  table key
Consult_ID       key to consults
Age_Onset       number could be months or years
Age_onset_Units  key to lu_units table
Description     eg Hypertension 
Notes              eg BP's 190/110, 200/150
Side_of_Body    key to lu_laterality (0,1,2) ie left,right,both
Ozcode          disease code
Date                    date condition noted or recorded
Active          if true this is an active problem
Operation               yes/no true/false whatever you want
Cause_of_death yes/no
Confidential        yes/no
Significant             yes/no  
Deleted                 yes/no 
==========================================

You will immediately note that:

* a SOAP editor as the list envisages it is not capable of recording this 
informatiion with this granularity, ie entering the data in ordinary progress 
notes will not work easily if you want to be able to later modify the way it 
is displayed, do research etc

*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.

*I've attatched some png's from my editing areas in my medical records project 
to illustrate the sort of data that this captures and will comment on the 
adequacy/inadequacy/pros/cons of my experience using this below.

What works about this granularity:
====================
- If you have a look at the attached png's, you will see that by and large 
they contain a reasonable amount of information, but not too much, which 
conveys the essence of the problem, and it is abbreviated enough to be able 
to pass on to other health care providers. Also it is granular enough to 
format in several different ways, depending on context.

-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).

-Active or Inactive (and the ability to switch back and forth) speak for 
themselves.

-Operation is useful for reaearch, and is not always obvious from the disease 
condition

-Confidential (I don't want everyone on the bock to know my HIV status or if I 
have herpes, thank you very much)

-Significant -(if not - we really don't need the PH item displayed in 
PHsummaries - eg the encounter for a Paronychia of the great toe becomes PH 
but is unlikely to be significant.

-Age/Year of onset obviously important if not always accurate

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. 
One can use abbreviations as  you can see from my entries, but it is not 
enough, and besides, anyone of us in general practice who has had to deal 
with hospital doctors can recall the constant pulling out of ones hair as the 
resident puts in abbreviations meaningful to them and the hospital system 
which are meaningless to us. 

A field of 100 characters would be 99.9% ok, but if using the multi-line SOAP 
stc control then lengh is not a real issue (except in that one still has to 
be able to generate a summary for letters etc, and in long term patients the 
amount of information could become a tome.

2)The rather naive beleif that one could at the time of entering the past 
history item, allocate a routine period of review, for a particular lengh of 
time ranging from months to indefinate. Great idea, but singularly the 
biggest goof in the screen design and functionality because try as hard as I 
could, and with all the motivation in the world, I could not get it to work 
in real life practice.

Anyway, tis my afternoon off, so I must go now.

Regards

Richard

Attachment: ph_je_1.png
Description: PNG image

Attachment: ph_je_5.png
Description: PNG image

Attachment: ph_je_3.png
Description: PNG image

Attachment: ph_je_4.png
Description: PNG image

Attachment: ph_je_2.png
Description: PNG image

Attachment: ph_je_6.png
Description: PNG image


reply via email to

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