V & V Documentation Model – 11 Documents

Posted on by admin

There are 11 document types in the basic V&V Documentation model as per “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices”, Table 3, May 11, 2005:

  1. LOC (Level of Concern: Min, Mod, Maj)
  2. SW Description
  3. Hazard / Risk Analysis (ISO 14971 / ICH Q9 = recommended       model; ultimately to the user / patient / clinician)
  4. SRS (SW Requirements Specification)
  5. Design Specification
  6. Architecture
  7. Development
  8. V&V[T] – can’t be achieved w/o being risk based
  9. Traceability (common para. numbering or matrix)
  10. Unresolved Anomalies (‘Bugs’) – risk based
  11. Rev. Nos / Release Number

Doc No. 1: U. S. FDA ‘LOC’ Risk Estimation

  • Major: If operation of s/w associated w/ device function directly (or information indirectly) affects patient/operator so failures/flaws could result in death or serious injury;
  • Moderate: If above could result in non-serious injury;
  • Minor: Failure/latent design flaws would not be expected to result in any injury to patient/operator.
  • “Serious injury”: Is life threatening; results in permanent/irreversible impairment of a body function, damage to a body structure; necessitates medical or surgical intervention to preclude such.
  • Use ISO 14971(devices) / ICH Q9 (pharma) “model” for risk (to patient / user level), and FDA device s/w guidance documents

Doc No. 2: S/W Description:

  • “30K foot” description; marketing description; comprehensive overview
  • Device features controlled/not controlled; user interactions; unchangeable; backups;
  • Operational environment: Language, hardware platform, OS, other components;

Doc No. 3: Hazard Analysis (based on ISO 14971:2012 “Model”; use to verify LOC):

  • Device / process / equipment hazard analysis: Event, level of concern (LOC), cause, control, corrective measures taken, verification; for intentional / inadvertent misuse;
  • ISO 14971 “Model”:
    •  File:
      • Narrative
      • Hazard Analysis
      • FTA
      • D-, P-, U-FMECAs
    • Report: Summary and Risk / Benefit Analysis

Note: All software V&V is a “risk-based” activity, by nature of the “beast”.

Doc No. 4: S/W Requirements Specification (SRS) – KEY — defines:

  • All inputs to be received;
  • All outputs to be produced;
  • All functions that will be performed;
  • All performance requirements to be met, e.g., data throughput, reliability, algorithms, controls/alarms; programming language and size;
  • Interface requirements, internal, external, and user;
  • Error definitions, and how errors are to be handled;
  • Intended operating environment; hardware platform; OS; device limitations due to s/w;
  • Safety requirements, features, or functions;
  • All ranges, limits, defaults, values accepted by s/w.

SRS Verification Activities:

  • No internal inconsistencies between requirements.
  • All performance requirements. defined
  • Fault tolerance/security requirements complete/correct
  • S/w function allocations accurate/complete
  • Requirements are appropriate for the system hazards
  • Requirements defined in measurable terms
  • ID any off-the-shelf s/w (if appropriate).
  • KEY: Supplies basis for subsequent validation test cases.

Doc No. 5: Architecture Design Chart: Functional subsystems (or modules) with descriptions

Doc No. 6:  S/W Design Specification:

Translates SRS into logical / physical representation of the s/w.  Especially for custom s/w.  May include:

  • Development, programming standards; language(s)
  • Systems documentation
  • Hardware requirements
  • Parameters measured / recorded
  • Logic (structure, control, processing steps)
  • Data structure, data flow diagrams, or pseudo code (supplemental word descriptions of algorithms)
  • Definitions of variables; description where used
  • Error and alarm messages
  • Supporting s/w (OS, drivers, others)
  • Communications links (w/ modules, suptg. s/w, h/w)
  • Security measures (physical and logical).

The S/W Design Spec describes logical structure, parameters measured / recorded, information flow, processing steps, control logic, data structures, error/alarm messages, security measures, predetermined acceptance criteria, plus supporting s/w or h/w.  Design .

Spec V&V consists primarily of verification steps, addressed in the IQ, OQ, and PQs test cases.

Doc No. 7: Traceability Matrix (and / or commonality of numbering): 

Traceability / Interface Analysis / Matrix – Shows links between the above elements (1-6; and especially between the SRS and V&V protocol test cases). May also involve:

  • Traceability: S/w requirements to system requirements to test cases (and vice versa)
  • Interface analysis: S/w requirements to hardware user.

 Operator-s/w interface requirements for accuracy, completeness, consistency, correctness, clarity; no external inconsistencies

  • Formal design review(s) to confirm fully specified  and appropriate requirements  

Doc No. 8: S/W Development:

Development – a summary of the software development life cycle plans / methodology / standards / activities;  especially if custom s/w. 

Includes:

  • Systems used to manage development;
  • Configuration management;
  • Activities performed; and
  • Maintenance plan.
  • Annotated list of control / baseline documents generated during development (for major control devices)

Doc No. 9: Verification & Validation – the other Key documentation section:

VT&V Test Cases – of s/w and its supporting documentation (if custom, at each stage of the s/w development process; if COTS, the results /  “black box” ):

  • Appropriate for intended use, will be reliable and safe; based on Hazard Analysis / ‘Level of Concern’ /  FMECA’s line items
  • Validation models keyed to Product (1), Process / Equipment (2) or QMS (3)
  • “Black box” testing — code unknown / unobtainable, e.g., COTS (commercial off-the-shelf); s/w tested by hardware operation
  • “White box” testing — code known; reviewed for logic, other problems

Doc No. 10: Unresolved Anomalies:

Bug(s) List:   Indicate problem, impact, any plans for corrections, or why benign and left in (most likely).  List of bugs should also be included in the device labeling.

Doc No. 11: Rev / Release Number(s):

  • Revision Level History – documenting all major changes to s/w during its development cycle; and
  • Release Version Number (no. assigned the rev. released to the public).

Note: Regulated software documentation requirements may not be reduced when developed under some of the current “fast” development systems, e.g., Agile.