JMP, LIMS, SPC & some stability analysis

[#1]

Maybe this is a long shot, but I thought I'd post it anyway. After a very productive 1h meeting with a JMP systems engineer last week I started suspecting that JMP at my workplace is highly underutilized. Partly this has historical reasons, as it is a young company, where the use of Excel proliferated for all purposes from logging process measurement data to stability & degradation analysis of finished products (nutritional supplements). Also, I believe we are now in a transition period where management starts realizing that data insight is required much faster than is currently possible. One of the things we are currently working on is the implementation of LIMS. With respect to product stability analysis, our data is spread over different folders, which are all related to different studies. Typically each study has its own Excel file for storing results, usually in its own non-standardized formatting, i.e. almost every dataset is organized in its own way.

My question is broad and multifaceted:

• What should my organization consider with respect to the implementation of LIMS? Can all of the major supplier databases be queried by JMP, e.g. for creating SPC reports or dashboards?

• The JMP systems engineer showed me a couple of options how to streamline stability analysis & data management. I wonder if there is a JMP stability community out there and if someone in that community would be willing to share their experiences.

• As I believe I still don't fully comprehend what JMP is capable of, I was wondering to what extent it is being used in modern day process industry. The first things that come to my mind are data querying (preferably from a single database that contains both process related measurements as well as stability data, if that is not a dumb idea) & real time analysis (e.g. via SPC).

• Once LIMS is implemented, how would I start extracting & analysing data from a database? Are there any SAS/JMP trainings on that topic?

[#2 · Accepted solution]

Wow, your Discussion Topic is really big.  

Let me provide you with some thoughts on some of your questions.

What should my organization consider with respect to the implementation of LIMS? Can all of the major supplier databases be queried by JMP, e.g. for creating SPC reports or dashboards?

1. This is an evolutionary task.  So dtermine what you currently believe the end point needs to be, and then plan the steps inbetween where you are today and the end point.  JMP is really well adapted to this method, in that it has the flexability to deal within your current chaotic world, and within a final structured environment.
2. Most data repository products support an ODBC interface into their world.  Therefore, JMP will be able to access such stored data.  But, on the rare occasion, or in situations where the database structure is very complex I have seen organizations develop Java, C, C++ systems that extract data from data sources, and then populates the users JMP instance with the data table(s) from the extraction.  All driven from the JMP instance.
3. JMP/Public should be a part of your final design. If your JMP demonstration you spoke of did not include the product, you need to look into it.  It will provide the final reports into an interactive web enviornment, for the providing of information to the JMP and nonJMP world of users.  All of your reports and Dashboards can be presented to your population of users without having to know anything about JMP.
4. Real JMP users may end up rarely using Excel.  JMP can replace >95% of what one uses Excel for, and it will be more efficient.  However, most JMP users do not get to this point, and Excel will remain their data manipulation tool.  Even with this, JMP's smooth interface into Excel makes this a very acceptable approach.

These are my thoughts......as my time schedule currently permits.  And, I reserve the right to futher comment at a later point in time :-)

[#3 · Accepted solution]

Greetings,

I experienced the developent and implementation of a new LIMS first-hand over the past few years. My comments below address some of your query points.

The first thing to consider is the data governance plan that your organization has in place before considering the merits of various systems. My previous organization decided to have few controls over how information was added to the system as a measure to cusion the blow of system change for technicians and scientists. This was a monumental mistake as the task of pulling data from the system for analyses was cumbersome and extremely time consuming. Terms for lboratory testing must be commonized as well as having a strict nomenclature for things like product codes, laboratory methods, batch numbers and technician names. I suggest to be sure to have a parallell pilot to load in a small amount of information so the organization can test the process of pulling out data of interest and running analyses/reports. 

The vasy majority of current system providers have products that will work well with the query builder options available in JMP. An ODBC driver is usually available that should be compatable with JMP for pulling in data.

Stability analysis works well as long as the data governance is sound. I have had experience with an organization that siloed data by product code instead of housing all data in one location, which made getting the appropriate data the toughest part of the job. Invariably, you will run into a stakeholder who wants to compare stability performance of one product to another. The biggest issue we ran into was the lack of data from long-term storage. Stability trends are not very robust until the data collected has had storage significantly beyond the expiration dating. It is ideal for the storage time modeled to be twice as long as the expiration date for long-term commercial products. The best prediction for a linear model is at the centroid. This is a difficult subject for management as the resources required for long-term storage are not trival. I do not know of a stability group; however, there is a chapter on stability in a recent book I put together with the link shown below:

https://www.sas.com/store/books/categories/usage-and-reference/pharmaceutical-quality-by-design-usin...

I am hopeful that the information provide is of value for you. 

[#4]

Regarding "housing all data in one location". I suppose you mean not spreading data across multiple folders and files, which is what we do now. I inherited a decent amount of legacy data together with an established structure of folders and xls data repositories, which seemed nightmarish at first. I feel that I am somewhat in control now, but maybe that is an illusion.

Is your recommendation to consolidate all available data in a single JMP data table? (Provided I have a back-up of some sorts in place)

P.s.: I'm sorry if these questions seem trivial, but for me this advice is essential. So I really do appreciate all these helpful comments.

[#5 · Accepted solution]

I think what @statpharmer was getting at was to let a data governance plan dictate the 'where, how, when, what' of the process for managing data.

Generally speaking, I think storing everything in a single JMP data table, and I'm taking the word 'everything' literally, that is, every single data point from the beginning of time, to the latest data point in time created, across all workflows coming through the LIMS system, in perpetuity, is not recommended.

The general model I saw across my customers was to have a standard process in place for storing, accessing, adding, maintaining, and distributing the data in the database(s) that is NOT tied to any single analysis or reporting application (even JMP). Then married to that piece of the data flow to end users is some sort of SQL based connection  (for example, using JMP Query Builder or other internally generated applications), for acquisition, and distribution of the data to analysis end users. Then the users work with the data in JMP for their specific analysis and reporting/sharing purposes. So generally the data in JMP is temporal related to a specific work problem. It may be stored in JMP in perpetuity but it's still temporal related to a specific business/analysis issue.

Generally I found the IT organization was charged by management from a strategic point of view with data stewardship wrt to the contents of database(s). These companies view this data as the 'crown jewels' of their R & D, quality, compliance, and production systems...and they want a foolproof/mistake proof/defect free means for managing that data. That's IT's responsibility...not the analysis end users.

Hopefully, I've not stepped on @statpharmer  too badly here? If I have...he'll let me know!

[#6]

That were some interesting remarks. I actually had a meeting with our IT department yesterday to talk about precisely these issues. The IT department agrees with this approach. Now all that remains is getting our routine laboratory QC as well as stability data into a unified database (I believe the person from our IT department I spoke to called it a "data lake") and make the data then accessible for statistical analysis, e.g using JMP. I was specifically instructed not to worry about the technical details, which was a relieve. However, I do also believe that @statpharmer made some excellent points regarding terms for laboratory testing, nomenclature for things like product codes, laboratory methods, batch numbers and technician names. Maybe my employer will provide for a good case study for -I hope- how to handle that issue.

[#7]

I ran across the issue of common terms as we were trying to demonstrate how the use of DOE for product development reduced resources and sped the time to submit and obtain approval. Some lab technicians identified testing trials by their initials, date, product code, and test method; others entered data in a different order. We also found that some identified the differing stages of a product batch with suffixes, others created a new batch ID for each stage. It took nearly a month to get an accurate count of the number of development batches for one product as many people had to be interviewed. With good data governance, an accurate count of development batches by product code could be done in minutes. You are doing your organization a great service by the thinking you are putting into this project. Best Wishes!

[#8]

One framework that could at least provide you with a vision or model of your future state is using what the US Food and Drug Administration mandates as part of the data management construct for clinical trials. It's called CDISC. A part of the CDISC framework are standard data naming conventions for variables within a clinical trial. The idea is to provide ONE framework for common data name identification fields so the FDA doesn't have to figure out what say, trial subject variable name is from one clinical trial study to the next...all trial subject identifiers follow the same naming convention and on and on. There are loads of FDA and other organizational resources on the subject...here's one that might provide some guidance?

https://www.cdisc.org/FDA-Final-Binding-Guidance-on-Standards

[#9]

I'll add one comment that I think supplements the wise advice from @txnelson and @statpharmer  that ties into the data governance plan mentioned by @statpharmer . Make sure to include your IT organization in ALL discussions, plans, and implementation details. The devil is in the details and having your IT colleagues in the deployment early and in perpetuity will minimize rework, defects, and surprises. As a former, now retired JMP systems engineer myself, with many of my JMP customers using a LIMS environment, that which you describe is entirely possible...so your team should be: users, your IT, your JMP sales team (maybe you'll want to modify the JMP deployment and system administration?) with an overall management sponsor to provide budget and strategic guidance.

Lastly, have you considered going to a JMP Discovery Summit event? You could I pretty much gaurantee finding others at the event who have been down the road you are headed down...and one thing about JMP users is they love to talk and share with other JMP users.