Submission-ready SDTM in
days, not weeks
BuildSDTMs turns raw clinical data into audit-trailed CDISC SDTM datasets and define.xml from one canonical mapping spec, with dual R and SAS output and 21 CFR Part 11 audit by construction.
Six weeks of senior programmer time, and no trail to prove it
A typical SDTM build runs two senior programmers for roughly six weeks plus independent QC, around 144 thousand dollars a study. The mapping logic lives in scripts nobody can read at a glance, and when an inspector asks how a value was derived the answer is in someone's memory.
× Programmer-weeks per domain
Every study re-maps the same domains by hand, and the senior time spent on plumbing is time not spent on the science.
× Opaque, unreviewable logic
Transformations hide in one-off macros. There is no single spec a reviewer can read and sign, and no diff when it changes.
× Audit prep is a fire drill
Reconstructing who derived what, when, and why from files and email costs days and still leaves gaps before a submission.
One canonical spec, dual R and SAS output, audit-trailed by construction
BuildSDTMs makes the mapping spec the single source of truth, generates reviewable code in both languages, and records every step in an append-only trail. It produces transparent code, not a black box.
Author the mapping once. Source-to-SDTM logic lives in a single reviewable specification a programmer can read and sign.
Generate matching R and SAS from that one spec. Run R in the platform, or hand the SAS to your own validated environment.
Every build, review, and approval is an append-only event with server time, actor, and a content hash. Nothing is editable after the fact.
A gated nine-state build for every domain
- Each domain moves through specced, mapped, generated, reviewed, executed, conformance, QC, approved, and frozen.
- A human approves each gate, and the workflow cannot skip a state or move backward without an audit event.
Why it mattersThe state of every domain is unambiguous and provable, so nothing reaches a submission without passing review, QC, and conformance first.
Named data sources, encrypted at rest
- Connect SAS transport, CSV, Excel, or a Postgres source as a named, reusable data source.
- Credentials are sealed with envelope encryption and resolved to plaintext only at connection time, never written to a log.
Why it mattersYour raw data and its connection secrets stay protected and tenant-scoped, so the same study setup is reusable without copying credentials around.
| Data source | Type | Secret | Status |
|---|---|---|---|
| raw_edc_prod | PostgreSQL | encrypted | connected |
| labs_central | SAS xpt | encrypted | connected |
| randomization | CSV | encrypted | connected |
| pk_vendor | Excel | encrypted | awaiting key |
One mapping spec, matching R and SAS
- The spec compiles to readable R and to SAS that follow the same logic line for line.
- Run the R in the platform on a pinned image, or take the SAS to your own validated environment.
Why it mattersYou are never locked in. The generated code is the deliverable, fully reviewable, and runs the same way on your platform as on ours.
R and SAS, checked to be identical
- The platform runs both engines and compares the resulting datasets value by value.
- It hashes each output and confirms the two match before the domain can advance.
Why it mattersYou get proof that the two languages agree, so a reviewer can trust either output and the dual-language promise is verified, not assumed.
Conformance findings before you submit
- A conformance preview runs the standard rule checks against each built domain.
- Errors and warnings are listed with the rule, the variable, and the affected record count.
Why it mattersYou find and fix the issues that fail a gateway long before the package leaves your hands, not after a rejection.
| Rule | Domain | Records | Level |
|---|---|---|---|
| SD0064 | AE | 2 | warning |
| SD1077 | LB | 1 | warning |
| SD0002 | DM | 0 | pass |
Define.xml generated from the same spec
- The data documentation is built from the mapping spec, so domains, variables, and value-level metadata stay in step with the data.
- Export submission-ready define.xml without re-keying anything.
Why it mattersThe define and the datasets can never drift apart, which removes one of the most common and costly submission findings.
An append-only trail, scoped to your tenant
- Every action writes an event with actor, server time, and a content hash to an append-only ledger.
- Row-level security keeps each tenant's data and audit separate at the database, and updates or deletes to the ledger are rejected even for an admin.
Why it mattersThe evidence an inspector wants is captured as you work, tamper-evident and exportable, rather than reconstructed under deadline.
| When | Actor | Event | Hash |
|---|---|---|---|
| 09:14:02 | j.okafor | DM approved | 7c1a…e9 |
| 09:02:51 | m.reyes | DM QC signed | b40f…2a |
| 08:47:19 | system | R / SAS verified | a3f1…9c |
| 08:31:08 | j.okafor | code generated | 5d8e…11 |
Built for the work hand-written SAS leaves undone
| Capability | Hand-written SAS | Pinnacle 21 | Veeva Vault / LSAF | BuildSDTMs |
|---|---|---|---|---|
| One spec, matching R and SAS output | ||||
| Submission-ready define.xml from the spec | ||||
| Conformance preview built in | ||||
| Dual-engine reproducibility self-check | ||||
| Append-only Part 11 audit trail | ||||
| Build time measured in days, not weeks |
One build, six points of view
Lead statistical programmer
Author the mapping spec once, see every domain's state on one board, and approve gates with the evidence attached.
QC programmer
Review generated code and the dual-engine compare in one place, then sign off knowing the trail is captured.
Biostatistician
Trust that the SDTM feeding analysis passed conformance and QC, with the derivation visible for any value.
Data manager
Register named sources once and reuse them across studies without copying credentials or re-wiring connections.
Submission lead
Ship datasets and a matching define.xml that cannot drift, with conformance already cleared.
QA / auditor
A read-only, tamper-evident trail and a one-click export, ready for inspection on demand.
Regulatory rigor, by construction
The controls auditors look for are inherent in the system, not bolted on after the fact.
21 CFR Part 11
Append-only audit trail, server-time stamping, access control, and human-gated approvals on every domain.
Audit immutability
Updates and deletes to the ledger are rejected by the database, so the record cannot be rewritten even by an admin.
Envelope-encrypted secrets
Source credentials are sealed at rest, resolved only at connection time, and never written to a log.
Tenant isolation
Row-level security separates every tenant's data and audit at the database, verified through the request path.
Build one of your domain sets in a 30-day pilot
See BuildSDTMs map your real source data to SDTM, generate dual R and SAS, and produce a define.xml and audit trail in days. No infrastructure to stand up, and the code is yours to keep.
- We load one of your studies into a private workspace
- Your team maps, generates, and QCs a domain set end to end
- You keep the generated R and SAS plus the define.xml
- A readout on time saved against your current build
info@the-bdkm.com · BDKM LLC · Back to Life Sciences