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

[Karsten Hilbert]

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:

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

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

> 3) do you allow any nulls in your database?
Yes, hopefully only where appropriate. Please do point out any
flaws you find.

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

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

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

> 7) is all clinical data coded?
All clinical data is categorized into SOAP. All clinical
narrative *can* be coded if you so wish.

> If so which vocabularies or standards
> are allowed/provided for?
*Any* you care to use.

> 8) do you have a dynamic security model that allows various roles that
> are implementation specific?
This is on the TODO list.

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

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

> 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 hope I haven't offended anyone. GNUmed 0.1 is due out this
year.

Karsten Hilbert, MD
GNUmed i18n coordinator
Leipzig, Germany
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346