Tampere University Biomedical Informatics (Engineering) Master's Thesis Guide: 30 ECTS, BBTM.TEK-S20 and Trepo

Quick answer: which Biomedical Informatics route is this?

This guide is for Tampere University’s Biomedical Informatics study option inside Biomedical Sciences and Engineering, which awards Master of Science (Technology). It is a 120 ECTS, two-year degree. The current degree page states that the master’s thesis is 30 ECTS, and the Technology thesis is graded 0-5. The current engineering advanced-studies object is BBTM.TEK-S20, at least 60 ECTS. Do not confuse it with BBTM.BMI-S14, at least 80 ECTS, which belongs to the parallel Biomedical Technology Master of Science route. Both Biomedical Informatics options are jointly taught in important areas, but their degree structures are not interchangeable.

1. The 60 ECTS versus 80 ECTS distinction matters

Tampere currently exposes two advanced-studies modules with the same English title. BBTM.TEK-S20 is in Engineering, Manufacturing and Construction and is at least 60 credits. BBTM.BMI-S14 is in Natural Sciences and is at least 80 credits. This guide uses BBTM.TEK-S20 because group 031 is the MSc (Technology) route. The 80-credit Natural Sciences module is a contamination control only. Joint teaching does not make two degree architectures identical. When checking Sisu, always start from your degree title and module code rather than the words “Biomedical Informatics” alone.

2. BSEM.BMI is not 120 extra credits

The broad current BSEM.BMI Biomedical Informatics object is labelled at least 120 credits. The degree itself is also 120 ECTS and separately states that the thesis carries 30 credits. Therefore BSEM.BMI must not be read as 120 ECTS of specialization courses plus another 30 ECTS thesis. It is a programme-level object inside the degree architecture. Your personal study plan determines how the current components are nested. For thesis planning, the safe fixed facts are the 30 ECTS Technology thesis and the engineering BBTM.TEK-S20 route.

3. BBT.MJS.111: current seminar with legacy wording

BBT.MJS.111 Master’s Seminar, Biomedical Sciences and Engineering is current in 2026-2027, 2 ECTS, and pass/fail. It teaches thesis-process understanding, scope control, writing practice and peer presentation. Its public completion option still uses the older field name Health Technology and Informatics rather than the current Biomedical Informatics engineering title. That is a transition-label issue, not a reason to import another faculty’s seminar. Treat BBT.MJS.111 as the current BSE seminar anchor, but verify its exact placement in your own Sisu plan before enrolment. Do not import CSEE’s ITC.CEE.800.

4. Start with the biomedical question, not the algorithm

A weak thesis starts with “I want to use deep learning.” A stronger thesis starts with a biomedical or health-system question and asks which computational method can answer it. Define the unit you are trying to predict, describe, classify, discover or support; identify the outcome or biological phenomenon; specify the population or data-generating process; and define the evidence required for the intended claim. BBTM.TEK-S20 explicitly trains students to design systems, algorithms, software, models, methods and processes while understanding the limitations of AI. The algorithm is therefore part of the method, not the scientific objective itself.

5. Build a data-provenance table before analysis

For every dataset, record where it came from, why it was collected, cohort or source system, collection dates where relevant, inclusion and exclusion rules, unit of observation, available outcomes, missingness, prior processing and permission constraints. Biomedical Informatics spans molecular, cellular, patient, population and healthcare-system data. A row in a table can represent a sequencing read, a cell, a visit, a patient, an admission or a hospital. Those units cannot be treated as equivalent merely because they are stored in one dataframe. A provenance table prevents later confusion about what a model actually learned from.

6. Define the experimental unit and grouping structure

Repeated measurements are a major source of false confidence. Thousands of cells can come from one donor; hundreds of image slices can come from one patient; dozens of visits can come from one person; many laboratory measurements can come from one biological sample. Decide which unit is independent for the claim and preserve the hierarchy during analysis. If the question is patient-level prediction, the patient usually needs to be the splitting unit. If the question is donor-level biology, cells within a donor are nested observations rather than independent donors. This decision belongs in Methods before model training.

7. Prevent participant and sample leakage

The same participant or closely linked records must not appear on both sides of a train/test split when the claim is performance on unseen people. Row-wise random splitting can leak repeated visits, images, cells or derived features. Leakage can also occur through preprocessing: normalisation, feature selection, imputation or dimensionality reduction fitted on the entire dataset may expose the test set to the training pipeline. Build splits first where possible, then learn data-dependent preprocessing inside the training folds. State explicitly what entity was grouped during splitting.

8. Separate tuning from final evaluation

A validation set or cross-validation loop helps choose features, model class and hyperparameters. A final test set estimates performance after those choices are fixed. Repeatedly checking the test set and changing the model turns that test set into another tuning set. For small biomedical datasets, nested cross-validation or a comparable separation can be more defensible than a single random split. The key principle is informational separation: the data used to choose the pipeline should not also be the untouched evidence used to claim final generalisation.

9. Baselines are part of the scientific argument

A complex model is only useful if it improves on a meaningful alternative. Include a simple statistical model, clinical score, conventional rule, majority/prevalence baseline or established bioinformatics method when appropriate. If a deep model performs no better than logistic regression after proper validation, that result is scientifically valuable. Explain the trade-off among accuracy, calibration, interpretability, computation and deployment requirements. BBTM.TEK-S20 asks students to understand the possibilities and limitations of advanced methods; a baseline is one of the clearest ways to demonstrate that understanding.

10. Choose metrics before looking for the best result

Metric choice should follow the task. Accuracy can be misleading with imbalance; F1 can hide probability calibration; AUC measures ranking rather than the quality of predicted probabilities; a small p-value does not quantify prediction usefulness. For regression, define the scale and error measure. For survival analysis, define time origin, event and censoring. For a clinical decision-support project, specify the operating threshold and the consequences of false positives and false negatives. Report uncertainty where appropriate, and distinguish statistical improvement from clinically meaningful benefit.

11. Missing data and imputation need a documented pipeline

Do not silently drop or fill missing values. State which variables are missing, how much, why missingness might occur, and whether it relates to the outcome or workflow. Imputation fitted on all data before splitting can leak information. Fit it inside the training process and apply the learned transformation to validation/test data. If complete-case analysis changes the population substantially, describe that selection effect. A sensitivity analysis using reasonable alternative missing-data assumptions can show whether the main conclusion depends on one convenient preprocessing decision.

12. Confounding can masquerade as biomedical signal

Models can learn age, sex, hospital, batch, scanner, laboratory protocol, calendar time, treatment pathway or coding convention instead of the biological mechanism you intended to study. Examine whether these variables differ between outcome groups. When possible, design the split so that site or time differences are tested rather than memorised. Report performance by relevant subgroup if the claim spans heterogeneous populations. High predictive performance does not establish that the top features are causal drivers of disease; predictive association and causal explanation are different scientific goals.

13. External, temporal and site validation answer different questions

Random internal cross-validation asks whether the pipeline generalises to held-out records from roughly the same data-generating environment. A site-separated test asks whether it transfers to another organisation or instrument context. A temporal test asks whether it works on later data after practice, coding or population changes. External validation asks still broader transportability questions. State exactly which evidence you have. Do not describe an internal split as “externally validated,” and do not generalise a single-site retrospective model to all healthcare systems without evidence.

14. BBT.021: sequence and omics data need versioned provenance

Current BBT.021 Bioinformatics covers DNA-seq, RNA-seq, scRNA-seq, epigenetics, proteomics, alignment, annotations, databases, genome browsers and enrichment analysis. In a thesis, record the reference genome/build, annotation/database versions and major tools or pipelines when they affect results. Sequencing and omics types have different measurement processes; avoid treating every matrix as generic tabular data. Document quality control, alignment/quantification or feature construction sufficiently for a knowledgeable reader to understand how raw or source data became the analysed matrix.

15. Multiple testing is not optional in high-throughput work

Current BBT.BI.202 Biological Data Analysis explicitly covers applied hypothesis testing and multiple testing. When thousands of genes, proteins, regions or features are tested, unadjusted p-values produce many expected false positives. State the multiplicity-control approach and what family of tests it applies to. Keep exploratory ranking separate from confirmatory inference. If enrichment follows a selected gene list, document how the list was created and what background universe and database version were used. Otherwise apparently precise biological conclusions can depend on hidden analytical choices.

16. Dimensionality reduction and clustering are exploratory evidence

Heatmaps, PCA-like embeddings and clustering can reveal structure, but a visually separated plot is not proof of a biological class. Scaling, feature selection, batch correction and distance choices can change the geometry. Report those choices. Cluster labels should be validated with independent biological information or robust sensitivity analysis before they are described as real cell types, disease subgroups or molecular mechanisms. If the analysis is exploratory, say so. An examiner is more likely to trust a bounded exploratory conclusion than a confident but unsupported discovery claim.

17. Single-cell studies: cells are nested within biological samples

Tampere’s Biomedical Informatics environment includes single-cell data through BBT.021 and BBT.INT.809 Cell Imaging and Signal Processing. Thousands of cells from one person or one culture do not create thousands of biological replicates. Preserve donor/sample identity through quality control, splitting and statistics. Report filtering, normalisation, dimensionality-reduction and clustering choices. If a classifier is evaluated at cell level, make sure cells from the same donor do not leak across training and test sets when the claim is donor- or patient-level generalisation.

18. Systems biology networks are models, not mechanisms by default

Current BBT.MJS.102 Systems Biology covers graph theory, gene co-expression networks, community detection, functional analysis and biomedical knowledge graphs. A network edge may represent correlation, database relation or another computational rule; it is not automatically a physical interaction. Define nodes, edges, thresholds and data sources. Community detection can generate useful hypotheses, but network structure alone does not prove a causal biological pathway. The Discussion should clearly separate computationally inferred relationships from experimentally established mechanisms.

19. Survival analysis needs time semantics

BBT.BI.202 includes survival analysis. Define the time origin, event of interest, censoring rule, follow-up horizon and whether competing outcomes matter. Check whether predictors are known at the prediction time; using future information creates leakage. If repeated updates are modelled, explain the landmark or time-varying design. A high concordance measure does not automatically mean predicted survival probabilities are calibrated. The thesis should state whether it is ranking risk, estimating absolute risk, explaining associations or supporting a decision.

20. Healthcare-process data are generated by workflows

Current BBT.038 Health Care Processes and Information Systems teaches healthcare processes, governance, records, standards and ICT architectures. Electronic health records are not neutral measurements of biology: they are produced by care workflows, documentation requirements, reimbursement, availability of tests and clinician decisions. Missing tests can mean “not clinically indicated,” not random absence. Diagnosis codes can change over time. A health-informatics thesis should therefore describe the workflow that generated the data and discuss how that workflow constrains interpretation.

21. Interoperability claims need exact standards and versions

Current BBT.MJS.144 covers health-informatics standards and interoperability, including HL7, CDA and IHE. Saying “the system is interoperable” is too broad. Identify the exchange, standard/profile/version, terminology and conformance condition being evaluated. Distinguish syntactic exchange from semantic consistency and from successful workflow integration. A prototype that parses a message format does not automatically interoperate with every healthcare system. Record the actual implementation tested and avoid copying confidential production configuration into the public thesis.

22. Security and privacy are engineering requirements

BBT.MJS.144 explicitly includes security, privacy and data protection. Treat them as design constraints from the start. Define data flows, access roles, storage/processing environment and threat-relevant assumptions at a level appropriate to the thesis. Do not claim a system is “secure” because one control worked or because data were pseudonymised. The thesis can demonstrate selected controls or a risk analysis, but enterprise security and formal compliance require broader evidence. Never expose credentials, patient identifiers or restricted architecture details in appendices or screenshots.

23. Decision support is not autonomous clinical decision-making

Current BBT.HTI.509 Decision Support in Healthcare provides a relevant academic environment for models intended to assist care. Be explicit about the user and decision: clinician, patient, planner, researcher or system administrator. A retrospective model can estimate historical performance but does not automatically establish prospective safety, workflow fit or patient benefit. Define how false positives and negatives matter, whether probabilities are calibrated and what information the user sees. Keep academic decision-support evaluation separate from claims of an authorised autonomous clinical system.

24. Health-software regulation: intended use changes the question

Current BBT.MJS.144 includes regulation relevant to health software. Whether software falls under particular medical-device obligations depends on intended use and context, so avoid generic compliance claims. A master’s thesis can describe applicable considerations, test technical requirements or evaluate interoperability/security. It should not imply formal conformity, certification, CE marking or market authorisation unless that status independently exists and is correctly documented. Separate intended use, technical verification, clinical evaluation, security/privacy evidence and formal regulatory status.

25. Human, clinical and genomic data require governance before analysis

Before accessing identifiable or pseudonymised participant data, patient records, genomic information or other sensitive datasets, establish the applicable ethics, permission and data-protection route. Tampere’s student data-protection guidance requires role and responsibility decisions before processing. A research group possessing data does not automatically authorise every student use. Document the approved data source and secure environment. Minimise variables, avoid unnecessary exports, and make sure notebooks, filenames, screenshots, model artefacts and AI prompts do not leak protected information.

26. Pseudonymised data are still personal data when re-linking is possible

Replacing names with study IDs is valuable but does not automatically make a dataset anonymous. If a key or other information can reconnect the data to people, it remains pseudonymised personal data. Genomic data can also be intrinsically sensitive and potentially identifying. Describe what identifiers were removed, who can access linkage information, and what data may appear in the public thesis. When reporting rare combinations or tiny subgroups, consider whether aggregate results could still reveal individuals.

27. AI use: distinguish research AI from writing assistance

The programme itself studies advanced computational methods including AI, while Tampere also has university-wide rules for AI in studies. Separate AI that is part of the research method from generative AI used to help with writing or coding. For research models, document data, architecture/version, training and evaluation. For generative assistance, follow acknowledgement requirements and verify outputs. Never paste protected clinical, genomic, company or unpublished data into an external AI service without an approved basis. Save the final code and reasoning needed for reproducibility rather than relying on a transient chat.

28. Reproducibility requires more than a Git repository

Record the data version or approved extract, code snapshot/commit, package environment, database/reference versions, random seeds where relevant, and the exact workflow that generates final tables and figures. Manual corrections or relabelling must be logged. Intermediate processed datasets should either be reproducibly regenerated or documented. If computation is nondeterministic, report the variability or stabilisation method. A repository is only useful when another knowledgeable researcher can map its files to the Methods and understand which version produced the submitted results.

29. Write the Methods and data dictionary early

As soon as access is approved and the pipeline is stable, write a data dictionary and Methods skeleton. Define each variable, unit, coding rule, source and allowed missing values. Record the split strategy, preprocessing and planned primary metric before repeatedly inspecting final results. This early writing exposes ambiguous labels, duplicated patients, leakage risks and undocumented transformations while they can still be fixed. Keep a result ledger linking each research question to dataset version, analysis script, figure/table and conclusion.

30. Supervision plan and data-access dependencies

Use Tampere’s Thesis Supervision Plan to state scope, milestones, responsibilities and meeting practices. Biomedical Informatics projects often depend on secure computing, data-use approvals, hospital extracts, external registries, specialised databases or shared compute. These can dominate the schedule. Agree a fallback question using already-approved data or a smaller methodological contribution if the preferred dataset is delayed. Do not design the whole thesis around a dataset you are not yet authorised to see.

31. Results: report the whole evaluation, not the best run

Present the declared primary result, uncertainty, baseline and relevant subgroup or sensitivity analyses. Report exclusions and missingness. If many pipelines were tried, describe the model-selection process instead of showing only the winner. Include failure modes: site shift, calibration drift, class imbalance, batch effects, unstable selected features or a baseline that performs equally well. In Discussion, separate what the data directly support from biological interpretation, clinical implications and future deployment ideas. A transparent null result can be a stronger thesis than a fragile headline metric.

32. Maturity, Turnitin, Trepo and final checklist

Complete the applicable maturity-test route, originality review and final Trepo submission under current Tampere instructions. The thesis is a public document, so confidential or identifying material must be kept outside the public manuscript where required. Before freezing the PDF, confirm: correct engineering route (BBTM.TEK-S20, not BBTM.BMI-S14); 30 ECTS thesis; seminar placement in your Sisu plan; no participant/sample leakage; documented data provenance and versions; justified metrics and baselines; multiple-testing control where applicable; protected data handled correctly; AI use documented; final code and figures traceable; PDF/A and graduation timing checked. A strong Biomedical Informatics thesis is an auditable evidence pipeline, not merely a high model score.

A final data leakage audit should be performed from the perspective of the unit that the conclusion refers to. BBT.MJS.111 remains a separate 2 ECTS pass/fail seminar from the 30 ECTS thesis, and the engineering route remains BBTM.TEK-S20, not the Natural Sciences module. For genomics/omics work, preserve sample-level provenance and version the reference genome, annotation and databases. For health-information-system work, state the exact interoperability standard/profile/version and distinguish syntactic, semantic and workflow interoperability. Recheck data protection before final export so that protected clinical/genomic data, linkage keys and restricted system details cannot enter the public thesis. Before release, explicitly recheck data leakage at participant/sample grouping, data leakage in preprocessing, and data leakage from outcome-derived features. Recheck genomics reference versions, genomics/omics sample provenance, and omics multiple-testing choices. Recheck data protection for source data, data protection for derived artefacts, and data protection for the public thesis. Then continue the audit from the perspective of the unit that the conclusion refers to. Start at every final metric and trace backwards: which rows contributed, which participants/samples those rows came from, what preprocessing parameters were learned, and whether any outcome-derived information could have crossed into training. Then rerun key results from a clean environment if feasible. In omics work, verify that reference builds, annotations and enrichment backgrounds match the submitted Methods. In health-informatics work, verify that standards, code systems and workflow assumptions correspond to the actual implementation studied. If a late correction changes the result, update the thesis rather than preserving a previously attractive number.