Off-the-shelf SW S.O.P. for non-product QSR regulated and non-regulated applications

[dendel]

Could someone provide or reference a sample SOP (or policy) that governs the acquisition, testing and usage of Off-The-Shelf SW applications that are NOT directly used for medical device products, but still may be subject to QSRs, and (the same SOP) would also cover applications that are NOT subject to QSR's?
Both types of apps may typically be found in a med device/business environment. Is there one SOP that covers all?
thanks.

 

[yodon]

Re: Off-the-shelf SW S.O.P.; for non-product QSR regulated and non-regulated applicat

Might help to clarify things a bit. There's a wide array of types of software that I would consider 'subject' to the QSR. I'll try to be brief (but in doing so, may miss some stuff). Note: being subject to the QSR and "acquisition, testing, and usage" are quite different.

1) There is software used in the construction of software (e.g., compilers, IDEs, etc.). I would consider these subject to the QSR since they directly affect quality. If uncontrolled changes are made (patches, revision upgrades), you would not be able to re-create a particular build. We have typically not validated these systems with the rationale that the output IS 100% verified (or at least reasonably so).

2) Software used in support of software development (e.g., code repositories). Since these 'touch' the software and have change tracking concerns (security), they are subject to the QSR and probably should be validated (mostly from the perspective of change tracking and security, not general functionality).

3) There is software used in support of design (Solidworks, etc.). These, too, are subject to the QSR since they directly affect quality. These might need to be validated since it's likely the electronic records kept by the systems will be the official record.

4) There is software used in general support of the design effort (e.g., problem / issue tracking tools). Clearly these are subject to the QSR but depending on how you use them, may or may not require validation. (This point is argued ad nauseum in a variety of formats but so far my approach hasn't been cited as inappropriate - so far). I have always used these as just a means to print the final paperwork and so I don't validate. A very rational argument can be made that the electronic records may still be used (e.g., for tracking and trending after closure) so you have to decide for yourself. A risk-based (and documented) decision helps.

5) Software that is incorporated in deliverable software (libraries, protocol stacks, etc.) are clearly subject to the QSR. Some level of validation beyond saying it's sufficiently tested in the product testing is probably warranted (assessment of open issues, for one).

6) Enterprise level applications (MRP, ERP, etc.) are subject to the QSR as they touch various aspects of quality. These are almost always validated.

7) Enterprise level applications that DON'T touch quality (payroll systems, HR systems - that don't manage training records!!, etc.). Typically not subject to the QSR and are typically not validated (per standards; however, undoubtedly tested thoroughly).

I don't think you can cover ALL the types in a single SOP. What you'll want to do is have a Validation Master Plan to address how you manage non-product software that impacts quality and then have a (product) Test Plan to address anything that is incorporated in your product software.

Hope that helps. Probably way more than you expected but I didn't really see bounds in your question.

 

[dendel]

Re: Off-the-shelf SW S.O.P.; for non-product QSR regulated and non-regulated applicat

Thanks for the response and the effort you took to be all-encompassing. You described the situation here, where I am trying to add the 'non'-product' portion of sw applications and the related document deliverables that are appropriate.
Such an SOP would have to cover a range of apps from, for example, a CNC programming tool level down to a simple spreasheet tool level. I haven't seen such a document that covers this range. If there are any samples available on-line, I'd love to take a look.
thanks again,
Dendel

 

[ciclozan]

Re: Off-the-shelf SW S.O.P.; for non-product QSR regulated and non-regulated applicat

Hello,

Does anyone have a Trending Procedure that I can look at for some ideas?

Thank you,

Corina

 

[mlgsmith]

Re: Off-the-shelf SW S.O.P.; for non-product QSR regulated and non-regulated applicat

Might help to clarify things a bit. There's a wide array of types of software that I would consider 'subject' to the QSR. I'll try to be brief (but in doing so, may miss some stuff). Note: being subject to the QSR and "acquisition, testing, and usage" are quite different.

1) There is software used in the construction of software (e.g., compilers, IDEs, etc.). I would consider these subject to the QSR since they directly affect quality. If uncontrolled changes are made (patches, revision upgrades), you would not be able to re-create a particular build. We have typically not validated these systems with the rationale that the output IS 100% verified (or at least reasonably so).

2) Software used in support of software development (e.g., code repositories). Since these 'touch' the software and have change tracking concerns (security), they are subject to the QSR and probably should be validated (mostly from the perspective of change tracking and security, not general functionality).

3) There is software used in support of design (Solidworks, etc.). These, too, are subject to the QSR since they directly affect quality. These might need to be validated since it's likely the electronic records kept by the systems will be the official record.

4) There is software used in general support of the design effort (e.g., problem / issue tracking tools). Clearly these are subject to the QSR but depending on how you use them, may or may not require validation. (This point is argued ad nauseum in a variety of formats but so far my approach hasn't been cited as inappropriate - so far). I have always used these as just a means to print the final paperwork and so I don't validate. A very rational argument can be made that the electronic records may still be used (e.g., for tracking and trending after closure) so you have to decide for yourself. A risk-based (and documented) decision helps.

5) Software that is incorporated in deliverable software (libraries, protocol stacks, etc.) are clearly subject to the QSR. Some level of validation beyond saying it's sufficiently tested in the product testing is probably warranted (assessment of open issues, for one).

6) Enterprise level applications (MRP, ERP, etc.) are subject to the QSR as they touch various aspects of quality. These are almost always validated.

7) Enterprise level applications that DON'T touch quality (payroll systems, HR systems - that don't manage training records!!, etc.). Typically not subject to the QSR and are typically not validated (per standards; however, undoubtedly tested thoroughly).

I don't think you can cover ALL the types in a single SOP. What you'll want to do is have a Validation Master Plan to address how you manage non-product software that impacts quality and then have a (product) Test Plan to address anything that is incorporated in your product software.

Hope that helps. Probably way more than you expected but I didn't really see bounds in your question.

Appreciated every word in that last reply/post. My question, to take it one step further, is: Where would NPSW such as an upgrade to MS Office (company wide) fit into needing/not needing a Validation? Excel, for example, is used for critical quality control regulated activities in one department, but Excel may be used very little in another department.

 

[yodon]

Re: Off-the-shelf SW S.O.P.; for non-product QSR regulated and non-regulated applicat

I've taken the approach that the outputs from Word and Excel (unless managing an e-record) are 100% verified and so validation of these tools is not required. If you're using Excel for managing e-records (and especially if it contains formulas), though, the individual spreadsheet should be validated (scoped appropriately for risk), not Excel. The spreadsheet validation would address security, data validation, data protection, etc. (all the Part 11 fun stuff).

 

[yodon]

Re: Off-the-shelf SW S.O.P.; for non-product QSR regulated and non-regulated applicat

Thanks for the response and the effort you took to be all-encompassing. You described the situation here, where I am trying to add the 'non'-product' portion of sw applications and the related document deliverables that are appropriate.
Such an SOP would have to cover a range of apps from, for example, a CNC programming tool level down to a simple spreasheet tool level. I haven't seen such a document that covers this range. If there are any samples available on-line, I'd love to take a look.
thanks again,
Dendel

Can you group the categories to minimize the list? For example, if you're thinking of listing every CNC program, then instead, maybe just have categories, say I, II, III - where the categories reflect the risk / level of control. (Just winging it here). You may still eventually need linkage between every program and its category but maybe that's partitioned off elsewhere.