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.txtSYNTHETIC 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 phrase | Span | What cTAKES adds | What it does not establish |
|---|---|---|---|
| 46–62 | A concept candidate, semantic type, assertion fields, and a possible right-flank location relation. | That the patient has a confirmed diagnosis. | |
| 85–90 | A concept candidate with polarity NEG because the note says "No fever." | That every blank polarity elsewhere means positive. | |
| 104–111 | A medication candidate plus literal dose, route, frequency, duration, and status evidence. | That the drug was dispensed, administered, taken, or reconciled. | |
| 170–174 | Two 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
| Field | Plain meaning | Example use |
|---|---|---|
CUI | A UMLS Concept Unique Identifier. It links synonymous terms to one concept identity. | Compare concept counts across sites without relying on the exact note wording. |
RxCUI | An identifier from RxNorm, the standardized medication terminology, attached to a medication candidate. | Keep the coded medication identity with the same CUI/RxCUI row. |
TUI | A 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 term | The 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 wording | Candidate | Assertion interpretation |
|---|---|---|
| "No fever" | Fever candidate remains | Polarity is negative. The row is retained so the absence is represented rather than erased. |
| "Possible obstruction" | Obstruction candidate remains | Uncertainty may be populated by the Apache assertion model. |
| "Mother had stones" | Stone candidate may remain | Subject 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.
| Term | Meaning in this wrapper |
|---|---|
| Annotation | A span of source text plus fields cTAKES attached to that span. |
| UMLS | The Unified Medical Language System. It connects many source terminologies under shared identifiers and semantic types; the local release here is 2026AA. |
| Metathesaurus | The 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. |
| RxNorm | A standardized medication terminology. An RxCUI identifies a drug concept such as an ingredient or brand candidate. |
| SNOMED CT | A broad clinical terminology used here as one source of findings, disorders, anatomy, procedures, and other clinical concepts. |
| LOINC | A terminology for laboratory tests, clinical measurements, and related observations. Its UMLS source abbreviation is LNC. |
| CAS / XMI | The native cTAKES analysis object, and its XML serialization. It contains the full note and many intermediate annotations. |
| Candidate | A supported terminology or medication match emitted by cTAKES. It is not automatically an adjudicated clinical fact. |
| Dictionary | The local database cTAKES queries to turn note phrases into terminology candidates. |
| Ontology | The maintained concept system that gives clinical meanings stable identifiers and relationships. |
| NER | Named-entity recognition: finding bounded mentions such as medications in source text and attaching structured fields. |
| POS | Part of speech, such as noun or verb, assigned to a token and retained as syntax evidence. |
| UIMA | The framework cTAKES uses to pass one analysis object through an ordered set of engines. |
| UTF-16 offset | A 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. |
| Relation | A directed link between annotations, such as a finding linked to an anatomic location or degree indicator. |
| Piper / recipe | The ordered cTAKES stage definition used for the run. |
| Assertion | Model output such as polarity, uncertainty, conditional, generic, or subject. |
| WSD | Candidate-preserving word-sense disambiguation for same-span ambiguity groups. |
| YTEX | The 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. |
| SQLite | The canonical relational database that stores exact source notes, rows, and run identities before the CSVs are exported. |
| JDBC | Java 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_check | SQLite's own corruption scan. The post-run read-back runs it against annotations.sqlite before a batch can be accepted. |
analysis_id | A content-derived identity for the extraction definition: wrapper source, effective recipe, dictionary database, schema, and WSD state/model. |
run_id | A new audit identity for one execution. Two runs can share an analysis ID and still have different run IDs. |
| Receipt | A JSON or manifest file recording what was checked, which bytes ran, and whether the batch completed. |
| Manifest | A 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-256 | A 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. |
| JVM | The 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 / Xmx | The 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. |
| cgroup | A 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. |
| RSS | Resident 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. |
| PHI | Protected 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.