LabLynx KB:SysAdmin - 5.3 LIMS system setup
 |
This is an article specific to the Category:LabLynx knowledge base. Its context outside of LabLynx, Inc may not be apparent, thus why it appears inside the LabLynx KB namespace. |
LIMS system setup
The testing that a laboratory performs is highly dependent on the workflow, standard operating procedures, and business practices that are adhered to. Because of this, LabLynx designed the LIMS test set-up area to be highly configurable in order to meet the requirements of small, medium, and large laboratory facilities. This document continues to discuss setup of the LIMS system, addressing the concept of tests.
Test management
Once sufficient processes and paths have been defined, tests may be created in the system for scheduling and ultimate assignment to samples for analysis. Tests within the system may be used for various purposes such as standard analytical laboratory tests, field tests, subcontracted tests, and/or other results requiring capture in the LabLynx LIMS database.
Note: Prior to creating a test, the user should be familiar with master parameters, paths, processes, labs, locations, and QC templates.
A test is any activity that is processed in the lab (or by a subcontractor) where results are to be tracked in the system database. The purpose of a test is to allow for the gathering of lab data for an entered sample either through scheduling (if applicable) or normal sample receipt.
As an example, a routine lab test example may be "pH." For this example the test may be named "pH" and have a path assigned to it with a single process called "results entry." Within the test a single Parameter "pH" may be assigned from the master parameter list. Should any additional parameters be required for data capture they may be added to the test as well (perhaps, lot number of buffer solution, etc.)
The design of the test definition area allows for significant versatility in the workflow of test entities. This versatility primarily revolves around the process/path assignments made to tests as described in the sections above. Through the Test List the user is shown a list of currently defined tests in the system (by default, the screen displays only active tests; however, a user may filter for inactive tests as well):
The user may edit an existing record simply by clicking the URL of the desired record in the Test List. The user may also create a new record in this list by selecting the New button, which will redirect to the Test Configuration Details screen:
From this screen, the user defines many aspects of the test type. Fields in bold are required. The various fields are explained below:
| Field | Description |
|---|---|
| Test Name | This is the name of the test as it is to appear on work lists and inter-laboratory reports. |
| Version # | This is a system-assigned integer value incremented by one as new tests are created. |
| Report Name | This is a user-defined value for the name of the test as it is to appear on final results reports. |
| Location/Department | This is the location or department assigned to the test. |
| Sample Type | This is a user-defined value for the purposes of referencing the appropriate methodology. |
| Path Name | This is a user-elected value from the list of existing paths in the system. |
| Test Ref. Methodology | This is a user-defined value for the purposes of referencing the appropriate methodology. |
| File Name | This is a user-defined value for the name of the test file. |
| All Users | All system users assigned to the Lab have the capacity to view the sample, provided that that they are also assigned to the path processes. |
| Sig. Fig. Default | This is a user-defined value for the number of significant figures that will be applied to the results for test parameters during rounding. |
| Resolution Default | This is a user-defined value for the number of places to the right of the decimal point that will be applied to the results for test parameters during rounding. |
| Std Price | This is the base price of the test. |
| Published | This determines whether this test is published. If it is published it cannot be modified. |
| Active | This is a user-selected flag indicating that the test is now active or in-use. |
| Description | This is a user-defined value for the description of the test. |
Specific points
Some specific knowledge items must be brought to the user's attention at this point. The following will break down general items that the user should review as each test is created/modified in the system.
- 1. The Location/Department selection list determines what system location/department combination will be responsible for the results entry for the processes associated with the path for the test:
- 2. The Path Name field for the test defines the processes that are required to perform a test. Please keep in mind that more processes in the path means more interaction with the system for users. The path concept was developed to allow laboratories to mimic their current sample testing workflow in the system. In some cases, however, it may not be the most efficient use of the system. A great amount of thought should be given to the path that is assigned to the test:
- 3. Once published a test cannot be modified except with respect to test parameters. The user may create a new limit set for any currently assigned test parameter. The limit set is the group of control limits assigned to the parameter, the detection limit, and the quantitation limit. Parameters may not be added to or deleted from a test.
- 4. Should it be necessary to modify information about the test or add/delete parameters, the user should be aware that it is possible to create a new revision of the test or simply copy it and create an entirely new test. The difference between the two is primarily that a revision to a test is related in the database to the previous version. Primarily this is done for scheduling purposes and/or any other area in the system that uses tests for reference purposes. For example, if a sample is scheduled for certain tests and one of the associated tests has a new version created for it, it will not be necessary to assign that new version to the scheduler. The system uses the established relationship to always assign the most current active version of the test. If the user copies the test, there is no relationship between the newly created test and the test it was created from, so anywhere in the system where the test was used for reference purposes will require modification.
- 5. The way that the system monitors which system user may enter results for a test is determined in several ways. First and foremost, the setup user should double-check that any system user they wish to grant access to this test has been assigned to the department in the security set-up area and also that they are associated with the process (either through the All Users check box or by individual user assignment).
- Once the location/department assignment is applied to the test, the user setting up the test must now determine if the Allow All Users flag is to be checked. If it is checked, then any user associated with the path processes for that department/location combination will be capable of entering results. Alternatively, the setup user may wish to minimize the list of users further still. In this case, the above conditions still exist regarding process and department assignments:
