---

Over the years, I have designed and written a great deal of custom code related to the dissolution and content uniformity/uniformity of dosage units (UDU) methods for a variety of LIMS systems. Regardless of the number of methods included or the complexity of the solution, this custom code tends to add significantly to the cost of the implementation.

When I mention "custom code" or "custom solution" in this article, I'm referring to code written by me specifically for one customer at-a-time to create a module to be used with their purchased system (i.e., one where a software vendor writes the code and sells the entire system to a variety of customers).

For several years, I've had an idea for a truly configurable module to accommodate these methods, and have been hoping a software vendor would create such a module.

Just the other day, I was griping to one of my customers about how much better the implementations would be with such a module, especially because I run across so many customers using many different evaluation methods. This particular customer's response was that I should develop and sell this software, myself. "After all," he added, "you could make a lot of money on something like this!" (Note: I should add that this response came from one of the customers who needs a number of methods and processes surrounding these methods.)

I'll skip over the reasons why it's not that easy to create and sell custom software and jump to the driving forces that compel customers to create their own solutions:

1. These methods aren't like other tests. Because of how the stages are done and because the stages are really just part of one, big test, they have to be calculated in a special way. Additionally, their specifications aren't straightforward (try to put the limits in specifications in your system and try it out; it won't work out as you expect).


2. You'll often hear sales reps say that their systems provide the USP evaluations. So far, I have not found that to be quite true. The systems may provide some of the USP evaluations, but there are many, many evaluation methods within the USP.


3. It's a global world. Companies now sell their drugs all over the world. They now must meet not just the USP, but the BP and the EP, as well.


4. In research situations, the numbers of dosage units aren't always what is specified in the USP/BP/EP. In fact, in a production situation, there are reasons why the numbers are sometimes different.


5. In research situations, it is sometimes desirable to modify the evaluation methods.


6. There might be software somewhere in the world that does all of this better than we can do with custom solutions, but because so much of dissolution/UDU needs to be posted into LIMS and is possibly most practically calculated there, and because much of the implementation issue is process-oriented and fits tightly with other LIMS processes, such software isn't usually taken seriously by customers.


7. Some customers have other methods besides just dissolution/UDU methods that operate this way that need to be included in the implementation.

You can already see the downside to creating a custom solution:

1. It's expensive to design and implement a custom solution within your LIMS for your specific process and method needs. Keep in mind all the documentation that's implied by the words "design" and "implement" and you'll get an idea of the size of this task.
2. The customer has to maintain the custom solution themselves, which can be expensive.
3. A custom solution is often an unexpected and additional expense to the project, as customers sometimes misunderstand what functionality they are or are not purchasing within the LIMS system. Or, customers may not realize the complexity of incorporating these methods into LIMS.
4. The sales person from the software vendor or services provider might not understand the additional functionality required in order to properly sell the services. Or, the consultants working on the implementation (i.e., the "experts," one would hope) may not realize the complexity of incorporating these methods into LIMS.

Bottom line:

1. Dissolution and UDU methods can add a lot to the project cost.
2. Dissolution and UDU methods are not trivial nor easily loaded into the LIMS because of the overall process involved.
3. Too much code must be written to make dissolution and UDU methods functional within many LIMS systems, especially considering how many companies do this type of testing.

Many LIMS now have Stability Modules that get better every year, largely because customers have pushed hard for these types of solutions. Now, it's time to develop dissolution/UDU packages with the flexibility required for all labs and all methods. Is that realistic? With the exception of one or two methods, I'm convinced it is possible. It may even be realistic to include the few unusual methods by using a really clever strategy.

---

---