Batch 1 completed 1,708,157 notes in 9 hours and 47 minutes
Batch 1 is one accepted run of 1,708,157 notes. Four workers completed the recorded plan, the aggregate SQLite and both CSVs passed their final read-back, the sanity report recorded zero errors, and WSD runtime validation passed. The timing, 60.14-note-per-second processing rate, hardware context, output sizes, and preliminary urinary-stone counts below belong to this run only.
The batch reached complete after every output check passed
The no-write input check inventoried all 1,708,157 notes once and finished in about 29 seconds. The accepted recovery contract then divided the batch into four async shards, assigned four pipeline threads and a 16,384 MB Java heap ceiling to each shard, and kept the aggregate Java heap ceiling at 65,536 MB. Combined observed memory stayed near 50 to 52 GB, and the output volume had 627.7 GB free after finalization.
| Execution specification | Batch 1 value | Evidence boundary |
|---|---|---|
| Compute host | CPM2, Linux x86-64 | Run location plus host inspection |
| CPU capacity | 2 × Intel Xeon Silver 4216 at 2.10 GHz; 32 physical cores and 64 logical CPUs | CPM2 lscpu inspection after the run |
| Installed memory | 404.7 GB decimal, reported by Linux as about 376.9 GiB | CPM2 free -b inspection after the run |
| Async plan | 4 shards × 4 pipeline threads | Accepted recovery_contract.json |
| Java heap plan | 16,384 MB per shard; 65,536 MB aggregate ceiling | Accepted recovery_contract.json |
| Clinical settings | STAR recipe, SQLite + 2 CSVs, WSD on, strict filenames, XMI off | Run manifest and receipt read-back |
| Software identity | Wrapper 2.1.19_2026AA.r1_6.0.0; Apache cTAKES 6.0.0; UMLS 2026AA dictionary | Run manifest and dictionary receipt |
| Timing measure | Batch 1 |
|---|---|
| Processing window | 7h 53m 24s |
| Engine wall time | 8h 03m 12s |
| Post-engine validation and export | 1h 43m 46s |
| Complete wall time | 9h 47m 21s |
The accepted output contains SQLite, two checked CSVs, and runtime receipts
The two CSV streams matched their scoped SQLite views during the final read-back. The sanity report passed the manifest, source-integrity, SQLite, WSD, embedded-source, and batch-CSV checks.
| Artifact | Approximate size | Checked state |
|---|---|---|
annotations.sqlite | 81.47 GB | Schema 8, checked |
concepts.csv | 19.73 GB | Row and cell parity checked |
drugs.csv | 1.53 GB | Row and cell parity checked |
run_manifest.json | 8.9 KB | Complete |
sanity_report.json | 2.0 KB | Pass, zero errors |
wsd_validation.json | 1.0 KB | Runtime pass |
The three main data files use about 102.73 GB in total. GB uses decimal storage units, where 1 GB equals 1,000,000,000 bytes.
The automatic handoff adds the batch-folder name
The canonical files stay named concepts.csv and drugs.csv inside the run folder because validation, recovery, and the viewer depend on those fixed names. After the run passes, the wrapper creates one owner-only handoff copy for each logical CSV under named-csv/. Because this input folder was batch_1, the automatic Batch 1 handoff is:
named-csv/batch_1--ctakes-async-20260724T232510Z-3615680/
batch_1--ctakes-async-20260724T232510Z-3615680--concepts.csv
batch_1--ctakes-async-20260724T232510Z-3615680--drugs.csvThe wrapper takes batch_1 from the selected notes-folder name automatically and adds the source run ID so separate runs cannot collide. Check output records each logical result once as canonical name → file to send. The automatic name has no handoff timestamp, so a retry verifies the same published bytes or rebuilds an interrupted unpublished staging directory instead of creating another timestamped set. A changed published CSV fails closed and is not overwritten.
Four direct urinary-stone CUIs identified the first cohort signal
The NIH project USDHub: community resource for Urinary Stone Disease research, project 1RC2DK140865-01, includes an aim to enrich USDHub from CT images and clinical notes with natural language processing and machine learning. This first readout checks whether the completed cTAKES batch contains the expected urinary-stone signal. It is an extraction inventory, not a phenotype validation or prevalence estimate.
The direct set used kidney calculi C0022650, kidney stone or nephrolithiasis C0392525, ureterolithiasis C0041952, and urolithiasis C0451641. NCBI MedGen documents the kidney-stone, ureterolithiasis, and urolithiasis mappings used in this preliminary set.
| Direct urinary-stone measure | Count |
|---|---|
| Candidate mentions | 178,146 |
| Notes with at least one core CUI | 104,728 |
| Notes with at least one core CUI not marked negated | 101,669 |
| Notes containing only negated core-CUI mentions | 3,059 |
| HubIDs with at least one core CUI | 4,548 of 4,996, or 91.0% |
| HubIDs with at least one core CUI not marked negated | 4,485 of 4,996, or 89.8% |
The person-level coverage is consistent with a urinary-stone cohort, while 6.1% of all notes contain one of the four direct CUIs. The batch averages 342 notes per HubID, so a patient-level history cannot count every note or repeated mention as a separate event.
The aggregate signal supports variable development, not clinical conclusions
The direct-stone coverage supports the intended cohort signal. It does not prove that cTAKES identified every true stone history or excluded every false one. A related concept in the same note does not prove that the stone caused the other condition, that both concepts refer to the patient, or that they belong to the same clinical episode.
An exact lookup for acute kidney injury CUI C2609414 returned no rows in the narrow code set. That is a code-set gap to investigate, not evidence that acute kidney injury is absent. The next pass needs a broader CUI and synonym set before evaluating that variable.
The most common raw co-occurring concepts also included generic rows such as stone, kidney, history, and pain. The output preserves candidates by design. The 142.9 million concept rows therefore cannot be treated as finished research variables.
The preliminary query stayed aggregate and read-only
The analysis opened the accepted SQLite file in immutable read-only mode and selected aggregate fields from run_metadata, documents, cui_counts, and terminology columns in concepts.
- No source note text was selected.
- No HubID, NoteID, filename, path, or row-level clinical value was printed or copied into this report.
- HubIDs appeared only inside
COUNT(DISTINCT ...). - Related-concept counts were limited to notes containing one of the four direct-stone CUIs.
- Counts overlap because one note and one HubID can contain several concepts.
The next pass should order approved note dates within HubID, separate current from historical and uncertain mentions, preserve conflicting evidence, collapse repeated references without collapsing separate events, and validate each final variable on a locked clinician-reviewed sample.
The install path now separates browser text from checkout execution
The README, install guide, troubleshooting guide, release notes, public TUI walkthrough, and versioned Word MOP use three separate steps: clone without running repository code, verify the exact remote/source/clean state with local Git, then run setup from that checkout.
The public site has no shell-command Copy button and no JavaScript path that writes site content to the clipboard. Commands and CSV examples remain visible and manually selectable. The site check fails if clipboard-writing code returns or if the clone command also invokes setup.sh or ./ctakes.