Re: [Gnumed-devel] Can we have a refresh of Attach documents (Episodes) when a problem was added to EMR

[Karsten Hilbert]

On Thu, Dec 08, 2011 at 08:33:58AM +0000, Jim Busser wrote:

> Maybe there was not even a problem identifiable. The
> patient for unclear reasons saw a cardiologist who assessed
> the patient and said they're normal. The patient brings it
> back with them from vacation.
> 
> So now it is not enough that the praxis is satisfied to attach this document 
> as a type
> 
>       Consultation - Cardiology
> 
> with a comment
> 
>       unsolicited, reason NYD
> 
> but the praxis also has to invent a problem and a pseudo episode under which 
> to associate this?

Nope. It's sufficient to "invent" an episode. And be it just
"documents on unsolicited external care".

(One might argue that there is ALWAYS a reason for the
patient to see a doctor - but I agree that it is over to top
to always establish said reason.)

A hook script can create such an episode without any
user intervention.

> I totally understand why you want to avoid to nightmare
> linking, but that is not what I am asking, and I still
> cannot understand why you are insisting to require an
> associate to episode???????

Because clinical data is - by its nature - characterized by
two items:

- administrative link (encounter)

- clinical link (episode)

There's no need to be upset about such things. I do agree
that *one* clinical link may not suffice. But linking to the
issue rather than the episode does not mitigate that. As for
why not NOT linking see below.

> Why not allow it to be null and then the sort order on
> episode will simply sort together the nulls?

For one thing the "simply" isn't so trivial to get right.

I maintain that it is more desirable to keep things
technically consistent and explicitely model "no we don't
know the actual episode but here's a bunch of similar things
so link to that".

There's a whole school of thought in SQL land arguing that
any data model needing NULLs is broken (not sufficiently
normalized, that is).

I tend to try to avoid them where feasible.

They always require special handling.

Which is easy to get wrong.

Which can kill patients.

I agree with your desire to ease the workflow though -
which is why I suggested that a plugin could be written to
hide the pseuo-episode stuff.

(quite similar to hiding the SOAP when people don't want it
-- but there I agree that it is clinically saner to allow
SOAPU because that allows to explicitely say "this is
Unspecified but clinical" rather than simply not showing the
doctor that the machine assumes this to be any single one of
SOAP and hopes to be right)

I have recently had the joy to assist a user in repairing
his database which - likely by some foreign-key disabling
restore process - had grown partially unlinked records.

It was only due to the stringent data consistency
constraints which GNUmed employs by exploiting PostgreSQL's
capabilities that there was any hope (and finally success)
of salvaging what had gone astray.

Once you've seen such you quickly learn being paranoid.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346