The Demand for Greater Data Integrity and Security Drives Software Development

A long-standing issue for the laboratory informatics industry has been managing and securing its data in order to be able to verify that the data has a high level of integrity. Reasons for this effort include the following:

• To ensure that the data researcher’s reference for decision-making and calculations is correct.
• To satisfy outside stakeholders, such as regulatory agencies, that the data is properly managed and represented. In the case of medical research, this also includes managing patient privacy by limiting access to personal data and records.
• To support other efforts, such as proving patents by providing the supporting data.

Whether you’re looking at a LIMS, ELN or another system, large or small, ensuring the integrity of the data is important for these reasons.

Securing data against changes

Most RFPs (request for proposals) that come from regulated companies to software vendors contain questions concerning how the system will secure the data. Potential customers want to know that the data cannot be changed by the users of the system or viewed by the wrong people. This is where a discussion of data integrity usually begins. Although data integrity requires a good process, there are often many technical issues to resolve in order to maintain the integrity of the data as well.

Most software offerings these days do allow users to protect their data from direct changes. Of course, this is one of those areas where one is also required to create good strategies and practices to support this. For example, since much of our data now sits in commercial databases, there are layers of protection. The software application itself will prevent users from changing data through the application. Even if the application can be modified by the customer, the actual software and data protection strategy should not be modified in a way that would allow unwanted changes. The customer will need to create and manage all the appropriate security measures surrounding the database, so that the application has access to read and write to the database but does not allow users to connect to the database and change it directly. There are many other factors as well, such as ensuring the clocks on the various systems providing data are kept in sync and that the date/time stamps are properly managed to ensure the highest integrity and to prove that data was entered or modified when the system claims it was done. Beyond this, there is the issue of secure data centers, which offer yet another layer of security.

These are examples of the ways in which data must be protected. It is not enough to have an application that supports this type of protection; one must also have a strong overall process of security.

Proving ownership of changes

Over the years, software vendors have focused increasingly on ensuring that data entries and changes are absolutely linked to the correct person. Although many systems have done this for a number of years, stricter rules are now being applied.

In the 1990s, 21 CFR Part 11 (the U.S. governmental guidelines on electronic signatures and electronic records) became a big talking point. Everyone wanted to know if particular pieces of software were “21 CFR Part 11”–compliant. As many of you already know, software is not compliant. It has to be written to support compliance if you want to have a compliant installation of it, but the way in which you use the system is what actually makes it compliant or not. This is similar to the physical management of data, where part of the responsibility for securing the data lies outside the software. As with the physical security of the data, an installation can be made noncompliant by improper use and maintenance.

The electronic move continues

The goal has long been to make data more electronic for many reasons, but proving ownership has been an important driver.

Even though 21 CFR Part 11 has been around for many years, we are still revising the way we handle electronic records and electronic signatures. Thus, as new technology comes about and as we learn more about the pitfalls of the technology, we are more capable of addressing these types of issues.

Electronic signatures and digital signatures are one example of this. If we look at the way we tried to manage these back when 21 CFR Part 11 came out in the 1990s, we see a vast difference from the way we handled them in early 2000. And in the past few years, we have witnessed even more changes to them.

For example, early on, some software vendors instituted electronic signatures in their software. But as standards changed, they have continued to modify the way these options work within their systems in order to best prove that the person changing the data is truly the person using the account. Additionally, when we approach the issue of digitally ensuring that the person is the person they say they are and attaching a true digital signature, we continue to wade into complex technical, procedural and legal territories. Consequently, we’ve seen at least one organization pull together a standard model for approaching this: the SAFE-BioPharma Association (http://www.safe-biopharma. org/). For those who think this has all become entirely straightforward after so many years, I need to point out that if it was so easy, nonprofit organizations such as SAFE-BioPharma would not have been created solely to address these standards.

But even SAFE-BioPharma’s standards are far from ubiquitous. Companies pay to join this organization in order to benefit from these standards and, the last I heard, although its membership is growing, SAFE-BioPharma is still far from representing the majority of the biopharma industry. Nor does it begin to address the issue that other industries and organizations have with this very same topic, which explains why, for example, HL7 (http://www.hl7. org/) was created specifically for handling health records.

Comfort level versus technology

While technology has continued to progress, if we consider how long we have been trying to make our data records and signatures electronic, one might think that our progress is extremely slow. However, corporate lawyers have become more comfortable allowing their laboratories to start moving away from manual signatures only recently, and the laboratory informatics community as a whole seems more comfortable with the idea only now as each step slowly gains acceptance. Even if technology and the understanding of it had moved along more quickly, we probably would not have been able to embrace it any more quickly, due to our general lack of comfort with and understanding of the issues.

Are we done?

As long as the topic of “electronic signatures” remains an important one, it isn’t finished. Technologies and strategies that we take for granted, that are no longer “hot,” are the ones that we have worked out to the point where they are probably reliable and straightforward. Considering that we have not stopped talking about electronic or digital signatures for a number of years, I predict we still have a few years to go before we can rightfully claim to have it all figured out, although that doesn’t stop us from making that claim year after year.

And, as usual, there is nothing to prevent companies from having bad practices that undo what good their new and “compliance-capable” systems might provide, nor, in some cases, prevent them from modifying these systems to the point where they allow the very things they were meant to prevent.