Public health surveillance is the continuous and systematic collection, analysis and interpretation of health data for the planning, delivery and evaluation of public health action. HSCI 341 Lesson 2 describes the main kinds of surveillance system in Canada and the action loop that links data to decisions, and HSCI 130 Lesson 2 traces the history of surveillance. This section adds the places where machine learning and language processing already do part of the work. The most mature is the reading of large volumes of text: news reports, official statements and clinical notes written in many languages, which AI systems can read, translate and sort far faster than any team of analysts. The second is estimation from new data streams, such as internet searches, where the record is more mixed and the lessons about model drift are more instructive.

This lesson follows a fictional case used throughout the course. The Cedar Valley Health Authority is a fictional, mostly rural health authority in British Columbia with about 210,000 residents, about 46,000 of them aged 65 and older, and 24 primary care clinics. Its population health team runs the Cedar Valley Connector program, a community connector (social prescribing) program for socially isolated or lonely older adults, which is operating in 12 of the 24 clinics in its first wave. The team is piloting an enterprise AI assistant for one year under the Responsible AI Policy Framework for the B.C. Health Sector, and Jordan, a Health Sciences co-op student, has joined the team for a four-month placement. Jordan's tasks in this section are small, but they use the same methods as the national systems described below.

Indicator-Based and Event-Based Surveillance

Surveillance specialists distinguish two broad sources of information. Indicator-based surveillance relies on structured data reported through established channels: notifiable disease reports from laboratories and clinicians, counts of influenza-like illness from sentinel practices, and hospital admissions. The data arrive in fixed formats, and the main analytical task is to detect changes in counts and rates. Event-based surveillance relies on unstructured reports of events that might signal a threat: a news story about an unusual cluster of illness, a statement from a municipal health office, a post from a veterinary network about animal deaths, or a radio broadcast. These reports arrive in many languages and formats, most of them are irrelevant, and the few that matter are often buried in long texts.

The work of finding, verifying and assessing such signals is called epidemic intelligence. It is the part of surveillance in which AI was adopted first, because its inputs are text and its main constraint is the time analysts need to read. A typical system has the stages shown in Figure 9.1. Software collects articles from thousands of open sources, removes duplicates, translates text into the analysts' working languages and classifies each article by its probable relevance, the disease or hazard involved and the place it concerns. Human analysts then review the articles that pass the filters, verify the most important signals with official sources, and decide whether an event warrants a risk assessment or an alert. Their decisions also provide new labelled examples that can be used to retrain the filters.

The division of labour in Figure 9.1 is the most important idea in this section. In every system described below, software expands the volume of text that can be screened, and people remain responsible for judging what a signal means and what to do about it. The systems differ mainly in their sources, their users and the organizations that act on their output.

Three Systems for Reading the World's News

Three systems show the division of labour in Figure 9.1 at work: the Global Public Health Intelligence Network (GPHIN), operated by the Public Health Agency of Canada; BlueDot, a Toronto company; and the WHO's Epidemic Intelligence from Open Sources (EIOS) initiative. The tabs describe each system in turn. The two subsections that follow use the SARS outbreak and the emergence of COVID-19 to show what such systems detected and how their output was used.

What the SARS record shows about machines and people

GPHIN's history shows that automated detection is only one link in the chain. During the SARS outbreak of 2002 and 2003, when GPHIN was part of Health Canada (the Public Health Agency of Canada was created in 2004), GPHIN received a Chinese-language news report of a flu outbreak in mainland China. The report was published on 27 November 2002 and was sent to the WHO with an English header, but the full text was never translated, and Health Canada officials became aware of the new disease along with the rest of the world in February 2003 (National Advisory Committee on SARS and Public Health, 2003). The system collected the right article months before the outbreak reached Toronto. What was missing was translation and interpretation by people with the time and authority to act.

The COVID-19 pandemic raised a related question. The Auditor General of Canada reported in March 2021 that GPHIN had not issued an alert to provide early warning when COVID-19 emerged in Wuhan, although it did email its daily report, with links to related news articles, to domestic subscribers, including the provinces. An independent review ordered by the federal Minister of Health in 2020 made 36 recommendations in its final report (July 2021), covering GPHIN's role, its staffing and the modernization of its technology, including the addition of social media sources, and PHAC has since established a Centre for Integrated Risk Assessment. The lesson for practice is that an intelligence system's value depends on the organization around it: who reads the output, who has authority to issue an alert, and how the alert is connected to a risk assessment.

Late December 2019

BlueDot's best-known alert illustrates the speed that automated reading allows. On 31 December 2019, BlueDot sent its clients an alert about a cluster of unusual pneumonia cases in Wuhan, China. The same day, the WHO's EIOS platform picked up a report on ProMED (a program of the International Society for Infectious Diseases) about the same cluster of "pneumonia of unknown cause", and the WHO Country Office in China picked up a statement from the Wuhan Municipal Health Commission (WHO, 2020). Within two weeks, Bogoch and colleagues (2020), a team that included Khan, had published an analysis of commercial air travel from Wuhan that identified the cities to which travellers from Wuhan were most likely to fly. Figure 9.2 places these events on one timeline.

Popular accounts at the time described BlueDot as having predicted the pandemic. The documented achievement is narrower and still useful: an automated system flagged a cluster within hours of the first public reports and helped estimate where travellers might carry the infection. Several independent systems detected the same signal on the same day, as one would expect when all of them read the same open sources, and the value of that speed depended on what the recipients did with it.

The three systems in this part apply automated reading to open sources such as news reports and official statements, and in each of them people remain responsible for judging what a signal means and what to do about it. The next part turns to the same kind of work inside the health system, where classifiers sort the free-text notes written at emergency department triage into syndromes.

Classifying Free Text in Syndromic Surveillance

Syndromic surveillance monitors non-specific signals of illness, such as emergency department visits for respiratory symptoms, so that a rise can be detected before laboratory results are available. HSCI 341 Lesson 2 places it among the four main types of surveillance system. The richest source for syndromic surveillance is the emergency department triage record, and the most informative field in that record is the chief complaint: a short free-text note, written by a triage nurse, giving the patient's reason for the visit. Chief complaints are written quickly and in shorthand. "SOB x2d, fever" (shortness of breath for two days, with fever) and "pt c/o cough and chills" (the patient complains of cough and chills) are typical.

To count visits by syndrome, a surveillance system must assign each chief complaint to a category such as respiratory illness, gastrointestinal illness or influenza-like illness. Early systems used keyword rules, which assign a record to a syndrome if it contains a listed word. Rules are transparent but brittle, because they miss misspellings and abbreviations they were not written for and cannot recognize negation. Natural language processing (NLP), the branch of AI that processes human language, offers an alternative. A learned classifier is trained on a large set of chief complaints that experts have already assigned to syndromes, and it learns how strongly each word, part of a word or phrase is associated with each syndrome. Table 9.1 shows, with illustrative records written for this lesson, where the two approaches differ.

Table 9.1. How a keyword rule and a learned classifier handle four illustrative chief complaints.

The records and classifications were prepared for this lesson to show typical behaviour.

Ontario's Acute Care Enhanced Surveillance (ACES) system is a Canadian example. Kingston, Frontenac and Lennox & Addington (KFL&A) Public Health developed ACES in response to the threat of pandemic disease that SARS exposed in 2003, and by 2021 the system received emergency department visit data from more than 95 percent of Ontario's acute care hospitals. Its NLP algorithms sort chief complaints and reasons for admission into predefined syndromes. They make probabilistic decisions in place of keyword searches by attaching learned weights to each word, part of a word or phrase, and they were built from a large set of triage records that acute care physicians and epidemiologists had classified by hand. Each syndrome was validated against diagnostic hospital records. During the COVID-19 pandemic, the team built the ACES Pandemic Tracker on the same system, using admissions data from 131 Ontario hospitals (Papadomanolakis-Pakis and colleagues, 2021).

The accordion that follows explains two features of such classifiers in practice: why free-text classification needs ongoing maintenance, and why syndromic classifiers favour sensitivity over specificity.

Syndromic classifiers are checked against records coded by experts and retrained when their agreement falls. The next part turns to estimation from a new data stream, internet searches, where the record is more mixed and the lessons about model drift are more instructive.

Google Flu Trends and Model Drift

The most widely studied attempt to estimate disease activity from internet data is Google Flu Trends. Ginsberg and colleagues (2009) reported in Nature that the relative frequency of certain Google search queries closely tracked the percentage of physician visits for influenza-like illness in the United States. Their model selected 45 queries from a very large pool of candidates and estimated weekly influenza activity in each region of the United States with a reporting lag of about one day, faster than the traditional surveillance reports it was trained to predict. Google published the estimates for many countries, including Canada.

The estimates did not stay accurate. Lazer and colleagues (2014) documented that Google Flu Trends completely missed the non-seasonal influenza A(H1N1) pandemic of 2009, and that after its model was updated it overestimated influenza activity in 100 of 108 weeks starting in August 2011. In February 2013 it was predicting more than double the proportion of doctor visits for influenza-like illness that the United States Centers for Disease Control and Prevention (CDC) reported. A Canadian analysis found similar problems in real time. Google's estimates for Canada became available only on 8 October 2009, at the start of the pandemic's second wave; the original estimates overestimated the second-wave peak by about 160 percent and peaked a week late, and more accurate revised estimates became available only after the pandemic had ended (Martin, 2017). Google stopped publishing new estimates in August 2015.

Lazer and colleagues identified two main causes. The first, which they called "big data hubris", was the assumption that a very large data source can replace traditional data in place of supplementing them. Searching millions of candidate queries for the best fit to a little over a thousand data points invites matches that reflect coincidence, such as search terms that rise every winter for reasons unrelated to influenza. The second cause was algorithm dynamics: Google's engineers continually changed the search service to improve it for users, for example by recommending related searches, and those changes altered what people searched for. Search behaviour can also change for reasons of its own, for example when news coverage prompts healthy people to search for influenza symptoms. The model had been calibrated on the relationship between searches and illness in one period, and that relationship changed underneath it.

The general name for this problem is dataset shift: the data a model meets in use differ from the data it was developed on, so that its accuracy falls even though nothing in the model has changed (Finlayson and colleagues, 2021). Shift can affect the inputs (people search more often), the relationship between inputs and outcome (a given search no longer means what it used to mean), or the outcome itself (a new virus behaves differently from seasonal influenza). The term model drift describes the gradual loss of accuracy that results. Lazer and colleagues recommended combining search-based estimates with other near-real-time health data, which is the basis of the main safeguard against drift: continuous comparison with an independent source of truth.

Interactive 9.1 reproduces this problem with synthetic data and shows how weekly recalibration against surveillance reports limits the error.

Google Flu Trends shows that a model calibrated in one period can lose accuracy when the relationship it learned changes, and that continuous comparison with an independent source is the main safeguard. The next part applies the same kind of check to a small task at Cedar Valley.

Case: Jordan's Monthly News Scan

Jordan's tasks in this section are small, and they use the same methods as the national systems: software filters a stream of items, and a person checks the result. Box 9.1 describes a monthly news scan in which the team's enterprise assistant classifies each item as relevant or not relevant, and Box 9.2 asks the reader to estimate the filter's precision and recall from the numbers in the case and to decide whether the scan can rely on the filter alone.

The case reproduces on a small scale the pattern of the national systems: the filter saves reading time, and its value depends on a person checking both the items it flags and a sample of the items it discards. The final part of this section draws these observations together.

What AI Does Well and Poorly in Surveillance

The examples in this section show a consistent pattern: AI performs well when the task is to read, translate and sort large volumes of text quickly, and when its output is reviewed by analysts who can verify signals against other sources. It performs poorly when a model trained on one period is used without checks in another, when its filters discard relevant material that no one samples, and when an organization treats an automated signal as a substitute for judgement. The flip cards summarize these points.

Section 2 turns from systems that read text to systems that predict outcomes for individual people. The same concerns about training data, drift and human review apply there with greater force, because a prediction about a person can determine whether that person receives care.

Before that, the reflection and knowledge check that follow review the surveillance systems and safeguards described in this section.

Lesson 1 introduced supervised learning, in which a model learns to predict a labelled outcome from examples, and it drew the distinction between prediction and causal explanation that Hernán, Hsu and Healy (2019) set out for health research. This section turns to prediction models that are already used to make decisions about people. Such models are attractive to health systems for the same reason that screening tests are: they promise to direct limited resources, such as a care manager's time or a nurse's attention, to the people most likely to benefit. They also carry the same risks as a screening test, together with some that are particular to machine learning. The section works through two well-documented cases in which models fell short and one Canadian case in which a hospital built, tested and monitored its own model, and it ends with the questions that a public health team should be able to answer before any model informs a decision.

Prediction, Decision Support and Automated Decisions

Three terms recur in this field. A risk prediction model estimates the probability that a person will experience an outcome, such as hospital admission in the next year or clinical deterioration in the next twelve hours, from information available now. Decision support is the use of such an estimate, or of other information, to inform a decision that a person then makes: an alert in a hospital record that prompts a nurse to reassess a patient, or a list that tells a care manager which patients to call first. An automated decision system goes further. The Responsible AI Policy Framework for the B.C. Health Sector defines it as a system that makes or supports decisions influencing access to services, care, employment or other consequential outcomes, and Section 4 shows that such systems carry the heaviest governance requirements.

Public health uses of prediction include identifying people for proactive outreach (for example, older adults at high risk of hospital admission), targeting care management programs, ranking neighbourhoods or facilities for inspection or intervention, and forecasting demand for services. In each use, a model's output is only one step in a chain. The model produces a score; someone chooses a threshold above which a person is flagged; a program decides what happens to flagged people; and the people who are not flagged receive nothing extra. Errors and biases at any step affect who receives care.

Judging any step in this chain begins with the model itself, and the next part describes how a prediction model is built and how its performance is measured.

How a Prediction Model Is Built and Judged

Every prediction model has four components that deserve scrutiny. The outcome label is the quantity the model is trained to predict, which is usually something recorded in data (a diagnosis code, an admission, a cost) that stands in for the thing the program cares about. The predictors are the information the model uses. The development population is the group of people whose records were used to train the model, and it determines whom the model has learned about. The threshold and action turn a score into a decision. Once a model is built, its performance is described with the measures in the flip cards and the formulas in Box 9.3.

These measures describe how a model performs in the data used to evaluate it. The two cases that follow show how a model can still fall short in practice, first through the outcome it is trained to predict and then when it is used in a new hospital.

Case 1: When the Label Is a Proxy

Obermeyer and colleagues (2019) examined a commercial algorithm of a kind that health systems in the United States use to identify patients with complex needs for high-risk care management programs, which provide extra nursing and coordination. The algorithm produced a risk score, and patients above a threshold were flagged for the program. The researchers had access to the algorithm's scores and to detailed health records for the patients of one large academic health system, which allowed them to compare the scores with direct measures of illness, such as the number of active chronic conditions.

At the same risk score, Black patients were considerably sicker than White patients. The cause lay in the outcome label. The algorithm predicted future health care costs, which its developers treated as a proxy for health need. Because of unequal access to care, less money was spent on Black patients than on White patients with the same level of need, so a model that predicted cost accurately also predicted, accurately, that Black patients would cost less. It therefore ranked them as lower risk than equally sick White patients. The researchers estimated that remedying this disparity would increase the percentage of Black patients receiving additional help from 17.7 to 46.5 percent. They showed that training on a label that combined cost with direct measures of health reduced the bias substantially, and the manufacturer confirmed the bias in its own national data. Their general conclusion was that convenient proxies for the outcome of real interest can introduce bias in many settings, and that the choice of label is one of the most consequential decisions in building a model.

Figure 9.3 traces how the proxy label carries unequal access to care into the risk score.

The case shows that a model can be accurate on its own terms and biased in its effect. Bias of this kind does not require race, or any other group characteristic, to be among the predictors, because it enters through the outcome the model is trained to predict. HSCI 230 Lesson 9 shows how measurement error can track structural inequality in epidemiological data, and the same mechanism operates here. Interactive 9.2 reproduces the mechanism with synthetic data.

Case 1 shows that a model can predict its label accurately and still rank equally sick patients differently, because the label reflects unequal access to care. Case 2 turns to a model whose reported performance did not hold when it was evaluated in a new hospital.

Case 2: A Proprietary Model Meets a New Hospital

Sepsis, the life-threatening organ dysfunction caused by a dysregulated response to infection, is a leading target for hospital prediction models because early treatment improves outcomes. The Epic Sepsis Model is a proprietary model that the electronic health record vendor Epic Systems offered to its hospital customers, and it was in wide use in the United States by 2021. Its developer had reported an AUC between 0.76 and 0.83. Wong and colleagues (2021) carried out an independent external validation at Michigan Medicine, the academic health system of the University of Michigan, using 38,455 hospitalizations of 27,697 patients. Sepsis occurred in 2,552 hospitalizations, about 7 percent.

Table 9.2 sets out the main results of the validation and what each means for the hospitals that used the model.

Table 9.2. Main results of the external validation of a proprietary sepsis model by Wong and colleagues (2021).

Several features of the case recur in other settings. The developer's figures came from its own evaluation, and the hospitals that adopted the model had limited means to check them, because the model's details were proprietary. The model's performance in a new hospital depended on that hospital's patients, documentation practices and coding, none of which matched the development data exactly. A related danger is dataset shift after deployment: Finlayson and colleagues (2021) describe how changes in patient populations, clinical practice and data systems can degrade a model that once performed well, and they argue that clinicians who use such models need to recognize the signs. The general lesson is that a model's reported performance describes its development setting, and external validation, the evaluation of a model in data from a different setting or period, is required before it is relied on elsewhere.

The next part describes a Canadian hospital that built, tested and monitored its own model.

A Canadian Example: Building, Testing and Monitoring Locally

The contrast with a locally developed model is instructive. St. Michael's Hospital in Toronto built CHARTwatch, a machine learning early warning system that uses real-time data from the electronic medical record to estimate each patient's risk of deterioration (defined as death or transfer to intensive care, step-up care or the palliative care unit) on the general internal medicine unit. The team evaluated it in a nonrandomized controlled study that compared 13,649 admissions to general internal medicine with 8,470 admissions to subspecialty units, before and after the system was introduced (Verma and colleagues, 2024). Non-palliative deaths on the general internal medicine unit fell from 2.1 percent to 1.6 percent after implementation (adjusted relative risk 0.74, 95 percent confidence interval 0.55 to 1.00). A comparison with the control units, which adjusts for changes over time that affected the whole hospital, did not reach statistical significance, and the authors cautioned that the findings should be interpreted carefully because of possible unmeasured confounding.

CHARTwatch is useful as a teaching example because of its process more than its result. It was developed on the hospital's own data, evaluated prospectively with a control group, and reported with its uncertainty. Those steps correspond closely to the lifecycle and accountability requirements of the B.C. framework, which Section 4 sets out.

CHARTwatch can be judged in this way because its evaluation was reported with its uncertainty. The next part describes the reporting guideline that sets out what studies of prediction models should report.

Reporting Standards: TRIPOD+AI

Readers can judge a prediction model only if its study reports what was done. The TRIPOD+AI statement (Collins and colleagues, 2024), published in the BMJ, is the current reporting guideline for studies that develop or evaluate clinical prediction models using either regression or machine learning. It replaces the original TRIPOD statement of 2015 and consists of a 27-item checklist for the full report, with a separate checklist for abstracts. Its items ask authors to describe, among other things, the source of the data and the participants, how the outcome and predictors were defined and measured, the sample size, the handling of missing data, how the model was built and evaluated, and its performance. A reporting guideline is a checklist of what to report and leaves the grading of a study's quality to other tools. Even so, a study that cannot answer its items gives readers little basis for trust. HSCI 230 Lessons 8 and 9 develop the selection and measurement biases that the items help readers detect.

The next part turns from reading published studies to the questions a public health team should ask of any model before it informs decisions, including models procured from vendors or embedded in software the organization already uses.

Questions to Ask Before a Model Informs Decisions

The cases in this section yield a set of questions that a public health team can put to any model, whether it is built in-house, procured from a vendor or embedded in software that the organization already uses. The accordion sets them out, with the case that motivates each.

Box 9.4 applies the six questions to a fictional vendor's social isolation risk score offered to the Cedar Valley Health Authority.

The vendor's score repeats the problems documented in this section: a proxy label, no validation in a population like Cedar Valley's, and a default threshold that flags nearly eight times as many people as the program can serve. The final part of this section summarizes what AI does well and poorly in prediction.

What AI Does Well and Poorly in Prediction

Machine learning models can combine many predictors and find patterns in large records more effectively than simple scoring rules, and locally built models such as CHARTwatch show how they can be developed and evaluated responsibly. Prediction models perform poorly when their outcome label is a biased proxy, when they are moved to a population unlike the one they were trained on, when they are tuned to a threshold that produces more alerts than staff can use, and when no one monitors them after deployment. These weaknesses explain the governance requirements that appear in every framework discussed in Section 4: local validation, monitoring and a named human owner before a model informs decisions.

Section 3 turns from models that produce a score to models that produce text. Large language models are evaluated in quite different ways, and the gap between their performance on tests and their effect in practice is the main theme of the evidence.

Before that, the reflection and knowledge check that follow review the cases and appraisal questions in this section.

The models in Section 2 each predict one outcome. Large language models are different: a single model can answer questions, summarize records, draft messages and explain test results, and it does so in fluent text that is hard to score with a single number. Lesson 2 explained how these models generate text one token at a time and why fluent text can still be wrong. This section asks what the evidence shows about their performance on health tasks, how that evidence should be read, and what it implies for the chatbots and communication tools that public health agencies are beginning to use.

Evidence about language models in health comes at four levels, shown in Figure 9.4. At the first level, a model answers examination-style questions with known correct answers. At the second, experts rate the quality of the model's free-text answers. At the third, a controlled study measures whether people do their work better when they use the model. At the fourth, an evaluation measures the effects of a deployed system on the people it serves. Studies become harder and rarer at each level, and each level answers a question that the level below it cannot.

The next three parts describe studies at the first three levels.

Performance on Medical Questions

Singhal and colleagues (2023), a team at Google, published one of the first systematic evaluations of a language model on medical questions in Nature. They assembled a benchmark called MultiMedQA, which combined six existing question-answering datasets drawn from professional medical examinations, medical research and consumer queries with a new dataset, HealthSearchQA, made up of medical questions that people had searched for online. They tested Flan-PaLM, a version of Google's PaLM language model that had been instruction-tuned to follow requests. Flan-PaLM answered 67.6 percent of the MedQA questions (multiple-choice questions in the style of the United States Medical Licensing Examination) correctly, which exceeded the previous best result by more than 17 percentage points.

The study's second level of evaluation was more revealing. A panel of clinicians rated the long-form answers that the model gave to consumer health questions, and judged only 61.9 percent of Flan-PaLM's answers to be aligned with scientific consensus. The authors then used a technique they called instruction prompt tuning, which adapts a model to a new domain using a small number of examples written by clinicians, to create Med-PaLM. The clinicians judged more than 92 percent of Med-PaLM's long-form answers to be aligned with scientific consensus, close to the figure for answers written by clinicians, and they rated far fewer of its answers as potentially harmful than Flan-PaLM's. Two lessons follow. A high examination score did not guarantee good free-text answers, and a modest amount of expert input changed the quality of those answers substantially. Both Flan-PaLM and Med-PaLM were research models evaluated on test questions, and the study did not measure their effect on any patient.

The next part turns to a study at the second level that compared a chatbot's answers with physicians' answers to questions posted by members of the public.

Comparing Chatbot and Physician Responses

Ayers and colleagues (2023) took the evaluation closer to everyday communication. They collected 195 questions that members of the public had posted to the AskDocs forum on Reddit in October 2022, each of which a verified physician had answered on the forum. They gave the same questions to ChatGPT, and licensed health care professionals compared the two responses to each question, making 585 evaluations in all. The evaluators preferred the chatbot's response in 78.6 percent of evaluations. They rated 78.5 percent of the chatbot's responses as good or very good in quality, against 22.1 percent of the physicians' responses, and 45.1 percent of the chatbot's responses as empathetic or very empathetic, against 4.6 percent of the physicians'.

The study attracted wide attention, and its design limits what it can show. The physicians were volunteers answering strangers on a public forum, and their responses were brief (about 52 words against the chatbot's 211), so the comparison does not represent a physician replying to their own patient. Longer answers may also have been rated as more empathetic partly because they were longer. The evaluators judged quality without checking each answer against the patient's actual situation, which the forum did not provide. The study supports a specific conclusion: language models can draft clear and warm responses to common health questions, which makes them promising assistants for drafting replies that a clinician then reviews.

Whether such assistance improves the work of the people who use it is a question for the third level of evidence, which the next part takes up.

When Physicians Use the Model

The third level of evidence asks whether people do better work with a model. Goh and colleagues (2024) ran a randomized trial with 50 physicians (26 attending physicians and 24 residents) in family medicine, internal medicine and emergency medicine. Each physician worked through up to six clinical case vignettes in 60 minutes and was randomly assigned to use either conventional diagnostic resources alone or conventional resources together with access to a general-purpose language model. Their written diagnostic reasoning was scored with a standardized rubric. The median score was 76 percent in the group with the model and 74 percent in the group without it, an adjusted difference of 2 percentage points (95 percent confidence interval −4 to 8; P = 0.60), so access to the model did not significantly improve diagnostic reasoning. The time spent per case also did not differ significantly. In a secondary analysis, the model working alone scored 16 percentage points higher than the group using conventional resources (95 percent confidence interval 2 to 30; P = 0.03).

The result looks paradoxical: the model alone outperformed physicians, yet physicians with the model did not improve. Several explanations are consistent with it. Physicians may have used the model for narrow look-ups in place of asking it to reason through the case, they may have discounted suggestions that differed from their own impressions, and they may have had little experience in prompting it effectively. The authors concluded that the technology and the workforce both need development before collaboration between physicians and AI produces its potential benefit. The same pattern appears in the jagged frontier described in Lesson 3: the value of an AI tool depends on how the person using it divides the work and checks the output, which is why the B.C. framework makes organizations responsible for the AI literacy of their staff.

Table 9.3 places the three studies side by side, with the level of evidence, the main finding and what each study cannot show.

Table 9.3. Three studies of language models in health, by level of evidence.

None of the three studies measured the effects of a deployed system on the people it serves, which is the fourth level of evidence. The next part turns to public-facing chatbots, the deployed systems in which such effects arise.

Public-Facing Health Chatbots

A health chatbot is a program that converses with users about health in natural language. Public health agencies have used chatbots for years, for example to answer frequent questions during the COVID-19 pandemic, and generative AI has changed what they can do. The design choice that matters most is where the chatbot's answers come from, as the tabs explain.

The WHO's S.A.R.A.H. (Smart AI Resource Assistant for Health) illustrates both the appeal and the risks of a generative design. The WHO unveiled it on 2 April 2024, ahead of World Health Day, as a prototype "digital health promoter" powered by generative AI. It could converse 24 hours a day in eight languages about healthy habits and mental health, risk factors for cancer, heart disease, lung disease and diabetes, and help with quitting tobacco, being active, eating a healthy diet and managing stress. Earlier versions, which followed pre-set scripts, had been used during the COVID-19 pandemic. In its announcement the WHO called for continued research and named the ethical concerns that AI raises, including equitable access, privacy, safety and accuracy, data protection and bias. Within weeks, journalists reported that the chatbot gave outdated answers, for example stating that lecanemab, an Alzheimer's disease drug approved in the United States in 2023, was still in clinical trials. The chatbot's landing page carried a disclaimer that its answers might not always be accurate because they are based on patterns and probabilities in the available data.

The flip cards set out four requirements for a public-facing chatbot that the S.A.R.A.H. example raises: currency, disclosure, escalation and evaluation.

Public-facing chatbots answer the questions that people bring to them. The next part turns to the wider flow of health information, in which language models can both help agencies respond to misinformation and produce it.

AI and Health Misinformation

Language models affect health misinformation in two directions. On the side of public health, the open-source intelligence systems described in Section 1 also track rumours and misleading claims, and classification models can sort large volumes of public posts and news items by topic and sentiment so that communicators can see which concerns are spreading. Language models can then help draft responses, such as frequently asked questions, plain-language explainers and versions for different audiences, which Lesson 6 showed must be reviewed by subject experts and members of the intended audience before release. HSCI 312 Lesson 8 covers the design and evaluation of communication campaigns into which such messages fit.

On the other side, the same models can produce misinformation quickly and in volume. Menz and colleagues (2024) tested whether publicly available language-model assistants would write blog posts promoting false health claims when asked to, and repeated the test twelve weeks later. One assistant consistently refused, including when the researchers tried to bypass its safeguards. Several others repeatedly produced disinformation, refusing only about 5 percent of requests across the two rounds, and one assistant that initially refused no longer did so at the twelve-week reassessment. Each developer offered a way to report problems, and none responded to the researchers' reports. The authors concluded that effective safeguards are feasible but were inconsistently implemented. The assistants tested were the versions available in 2023 and 2024, and current safeguards differ; the durable lesson is that safeguards vary between products, change without notice, and need independent auditing.

The next part describes two reporting guidelines that help readers judge studies of language models in health, such as those described in this section.

Reporting Guidelines for Language Model Studies

Studies of language models in health are published quickly and vary widely in quality, and two reporting guidelines published in 2025 help readers judge them. TRIPOD-LLM (Gallifant and colleagues, 2025), published in Nature Medicine, extends the TRIPOD family described in Section 2 to studies that develop, tune or evaluate large language models in health. It has 19 main items and 50 subitems, uses a modular format in which some items apply only to particular tasks or designs, and is maintained as a living guideline that will be updated as the field changes. The Chatbot Assessment Reporting Tool, CHART (CHART Collaborative, 2025), covers studies that evaluate chatbots summarizing clinical evidence or giving health advice. It has 12 items and 39 subitems and was developed through an international Delphi process with 531 participants followed by consensus meetings.

Reading a chatbot study with these guidelines in mind leads to practical questions. Which model and version were tested, and on what date? Were the exact prompts reported, and were questions drawn from real users or written by the researchers? Who judged the answers, against what standard, and did they know which answers came from the model? Was the test repeated to see whether answers varied? A study that leaves these questions unanswered may still be informative, but its results cannot be compared with others or reproduced.

A single chatbot answer can also be judged against a known standard. Box 9.5 gives a representative answer to a Cedar Valley resident's question about the Connector program, together with the program's actual rules, and asks the reader to judge the answer against them.

The final part of this section draws together what the evidence and these examples show about language models in health communication.

What AI Does Well and Poorly in Health Communication

Language models write clear, warm and adaptable answers to common health questions, perform well on examination-style questions, and can draft replies, explainers and versions of a message for many audiences far faster than staff can. They perform poorly at staying current, at distinguishing a program's specific rules from general patterns, and at resisting misuse when their safeguards are weak. The evidence also shows that a model's performance in testing does not translate automatically into better work by the people using it. Public-facing services therefore need grounding in approved sources, disclosure, escalation rules, testing and named oversight.

Section 4 turns from clinical and public-facing uses to the routine work of public health staff, where most current use of AI takes place, and sets out the federal and provincial rules that govern it.

Before that, the reflection and knowledge check that follow review the evidence on language models and its implications for public-facing tools.

Most public health staff who use AI in 2026 meet it through a general-purpose assistant, such as ChatGPT, Claude, Gemini or Microsoft Copilot, or through an enterprise version of one that their organization has procured, and they use it for the ordinary work of reading, writing, analyzing and coordinating. This section describes that work and the federal and provincial rules that govern it, and it ends with an assessment of a proposed chatbot against the B.C. framework.

A large published study of such use in government comes from the United Kingdom, where 20,000 civil servants in 12 organizations used an AI assistant built into their office software (Microsoft 365 Copilot) from 30 September to 31 December 2024. Participants reported saving an average of 26 minutes a day, with the largest savings for drafting documents, and 82 percent said they would not want to return to their working conditions before the assistant. The report also found limitations with complex or data-heavy work, and it stated that human oversight was required at all times. The savings were self-reported, and the experiment could not determine how the time saved was used. The picture is nonetheless realistic: modest daily savings on many routine tasks, concentrated in drafting.

Routine Tasks in Which AI Saves Time

The savings in the United Kingdom study came from many routine tasks and were concentrated in drafting. Table 9.4 lists the routine tasks in which public health staff most often use AI, with the check that each requires.

Table 9.4. Routine public health tasks in which AI saves time, with the check that each requires.

A brief introduction to coding open-ended responses

Coding open-ended responses is one of the most time-consuming tasks in program evaluation, and HSCI 841 Lesson 12 treats it at graduate depth; the workflow here is the introductory version. The Cedar Valley team ran an anonymous survey of staff in the 12 first-wave clinics about the Connector referral process and received 180 free-text responses. Jordan removed clinic names and other identifying details, and the regional privacy officer confirmed that the edited responses could be used with the team's assistant.

Jordan drafted a codebook with five codes, each with a definition and an example (for instance, "unclear eligibility": the respondent is unsure who qualifies for referral or how screening scores are used), and coded a random sample of 40 responses by hand. The assistant was given the codebook and the same 40 responses and asked to assign codes and quote the phrase that justified each one. For the code "unclear eligibility", Jordan and the assistant both applied it to 14 responses and both omitted it from 20; Jordan alone applied it to 2 and the assistant alone to 4. The two coders therefore agreed on 34 of 40 responses (85 percent). Because some agreement would occur by chance, the team also computed Cohen's kappa, which HSCI 410 Lesson 7 explains.

Worked Example 9.1 works through the calculation for the code "unclear eligibility".

A kappa of 0.69 indicates substantial but imperfect agreement. Jordan read the six disagreements, found that the assistant had applied the code to two responses about confusing forms (a different code), and sharpened the definition. After a second agreement check, the assistant coded all 180 responses, and Jordan reviewed every response it marked as uncertain. "Unclear eligibility" was the most frequent code, applied to 71 of the 180 responses (39 percent). That finding prompted the proposal assessed in Worked Example 9.2 at the end of this section.

The coding workflow shows the checks that make one routine task dependable. The next two parts set out the federal and provincial rules that govern such use, beginning with the Government of Canada's guide.

The Government of Canada's Guide: FASTER

The Treasury Board of Canada Secretariat first published its Guide on the use of generative artificial intelligence for federal institutions in 2023 and has revised it since (the version consulted for this lesson was last modified in August 2026). It is guidance for federal institutions, and it is not binding on provincial health authorities; the B.C. framework describes it as a source of best practices relevant to managing AI risks. The guide organizes its advice under six principles whose initials spell FASTER. The flip cards summarize each.

Several of the guide's specific rules apply directly to public health work. Public servants must not enter personal information into publicly available online generative AI tools. Institutions should try low-risk uses before higher-risk ones, and the guide names deploying a chatbot for use by the public, and summarizing client information, as higher-risk uses. Drafting emails and briefing notes is acceptable depending on the context, provided the user checks the output, keeps sensitive data out of the prompt and tells their manager, and use that forms part of an activity of business value must be documented. Administrative decisions about people also fall under the federal Directive on Automated Decision-Making, which Lesson 10 describes.

The federal guide is not binding on provincial health authorities. The next part describes the framework that governs AI use in the B.C. health sector, which builds on the federal guide.

The Responsible AI Policy Framework for the B.C. Health Sector

British Columbia's Ministry of Health published the Responsible AI Policy Framework for the B.C. Health Sector in June 2026. It responds to Action 29 of the province's Health Human Resources Strategy (2022), which called for a strategy to guide the implementation of AI and other workforce-enabling technologies, and it builds on the federal guide, the 2021 joint report of the B.C. and Yukon Ombudspersons and Information and Privacy Commissioners (Getting Ahead of the Curve) and the B.C. Office of the Chief Information Officer's policy on the use of generative AI (2025) for the provincial public service. The tabs summarize its main parts.

Figure 9.5 shows the ten stages of the AI lifecycle described in the Lifecycle and risk tab.

The framework reaches beyond formal AI projects to the assistants staff use for drafting and to AI features added to existing software, which is why the Cedar Valley pilot keeps an AI use log and limits the assistant to public, internal non-confidential and aggregate information. It also allocates responsibility at several levels: the organization assesses risk and trains staff, the system owner monitors performance, and each user applies professional judgement to the output.

The next part applies these rules and checks to the duties of a public health analyst.

Mapping AI-Supported Tasks in a Public Health Analyst Position

A public health analyst in a B.C. health authority typically compiles and analyzes surveillance and program data, scans evidence, writes reports and briefing notes, and supports evaluation and communication. Table 9.5 maps these duties to AI-supported tasks and to the rule or check that governs each.

Table 9.5. AI-supported tasks in a typical public health analyst position, with the rule or check that governs each.

The final part of this section applies the B.C. framework to a proposal that arose from the staff survey described earlier.

Worked Demonstration

Worked Example 9.2 follows Jordan through an assessment of the Connector Referral Helper, a chatbot for clinic staff that the team lead proposed after the staff survey. It shows the assistant's draft assessment against the B.C. framework, the five checks Jordan applied to it and the revised assessment that resulted.

The tools described in this lesson will change, while the verification habits that make them dependable carry over from one tool to the next. A useful next step is to take a public surveillance report, such as one published by the BC Centre for Disease Control, ask an assistant to summarize it, and check every number in the summary against the report. Reading the B.C. framework itself, which runs to 18 pages, is another. Lesson 10 brings the course together with the team's rules for AI use, the wider governance of AI, and a plan for continued learning.

Box 9.6 brings the four sections of the lesson together. Table 9.6, within it, lists six kinds of public health task, how AI performs at each and the check that applies.

The reflection and knowledge check that follow review the routine uses of AI in public health work and the federal and provincial rules described in this section.

Bringing It All Together

This lesson has surveyed the places where AI already works in public health. In surveillance, systems such as the Global Public Health Intelligence Network, BlueDot and the WHO's EIOS read news and official reports in many languages, and natural language processing sorts emergency department records into syndromes, while analysts remain responsible for judging what a signal means. Google Flu Trends showed how a model built on data produced by people and platforms drifts when the platform and behaviour change, and why continuous comparison with surveillance data is the standard safeguard.

In prediction and decision support, the Obermeyer case showed that a model can be accurate on its own terms and biased in its effect when its label is a proxy, and the external validation of a proprietary sepsis model showed that developers' figures need independent checking. CHARTwatch illustrated local development, evaluation and monitoring, and TRIPOD+AI set out what a prediction study should report. For language models, the evidence moved from examination questions through expert ratings to a randomized trial in which access to a model did not improve physicians' reasoning, and public chatbots such as S.A.R.A.H. showed the value of grounding, disclosure and evaluation.

Most everyday use of AI in public health is routine drafting, summarizing, scanning and coding, and it is governed in British Columbia by the Responsible AI Policy Framework for the B.C. Health Sector and informed by the federal FASTER principles. The worked demonstration showed how an assistant can draft an assessment of a proposed service quickly, and how checks against the framework itself caught an omission, a misapplied requirement, a wrong date, a fabricated figure and an invented premise.

The final reflection asks you to plan the use of AI for one realistic task and to name the checks and rules that would govern it.

Final Knowledge Assessment

Key terms, systems, guidelines and people from this lesson on AI in public health practice.