cTAKES USDHUBClinician documentation
Start-to-finish walkthroughRelease 2.1.19Fictional screenshots

Run cTAKES from the terminal interface

The TUI keeps one clinical run in a fixed sequence: verified installation, fictional known-answer test, no-write batch check, background extraction, post-run read-back, local review, and two-file handoff. Each screen names the current state and the next permitted action, so a complete note count cannot be mistaken for an accepted delivery.

Deliverconcepts.csv

The 13-column concept extract.

Deliverdrugs.csv

The 16-column medication and RxNorm extract.

Keep localEverything else

SQLite, receipts, logs, manifests, optional XMI/browser HTML, and prepared-note receipts support audit, review, and recovery. Do not include them in the routine handoff unless the protocol owner explicitly requests them and the transfer is approved.

Install and run the known-answer test

The main branch keeps the source current. Setup downloads the release-matched immutable assets, verifies their checksums, chooses the newest supported Python already on the machine, and creates a private virtual environment. It does not replace the system Python.

Clone without executing the checkout

git clone --branch main --depth 1 https://codeberg.org/editnori/Ctakes_USD.git Ctakes_USD

Verify the local checkout

A pass prints Verified clean main checkout: and the local commit ID. If the exact-remote, branch, or clean-state check fails, stop.

test "$(git -C Ctakes_USD remote get-url origin)" = "https://codeberg.org/editnori/Ctakes_USD.git" && test "$(git -C Ctakes_USD branch --show-current)" = "main" && test -z "$(git -C Ctakes_USD status --porcelain)" && printf 'Verified clean main checkout: ' && git -C Ctakes_USD rev-parse --short=12 HEAD

Run setup from the verified checkout

cd Ctakes_USD && bash scripts/setup.sh --tui && ./ctakes verify && ./ctakes tui

After installation, reopen the interface from any folder with ctakes tui. If the shell has not refreshed its PATH, enter the repository and use ./ctakes tui.

Confirm the home screen says ready

The green ready banner means setup, system diagnostics, and the included sample test have passed. If the screen instead offers Run sample test, run it before selecting clinical notes. Then choose New run.

cTAKES USDHUB TUI home screen with a green Ready to process notes banner and New run selected.
Screen 1. A ready home screen after setup, diagnostics, and sample testing pass. Open full size

Choose the note folder and results folder

Select the approved folder containing the input notes, then select or accept a separate results folder. The note folder may contain subfolders, but it must contain only .txt notes. Keep XML, CSV, and other files outside it.

  • Each filename begins with literal USDHUB plus exactly 20 digits.
  • A period separates that HubID from a safe NoteID, followed by .txt.
  • Letters, digits, periods, underscores, and hyphens are allowed inside NoteID; dots inside NoteID are valid.
  • If the source names use PID or HID instead, use Prepare compatible copy. Preview the mapping and write a new private copy; do not rename the originals in place.
New run screen with separate fictional notes and results folder fields filled in.
Screen 2. Select the source notes and their separate results destination. The example uses fictional notes and neutral paths. Open full size

Run Check and read the summary

Choose Check run. This is a no-write preflight: it scans the note set, validates every filename, estimates storage, checks CPU and memory, and confirms the release-matched dictionary, WSD model, and SQLite driver. On a large folder, the summary is intentionally aggregated rather than printing thousands of repeated filename errors.

Confirm that the note count, folder, clinical settings, capacity, and storage estimate match what you intend to run. Start remains disabled until every required gate passes.

New run preflight summary showing 100 valid note filenames, three parallel jobs, and checked storage.
Screen 3. The no-write check has passed and the run summary is ready for review. Open full size

Confirm the clinical run and background handoff

Choose the Start button labeled with the note count, such as Start 100. Read the confirmation and continue only if the displayed folders, note count, and clinical settings are correct. The default is the STAR recipe, strict filenames, WSD on, SQLite plus two CSVs, XMI off, automatic capacity scaling, and final sanity checking.

The controller records the job before starting cTAKES and waits for a background-process handshake. Do not close the window until the confirmation says the background run has started.

Start this run confirmation dialog showing 100 notes, three parallel jobs, and that the run survives closing the window.
Screen 4. The final confirmation before the run is handed to the background controller. Open full size

Monitor progress, or leave and reconnect later

Runs & cTAKES logs shows the current phase, completed notes, elapsed time, rate, remaining-time estimate, CPU, memory, and storage. Sharded runs aggregate validated shard progress into the same job row. During startup, the total can temporarily show as unknown; rate and remaining time begin after notes finish.

Once the background-start handshake completes, leaving the TUI or losing the SSH session does not intentionally stop the controller. Reconnect and run ctakes tui to reopen the saved job. If the host or process actually stops, the TUI reconstructs the recorded state and offers recovery only from shards that validate against the same analysis and input identities.

Runs and cTAKES logs screen showing a fictional run starting in the background and the saved sample test below it.
Screen 5. One progress view covers direct and sharded runs without requiring the live log text. Open full size

Wait for PASSED, not only 100% notes

When all notes finish, the run can remain in CHECKING or FINALIZING while it builds indexes, exports the two CSVs, reads them back against SQLite, validates hashes and receipts, and writes the completion state. Accept the run only when it shows PASSED, the run manifest is complete, and the sanity report passes.

Runs screen showing a completed fictional cTAKES job with PASSED status and all notes finished.
Screen 6. A completed job after notes, export, read-back, receipts, and sanity checks pass. Open full size

Review the checked result inside the TUI

Select the passed run and choose Open built-in viewer. The viewer opens the receipt-bound SQLite database and lets an approved reviewer page through notes, concepts, and medications. Selecting a row highlights its exact source phrase. No separate browser file is required.

Built-in results viewer showing the verified fictional document index with Hub IDs, Note IDs, character counts, concept counts, and medication counts.
Screen 7. The built-in reviewer reads the checked SQLite run without creating a second note-bearing file. Open full size

Read the canonical role and exact file to send in one place

After a clinical run passes, the detached controller creates one private folder-named copy for each checked CSV. Nothing is uploaded or sent. Return to the passed run and choose Check output. The concept row reads concepts.csv (canonical) → …--concepts.csv (file to send), and the medication row uses the same shape. The left name is the stable internal role. The right name is the physical file to send.

Technical files screen listing the verified run artifacts with concepts.csv selected as the approved concept handoff.
Screen 8. Technical files distinguishes the two CSV deliveries from local audit and review artifacts. Open full size

The passing sanity check already compares both CSVs with the accepted SQLite views and records their hashes. The automatic action reuses that bound proof, writes owner-only copies while hashing them, and writes a small receipt, so it does not repeat the full SQLite parity scan. The copy name is deterministic, so a retry verifies the same published bytes or rebuilds only the wrapper's own unpublished staging directory. A changed published handoff fails closed and is not overwritten. If the copy needs disk or filesystem attention, the clinical run remains passed and shows HANDOFF ATTENTION with Retry automatic CSV copies. A verified older run without an automatic-copy record may show Prepare automatic CSV copies. Technical files reports AUTOMATIC CSV COPIES READY and keeps the canonical artifacts available for local review, but it does not repeat the handoff names.

Check output screen showing concepts.csv and drugs.csv as canonical roles beside the exact folder-named files to send.
Screen 9. Check output records each logical CSV once and places its canonical role beside the exact handoff filename. This five-note naming proof used synthetic data on CPM2. Open full size

An exceptional extra labeled copy is a command-line-only option: ./ctakes handoff <job-id> --name <safe-label>. Never put PHI in that label.

SendNamed concepts.csv copy

13 approved columns; generated from the passed run.

SendNamed drugs.csv copy

16 approved columns; generated from the same passed run.

RetainAudit and recovery artifacts

Keep SQLite, JSON receipts, logs, manifests, the copy receipt, optional XMI, and optional browser HTML locally unless an explicit approved request expands the handoff.

Outputs and review lists every column in both delivery files and explains what each local artifact is used for.

Nextunderstand every delivery field and local audit artifactOutputs and review