With Wireless Monitoring on the Rise, What Changes in Ensuring Compliance with 21 CFR Part 11?
As wirelessly networked monitoring devices become more popular, many of our GxP-regulated customers ask about 21 CFR Part 11 and how it impacts wireless monitoring. In this blog, our regulatory expert Paul Daniel gives his latest thoughts on a matter that is becoming more important as the use of wireless devices increases in GxP applications.
I don't think Part 11 requires us to do too much different with the addition of wireless monitoring. When it comes to the regulations we should look at what is the real expectation of regulators. In terms of an environmental monitoring system this means that we provide a reliable monitoring, recording and alarming system that collects accurate data, without gaps and errors, and ensure that the data maintains its integrity for its lifecycle. That done, we ask ourselves what specific risks and challenges are posed by a wireless system?
This regulation was first written before wireless monitoring was a thing, back in the mid 90's. Its primary focus was to ensure that the use of a new technology at the time, Electronic Records and Signatures, did not introduce more risk than good old fashioned paper records.
What Part 11 didn't include was the mode of communication – Ethernet, TCP/IP, Wi-Fi, etc. It has been periodically revised, but it hasn't really addressed technological shifts in data transmission methods, maintaining a focus primarily on procedural controls, such as training, SOPs, and review of data and audit trails. Because of this I think Part 11 is more about procedures than technological functions.
Despite this, functions (like the audit trail) and technologies still matter.
I usually break Part 11 down into 10 parts drawn from the sections of Part 11 dealing with "Closed Systems"(because I think most monitoring system fits this category.) (Learn more in this white paper)
- Human Readable Records
- Protection and Retention of Records
- Audit Trails
- Restrict Access to Authorized Users
- Device Checks
- Authority Checks (Different roles to match job requirements)
- Written Procedures
- System Documentation
When I look at that list the only things that seem specifically different with a wireless sensor are #1 Validation and #6 Device Checks. I think I would also want to see #9 Written Procedures, but with specific applicability to the IT side of the security of the wireless network.
So what would I do different for a wireless sensor system with regards to Validation, Device Checks, and Written Network Security Procedures?
Validation: I'd probably add some wireless-specific steps to my IQ, like verifying signal strength and connectivity, with some sort of challenge added. An additional range challenge perhaps. I might also want to see the specific wireless network settings documented, or a verification of such activity, as actually recording them in the protocol might be a security risk (especially if the system was Wi-Fi). I would also pay more attention to verifying the physical location and identity of each device, and verifying that the device is fixed in place. A battery-powered wireless device can get moved easier than a wired one with a power cable.
Device Checks: This ensures that information sent over the wireless network is legitimate data from a legitimate device. We can assume that the risk of someone inserting falsified data into a monitoring device is the same for wired or wireless. However, it would be easier for a non-legitimate wireless device to connect to your monitoring network, since it doesn’t need the physical connection.
Written Procedures: I'd like to see a SOP for how the security of the wireless network is maintained. This is more of a concern with a Wi-Fi system, which is usually using a shared infrastructure (usually the LAN) to connect to the monitoring systems server/database. There are some security concerns with Wi-Fi, that aren't present with other types of wireless (Bluetooth, ZigBee), because wireless uses the same TCP/IP protocols as wired Ethernet – so essentially an exploitable opening to your LAN for a user with the correct credentials. Because Bluetooth and ZigBee use different protocols (not TCP/IP), it is more difficult for a malicious agent to penetrate the wired Ethernet TCP/IP-based LAN through the non-Wi-Fi access point.
But is there equivalent risk of hacking a wireless or wired network?
Common wisdom is that the wired network is more secure. Sadly, there are many other easy ways to send falsified data without hacking a wireless network. Monitoring system connectivity is not the only security issue. Among the easiest ways is to simply move the sensor to a favorable temperature environment, or create a false environment (put an icepack next to the sensor).
Back to Part 11; if we review we find that it does not say: "Do this for your wireless monitoring system because it is wireless."
I recommend that we expand #1 Validation to combine it with an overall quality systems approach. So if you are considering implementing a wireless monitoring system, include requirements for reliability, range, security, etc. in your User Requirements documents.
You do this so that if you choose a wireless system, you have at least ensured that it has all the capabilities and features required for GxP compliance purposes. Once you have entered such concerns in the URS, it forces the Validation process (risk assessment, protocols etc.) to address any concerns that are introduced by the use of wireless.
For wireless systems, simply follow existing procedures that you normally use to implement any computerized system, including Part 11, and you will be on the right track. There is nothing specific to wireless that shouldn't be already covered in the expectations that our IT departments are following good basic GMP with written procedures and best practices.
You can reduce the complexity by selecting a proprietary wireless system where the wireless portion is "closed", meaning only the sensors use that network, and the network protocols cannot be altered or edited by a user. An example of this would be Vaisala's VaiNet system. Learn about VaiNet in this Webinar.