A common topic at this year’s AMP Annual Meeting & Expo was the Food and Drug Administration’s (FDA) proposed rule change on laboratory developed tests (LDTs). AMP members are reviewing the proposal and assessing its implications for their laboratories.
For those who are unfamiliar, the rule would amend FDA regulations to unequivocally define LDTs as in vitro diagnostic products (IVDs), i.e. medical devices overseen by the FDA under the Federal Food, Drug, and Cosmetic Act (FDCA). Prior to this LDTs did not require FDA approval.
What’s interesting to us is how rarely the topic of change management support comes up, both at the conference and during LIMS and LIS selection. Most discussions revolve around immediate needs like specific features, budget limitations, or security. It’s not very often that we’re asked how our software supports the process of deploying changes in a regulated environment.
We thought it would be helpful for our audience to outline the resources required to make changes to an LIS or LIMS so they can make informed decisions about their future investments into laboratory informatics systems.
From our experience maintaining informatics systems for laboratories, the process of changing an already validated system looks like this:
- Changes to the system must be propagated throughout the existing documentation for SOPs, requirements, design, structure, and validation plans
- Multiple cycles of review and approval for these changes prior to moving forward with the changes
- Actually making the changes to the impacted systems
- Re-execution of system validation and, if the impact is large enough, of real-life lab processes
- Multiple cycles of review and approval for the validation results
- An audit of documentation traceability through the entire process, forward and backward, to ensure that future audits move smoothly
Now let’s take a look at the risks involved with these changes:
- The scope of a change can and frequently does shift suddenly as knock on effects are discovered during the process
- Data migrations must be thought through extremely carefully as they can impact system integrity and consistency from pre- to post-change
- In order to limit the scope of revalidation testing an organization must be able to prove that the scope and impact of a change is confined to the areas to be tested, which relies heavily on having system design documentation which is frequently not available or has not yet been created
- Depending on the scope of the change, gaining alignment amongst multiple stakeholders can be costly and time consuming, stealing resources from core business activities
As you can see, depending on the size of the change and the current state of the supporting system documentation, these projects can take weeks or even months of expensive professional resources and negatively impact future operations if the change is not managed well.
Tying back to our original observation at AMP 2023, we invite you to consider the inevitability of change when making decisions about your informatics platform – whether you already have one or are planning to invest in one in the next few years. Some platforms, like Labbit, have recognized this need and have been designed for rapid, version controlled change to facilitate these changes, and reduce the required effort to a fraction of what’s involved with legacy and home grown systems.
To provide further guidance, we’re going to embark on a series of articles to share the knowledge we’ve accumulated on this topic from our services expertise including how to set up and mitigate risks within a change control process in a way that encompasses ALL of the informatics solutions your laboratory uses, rather than one isolated application at a time. If you’d like to learn more follow us on LinkedIn!
