gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] clin_health_issue - some thoughts


From: J Busser
Subject: Re: [Gnumed-devel] clin_health_issue - some thoughts
Date: Tue, 16 Nov 2004 00:47:18 -0800

At 6:40 PM +0100 11/14/04, Karsten Hilbert wrote:
 > Is it possible to overhaul the is_aoe/is_rfe/is_active/is_relevant
 flag collection so we can make health_issue and episode pure views
 on clin_narr?
Yes and no. I don't think we can make them pure views because
they might serve defining purposes beyond the naming.

Is_aoe/is_rfe is encounter related and not immediately a
concern for this step.

I'll try to propose a structure this week that implements the
defines_* fields in clin_narrative thereby consolidating the
is_active/is_clinically_relevant business if no one objects.

snip...

Further discussion welcome.

The following form a "background" over which I planned to further ruminate on the issue / episode / encounter / diagnosis decisions. They might be "simple"... I only offer them now in case I am delayed in making any concrete suggestions.

We want to:

efficiently capture & input info
  -> speaks for itself!

be able to re-examine what was found/done at discrete encounters
  -> Richard may advise this is not _usual_, yet it may be an important
functionality on an intermittent basis, when having later to rethink /
reconsider / defend the care or actions, IMO - am I alone here?

group any apparent recurrence of clinical items
  -> makes it easier to locate individual items
  -> permits scrutiny of frequency & time profiles
  -> facilitates nesting

nest related items &/or assign importance (clinical_relevance)
  -> reflects a decision concerning relationship or importance
  -> permits meaningful collapse of data &
  -> limits drowning in a sea of information
  -> assists more relationships to be observed / inferred

code data, where useful
  -> assists communication; analysis; and decision support

avoid logical and clinical inconsistencies
  -> less dependence on human compensation for weak design

=====================================
Taking the above together, in assessing patients, we

- identify one or more Purpose(s) (RFEs / Patient requests) for the visit
- collect History / Subjective data that may concern more than one problem
- examine patients and may find abnormalities (or notable normal findings) in more than one area
- take into account test results and come to an assessment
- make decisions and take action




reply via email to

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