SlideShare a Scribd company logo
SharePoint and 21 CFR Part 11
A Risk-Based Validation Approach for Life Sciences



                   Paul Fenton
     VP Pharmaceutical Processes and Technology




                                                     1
<<Your Logo>>


Overview	
  

•    Objec&ves	
  of	
  valida&on	
  
•    Regulatory	
  requirements	
  
•    How	
  to	
  iden&fy	
  electronic	
  records	
  
•    Deploying	
  controlled	
  and	
  non-­‐controlled	
  MOSS	
  environments	
  
•    Risk	
  evalua&on	
  methods	
  and	
  scoping	
  the	
  valida&on	
  strategy	
  
•    Step	
  by	
  Step	
  overview	
  of	
  the	
  risk-­‐based	
  valida&on	
  process	
  following	
  the	
  
     GAMP5	
  model	
  
•    Implemen&ng	
  effec&ve	
  configura&on	
  and	
  change	
  control	
  procedures	
  for	
  
     MOSS	
  
•    Maximizing	
  quality	
  and	
  ROI	
  	
  
•    Lessons	
  learned	
  and	
  best	
  prac&ces	
  
•    Q&A	
  
                                                                                                                   2
<<Your Logo>>


 What	
  is	
  Computer	
  Systems	
  Valida&on?	
  

•  A	
  formal	
  process	
  to	
  ensure	
  that:	
  
    –  systems	
  	
  consistently	
  operate	
  as	
  they	
  were	
  intended	
    	
  
    –  user,	
  business	
  and	
  regulatory	
  system	
  requirements	
  
         are	
  met	
  
    –  informa&on	
  is	
  secure	
  and	
  properly	
  managed	
  by	
  the	
  
         system	
  
    –  procedures	
  and	
  processes	
  are	
  in	
  place	
  for	
  the	
  use	
  
         and	
  management	
  of	
  the	
  system	
  
<<Your Logo>>


What	
  the	
  regula&ons	
  say…	
  
   •  FDA:	
  21	
  CFR	
  Part	
  11	
  	
  
      §11.10(a)	
  Valida&on	
  of	
  systems	
  to	
  ensure	
  accuracy,	
  
        reliability,	
  consistent	
  intended	
  performance,	
  and	
  
        the	
  ability	
  to	
  discern	
  invalid	
  or	
  altered	
  records.	
  
   •  ICH	
  E6	
  –	
  GCP	
  
      §5.5.3(a)	
  Ensure	
  and	
  document	
  that	
  the	
  electronic	
  
        data	
  processing	
  system(s)	
  conforms	
  to	
  the	
  
        sponsor’s	
  established	
  requirements	
  for	
  
        completeness,	
  accuracy,	
  reliability	
  and	
  consistent	
  
        intended	
  performance	
  (i.e.	
  valida&on)	
  
                                                                                  4
<<Your Logo>>


What	
  the	
  regula&ons	
  say….	
  

   •  FDA:	
  CSUCI	
  
      §F5	
  Change	
  Control	
  -­‐	
  The	
  integrity	
  of	
  the	
  data	
  and	
  the	
  
        integrity	
  of	
  the	
  protocols	
  should	
  be	
  maintained	
  when	
  
        making	
  changes	
  to	
  the	
  computerized	
  system,	
  such	
  as	
  
        sodware	
  upgrades,	
  including	
  security	
  and	
  performance	
  
        patches,	
  equipment,	
  or	
  component	
  replacement,	
  or	
  new	
  
        instrumenta&on.	
  The	
  effects	
  of	
  any	
  changes	
  to	
  the	
  system	
  
        should	
  be	
  evaluated	
  and	
  some	
  should	
  be	
  validated	
  
        depending	
  on	
  risk.	
  Changes	
  that	
  exceed	
  previously	
  
        established	
  opera&onal	
  limits	
  or	
  design	
  specifica&ons	
  
        should	
  be	
  validated.	
  Finally,	
  all	
  changes	
  to	
  the	
  system	
  
        should	
  be	
  documented.	
  
                                                                                               5
<<Your Logo>>


Other	
  important	
  guidance	
  documents	
  

•  PIC/S	
  Annex	
  11	
  –	
  PI	
  011-­‐3	
  Good	
  Prac&ces	
  for	
  
   Computerised	
  Systems	
  in	
  Regulated	
  GxP	
  
   Envrionments	
  (2007)	
  
•  US	
  FDA:	
  General	
  Principles	
  of	
  Sodware	
  
   Valida&on;	
  Final	
  Guidance	
  for	
  Industry	
  and	
  
   FDA	
  Staff	
  (2002)	
  



                                                                               6
<<Your Logo>>


What	
  is	
  expected?	
  

•  That	
  procedures	
  should	
  be	
  in	
  place	
  to	
  ensure	
  that	
  
   systems	
  used	
  in	
  regulated	
  ac&vi&es	
  are	
  adequately	
  
   validated	
  
•  That	
  systems	
  should	
  be	
  maintained	
  in	
  a	
  validated	
  state	
  
   through	
  effec&ve	
  change	
  control	
  mechanisms	
  
•  That	
  sponsors	
  take	
  a	
  risk	
  based	
  approach	
  to	
  computer	
  
   systems	
  valida&on	
  (CSV)	
  
•  That	
  individuals	
  involved	
  in	
  CSV	
  ac&vi&es	
  and	
  the	
  
   maintenance	
  of	
  validated	
  systems	
  have	
  adequate	
  
   experience	
  and	
  training	
  
<<Your Logo>>


How	
  to	
  iden&fy	
  electronic	
  records	
  

•  21	
  CFR	
  Part	
  11	
  defines	
  electronic	
  records	
  as:	
  
     –  Records	
  that	
  are	
  required	
  to	
  be	
  maintained	
  under	
  predicate	
  rule	
  
        requirements	
  and	
  that	
  are	
  maintained	
  in	
  electronic	
  format	
  in	
  place	
  of	
  
        paper	
  format	
  
     –  Records	
  that	
  are	
  required	
  to	
  be	
  maintained	
  under	
  predicate	
  rules,	
  that	
  
        are	
  maintained	
  in	
  electronic	
  format	
  in	
  addi/on	
  to	
  paper	
  format,	
  and	
  
        that	
  are	
  relied	
  on	
  to	
  perform	
  regulated	
  ac/vi/es	
  
     –  Records	
  submihed	
  to	
  FDA,	
  under	
  predicate	
  rules	
  (even	
  if	
  such	
  records	
  
        are	
  not	
  specifically	
  iden&fied	
  in	
  Agency	
  regula&ons)	
  in	
  electronic	
  
        format	
  
     –  Electronic	
  signatures	
  that	
  are	
  intended	
  to	
  be	
  the	
  equivalent	
  of	
  
        handwrihen	
  signatures,	
  ini&als,	
  and	
  other	
  general	
  signings	
  required	
  by	
  
        predicate	
  rules	
  

                                                                                                              8
<<Your Logo>>


Electronic	
  Records	
  within	
  MOSS	
  

•  Records	
  within	
  the	
  context	
  of	
  MOSS	
  could	
  be:	
  
    –  Documents	
  (excluding	
  descrip&ve	
  metadata)	
  
       required	
  to	
  be	
  maintained	
  by	
  predicate	
  rule	
  
    –  Metadata	
  (Columns)	
  used	
  to	
  perform	
  regulated	
  
       ac&vi&es	
  (or	
  make	
  regulated	
  decisions)	
  
    –  InfoPath	
  forms	
  used	
  to	
  document	
  regulated	
  
       ac&vi&es	
  


                                                                           9
<<Your Logo>>


Electronic	
  Records	
  within	
  MOSS	
  

    –  Electronic	
  /	
  Digital	
  Signatures	
  used	
  to	
  sign	
  records
                                                                               	
  
       required	
  by	
  predicate	
  rules	
  
    –  Audit	
  Trails	
  generated	
  for	
  electronic	
  records	
  being	
  
       generated	
  and/or	
  managed	
  in	
  MOSS	
  




                                                                                 10
<<Your Logo>>


How	
  to	
  iden&fy	
  electronic	
  records	
  	
  

•  Points	
  to	
  consider:	
  
      –  Does	
  the	
  record	
  exist	
  in	
  electronic	
  format	
  only	
  with	
  no	
  paper	
  source?	
  
      –  Is	
  the	
  record	
  required	
  by	
  predicate	
  rule?	
  
      –  Does	
  the	
  record	
  drive	
  a	
  regulated	
  process	
  or	
  decision?	
  
•  If	
  the	
  answer	
  to	
  any	
  of	
  the	
  above	
  is	
  ‘Yes’	
  then	
  21	
  CFR	
  Part	
  11	
  	
  
   applies	
  and	
  your	
  system	
  must	
  be	
  validated	
  
•  You	
  should	
  document	
  this	
  in	
  a	
  valida&on	
  assessment	
  
   document	
  or	
  valida&on	
  plan.	
  You	
  should	
  also	
  clearly	
  iden&fy	
  
   the	
  scope	
  of	
  valida&on	
  in	
  this	
  document	
  
•  This	
  document	
  can	
  help	
  structure	
  your	
  MOSS	
  deployment	
  into                               	
  
   controlled	
  and	
  non-­‐controlled	
  environments	
  
                                                                                                                     11
<<Your Logo>>


Controlled	
  vs.	
  Non-­‐Controlled	
  MOSS	
  Architecture	
  

•  MOSS	
  can	
  be	
  used	
  across	
  the	
  enterprise	
  for	
  many	
  different	
  
   applica&ons	
  and	
  groups	
  
•  It	
  is	
  impera&ve	
  to	
  make	
  a	
  clear	
  separa&on	
  between	
  controlled	
  
   (validated)	
  and	
  non-­‐controlled	
  environments	
  
•  This	
  can	
  be	
  achieved	
  by	
  deploying	
  an	
  independent	
  web	
  
   applica&on/site	
  collec&on	
  or	
  controlled	
  sites	
  for	
  regulated	
  
   documents	
  and	
  processes	
  
•  There	
  are	
  advantages	
  and	
  disadvantages	
  to	
  both	
  models	
  due	
  
   to	
  limita&ons	
  of	
  MOSS	
  
•  These	
  architecture	
  models	
  aim	
  to	
  offer	
  both	
  flexibility	
  and	
  
   control	
  and	
  reduce	
  valida&on	
  /	
  change	
  control	
  scope	
  
                                                                                            12
<<Your Logo>>


Controlled	
  vs.	
  Non-­‐Controlled	
  –	
  Integrated	
  Op&on	
  
                                                           Central	
  Admin	
  
    • Features and Solutions (Scope must be controlled)                                                                                            Admin	
  
    • Administered Forms (Scope must be controlled)                                                                                                 	
  DB	
  



    • Controlled Content Types                      Validated	
  Web	
  Applica&on	
                         • Controlled Security Groups
    • Controlled Columns                    Top	
  Level	
  Site	
  Collec&on	
  (Controlled)	
              • Controlled Templates
    • Controlled Lists
                                                                                                                                                 Content	
  
                                                                                                                                                   DB	
  




  Uncontrolled	
  Func&onal	
                           Controlled	
  Func&onal	
                                Record	
  Center	
  or	
  
           Sites	
                                        Sites	
  –	
  Validated	
                            Document	
  Repository	
  –	
  
                                Custom	
  
 • Uncontrolled Content Types Send-­‐To	
  /	
  
                                                                                        Custom	
                    Validated	
  
                                Hyperlinks	
                                            Send-­‐To	
  /	
  
 • Uncontrolled Columns                                                                 Hyperlinks	
  
 • Uncontrolled Lists
 • Uncontrolled Security Groups                      • Controlled Site and Library                             • Information Management
 • Uncontrolled Templates                            structures                                                Policies
 • Non-validated Features and                        • Validated Features and                                  • Records Mgt Site Structures
 Solutions                                           Solutions                                                 • Record Mapping
 • Non-validated Workflows                           •  Validated Workflows
                                                     •  Validated Dashboards


                                                                                                                                             13
<<Your Logo>>


        Controlled	
  vs.	
  Non-­‐Controlled	
  –	
  Isolated	
  Op&on	
  
                                                                   Central	
  Admin	
  
                 • Features and Solutions (Scope must be controlled)                                                                                      Admin	
  
                 • Administered Forms (Scope must be controlled)                                                                                           	
  DB	
  




              Uncontrolled	
  Web	
  Applica&on	
                            Validated	
  Controlled	
  Web	
  Applica&on	
  
               • Uncontrolled Templates                       • Controlled Content Types                           • Controlled Security Groups
               • Uncontrolled Content Types
                                                              • Controlled Columns                                 • Controlled Templates
               • Uncontrolled Columns                         • Controlled Lists
               • Uncontrolled Lists                                                                                                                    Content	
  
               • Uncontrolled Security Groups                                                                                                            DB	
  


Content	
  
  DB	
                                                          Controlled	
  Func&onal	
                              Record	
  Center	
  or	
  
                                                                  Sites	
  –	
  Validated	
   Custom	
               Document	
  Repository	
  –	
  
               Uncontrolled	
  Func&onal	
  
                                             Hyperlinks	
  
                                                                                              Send-­‐To	
  /	
            Validated	
  
                        Sites	
                                                               Hyperlinks	
  

              • Non-validated Features and                     • Controlled Site and Library
                                                                                                                     • Information Management
              Solutions                                        structures                                            Policies
              • Non-validated Workflows                        • Validated Features and                              • Records Mgt Site Structures
                                                               Solutions                                             • Record Mapping
                                                               •  Validated Workflows
                                                               •  Validated Dashboards



                                                                                                                                                   14
<<Your Logo>>


   Example	
  of	
  Controlled	
  and	
  Non-­‐Controlled	
  Environment	
  


                                                                       Central	
  
                                                                     Admin	
  /	
  TLS	
  



                       Uncontrolled	
                                                                 Controlled	
  
                        Workspace	
                                                                   Workspace	
  



                                                                                                                                    Records	
  
ClinOps	
     PV	
       CMC	
            RegOps	
     HR	
     ClinOps	
                    PV	
        CMC	
         RegOps	
  
                                                                                                                                    Center	
  




                                                                                   Validated Environment

                                                                                                                                     15
<<Your Logo>>


Risk	
  Evalua&on	
  and	
  Scoping	
  the	
  Valida&on	
  Strategy	
  
•  Agencies	
  are	
  ac&vely	
  encouraging	
  the	
  use	
  of	
  risk	
  based	
  
   approaches	
  for	
  the	
  valida&on	
  of	
  computerized	
  systems	
  used	
  
   in	
  GxP	
  environments	
  
•  The	
  use	
  of	
  a	
  risk	
  based	
  approach	
  allows	
  us	
  to	
  focus	
  on	
  high	
  
   risk	
  areas	
  whilst	
  reducing	
  the	
  valida&on	
  effort	
  and	
  improving	
  
   quality	
  
•  When	
  star&ng	
  the	
  deployment	
  of	
  MOSS	
  in	
  regulated	
  
   environments,	
  it	
  is	
  important	
  to	
  evaluate	
  risk	
  so	
  as	
  to	
  focus	
  
   valida&on	
  efforts	
  on	
  high	
  risk	
  areas	
  
•  Risk	
  should	
  be	
  measured	
  at	
  two	
  levels:	
  
     –  General	
  procedural	
  risk	
  
     –  Detailed	
  func&onal	
  risk	
  
                                                                                                     16
<<Your Logo>>


Risk	
  Evalua&on	
  and	
  Scoping	
  the	
  Valida&on	
  Strategy	
  

•  Risk	
  can	
  be	
  iden&fied	
  as	
  either	
  regulatory	
  risk	
  or	
  
   business	
  risk	
  
•  You	
  should	
  clearly	
  specify	
  that	
  you	
  intend	
  to	
  adopt	
  a	
  
   risk	
  based	
  approach	
  in	
  your	
  valida&on	
  plan	
  and	
  also	
  
   explain	
  the	
  ra&onale	
  behind	
  the	
  approach	
  
•  Ensure	
  that	
  risk	
  assessment	
  is	
  carried	
  out	
  by	
  a	
  
   knowledgeable	
  team	
  
•  Be	
  strict	
  as	
  everything	
  can	
  end	
  up	
  being	
  high-­‐risk	
  
   with	
  enough	
  debate….	
  
                                                                                      17
<<Your Logo>>


Risk	
  based	
  approach	
  101	
  –	
  Iden&fy	
  Scope	
  
•  Step	
  1	
  -­‐	
  When	
  defining	
  the	
  scope	
  of	
  your	
  MOSS	
  deployment	
  clearly	
  
   iden&fy	
  regulated	
  procedures	
  and	
  records	
  that	
  will	
  be	
  generated	
  or	
  
   managed	
  by	
  the	
  system	
  
    MOSS Examples:

    1.  MOSS will be used to generate submission ready electronic PDF
        records that will be submitted to FDA as part of our INDs
    2.  MOSS will be used to control the drug shipment authorization
        process for clinical sites
    3.  MOSS will be used to generate CAPA records for our GMP facility
    4.  MOSS will be used to manage audit report observations

     IMPORTANT:	
  If	
  MOSS	
  will	
  not	
  be	
  used	
  for	
  processes	
  or	
  records	
  that	
  are	
  
        governed	
  by	
  predicate	
  rules…there	
  is	
  no	
  regulatory	
  requirement	
  to	
  
                                                      validate!   	
  
                                                                                                                     18
<<Your Logo>>


Risk	
  based	
  approach	
  101	
  –	
  Risk	
  Type	
  /	
  GxP	
  Determina&on	
  
•  Step	
  2	
  -­‐	
  Associate	
  a	
  type	
  of	
  risk	
  (regulatory	
  or	
  business)	
  to	
  each	
  record	
  or	
  
   process	
  based	
  on	
  the	
  following	
  criteria:	
  
       A.    Is	
  the	
  record	
  or	
  procedure	
  governed	
  or	
  required	
  by	
  predicate	
  rule?	
  
       B.    Does	
  the	
  procedure	
  or	
  record	
  have	
  an	
  impact	
  on	
  subject	
  safety?	
  
       C.    Does	
  the	
  procedure	
  or	
  record	
  have	
  an	
  impact	
  of	
  product	
  quality?	
  
       D.    Does	
  the	
  procedure	
  or	
  record	
  have	
  an	
  impact	
  on	
  data	
  integrity?	
  
       E.    Does	
  the	
  procedure	
  or	
  record	
  have	
  a	
  important	
  impact	
  on	
  our	
  ability	
  to	
  carry	
  out	
  the	
  
             daily	
  tasks	
  of	
  our	
  business?	
  
      MOSS Examples:
      1.  MOSS will be used to generate submission ready electronic PDF records that will be
          submitted to FDA as part of our INDs – Regulatory risk (A)
      2.  MOSS will be used to control the drug shipment authorization process for clinical sites –
          Regulatory Risk (B)
      3.  MOSS will be used to generate CAPA records for our GMP facility – Regulatory Risk (C)
      4.  MOSS will be used to manage audit report observations – Regulatory and Business
          Risk (A-E)

      IMPORTANT: If a procedure or record has no regulatory risk associated, it may be
      excluded from the validation effort provided that adequate rationale is provided
                                                                                                                                                     19
<<Your Logo>>


Risk	
  based	
  approach	
  101	
  –	
  Risk	
  Scenarios	
  
•  Step	
  3	
  –	
  Define	
  risk	
  scenarios	
  for	
  each	
  process	
  or	
  record	
  iden&fied.	
  
   Scenarios	
  should	
  include:	
  
      –    Poten&al	
  risk	
  
      –    Likelihood	
  of	
  occurrence/detec&on	
  	
  
      –    Impact	
  
      –    Pallia&ve	
  ac&ons	
  
     MOSS Example:
     1.  MOSS will be used to control the drug shipment authorization process for clinical sites –
         Regulatory Risk (B)
     Risk Scenario A:
           •  Risk: IRB approval has not been received and a subject is enrolled in study and
              treated
           •  Likelihood: Medium – Due to combination of procedural and system controls
           •  Impact: High – Treating subjects without IRB approval considered a serious
              deviation
           •  Palliative Action: Ensure that drug cannot be shipped to site before IRB approval
              has been received through system and procedural controls

                                                                                                             20
<<Your Logo>>


Risk	
  based	
  approach	
  101	
  –	
  Link	
  System	
  Func&ons	
  to	
  Scope	
  	
  
•  Step	
  4	
  –	
  Once	
  processes	
  and	
  records	
  have	
  been	
  classified	
  by	
  procedural	
  
   risk,	
  they	
  must	
  be	
  linked	
  to	
  the	
  system	
  func&onality	
  defined	
  in	
  the	
  user	
  
   requirements	
  specifica&on	
  (URS):	
  
     MOSS Example:

        Process	
  /	
  Record	
               URS	
  ID	
     Requirement	
  
        MOSS	
  will	
  be	
  used	
  to	
     UR3.1.	
        The	
  system	
  should	
  allow	
  the	
  automa&c	
  genera&on	
  of	
  PDF	
  
        generate	
  submission	
                               v1.4.	
  files	
  
        ready	
  electronic	
  PDF	
           UR3.2.	
        The	
  system	
  should	
  allow	
  the	
  electronic	
  signature	
  of	
  
        records	
  that	
  will	
  be	
  
                                                               records	
  
        submihed	
  to	
  FDA	
  as	
  
        part	
  of	
  our	
  INDs	
            UR3.3.	
        The	
  system	
  should	
  be	
  able	
  to	
  invalidate	
  electronic	
  
                                                               signatures	
  if	
  the	
  signed	
  record	
  is	
  modified	
  
                                               UR3.4.	
        The	
  system	
  should	
  manage	
  the	
  version	
  number	
  of	
  
                                                               records	
  
                                               UR3.5.	
        The	
  system	
  should	
  be	
  capable	
  of	
  rendering	
  final	
  records	
  
                                                               read-­‐only	
  


                                                                                                                                                    21
<<Your Logo>>


Risk	
  based	
  approach	
  101	
  –	
  GAMP	
  Risk	
  Evalua&on	
  method	
  

                              Probability                                              Detectability




                                                                                                 Medium
                                    Medium




                                                                                          High
                                             High




                                                                                                          Low
                             Low




                                                                 Risk Class
                               2   1         1                                            M      H        H


                                                    Risk Class




                                                                                                                Priority
         Severity




                      High                                                            1                                    Risk
                               3   2         1
                    Medium                                                                L      M        H

                      Low
                               3   3         2
                                                                                      2

                                                                                      3
                                                                                          L      L        M                M

   Severity = Impact on Patient Safety,                                       Detectability = Likelihood that
   Product Quality or Data Integrity                                          the fault is detected before harm
   Probability = Likelihood of fault                                          occurs
   occurring
                                                                              Priority = Risk Class x
   Risk Class = Severity x Probability                                        Detectability

                                                                                                                                  22
<<Your Logo>>


Risk	
  based	
  approach	
  101	
  –	
  Decide	
  on	
  risk	
  acceptability	
  level	
  

•  Step	
  5	
  –	
  Based	
  on	
  the	
  type	
  of	
  system	
  and	
  the	
  high	
  level	
  risk	
  assessment	
  
   we	
  must	
  decide	
  on	
  what	
  level	
  of	
  risk	
  must	
  be	
  tested	
  for	
  during	
  valida&on	
  
      –  Custom	
  built	
  systems	
  or	
  components	
  tend	
  to	
  present	
  a	
  higher	
  level	
  of	
  risk	
  than	
  
         OTS	
  systems	
  
      –  It	
  may	
  be	
  appropriate	
  to	
  exclude	
  business	
  risk	
  from	
  tes&ng	
  
      –  The	
  valida&on	
  plan	
  should	
  specify	
  the	
  acceptable	
  risk	
  levels	
  with	
  ra&onale	
  
     MOSS Example:
     1.  All OTS MOSS functions that have a risk rating of low or medium will not be formally
         tested during validation. These functions are deemed to be adequately tested by the
         vendor.
     2.  All custom applications deployed within the MOSS environment that have GxP impact
         and a risk rating of medium or high will be formally tested during validation. Low risk
         functions and functions that do not have GxP impact will be informally verified during the
         build phase.




                                                                                                                               23
<<Your Logo>>


  Risk	
  based	
  approach	
  101	
  –	
  Evaluate	
  System	
  Func&ons	
  
  •  Step	
  6	
  –	
  Once	
  processes	
  and	
  records	
  have	
  been	
  linked	
  to	
  system	
  func&ons,	
  
     a	
  risk	
  evalua&on	
  of	
  each	
  func&on	
  involved	
  is	
  undertaken:	
  
MOSS Example:

 Process	
  /	
        URS	
  ID	
   Requirement	
                             Risk	
  Scenario	
           Severity	
  /	
  Probability	
  /	
     Test	
  Y/N	
  
 Record	
                                                                                                   Detectability	
  
                                                                                                            Low	
  (L),	
  Medium	
  (M),	
  
                                                                                                            High	
  (H)	
  
 MOSS	
  will	
  be	
   UR3.1.	
   The	
  system	
  should	
  allow	
          PDF	
  Files	
  are	
  
 used	
  to	
                      the	
  automa&c	
  genera&on	
  of	
        generated	
  in	
  the	
            M	
         L	
       H	
        No	
  	
     L
 generate	
                        PDF	
  v1.4.	
  files	
                      incorrect	
  format	
  
 submission	
  
                        UR3.2.	
   The	
  system	
  should	
  allow	
          Record	
  cannot	
  be	
  
 ready	
                                                                                                            L	
       M	
        H	
  
                                   the	
  electronic	
  signature	
  of	
      signed	
                                                             No	
         L
 electronic	
  
                                   records	
  
 PDF	
  records	
  
 that	
  will	
  be	
   UR3.3.	
   The	
  system	
  should	
  be	
  able	
     Signature	
  
 submihed	
  to	
                  to	
  invalidate	
  electronic	
            remains	
  valid	
                   H	
       M	
        L	
        Yes	
        H
 FDA	
  as	
  part	
               signatures	
  if	
  the	
  signed	
         ader	
  record	
  
 of	
  our	
  INDs	
               record	
  is	
  modified	
                   modifica&on	
  
                                                                                                                                                                 24
<<Your Logo>>


Risk	
  based	
  approach	
  101	
  -­‐	
  Comple&on	
  

•  The	
  result	
  of	
  the	
  func&onal	
  risk	
  assessment	
  provides	
  us	
  with	
  
   the	
  founda&on	
  for	
  the	
  various	
  tests	
  that	
  we	
  should	
  execute	
  
   against	
  the	
  installed	
  MOSS	
  environment	
  
•  The	
  same	
  methodology	
  should	
  be	
  applied	
  when	
  performing	
  
   change	
  control	
  
•  Risk	
  assessment	
  should	
  be	
  reviewed	
  by	
  the	
  system	
  stake	
  
   holders	
  and	
  QA	
  for	
  completeness	
  before	
  moving	
  on	
  to	
  the	
  
   next	
  step	
  of	
  valida&on	
  




                                                                                                 25
<<Your Logo>>


Step	
  by	
  Step	
  CSV	
  Model	
  

•  GAMP5	
  is	
  a	
  standard	
  that	
  was	
  established	
  by	
  ISPE	
  
•  The	
  standard	
  provides	
  a	
  framework	
  for	
  achieving	
  compliant	
  GxP	
  
   computerized	
  systems	
  
•  This	
  standard	
  is	
  widely	
  recognized	
  and	
  understood	
  by	
  industry	
  
•  GAMP	
  provides	
  guidance	
  for	
  the	
  valida&on	
  of	
  different	
  categories	
  of	
  
   systems	
  
•  MOSS	
  would	
  be	
  considered	
  a	
  Configured	
  Off	
  the	
  Shelf	
  system	
  within	
  the	
  
   context	
  of	
  GAMP	
  
•  It	
  is	
  expected	
  that	
  these	
  systems	
  have	
  already	
  undergone	
  significant	
  
   valida&on	
  during	
  development	
  by	
  the	
  vendor	
  
•  Configured	
  off	
  the	
  shelf	
  systems	
  require	
  less	
  valida&on	
  effort	
  than	
  
   customized	
  systems	
  	
  	
  

                                                                                                              26
<<Your Logo>>


GAMP5	
  –	
  CSV	
  Framework	
  for	
  a	
  Configured	
  Product	
  
                                                                                                        Responsibility:
          User	
                                                                                          Sponsor
                                                                                  Requirements	
  
      Requirements	
  
      Specifica&on	
                                                                Tes&ng	
  (PQ)	
  



                  Func&onal	
                                          Func&onal	
  
                 Specifica&on	
                                        Tes&ng	
  (OQ)	
  



                           Configura&on	
                Configura&on	
  
                           Specifica&on	
                 Tes&ng	
  (IQ)	
  



                                             Configured	
  
                                              Product	
                                                    Supplier



                                         Supplier QMS
<<Your Logo>>


CSV	
  Documents	
  –	
  Valida&on	
  Plan	
  

•  Governs	
  the	
  valida&on	
  process	
  for	
  a	
  system	
  
•  Outlines:	
  
      –    Roles	
  and	
  responsibili&es	
  
      –    Valida&on	
  approach	
  and	
  risk	
  ra&onale	
  
      –    System	
  scope	
  and	
  pre-­‐requisite	
  requirements	
  
      –    Documenta&on	
  deliverables	
  for	
  the	
  system	
  
•  The	
  plan	
  should	
  be	
  high	
  level	
  and	
  flexible	
  whilst	
  clearly	
  specifying	
  what	
  is	
  
   required	
  to	
  achieve	
  compliance	
  
•  If	
  MOSS	
  is	
  to	
  be	
  deployed	
  in	
  a	
  controlled	
  and	
  non-­‐controlled	
  configura&on,	
  
   the	
  plan	
  should	
  clearly	
  state	
  that	
  only	
  the	
  controlled	
  environment	
  will	
  be	
  
   validated	
  
<<Your Logo>>


CSV	
  Documents	
  –	
  User	
  Requirements	
  Specifica&on	
  

 •  Document	
  that	
  defines:	
  
      –    business	
  (end	
  user)	
  requirements	
  
      –    func&onal	
  requirements	
  
      –    performance	
  requirements	
  
      –    regulatory	
  requirements	
  (including	
  21	
  CFR	
  Part	
  11	
  requirements)	
  
      –    system	
  architecture	
  and	
  security	
  requirements	
  
 •    Requirements	
  should	
  be	
  precise	
  and	
  measurable	
  
 •    Used	
  as	
  the	
  basis	
  for	
  developing	
  test	
  scripts	
  
 •    Try	
  to	
  priori&ze	
  requirements	
  (Must,	
  Should,	
  Want)	
  
 •    Try	
  and	
  minimize	
  requirements	
  and	
  avoid	
  sta&ng	
  the	
  obvious	
  for	
  known	
  
      OTS	
  systems	
  such	
  as	
  MOSS	
  
<<Your Logo>>


CSV	
  Documents	
  –	
  Traceability	
  Matrix	
  

•  It	
  is	
  strongly	
  recommended	
  that	
  a	
  traceability	
  matrix	
  is	
  
   maintained	
  throughout	
  the	
  life&me	
  of	
  the	
  system	
  
•  The	
  trace	
  matrix:	
  
     –    Links	
  test	
  scripts	
  to	
  user	
  and	
  func&onal	
  requirements	
  
     –    Ensures	
  that	
  all	
  requirements	
  are	
  adequately	
  tested	
  
     –    Indicates	
  the	
  risk	
  classifica&on	
  for	
  each	
  testable	
  requirement	
  
     –    Should	
  be	
  considered	
  a	
  living	
  document	
  and	
  therefore	
  versioned	
  and	
  
          updated	
  during	
  change	
  control	
  
<<Your Logo>>


CSV	
  Documents	
  –	
  Func&onal	
  Specifica&on	
  
•  Func&onal	
  specifica&ons	
  allow	
  us	
  to	
  describe	
  how	
  system	
  func&ons	
  will	
  
   meet	
  user	
  requirements	
  
•  The	
  func&onal	
  specifica&on	
  clearly	
  describes:	
  
      –    The	
  purpose	
  of	
  each	
  func&on	
  
      –    The	
  inputs	
  
      –    The	
  process	
  
      –    The	
  outputs	
  
•  Func&onal	
  specifica&ons	
  are	
  not	
  required	
  for	
  the	
  installa&on	
  and	
  
   configura&on	
  of	
  baseline	
  MOSS	
  
•  Func&onal	
  specifica&ons	
  should	
  be	
  developed	
  for:	
  
      –    Validated	
  InfoPath	
  forms	
  
      –    Validated	
  workflows	
  
      –    Custom	
  web	
  parts,	
  features	
  and	
  solu&ons	
  
      –    Integra&on	
  with	
  any	
  third	
  party	
  applica&ons	
  or	
  services	
  
<<Your Logo>>


CSV	
  Documents	
  –	
  Configura&on	
  Specifica&on	
  
•  The	
  configura&on	
  specifica&on	
  clearly	
  documents:	
  
      –  The	
  baseline	
  MOSS	
  parameters	
  and	
  architecture	
  required	
  for	
  installa&on	
  of	
  
         the	
  product	
  and	
  any	
  3rd	
  party	
  add-­‐ons	
  
      –  The	
  structure	
  of	
  the	
  controlled	
  environment,	
  notably:	
  
           •  Site	
  and	
  library	
  seongs	
  
           •  Libraries	
  
           •  Content	
  types	
  
           •  Columns	
  
           •  Security	
  groups	
  and	
  user	
  rights	
  
           •  Template	
  and	
  workflow	
  deployment	
  
•  The	
  specifica&on	
  can	
  be	
  versioned	
  and	
  used	
  to	
  document	
  the	
  execu&on	
  of	
  
   the	
  configura&on	
  in	
  MOSS	
  
•  The	
  specifica&on	
  should	
  be	
  updated	
  each	
  &me	
  changes	
  are	
  required	
  
   through	
  change	
  control	
  
<<Your Logo>>


CSV	
  Documents	
  –	
  Configura&on	
  Tes&ng	
  (IQ)	
  
•  Ensures	
  that	
  all	
  sodware	
  modules	
  are	
  installed	
  correctly	
  
•  Lists	
  step	
  by	
  step	
  process	
  for	
  the	
  installa&on	
  and	
  configura&on	
  of	
  all	
  
   sodware	
  modules	
  
•  Defines	
  expected	
  results	
  at	
  each	
  control	
  point	
  of	
  the	
  installa&on	
  
•  Ensures	
  that	
  all	
  documenta&on	
  is	
  in	
  place	
  and	
  that	
  the	
  system	
  is	
  
   adequately	
  protected	
  
•  Ensures	
  proper	
  verifica&on	
  of	
  the	
  structural	
  elements	
  i.e.	
  sites,	
  content	
  
   types	
  etc.	
  
•  It	
  is	
  recommended	
  to	
  develop	
  an	
  IQ	
  protocol	
  which	
  governs	
  the	
  overall	
  
   installa&on	
  and	
  configura&on	
  process	
  
•  Develop	
  IQ	
  scripts	
  for	
  the	
  installa&on	
  of	
  baseline	
  MOSS	
  and	
  3rd	
  party	
  add-­‐
   ons	
  in	
  all	
  validated	
  environments	
  
•  Develop	
  IQ	
  scripts	
  for	
  the	
  execu&on	
  of	
  the	
  configura&on	
  specifica&on	
  for	
  
   structural	
  MOSS	
  elements	
  
<<Your Logo>>


CSV	
  Documents	
  –	
  Func&onal	
  Tes&ng	
  (OQ)	
  

•  Consists	
  of	
  end	
  to	
  end	
  posi&ve	
  and	
  nega&ve	
  tes&ng	
  that	
  all	
  system	
  
   components	
  i.e.	
  hardware	
  and	
  sodware	
  are	
  opera&ng	
  as	
  intended	
  
•  Tests	
  are	
  executed	
  on	
  base	
  func&onality	
  by	
  end	
  users	
  and	
  IT	
  
•  Tests	
  are	
  governed	
  by	
  a	
  test	
  protocol	
  which	
  clearly	
  describes	
  the	
  test	
  and	
  
   devia&on	
  management	
  procedures	
  that	
  must	
  be	
  followed	
  
•  Tests	
  should	
  be	
  broken	
  down	
  into	
  test	
  scripts	
  by	
  func&onal	
  area,	
  linked	
  to	
  
   baseline	
  system	
  func&on,	
  and	
  be	
  approved	
  before	
  execu&on	
  
•  All	
  test	
  results	
  should	
  be	
  clearly	
  documented	
  using	
  good	
  documenta&on	
  
   prac&ces	
  (ALCOA)	
  
•  Use	
  of	
  adequate	
  risk	
  assessment	
  should	
  greatly	
  reduce	
  the	
  scope	
  of	
  OQ	
  
   for	
  OTS	
  MOSS	
  deployments	
  



                                                                                                                   34
<<Your Logo>>


CSV	
  Documents	
  –	
  Requirements	
  Tes&ng	
  (PQ)	
  

•  Requirements	
  tes&ng	
  consists	
  of	
  posi&ve	
  tes&ng	
  of	
  company	
  specific	
  
   configura&on	
  and	
  user	
  requirements	
  
•  Tests	
  are	
  executed	
  on	
  business	
  specific	
  func&onality	
  such	
  as	
  workflows	
  or	
  
   InfoPath	
  forms	
  that	
  were	
  iden&fied	
  as	
  being	
  testable	
  during	
  the	
  risk	
  
   assessment	
  exercise	
  
•  Tests	
  are	
  governed	
  by	
  a	
  test	
  protocol	
  which	
  clearly	
  describes	
  the	
  test	
  and	
  
   devia&on	
  management	
  procedures	
  that	
  must	
  be	
  followed	
  
•  Tests	
  should	
  be	
  broken	
  down	
  into	
  test	
  scripts	
  by	
  func&onal	
  area,	
  linked	
  to	
  
   user	
  and	
  func&onal	
  requirements,	
  and	
  be	
  approved	
  before	
  execu&on	
  
•  All	
  test	
  results	
  should	
  be	
  clearly	
  documented	
  using	
  good	
  documenta&on	
  
   prac&ces	
  (ALCOA)	
  
•  Tests	
  are	
  typically	
  executed	
  by	
  end	
  users	
  and	
  serve	
  as	
  a	
  user	
  acceptance	
  
   mechanism	
  
<<Your Logo>>


Final	
  Valida&on	
  Summary	
  Report	
  

•  Describes	
  how	
  the	
  valida&on	
  went,	
  verifies	
  that	
  all	
  devia&ons	
  
   are	
  closed,	
  and	
  provides	
  for	
  the	
  final	
  approval	
  of	
  the	
  CSV	
  
   document	
  package	
  to	
  allow	
  the	
  system	
  to	
  go	
  into	
  produc&on	
  
•  Individual	
  summary	
  reports	
  for	
  each	
  step	
  of	
  the	
  verifica&on	
  
   process	
  or	
  a	
  comprehensive	
  report	
  covering	
  all	
  steps	
  may	
  be	
  
   produced	
  
•  The	
  summary	
  report	
  should	
  clearly	
  show	
  that	
  the	
  valida&on	
  
   plan	
  and	
  protocols	
  were	
  followed	
  and	
  that	
  the	
  acceptance	
  
   criteria	
  for	
  puong	
  the	
  system	
  into	
  produc&on	
  have	
  been	
  met	
  
<<Your Logo>>


Configura&on	
  control	
  and	
  maintaining	
  the	
  validated	
  state	
  
•  Configura&on	
  control	
  should	
  be	
  governed	
  by	
  a	
  formal	
  MOSS	
  specific	
  
   procedure	
  in	
  addi&on	
  to	
  any	
  general	
  provisions	
  of	
  the	
  IT	
  Configura&on	
  
   control	
  SOP	
  	
  
•  This	
  procedure	
  should	
  govern	
  the	
  update	
  of	
  the	
  configura&on	
  specifica&on	
  
•  The	
  configura&on	
  specifica&on	
  should	
  be	
  used	
  to	
  clearly	
  document	
  
   updates	
  /	
  addi&ons	
  to	
  MOSS	
  	
  
•  Any	
  changes	
  to	
  the	
  validated	
  controlled	
  environment	
  must	
  also	
  be	
  
   documented	
  using	
  change	
  control	
  
•  Should	
  significant	
  changes	
  or	
  addi&ons	
  be	
  made,	
  a	
  new	
  valida&on	
  project	
  
   may	
  be	
  required	
  
•  For	
  workflows,	
  forms	
  or	
  features/solu&ons	
  it	
  is	
  impera&ve	
  to	
  correctly	
  
   evaluate	
  impact	
  and	
  risk	
  and	
  produce	
  adequate	
  test	
  scripts	
  properly	
  
   integrate	
  the	
  addi&onal	
  elements	
  into	
  the	
  current	
  environment	
  
<<Your Logo>>


Maximizing	
  quality	
  and	
  ROI	
  

•  Valida&on	
  can	
  be	
  expensive	
  and	
  &me	
  consuming	
  if	
  it	
  is	
  not	
  done	
  correctly	
  
•  By	
  defining	
  a	
  clear	
  valida&on	
  strategy	
  and	
  by	
  leveraging	
  risk	
  assessment	
  
   techniques,	
  we	
  are	
  able	
  to	
  focus	
  the	
  valida&on	
  effort	
  on	
  what	
  is	
  really	
  
   important	
  
•  Consider	
  acquiring	
  tried	
  and	
  tested	
  test	
  scripts	
  and/or	
  valida&on	
  packages	
  
   for	
  MOSS	
  /	
  third	
  party	
  add-­‐ons	
  so	
  as	
  to	
  reduce	
  the	
  amount	
  of	
  prepara&on	
  
   &me	
  and	
  improve	
  quality	
  
•  Make	
  sure	
  that	
  all	
  individuals	
  involved	
  in	
  the	
  valida&on	
  effort	
  are	
  fully	
  
   trained	
  and	
  understand	
  the	
  CSV	
  process	
  
•  Isolated	
  controlled	
  environments	
  facilitate	
  valida&on	
  and	
  configura&on	
  
   control	
  
•  Use	
  virtual	
  environments	
  so	
  as	
  to	
  facilitate	
  replica&on	
  between	
  produc&on	
  
   and	
  test	
  environments	
  

                                                                                                                    38
<<Your Logo>>


Lessons	
  learned	
  and	
  best	
  prac&ces	
  
•  Create	
  a	
  ‘Big	
  Picture’	
  of	
  your	
  MOSS	
  deployment	
  so	
  as	
  to	
  ensure	
  that	
  you	
  
   are	
  able	
  to	
  adequately	
  accommodate	
  all	
  of	
  your	
  controlled	
  and	
  non-­‐
   controlled	
  needs	
  	
  
•  Use	
  a	
  risk	
  based	
  approach	
  to	
  focus	
  and	
  reduce	
  valida&on	
  efforts	
  –	
  be	
  strict	
  
   otherwise	
  everything	
  becomes	
  high	
  risk…	
  
•  Remember	
  that	
  MOSS	
  is	
  an	
  off-­‐the-­‐shelf	
  product	
  and	
  that	
  you	
  should	
  limit	
  
   valida&on	
  scope	
  to	
  high	
  risk	
  business	
  and	
  regulatory	
  requirements	
  as	
  
   much	
  as	
  possible	
  
•  Establish	
  a	
  MOSS	
  valida&on	
  team	
  to	
  oversee	
  and	
  manage	
  the	
  valida&on	
  
   process	
  and	
  changes	
  to	
  the	
  controlled	
  MOSS	
  environment	
  	
  
•  Implement	
  SOPs	
  and	
  WIs	
  which	
  clearly	
  define	
  how	
  the	
  environment	
  is	
  
   configured	
  and	
  administered	
  and	
  which	
  level	
  of	
  documenta&on	
  /	
  re-­‐
   valida&on	
  is	
  required	
  by	
  type	
  of	
  change	
  
•  Use	
  a	
  step	
  by	
  step	
  deployment	
  methodology	
  to	
  keep	
  things	
  manageable	
  
                                                                                                                     39
<<Your Logo>>




It is easy to drown
   in the details…
   Try and keep it
       SIMPLE!
        Contact Info:
  pfenton@montrium.com
 Tel. 514-223-9153 ext. 206

                                          40
41

More Related Content

What's hot

Myths of validation
Myths of validationMyths of validation
Myths of validation
Jeff Thomas
 
Strategies for Conducting GxP Vendor Assessment of Cloud Service Providers - ...
Strategies for Conducting GxP Vendor Assessment of Cloud Service Providers - ...Strategies for Conducting GxP Vendor Assessment of Cloud Service Providers - ...
Strategies for Conducting GxP Vendor Assessment of Cloud Service Providers - ...
Montrium
 
Network Infrastructure Validation Conference @UPRA (2003)
Network Infrastructure Validation Conference @UPRA (2003)Network Infrastructure Validation Conference @UPRA (2003)
Network Infrastructure Validation Conference @UPRA (2003)
Raul Soto
 
21 cfr part 11
21 cfr part 1121 cfr part 11
21 cfr part 11
roshankhetade2
 
21 cfr part 11 an approach towards compliance
21 cfr part 11   an approach towards compliance21 cfr part 11   an approach towards compliance
21 cfr part 11 an approach towards compliance
deepak mishra
 
FDA 21 CFR Part 11 and Related Regulations and Guidances
FDA 21 CFR Part 11 and Related Regulations and GuidancesFDA 21 CFR Part 11 and Related Regulations and Guidances
FDA 21 CFR Part 11 and Related Regulations and Guidances
Institute of Validation Technology
 
Computer System Validation
Computer System ValidationComputer System Validation
Computer System Validation
Eric Silva
 
Case Study – Deploying SharePoint Based eTMF in the Cloud
Case Study – Deploying SharePoint Based eTMF in the CloudCase Study – Deploying SharePoint Based eTMF in the Cloud
Case Study – Deploying SharePoint Based eTMF in the Cloud
Montrium
 
Overview on “Computer System Validation” CSV
Overview on  “Computer System Validation” CSVOverview on  “Computer System Validation” CSV
Overview on “Computer System Validation” CSV
Anil Sharma
 
ISPE-CCPIE China Conference 2010 (Stokes-GAMP Legacy Systems - English)
ISPE-CCPIE China Conference 2010 (Stokes-GAMP Legacy Systems - English)ISPE-CCPIE China Conference 2010 (Stokes-GAMP Legacy Systems - English)
ISPE-CCPIE China Conference 2010 (Stokes-GAMP Legacy Systems - English)
David Stokes
 
IT Validation Training
IT Validation TrainingIT Validation Training
IT Validation Training
Robert Sturm
 
Computerized system validation_final
Computerized system validation_finalComputerized system validation_final
Computerized system validation_final
Duy Tan Geek
 
SharePoint Configuration Management – Effective Techniques for Regulated Shar...
SharePoint Configuration Management – Effective Techniques for Regulated Shar...SharePoint Configuration Management – Effective Techniques for Regulated Shar...
SharePoint Configuration Management – Effective Techniques for Regulated Shar...
Montrium
 
21 CFR part 11 Overview
21 CFR part 11 Overview21 CFR part 11 Overview
21 CFR part 11 Overview
Zahid Munir Choudhry
 
Computerized System Validation : Understanding basics
Computerized System Validation : Understanding basics Computerized System Validation : Understanding basics
Computerized System Validation : Understanding basics
Anand Pandya
 
Kelis king - a storehouse of vast knowledge on software testing and quality ...
Kelis king  - a storehouse of vast knowledge on software testing and quality ...Kelis king  - a storehouse of vast knowledge on software testing and quality ...
Kelis king - a storehouse of vast knowledge on software testing and quality ...
KelisKing
 
Computer System Validation - The Validation Master Plan
Computer System Validation - The Validation Master PlanComputer System Validation - The Validation Master Plan
Computer System Validation - The Validation Master Plan
Wolfgang Kuchinke
 
Codex validation Group presentation
Codex validation Group presentationCodex validation Group presentation
Codex validation Group presentation
Walter Acevedo
 
Gamp Riskbased Approch To Validation
Gamp Riskbased Approch To ValidationGamp Riskbased Approch To Validation
Gamp Riskbased Approch To Validation
Rajendra Sadare
 
Computerized system validation
Computerized system validationComputerized system validation
Computerized system validation
Devipriya Viswambharan
 

What's hot (20)

Myths of validation
Myths of validationMyths of validation
Myths of validation
 
Strategies for Conducting GxP Vendor Assessment of Cloud Service Providers - ...
Strategies for Conducting GxP Vendor Assessment of Cloud Service Providers - ...Strategies for Conducting GxP Vendor Assessment of Cloud Service Providers - ...
Strategies for Conducting GxP Vendor Assessment of Cloud Service Providers - ...
 
Network Infrastructure Validation Conference @UPRA (2003)
Network Infrastructure Validation Conference @UPRA (2003)Network Infrastructure Validation Conference @UPRA (2003)
Network Infrastructure Validation Conference @UPRA (2003)
 
21 cfr part 11
21 cfr part 1121 cfr part 11
21 cfr part 11
 
21 cfr part 11 an approach towards compliance
21 cfr part 11   an approach towards compliance21 cfr part 11   an approach towards compliance
21 cfr part 11 an approach towards compliance
 
FDA 21 CFR Part 11 and Related Regulations and Guidances
FDA 21 CFR Part 11 and Related Regulations and GuidancesFDA 21 CFR Part 11 and Related Regulations and Guidances
FDA 21 CFR Part 11 and Related Regulations and Guidances
 
Computer System Validation
Computer System ValidationComputer System Validation
Computer System Validation
 
Case Study – Deploying SharePoint Based eTMF in the Cloud
Case Study – Deploying SharePoint Based eTMF in the CloudCase Study – Deploying SharePoint Based eTMF in the Cloud
Case Study – Deploying SharePoint Based eTMF in the Cloud
 
Overview on “Computer System Validation” CSV
Overview on  “Computer System Validation” CSVOverview on  “Computer System Validation” CSV
Overview on “Computer System Validation” CSV
 
ISPE-CCPIE China Conference 2010 (Stokes-GAMP Legacy Systems - English)
ISPE-CCPIE China Conference 2010 (Stokes-GAMP Legacy Systems - English)ISPE-CCPIE China Conference 2010 (Stokes-GAMP Legacy Systems - English)
ISPE-CCPIE China Conference 2010 (Stokes-GAMP Legacy Systems - English)
 
IT Validation Training
IT Validation TrainingIT Validation Training
IT Validation Training
 
Computerized system validation_final
Computerized system validation_finalComputerized system validation_final
Computerized system validation_final
 
SharePoint Configuration Management – Effective Techniques for Regulated Shar...
SharePoint Configuration Management – Effective Techniques for Regulated Shar...SharePoint Configuration Management – Effective Techniques for Regulated Shar...
SharePoint Configuration Management – Effective Techniques for Regulated Shar...
 
21 CFR part 11 Overview
21 CFR part 11 Overview21 CFR part 11 Overview
21 CFR part 11 Overview
 
Computerized System Validation : Understanding basics
Computerized System Validation : Understanding basics Computerized System Validation : Understanding basics
Computerized System Validation : Understanding basics
 
Kelis king - a storehouse of vast knowledge on software testing and quality ...
Kelis king  - a storehouse of vast knowledge on software testing and quality ...Kelis king  - a storehouse of vast knowledge on software testing and quality ...
Kelis king - a storehouse of vast knowledge on software testing and quality ...
 
Computer System Validation - The Validation Master Plan
Computer System Validation - The Validation Master PlanComputer System Validation - The Validation Master Plan
Computer System Validation - The Validation Master Plan
 
Codex validation Group presentation
Codex validation Group presentationCodex validation Group presentation
Codex validation Group presentation
 
Gamp Riskbased Approch To Validation
Gamp Riskbased Approch To ValidationGamp Riskbased Approch To Validation
Gamp Riskbased Approch To Validation
 
Computerized system validation
Computerized system validationComputerized system validation
Computerized system validation
 

Viewers also liked

The Good vs. Bad: The Specifics for Validating CMS Data
The Good vs. Bad: The Specifics for Validating CMS DataThe Good vs. Bad: The Specifics for Validating CMS Data
The Good vs. Bad: The Specifics for Validating CMS Data
All4 Inc.
 
Initiative for an eTMF Exchange Mechanism from the TMF Reference Model
Initiative for an eTMF Exchange Mechanism from the TMF Reference ModelInitiative for an eTMF Exchange Mechanism from the TMF Reference Model
Initiative for an eTMF Exchange Mechanism from the TMF Reference Model
Montrium
 
Practical considerations for eTMF Planning
Practical considerations for eTMF PlanningPractical considerations for eTMF Planning
Practical considerations for eTMF Planning
Paragon Solutions
 
eTMF ppt
eTMF ppteTMF ppt
CDISC & Risk Based Monitoring to Compress Clinical Trial Duration
CDISC & Risk Based Monitoring to Compress Clinical Trial DurationCDISC & Risk Based Monitoring to Compress Clinical Trial Duration
CDISC & Risk Based Monitoring to Compress Clinical Trial Duration
Clinical Data Inc .
 
Executing Validation of GxP Systems Electronically using SharePoint
Executing Validation of GxP Systems Electronically using SharePointExecuting Validation of GxP Systems Electronically using SharePoint
Executing Validation of GxP Systems Electronically using SharePoint
Montrium
 
Change Control Form
Change Control FormChange Control Form

Viewers also liked (7)

The Good vs. Bad: The Specifics for Validating CMS Data
The Good vs. Bad: The Specifics for Validating CMS DataThe Good vs. Bad: The Specifics for Validating CMS Data
The Good vs. Bad: The Specifics for Validating CMS Data
 
Initiative for an eTMF Exchange Mechanism from the TMF Reference Model
Initiative for an eTMF Exchange Mechanism from the TMF Reference ModelInitiative for an eTMF Exchange Mechanism from the TMF Reference Model
Initiative for an eTMF Exchange Mechanism from the TMF Reference Model
 
Practical considerations for eTMF Planning
Practical considerations for eTMF PlanningPractical considerations for eTMF Planning
Practical considerations for eTMF Planning
 
eTMF ppt
eTMF ppteTMF ppt
eTMF ppt
 
CDISC & Risk Based Monitoring to Compress Clinical Trial Duration
CDISC & Risk Based Monitoring to Compress Clinical Trial DurationCDISC & Risk Based Monitoring to Compress Clinical Trial Duration
CDISC & Risk Based Monitoring to Compress Clinical Trial Duration
 
Executing Validation of GxP Systems Electronically using SharePoint
Executing Validation of GxP Systems Electronically using SharePointExecuting Validation of GxP Systems Electronically using SharePoint
Executing Validation of GxP Systems Electronically using SharePoint
 
Change Control Form
Change Control FormChange Control Form
Change Control Form
 

Similar to SharePoint And 21 CFR Part 11 Share Fest

21 CFR Part 11 checklist software.pptx
21 CFR Part 11 checklist software.pptx21 CFR Part 11 checklist software.pptx
21 CFR Part 11 checklist software.pptx
AartiVats5
 
PSI Pharmaway 1.0
PSI Pharmaway 1.0PSI Pharmaway 1.0
PSI Pharmaway 1.0
Dash Way
 
Tools for Accelerating Validation of Office 365
Tools for Accelerating Validation of Office 365Tools for Accelerating Validation of Office 365
Tools for Accelerating Validation of Office 365
Montrium
 
Data Integrity II - Chromatography data system (CDS) in Pharma
Data Integrity II - Chromatography data system (CDS) in PharmaData Integrity II - Chromatography data system (CDS) in Pharma
Data Integrity II - Chromatography data system (CDS) in Pharma
Sathish Vemula
 
MES systems
MES systemsMES systems
MES systems
Barry Curry
 
Compliance at Velocity with Chef
Compliance at Velocity with ChefCompliance at Velocity with Chef
Compliance at Velocity with Chef
James Casey
 
1 - Introduction to Computerized Systems Validation - for review.pptx
1 - Introduction to Computerized Systems Validation - for review.pptx1 - Introduction to Computerized Systems Validation - for review.pptx
1 - Introduction to Computerized Systems Validation - for review.pptx
patemalabanan
 
Software Engineering (Software Configuration Management)
Software Engineering (Software Configuration Management)Software Engineering (Software Configuration Management)
Software Engineering (Software Configuration Management)
ShudipPal
 
Enterprise Risk Management Solutions
Enterprise Risk Management SolutionsEnterprise Risk Management Solutions
Enterprise Risk Management Solutions
LexComply
 
Epitome Corporate PPT
Epitome Corporate PPTEpitome Corporate PPT
Epitome Corporate PPT
Epitome Technologies Training
 
Calibration/PM and Asset Management in Bio-Med Applications
Calibration/PM and Asset Management in Bio-Med ApplicationsCalibration/PM and Asset Management in Bio-Med Applications
Calibration/PM and Asset Management in Bio-Med Applications
Sanjay Dhal , MS, MBA
 
INTRODUCTION to software engineering requirements specifications
INTRODUCTION to software engineering requirements specificationsINTRODUCTION to software engineering requirements specifications
INTRODUCTION to software engineering requirements specifications
kylan2
 
SOP Management Factsheet
SOP Management FactsheetSOP Management Factsheet
SOP Management Factsheet
NextDocs
 
SOX Cloud Criteria Cloud Hosted Accounting
SOX Cloud Criteria Cloud Hosted AccountingSOX Cloud Criteria Cloud Hosted Accounting
SOX Cloud Criteria Cloud Hosted Accounting
RoseASP
 
Software configuration management
Software configuration managementSoftware configuration management
Software configuration management
Julia Carolina
 
SaaS System Validation, practical tips on getting validated for go-live and t...
SaaS System Validation, practical tips on getting validated for go-live and t...SaaS System Validation, practical tips on getting validated for go-live and t...
SaaS System Validation, practical tips on getting validated for go-live and t...
Steffan Stringer
 
Requirement management traceability.ppt
Requirement management  traceability.pptRequirement management  traceability.ppt
Requirement management traceability.ppt
ubaidullah75790
 
Requirments management traceability.ppt
Requirments  management traceability.pptRequirments  management traceability.ppt
Requirments management traceability.ppt
ubaidullah75790
 
Achieving IT Governance and compliance using Kovair
Achieving IT Governance and compliance using KovairAchieving IT Governance and compliance using Kovair
Achieving IT Governance and compliance using Kovair
Kovair
 
Getting It Right
Getting It RightGetting It Right
Getting It Right
Scott Sehlhorst
 

Similar to SharePoint And 21 CFR Part 11 Share Fest (20)

21 CFR Part 11 checklist software.pptx
21 CFR Part 11 checklist software.pptx21 CFR Part 11 checklist software.pptx
21 CFR Part 11 checklist software.pptx
 
PSI Pharmaway 1.0
PSI Pharmaway 1.0PSI Pharmaway 1.0
PSI Pharmaway 1.0
 
Tools for Accelerating Validation of Office 365
Tools for Accelerating Validation of Office 365Tools for Accelerating Validation of Office 365
Tools for Accelerating Validation of Office 365
 
Data Integrity II - Chromatography data system (CDS) in Pharma
Data Integrity II - Chromatography data system (CDS) in PharmaData Integrity II - Chromatography data system (CDS) in Pharma
Data Integrity II - Chromatography data system (CDS) in Pharma
 
MES systems
MES systemsMES systems
MES systems
 
Compliance at Velocity with Chef
Compliance at Velocity with ChefCompliance at Velocity with Chef
Compliance at Velocity with Chef
 
1 - Introduction to Computerized Systems Validation - for review.pptx
1 - Introduction to Computerized Systems Validation - for review.pptx1 - Introduction to Computerized Systems Validation - for review.pptx
1 - Introduction to Computerized Systems Validation - for review.pptx
 
Software Engineering (Software Configuration Management)
Software Engineering (Software Configuration Management)Software Engineering (Software Configuration Management)
Software Engineering (Software Configuration Management)
 
Enterprise Risk Management Solutions
Enterprise Risk Management SolutionsEnterprise Risk Management Solutions
Enterprise Risk Management Solutions
 
Epitome Corporate PPT
Epitome Corporate PPTEpitome Corporate PPT
Epitome Corporate PPT
 
Calibration/PM and Asset Management in Bio-Med Applications
Calibration/PM and Asset Management in Bio-Med ApplicationsCalibration/PM and Asset Management in Bio-Med Applications
Calibration/PM and Asset Management in Bio-Med Applications
 
INTRODUCTION to software engineering requirements specifications
INTRODUCTION to software engineering requirements specificationsINTRODUCTION to software engineering requirements specifications
INTRODUCTION to software engineering requirements specifications
 
SOP Management Factsheet
SOP Management FactsheetSOP Management Factsheet
SOP Management Factsheet
 
SOX Cloud Criteria Cloud Hosted Accounting
SOX Cloud Criteria Cloud Hosted AccountingSOX Cloud Criteria Cloud Hosted Accounting
SOX Cloud Criteria Cloud Hosted Accounting
 
Software configuration management
Software configuration managementSoftware configuration management
Software configuration management
 
SaaS System Validation, practical tips on getting validated for go-live and t...
SaaS System Validation, practical tips on getting validated for go-live and t...SaaS System Validation, practical tips on getting validated for go-live and t...
SaaS System Validation, practical tips on getting validated for go-live and t...
 
Requirement management traceability.ppt
Requirement management  traceability.pptRequirement management  traceability.ppt
Requirement management traceability.ppt
 
Requirments management traceability.ppt
Requirments  management traceability.pptRequirments  management traceability.ppt
Requirments management traceability.ppt
 
Achieving IT Governance and compliance using Kovair
Achieving IT Governance and compliance using KovairAchieving IT Governance and compliance using Kovair
Achieving IT Governance and compliance using Kovair
 
Getting It Right
Getting It RightGetting It Right
Getting It Right
 

SharePoint And 21 CFR Part 11 Share Fest

  • 1. SharePoint and 21 CFR Part 11 A Risk-Based Validation Approach for Life Sciences Paul Fenton VP Pharmaceutical Processes and Technology 1
  • 2. <<Your Logo>> Overview   •  Objec&ves  of  valida&on   •  Regulatory  requirements   •  How  to  iden&fy  electronic  records   •  Deploying  controlled  and  non-­‐controlled  MOSS  environments   •  Risk  evalua&on  methods  and  scoping  the  valida&on  strategy   •  Step  by  Step  overview  of  the  risk-­‐based  valida&on  process  following  the   GAMP5  model   •  Implemen&ng  effec&ve  configura&on  and  change  control  procedures  for   MOSS   •  Maximizing  quality  and  ROI     •  Lessons  learned  and  best  prac&ces   •  Q&A   2
  • 3. <<Your Logo>> What  is  Computer  Systems  Valida&on?   •  A  formal  process  to  ensure  that:   –  systems    consistently  operate  as  they  were  intended     –  user,  business  and  regulatory  system  requirements   are  met   –  informa&on  is  secure  and  properly  managed  by  the   system   –  procedures  and  processes  are  in  place  for  the  use   and  management  of  the  system  
  • 4. <<Your Logo>> What  the  regula&ons  say…   •  FDA:  21  CFR  Part  11     §11.10(a)  Valida&on  of  systems  to  ensure  accuracy,   reliability,  consistent  intended  performance,  and   the  ability  to  discern  invalid  or  altered  records.   •  ICH  E6  –  GCP   §5.5.3(a)  Ensure  and  document  that  the  electronic   data  processing  system(s)  conforms  to  the   sponsor’s  established  requirements  for   completeness,  accuracy,  reliability  and  consistent   intended  performance  (i.e.  valida&on)   4
  • 5. <<Your Logo>> What  the  regula&ons  say….   •  FDA:  CSUCI   §F5  Change  Control  -­‐  The  integrity  of  the  data  and  the   integrity  of  the  protocols  should  be  maintained  when   making  changes  to  the  computerized  system,  such  as   sodware  upgrades,  including  security  and  performance   patches,  equipment,  or  component  replacement,  or  new   instrumenta&on.  The  effects  of  any  changes  to  the  system   should  be  evaluated  and  some  should  be  validated   depending  on  risk.  Changes  that  exceed  previously   established  opera&onal  limits  or  design  specifica&ons   should  be  validated.  Finally,  all  changes  to  the  system   should  be  documented.   5
  • 6. <<Your Logo>> Other  important  guidance  documents   •  PIC/S  Annex  11  –  PI  011-­‐3  Good  Prac&ces  for   Computerised  Systems  in  Regulated  GxP   Envrionments  (2007)   •  US  FDA:  General  Principles  of  Sodware   Valida&on;  Final  Guidance  for  Industry  and   FDA  Staff  (2002)   6
  • 7. <<Your Logo>> What  is  expected?   •  That  procedures  should  be  in  place  to  ensure  that   systems  used  in  regulated  ac&vi&es  are  adequately   validated   •  That  systems  should  be  maintained  in  a  validated  state   through  effec&ve  change  control  mechanisms   •  That  sponsors  take  a  risk  based  approach  to  computer   systems  valida&on  (CSV)   •  That  individuals  involved  in  CSV  ac&vi&es  and  the   maintenance  of  validated  systems  have  adequate   experience  and  training  
  • 8. <<Your Logo>> How  to  iden&fy  electronic  records   •  21  CFR  Part  11  defines  electronic  records  as:   –  Records  that  are  required  to  be  maintained  under  predicate  rule   requirements  and  that  are  maintained  in  electronic  format  in  place  of   paper  format   –  Records  that  are  required  to  be  maintained  under  predicate  rules,  that   are  maintained  in  electronic  format  in  addi/on  to  paper  format,  and   that  are  relied  on  to  perform  regulated  ac/vi/es   –  Records  submihed  to  FDA,  under  predicate  rules  (even  if  such  records   are  not  specifically  iden&fied  in  Agency  regula&ons)  in  electronic   format   –  Electronic  signatures  that  are  intended  to  be  the  equivalent  of   handwrihen  signatures,  ini&als,  and  other  general  signings  required  by   predicate  rules   8
  • 9. <<Your Logo>> Electronic  Records  within  MOSS   •  Records  within  the  context  of  MOSS  could  be:   –  Documents  (excluding  descrip&ve  metadata)   required  to  be  maintained  by  predicate  rule   –  Metadata  (Columns)  used  to  perform  regulated   ac&vi&es  (or  make  regulated  decisions)   –  InfoPath  forms  used  to  document  regulated   ac&vi&es   9
  • 10. <<Your Logo>> Electronic  Records  within  MOSS   –  Electronic  /  Digital  Signatures  used  to  sign  records   required  by  predicate  rules   –  Audit  Trails  generated  for  electronic  records  being   generated  and/or  managed  in  MOSS   10
  • 11. <<Your Logo>> How  to  iden&fy  electronic  records     •  Points  to  consider:   –  Does  the  record  exist  in  electronic  format  only  with  no  paper  source?   –  Is  the  record  required  by  predicate  rule?   –  Does  the  record  drive  a  regulated  process  or  decision?   •  If  the  answer  to  any  of  the  above  is  ‘Yes’  then  21  CFR  Part  11     applies  and  your  system  must  be  validated   •  You  should  document  this  in  a  valida&on  assessment   document  or  valida&on  plan.  You  should  also  clearly  iden&fy   the  scope  of  valida&on  in  this  document   •  This  document  can  help  structure  your  MOSS  deployment  into   controlled  and  non-­‐controlled  environments   11
  • 12. <<Your Logo>> Controlled  vs.  Non-­‐Controlled  MOSS  Architecture   •  MOSS  can  be  used  across  the  enterprise  for  many  different   applica&ons  and  groups   •  It  is  impera&ve  to  make  a  clear  separa&on  between  controlled   (validated)  and  non-­‐controlled  environments   •  This  can  be  achieved  by  deploying  an  independent  web   applica&on/site  collec&on  or  controlled  sites  for  regulated   documents  and  processes   •  There  are  advantages  and  disadvantages  to  both  models  due   to  limita&ons  of  MOSS   •  These  architecture  models  aim  to  offer  both  flexibility  and   control  and  reduce  valida&on  /  change  control  scope   12
  • 13. <<Your Logo>> Controlled  vs.  Non-­‐Controlled  –  Integrated  Op&on   Central  Admin   • Features and Solutions (Scope must be controlled) Admin   • Administered Forms (Scope must be controlled)  DB   • Controlled Content Types Validated  Web  Applica&on   • Controlled Security Groups • Controlled Columns Top  Level  Site  Collec&on  (Controlled)   • Controlled Templates • Controlled Lists Content   DB   Uncontrolled  Func&onal   Controlled  Func&onal   Record  Center  or   Sites   Sites  –  Validated   Document  Repository  –   Custom   • Uncontrolled Content Types Send-­‐To  /   Custom   Validated   Hyperlinks   Send-­‐To  /   • Uncontrolled Columns Hyperlinks   • Uncontrolled Lists • Uncontrolled Security Groups • Controlled Site and Library • Information Management • Uncontrolled Templates structures Policies • Non-validated Features and • Validated Features and • Records Mgt Site Structures Solutions Solutions • Record Mapping • Non-validated Workflows •  Validated Workflows •  Validated Dashboards 13
  • 14. <<Your Logo>> Controlled  vs.  Non-­‐Controlled  –  Isolated  Op&on   Central  Admin   • Features and Solutions (Scope must be controlled) Admin   • Administered Forms (Scope must be controlled)  DB   Uncontrolled  Web  Applica&on   Validated  Controlled  Web  Applica&on   • Uncontrolled Templates • Controlled Content Types • Controlled Security Groups • Uncontrolled Content Types • Controlled Columns • Controlled Templates • Uncontrolled Columns • Controlled Lists • Uncontrolled Lists Content   • Uncontrolled Security Groups DB   Content   DB   Controlled  Func&onal   Record  Center  or   Sites  –  Validated   Custom   Document  Repository  –   Uncontrolled  Func&onal   Hyperlinks   Send-­‐To  /   Validated   Sites   Hyperlinks   • Non-validated Features and • Controlled Site and Library • Information Management Solutions structures Policies • Non-validated Workflows • Validated Features and • Records Mgt Site Structures Solutions • Record Mapping •  Validated Workflows •  Validated Dashboards 14
  • 15. <<Your Logo>> Example  of  Controlled  and  Non-­‐Controlled  Environment   Central   Admin  /  TLS   Uncontrolled   Controlled   Workspace   Workspace   Records   ClinOps   PV   CMC   RegOps   HR   ClinOps   PV   CMC   RegOps   Center   Validated Environment 15
  • 16. <<Your Logo>> Risk  Evalua&on  and  Scoping  the  Valida&on  Strategy   •  Agencies  are  ac&vely  encouraging  the  use  of  risk  based   approaches  for  the  valida&on  of  computerized  systems  used   in  GxP  environments   •  The  use  of  a  risk  based  approach  allows  us  to  focus  on  high   risk  areas  whilst  reducing  the  valida&on  effort  and  improving   quality   •  When  star&ng  the  deployment  of  MOSS  in  regulated   environments,  it  is  important  to  evaluate  risk  so  as  to  focus   valida&on  efforts  on  high  risk  areas   •  Risk  should  be  measured  at  two  levels:   –  General  procedural  risk   –  Detailed  func&onal  risk   16
  • 17. <<Your Logo>> Risk  Evalua&on  and  Scoping  the  Valida&on  Strategy   •  Risk  can  be  iden&fied  as  either  regulatory  risk  or   business  risk   •  You  should  clearly  specify  that  you  intend  to  adopt  a   risk  based  approach  in  your  valida&on  plan  and  also   explain  the  ra&onale  behind  the  approach   •  Ensure  that  risk  assessment  is  carried  out  by  a   knowledgeable  team   •  Be  strict  as  everything  can  end  up  being  high-­‐risk   with  enough  debate….   17
  • 18. <<Your Logo>> Risk  based  approach  101  –  Iden&fy  Scope   •  Step  1  -­‐  When  defining  the  scope  of  your  MOSS  deployment  clearly   iden&fy  regulated  procedures  and  records  that  will  be  generated  or   managed  by  the  system   MOSS Examples: 1.  MOSS will be used to generate submission ready electronic PDF records that will be submitted to FDA as part of our INDs 2.  MOSS will be used to control the drug shipment authorization process for clinical sites 3.  MOSS will be used to generate CAPA records for our GMP facility 4.  MOSS will be used to manage audit report observations IMPORTANT:  If  MOSS  will  not  be  used  for  processes  or  records  that  are   governed  by  predicate  rules…there  is  no  regulatory  requirement  to   validate!   18
  • 19. <<Your Logo>> Risk  based  approach  101  –  Risk  Type  /  GxP  Determina&on   •  Step  2  -­‐  Associate  a  type  of  risk  (regulatory  or  business)  to  each  record  or   process  based  on  the  following  criteria:   A.  Is  the  record  or  procedure  governed  or  required  by  predicate  rule?   B.  Does  the  procedure  or  record  have  an  impact  on  subject  safety?   C.  Does  the  procedure  or  record  have  an  impact  of  product  quality?   D.  Does  the  procedure  or  record  have  an  impact  on  data  integrity?   E.  Does  the  procedure  or  record  have  a  important  impact  on  our  ability  to  carry  out  the   daily  tasks  of  our  business?   MOSS Examples: 1.  MOSS will be used to generate submission ready electronic PDF records that will be submitted to FDA as part of our INDs – Regulatory risk (A) 2.  MOSS will be used to control the drug shipment authorization process for clinical sites – Regulatory Risk (B) 3.  MOSS will be used to generate CAPA records for our GMP facility – Regulatory Risk (C) 4.  MOSS will be used to manage audit report observations – Regulatory and Business Risk (A-E) IMPORTANT: If a procedure or record has no regulatory risk associated, it may be excluded from the validation effort provided that adequate rationale is provided 19
  • 20. <<Your Logo>> Risk  based  approach  101  –  Risk  Scenarios   •  Step  3  –  Define  risk  scenarios  for  each  process  or  record  iden&fied.   Scenarios  should  include:   –  Poten&al  risk   –  Likelihood  of  occurrence/detec&on     –  Impact   –  Pallia&ve  ac&ons   MOSS Example: 1.  MOSS will be used to control the drug shipment authorization process for clinical sites – Regulatory Risk (B) Risk Scenario A: •  Risk: IRB approval has not been received and a subject is enrolled in study and treated •  Likelihood: Medium – Due to combination of procedural and system controls •  Impact: High – Treating subjects without IRB approval considered a serious deviation •  Palliative Action: Ensure that drug cannot be shipped to site before IRB approval has been received through system and procedural controls 20
  • 21. <<Your Logo>> Risk  based  approach  101  –  Link  System  Func&ons  to  Scope     •  Step  4  –  Once  processes  and  records  have  been  classified  by  procedural   risk,  they  must  be  linked  to  the  system  func&onality  defined  in  the  user   requirements  specifica&on  (URS):   MOSS Example: Process  /  Record   URS  ID   Requirement   MOSS  will  be  used  to   UR3.1.   The  system  should  allow  the  automa&c  genera&on  of  PDF   generate  submission   v1.4.  files   ready  electronic  PDF   UR3.2.   The  system  should  allow  the  electronic  signature  of   records  that  will  be   records   submihed  to  FDA  as   part  of  our  INDs   UR3.3.   The  system  should  be  able  to  invalidate  electronic   signatures  if  the  signed  record  is  modified   UR3.4.   The  system  should  manage  the  version  number  of   records   UR3.5.   The  system  should  be  capable  of  rendering  final  records   read-­‐only   21
  • 22. <<Your Logo>> Risk  based  approach  101  –  GAMP  Risk  Evalua&on  method   Probability Detectability Medium Medium High High Low Low Risk Class 2 1 1 M H H Risk Class Priority Severity High 1 Risk 3 2 1 Medium L M H Low 3 3 2 2 3 L L M M Severity = Impact on Patient Safety, Detectability = Likelihood that Product Quality or Data Integrity the fault is detected before harm Probability = Likelihood of fault occurs occurring Priority = Risk Class x Risk Class = Severity x Probability Detectability 22
  • 23. <<Your Logo>> Risk  based  approach  101  –  Decide  on  risk  acceptability  level   •  Step  5  –  Based  on  the  type  of  system  and  the  high  level  risk  assessment   we  must  decide  on  what  level  of  risk  must  be  tested  for  during  valida&on   –  Custom  built  systems  or  components  tend  to  present  a  higher  level  of  risk  than   OTS  systems   –  It  may  be  appropriate  to  exclude  business  risk  from  tes&ng   –  The  valida&on  plan  should  specify  the  acceptable  risk  levels  with  ra&onale   MOSS Example: 1.  All OTS MOSS functions that have a risk rating of low or medium will not be formally tested during validation. These functions are deemed to be adequately tested by the vendor. 2.  All custom applications deployed within the MOSS environment that have GxP impact and a risk rating of medium or high will be formally tested during validation. Low risk functions and functions that do not have GxP impact will be informally verified during the build phase. 23
  • 24. <<Your Logo>> Risk  based  approach  101  –  Evaluate  System  Func&ons   •  Step  6  –  Once  processes  and  records  have  been  linked  to  system  func&ons,   a  risk  evalua&on  of  each  func&on  involved  is  undertaken:   MOSS Example: Process  /   URS  ID   Requirement   Risk  Scenario   Severity  /  Probability  /   Test  Y/N   Record   Detectability   Low  (L),  Medium  (M),   High  (H)   MOSS  will  be   UR3.1.   The  system  should  allow   PDF  Files  are   used  to   the  automa&c  genera&on  of   generated  in  the   M   L   H   No     L generate   PDF  v1.4.  files   incorrect  format   submission   UR3.2.   The  system  should  allow   Record  cannot  be   ready   L   M   H   the  electronic  signature  of   signed   No   L electronic   records   PDF  records   that  will  be   UR3.3.   The  system  should  be  able   Signature   submihed  to   to  invalidate  electronic   remains  valid   H   M   L   Yes   H FDA  as  part   signatures  if  the  signed   ader  record   of  our  INDs   record  is  modified   modifica&on   24
  • 25. <<Your Logo>> Risk  based  approach  101  -­‐  Comple&on   •  The  result  of  the  func&onal  risk  assessment  provides  us  with   the  founda&on  for  the  various  tests  that  we  should  execute   against  the  installed  MOSS  environment   •  The  same  methodology  should  be  applied  when  performing   change  control   •  Risk  assessment  should  be  reviewed  by  the  system  stake   holders  and  QA  for  completeness  before  moving  on  to  the   next  step  of  valida&on   25
  • 26. <<Your Logo>> Step  by  Step  CSV  Model   •  GAMP5  is  a  standard  that  was  established  by  ISPE   •  The  standard  provides  a  framework  for  achieving  compliant  GxP   computerized  systems   •  This  standard  is  widely  recognized  and  understood  by  industry   •  GAMP  provides  guidance  for  the  valida&on  of  different  categories  of   systems   •  MOSS  would  be  considered  a  Configured  Off  the  Shelf  system  within  the   context  of  GAMP   •  It  is  expected  that  these  systems  have  already  undergone  significant   valida&on  during  development  by  the  vendor   •  Configured  off  the  shelf  systems  require  less  valida&on  effort  than   customized  systems       26
  • 27. <<Your Logo>> GAMP5  –  CSV  Framework  for  a  Configured  Product   Responsibility: User   Sponsor Requirements   Requirements   Specifica&on   Tes&ng  (PQ)   Func&onal   Func&onal   Specifica&on   Tes&ng  (OQ)   Configura&on   Configura&on   Specifica&on   Tes&ng  (IQ)   Configured   Product   Supplier Supplier QMS
  • 28. <<Your Logo>> CSV  Documents  –  Valida&on  Plan   •  Governs  the  valida&on  process  for  a  system   •  Outlines:   –  Roles  and  responsibili&es   –  Valida&on  approach  and  risk  ra&onale   –  System  scope  and  pre-­‐requisite  requirements   –  Documenta&on  deliverables  for  the  system   •  The  plan  should  be  high  level  and  flexible  whilst  clearly  specifying  what  is   required  to  achieve  compliance   •  If  MOSS  is  to  be  deployed  in  a  controlled  and  non-­‐controlled  configura&on,   the  plan  should  clearly  state  that  only  the  controlled  environment  will  be   validated  
  • 29. <<Your Logo>> CSV  Documents  –  User  Requirements  Specifica&on   •  Document  that  defines:   –  business  (end  user)  requirements   –  func&onal  requirements   –  performance  requirements   –  regulatory  requirements  (including  21  CFR  Part  11  requirements)   –  system  architecture  and  security  requirements   •  Requirements  should  be  precise  and  measurable   •  Used  as  the  basis  for  developing  test  scripts   •  Try  to  priori&ze  requirements  (Must,  Should,  Want)   •  Try  and  minimize  requirements  and  avoid  sta&ng  the  obvious  for  known   OTS  systems  such  as  MOSS  
  • 30. <<Your Logo>> CSV  Documents  –  Traceability  Matrix   •  It  is  strongly  recommended  that  a  traceability  matrix  is   maintained  throughout  the  life&me  of  the  system   •  The  trace  matrix:   –  Links  test  scripts  to  user  and  func&onal  requirements   –  Ensures  that  all  requirements  are  adequately  tested   –  Indicates  the  risk  classifica&on  for  each  testable  requirement   –  Should  be  considered  a  living  document  and  therefore  versioned  and   updated  during  change  control  
  • 31. <<Your Logo>> CSV  Documents  –  Func&onal  Specifica&on   •  Func&onal  specifica&ons  allow  us  to  describe  how  system  func&ons  will   meet  user  requirements   •  The  func&onal  specifica&on  clearly  describes:   –  The  purpose  of  each  func&on   –  The  inputs   –  The  process   –  The  outputs   •  Func&onal  specifica&ons  are  not  required  for  the  installa&on  and   configura&on  of  baseline  MOSS   •  Func&onal  specifica&ons  should  be  developed  for:   –  Validated  InfoPath  forms   –  Validated  workflows   –  Custom  web  parts,  features  and  solu&ons   –  Integra&on  with  any  third  party  applica&ons  or  services  
  • 32. <<Your Logo>> CSV  Documents  –  Configura&on  Specifica&on   •  The  configura&on  specifica&on  clearly  documents:   –  The  baseline  MOSS  parameters  and  architecture  required  for  installa&on  of   the  product  and  any  3rd  party  add-­‐ons   –  The  structure  of  the  controlled  environment,  notably:   •  Site  and  library  seongs   •  Libraries   •  Content  types   •  Columns   •  Security  groups  and  user  rights   •  Template  and  workflow  deployment   •  The  specifica&on  can  be  versioned  and  used  to  document  the  execu&on  of   the  configura&on  in  MOSS   •  The  specifica&on  should  be  updated  each  &me  changes  are  required   through  change  control  
  • 33. <<Your Logo>> CSV  Documents  –  Configura&on  Tes&ng  (IQ)   •  Ensures  that  all  sodware  modules  are  installed  correctly   •  Lists  step  by  step  process  for  the  installa&on  and  configura&on  of  all   sodware  modules   •  Defines  expected  results  at  each  control  point  of  the  installa&on   •  Ensures  that  all  documenta&on  is  in  place  and  that  the  system  is   adequately  protected   •  Ensures  proper  verifica&on  of  the  structural  elements  i.e.  sites,  content   types  etc.   •  It  is  recommended  to  develop  an  IQ  protocol  which  governs  the  overall   installa&on  and  configura&on  process   •  Develop  IQ  scripts  for  the  installa&on  of  baseline  MOSS  and  3rd  party  add-­‐ ons  in  all  validated  environments   •  Develop  IQ  scripts  for  the  execu&on  of  the  configura&on  specifica&on  for   structural  MOSS  elements  
  • 34. <<Your Logo>> CSV  Documents  –  Func&onal  Tes&ng  (OQ)   •  Consists  of  end  to  end  posi&ve  and  nega&ve  tes&ng  that  all  system   components  i.e.  hardware  and  sodware  are  opera&ng  as  intended   •  Tests  are  executed  on  base  func&onality  by  end  users  and  IT   •  Tests  are  governed  by  a  test  protocol  which  clearly  describes  the  test  and   devia&on  management  procedures  that  must  be  followed   •  Tests  should  be  broken  down  into  test  scripts  by  func&onal  area,  linked  to   baseline  system  func&on,  and  be  approved  before  execu&on   •  All  test  results  should  be  clearly  documented  using  good  documenta&on   prac&ces  (ALCOA)   •  Use  of  adequate  risk  assessment  should  greatly  reduce  the  scope  of  OQ   for  OTS  MOSS  deployments   34
  • 35. <<Your Logo>> CSV  Documents  –  Requirements  Tes&ng  (PQ)   •  Requirements  tes&ng  consists  of  posi&ve  tes&ng  of  company  specific   configura&on  and  user  requirements   •  Tests  are  executed  on  business  specific  func&onality  such  as  workflows  or   InfoPath  forms  that  were  iden&fied  as  being  testable  during  the  risk   assessment  exercise   •  Tests  are  governed  by  a  test  protocol  which  clearly  describes  the  test  and   devia&on  management  procedures  that  must  be  followed   •  Tests  should  be  broken  down  into  test  scripts  by  func&onal  area,  linked  to   user  and  func&onal  requirements,  and  be  approved  before  execu&on   •  All  test  results  should  be  clearly  documented  using  good  documenta&on   prac&ces  (ALCOA)   •  Tests  are  typically  executed  by  end  users  and  serve  as  a  user  acceptance   mechanism  
  • 36. <<Your Logo>> Final  Valida&on  Summary  Report   •  Describes  how  the  valida&on  went,  verifies  that  all  devia&ons   are  closed,  and  provides  for  the  final  approval  of  the  CSV   document  package  to  allow  the  system  to  go  into  produc&on   •  Individual  summary  reports  for  each  step  of  the  verifica&on   process  or  a  comprehensive  report  covering  all  steps  may  be   produced   •  The  summary  report  should  clearly  show  that  the  valida&on   plan  and  protocols  were  followed  and  that  the  acceptance   criteria  for  puong  the  system  into  produc&on  have  been  met  
  • 37. <<Your Logo>> Configura&on  control  and  maintaining  the  validated  state   •  Configura&on  control  should  be  governed  by  a  formal  MOSS  specific   procedure  in  addi&on  to  any  general  provisions  of  the  IT  Configura&on   control  SOP     •  This  procedure  should  govern  the  update  of  the  configura&on  specifica&on   •  The  configura&on  specifica&on  should  be  used  to  clearly  document   updates  /  addi&ons  to  MOSS     •  Any  changes  to  the  validated  controlled  environment  must  also  be   documented  using  change  control   •  Should  significant  changes  or  addi&ons  be  made,  a  new  valida&on  project   may  be  required   •  For  workflows,  forms  or  features/solu&ons  it  is  impera&ve  to  correctly   evaluate  impact  and  risk  and  produce  adequate  test  scripts  properly   integrate  the  addi&onal  elements  into  the  current  environment  
  • 38. <<Your Logo>> Maximizing  quality  and  ROI   •  Valida&on  can  be  expensive  and  &me  consuming  if  it  is  not  done  correctly   •  By  defining  a  clear  valida&on  strategy  and  by  leveraging  risk  assessment   techniques,  we  are  able  to  focus  the  valida&on  effort  on  what  is  really   important   •  Consider  acquiring  tried  and  tested  test  scripts  and/or  valida&on  packages   for  MOSS  /  third  party  add-­‐ons  so  as  to  reduce  the  amount  of  prepara&on   &me  and  improve  quality   •  Make  sure  that  all  individuals  involved  in  the  valida&on  effort  are  fully   trained  and  understand  the  CSV  process   •  Isolated  controlled  environments  facilitate  valida&on  and  configura&on   control   •  Use  virtual  environments  so  as  to  facilitate  replica&on  between  produc&on   and  test  environments   38
  • 39. <<Your Logo>> Lessons  learned  and  best  prac&ces   •  Create  a  ‘Big  Picture’  of  your  MOSS  deployment  so  as  to  ensure  that  you   are  able  to  adequately  accommodate  all  of  your  controlled  and  non-­‐ controlled  needs     •  Use  a  risk  based  approach  to  focus  and  reduce  valida&on  efforts  –  be  strict   otherwise  everything  becomes  high  risk…   •  Remember  that  MOSS  is  an  off-­‐the-­‐shelf  product  and  that  you  should  limit   valida&on  scope  to  high  risk  business  and  regulatory  requirements  as   much  as  possible   •  Establish  a  MOSS  valida&on  team  to  oversee  and  manage  the  valida&on   process  and  changes  to  the  controlled  MOSS  environment     •  Implement  SOPs  and  WIs  which  clearly  define  how  the  environment  is   configured  and  administered  and  which  level  of  documenta&on  /  re-­‐ valida&on  is  required  by  type  of  change   •  Use  a  step  by  step  deployment  methodology  to  keep  things  manageable   39
  • 40. <<Your Logo>> It is easy to drown in the details… Try and keep it SIMPLE! Contact Info: pfenton@montrium.com Tel. 514-223-9153 ext. 206 40
  • 41. 41