up a level
post article
search
admin
Contact
main
parent
thread
|
Re: Consolidation Proposal: ClearHealth, FreeMED a
by Fred Trotter on Tuesday June 14, 2005 @ 07:05 PM
|
MSgt Cook,
This is a technical response to your last question from some quick conversations with Josh. There were even some cases where I knew the answer myself :)
Answers throughout.
>
> 1) describe how you developed your data model.
We use the some of the more modern OOP capabilities in PHP 4, as well as some object persistence code and data abstraction code. These were previously written by Uversa for other carrier-grade software projects.
We bundle this code into a library called Cellini, which is some of our own code, but mostly the most useful third party php systems, such as Smarty templating system, PEAR, and ADOdb for DB abstraction.
> 2) where is your data model documented?
We have some DB structure documents available on the Wiki. We also have a basic data dictionary built using the tools built into phpMyAdmin, but we haven't had a chance to update things based on the many recent changes. Eventually we will be using UML for usecases and DB structure.
> 3) do you allow any nulls in your database?
Yes but only for optional relationships
> 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?
I believe so all encounter information is created in seperate entires with timestamps. We would have to generate a report we do not yet have, but the data is there.
> 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?
Session data isn't used for updating information, the forms contains the id of the record your editing so having multiple patients open won't
effect that.
There are some features that might run into problems such as the current selected patient quick view that could be messed up by this, but thats not a data loss issue just a usability one.
> 6) have you performed clinical audit and data quality testing of several
> (10 - 20) thousand records?
One of our customers is working on this now.
> 7) is all clinical data coded? If so which vocabularies or standards
> are allowed/provided for?
Currently just billing codes. The current system is targeted to be a good EMR for Practice Management for now, moving towards a great EMR for everything later.
> 8) do you have a dynamic security model that allows various roles that
> are implementation specific?
We use Generic Access Controls for our security model. Specific user actions are checked based on:
An enitity (like the calendar, or even a specific patient record)
An action (mostly generic ones like read,update,delete,add)
A user (whoever is logged in)
An acl applied these 3 items then allows or denies the action.
This is actually synergy between all three projects since I think everyone is using the excellent PHPGacl.
> 9) do you provide E&M calculation/classification for notes? (this is a
> US specific feature)
Not yet
> 10) how do you handle allergies and drug interactions during
> prescribing?
No prescription module at all yet.
> 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).
josh said: I haven't reviewed openEHR's data model so I don't any basis of comparison.
Fred: Until we feel like we have Practice Management EMR in hand, we will not be looking at this. However, rapidly after that, it will become
a concern. In general, we will be hoping to work with openEHR, since I understand it is Free Software friendly.
> 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.
I have database design classes and read the arguments over null, I would agree they can make things more complicated but, they are the only way to allow for optional relationships or data in a
relational databases, so they are used sparingly but when needed.
> 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).
Updates are always done using specific ids either built into the url
(most cases) or passed in the form. I can't think of any place where we make an update based on the last id you selected in your session.
In summary, these questions point out some of the major issues with the LAMP development model. However, since all three projects are LAMP, the
only real question is who handling these issues best, given that they are often an issue with the architecture. Even if there is no consolidation possible, it would be interesting to compare and contrast between the three projects on this issue. I can say that if anybody is handling this better, ClearHealth will be the first to move to an
improved design.
Fred Trotter |
|
|
