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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
