NLP at the BC Cancer Registry: From Pathology Reports to Privacy

Start at the top left: pathology reports are the registry's main source, and below them are the tasks NLP suits. The green brace shows why the old rule-based system failed, and the orange brace with the lightbulb lists the three new pipelines. The purple line at the bottom left is the practical idea I took away: simple methods go first. The right half is privacy: large models can memorize and leak their training data, so there are two defences, differential privacy and anonymization, and the blue tiers are how the registry anonymizes its reports. My takeaway is in the bottom-right corner.

The BCCR is a population-level, centralized registry: its mandate is to collect data on every reportable tumor among British Columbia residents, around 30,000 tumors a year, a number that grows with the population. Its main source of confirmation, as in most cancer registries, is the pathology report: a medical document describing a tissue sample or body fluid, which may or may not give a diagnosis.

A pathology report serves three uses:

Use	Who reads it	What for
Clinical	The doctor who ordered the test or did the procedure	Diagnosis and a treatment plan
Operational	The registry	Data that informs decisions and plans for future needs
Research	Researchers	Finding a cohort, such as breast cancer patients by estrogen receptor (ER), progesterone receptor (PR) and HER2 status

The report also carries a lot of personal information: the patient's name, personal health number (PHN), address and phone number, and the physician's name, registration number and contact details. That matters for the second half of this note.

Gondara places NLP as a subfield of machine learning, which is itself a subset of AI. Most of its recent progress comes from pre-trained models: models first trained on huge amounts of general text (think of all of Wikipedia and PubMed), then fine-tuned on a small domain-specific dataset for one task, such as predicting a diagnosis from pathology reports. The tasks this approach improved include classification (does this report contain cancer information?), question answering over a given context, chat, and data generation, for example generating synthetic pathology reports for a given disease.

The registry receives the provincial feed of pathology reports: upwards of a million a year, both cancer and non-cancer. Since 2020 it has used eMaRC Plus, free software from the US Centers for Disease Control and Prevention (CDC). eMaRC is rule-based: it keeps tables of terms (adenocarcinoma, carcinoma and so on) and flags a report as cancer when one of those terms appears.

Among the cancer reports, the registry must then separate reportable tumors, the ones national and international registry rules say it collects (breast, lung, colorectal cancer and most major tumors), from non-reportable ones, such as a basal cell carcinoma on a person's shin.

Rules cannot read context. A pathologist may write "I have reviewed this sample and there is no evidence of cancer." eMaRC sees "cancer" and flags the report as positive; it cannot combine "no evidence" with the word after it. The consequences pile up:

1. A high error rate on complex text.
2. Every classification has to be checked by hand, straining the registry's few subject matter experts.
3. Data arrive late: on average 18 months, so 2023 data become available in mid to late 2025, which is too slow for research.

Deep learning models do not rely on handcrafted rules, and they can use a much longer context. Could they do better? Gondara's answer: yes.

The BCCR has now built and deployed several NLP pipelines. A report travels through them in this order:

1. Stage one, eMaRC: decides whether the report contains any cancer information. It does a decent job here because it over-calls cancer: many false positives, so that few cancers are missed.
2. Pre-processing: removes the report header, which mostly holds patient and physician identifiers, and, depending on the project, keeps only useful segments such as the diagnosis and specimen sections.
3. Anonymization: language models and regular expressions remove the remaining identifiers (the last sections of this note).
4. Reportability: weeds out the non-reportable tumors and non-cancers that eMaRC let through.
5. Tumor group: assigns each report a broad tumor group (lung, breast, prostate, colorectal, melanoma, neuroendocrine and so on), so the work can go to the tumor registrars who specialize in that group.
6. Auto-coding: extracts the surveillance data fields from each report.
7. Consolidation: one person may have several reports about one tumor, such as biopsies and tests over a few months. Every pipeline above decides per report, but the registry collects data per tumor, so the reports are combined into a single tumor record.
8. Manual review: cases where the models may not have done well go to people, a human-in-the-loop design, before the data enter the registry.

✎ reading noteA reading note: in this picture "97–99% accuracy" sits next to "LLMs as final decision-makers", but they belong to two different pipelines. 97–99% is the reportability pipeline's accuracy on reportable tumors (a two-model ensemble, above 90% for non-reportable ones); the LLM is the tie-breaker in the tumor group pipeline. Rule-based keyword matching did not simply "fail" either: eMaRC is still the first filter.

What struck me most is how each pipeline picks its tools. Gondara put it with a proverb: if all you have is a hammer, every problem looks like a nail. The registry can use LLMs, but it does not want to overuse them where they are not needed.

Pipeline	Task	How it works
Reportability	Reportable or not (two classes)	Two fine-tuned language models, each reading a different section of the report. If either says reportable, the report is reportable, so that no reportable tumor is missed. Accuracy: about 97–99% for reportable tumors, above 90% for non-reportable ones
Tumor group	One of 19 tumor groups	Six small BERT-type models (each reads only about 512 tokens): three read the top of the report, three the bottom. They vote; if enough agree, that group wins. If not, a large language model reads the whole report plus the six votes and decides
Auto-coding	Behavior (benign, in situ, invasive), laterality, site, histology and more; neoadjuvant therapy; whether an addendum is present	A suite: regular expressions for simple patterns ("right breast", "left lung"), question answering for what a report mentions (does it give the ER status?), language-model classifiers for harder labels
Consolidation	Report-level data to tumor-level data	No NLP: business logic in ordinary code, such as which item takes priority when two reports fall within a time window

The tumor group task shows why the design is layered. Where a report names the tumor group varies: at the top, the bottom, the middle, or ambiguously. A specimen may be taken from the breast but tested for squamous cell carcinoma or melanoma, which has nothing to do with breast cancer. Small models with short context windows see only part of the report, so the large model, which can read all of it, is kept for the cases where they disagree. In the published version, the large model steps in when fewer than five of the six agree.

My practical idea from this: let the simple method go first. Use a regular expression when a pattern does the job, a BERT-type classifier next, and an LLM last, for what remains hard. Each step is cheaper, faster and easier to check than the one after it.

Pathology reports are full of personal identifiers. Leaking any of them can lead to stolen or forged identity, and unauthorized access breaks privacy laws such as British Columbia's Personal Information Protection Act (PIPA) and Canada's PIPEDA, much as HIPAA does in the US. Yet a diagnostic or prognostic model does not need a patient's or physician's name at all; it needs the part of the report that describes the sample and what the pathologist saw.

So what if I train a model on raw, un-anonymized reports on my own servers and share only the trained model? It is just a set of matrices, a bunch of numbers. Studies say otherwise: large models can leak their training data, sometimes verbatim. A model trained on customer-service logs can reveal customer names and phone numbers; a model trained on health records can reveal a patient's name, PHN and address exactly as written. Researchers have extracted gigabytes of training data from production models such as ChatGPT. Releasing such a model as open source lets anyone query it for that data.

Why does this happen? Size. A logistic regression in biostatistics may have four or five parameters, and people start questioning anything over ten. Today's largest models have over a trillion. With that many parameters, a model can memorize parts of what it saw during training, including sensitive information.

There are two main ways to share a model safely:

	Differential privacy (DP)	Anonymization
Idea	Change how the model is trained: add controlled noise so no single record can be detected	Change the data: remove what we want to protect before training. Nothing left, nothing to leak
Strength	The amount of privacy is tunable, and the guarantee is theoretical: it holds whatever the attacker's computing power	Practical today; for most tasks identifiers do not help the diagnosis anyway
Cost	The privacy–utility trade-off: more privacy means more noise and a less accurate model	Must find every identifier; no theoretical guarantee

The formal definition compares two neighboring datasets D and D′ that differ in one record, which means one person. A mechanism M is differentially private if, for any set of outputs S, P[M(D) ∈ S] ≤ e^ε · P[M(D′) ∈ S] + δ. The smaller ε and δ, the more alike the two outputs, so an attacker cannot tell whether any one person was in the data. DP is already in everyday use: some of the data that phones send back to Apple or Google is protected this way. The lecture focuses on anonymization because it is practical now.

What has to go: patient and physician names, the PHN, date of birth, and any item that alone or combined with others can identify a person, such as a case number or medical record number. The registry's in-house tool, BCCR Obscura, does it in three tiers:

Tier	Method	What it removes
Tier 1	Pre-processing (remove special characters, lowercase), then regular expressions only	Anything with a fixed pattern: PHN, physician IDs, phone numbers, postal codes
Tier 2	Microsoft Presidio, an open-source framework for finding and removing sensitive information, running GLiNER named entity recognition (NER) models	Most patient and physician names
Tier 3	spaCy, another NER library with deep-learning models, as a fail-safe	Names tier 2 missed or removed only partly, such as long names or names with two or three middle names

Two details make it work for pathology. Obscura keeps a dictionary of eponymous diseases, conditions named after people, such as Paget's disease and Kaposi's sarcoma, so that removing names does not remove diagnoses. It also leaves the report's structure unchanged, because downstream pipelines rely on it. It works on any text file, including Health Level Seven (HL7) messages, the format the registry mostly receives.

The results: close to 99% of patient identifiers and about 95% of physician identifiers removed, measured by a person checking a few hundred anonymized reports by hand for anything left behind. On one desktop GPU such as an RTX 4090, it anonymizes 10,000 to 15,000 reports an hour.

✎ reading noteA reading note: "99% accuracy" is for patient identifiers; physician identifiers are about 95%. The shorter data delay comes from all the NLP pipelines together, not from anonymization alone, and the lecture gave the earlier delay as 18 months on average (18 to 24 in its summary). The "StarPy" in the picture is spaCy, the tier 3 model.

Together, these pipelines are improving data quality and shortening data capture at the registry: the delay of 18 to 24 months has come down to about 14, with real-time data as the goal for the next year or year and a half.

This case made the use of NLP to improve the efficiency of a health system feel much more real to me. It also kept one rule in front of me the whole time: patient privacy comes first, and efficiency has to be gained while that privacy is protected.

But I think NLP can do more than screen for disease faster. It can also help with data analysis, with patient follow-up, and with health education.

This note is based on my study notes from the University of British Columbia (UBC) micro-certificate program "Natural Language Processing to Improve Patient Care," in the course Extraction and Analysis of Clinical Documents (Module 1, lesson 1.2, "Applied NLP at the BC Cancer Registry," by Lovedeep Gondara). Technical details were checked against:

• Lovedeep Gondara et al. (2024), Classifying tumor reportability status from unstructured electronic pathology reports using language models in a population-based cancer registry setting, JCO Clinical Cancer Informatics (the two-model ensemble with the either-model rule).
• Lovedeep Gondara et al. (2025), ELM: a hybrid ensemble of language models for automated tumor group classification in population-based cancer registries, arXiv (six small models, an LLM when fewer than five agree).
• Lovedeep Gondara et al. (2025), Bridging AI innovation and healthcare needs: lessons learned from incorporating modern NLP at the BC Cancer Registry, arXiv (hybrid approaches: regular expressions where they suffice, LLMs for ambiguous reports).
• CDC, Advancing electronic reporting (eMaRC Plus, the free rule-based tool for pathology reports).
• Milad Nasr et al. (2023), Scalable extraction of training data from (production) language models, arXiv (extracting training data from ChatGPT).
• Cynthia Dwork and Aaron Roth (2014), The algorithmic foundations of differential privacy, Foundations and Trends in Theoretical Computer Science (the ε, δ definition).

Try it yourself

• Microsoft Presidio: the open-source framework used in tier 2. Its online demo lets you paste a made-up report and see which names, phone numbers and dates it detects and how it masks them. Use only synthetic text, never a real report.
• regex101: try a tier-1-style pattern, such as a 10-digit health number or a Canadian postal code, on your own made-up text. Choose the flavor that matches your code (for example Python).