Clinical data visualization
your medical monitors will open every morning.
Sponsor-controlled dashboards built from SDTM and ADaM inside your environment: interactive patient profiles, protocol-specific oversight views, RBQM site risk, lab shifts, exposure and safety signals. Spotfire first because it is what your reviewers already know; SAS Visual Analytics where the estate runs on Viya; R Shiny, D3.js or Highcharts when a view needs full control of rendering. Every dashboard is accepted against a written spec before it goes to a monitor.
Oversight that arrives as a PDF is oversight that arrives late
Three patterns we see in almost every sponsor that still runs study oversight from static listings.
Subject-level review happens in a PDF produced weekly by programming. By the time a lab excursion is noticed, the next visit has happened. The listing is accurate and useless at the moment it is needed.
The CRO provides a portal with the views it provides to everyone. Adding your protocol-specific endpoint is a change order; the data behind it is a snapshot you do not control; and when the study transfers, the history does not come with it.
Site risk indicators are calculated by hand from EDC exports, by one person, monthly. The method is sound and the cadence is wrong. Risk-based monitoring that cannot be refreshed is a quarterly report with a different name.
One subject, one timeline, every domain
The view reviewers ask for first. Demographics, exposure, adverse events, labs, vitals and concomitant medications for one subject on a single timeline, generated per study from your standards, self-service for medical monitors and safety reviewers.
Spotfire first, then what the view needs
Platform choice follows the review task and the estate you already run, not a preference of ours.
Information links against your SDTM and ADaM, GxP access control through your identity provider, versioned analyses under change control. Where Spotfire is already licensed, the fastest path to an oversight view the monitors trust. We also build the Spotfire operating model: environment governance, analysis library, developer standards and reviewer enablement.
Reports and explorations served from CAS, sharing the same validated data layer as the programming work. One security model, one lineage, no second copy of the data to govern.
Protocol-specific displays that no off-the-shelf tool renders well: adjudication timelines, exposure-response overlays, DMC packages with locked snapshots. Built under the same validation approach as the programming deliverables.
Protocol-specific views, not a generic portal
Screening to randomization funnel by site and region, endpoint accrual against plan, visit compliance and query aging, with drill-down to subject.
Adverse event incidence by system organ class and arm, lab shift tables with excursion flags, potential drug-induced liver injury quadrant views, exposure and dose-modification history.
Key risk indicators calculated from EDC and CTMS feeds on a schedule, thresholds owned by your clinical quality lead, site risk trends with the evidence behind each flag.
Closed and open reports generated from a frozen cut, versioned, reproducible on request, with the unblinded path separated by role.
Metadata-driven ETL from RAVE, Veeva Vault or Oracle into the analytical layer, conformance checks in the pipeline, refresh on a cadence the study team sets.
Signal rules are written down, validated and owned by your reviewers. Where a model assists, it proposes and a person disposes; nothing alerts a monitor on model output alone.
Three phases, each accepted before the next
Visualization work is scoped as a corridor: one study, one set of views, one group of reviewers, accepted against the spec before the next corridor opens.
Four to ten weeks. The environment your dashboards will run on is made validated and yours: server or tenancy, access control, data layer, refresh schedule, change control. If the estate is already sound, this phase is a review, not a build.
Six to fourteen weeks. The protocol-specific views are built and accepted one at a time: spec, build, reviewer walkthrough, acceptance. Patient profiles usually go first because they are the view everyone uses.
Ongoing, limited availability. New studies onboarded from the same standards, views maintained through protocol amendments, reviewer questions answered by people who built the views.
Every dashboard runs under the four rules
The same rules that govern the programming work govern the views built on top of it.
Rules settle every case they can. A model is consulted only for the residual the rules cannot decide, and its output passes through the same rules before anyone sees it.
Processing runs in your environment, under your identity system. Nothing potentially unblinding reaches an outside model. The data flow diagram is available under NDA before kickoff.
Every output that matters is accepted by a person on your side whose name is on the record. Model output never writes a finding into a deliverable on its own.
Inputs, versions, tool events and decisions are logged as they happen, so the packet an auditor asks for exists before the audit does.
What you provide, what you receive, who signs
Current Spotfire or SAS Visual Analytics posture, EDC and data-transfer specs, protocol endpoints, the RBQM plan, hosting constraints, the names of the reviewers who will use the views.
A validated environment you own, metadata-driven ETL, protocol dashboards and patient profiles, signal alerts with their rules, DMC-ready reporting, governance documentation, reviewer enablement.
Clinical operations and biometrics leads accept each dashboard against its spec. Signal rules are validated by your reviewers before they alert anyone.
Before you decide
The questions that come up in the first technical conversation, answered the way we answer them on a call.
Do you only work in Spotfire?
No. Spotfire goes first where it is licensed and the reviewers know it, because the fastest route to an oversight view people trust is the one they already use. SAS Visual Analytics, R Shiny, D3.js and Highcharts are used where the estate or the view calls for them. The spec decides, not a platform preference.
Is the data copied to a vendor cloud?
No. The dashboards run in your environment, on premise or in a tenancy you own, under your identity system. We do not host clinical data and the data flow diagram is shared under NDA before kickoff.
Can the views be validated for GxP use?
Yes. Each dashboard has a written spec, test evidence, and an acceptance record signed by your reviewer. The data layer is built under change control with lineage from source to view. Validation scope is agreed in the proposal and matches how your organization qualifies tools.
How is unblinding handled?
Role-separated access at the data layer, not at the chart. Open and closed views are built as distinct analyses with distinct permissions, and the unblinded path is documented and tested before any DMC use.
What about AI-assisted signal detection?
Rules first. Where a model assists, it proposes candidates for a reviewer; it never raises an alert on its own and never writes to the record. The evaluation evidence for any model-assisted step is part of the validation package.
How is the engagement priced?
Against a written statement of work with deliverables, milestones and acceptance criteria, after a scoping conversation. No figure is quoted before the scope is understood.
Where this sits
A complete synthetic TLF QC run with its evidence packet: what a corridor looks like when it is finished.
OPEN THE EVIDENCE ROOMThe validated data layer most dashboards are built on: Viya migration, 9.4 optimization, LSAF to Clinical Acceleration.
SEE THE SAS PRACTICETen services across two layers and the corridor map.
BACK TO THE CLINICAL HUBStart with the view your reviewers ask for most.
Tell us the study, the systems and who will use the views. We reply with a scoped proposal: deliverables, milestones and acceptance criteria.
Or start with the Validated Automation Review: two to four weeks, one workflow corridor, fixed scope. The plan is yours whether or not we build it.