On Mon, 2005-06-13 at 19:49, Fred Trotter wrote:

> This message is being cross posted on all the relevant forums.

I only have access to openhealth at yahoogroups.com so maybe someone
wants to pass this along?

>
> As a result of the fact that Josh and David are first class
> architects,
> and David and I have a deep background in the current architecture of
> FreeMED and OpenEMR, I feel ClearHealth has the cleanest layout and
> most
> progressive core features of any of the three projects.

Since I have no interest in any of the projects mentioned I would like
to address this paragraph.

I do not know Josh or David beyond what I've read on the web. But,
it would seem that I should be able to extrapolate the above paragraph
into; "ClearHealth has a great architecture". If I am correct can David
and Josh please address these issues:

1) describe how you developed your data model.

2) where is your data model documented?

3) do you allow any nulls in your database?

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?

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?

6) have you performed clinical audit and data quality testing of several
(10 - 20) thousand records?

7) is all clinical data coded? If so which vocabularies or standards
are allowed/provided for?

8) do you have a dynamic security model that allows various roles that
are implementation specific?

9) do you provide E&M calculation/classification for notes? (this is a
US specific feature)

10) how do you handle allergies and drug interactions during
prescribing?

Of course OpenEMR and FreeMED developers are ENCOURAGED to address these
issues also.

My reason for asking these question are that no matter how fancy your
scheduler or glitzy your templates. If you can't absolutely guarantee to
return the context of my clinical patient data in 5, 50 or 100 years
then you have a broken model. (HINT: I am a proponent of the openEHR
two level modeling approach).

If you allow nulls anywhere in your database you run the risk of queries
returning incorrect information. If you allow nulls in your database
you now allow a three valued logic and are no longer faithful to the
relational model as defined by E.F. Codd and refined by others.

If your server can't distinguish between data write operations on
separate patient records coming from the same workstation then you have
a VERY serious issue (yes, this was (is?) characteristic of at least one
of the mentioned applications).

Is that enough to start up a technical dialog? I believe the level to
which each application addresses these issues will help establish a
baseline for your consolidation.


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



[Non-text portions of this message have been removed]