gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] Re: [FreeB] Re: [openhealth] Consolidation Proposal: Clea


From: Karsten Hilbert
Subject: [Gnumed-devel] Re: [FreeB] Re: [openhealth] Consolidation Proposal: ClearHealth, FreeMED and OpenEMR
Date: Wed, 15 Jun 2005 17:41:25 +0200
User-agent: Mutt/1.3.22.1i

On Wed, Jun 15, 2005 at 12:11:09AM -0700, Tim Cook wrote:

> I assume you are reffering to the POMR work (not relational theory work)
> by L.L. Weed?
Yes.

> > > 3) do you allow any nulls in your database?
> > Yes, hopefully only where appropriate. Please do point out any
> > flaws you find.
> There are no appropriate places for NULLS in a "relational" data model.
Not in a "pure" relational model, true. I do think great care
needs to be taken when using NULLs. All in all it's a
religious issue.

> > > 4) could I produce a view of the patient record that gives me the
> > > condition of the patient at a specific point in time (1 month or 1
> > year
> > > ago) maintaining the complete context of the patient condition as
> > > recorded in the database?
> > Yes. Likely not in a snap but a resounding Yes!
> For legal or clinical reasons I might need to know exactly what was
> known about a patient at an exact point in time.
As far as the database is concerned we should be able to
deliver on that. The implementation is likely to lack in
several places. The concept is built in, however.

> I think this might be
> much more complex than you are first giving credit.
It might and I should like to learn about how it is.

> This is especially
> so given you are allowing data elements to be in unknown states at
> different points in time (NULLS result because of data that is unknown,
> not knowable or not applicable.  Unfortunately, you can never know
> exactly why something was NULL at any point in time unless you were the
> data entry person.).
You are correct. Not only should some NULLs be typed (as in
data type) but rather should they be modelled.

> This question again really refers back to my question about your
> CLINICAL data and maintaining the context in a patient record over long
> periods of time.  Load testing for performance is a very different
> thing.
I understand the difference but fail to see how you would test
for the former case ? Are you referring to torture tests ?

> > > 7) is all clinical data coded?
> > All clinical data is categorized into SOAP. All clinical
> > narrative *can* be coded if you so wish.
> Certainly anyone CAN type in ICD's or other codes.  The question is does
> your data entry mechanisms FACILITATE clinical coding?
The backend facilitates coding as in the codes being attached
rather than included in the narrative. The frontend does not
yet facilitate entering codes.

> > > If so which vocabularies or standards
> > > are allowed/provided for?
> > *Any* you care to use.
> A meaningless answer.  Does this indicate the level of understanding of
> clinical coding or a lack of appreciation for the requirement?
No vocabularies are provided at the moment. Mostly due to
license issues. The backend, however, provides for storing and
attaching to some narrative any type of such. The frontend has
precious little support for actually attaching codes to
things. The only coding that's already done (and in fact
cannot be avoided) is SOAP classifying which falls short of
many things interesting to an epidemiologist but goes a long
way in structuring data for everyday clinical use.

> > > 8) do you have a dynamic security model that allows various roles
> > > that are implementation specific?
> > This is on the TODO list.
> Ok.  I'm not quite sure how you retro-fit this into an application
> though.  
I am sure we will hit several spots where we need to rewrite
the client(s). We will also need to rewrite (parts of) the
database schema. No problem I can see :-)

> > > 10) how do you handle allergies and drug interactions during
> > > prescribing?
> > Allergies are stored as such, eg typed as allergies. They are
> > *always* prominently displayed (in the reference client) along
> > with the patient name. Being typed they can be re-used
> > programmatically. 
> I assume you do not mean typed in the keyboard typing sense of the
> word?
No. They are stored in an allergy table with several fields to
specify the certainty, the substance etc etc. This is what I
mean by "typed". One can if wanted code the clinical narrative
as put into the comment field, for example. Coding is also
provided for regarding the substance(s) such that that can be
used in decision support.

> > We don't do prescribing yet. The code we
> > have and how we intend to do it is fully typed data such that
> > drug interactions can be checked programmatically.
> How curious.  This is usually considered a "quick win". An EMR without
> prescribing capability.  Is there a specific reason for this?
Yes. Doing prescriptions properly is *extremely* complex. It
may not be so in the US but it is here (Germany) and quite a
few other countries.

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




reply via email to

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