Re: [Gnumed-devel] SOAP - Edit Area - Parser - some thoughts

[Karsten Hilbert]

Ian,

> My understanding now is the soAp assessment becomes a running title for 
> the episode,
sort of

1) clin_narrative stores all SOAP parts
2) some soAp rows can be labelled AOE
3) any soAp row can be linked from diag tables
4) the AOEs are the running aP (active problem)
5) for lack of entering something else the episode title may
   draw from the aP but note that there may be several
   parallel aPs per episode, eg the episode title can be "knive
   cut L arm 9/2000" while there are two aPs "delayed wound healing"
   and "numbness Dig III-V" linked to that episode
5) the number of AOEs per episode should be limited to as few
   as possible, preferably just one

> it is a text string that may or may not be linked to a coded diagnosis.
right

> Sounds good. But (unless I'm missing something) where do health_issue and 
> past history fit in?
Health issue for the above might be "auto-agressive behaviour"
or "Lesh-Nyhan-Syndrome". Or just "xxxDEFAULTxxx".

Past history is, well, the past history stored with previous
encounters. IOW, clin_narrative rows.

> IMHO "past history" is just a query on all formal diagnoses assigned to the 
> patient.
Not in how I understand "past history". But let's work with
that concept for the rest of the message.

> They may be tagged with various levels of activity/dormancy/privacy/etc.
> [as an aside, it may be useful to assign some coded daignoses with a default 
> high privacy setting, such as STDs and pregnancy termination]
sure

> Obviously we still need a separate screen for entering past history on the 
> inital consultation
> (i.e. 'orphaned' coded diagnoses that don't link to an AOE, and so are by 
> definition dormant)
You can always just enter clin_narrative rows where
soap_cat='a' and make them diagnoses by putting data into
clin_diag (codes, laterality et al). Then tag them as
appropriate and perhaps put in a clin_narrative row where
soap_cat='s' saying "AU-type past history taken" ;-)

clin_narrative rows where soap_cat='a' don't *have* to be
is_aoe but can still have more data in clin_diag* tables.

> With health issues/episodes/AOEs I'm worried users may get bogged down trying 
> to decide 
> what should be what.
That is a real concern, yes. However, health issues will
hardly ever be represented to the user except for viewing.
Episodes will (or at least *I* would make the app) draw titles
from the AOEs. Episodes are likely to be editable in more
places than health issues but are still only moderately visible.

> the user is presented with a list of active problems (i.e. active health 
> issues)
active problem is an established current problem that
we work on

health issue is an overarching issue with one's health, eg
immunodeficiency, few people will have more than 2 of those,
older = more, I fear

eg. a knive cut will in many cases belong the the default
health issue since it does not signify anything about the
general state of the patient's health

> if the user tries to attach a SOAP entry to a problem
(active) problems *are* soAp entries which are tagged is_aoe

> after a certain timeout (... snip ...) a new episode is
> implicitly created under the health issue.
No, why ? An encounter is created. (Perhaps several) RFE(s)
are created belonging to the encounter. It is up to the user
to decide which episode those RFEs (and thus "partial"
encounters) belong to. Most of the time they belong to a) one
single episode b) which is the most recent one.

Only if the user decides that this is a *new* episode will a
new episode be created. Eg. the 1998 upper leg fracture healed
(episode closed) but now the gamma-splint starts to make trouble
(new episode). Due to that fracture being part of a polytrauma
and exposing a second episode the user *may* decide to declare
a health issue "condition after polytrauma 1998" to which
those and further episodes get linked.

> Health issues are named after the coded_diagnosis (if assigned),
> otherwise the title of their penultimate episode.
Seems like two options to be suggested once the user decides
to move episodes from the default health issue to their own
health issue.

Eg.in practice the user never *has* to deal with health
issues (everything belongs to default) unless she wants to.

Perhaps issue is not the most fortunate term but naming is
hard. Ask any parent.

> Obviously we should provide an override in the history browser where users 
> can forcibly fuse consecutive episodes, or divide a 
> longer episode, much as gnumed already does for separating encounters. 
Absolutely ! But I would only let the user do this manually.

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