The work performed in laboratories often produces too much data for one person to fully understand in a reasonable amount of time. Reports help extract complex data and turn it into information that can be comprehended easily. Sometimes the data can be as simple as reporting on results that fall out of spec (in which case a dashboard may also be used) or as complicated as reporting on those same results but with charts, subreports (reports within reports), or in another language.
Crystal Reports is the preferred reporting tool in LabWare LIMS, as it is compatible with LabWare out-of-the-box and is one of the most customizable reporting platforms. In this blog, we will share how Crystal Reports in LabWare enables businesses to tailor reports to fit their exact needs, along with how to recognize and avoid pitfalls that may be encountered.
Additional Reading: LabWare LIMS Dashboard – A Practical Implementation
LabWare LIMS allows you to build reports without writing any code. This may be accomplished several ways. A classic approach uses the concepts of Query Tags (QTs) and Access Routines (ARs). QTs and ARs work by allowing the user to build simple filters for the report. Essentially, the AR defines which fields will be filtered, while the QT may provide values to filter by.
For example, if a user wants to generate a report on samples that have been cancelled, then they would have a field defined in the AR for SAMPLE.STATUS and a value in the QT with “X” (the database value for the status “Cancelled”).
Although complex reports will require writing some code (e.g., reports with conditional filtering/formatting), the following steps are all that is needed to generate a simple report in LabWare:
Aside from these steps being a simple method to configure reports, this process can make testing/validating a report much easier because there may be no or limited code involved. Most businesses have strict change control processes when it comes to the introduction of custom code. However, those change control processes are usually less stringent with respect to simple configurations.
Usually, ARs and static QTs aren’t enough to generate the exact report desired by stakeholders. A desired report may need conditional filtering that can be modified by users, and it takes a bit of developer elbow grease to get the job done. QTs can be configured to collect data from users, but if many fields are involved, referencing multiple QTs to sequentially prompt the user probably won’t be very user friendly.
This is where LabWare’s customizable user dialogs really shine. User dialogs prescribe a user interface that can collect user feedback similar to how QTs can, but they can have rules attached to each field that depend on other fields before it (referred to as cascading fields) all within the same prompt. This makes user filtering easier, as it allows users to view all the filtering criteria at the same time with limited choices specific to their needs, which in turn pass variables to the Crystal Report to conditionally display data.
So, what does this all mean? It means that users can generate reports that have as little or as much data as they want. They may even generate multiple report files using a single prompt. Not only are users able to control the quantity of data being shown but also to control the type of data being shown (all from the same report).
For example, imagine a lab tech is trying to generate a report. The system prompts them with a user dialog that asks which filters they would like to apply on the report. On the user dialog, one of the filters could be a True/False radio button with the label, “Display Charts.” Simply by checking “True,” on that filter, the report will now generate charts for the data they selected.
Essentially, a user could generate reports that look completely different, all from the same Crystal Reports file. So how can the same report completely change its appearance based on one filter? One way is through Subreports.
Subreports can be conditionally generated based on the user’s selections. But what are subreports generally used for? That depends on who you ask. Subreports function in much the same way as main reports, with a few key technical differences. They are powerful tools when it comes to configuring a report, and when used appropriately, they can be a great asset.
If a Crystal Report is not configured with efficiency and simplicity in mind, issues often will arise. Sometimes subreports are used to group multiple related reports into the same report. This is usually not recommended because it adds complexity to the report. The issues surrounding that design choice become apparent if changes need to be made to one subreport but not the others.
For example, let’s say a user makes a single Crystal Report with three subreports (A, B, and C), and each acts as a separate report depending on the user’s selection. If a change needs to be made to Subreport A, change control processes may require Subreports B and C to be regression tested. Such regression-testing efforts could have been avoided if the subreports were broken out into their own reports.
Adding unneeded complexity to a report, more often than not, adds to performance issues as well. Using the same example, even if a user only wants to generate Subreport A, having three subreports in the main report can increase report generation time. The main report would still need to bring in data for the other subreports, but simply not display the data that isn’t relevant to Subreport A. Such inefficiencies in the report are solely due to the design choices made during report development in Crystal Reports and could have been mitigated if they were separate reports.
Avoiding subreport pitfalls can be tricky and requires experienced hands. Fortunately, many other features are easy to use, such as generating a report in any language you want!
There are businesses with labs that operate all around the world in multiple languages. This could present issues when sharing reports, but language shouldn’t be a barrier to good science.
LabWare is capable of supporting multiple languages in a single implementation through its National Language Support (NLS) functionality. This NLS infrastructure can work alongside Crystal Reports to enable report generation in any language supported by Microsoft Windows.
For example, in a LabWare Implementation that has multiple languages already set up: If a user has a “Language” field set as English in their user record, then the report would be generated in English, and if the same user switched their language to Spanish then the report could follow suit. This is especially useful in LabWare implementations where users all around the world are using the same LabWare instance to do their work.
Although this is not strictly an out-of-the-box feature for LabWare LIMS, the configuration and static data needed to generate multi-lingual Crystal Reports in a system that already has multiple languages set up is straightforward.
Creating a Crystal Report that interfaces with LabWare LIMS can be as simple or as complex as users want it to be. While Crystal Reports is a powerful and customizable tool, it does have its drawbacks. Inefficient configuration of a report can lead to long load times and poor supportability. Here at CSols, Inc., we have the LabWare LIMS talent needed to build reports that are efficient, quick to run, and representative of the value that your lab generates.
Do you have an existing Crystal Report that you would like to see changed or improved? Feel free to tell us about it in the comments below.