Chapter 2: Knowledge is Power — Do Your Research

With a solid plan and a clear understanding of the context established, the next crucial step in our 8-step process is to arm ourselves with the necessary knowledge. Before we even think about prompting an LLM to generate code, we need to gather foundational knowledge relevant to each of the sub-tasks we identified in the planning phase [bioinformatics LLM review]. This involves researching the methods, libraries, or tools that are commonly used to accomplish these tasks within our respective domains. For instance, in our BMI harmonization example, this would mean investigating appropriate R packages for data cleaning and manipulation, such as dplyr or data.table, as well as looking into established medical guidelines and definitions for BMI categories. This domain-specific knowledge will be invaluable in guiding the LLM later on and in evaluating the quality and appropriateness of its suggestions.

Furthermore, it is important to take this time to clarify uncertainties that might exist regarding the task at hand. Before we ask an LLM for code, we should strive to resolve any ambiguities or domain-specific questions we might have. In our BMI example, this could involve determining what range of BMI values would be considered implausible and should be filtered out, or deciding on the most appropriate method for selecting a single representative BMI measurement for each person if multiple measurements exist in the EHR data. Addressing these uncertainties upfront will lead to more focused and effective prompts when we eventually interact with the LLM.

flowchart TB
    accTitle: Research-to-method decision workflow
    accDescr: A branch-and-converge workflow showing how guidelines and validation tools inform a defensible updated analysis plan.
    A[Initial project plan] --> B[Research questions and uncertainties]
    B --> C[Authoritative guidelines]
    B --> D[Data-cleaning tools]
    C --> E[Thresholds and category definitions]
    C --> F[Boundary and rounding rules]
    D --> G[Outlier and validation strategy]
    E --> H[Updated analysis plan]
    F --> H
    G --> H
    H --> I[Prompt with defensible methods]

Considering Edge Cases in Category Definitions

It is also crucial to recognize that human-friendly definitions for categories (like “Obesity class 2: 35 kg/m2 to 39.9 kg/m2”) may not translate neatly into code. Official guidelines often list the upper limit as a single decimal like 39.9. But from a coding perspective, you might represent that boundary as < 40.0 or ≤ 39.9, each of which can alter how borderline values are classified.

For example, a BMI of 39.95 is both less than 40 and greater than 39.9. These comparisons produce different results unless the analysis plan specifies how to handle precision:

  • Flooring vs. Rounding: Flooring 39.95 to one decimal place gives 39.9; conventional rounding to the nearest tenth gives 40.0. These are different transformations and can change category assignment. A language’s rounding convention and floating-point representation also need testing.
  • Choosing < vs. <=: If your logic says bmi <= 39.9 for Obesity class 2, then 39.95 is excluded. But if you code it as bmi < 40, 39.95 is included.
  • Printed Ranges vs. Analysis Rules: A printed range does not by itself specify how to process higher-precision measurements. In this tutorial, the documented rule is to classify validated, unrounded BMI using half-open intervals: 35 <= bmi & bmi < 40 for obesity class 2. Round only displayed values, and test the category assignment separately.

Suggestions for Handling These Subtleties

  1. Be Explicit About Boundaries: Record every lower and upper comparison in the methods. The tutorial’s interval [35, 40) includes 35 and excludes 40, with no gap for 39.95.
  2. Separate Classification From Display: Preserve validated, unrounded BMI for this tutorial’s classification. Document display precision so a displayed value of 40.0 does not obscure why an underlying value of 39.95 was assigned to class 2.
  3. Validate the Rule: Have the methods reviewer approve the implementation rule for the intended analysis. Test exact cutoffs and values just above and below them; do not infer a clinical rounding policy from a printed table.

These decisions make borderline cases reproducible. The tutorial’s half-open intervals are an explicit implementation choice, distinct from the guideline’s printed ranges, so a reviewer can see exactly how a BMI of 39.95 is categorized.

Guideline text is not executable logic. Convert every clinical threshold into explicit comparison rules, rounding rules, and documented assumptions before asking an LLM to code it.

Incorporating Authoritative Guidelines

During the research phase, we may uncover important clinical practice guidelines that further inform how we categorize and interpret BMI data:

  1. European Association for the Study of Obesity (EASO) – The EASO offers position statements and guidelines discussing the use of BMI and related anthropometric measures in both clinical and epidemiological settings. This information can help frame how BMI (as well as height and weight) should be interpreted in population studies. It also provides insight into epidemiological nuances behind BMI thresholds, including considerations tailored to different demographic groups.

  2. NICE Guideline on Overweight and Obesity Management (Reference number: NG246, published 14 January 2025, last updated 8 January 2026) – This guideline provides a detailed classification of overweight and obesity in adults [NICE NG246], including:

    • Healthy weight: BMI 18.5 kg/m2 to 24.9 kg/m2
    • Overweight: BMI 25 kg/m2 to 29.9 kg/m2
    • Obesity class 1: BMI 30 kg/m2 to 34.9 kg/m2
    • Obesity class 2: BMI 35 kg/m2 to 39.9 kg/m2
    • Obesity class 3: BMI 40 kg/m2 or more

    It also identifies South Asian, Chinese, other Asian, Middle Eastern, Black African, and African–Caribbean backgrounds as associated with central adiposity and cardiometabolic risk at lower BMI thresholds:

    • Overweight: BMI 23 kg/m2 to 27.4 kg/m2
    • Obesity: BMI 27.5 kg/m2 or above

    NICE also recommends reducing the usual class 2 and class 3 thresholds by 2.5 kg/m2 for these populations. Applying these recommendations requires evidence that the recorded categories identify the relevant backgrounds; broad EHR race labels are not an automatic mapping.

Use this guidance to document applicability and limitations. The tutorial’s Advanced Project Plan uses general descriptive categories for synthetic adults aged 20 or older at measurement. Demographic fields support audits; they do not select BMI thresholds. This teaching workflow is not a clinical diagnostic or treatment rule.

Research first, prompt second. The LLM should implement the method you selected from authoritative sources, not invent the method for you.

Leveraging Tools for Data Cleaning and Validation

In addition to reviewing guidelines, we should seek out robust packages or software that can streamline data cleaning. One such tool is:

growthcleanr – An R package focused on cleaning anthropometric measurements (height, weight, and derived BMI) from EHR systems [growthcleanr manual]. It implements a series of algorithms to flag implausible values without deleting them outright. While its original emphasis was on pediatric growth curves, it has been expanded to handle adult measurements. Highlights include:

  • Biologically implausible value detection: Uses patient-specific longitudinal analysis, outlier flagging, and thresholds derived from known growth curve references.
  • Adult algorithm: Accommodates stable height and weight fluctuations in adults and flags erroneous or extreme measurements.
  • Easy integration: Offers additional utilities to calculate Z-scores and percentiles, potentially saving a great deal of time in data preprocessing.

Because growthcleanr specifically targets clinical anthropometric data, it aligns well with tasks such as identifying outlier BMI values in EHR-based cohorts. By using such a tool, you can systematically flag data issues and maintain consistent filtering methods in your workflow.

Refining the Plan Based on Research

Use the research to refine the plan before coding. For example, document whether guideline populations can be identified in the available schema before considering population-specific thresholds [NICE NG246]. Assess whether a cleaning tool’s required inputs and validation approach suit your data [growthcleanr manual]. The Advanced Project Plan makes a narrower teaching choice: explicit validation and general descriptive categories, with unsupported demographic mappings excluded.

Conclusion

By diligently gathering knowledge from reliable sources (clinical guidelines, relevant software packages, and domain experts) and clarifying any uncertainties early on, you will enable the LLM to generate code that reflects scientifically validated practices. As a result, your subsequent workflow steps—such as code generation, review, and refinement—will be grounded in robust methods and aligned with real-world clinical and research standards. Crucially, be sure to address edge cases carefully, documenting how borderline BMI values are handled so that both code and human interpretation remain consistent.

Good prompts inherit their quality from good methods. If a definition, package choice, or edge case is unresolved, resolve it in the plan before generating code.