[Gnumed-devel] Re: [openhealth] Consolidation Proposal: ClearHealth, FreeMED and OpenEMR

[Tim Cook]

On Tue, 2005-06-14 at 09:59, Karsten Hilbert wrote:
> Tim,
> 
> I know you did not ask for GNUmed answers but it is always
> good to put up with inquisitive questions ;-)  Even more so
> when done out in the open:

Very true.  

> 
> > 1) describe how you developed your data model.
> Our model is a one-level model. If and when we see/understand
> how to start using OpenEHR we will keep using it. It was
> developed by doctor-programmers. We used relational theory,
> extensions of the concepts put forth by L.L.Weed et al., and
> the experience of a few doctors/programmers having written
> EMRs/medical software previously.

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

> > 2) where is your data model documented?
> Our docs aren't formally recognized, eg no explicit UML and
> such, but we do have a heavily commented schema, dumps
> thereof, HTML versions thereof and entity-relationship
> diagrams. All of it freely available on the web.

Thanks.

> 
> > 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.

> > 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! We audit
> everything (pretty much). As for the context: We only have as
> much context as you initially put into the database, of
> course. That includes encounter, episode, problem, health
> issue, patient as foreign keys.

For legal or clinical reasons I might need to know exactly what was
known about a patient at an exact point in time.  I think this might be
much more complex than you are first giving credit.  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.).

> > 5) how does your sessioning machinery guarantee that I write data to
> the
> > correct patient record when I have multiple patient records open on
> the
> > same workstation at the same time?
> I cannot imagine anyone releasing an EMR that does not
> *inherently* fulfill the requirement ? 

Hard to imagine isn't it?  It happened and there were several
installations.

> Anyways, our reference
> client (written in Python) operates with (among others) one
> basic assumption: There is only ever one patient active in one
> instance of a client to which all data is attributed. This is
> embodied not just in the client but rather - by way of OOness
> - inherent to the middleware. If you open several clients on
> one machine you can work with several patients at the same
> time, of course.

I was referring to the browser clients with this question because it is
more difficult than in a client/server implementation.  Though you could
really screw this up in a C-S environment as well. :->

> > 6) have you performed clinical audit and data quality testing of
> several
> > (10 - 20) thousand records?
> Partially yes. We did load up our demographics database with
> 125 000 (real) names/addresses at one point. We have tested
> lab data up to several hundred records. Not much beyond that
> point yet.

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.  If this issue still isn't clear I'll attempt to expand on it.

> 
> > 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?  This is
important so that the EMR can drive things such as billing, decision
support, population health and other analysis reporting (given
appropriate ethical considerations of course).  Otherwise the EMR falls
short of user expectation and actually increases the overall workload
for no apparent benefit.

> > 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?

> > 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.  

> > 9) do you provide E&M calculation/classification for notes? (this is
> a
> > US specific feature)
> No. I also have no idea what this is about :-)  Perhaps
> triage support ?
> 

As indicated it is US specific.  It relates the level of care given
(documented) and therefore guides the amount of reimbursement.

> > 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?  Because if so there would be no way to reuse them
programmatically.  I would hope they were clinically coded so they could
be used in prescribing and other decision support functions.

> 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?

> > If you allow nulls anywhere in your database you run the risk of
> queries
> > returning incorrect information.
> Meaning you have a bug in your code that needs to be
> fixed.
> 

I must agree that if you allow NULLS in your database you have bugs in
your database constraint code.


Thanks for taking the time to respond Karsten.

Cheers,
  * -- 
    Tim Cook
    Key ID 0203DEEC @ http://www.keyserver.net & http://keyserver.mine.nu
    Get the key from: 
http://24.85.34.168:28080/Nikki_and_Tim/twcook_publickey.txt/file_view

signature.asc
Description: This is a digitally signed message part