Standard Operating Procedures (SOPs) –

An SOP is a written document or instruction detailing all steps and activities of a process or procedure. ISO 9001 essentially requires the documentation of all procedures used in any manufacturing process that could affect the quality of the product.^[1]

To meet regulations, a company needs rock solid SOPs that outline the entire process around the creation, validation, and training of software used in the regulated industry like clinical trial software.

How does this work?  Think of this as a legal framework within a company, and you will understand its purposes and intentions.  you cannot just put the words SOP on something and call it good, you need to understand the system as a whole and then you can follow the procedures to allow

1- Transparency

2– Traceability

3 – Accountability

4 – Lower risk

5 – Increased Quality

6 – Meeting regulatory requirements obeying the law and protecting the public.

To start off the whole process where do we begin:

Step 1: The first step is to create a document log, this is also called “document control” which is a log of all the documents in the system, this allows you to track document names, document versions, ownership, status (active, inactive,etc..), training requirements and effective dates.  The document log is your catalog of documents, you can also use software systems to track this but all that is needed is an excel spreadsheet and your good to go.  Download Excel 2010 Document Log Template Here:

Step 2: The second document needed is an organization chart which outlines the roles and hierarchy of a company.  This is important as this is the foundation of who is in authority and what they do, and this also dictates what they are required to be trained on.

Download Word 2010 Org Chart Template Here:

Step 3: The third document you create is a document outlining how you do document management, you cannot have SOP system in place without knowing the genesis of your system, this describes the format, layout, and content of your SOP’s along with processes needed to manage the documents.  It is important to note that SOP’s are like “laws” and as such when they are signed by people who have the roles within an organization to enforce the policies, they become effective, however only after people have been training on the documents and the training is documented as well.

I will dive into more in a later post, for now this is the foundation of compliance for a company.

It is important to note that Standard Operating Procedures (SOPs) are required in order for the system to work as a legal framework and the SOPs will dictate the structure, flow, and process around the documents in a system, SOPs are essentially the core principals to any regulated company.

Parts of a Protocol for validation of software

1 – Approvers

2 – Environment & Setup

3 – Defect Tracking

4 – Test Cases

5 – Test Results

Appendix – This could be a test execution worksheet documentation of the evidence that testing took place.

Part 1 – Approvers

This is a list of people and titles and signatures needed to approve the test protocol, once signed it is in effect, however signing this doesn’t complete the testing it just completes the definition of how to test.

Part 2 – Environment

Describes the system environment testing is being completed in.

Part 3 – Defect Tracking

This is very important what do you do, if when testing a test fails?  You need to track the whole process to ensure it gets documented, fixed or not and risks justification.

Part 4 – Test Cases

These are step-by-step instructions on the testing, it is good idea to track each test case to a requirement to ensure that you can prove you are meeting the definitions of the function of what the software should do.

Part 5 – Test Report

This is the summary of what you will record when testing is complete, how it is recorded and processes around the record keeping.

Appendix

Usually contains templates or worksheets and review sheets as documented evidence of the testing.

See an example template in MS Word 2010

The overall validation process must be linked to your Standard Operating Procedures (SOPs) which are legally binding laws within an organization.  There is a general pattern common to validation systems that are expected in the Part 11 industry, these are protocols and reports. 

Protocols: a protocol is a process that you follow, spelled out in great detail and the idea of it is you have a protocol that describes what you want to do.

Report: a report is a write-up about the execution of a protocol and the results of the protocol, protocols and reports go together

A protocol and a report don’t really mean anything in the big picture unless you have SOP’s that dictate the use of protocols and reports and tie the whole process and system together in a type of “legal framework”

What is an example of all of this?

A Great example is software validation, how would this work with validation of a software system?  You have a validation protocol, and a validation report, the protocol describes how you validate something, and the report is the write up on how the protocol execution went,

So lets say you are testing module A in your new clinical portal, you draft up a validation protocol to test the system outlining everything you need to test, this usually includes screen-shots and signatures to ensure accountability and more evidence and a worksheet used to sign / initial each test is executed and passed or failed.  Once complete, you then write up a report which outlines how it went, pass/fail and next steps, if things didn’t go well you can write a new protocol version or create a new protocol against the fixes needed.  It is important to note that these documents need a process and the process needs to be complete (secure, auditable, etc..) using defect tracking, etc.. to ensure no defects are allowed in the system.

There was a good point brought up in a comment from a reader of this blog around the fact that the FDA had withdrawn guidance documents around Part 11 therefore they do not enforce it.  There is new guidance so it can be deceiving.

You can see the withdrawn list here I am not linking to them since they are withdrawn the less that is known about them the better.:

• Guidance for industry, 21 CFR Part 11; Electronic Records; Electronic Signatures Validation
• Guidance for industry, 21 CFR Part 11; Electronic Records; Electronic Signatures, Glossary of Terms
• Guidance for industry, 21 CFR Part 11; Electronic Records; Electronic Signatures, Time Stamps
• Guidance for industry, 21 CFR Part 11; Electronic Records; Electronic Signatures, Maintenance of Electronic Records
• Compliance Policy Guide, CPG 7153.17: Enforcement Policy: 21 CFR Part 11; Electronic Records; Electronic Signatures

;

There is new guidance which can be downloaded here : [PDF version] or read here:

http://www.fda.gov/regulatoryinformation/guidances/ucm125067.htm

This can be confusing but don’t let this fool you, the whole reasoning around the FDA withdrawing the Guidance documents was two-fold.

1 – The FDA published this guidance which is a copy (with exception of the header) of the IEEE SDLC process around hardware systems testing and validation, unfortunately software and hardware are very different and the FDA withdrew this to aliviate confustion around audits that didn’t look at any specific system with its application to the intent of the Part 11 law.

In other words, auditors are not very good at interpreting law, they took the guidance as law which had a side-effect of causing huge inefficiencies in the auditing and validation of part-11 systems.

2- Another aspect is if the government gives out advice or guidance it opens itself up for lawsuits, the government should be making laws and enforcing them, not offering guidance on following the laws.

The new guidance is a lot more vague and limited, mostly giving guidance on interpretation of the law and also aligning with any cases that have come to be known.

We are now re-examining part 11, and we anticipate initiating rulemaking to revise provisions of that regulation. To avoid unnecessary resource expenditures to comply with part 11 requirements, we are issuing this guidance to describe how we intend to exercise enforcement discretion with regard to certain part 11 requirements during the re-examination of part 11. As mentioned previously, part 11 remains in effect during this re-examination period.

As you can see part-11 is still in effect, as this would impact public safety and any efficacy of data used in clinical trials among other things.

Predicate Rules:

What is a predicate rule?  Predicate rules are rules that help you determine if something applies to you or not. In the case of part-11 compliance, a predicate rule is some other law that dictates what needs to be retained, how long it is needed, any other constraints with respect to electronic systems.  An example is when you are building a system, you need to ask, is this information regulated?  If the answer is yes.. then part-11 applies, along with some constraints like the e-signatures part only applies to records that needed to be “signed” in paper form, and you are replacing this with an electronic system.

What other laws could apply, how do you know?

Well in any regulated industry there are the CFR’s (federal regulations) which spell out in detail the specifics, and other acts as well (Food, Drug and  Cosmetic Act, or the Public Health Service Act and any ammendments) in our case of 21 CFR Part 11, we look at the GXPs (Good Clinical Practices, Good Manufacturing Practices) 

A Policy in XACML is essentially an XML document that describes a couple of things needed to grant permission or access to a resource. It comes down to some basic composition,

You have a set of three things,

1 – Subject : This is who is requesting access, the “WHO”

2 – Resource: This is the “WHAT” and specifically it is something you are protecting for some reason.

3 – Action: This is the "active verb” that is being performed, usually the activity of what you can do to the resource as in disk-access would be “Read” , “write”, “delete” or could be a function in the system at a higher level “manage” or “review”.

A Policy is linked to these three things which are grouped together as a “target” to make things reusable, and also add shared attributes to the collective.

A Policy also has this thing called “Policy Combining Algorithm” and a “Rule Combining Algorithm” this is the logic to use when more than one policy or rule are in use, the standard default is DENY-OVERRIDES

Deny-Overrides: This is that a deny permission will always override a permit, so that if you have 100 rules applied to you, if only 1 of them is deny, you cannot access, this is a more default-secure method for security.

The Rule is straightforward, it defines the logic and attributes needed to check for security on the target, this is the power of XACML as you can apply a rule which is composed of an Effect and optionally a condition, so this means , effect is always “permit” or “deny” and you can apply a condition optionally to grant the effect based on time of day or other attributes for the user.

Policy Set this is just as it says, a collection of policies which allows for better composition.

Lastly there are these things called “Obligations” which help cross-cut a concern like logging or auditing, preventing rule-explosion. 

The composition above describes the Scheme of a Policy and Policy set as is required by the XACML standard.  In summary you can see that

A Policy has

0 or 1 Targets,

has 1 policy combining algorithm,

0 or 1 Obligations,

1 Rule Combining Algorithm.

A Target has a Subject, Resource, and Action, and Rule, and a Policy Set and Policy.

A Rule has an Effect and 0 or 1 Conditions, and a Rule Combining Algorithm.

A Policy Set has a Target, A Policy Combining Algorithm, and 0 or 1 Obligations.

An Example Policy is shown below:

Next overview will be around the application of the Policies, and an implementation of a PDP (Policy Decision Point) in C# as an example on how it works internally.

.

As you can see in the above diagram. Here is a step-by-step breakdown.

1 – You attempt access to a secure system, you will essentially be calling a PEP (enforcement point) which will check your authentication to ensure you are who you say you are, if you are authentic, it will forward request to PDP.

2- PEP packs this information along with roles and claims to the PDP for a decision to be made about you.

3 – PEP will check cache and return, if not available, it will then try to make a decision, most likely getting information from PIP to make a decision about your authorization access.

4 – PIP will query all identity system usually Active Directory or some Identity system.

5 – PIP will also query any other systems if needed, and send this back to PDP for decision.

6 – PDP caches data from PIP and makes a decision about authorization.

7 – PDP sends decision back to PEP to then allow request or deny.

8 – PEP allows or disallows request based on policies.

We will examine the components and possibly implementation solutions to these problems, and why they are very useful for externalizing security decisions from an application.  Another alternate flow is that the PEP controls the data flow as well, rather than just a security check, but would constrain the data based on policies.

Here is the intent of the Specification pattern: “ to separate the logic for (e.g.) filtering an entity from the entity itself.”

Example application for this pattern has been to support filtering as a pluggable entity “collection” of specifications.  The implementation details as things mature are apparent with generics and expression tree’s and event the IQueryable<> interfaces against OR/M layers.

The main benefits of this pattern are

1 – Loose coupling of the filter logic from the objects being filtered,

2- Single responsibility: Filtering is essentially a first class citizen and also can exist in a decoupled state for better testing and independent improvement

3 – Composition of specifications allows for reuse and complex nested specifications for easier maintenance.

e-signatures are part of the law required for part 11 compliance here is what the law says itself

Subpart C–Electronic Signatures

Sec. 11.100 General requirements.

(a) Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else.

(b) Before an organization establishes, assigns, certifies, or otherwise sanctions an individual`s electronic signature, or any element of such electronic signature, the organization shall verify the identity of the individual.

(c) Persons using electronic signatures shall, prior to or at the time of such use, certify to the agency that the electronic signatures in their system, used on or after August 20, 1997, are intended to be the legally binding equivalent of traditional handwritten signatures.

(1) The certification shall be submitted in paper form and signed with a traditional handwritten signature, to the Office of Regional Operations, 12420 Parklawn Drive, RM 3007 Rockville, MD 20857.

Sec. 11.200 Electronic signature components and controls.

(a) Electronic signatures that are not based upon biometrics shall:

(1) Employ at least two distinct identification components such as an identification code and password.

(i) When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual.

(ii) When an individual executes one or more signings not performed during a single, continuous period of controlled system access, each signing shall be executed using all of the electronic signature components.

(2) Be used only by their genuine owners; and

(3) Be administered and executed to ensure that attempted use of an individual’s electronic signature by anyone other than its genuine owner requires collaboration of two or more individuals.

(b) Electronic signatures based upon biometrics shall be designed to ensure that they cannot be used by anyone other than their genuine owners.

E-Signatures are required when you are replacing a regulated process that is paper-based (required signatures) with electronic signatures. There are 2 parts to this

1 -  As an organization you need to accept e-signatures as physical signatures (or the client running the software)

2- You need to implement the baseline features and have training and signatures of people accepting the signature requirement.

Here are some foundation e-signature requirements for a part 11 compliant system

1 – Unique accounts for each user who signs

2 – Encrypted connection to the system (SSL)

3 – They need to see and agree to the statement of intent to validate this you require some unique data like a username/password, digital identity (biometrics, dongle, rsa token), passphrase, they must provide this with the statement of intent for the signature so they understand they are signing it.

4 – Any user must be able to see all things they have signed in the system (a history of signatures and versions of documents)

5 – Auditing of the entire data stored in an immutable form with full history to prevent falsification (image with checksum etc..)

6- Each signature needs

a. the name of person

b. the date/time of signature

c. a storage mechanism to prevent tampering and ensure integrity

d. statement of intent

e. the role of person

7 – The things being signed cannot be pre-loaded with data, the person must fill out the form on their own, no defaults.

8 – If signing more than 1 thing within a 20 minute window, you can only require password for each signature rather than name/password within the session after 20 minuets they must enter both name and password.

9 – Signature and Data must be stored together and not be separable.

security is part of the law required for part 11 compliance here is what the law says itself

Sec. 11.300 Controls for identification codes/passwords.

Persons who use electronic signatures based upon use of identification codes in combination with passwords shall employ controls to ensure their security and integrity. Such controls shall include:

(a) Maintaining the uniqueness of each combined identification code and password, such that no two individuals have the same combination of identification code and password.

(b) Ensuring that identification code and password issuances are periodically checked, recalled, or revised (e.g., to cover such events as password aging).

(c) Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and other devices that bear or generate identification code or password information, and to issue temporary or permanent replacements using suitable, rigorous controls.

(d) Use of transaction safeguards to prevent unauthorized use of passwords and/or identification codes, and to detect and report in an immediate and urgent manner any attempts at their unauthorized use to the system security unit, and, as appropriate, to organizational management.

(e) Initial and periodic testing of devices, such as tokens or cards, that bear or generate identification code or password information to ensure that they function properly and have not been altered in an unauthorized manner.

Here are some foundation security requirements for a part 11 compliant system

1 – Unique accounts for each user

2 – Encrypted connection to the system (SSL)

3-  Complex Password required (numbers, symbols, length)

4 – Required to change password every 90 days

5 – Password history no reuse within a year

6 – 3 failed attempts lockout system (send notification to administrator)

7 – synchronize time on all servers

8 – show the username, name, and last logged in date on the screen at all times

9 – after 20 minutes log out account

10 – only allow one login at a time per an account

11 – log all activity in an audit log

12 – display version of software on screen (about screen)

13 – encrypt password is hash so it is irreversible and not viewable by anyone

14 – train people on security to thwart attempts at social engineering

With these feature requirements you can see that a part 11 security system has a pretty high level of requirement, but having the features is not enough you need to validation process and training to complete compliance.