Not logged in
  • Log in
    Membership (40249+) Group hosting [?] Wiki
    Franklin Award

    About bioinformatics
    Bioinformatics training
    Bioinformatics jobs

    All information groups
    Online databases Online analysis tools Online education tools More tools

    All software groups
    FTP repository
    SVN & CVS repositories [?]
    Mailing lists

    News & Commentary
  • Submit
  • Archives
  • Subscribe

  • Jobs Forum
    (Career Center)
  • Submit
  • Archives
  • Subscribe
  • OpenLIMS: Lab information system - Message forums

    Discussion forums: Open Discussion

    Expanded view | Monitor forum | Save place

    Submitted by Nobody; posted on Tuesday, December 03, 2002
    Hello, for inspiration you may take a look at Labcollector web site: Darek

    Post a followup to this message:
    You have to be logged in to post a reply.
    Thread view
    Submitted by Byron Ellis; posted on Thursday, February 08, 2001
    I am opening as a place to brainstorm features and structures for the project's design document.
    Submitted by T. Peter Herndon; posted on Friday, February 16, 2001
    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
    Submitted by Nobody; posted on Tuesday, December 03, 2002
    Hello, for inspiration you may take a look at Labcollector web site: Darek
    Re: Labcollector
    Submitted by Unamed; posted on Saturday, April 09, 2011
    I used once the Lims solution called LabCollector. It's a scam. Slow, using outdated technologies and the statistical software is even returning false values !! TO AVOID ! Mike
    Submitted by Nobody; posted on Thursday, October 02, 2003
    XML -- good - just make sure to talk to your vendors and get THEM to have THEIR data exported in an XML format! makes live easier for everybody DB -- good - many exists. some have more adv. features than others, like native support of XML data. ie. give DB an XML file, and DB fills in relational tables for you. For true security (ie encrypt db files), i feel only purchased DBs can give you that capability. good luck
    Submitted by Scott C. Lohr; posted on Wednesday, January 21, 2004
    Maybe this project should work on expanding what will be released by 3rd Millenium. That is, if this project is still alive.


    Copyright © 2018 · Scilico, LLC