A machine learning model cannot be better than the label it learns from. In health datasets, labels are often built from diagnosis codes, chart review, prescriptions, procedures, or future events. This page teaches students how to think clearly about what the outcome means, how noisy it is, and whether the label matches the real clinical decision they want to support.
The portal already covers missing data, leakage, external validation, and bias. The next high-value gap is what students repeatedly face in EHR projects: the outcome itself may be ambiguous, delayed, site-specific, or only partly observed. If the label is poorly defined, downstream metrics and explanations become hard to trust.
Students should first ask what the target means in plain language.
Many health labels are proxies built from codes, orders, or documentation rather than direct truth.
Advanced students should inspect whether features leak future information and whether the target shifts across sites or years.
Choose a common EHR label strategy. Watch how collection speed, label noise, leakage risk, and clinical alignment move together. The point is not that one label is always best. The point is that every label choice trades convenience for validity.
Billing codes can scale quickly, but they may reflect documentation and reimbursement processes as much as disease biology.
If discharge codes or finalized notes appear after the intended prediction time, the model may learn the answer key.
Treatment orders, ICU transfer, or consultation requests can reflect clinician behavior rather than disease itself.
The same code list or abstraction rule may behave differently across hospitals, years, or coding teams.
Borderline or ambiguous cases are often where label noise is highest, yet they matter most for real deployment.
Define the decision, the patient group, and the prediction time in plain language before opening the database.
Choose the exact moment when prediction starts so features and labels can be checked against the same clock.
Decide whether the outcome comes from codes, lab thresholds, chart review, registry linkage, or a hybrid phenotype.
Review a subset of records to estimate false positives, false negatives, and edge cases in the outcome definition.
Ask whether the same label logic would behave similarly across hospitals, calendar time, and coding workflows.
Report how the label was built, what its likely errors are, and where the phenotype is strongest or weakest.
Use these short cases to confirm the main label-design logic before moving on.
You predict sepsis at emergency department arrival, but your label uses discharge diagnosis codes finalized days later. Main concern?
A treatment order is used as the outcome, but treatment habits differ between hospitals. What should you suspect?
Which extra step most improves confidence in a new phenotype built from ICD codes and labs?
Read missing data and safe pipelines to prepare features only after the target and timing are defined.
Use train, validation, test splits and leakage to ensure the outcome logic does not look into the future.
Connect this page to bias in ML and external validation when phenotype rules vary across settings.
This page prepares students for later work on reporting standards, governance, and prospective validation.