“Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate”
I have been discussing this with a colleague and we interpret it differently. I am of the opinion that the SOP will indicate operational system checks and this will be configured in the software.
So, pre-defined messages can be configured to prompt an operator, supervisor, manager or QP to enter data. The SOP will instruct on this and the software will only allow a certain order to the steps.
The QP would not be able to sign off a batch electronically unless all previous steps from operators, supervisors and managers were completed (if this is how it was configured).
For example:
Operator to add X to container Y - prompted on screen to add, has to complete box with weight and sign
Supervisor prompted to check, enters yes and signs to confirm review
Manager prompted to authorise, enters comments and signs
QP to prompted to approve and the batch and it will not be marked as acceptable until this final signature is entered.
My colleague interprets operational system checks from a purely software perspective in that the actual software design includes system checks internally.
FDA regulated computer systems should have sufficient controls or operational system checks to ensure that users must follow required procedures. For example, if a computer system regulates the release of a manufactured product, the computer system should not authorize the release until the appropriate Quality approval has been provided.
My interpretation is that the system should not allow steps to occur in the wrong order. For example, should it be necessary to create, delete, or modify records in a particular sequence, operational system checks would ensure that the proper sequence is followed. Another example would be system checks that prevent changes to a record after it has been reviewed and signed.
An operation system check is any system control that enforces a particular workflow. For example, when approving a batch release, a system might require an electronic signature from manufacturing and quality control before the batch status can be changed to released. Another system may have a requirement that once an electronic signature is attached to a record, the record can no longer be modified. In this case, applying the electronic signature would trigger a control locking the record from future edits until the electronic signature is removed.
Probably a good idea to circle back to the intent of the regulation: electronic records and electronic signatures. The aforementioned “controls” may be programmatic. The preamble doesn’t give much more help:
The agency advises that the purpose of performing operational checks is to ensure that operations (such as manufacturing production steps and signings to indicate initiation or completion of those steps) are not executed outside of the predefined order established by the operating organization.
(Here’s a link to the preamble if you want to read further - there’s a good discussion on the Agency’s position on that clause starting on p. 19:
)
Again, there’s no specific mention of software. So while such controls may be implemented in software - which would require validation, of course - I think Graham is right in that you both may be over-limiting the scope with your interpretation.
Thanks to you both for your interest and comments. I am unsure what you mean by ‘over-limiting the scope’ would you elaborate for me please?
I read the link. It seems to me from the Agency’s standpoint both internal software system checks and process systems checks are required. Am I correct in my interpretation? If so, I think these are seperate entities and should be addressed and validated as such. What is your view?
Sorry, yes, “over-limiting scope” may not have been the best choice of words (and it was certainly not meant to be inflammatory). It just seemed you were both focusing on just software. I was just trying to point out that the controls could be implemented in software, hardware, or procedurally. Part 11 expects that the manufacturer demonstrates “system” compliance, not just software.
'm not sure I have been clear enough in my explanations.
My view is the computerised system incorporates everything, software, hardware, documentation (SOP). When looking at part 11 (f), my view is to look at the system as a whole, software and SOP, etc. My colleagues view focuses on the internal workings of the software (as a programmer). Does this make sense? Even though both areas are covered by part 11 (f), I think the internal workings of the software need to be addressed separately from the software and how it is configured.