IT Innovation Contest

A team-based contest for creative IT solutions

A Lab Exchange Drupal Module for UCSF

Proposal Status: 

DESCRIPTION OF THE PROJECT. Managing unique scientific research materials is a problem faced by almost all labs at UCSF.  In addition, sharing between labs is difficult since there is no common inventory system, or method of keeping potential collaborators up to date on the materials available among UCSF labs. Here we describe an easy solution for sharing lab resources among collaborating labs and larger networks.  In short, we will build a Drupal module that will allow scientists to communicate their sharable reagents. 


Sharing is ‘opt-in’: An important aspect of our proposed Lab Exchange Module is that sharing is based on an “opt in” basis.  In this way, investigators can choose to share what they want, and keep other materials private.  It parallels the UC-wide mouse sharing system developed by Gail Martin.


Building upon a pre-existing infrastructure.  This proposal builds upon an existing infrastructure built by the McManus Lab.  This infrastructure has been in place for over five years and has already been distributed to other labs around UCSF.  It is composed of several simple applications that are used to track information on various lab reagents within a single lab.  These reagents include antibodies, DNA vectors, and cryovial data, all of which are tracked and maintained in an internal database using the Drupal Content Management System. 


A broad impact for thousands of UC scientists. The existing system is currently only developed to share among members within a single lab.  This single-lab system is currently available to all labs at UCSF through an Acquia:UCSF hosting contract.  Our plan is to network this system, and once integrated, it will generate a broad impact among thousands of UCSF investigators.  By nature, this system is scalable, meaning that it can exist outside of UCSF if desired.


How does it work? This project aims to broaden the McManus Lab infrastructure from single lab websites to multiple lab websites by pulling data from a central repository. The contributing lab controls who they share their data with via a “grouping” function.  Specifically, sharing will be on reciprocal basis within groups.  The group founder (owner of a specific reagent) will manage group membership for that reagent.  In addition to groups, information can be shared to all of UCSF regardless of group.  In lay terms, this means a lab can choose to share a specific reagent with one or more of the following: 1) a small project team composed of several UCSF labs, 2) all labs within a program or department, 3) all of UCSF, and 4) potentially among the entire UC network.  For the end user, all of this can be accomplished by simply checking a box on the lab reagent page.


DELIVERABLE. We will build an open source Drupal Lab Exchange module that allows labs to share reagents within their allocated networks.


 IMPACT ON UCSF'S MISSION

  • Saves time and money, since labs don’t need to recreate or repurchase existing UCSF reagents
  • Enhances cooperativity and collaboration among labs at UCSF
  • Improves productivity, since scientists can focus more time on experiments rather than building reagents
  • Distributed reagents are in essence a backup for lost reagents (e.g. lab contamination, natural disasters)


TEAM MEMBER     PROJECT ROLE

John Kealy              Web Admin/Programmer/Tester

Michael McManus  Project Coordination/Adviser/Web Admin/Tester

Khang Nguyen        Web Admin/Programmer/Tester

 

ESTIMATED TIME DEVOTED BY EACH TEAM MEMBER. Kealy, 40 hours; McManus; 10 hours; Nguyen, 30 hours.

 

We welcome input and suggestions.  If you'd like to participate on this team, please contact one of the existing team members.

Comments

Very nice outgrowth of an existing system. Would facilitate sharing among researchers, saving time, effort, and reduce duplication of resources.

Would like to hear more about how the inventory is managed and if SOP's have been created if we do scale?

Courtney, The inventory is being managed via a series of web forms that are in the Drupal Content Management System. Data is currently displayed via Drupal views The inventory information is kept in a mysSQL database for the most part with the exception of images other files which are stored on a remote filesystem. We have not documented a Standard Operating Procedure beyond business rules in the existing prototype's code. We would document those procedures as part of the project. The application should be able to scale, as it is hosted on a managed cloud service provider. The service allows us to scale for increased database and web traffic on demand. Thanks for your questions!

Thanks John. I definitely see a value in developing some Standard Procedures especially as this scales we want to make certain that the integrity remains and the trust is established across labs. How do you see communicating this to other labs? Via shared research interest areas?

Courtney, Shared research interest will be the driving factor for participation. Researchers would need to determine the appropriate information to share. The creation of ad hoc groups and coordination within those groups should facilitate the creation of standards among the respective groups.

Great! could this resource be listed with the lab core info? http://cores.ucsf.edu/

Teresa, When completed data could potentially be shared with the http://cores.ucsf.edu/ system. That being said, It appears that the system we are proposing here deals with a different kind of item from that system. That system appears to deal with commercially available items (freezers, microscopes, etc.) while this deals with specific antibodies, DNA vectors, and cryovial data produced by researchers to facilitate their research. We are hoping to scale up the existing application on mcmanuslab.ucsf.edu to create a federated inventory system for research use. Thanks for your question and the link to the cores.ucsf.edu site!

UCSF Cores Search (http://cores.ucsf.edu) utilizes the Eagle-i ontology, which supports reagents, antibodies and many more resources that just equipment and services. The current site is heavy on equipment and services because that's the data we had in a legacy database. For an idea of what could be supported, you can see the entire Eagle-i ontology here: https://search.eagle-i.net:8443/model/ and their federated search system here:https://www.eagle-i.net/

Brian, That's good to know. Does that legacy database have any way of importing data? We can organize the data to meet the existing systems basic data requirements and present the public data from the application as an RSS feed or XML format so that the existing application can access the data.

We transferred the data into Eagle-i and deprecated the old database. We are planning to make the search layer in the new system open source. So it could potentially be modified to support more than one data source. Or you could put/house the data in Eagle-i. It has an ETL process to get data in. I don't know if any data feeds in are planned. Anirvan Chatterjee knows the most about the search layer. I'll ask him to comment here too.

We might be able to work with you to get a list of supported reagents in a reasonable format, and advertise the availability on your site to our users. That is: (1) You tell us what reagents you have available (automated import into our underlying Eagle-I database would be best, might be complicated, but we can figure it out). (2) Say some of your users have reagent X. We can then tell users on our Reagent X page to go to your website to get Reagent X.

That sounds excellent. Is there a technical contact in CTSI we should loop in?