Does requirement to validate QMS software rule-out cloud-based apps?

Curious:
The just-released ISO 13485:2016 will require vigilance regarding validation of QMS software.

I'm wondering to what degree this would rule-out using cloud-based applications?

We've been finding using shared, cloud-based applications such as Google Sheets to be a useful tool where everyone can access, contribute. Also invaluable is that version-history is automatically maintained, including traceability to particular accounts and timestamps when changes are made... a very-handy, free tool!

But, as far as I can tell, there is no way to see (let alone control) the version of Google Sheets. Because it is cloud-based, I think Google just automatically applies patches to their software...making it hard to justify it being validated.

Any thoughts?
MM

 

Validation of software related to production and service provision has always been there. FDA has always said validation also applies to execution of the QMS (process as well as product). So I don't think the expectation to validate is particularly new. (I haven't read 13485:2016 yet.).

All such software validation should be risk based. If you uploaded data to a cloud app for quality calculations to approve product release, your risk is higher than for using a schedule management tool.

If you can't control the releases / updates then you should probably have some monitoring in place to detect changes. Depending on risk, you may need to re-validate. In you case, it sounds like risk is quite low so maybe you can justify not doing much.

I don't think it would be a defensible position to just say that since it's in the cloud, validation is not necessary.

 

I think we can all agree this would not fly.

My concern is with respect to the fact that Google automatically applies updates, and often - and this is completely outside our control, and outside our ability to do any sort of assessment as to how their patches may or may-not affect our intended uses.

Google Sheets, as with MS Excel, can and does do automatic calculations - the results of which we use to evaluate our system (e.g. calculating elapsed time, number of records in a particular category...etc.).

On the one hand, this could be assessed as a critical element of the Quality System (because it is a major feedback & improvement mechanism). ...but on the other hand, what are the chances that a Google update to their Sheets app would break the basic spreadsheet features (add, average, stdev..etc.) we make use of? I'd personally assess this to be extremely unlikely, but have no objective evidence for such a claim.

 

I am not in medical, nor am I familiar with medical regulation. That said...

"this could be assessed as a critical element of the Quality System"
"Google automatically applies updates, and often - and this is completely outside our control"
"outside our ability to do any sort of assessment as to how their patches may or may-not affect our intended uses"
That sounds like a dangerous mix there...

I agree that the risk of publishing software that can't add is fairly low...but "critical" doesn't mix well with "Outside our control" and "outside our ability to do any sort of assessment".

...though there is little in the world that is indeed unable to be assessed...it becomes a cost benefit decision on the number of times you would have to check if the software has been updated and do a re-assessment.
You can assess the software, and likely did so before using it. The question is not "can we?"...it is "how often must we?"

My two cents...

 

My line of thinking aswell...to which I'm reaching the unfortunate conclusion that cloud-based solutions like Google Sheets may potentially be unacceptable to use (because validation schedules are either unfeasible or very difficult to justify).

A shame, because it's such a useful collaborative tool...

 

On the other hand, the requirement is to validate the application of software, not the software itself (although sometimes you will conclude that you does need to validate the software itself to validate its application).

 

That's an interesting distinction, however in practice I don't see how the two (application of software versus intended software function) can be treated independently.

It'll be interesting to see how this increased emphasis on validating software (application) will be regulated, and what burden this will be on business. Personally, I worry that it'll end-up restricting the options available to manufacturers & developers, as the cost of continually (re)validating becomes a major consideration.

We're likely to see (as we already are) some "industry-standard" software packages emerge as all-in-one solutions. Unfortunately, for small business, these packages are (currently) prohibitively expensive. Many such companies (mine included) have opted instead to use a variety of free/inexpensive solutions for particular tasks. If every one of these needs a procedure and schedule for validation, then it's going to be a tremendous burden on companies presently employing several software solutions.

 

getting back to the root, whether in medical or outside it, the point is to verify/validate that the tool you are using to do a job actually does the job you think it does.

In my mind, a change to the tool requires verification that that change did not alter whether or not the tool does what you think it does.

Doc storage, measuring length, alerts, statistical analysis...whatever...how do you know that the tool does what you think it does...is that not the root?

 

I think the "root" is an indisputable principle.

As I say, it remains to be seen what kind of evidence is acceptable...and the trend seems to be towards increased requirements and scrutiny?

What I'm pointing out with respect to cloud-based 3rd-party applications is that there will be a lot of factors outside of your control or ability to analyze - and hence they're very difficult to validate, or unfeasible justify validation schedules.
Does this potentially prevent/deter companies from adopting these well-known, ubiquitous, and cost-effective solutions?

 

In all cases? No. There are certainly cases where the risk can be justified. In your case, assume some change occurs with the software that breaks whatever you're doing. What is the potential for it going undetected? What is the potential for it creating a hazardous situation? I think those questions will drive the level of control applied. If there's high risk and you still want to use the tool, you may need to step up vigilance (up to checking the version prior to each use and then suspending use until assessed if a change is identified).

 

Admittedly, the tools are used for documentation only - not directly tied to quality of outgoing product - so is there "the potential for it creating a hazardous situation"? Not really.

Ultimately, it remains to be seen how this development of increased scrutiny on QMS software validations gets interpreted and enforced.
At this point, I'm expressing a concern, because I'd hate to build my QMS to be heavily dependent on cloud-based solutions, only to be told that our level of vigilance is not adequate.

At the end of the day, there's a certain degree of faith in the software you choose. I choose Google because I have a certain degree of trust that, despite the fact they issue patches frequently, none of these will affect the basic functionality of their spreadsheets. Can I prove this? No. ...but do I have reason to trust that I shouldn't have to re-validate their Sheets app every time there's a patch? Absolutely.

 

You have to develop your QMS with the solutions that are required to fulfill requirements, including regulatory requirements. If a cloud-based solution does fulfill those requirements, that's ok.

The problem I see, and you may be inferring, is that a lot of those solutions are created to be used by anyone, anytime, and are not focused on specific requirements of specific fields, and thus may not be easy to fullfill those requirements with them. Google is an example, their solutions are created to be used by anyone in the world, and that's their wish. They did not create a solution to fulfill specific requirements.

But in this case, it's not that the requirements are too much, the fact would be that these solutions are not good solutions when you take into consideration the specific requirements of your field.

 

A quick internet search turns up this link, from FDA:

http://www.fda.gov/ScienceResearch/FieldScience/ucm174286.htm

So that is related to the pharma industries, but the principles are the same and quite straightforward.

Although I do notice that last bullet point - how often is periodically?

 

Just a note, not really directly on the OP topic, but on XL protection...

Lock the spreadsheet, password protect it, whatever.......drag and drop still breaks it.

Drag data from one editable cell used in a formula to another editable cell used in a formula...then look at those locked formulas...they changed!
I have not yet found a way to protect a sheet from drag and drop...

 

Well snap, I never noticed that.

As a matter of fact, I'm going to pretend that I never even read that.

 

OK, back to cloud-based validations. Regardless of where the hardware and software reside, you're still required to cover all of the bases. That means you need to cast eyes on the all the IQs and OQs you would have/require if you owned the software. In fact, it's even more important that you do that if you don't own the software and it's being provided as a service. You should at least make a list of the documents you have reviewed, their titles, dates, etc. because you're surely not going to be getting copies from the software developer.

You should also have a software vendor assessment form that includes questions for cloud/internet/based software, such as:

Hosting Provider and Data Location:
a) Who is the hosting provider?
b) Where is/are the hosting location(s)?
c) What type of infrastructure is used?
d) Where is the primary data being stored?
e) Where is the backup data being stored?
f) What type of virtualization software is being used?
g) What type of network bandwidth is available (min 100 Mbps)?


Data Access, Security, Segregation and Encryption
a) Is it a dedicated or shared environment?
b) If it is a shared environment, how is the data segregated from other shared environments?
c) What type of data architecture is implemented? Diagrams?
d) How is security managed in the shared environment? What controls are in place?
e) Who has access to the infrastructure, hardware, software, and data?
f) Please give specific information regarding the roles and responsibilities of administrators, profiles, and hiring practices.
g) What application and data access audit logs are available? How often can we get this?
h) How is the primary data encrypted? What encryption schemes are used? Who has access to the decryption keys? How often is this tested?
i) How is the backup data stored? Is the data in raw files or encrypted format?
j) What type of investigative support is provided in cases of breach?
k) If your company is acquired, sold, or dissolved, what options are available to Ranir to get the data? Costs? How is the data wiped out of the environment?
l) Are your systems subjected to penetration testing?
m) If the answer to the above is “yes” can we get an annual report of the penetration test results?
n) Is penetration testing performed by internal personnel or outsourced?
o) When was the last penetration test?
p) What were the results?

Certifications
· SAS 16 Certification
· SAS 70 Certification
· HIPPA Certification
· Other Certification

Identity Management, Security and Single Sign-On
a) What type of identity management solution is provided?
b) Can the SaaS application be integrated with an existing Identity Management system?
c) What type of user security, authentication and authorization options are available?

Business Continuity and Disaster Recovery:
a) Do you have a comprehensive Disaster Recovery Plan?
b) Do you test your Disaster Recovery Plan on a regular basis?
c) Does your Disaster Recovery Plan pass your DR tests?
d) What type of business continuity and disaster recovery options are available to Ranir?
e) Is this part of the standard service?
f) Where are the disaster recovery data centers located?
g) If the primary center is down, how quickly can the disaster recovery environment be made active either in the primary or disaster recover data center.


Damn, I sure miss the Elsmar Cove Forum!

 

pbojsen: while I appreciate the exhaustive list, how much of this information do you think would be disclosed by, say, Google or Apple? And even if they were to disclose, I question how valuable the information would be for two reasons:
1. Scale. These organizations are so huge, that a question such as "where are the hosting location(s)" would just yield a whole tonne of distributed systems, which doesn't help very much.
2. Change. These organizations are always making changes. Even if you got the answer to one of these questions one day, there's no guarantee that it'll be the same a week from now.

Don't we all...
...but this forum is good and growing....just have to give it time...