Re: [Gnumed-devel] need assessment from fellow clinicians

[Karsten Hilbert]

> Methinks an even bigger challenge than billing!
Only if we make it to be. Years of research have gone into
this (too little, however) which I am wading through at the
moment. But we must find a well-fitting framework that works
for us. It needn't be perfect in a theoretical sense.

> - active problems (aPs) are a subset of all of a patient's problems, so aPs 
> can 
> (best?) be regarded as those problems that have the attribute "active".
Yes and no. Except that I would propose to define aPs
backwards using this algorithm:

1) grab all AOEs that are labelled "permanently relevant"
2) look at active episodes (how to determine that is up for grabs)
3) of those grab the most recent AOEs

Or easier:

1) grab most recent AOE per episode
2) sort most-recent first

> Yet problems, while active, can have further attributes:
Those are not further *attributes* but rather
further *states* combined with attributes, IMO.

> ...active-uncontrolled (by definition most "active" & likely source of RFEs)
eg. most recent AOEs of active episodes, uncontrolled state may
be reflected in naming

> ...active-controlled (parameters [like symptoms, measures] satisfactory)
see above

> ...inactive-dormant (able to recur)
> ...inactive-cured (unable to recur e.g. appendicitis post appendectomy)
Sure ? ;-)

I am not really sure we need to hardcode the dormant/cured
state into the tables ?

> - if we assert that the following, though codable to diagnoses, are also 
> appropriate 
> to consider "problems', then each of a patient's Diabetes, Hypertension, 
> Asthma and 
> Back pain can,
Once an episode has led to a medically well-founded diagnoses
the most recent AOE is likely to contain the diagnosis text.
So they will automatically appear as aPs, perhaps labelled
permanently relevant.

> if coded as controlled or uncontrolled, be automatically understood 
> to be "active" whereas once the back pain improves, or the diabetes proved to 
> be 
> gestational or steroid-related, these could be coded "dormant" thus 
> understood to be 
> "inactive".
The episode timeout (or other lifetime limiting mechanism)
should do for "dormant".

> These are more functionally informative than active/inactive, provide 
> more useful thresholds by which to expand and contract data displays while 
> sparing 
> the need to manually update a separate active/inactive attribute.
That is what I am also concerned about.

> - the aPs would arise from the latest AOE per episode, I am wondering 
> therefore if 
> aP table records are just a subset of specially-attributed AOE records
Yep, that's pretty much what I had in mind. There would be two
kinds of assessments for an encounter (eg per episode per
encounter):

an AOE - the latest of which is the name of the aP for this
         episode, the history of which will allow us to track
         progression from less to more certain

a clin_narrative row where soap_cat=='a' which is the clinical
narrated assessment of the episode snippet in this encounter

> during any one episode the AOE approximates an active-uncontrolled problem 
> and 
> whether it is upon conclusion of an episode that an AOE becomes an aP that is 
> considered either active-controlled or inactive (-dormant or -cured as the 
> case 
> applies) --- see also below, concerning "forced closure" of an episode when a 
> problem is not yet controlled ---
Yes ! That pretty much sounds like what I had in mind :-)

> Reason for Encounter (RFEs)
> - initiation may be
> ...by doctors (as in followups or recalls or periodic health exams)
> ...by patients (as in new, or worsening, or recurrent complaints) or
> ...by others (a concerned relative, a community nurse, an employer)
full ACK, often the RFE will be entered by front-desk staff
into the waiting list, but not always

> - presumably a Gnumed doctor initiating an encounter
Which is akin to instantiating a clinical_record object. The
initial encounter type is set to chart review or to the most
recently used encounter type.

> would desire to designate the 
> inciting aP or
which happens automatically by associating with an
encounter/episode -> the previous AOE becomes the current AOE
(a copy thereof) perhaps a "followup" added

> if none yet exists, input a value into the AOE that is able to be 
> either kept, or modified, at the time of the encounter
exactly, the default for this would be the RFE :-)

> - supposing a Gnumed doctor initiates an encounter to reassess the 
> hypertension of a 
> patient last seen 6 or 12 months before, is a new episode being 
> created/opened, with 
> the potential to range from a one-encounter episode (if the BP is under 
> control) or 
> a multi-encounter episode (if the hypertension proves to be 
> active-uncontrolled)
It may be argued that hypertension checks that show BPs under control
all belong to the same episode of care "hypertension control"
that ends when "bout of out-of-control BP" starts. However,
that is rather arbitrary and up to the user. If the patient
really only checks in for BP assessments every 6-12 months one
could just as well use one-encounter episodes aggregated under
the health issue "hypertension".

> - if within any one "open" episode more than one problem is being dealt with,
Never, conceptually. That's what the most recent AOE == aP
paradigm is based upon. There may be several "problems" in the
linguistic sense but only one in the episode-sense. Or else we
would be equating aPs with "symptoms that sufficiently bother the
patient to seek care". Is this what we want ? I don't think so.

> does 
> the episode remain "open" until the last of the problems achieves the status 
> active-
> controlled (or can an episode be "forced" closed if the patient and doctor 
> agree 
> that partial control is all that can be achieved until the patient can later 
> engage 
> again in a future episode)
IMO up to the doctor/patient, not the programmer :-)

> If multiple RFEs across multiple encounters within an episode prove to 
> pertain to a 
> single disorder, together with its investigations, treatments and any side 
> effects, 
> I could understand that a single AOE could meaningfully give:
> 
> > the gist thereof in one catchy phrase.
> Suppose a patient begins thiazide for hypertension, gets a rash and gout, 
> takes 
> NSAIDs, and gets a GI bleed, all before hypertension control is achieved.
Well, that's an interpretation issue. IMO the GI bleeding
isn't caused by the hypertension - she could be taking NSAIDS
for any amount of reasons. Hence I'd introduce a new episode
"epigastric pain" where "nsaid-related epigastric pain" ->
"suspected epigastric ulcer caused by nsaid" -> "nsaid-caused
bleeding epigastric ulcer" in that order of AOEs for this
episode. Hypertension control needs to be achieved regardless.

> In such a case, where within an open episode of care the encounters span more 
> than 
> one problem, we don't open multiple overlapping episodes, do we?  But if we 
> don't, 
> and there is therefoe only one AOE, it will have to provide a phrase to 
> paraphrase 
> multiple problems e.g.
> "BP high, thiazide for hypertension, got a rash and gouty flare, stopped 
> thiazide, 
> started ACE, GI bleed on NSAIDs, scoped for large gastric ulcer, Rx PPI, 
> stable, BP 
> controlled"
Nope. See above. Overlapping episodes. Episode of Care ==
"Episode of Care for one Particular Health Issue".
Not "Episode of Care in time as opposed to times when no care
at all was needed".

Even if we would, the above narrative would be found in
clin_narrative where soap_cat=='a'. And the AOE might contain
"uncontrolled hypertension with GI bleed complication" or
something along those lines.

> If the above is what is intended, then the AOE would not equate to an aP, 
> would it?
Exactly.

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