I want to choose the right software for my research but it's not the easiest of tasks!  
Jean-Gérard Napoleoni, Andreas Theodorou, Jonathan Pitcher

In recent years, preclinical research has evolved considerably to exploit the benefits of wireless communications. The most obvious manifestation has been the advent of telemetry systems (invasive and non-invasive) providing higher quality data generated by less stressed subjects. Software has also had to adapt, to efficiently and reliably handle increasing amounts of data associated with continuous recordings. The upward trend is set to continue as installations become larger (Adapting Telemetry Setups to Large Populations Animal Lab News, October 2007 6(7): 27-30) and video becomes commonplace. In this context, choosing acquisition and analysis software really able to enhance your research productivity is not an easy task, especially when one of your key objectives should also be to have an open system, avoiding being tied to a single vendor.

wireless means telemetry

Wireless technology has made possible the ability to reliably transfer high volumes of data from a freely moving animal.

Advantages associated with these techniques are obvious and well known: longer and better quality data obtained from less stressed subjects.

During the last 6 years, the advent of non-invasive telemetry has taken us a step further, making long and high quality data available from animals that have not undergone surgery.

Telemetry provides continuous data for hours and days. This is wonderful from the scientific point of view since the quality of information that can be derived from such long recordings is greatly enhanced, as compared with, for example, one-minute ecg recording snapshots which, until only recently, were the rule in toxicology.

Telemetry hardware is so different form previous technologies that it has a powerful impact on the software (that users should choose and use). Thus, telemetry systems need to be integrated into your IT structure(s), to be operated with a powerful software package, a software platform that deals with the issues created by telemetry systems.

data volume has exploded

The exponential increase in amount of generated data is one of the outcomes of telemetry. The pattern is set to continue as synchronized video recording becomes more widespread. The demand is driven by a simple but persuasive rationale: what is better than an actual image to assess animal behaviour when an outstanding cardiovascular or respiration event is detected in the analyzed data?

Recording from one subject will typically generate from 100 Mb to 150 Mb of physiological data, up to 1.5 Gb if video is added. For a study of 40 subjects, each of them undergoing 6 to 8 recording sessions of 24 hours, the total amount of data will range from 30 Gb to 400 Gb.

If you still doubt the complexity of the data structure, remember that during that same study, you may well be recording up to 6 or 8 traces of physiological data per animal, making a total of 1500 to 2500 traces.

think big

If recent years are a good indication, there is every reason to believe that the volume of data generated by wireless systems will continue to increase:

• As indicated above, video recording, which initially met with mitigated interest from users, is now becoming widespread and might become the rule in a few years.
• More physiological signals are being recorded from each subject. Vendors are striving to meet this increasing demand, which is underpinned by a simple economic argument. The cost of adding one or more physiological signals is marginal compared to the amount spent on the animal facility, animals and skilled personnel.
• This is also exactly where the 3R's - the replacement, refinement and reduction of animals in research - lead us: produce more from less.

The upshot is that when deciding how to dimension your project, you should ensure that you can accommodate significant increases in recording length and volume.

record all, analyze all? changing analysis needs

Confronted with huge volumes of data, pharmaceutical companies and CROs have had to make difficult choices about how to analyze them. Three main solutions predominate:

• perform scheduled recordings, for example 5 minutes every hour, even though continuous data is provided by the telemetry system. This seems counter-intuitive but it nevertheless represents a huge improvement over snapshot recordings, done in the past, and it limits the volume of data. There are therefore sound reasons for devising SOPs along these lines.
• record continuously, but limit analysis to specific time points within the recording. This is a compromise, as all the data are available if it is one day required to look at the whole recording in more detail.
• systematically record and analyze all data. More and more users are adopting this practice in the belief that the extra efforts made at this stage are justified by the superior information gathered earlier on in the drug development process. They also feel that now that the technology allows continuous recording and analysis, it is difficult to explain and justify why the investigation should be kept partial.

real-time versus off-line processing

With the advent of powerful computers, it became possible to perform real-time data analysis. Not only could users see the signal being acquired and recorded in real time but they could also watch how fiduciary points were being positioned on the traces, allowing them to check that analysis was proceeding correctly. Real-time data analysis also provides the possibility, if required, to adjust analysis settings and immediately see their effect on the newly analyzed traces.

Now that real-time is taken for granted and the novelty of seeing traces and analysis on screen in real-time has worn off, many users realize that, although they run long recordings of many hours on multiple subjects, the last thing they want or need to do is to watch the signal and analysis while they are being performed.

On the other hand, most, if not all, users will tell you that they never trust their system to the point that they would not look at their data, and send them directly for post-processing or for direct inclusion in study databases.

This is not so much because the telemetry and software tools are not performing well. It is because, very often, the data points of greatest interest are those where the signal took on an unexpected shape, or when the produced derived data started moving away from standard values.

And these difficult data zones are where human expertise remains indispensable for validating or editing results proposed by the software. Keep in mind that currently, and probably for many more years to come, when a human expert has difficulty distinguishing, for example, an ECG arrhythmia from a normal complex, software tools, at best, indicate an abnormality but are unable to qualify it as 100% reliable.

In view of this, well designed software will be able to establish easily accessible lists of all "difficult" data zones, allowing fast and efficient examination and qualification of each of those potentially interesting events.

all software solutions are not equal

Using a powerful and user-friendly development environment, any engineering student is now capable of developing a data acquisition and display tool in just a few days.

But although this is where it all begins, recording data is only a minor part of state-of-the-art software tools needed to acquire and process telemetry data.

At a minimum, complying with Good Laboratory Practice rules requires a number of modules and functions such as audit-trail, access control, electronic signature. 

Today, many software applications share a set of basic features. All good products on the market will be able to record several traces, at independently adjustable sampling rates, while allowing you to enter event markers. These products also analyze most standard physiological signals (respiration, cardiovascular, electrophysiological, etc.) from which they will also derive the most standard parameters.      

The differences will be in the details and this is where making the right choices is crucial. Some of the questions to consider, to give just a few, are the following:

• Can you easily review the data, and are there tools to allow you to go directly to areas where you must check and confirm analysis validity?

• Once you decide that some data points require editing, how easy and fast is it to perform these edits? Are these edits fully traced as required by GLP rules?

• Is the data structure simple? In particular how many data files do you produce per subject and recording session (clearly 1 file per subject is optimal; having too many is at, worst, a source of errors and, at best, time-consuming when handling study data) ;

• How smoothly will you transfer the produced data to your in-house database or LIMS?

telemetry, from hardware to software, should be thought of as a platform

Working in the life sciences is a rewarding endeavor; the combined ideas and efforts of several talented chemists and biologists contributes to the development of new drugs. However, it is also a productivity race, and it is essential to produce thorough and reliable results fast.

This brings up another key point in your decision-making process: how many work hours from data recording to final archiving? Try to evaluate the overall time that your complete data-processing cycle will require from your team and yourself.

Some of the key steps to evaluate are the following:

• Daily system set-up: how easy and fast? What type of daily or weekly recalibration and readjustments are required ?
• Can you automate tasks such as the recording protocol, event creation, etc?
• Can you perform batch analysis, eg the automated succession of analyses performed on all files of an entire recording session or study?
• Can you easily set the system to produce a more thorough analysis? It is always more efficient to perform a more in-depth analysis once (even at the cost of a slightly longer processing time) than to have to perform it many times over, after successive setting changes.
• Can you easily and rapidly review the analyzed data, focusing only on the zones with unusual or difficult data?
• How fast and easy is the final transfer of data to the study archive?

You could easily argue that the answers to the above questions would only become evident a few weeks after purchasing the system. Our advice therefore is to ask for a trial. Vendors are often obliging in this respect: at no charge or at a reasonable fee to cover labour costs, they will accept to let you try a system for a number of days or weeks and will provide initial installation and training services to make this trial worthwhile.

This is by far the best way to make sure that the major investment you are considering is the one you need.

telemetry means digital

Digital is great, but do not expect it to be simple. In the past, all data were analogue, i.e. signals produced by hardware devices translated into an electrical signal of varying voltage, usually in the -10V +10V range. In these good old days, just about any piece of hardware could be made to communicate with any other piece of hardware or hooked up to any recording software.

With the advent of the digital age, there were many good reasons to switch to digital data production and handling. Systems became more sophisticated: carrying greater volumes of data within the same "pipeline"; ensuring that the origin of each data packet was safely traced; and avoiding situations where changes made on systems settings went unrecorded.

But going digital also came with a partly hidden cost:

• linking two hardware components together or getting one piece of hardware to send its data to a software module has often become an impossible or, at best, very complex task. Unless, of course, both items have been specifically designed to talk to each other.

• when you ask the vendor of any of these components for information on a data format or communication capabilities with third-party systems, the response will often be far removed from "Yes certainly", to put it mildly!

You thus very often end up in a situation where transfering data, either real-time or off-line, to another system is close to impossible.

choosing a vendor

Once you have chosen the best product and have started using it, it is very likely that ideas will crop up about additional analyses that could be done. Posters or talks at scientific shows will suggest new ways of extracting valuable information from the data. Your system will probably not be able to immediately accommodate these new methods and your only solution will be to ask the vendor for an update to include these new features.

This leads to the following points to consider when choosing a vendor:

• Make sure that you check the vendor's track record for technical support and reactivity in providing new features.
• Ensure that the ability to request new features is sold as an individual option or is covered by a maintenance contract.
• Ensure also that any update comes with detailed information which help limit the required revalidation work to reasonable "change control" procedure.

If validation is taking too much of your internal resources, you may think of subcontracting it to your vendor or to a specialized third-party. Since they know the product already, vendors who offer this service on their products are usually more cost-competitive than third-parties.

your options, and the system you buy, should always remain open!

Obviously you are only working with the best vendors and their products are excellent.

But one day you hear that some researchers have developed a very clever algorithm, or your colleagues from another lab tell you how fast and efficiently they analyze their data with the new software they just purchased.

How sad and frustrating then to discover that there is no way to make your data readable by any of these potentially very efficient new tools you have just heard of.

From a broader perspective, should you allow your favourite vendor to feel that you have little choice than to stay with him. What effect do you think this will have on prices ? Do you think this is the best situation to be in if you require product improvements or fast support and service ?

Our strong advice here is that you must make sure that, when you purchase a system, your vendor will provide you, immediately or at your first request, and at a predefined and reasonable cost, the necessary tools to make data from his system available to third parties.

In computer science jargon, these tools are known as converters or DLL. What counts is that they should let somebody else access the data and key information (physiological signals, of course, and also event markers, calibration values, etc).

Compulsory system openness is most probably something that the FDA, or the scientific community (for example Safety Pharmacology or Toxicology societies)  will soon actively support and promote.

But in all cases this is a wise policy, and it is your responsibility to make sure that your options remain open!