Main problems of automation of laboratory processes

LIMS is an automated laboratory system that collects and processes (manages) data(s). Some people think that LIMS is a set of electronic journals used by the Laboratory, but a real LIMS is a specialized program that is used for accounting, calculations, reports, control, etc.

LIMS is a system, and at a minimum combines several journals, allows using information from some journals in others, for example, using equipment information in the measurement (test) journal, or using information from the sampling journal in the protocol issuance journal. By combining several journals and reference books in one system, new properties and functions of record keeping can be achieved. It turns out that emergent properties are achieved due to systematicity.

One of the important features of LIMS is the properties of record management, which are not available when using paper journals. As a rule, when implementing LIMS, a laboratory has requirements for the need to comply with the requirements of GOST ISO / IEC 17025-2019 for maintaining records set out in paragraphs 7.5 and 8.4. It is clear that LIMS should be able to record results, track changes, prohibit changes, archive, backup. In one form or another, all LIMS manufacturers strive to implement all this. Of course, there are not very convenient and practical forms of implementation, but in any case, you can program it so that the date, time of entering and changing data, the user and information about him are automatically recorded. In this case, the user will not be able to edit this information.

But this is all in LIMS, but if you think about it, it becomes clear that this cannot be achieved on paper.

For example, an employee can fill out a log with results not at the time of testing (measurements), but later or even on another day, since information about the time and date is entered by him, if it is entered at all.

The same applies to changes, you can always make a correction and sign with a different date. You can completely rewrite the measurement sheet (primary protocol) and even the measurement log. If necessary, you can make corrections in the log with any date.

Keeping records on paper does not ensure compliance with technical record requirements and their modification. Without a full-fledged LIMS, it will not be possible to implement all the requirements for technical records.

Experience shows that it is difficult for laboratories to successfully implement LIMS. The main mistakes in implementing LIMS are not much different from the mistakes in implementing other information systems:

1. Lack of clear technical specifications for implementation. As a rule, when implementing a LIMS, the laboratory takes the technical specifications from the supplier. It is clear that the part about the functions and capabilities of the program should not be changed after choosing a specific program, but there is another part of the technical specification that concerns implementation. And this section of the technical specifications should be given as much attention as possible;

2. The laboratory drags all its printed/handwritten forms of record keeping into the LIMS. Well, I guess there is no need to explain this. If you are switching to electronic records, you need to abandon the old paper ones. Perhaps they were optimized by you and are convenient to fill out, but in the program everything will definitely not be the same. You should not hold on to your double and triple tables;

3. The processes that the laboratory wants to automate are not clearly defined in the management system, there are ambiguities and imprecision in the descriptions, the employee's behavior when choosing alternative options is not assigned. The process is not “transparent”. We can talk about this for a long time, and this topic should be considered separately. The developer and implementer of LIMS often encounters the fact that the laboratory seems to have documented the processes, prescribed the forms of records. But in fact, there are undocumented records, and the employee's behavior when alternative options arise is not always prescribed. That is, some actions occur, but they occur out of habit or because the manager said to do so, and this was not included in the SM(K). Here is a simple example – “the process of registering a sample”. It would seem that registering a sample is very simple, and the entire process is described in two sentences. “The employee accepting the sample enters the information in the log (Appendix 1). The number is assigned in order in the log.” But there are various nuances here. For example, laboratories can use specific codification/numbering of samples, have several registration logs, each for its own type of samples (say, by objects, by state assignment and separately paid ones), they can also be divided by departments, and the composition of the entered information can vary greatly. Additionally, an employee can make notes in the log between the lines with some other information about the sample (for example, indicate the state of the sample or a note on sampling);

4. A variation of the third error is not quite correct implementation of methods. If LIMS assumes that records and calculations will be made according to methods, then it is necessary to very well prescribe the sequence of actions of the personnel for entering these records and to analyze the calculation formulas well. Unfortunately, in practice there is a misunderstanding of methods by the personnel, and then it is still dragged and fixed in LIMS;

5. A serious mistake of the laboratory is the unwillingness to rework the SM(K) documentation for LIMS. The implementation of LIMS in any case changes the processes in the laboratory and all this should be reflected in the SM(K) documentation. Unfortunately, there are not always people on the LIMS developers' side who are well versed in this;

6. The laboratory is not ready to validate LIMS. Validation of such software is actually mandatory, just like validation of calculations in spreadsheets. Laboratories try to get confirmation from developers, but during the implementation process, many changes are made and the product installed at one customer may differ greatly from the product at another customer. Of course, LIMS suppliers present some certificates for their software. But such certification is not regulated in our country and such certificates are issued by non-accredited bodies, which violates the law on technical regulation (184-FZ), and therefore such beautiful papers have no force.

7. The laboratory, for its part, has not formed a group of people responsible for implementation. Well, this error is everywhere. On the one hand, the developer must have an implementation team with a project manager for the implementation, and on the other hand, the laboratory must also have responsible people who undertake to complete this implementation. The responsible people can be authorized by an order or by some other method accepted in the organization. Naturally, the person responsible for implementation must have the necessary powers to change the MS documents, draw up the technical specifications, plan validation, etc.;

8. Well, the last mistake is the lack of goal-setting in implementation. It is impossible to correctly implement something that is not known why it is being implemented. It happens that the top management makes such a decision because others have it or some regulator requires it, but does not set the right goals. Such implementation for the sake of implementation is not needed by anyone and, as a rule, fails.

If we introduce something new in the laboratory, or in any activity, we must first set TARGET. Moreover, the implementation of something new is not a goal in itself. The goal must be described and visualized. If the goal can be described and visualized, then it is real and achievable.

What goals can a laboratory set for itself?

1. Automatically generate test reports to reduce errors and human factors.

2. Automatically accept applications and samples to make it easier to track and control the movement of samples and the timing of work.

3. Receive accurate and detailed reports on laboratory work without request.

4. Eliminate the use of (filling out) handwritten forms.

5. Speed ​​up the work of the laboratory (although such a goal should be set with caution).

You can select several non-contradictory goals and define an achievement criterion for each. For example, the goal of generating reports will be achieved if it is possible to generate a target report for six months of work.

The criteria for achieving goals must be written down for each goal, in general, this is part of the visualization. Criteria allow us to focus attention and designate the boundaries after which the implementation project can be considered complete.

If the organization uses any scoring systems or KPIs for bonuses, then the criteria for achieving the goals allow motivating those responsible for implementation. The implementation team should be assembled at the goal-setting stage, since the composition of this team depends on the goals. In the process of forming the team, additional goals and criteria for achieving them may appear.

The management's goal is usually to increase control over the employees' work, automate reports, and reduce errors. And the employees' goal is to automate their work, simplify routine operations. It is necessary for the management and employees to be motivated so that LIMS solves some of their serious problems, then the implementation may be successful.

When the Laboratory Management has defined the goal and visualized it, it is necessary to form a team responsible for implementation. This team should include the laboratory manager, department heads, quality manager, key employees – process owners. It is desirable that the team size does not exceed 5-7 people, otherwise it will be difficult for them to agree among themselves.

The team bears a heavy burden:

1. Description of functional requirements for LIMS;

2. Familiarization and selection of products from those available on the market;

3. Preparation of technical specifications for implementation in accordance with the functional requirements of the laboratory and the capabilities of the selected LIMS;

4. Coordination of the implementation plan provided by the LIMS supplier;

5. Monitoring the implementation process, communicating with the implementation team from the supplier, clarifying requirements, checking LIMS and describing errors;

6. Validation of LIMS after implementation.

Implementation work can take quite a long time and consist of many stages, so the team should meet periodically and discuss the current status of implementation, problem areas, what else needs to be done at the current stage, and agree on any changes and improvements.

Having chosen a LIMS from those available on the market or having decided to develop their own, each implementation team faces the problem of writing a technical specification. If a commercial option is chosen, then, as a rule, the software supplier provides its own technical specification, slightly modified in accordance with the transferred FT. You should not expect any detailing of the planned solutions there. Everything will be described in general, evasive phrases, the main emphasis will be on some technical issues (for example, the database server used). For the software supplier, the main problem is that in order to draw up a detailed technical specification, it is necessary to examine the laboratory processes, familiarize employees with the proposed solutions, determine and agree on the volume of necessary settings, modifications and changes. This takes quite a lot of time, and there is no point in the software supplier doing this before concluding a contract. Although the implementation team is interested in a detailed technical specification, firstly, it does not have the relevant knowledge and skills (competencies), secondly, it does not have full information about the capabilities of the selected LIMS in customizing it to the needs of the laboratory, and thirdly, it often has an incomplete understanding of the laboratory processes due to their opacity, lack of clarity in the description, and lack of alternatives. I wrote about the problem with process transparency at the beginning. It is impossible to write a good technical specification if the processes are “opaque”. It is necessary to first clarify the description of the processes, determine the level of detail, etc.

We can talk about processes for a long time, but in general it is clear that if a laboratory cannot describe its processes, then it will encounter problems when implementing LIMS.

Therefore, there is an option to divide the work on the technical specifications into three stages:

1) The laboratory writes the technical specifications and transfers them to the LIMS supplier;

2) The LIMS supplier conducts a laboratory survey according to the technical specifications and identifies nuances

a specific laboratory, introduces employees to LIMS, and during the introduction and discussion, many hidden issues and problems in the processes are revealed;

3) Based on the results of the survey, the supplier draws up a final detailed technical specification and agrees with

laboratory.

It makes sense for LIMS suppliers to include the survey stage in the contract stages and stipulate that based on the survey results, the list of methods, logs, forms and reports that will be implemented in the laboratory (configured by the supplier in LIMS) will be clarified. Some laboratory forms and reports can be changed during this period if they cannot be implemented directly in the same form in LIMS.

Implementation documentation (basic list):

• Purpose and functional requirements – internal document;

• Technical specifications are an internal document and/or appendix to an agreement (contract);

• Contract, agreement, treaty or other document with a supplier (contractor);

• Work plan agreed with the supplier, order to assign a person responsible from the laboratory;

• Acts, protocols of acceptance and transfer of LIMS, launch of test operation, order on assigning the responsible person(s);

• Test operation log or protocol (TO);

• Act or protocol of transfer to pilot industrial operation (PIO), order on assigning the responsible person(s);

• Validation plan, validation protocols, validation report;

• OPE Completion Act;

• Order on launching into industrial operation.

Some of these documents will be prepared by the supplier itself, but it is necessary to take the most active part in this. Advanced LIMS suppliers can provide documentation according to GOST series 34, but strictly speaking, this is not required for laboratories. It is necessary to monitor compliance with formal deadlines and their postponement if necessary. The documentation on implementation should remain in the laboratory so that it can be referred to later when making changes, improvements and revalidation of the LIMS. This documentation may also be needed for accreditation or the next confirmation of competence, since accreditation experts may request it. Before the implementation is completed (or at the time of completion), it is also necessary to issue new documents (procedures) of the SM(K), which will describe the work of laboratory employees in the LIMS.

A very common question is: “Why is it so difficult (expensive) to automate processes in the laboratory?”

The answer is actually very simple. Unlike other areas of activity (accounting, HR, production), a laboratory has many processes. No, not even that — a lot of processes. In many cases, each test method is a separate process, including with branches and cycles. And in each laboratory, even seemingly identical processes are implemented in their own way, and there is no universal solution here. Therefore, normal automation in the form of implementing a program that is customized for all processes becomes very expensive. Well, it is clear that for the rapid implementation of calculations for various measurement and testing methods, it is necessary to use some low-code tools one way or another. Therefore, the best implementation of LIMS will be a constructor application with elements of no-code and low-code.

But unfortunately, not all developers of such programs understand this and continue to follow the paradigm of classical development.