Compliance Blog


Page 2 of 212
  1. An Introduction to CDISC Data Standards

    Tags: | | | |

    data1CDISC is the Clinical Data Interchange Standards Consortium, a nonprofit organization whose goal is to “develop and support global, platform-independent data standards that enable information system interoperability to improve medical research and related areas of healthcare.” CDISC develops standards for packaging and reporting clinical research and related data. According to the CDISC website, use of these data standards will “become mandatory 2 years after the final guidance is issued for NDAs and BLAs, and will apply to all new studies begun 1 year after the final guidance is published.” The final guidance is required by fiscal year 2017.

    Some of the more significant standards include:

    CDASH (Clinical Data Acquisition Standards Harmonization) is used for acquiring clinical study data. The goal of CDASH is to harmonize clinical element names, definitions and metadata.

    SDTM (Study Data Tabulation Model) is used for reporting clinical study data in a machine-readable format. SDTM reports clinical observations as series of variables. These variables represent values in a corresponding table.

    ADaM (Analysis Data Model) is used for analyzing data.

    LAB (Laboratory Data Model) is a standard for transmitting laboratory data. Unlike the other standards, the name is not an acronym. It was originally created to facilitate transferring data from Labs to Clinical organizations.

    The different standards are used for different parts of the clinical process: acquiring data (CDASH), reporting data (SDTM) and analyzing data (ADaM).

    The usual flow of clinical data through the CDISC standards is:

    1. Data are collated from medical source documents and collected in CDASH formats.
      If there is clinical laboratory data, this can be concurrently collected in LAB format and added to CDASH datasets.
    2. CDASH and LAB data are transcribed to SDTM format for reporting.
    3. SDTM data are reformatted and updated to ADaM datasets.
      (Some organizations go directly from CDASH to ADaM datasets.)
    4. ADaM datasets are analyzed.
    5. Study tables and listings are generated using data lists from the CDASH or SDTM datasets and the analysis results are generated from the ADaM datasets.

    Data sets are generally only human-readable at the beginning and end of this process. The CDASH and LAB can be human readable when viewed directly with some experience.  SDTM and ADaM data are not human-readable; programs use SDTM and ADaM data to produce the tables, listings, figures, and statistical results that are the core of the Clinical Study Report (CSR).


    Recommended Solutions

    Compliance Training >>

    Recommended Solutions

    ExcelSafe >>

    Recommended Solutions

    Ofni Clinical >>

    Recommended Solutions

    Part 11 Toolkit >>

    Recommended Solutions

    Part 11 Advisor >>

    Recommended Solutions

    MedWatch Reporter >>

    Recommended Solutions

    Computer Validation >>

    Recommended Solutions

    Custom Programming >>

    Recommended Solutions

    Validating MS Excel Spreadsheets >>

    Recommended Solutions

    Access Databases >>

  2. Requirement Shock is Not a Requirement for Clinical Databases

    Tags: | |

    We’ve all looked at a price tag (“How many zeros?”) and felt sticker shock.

    When you take your clinical data collection design to most clinical data management contractors and ask for an estimate, you will likely receive a series of implementation requirements tacked on, such as:

    • Several month creation times.
    • Six-figure startup costs.
    • Ongoing software or support fees.
    • Costly training courses or hiring already-trained personnel.
    • Per-user licensing.
    • Special software requirements.
    • Required remote hosting.

    Looking at this list of implementation requirements (“How many zeros?”), you are feeling requirement shock.

    Requirement Shock is not a Requirement.

    Ofni Systems designed Ofni Clinical to avoid requirement shock:

    • Rapid implementation – Ofni Clinical databases can be implemented in days or weeks (which also cuts down on startup costs).
    • Once you purchase Ofni Clinical you own the software – there are no ongoing fees and you may install it wherever you wish.
    • Ofni Clinical is easy to learn and administer.
    • The Ofni Clinical license allows an unlimited number of users.
    • No special software or hardware is needed – Ofni Clinical runs any computer with Microsoft Office Professional 2003 or later.

    Our last Ofni Clinical database project was based on a 172 page Case Report Form and had 55 Edit Checks.

    It was implemented in under 100 hours – less than two and a half weeks.

    Contact us to find out how Ofni Clinical can help you avoid requirement shock.


    Recommended Solutions

    Compliance Training >>

    Recommended Solutions

    ExcelSafe >>

    Recommended Solutions

    Ofni Clinical >>

    Recommended Solutions

    Part 11 Toolkit >>

    Recommended Solutions

    Part 11 Advisor >>

    Recommended Solutions

    MedWatch Reporter >>

    Recommended Solutions

    Computer Validation >>

    Recommended Solutions

    Custom Programming >>

    Recommended Solutions

    Validating MS Excel Spreadsheets >>

    Recommended Solutions

    Access Databases >>

  3. Validation Methodology: Documenting and Testing Functions Directly

    Tags: | |

    Calculations represent one of the highest risk components of any computer validation project. When results are displayed on a form or report, users tend to accept those results as correct. Validation has to ensure that the results are actually correct. One common method to validate calculations is to enter a few known values and verify that the expected results are returned. However, even if the results of a calculation are correct in a few cases that does not mean the underlying formula is correct. For that reason, Ofni Systems’ preferred method is to directly verify the function or formula.

    The User/Functional Requirements is the appropriate place to document what each formula is supposed to calculate. All of the components of the function should be explained, including any Boolean logic that is used to capture errors or unusual conditions. For example:

    • Force = Mass x Acceleration
    • With valid input, Current = Voltage / Resistance. If Resistance = 0, then Current is NULL.

    The Design Specification is the appropriate place to document the actual calculation. It is a good practice for the author of the Design Specification to document the arguments in the calculation to ensure that the calculation does represent the intended calculation; if the author notices that the calculation does not match the requirement, this should be brought to the appropriate person’s attention. For example:

    • Force = Mass x Acceleration. In Excel this is expressed as Cn = (An*Bn), where Column A is Force, Column B is Acceleration and n is row number.
    • Current = IF (Resistance = 0) THEN 0 ELSE (Voltage / Resistance)

    The test protocol then ties the User/Functional Requirements to the Design Specification. The protocol procedure describes the requirement. The tester documents the calculation in the results along with the individual components of the calculation. The tester then verifies that the calculation accurately describes the requirement. This does require a tester who is has enough experience to review the formulas, compare them with the requirement and verify that the formula meets the requirement. It also requires that the functions are directly accessible by the tester. The advantage of this method is that the function itself has been directly verified and validated, rather than a few selected inputs.


    Recommended Solutions

    Compliance Training >>

    Recommended Solutions

    ExcelSafe >>

    Recommended Solutions

    Ofni Clinical >>

    Recommended Solutions

    Part 11 Toolkit >>

    Recommended Solutions

    Part 11 Advisor >>

    Recommended Solutions

    MedWatch Reporter >>

    Recommended Solutions

    Computer Validation >>

    Recommended Solutions

    Custom Programming >>

    Recommended Solutions

    Validating MS Excel Spreadsheets >>

    Recommended Solutions

    Access Databases >>

  4. Changes in Software Development Documentation in GAMP 5

    Tags: |

    ISPE has just released version 5 of GAMP, Good Automated Manufacturing Practices. GAMP 5 emphasizes a cost effective approach to compliance, while incorporating recent regulatory and industry developments that focus attention on patient safety, product quality and data integrity.

    Primary Changes between GAMP 4 and GAMP 5

    • Risk Assessment – One of the principal focuses in GAMP 5 is the focus on risk assessment throughout the software development process. GAMP 5 guidelines state that risk assessment should be performed at critical junctures in the software life cycle, including during all requirement gathering phases in the development cycle, the beginning of each change control cycle and before system decommissioning.
    • Scalability – All testing and validation efforts should be appropriate to the system. The scale of the testing effort should reflect the relative risk present in the system.
    • Increased Focus on Computer System Life Cycle – Companies need to retain control over their computer systems and system data, from system concept to system decommissioning.
    • Avoid Duplication of Activities – It is not necessary to repeat testing performed by qualified vendors and other third parties, so long as this testing is appropriately documented. One of the primary goals of GAMP 5 is to reduce the cost and effort of regulatory compliance. Each additional testing step should not repeat previous efforts. Supplier testing can be included as part of the testing effort.
    • Increased awareness of Configurable and Networked Systems – GAMP 5 fits into the ITIL framework, which is widely used for managing systems. Software testing should focus on the specific configuration of the program, not core operational characteristics, especially when the supplier can demonstrate testing of the core operational functionality of the system.
    • Comprehensive Guidelines on Operational Aspects – GAMP 5 has increased the specificity of requirements for maintaining operational systems under change control. Configuration Management has been added to the Appendix on Operational Change Control, O6.
    • Clarity and Flexibility – GAMP 5 strives to simultaneously make all aspects of software testing more explicit, while not restricting good testing procedures and practices. There are numerous changes throughout GAMP 5 which attempt to clarify key roles in the testing, risk assessment and supplier evaluation processes while not adding undue paperwork or effort.

    The new GAMP 5 emphasizes leveraging risk assessment and risk management to scale validation efforts appropriately. GAMP 5 favors a holistic approach to risk management, not individual risk assessments of each individual computer systems. Risk is so important that it’s in the new subtitle of the standard: A Risk-Based Approach to Compliant GxP Computerized Systems

    Ofni Systems can help your company review their policies and practices to ensure they follow the best practices guidelines outlined in GAMP 5. Ofni Systems can also provide your employees with the training to remain in compliance with all applicable regulations.


    Recommended Solutions

    Compliance Training >>

    Recommended Solutions

    ExcelSafe >>

    Recommended Solutions

    Ofni Clinical >>

    Recommended Solutions

    Part 11 Toolkit >>

    Recommended Solutions

    Part 11 Advisor >>

    Recommended Solutions

    MedWatch Reporter >>

    Recommended Solutions

    Computer Validation >>

    Recommended Solutions

    Custom Programming >>

    Recommended Solutions

    Validating MS Excel Spreadsheets >>

    Recommended Solutions

    Access Databases >>


Page 2 of 212