One Connected eClinical Platform for Faster Trial Execution
Run EDC, RTSM, CTMS/eTMF, ePRO and eConsent through a configurable cloud platform built for sponsors and CROs — with study builds in days, not months.
The Problem We Solve
Fragmented trial systems are costing you time, data quality, and competitive advantage
Most clinical teams juggle 4–6 disconnected point solutions. The result: duplicate data entry, manual reconciliation, and months lost before first patient first visit.
Months to First Patient
Legacy EDC and RTSM vendors take 8–24 weeks to build a study. Every week of delay costs clinical budget and competitive advantage.
Data Silos & Reconciliation
When EDC, RTSM, and CTMS are separate systems, data never stays in sync. Teams waste weeks on reconciliation that should be instant.
Enterprise Cost, SME Budget
Medidata and Veeva were built for large pharma. Small and mid-size sponsors and CROs end up overpaying for capabilities they cannot fully use.
Unified eClinical Suite
End-to-end platform connecting every stakeholder and system in your clinical trial ecosystem
Solutions for End-to-End Clinical Operations
Specialized services that complement our eClinical products, helping sponsors and CROs manage data, projects, and compliance across the full trial lifecycle
Clinical Data Management
CDM services ensure accuracy, completeness, and consistency of clinical trial data while meeting regulatory requirements
Design and build CRFs/EDC databases leveraging SOLASTA@edc for efficient data capture
Manage data validation, discrepancy handling, and medical coding to maintain clean datasets
Oversee database lock and data extraction processes supporting statistical analysis
Project Management
Shilowiz project managers coordinate cross-functional clinical teams to deliver studies on time, within scope, and to quality expectations
End-to-end planning, timelines, and resource allocation for clinical activities
Risk and issue tracking with proactive mitigation and stakeholder communication
Progress tracking using dashboards integrated with Shilowiz platforms
Consulting Services
Shilowiz provides QA, validation, and regulatory consulting to help clients design compliant processes and systems
QA and validation support for eClinical systems, including document review
Process and SOP consulting to align trial operations with GCP expectations
Audit readiness and remediation guidance for inspection-ready documentation
Looking for a tailored combination of technology and services?
Who We Serve
Built for the Teams Running Clinical Trials
Different buyers have different priorities. Select your role to see how Shilowiz addresses your specific challenges.
Your challenges as a sponsor
- Protocol amendments derail timelines and require extended re-development effort with your current vendor
- EDC, RTSM, and CTMS don’t share a data model — reconciliation is manual, time-consuming, and error-prone
- Enterprise vendor pricing wasn’t built for your company size — you’re paying for capability you can’t use or justify
- Vendor qualification takes weeks — your QA and IT teams are chasing documentation from your current platform
- Portfolio visibility requires logging into multiple systems and building manual dashboards
How Shilowiz helps: One unified platform means your EDC, RTSM, and CTMS share a single data model. Protocol amendments apply in hours with controlled change records. Regulatory documentation — audit trails, e-signatures, RBAC controls — is built in, not a consultant add-on.
Compliance controls included:
Shilowiz provides configurable controls designed to support these requirements. Compliance responsibility rests with the sponsor and/or CRO as applicable under ICH E6(R3).
Your challenges as a CRO
- Every sponsor wants a different EDC or RTSM — your team ends up managing 5 different platforms
- Study builds take weeks — you're losing bids to vendors who promise faster startup
- Site activation is bottlenecked by slow feasibility and fragmented site management processes
- Sponsor qualification questionnaires require documentation your current vendors don't provide easily
How Shilowiz helps: One platform your team learns once — configurable per sponsor, per study. Reusable CRF libraries and pre-built configurations mean faster builds and stronger bid defensibility. NAVON@site accelerates feasibility with high questionnaire response rates in under a week. Vendor qualification documentation is packaged and ready for sponsor review — reducing the time your team spends responding to sponsor RFIs.
Products most used by CROs:
Your challenges as a site
- Your coordinators log into a different system for every study — training overhead is significant
- Data entry screens are complex and generate excessive queries that take hours to resolve
- Patient randomisation requires calling an IRT hotline or navigating a complex separate system
- eTMF submissions are manual, time-consuming, and always seem to be flagged at inspection
How Shilowiz helps: One login gives site coordinators access to EDC, randomisation, and eTMF. AI-driven query reduction means significantly fewer manually generated queries to resolve. COPIOUS@rtsm integrates directly into the EDC workflow — no separate IRT login.
Site training time:
Most site coordinators are proficient in SOLASTA@edc within a single half-day onboarding session. The interface is designed for clinical staff, not IT professionals.
Technology + Clinical Expertise
Software backed by the clinical expertise to make it succeed
Shilowiz is not just a software vendor. Behind every product deployment is a team of clinical data managers, QA specialists, validation engineers, and clinical operations professionals.
Software Only
For organisations with established internal clinical operations teams. You build and manage; we provide the platform, training, and technical support.
- Full platform access
- Technical support & training
- Validation documentation package
Technology + Services
Add clinical data management, implementation support, validation consulting, or clinical operations expertise alongside your Shilowiz deployment.
- CRF and EDC database design
- Data validation & discrepancy management
- GxP SOP & process consulting
- Audit readiness preparation
Fully Supported Deployment
Technology, implementation, validation, and ongoing study support — one accountable team from protocol sign-off through database lock.
- End-to-end project management
- Dedicated study manager through lock
- On-call clinical operations support
eClinical Insights
Thinking from the Shilowiz team
Practical guidance on EDC, RTSM, CTMS, and AI governance — written by the team building these systems.
EDC validation under GCP and 21 CFR Part 11 stays with the sponsor. Ask whether the vendor's validation package covers your study type, and who signs the IQ/OQ/PQ documents when a new eCRF version is released mid-study.
- Who generates the validation documentation for our study build?
- When we add a new visit or field post-FPI, who re-validates — and in how many days?
- Can you provide a sample IQ/OQ/PQ package from a comparable Phase II study?
Vendor says validation is "the sponsor's responsibility" with no packaged support — this delays every amendment.
Protocol amendments arrive mid-study. A poor amendment workflow freezes data entry at active sites for days while the new build is tested and deployed.
| Driver | Ask the vendor |
|---|---|
| Days to deploy a new eCRF version | With existing subject data — not on a blank study |
| Parallel editing | Can monitors continue SDV while a new version is being staged? |
| Historical data migration | How are existing records handled when a field is renamed or removed? |
| Amendment audit trail | Is the version change recorded per subject record? |
Build environment is the same as production — any update freezes live data entry.
High query rates inflate site workload and CRA time. Ask for query-per-subject data from a comparable closed study, split by auto-generated vs. manual.
- What is the average queries-per-subject rate on your last three Phase II oncology studies?
- What percentage of queries are auto-generated vs. manually raised?
- Can edit checks be configured by the sponsor without vendor involvement?
Vendor cannot supply query-rate data from a closed comparable study — they cannot benchmark what they cannot measure.
Every day a site spends in training before first patient entry is a cost and a delay risk. Ask for the actual training hours per site coordinator role from a recent study.
- What is the typical training time (hours) for a site coordinator to reach independence?
- Is training material available in the local language for our target site countries?
- What happens to training records if a site staff member changes roles mid-study?
Training is described as a bespoke project quoted separately — expect cost overruns every time you add a site country.
EDC and RTSM must share stratification factors, randomization number, and kit dispensing data in real time. Loose integrations lead to double-entry and reconciliation at lock.
| Data element | Expected flow |
|---|---|
| Stratification factors | EDC → RTSM, before randomization |
| Randomization number & date | RTSM → EDC, real-time |
| Kit number dispensed per visit | RTSM → EDC, real-time |
| Withdrawal / early termination | EDC → RTSM (stops resupply), real-time |
Integration is offered as a custom services project with no prior reference client.
Who owns the eCRF build configuration — the vendor or your team? Vendor-owned builds create dependency for every change. Ask for the actual calendar time from protocol sign-off to first patient in on a comparable study.
- Can your own team build and modify eCRFs without vendor involvement?
- What is the median calendar time from protocol sign-off to go-live on a Phase II oncology study?
- Are mid-study changes self-service or ticketed through a vendor change-control process?
Every eCRF change requires a vendor change order and an SLA of 5+ business days.
Regulatory submission timelines depend on how quickly clean data is exported after database lock. Ask whether SDTM mappings are built during study set-up or after lock as a separate billable engagement.
- Do SDTM mappings run in real time, or are they generated post-lock?
- Can your team review DEFINE.xml and annotated CRF before first patient in?
- What is the format of the final data export, and what tools are needed to read it?
CDISC/SDTM output is quoted as a post-database-lock services engagement — this delays submission timelines by weeks.
EDC contracts are won on per-subject licence fees. The true cost emerges in amendment charges, integration fees, training costs, and lock-to-export services. Ask for a fixed-scope quotation that includes all foreseeable change types.
- Is the amendment charge per-amendment or included in the licence?
- What happens to the price if the study extends by six months past the contracted end date?
- Are RTSM integration, CDISC mapping, and audit trail exports included or separately quoted?
Only a per-subject fee is quoted — every downstream cost arrives as a change order.
Ask for a dated plan with named owners from protocol sign-off to go-live. RTSM go-live gates the first randomization and the first drug release to sites.
| Driver | Ask the vendor |
|---|---|
| Configured vs coded | Is the study set up through parameters, or does it need custom development? |
| Randomization design | Can they support stratified block, minimisation, adaptive, or cohort-based dose escalation without custom work? |
| Who writes the specs | Does the vendor draft the user requirements spec, or do you? |
| UAT cycles | Are standard UAT scripts provided, and how many UAT cycles are included? |
| Mid-study changes | Adding a cohort, arm, country or depot: days to production, and at what fee? |
The quoted timeline starts at "approved specification" — pushing the hardest weeks onto your team.
Ask the vendor to explain the resupply logic in plain terms and run it against your study's enrolment assumptions. Supply strategy decides whether you overproduce expensive drug or stock out at your best-recruiting site.
- What resupply models are supported: fixed trigger, predictive (scheduled visits + enrolment rate), or both?
- Does the forecast account for visit windows, dose titration, cohort changes, and randomization ratio — not just headcount?
- Is expiry managed automatically with do-not-dispense days before expiry and automatic blocking?
- Can depot-to-site and depot-to-depot shipments, import licences, and country-level release be modelled?
- Can a supply manager run "what-if" scenarios before the first kit is packaged?
Ask for evidence: Overage planned versus actually used on a recent comparable study, and how many stock-outs occurred.
Forecasting is a spreadsheet the vendor's supply team maintains outside the system.
Even a site-based study now often needs a hybrid option: home nursing visits, direct-to-patient shipments, or patient-entered data. Ask what works today, not what is planned.
| Capability | What to look for |
|---|---|
| DtP shipment | Kit assigned to a subject, shipped from depot or site to home, with courier tracking |
| Patient privacy | Home addresses held by the courier or a segregated role — never visible to the sponsor or blinded staff |
| Chain of custody | Dispatch, delivery confirmation and receipt by patient recorded with timestamps |
| Temperature control | Logger data linked to the shipment, excursion handling defined before dispatch |
| Hybrid switching | A subject can move between site and home visits without breaking the dispensing schedule |
DCT support means a manual workaround run by the vendor's helpdesk.
Kit replacement is where blinding is most often put at risk. Ask the vendor to walk through each scenario live. The site must get a matching replacement fast, without anyone learning the treatment arm.
Replacements require an unblinded vendor staff member to pick the kit manually.
Ask for the data map and the failure handling, not the API brochure. Without a live integration, sites enter subject data twice and data managers reconcile the systems by hand.
| Data element | Source of truth | Direction | Timing |
|---|---|---|---|
| Subject screening & enrolment | Agree one system | One way, no double entry | Real-time |
| Stratification factors | EDC | EDC → RTSM | Before randomization |
| Randomization number & date | RTSM | RTSM → EDC | Real-time |
| Kit number dispensed per visit | RTSM | RTSM → EDC | Real-time |
| Withdrawal / early termination | EDC | EDC → RTSM (stops resupply) | Real-time |
| Emergency unblinding | RTSM | Event flag only to EDC | Real-time |
Integration is quoted as a custom services project with no prior reference client.
AI may draft, flag and suggest; a qualified, named human decides. "Human-in-the-loop" only means something when the system makes it impossible for an AI output to reach the trial record without an attributable approval.
| Risk tier | Example uses | Minimum control |
|---|---|---|
| High — subject safety, eligibility, efficacy data or submissions | AE coding, eligibility pre-screening, SDTM mapping, narrative drafting | Mandatory review + e-signed approval per item; no bulk accept |
| Medium — data quality or trial operations | Query drafting, data anomaly flags, protocol deviation classification | Review before action; bulk allowed with sampling QC |
| Low — no effect on trial record | Report summaries, help-desk answers, study document search | User sees output is AI-generated; feedback captured |
"Autonomous" or "auto-applied" anywhere near trial data.
Subject data, unblinded data, and proprietary protocol content must never leak across studies, sponsors, or into a model's training set. Ask the vendor to draw the data flow for each AI feature, end to end.
| Control | What "good" looks like |
|---|---|
| Training use | Contractual commitment that sponsor data is not used to train or fine-tune any model, by the vendor or its model provider |
| Third-party model providers | Named, with zero-retention or no-logging terms, and listed as sub-processors in the DPA |
| Data residency | Processing region stated per feature; compatible with India's DPDP Act 2023, GDPR and sponsor requirements |
| Tenant & study isolation | Retrieval and prompts scoped to one study; no cross-study or cross-sponsor context |
| Exit | Prompts, outputs and embeddings deleted or returned at contract end, with a certificate |
The vendor cannot name which model provider processes your data, or where.
A standard Part 11 audit trail shows who changed a value and when. With AI in the workflow, an inspector will also ask what the machine proposed and how the human responded. The audit trail must reconstruct both.
Also confirm: Entries are tamper-evident, retained for the same period as other trial records, and exportable in a readable form for inspections and the TMF.
The audit trail shows only the final value — an AI-generated entry is indistinguishable from a human one.
A validated workflow is validated against a specific model, prompt, and configuration. If the provider silently updates the model, the validated state is gone — even though no code changed. Treat model and prompt changes exactly like software releases under change control.
| Control | What to demand |
|---|---|
| Pinned versions | Each study runs on a fixed, named model version; no automatic upgrades |
| Prompt & config versioning | Prompts, retrieval settings and thresholds version-controlled like code |
| Change control | Written impact assessment and sponsor notification before any model or prompt change reaches production |
| Regression testing | A fixed benchmark set per use case, re-run on every change, with results shared |
| Deprecation plan | Advance notice when a provider retires a model, and a tested migration path |
"We always use the latest model" in a GxP context.
Hallucination handling does not mean a model that never errs; it means a workflow where a wrong or invented output cannot reach the trial record unnoticed. Assume the model will sometimes be confidently wrong, and ask how the system catches it.
| Layer | Control | Clinical example |
|---|---|---|
| Grounding | Outputs drawn only from the study's own source data and documents, with no free generation of facts | A query draft cites the exact field values it is based on |
| Citation | Every statement links back to its source record or document passage | An AE narrative links each sentence to the eCRF entry it came from |
| Constrained output | Answers limited to controlled vocabularies and valid structures | Coding suggestions restricted to the licensed MedDRA or WHODrug version |
| Deterministic checks | Rule-based validation runs on AI output before it is shown | Suggested SDTM mapping checked against controlled terminology and the define.xml spec |
| Human review | Risk-tiered approval (Principle 1) as the final gate | Data manager approves each coding suggestion |
Ask the vendor: What was the measured error rate on the benchmark for each use case, how was it measured, and what happens operationally when an error is found after approval (correction, impact assessment, CAPA)?
"Our model rarely hallucinates" — with no benchmark, no citations, and no abstain behaviour.
Contact Us
Reach out with questions about our eClinical products, services, or partnerships. Our team will respond promptly to discuss how Shilowiz can support your clinical trial needs.
Book a Meeting Now
Schedule time directly with the Shilowiz team for personalized demos or in-depth discussions about your clinical trial requirements.
Schedule a DemoChoose a convenient slot to speak with our experts about your study needs
