Protocol Analysis Services

An Ounce of Prevention is Worth a Pound of Cure.
Approximatly 50% of what is perceived as “technical issues” in a study is really just a lack of accounting for edge case scenarios, training, and alignment of roles/expectations up-front in the process.
Vertocol anticipates these impacts by proactively addressing issues. With our suite of service offerings paired with our extensive experience, we can prevent problems before they happen.
Protocol Analysis Process
Using Vertocol’s methodology, we are able to identify technical, integration, user experience, and operational issues upfront to limit budget and timeline risks to your study.
STEP 1:
PROTOCOL
ASSESSMENT
STEPS 2:
SUCCESS INTERVIEWS
STEP 3:
DEVELOP
TSOA
STEP 4:
EXPERIENCE
MAPPING
STEP 5:
REQUIREMENTS
MAPPING
STEP 6:
FINAL UPDATES AND PACKAGING
Success Interviews
Success interviews adapt established product development techniques to help critical stakeholders within a clinical studies understanding the “job to be done” rather than prescriptive solutions based on historical bias. Through this process, collaborate with key stakeholders to:
Support end-to-end delivery and management of technology into your clinical study.
Gain feedback from cross functional stakeholders who will use the system
Reduce downstream cost and data risks through proactive planning
Ensure consistent study understanding from FSI to Data Lock
Eliminate disjointed and siloed implementation plans
Chose the right technology for your study based on need and not perceived biases
Technical Schedule of Assessments (TSOA)
Vertocol’s Technical Schedule of Assessment (TSOA) is a tool that is designed to help bridge high-level technical needs to quickly communicate critical assumptions for how technology is expected to work within a study.
Traditional Schedules of Assessments found within a protocol are operational constructs. For the purposes of implementing technology into a study, this happens to be a primary piece of documentation that drives understanding of the protocol; however, in a DCT or Hybrid context, this is an imperfect tool. They outline high-level activities within a study but do not provide much detail beyond that.
Within the TSOA, the critical objectives to achieve are:
Review protocol and map key technical logic eClinical platform and business processes should facilitate during the data collection process to understand:
Timing for triggering events
Mapping of activities by user role
Critical path dependencies
System integrations
Includes detailed notes explaning expected actions:
Review critical roles with assumptions based on the target populations and country mix
Understand critical technical and operational nuances that can drastically impact the overall success of the study:
Manual vs. automated steps
System integrations
Complex logic
Experience Mapping
Detailed mapping of expected activities within the study are used to:
Identify critical risks related to cultural, regulatory, and technical feasibility
Identify critical success points to ensure success across all customer types
Calculate a comprehensive risk and success score is created to:
Identify key objectives and goals for study success
Identify critical learning objectives for training
Clarify roles and responsibilities for study staff to ensure overall accountability
Key benefits
Identify 100% of cross-functional risks
Increase compliance by 20–30%
Identify gaps in training to help ensure CRO and site coverage
Expose cascading impacts through the entire business process
Eliminate up to 50% of all helpdesk issues
Success Mapping
Traditional business requirements gathering process excels at defining happy path scenarios related to “how” a technical solution should work. However, lessons learned have taught us that it is the edge case, unaccounted for scenarios that introduce the most risk when implementing a new technology.
Example mapping is a technique for fleshing out and gaining clarity around the acceptance criteria for a given story. It is based on the idea that multiple examples of specific cases convey information better than a single bad abstraction of a concept.
Through this process, nuanced aspects of a technical solution are defined along with the critical user roles, definitions, questions and examples to ensure clarity within configuration and development processes.
Within the TSOA, the critical objectives to achieve are:
Use requirements in RFP process to:
Get more precise quotes
Ensure greater alignment of downstream expectations
Reduce chance of critical technical and opera gaps
Reduce post go-live costs due to missed requirements
Align all key therapeutic stakeholders prior kickoff
Ensure operational staff is aligned their technical role
Deliver refined requires as a protocol addendum:
Define happy path and edge-case scenarios for use in requirements specifications to align operational and technical needs
Define exact rules for triggering events, alerts, integrations, etc.
Create clear understanding of business rules for exact alignment
Define study-specific business rules for use in QA activities:
Write test cases for validation and UAT
Ensure clear traceability for audits