A Configured Workflow
Source code and configuration for the agreed task, approved references, tool permissions and model connection.
Your Review Can the workflow perform the agreed task in your test environment?
Clinical / Platform intelligence + Operational intelligence
Deterministic first. Reviewed always.
Clinical Practice
Home
Clinical Catalyst / Catalyst CodeOps
Clinical Catalyst CodeOps combines AI-assisted programming, execution checks and a review record in one scoped implementation. Start with TLF QC, SDTM mapping or ADaM programming and receive the agreed source and handover in your approved environment.
For Biometrics and Programming Leaders
One workflow to start. A named reviewer. Measured results before expansion.
What You Receive / For an Agreed Build
Agree these outputs and their acceptance criteria before work starts. The pilot defines a limited scope; production integration and handover follow a separate decision.
Source code and configuration for the agreed task, approved references, tool permissions and model connection.
Your Review Can the workflow perform the agreed task in your test environment?
Execution checks, comparison rules, tolerances and discrepancy outputs, with documented failure behavior.
Your Review Do known failures get caught, and are differences explained?
Input and output versions, source references, comparison results, test evidence and named reviewer decisions.
Your Review Can your team trace a result to its inputs and acceptance decision?
Operating guidance, training and change controls, plus the agreed baseline and pilot measurement report.
Your Review Can the designated owner run, monitor and maintain the agreed scope?
Your team provides the environment, approved references and reviewers. INNOVIZZ implements the agreed workflow and evidence capture. Production release stays with your authorized team.
Retrieve approved examples and propose a candidate within scoped permissions. Retrieval does not train a model on client data.
Run in a controlled test workspace. Check the result against agreed references and block failed acceptance criteria.
Link versions, actions and comparison results to a named review decision. Define retention and integrity controls with QA.
Follow the Evidence / Synthetic TLF QC
A candidate table runs successfully but uses the wrong population. Follow how the check surfaces the discrepancy and how the QC lead returns it for correction.
Play the six-step walkthrough, or choose a stage.
Step 1 of 6
The task names the analysis population, the shell and the comparison reference. Access is limited to the approved study scope.
| Artifact | Version | Access |
|---|---|---|
| ADAE Analysis Data | Snapshot 04 | Read Only |
| TEAE Table Shell | Version 3 | Read Only |
| QC Specification | Version 2 | Read Only |
Your QC lead can confirm the agreed population and reference before any candidate is assessed.
Explore the review sequence with prepared inputs and outputs. The controls demonstrate reviewer choices; they do not execute SAS code.
Technical Review
Execution, output checks and comparison evidence support your reviewer. A score cannot override a failed mandatory criterion or authorize release.
Agree references, keys, tolerances and failure behavior before the pilot. L0 to L5 is the proposed Catalyst assessment model, not an industry validation standard.
Verify the language-specific execution checks, return status and log. SAS requires explicit log and result checks; a clean process exit alone is insufficient.
The expected output is created and can be read. L0 and L1 must pass before a comparison score is reported.
Compare names, types and required attributes against the agreed specification. Flag missing or unexpected columns.
Compare row counts, keys and expected categories. Equal row counts alone do not establish that the correct population was selected.
Check prespecified derived values and risk-relevant cells. Sampling cannot establish a complete match.
Compare all in-scope cells using agreed alignment, missing-value and tolerance rules. Figures and free text require separately specified review.
The draft weights are 15%, 20%, 25% and 40% for L2 through L5. The pilot specification must define each level's score calculation and which discrepancies block release. A high aggregate score cannot override a failed mandatory criterion.
Repeatability applies to fixed inputs, comparison rules and a controlled execution environment. It is not a promise that a language model generates identical code. A full reference match can still reproduce an error in the reference; independent QC, scientific review and validation remain necessary.
Choose One Starting Workflow
Start with a clearly defined task, an available reference result and a designated reviewer. Each workflow has a different acceptance decision.
Re-derive tables and listings from analysis datasets and compare candidate outputs with the agreed reference.
Cell-level discrepancy records, comparison scores and an evidence packet. Figures and free text go to a reviewer.
Apply established mapping rules first. Propose unresolved mappings with rationale and a standards reference.
Proposals, terminology check results and a record of mappings accepted, changed or rejected.
Draft derivations from specifications and approved programming patterns, then execute against a defined reference.
Candidate programs, comparison results and discrepancy explanations for review.
Normalize issue exports, identify duplicates and dependencies, and recommend an owner under your routing rules.
A review queue, dependency view and routing rationale linked to the source artifact.
Fit and Boundaries
Catalyst CodeOps is a way to add a reviewed programming workflow around your existing systems. Model deployment, approved retrieval, permissions and production access are specified with your IT and QA teams.
Existing infrastructure can be reused, but new components and changes still need a risk assessment and appropriate validation. No blanket exemption follows from an additive design.
The execution harness, source, operating guidance and agreed evidence records form part of the deliverables. Version the model, prompts, patterns and comparison rules so changes can be assessed.
Client data is not used to train or tune a model. Retrieval indexes and any patient-level processing remain within the agreed client-controlled boundary. Records alone do not establish regulatory compliance.
An approved data owner, usable reference outputs, a named reviewer and an operating audit trail are prerequisites. Platform licensing, infrastructure and specialist dependencies are established during scoping.
From Review to Operation
Start with a fit conversation. If an audit is useful, agree its scope and fee in writing. The audit stands alone; it does not commit you to a build.
Leave with a shared view of the workflow, readiness gaps and whether a paid audit is the right next step.
Map manual steps, dependencies, suitability and risk. Establish a measured baseline, prioritized opportunities and a pilot plan. You receive a standalone audit report and pilot scope. No commitment to proceed follows.
Start with one workflow on an agreed study scope. Inspect candidate outputs, failed checks and reviewer decisions before considering another workflow.
Complete integration, access controls, corpus indexing, SOP alignment, validation evidence and the operating handover against the agreed scope.
Onboard new studies, maintain approved patterns, assess model and prompt changes, and monitor results against the baseline.
Indicative planning ranges from the offering brief. Scope, systems, access, review capacity and the statement of work determine the schedule; these are not delivery guarantees.