Byron,
I've read your architecture document, and agree with most of your choices. Apache as webserver, ANSI SQL92 for the database schema, security through SSL and interoperability through XML. As for the app server, I'd strongly suggest looking into Enhydra as a possibility.
As a question, towards what purpose do you expect to be driving the Open LIMS? That is, what kind of lab?
I'm currently working on the database design of a LIMS for a gene transfer facility (from scratch), the design of a database for a clinical genetic counseling (and clinical research) service using Progeny (Sybase back-end, ActiveX and PowerBuilder front-end package combining pedigree-drawing tool with database), and doing smaller stuff in Access for various other labs/facilities within the genetics department, and the one thing I've found is that a database for one service has a lot of differences from a database for another. There is a lot in common, of course, and we'll need to identify those areas of commonality. But there's a big difference in the focus of a solution designed for, say, a small mutation detection lab versus a clinical genetics counseling service, versus a gene transfer facility.
On the one hand, the mutation detection lab wants a LIMS that will allow them to track the information on a given sample as it moves through the lab. They'd also like the ability to output barcode labels and input label scans, and it would be really great if their lab equipment could directly dump data into the LIMS. Some of the equipment is designed for that sort of thing, other machines aren't, and most of the ones so designed are older and built for interfacing with Macintoshes. Base focus: the sample. Since each sample has a unique patient, we can focus the top of the database on the patient. Other than that, usage of the system will be fairly simple. Things start getting more complex when we move to attempting to interface with equipment.
On the other hand, the system designed for a clinical service has to deal with a much larger set of workflow issues. Individuals within the service have differing security access, particularly to mutation results data. There are a large number of discreet human-performed workflow steps. Also, the service is focused on the family rather than the individual patient, even though working within a clinical, hospital environment requires that patients be uniquely identifiable. So, the database focus needs to be a step up in the hierarchy, on the family.
The gene transfer facility is facing FDA clinical trials, and thus needs to capture information on each individual step in the process in minute detail. Further, the process itself will change, as will the standard operating procedures. Each change needs to be tracked, approved before use, and each use needs to be tracked. The focus, once again, is on the patient rather than the family. In light of these particular issues, the system needs to be easily customizable by the facility's management in order to capture an ever-changing set of data. Also, due to the rigors of the lab environment (needs to be very clean), PCs with fans (power supply, CPU heatsink-fan, etc.) cannot be allowed inside the lab. Yet, with the sheer quantity of data being captured by the lab technicians (the process is 90% hands-on, no automation available at this time), they need to have an easy and ubiquitous means of entering data -- possibly a hand-held or a tablet computer on a wireless network. Finding the proper form factor for true ease of use is not going to be easy, but if the form factor is PDA-sized, then WML will need to be used in addition/in place of HTML.
I apologize for the lack of coherence of this message, but I hope that I can help bring to light some of the issues that I've faced when dealing with implementing data management solutions in a genetics environment -- and that, by extension, any bioinformatics-focussed LIMS will face.
---Phoukka
|