I want to start out by saying I’ve been reading this group but never posted before, and I’ve learned a lot by just reading the topics and replies, and I’m hoping that I can get some guidance for an issue I’m dealing with now.
I work for a small software consulting firm and we’ve been asked by a client whether we can help them with an automated workflow process that involves 21/11 compliant electronic signatures on document approvals. They have a validated process, and the way it works at present is that users logon to a website, review the material, indicate approval. Then they are prompted for their userid and password to authenticate and authorize their approval.
I’m having some trouble understanding what it would take to do this if the user is on a Blackberry or an iPhone or some other mobile device, so that this process would still meet the 21/11 standard. I would appreciate any advice any of you knowledgeable folks might offer.
Interesting question, as i understand they will be logging into the website through a handheld device in order to use their electonic signature.
What is the difference if they log into a website through a PC or a mobile device?
As far as I can see there is no difference as long as the security/login aspect of the application has been fully validated and tested.
Perhaps as part of the protocol include a user loggin into the application using a PC and a mobile device and make it clear that there is no difference between both access points.
I dont see a major problem here as they the only difference seems to be the users logging onto the web through a mobile device and not a PC.
I would be interested to hear more opinions on this.
This comes down to do you consider the system an open or closed system.
If it is open then you have to follow the rules for that. At this point
I don’t see much of a difference between a Blackberry and a wireless
laptop. The big concern is that the communication is secure.
I have heard that you can snoop these signals and given time break the
encryption, but it sure sounds like a hassle to me. Given the huge
volume of wireless traffic, how likely is it that someone will try to
hack your connection.
There are other people on this list that know more
about this kind of security than I do, but it seems to me that this is
another case where a risk assessment is in order.
As long as the signature is adequately linked to the information (record)
and meets the non-repudiation requirement, it should be fine. That sounds a
lot easier than it probably is because the non-repudiation requirement alone
would require qualification for security aspects as well as authentication.
Since you already have signatures being applied to the record via the
internet, we will assume that the link is adequately estalished.
As has been said several times here, you need to determine the process
(proccess and domain mapping), determine risks (risk assessment), and plan
your validation strategy (IQ/OQ/PQ) accordingly. Basically the same route
you would take if you were using any device that accesses your system and
data from points external to your domain (such as the internet).
The simple first step is to ensure the application is mobile browser capable - you are talking about a wider array of browsers in the mobile world than in the PC one
The iPhone single threads its applications - so you may end up annoying the user if he has to log back into the service every time he opens his browser (even if taking a phone call while using the app). The Android units run apps in the background so you could end up with the opposite problem of users never logging out. And Blackberrys compress everything and convert to their own presenter formats so you need to be be aware of that…the windows phones are fine (when they work).
In terms of tablets - the same applies as technically its the same OS and Browsers with a few tweaks.
Best application for online testing and validation =
Best accessory to give your mobile workforce to be properly productive =
Best place to get someone to “Smart Phone” your apps = www.getacoder.com
Best place to get involved in promoting paperless systems in Life Sciences = www.obdis.com
Regards
Alan
Declaration: I am directly or indirectly involved in all of the above web sites
There are some important points that may prove tricky…
Validation and maintaining a validated state is all about control. This means that any potential updates need to be reviewed for potential effect on the validated state before installing and testing… Most mobile devices update themselves and this would prove to be an issue.
part 11 requires actuall device identification… this would mean a server checking the imei # of the phone and performing some sort of a handshake before accepting a connection… Im not sure if this has been considered. To this end you will need to decide on a make and model and lock users into that make and model… also this will need to go to the OS/firmware level.
There needs to be some system whereby your organisation reviews sofware / firmware updates before installation on the mobile device… this is would be a QA system but run by IT in my estimation. people are required for this. microsoft updates windows monthly so you can image that once a month it would be hectic to assess the effect a software/os update will have on your validated state
if the mobile device is used remotely your system is by definition open, as the data you are sending will have to travel over third party hardware such as internet service provider servers etc. so you need to encrypt the data. im not a software developer so I cant give any more info on this.
regarding logins… the regulation states that if there is more than one approval per session is being done only password needs to be entered. if there is a break in the session both user name and password need to be entered.
sessions should be programmed to autologout after a time period. This time should be set to a maximum of 8-10 mins (based on direct experience of dealing with the FDA)
Also some browsers keep the user session active when the browser is closed. this is not acceptable from the regulations point of view. EG if a user is logged in on their iphone and is interrupted with a call and needs to close the browser app. they should be forced to log in again after hanging up the call. there is no clarification from the FDA that the definition of the word session aligns with the way it is used with browsers… unfortunately!
finally the last thing I can think of is password complexity and ageing needs to be enforced from the server.
thats all… sorry about the length of the mail… if anyone has more info let me know!
A brief point - when using an iPhone, iPad, Android device etc then there should be little if any difference connecting from a LAN PC if you enforce use of a suitable VPN. If you really need extra identification then there are other device IDs available a mentioned in the post above.
Also, with regards to updates, I wouldn’t necessarily agree that mobile device would be updating themselves. Firmware normally still requires connection to a computer and updates could certainly be reviewed by yourselves or IT if required, and there is plenty warning of major changes to iOS/Android anyway. Also, if rolling out an app instead of using the device’s built in browser, any updates are going to be controlled by, or at least have involvement from yourselves, before they are made available (whether that’s an over-the-air update or via computer). Another way to look at it is the situation with your desktop PCs/laptops - whatever version of Windows and your browser presumably meet a minimum requirement for whatever systems you have, but are they validated? If not, then why validate the mobile device OS/browser?