cTAKES USDHUBClinician documentation
Clinical basicsLookup page and glossary

What cTAKES is doing to the note

Apache cTAKES turns one unchanged note into reviewable candidate rows. It marks the exact source characters, attaches possible terminology meanings, then records assertion, relation, medication, and WSD fields when the corresponding engine supplies them. The candidate row still needs its source span and clinical context; the code or model field alone does not establish a diagnosis.

The exact words in the note come first

The wrapper keeps the original text unchanged. cTAKES records where a phrase begins and ends as two character offsets, so another person can return to the same characters and see exactly what produced a row. The note below is the same synthetic fixture that How it works walks station by station; its codes are fake on purpose, shaped like DEMO-C001 instead of real terminology identifiers.

Synthetic note

USDHUB00000000000000000001.SYNTHETIC-DEMO.txt
SymptomNegated symptomMedication
SYNTHETIC NOTE - no patient data.

Assessment
started yesterday. No .

Plan
Start 10 mg by mouth twice daily for 5 days.

Imaging context
A near the right kidney is described.

Select a phrase. The matching row below carries the same source evidence.

Source phraseSpanWhat cTAKES addsWhat it does not establish
46–62A concept candidate, semantic type, assertion fields, and a possible right-flank location relation.That the patient has a confirmed diagnosis.
85–90A concept candidate with polarity NEG because the note says "No fever."That every blank polarity elsewhere means positive.
104–111A medication candidate plus literal dose, route, frequency, duration, and status evidence.That the drug was dispensed, administered, taken, or reconciled.
170–174Two retained terminology candidates and, only when every WSD requirement passes, one Y and one N.That either candidate is a clinically confirmed finding.

The row stays connected to the phrase that created it. Clinical review happens after extraction, not inside the terminology lookup.

The identifier fields on a candidate row

"Renal calculus" and "kidney stone" are different wording for one clinical idea, and the CUI, a Concept Unique Identifier, is the shared code that links both to it. A real CUI is the letter C plus seven digits, such as C0015733 for the feces concept. The note above uses fabricated DEMO- codes. The fixture rows and codes are made up, and the site does not embed a dictionary extract. The separately labeled reviewed failure on the WSD page names real CUIs. The code system behind the CUI is UMLS, the Unified Medical Language System; How it works introduces terminology, ontology, and UMLS beside the synthetic fever span.

The mapping does not decide whether the concept is true for this patient or guarantee that one CUI perfectly captures the sentence. Assertion fields and the source sentence carry that separate information, such as negation or uncertainty.

Four identifiers clinicians will see

FieldPlain meaningExample use
CUIA UMLS Concept Unique Identifier. It links synonymous terms to one concept identity.Compare concept counts across sites without relying on the exact note wording.
RxCUIAn identifier from RxNorm, the standardized medication terminology, attached to a medication candidate.Keep the coded medication identity with the same CUI/RxCUI row.
TUIA UMLS semantic-type identifier. It says what kind of meaning the candidate is.Distinguish a disease/disorder type from an anatomy or drug type.
Preferred termThe dictionary's selected human-readable label for that candidate.Display the terminology label beside the original note phrase.

The recipe names the engines and their order

The recipe is a small .piper file that tells cTAKES which analysis engines to load and in what order; order matters because one stage often needs annotations created by an earlier stage. The default recipe's key is star, and its full stage-order table, with what each engine adds and why the order holds, is on Dictionary and recipes. How it works walks the same order on the synthetic note.

Assertions describe how the note talks about a candidate

A CUI alone says which concept matched. Assertion fields say whether the language is negated, uncertain, conditional, generic, or about someone other than the patient. The wrapper keeps missing values blank because a fabricated default would look like a model result.

Source wordingCandidateAssertion interpretation
"No fever"Fever candidate remainsPolarity is negative. The row is retained so the absence is represented rather than erased.
"Possible obstruction"Obstruction candidate remainsUncertainty may be populated by the Apache assertion model.
"Mother had stones"Stone candidate may remainSubject can distinguish family context when the model supports it; blank remains blank when it does not.

Degree and location relations are separate. A relation is a directed link between two annotations: a pain candidate can link to a right-flank anatomy candidate, while a severity cue such as "severe" can link to the concept it modifies. These links still need representative clinical review because a structurally valid relation can point in the wrong direction or attach to the wrong nearby site.

WSD handles one phrase with more than one candidate

Word-sense disambiguation (WSD) runs when one text span carries multiple distinct candidate meanings, the way "mass" at span 170–174 carries a body-structure candidate and a quantitative one. It keeps every candidate row, and it writes one Y, one or more N values, and scores only when a passing decision is possible; otherwise it abstains and both WSD columns stay blank. The score compares candidates inside that one ambiguity group and is not the probability that the concept is clinically true. The WSD page carries the full method, the decision path, the thresholds, the wrapper 2.1.1 controlled 858-note comparison, and the not-evaluated clinical status.

Federated learning keeps the source notes at each site

In a federated study, Site A and Site B do not pool their raw notes into one central folder: each site runs the same extraction definition locally, and only protocol-approved results cross the boundary. The wrapper supplies the first requirement, because both sites can prove they used the same wrapper source, pipeline, dictionary bytes, SQLite schema, and WSD model by comparing analysis_id; it does not implement the federated trainer, authentication, secure aggregation, coordinator, or privacy accounting. Multi-site use carries the full workflow and data boundary.

The site-wide glossary

Every page on this site links here. Terms are defined the way this wrapper uses them, not as general textbook entries.

TermMeaning in this wrapper
AnnotationA span of source text plus fields cTAKES attached to that span.
UMLSThe Unified Medical Language System. It connects many source terminologies under shared identifiers and semantic types; the local release here is 2026AA.
MetathesaurusThe UMLS component that merges the source vocabularies into one set of concept tables, such as MRCONSO and MRSTY. The 2026AA dictionary build reads these files; the raw release is not queried for every note.
RxNormA standardized medication terminology. An RxCUI identifies a drug concept such as an ingredient or brand candidate.
SNOMED CTA broad clinical terminology used here as one source of findings, disorders, anatomy, procedures, and other clinical concepts.
LOINCA terminology for laboratory tests, clinical measurements, and related observations. Its UMLS source abbreviation is LNC.
CAS / XMIThe native cTAKES analysis object, and its XML serialization. It contains the full note and many intermediate annotations.
CandidateA supported terminology or medication match emitted by cTAKES. It is not automatically an adjudicated clinical fact.
DictionaryThe local database cTAKES queries to turn note phrases into terminology candidates.
OntologyThe maintained concept system that gives clinical meanings stable identifiers and relationships.
NERNamed-entity recognition: finding bounded mentions such as medications in source text and attaching structured fields.
POSPart of speech, such as noun or verb, assigned to a token and retained as syntax evidence.
UIMAThe framework cTAKES uses to pass one analysis object through an ordered set of engines.
UTF-16 offsetA begin or end position counted the way Java indexes text. The stored offset lets the reviewer recover the exact source characters, including text outside basic ASCII.
RelationA directed link between annotations, such as a finding linked to an anatomic location or degree indicator.
Piper / recipeThe ordered cTAKES stage definition used for the run.
AssertionModel output such as polarity, uncertainty, conditional, generic, or subject.
WSDCandidate-preserving word-sense disambiguation for same-span ambiguity groups.
YTEXThe Apache cTAKES/YTEX extension whose native WSD implementation was measured as a comparator in the wrapper 2.1.1 controlled 858-note run. The USDHUB recipe does not load it.
SQLiteThe canonical relational database that stores exact source notes, rows, and run identities before the CSVs are exported.
JDBCJava Database Connectivity, the driver interface Java uses to open a database. The pinned SQLite JDBC 3.45.3.0 jar is what lets the Java writer commit annotations.sqlite.
quick_checkSQLite's own corruption scan. The post-run read-back runs it against annotations.sqlite before a batch can be accepted.
analysis_idA content-derived identity for the extraction definition: wrapper source, effective recipe, dictionary database, schema, and WSD state/model.
run_idA new audit identity for one execution. Two runs can share an analysis ID and still have different run IDs.
ReceiptA JSON or manifest file recording what was checked, which bytes ran, and whether the batch completed.
ManifestA file naming what a bundle or run must contain. The dictionary manifest pins the expected descriptor hash, database hash, UMLS release, and source inventory; run_manifest.json records whether the run completed.
SHA-256A cryptographic fingerprint of a file's exact bytes. The wrapper records it for archives, the dictionary database, the WSD model, and each stored note text, so changed bytes are detectable.
JVMThe Java Virtual Machine, the process that runs cTAKES 6.0.0 and the wrapper's Java writers. Model and dictionary loading happen inside it before the first note finishes.
Heap / XmxThe JVM's main working memory, and the Java flag that caps it. The wrapper sizes the heap from memory actually available inside the job boundary, not from total host RAM.
cgroupA Linux control group: the kernel boundary that limits the CPU and memory a job can use. The capacity probes read cgroup quotas so a container with a two-core quota is not planned as the full host.
RSSResident set size, the physical memory a running process actually holds. The isolated WSD comparison reports it per process; peak RSS monitoring stays with infrastructure tooling.
PHIProtected health information: patient-identifying content in clinical data. Notes, SQLite, XMI, the built-in viewer session, an optional browser export, and logs can carry it, so every note-derived artifact and review session stays inside clinical-data controls.

Continue to the exact terminology selection, or see how these terms and identities appear in the delivered files.

Nextthe checks around cTAKES, before, during, and after the runWrapper details