Refinement guide
Turning an idea into a concrete, feasible research question is often the hardest step. Listed projects from Topics & projects need this step too: your proposal has to turn the project into a testable question.
You have unusually open access to data, hardware, collaborators and clinicians, but only if you take a half-step toward it: read, ask, use class time and talk to guest speakers. Cramming a project into the last week of the semester does not work in CACoM.
Step 1: Define the core question
A CACoM project starts from a focused, testable research question with specific, measurable objectives. Avoid vague goals such as "analyze clinical data" or "build an ML model", and above all avoid non-ideas: projects that miss the purpose of the course entirely.
| Vague idea | Problem | Refined question |
|---|---|---|
| "Predict complications in pregnancy." | Too broad: which complications, which data, what prediction horizon? | "Can features extracted from CTG recordings predict fetal distress, as measured by arterial pH, within the last hour before delivery?" |
| "Use IMU data for gait analysis." | No clear target or metric | "How accurately can a ZUPT-based algorithm estimate step length in treadmill vs. overground walking?" |
| "Do NLP on clinical notes." | No clear goal or metric | "What is the accuracy of a fine-tuned transformer model for classifying discharge summaries by diagnosis category?" |
| "Build a heart rate simulator." | Broad and hardware-centric: what is the simulator for, and how will you evaluate it? | "Can a mechanical fetal heart rate simulator driven by real CTG recordings reproduce realistic Doppler signals that could be used to test fetal monitoring algorithms?" |
| Non-idea | Why it doesn't work |
|---|---|
| "Explore the use of ChatGPT in the context of cachexia in cancer patients." | Verifying or benchmarking LLM output on clinical tasks is close to impossible at present and beyond what CACoM can realistically cover. |
| "Develop a lightweight cognitive-assessment game using Unreal Engine 5." | Building a tool or GUI is not a research question. |
| "Create a website/app to display hospital statistics." | Pure software engineering, with no hypothesis or analysis. |
| "Use AI to predict anything from any dataset we can find online." | Unfocused and unverifiable, and ethically questionable without defined data and metrics. |
CACoM is not a software engineering, app development or video making course. It is about understanding and answering clinically meaningful questions with computational and statistical methods. You may use any tool you like, from Python, R, MATLAB or Julia to ChatGPT, Claude, Unity, BLE or DaVinci Resolve, but only as a means to that end.
If your proposal centers on building a tool instead of using it to gain insight into a medical or biological question, it is off topic and you will fail the course.
A few listed projects are exceptions and center on building a tool, such as the wireless PCB for the FullSoul insole. They only work in full alignment with us and need closer supervision.
Step 2: Clarify inputs and outputs
Whether you analyze data, build a model or set up an experiment, state what goes in and what comes out:
- What dataset, signal source or experimental setup will you use? If you collect your own data, for example with an IMU, a stethoscope or a simulator, describe how and under what conditions, and check that this is ethically and practically feasible.
- What will you measure, extract or compute? In an experiment, which physical parameters will you record or control?
- What will you predict, estimate, compare or reproduce? In an engineering project, which measurable signal or behavior do you expect?
If your data are not available yet, use synthetic, simulated or public substitutes for early prototyping and validation.
Engineering and experimental projects must include a computational or analytical evaluation, for example of whether a device produces realistic signals or whether a simulator can be used to test algorithms. The outcome must answer a scientific or clinical question.
Step 3: Frame the clinical or scientific relevance
Motivate and interpret your work in clinical or scientific terms, even when the project is mainly about methods or engineering. Explain why the problem matters for medicine, biology or healthcare and how your methods add insight or enable validation. Say what a positive or a negative result would mean (for example more reliable signals, better diagnostic interpretation or a validated dataset for future research) and who would benefit: clinicians, patients, data scientists or other researchers.
Step 4: Choose and justify your method
Describe your approach in enough detail to show that the project is feasible and will give interpretable results. It can be:
- computational analysis, such as machine learning, signal processing, simulation or modeling
- engineering or experimental work, such as sensor design, data acquisition systems, simulators or controlled experiments
- a systematic review or meta-analysis with transparent inclusion and exclusion criteria
- a survey or clinical study run with clinical partners, with quantitative or qualitative analysis of the responses
You don't need to invent new algorithms or instruments. Reproducing, benchmarking or combining existing methods is fine if the question is well defined and the analysis rigorous.
Step 5: Define evaluation and validation
Every project needs an evaluation that shows whether your method, model or instrument captures what you claim. Its form depends on the project type, but it must be quantifiable or systematically verifiable.
| Project type | Possible evaluation criteria |
|---|---|
| Prediction or classification | Accuracy, sensitivity, specificity, F1, ROC-AUC |
| Regression or estimation | RMSE, MAE, R² |
| Signal analysis or simulation | Agreement with reference data, signal fidelity, reproducibility |
| Experimental or hardware | Measurement accuracy, stability, response latency, calibration error |
| Systematic review | Number of included studies, pooled effect size, risk-of-bias scoring, PRISMA compliance |
| Survey-based study | Internal consistency (Cronbach's α), inter-rater reliability, distribution of responses, reliability of qualitative coding |
| Questionnaire design | Construct validity: does each question measure what you intend? |
Before you distribute the survey widely, check what each question measures. Asking clinicians "Are you uncertain in borderline CTG cases?" does not measure their confidence or competence, because it only restates what a borderline case is. Pilot the survey to check that respondents read the questions as you intend.
Step 6: Assess feasibility
Check that the plan fits one semester and your resources:
- Can you get the data or participants, with the ethics approvals you need?
- Does your team have the technical and analytical skills?
- Do you have the equipment and computing resources?
- Can every stage, from pilot testing to analysis, be finished in time?
- What is your fallback if a dataset, a collaborator or the survey response rate falls short?
Over-ambitious or methodologically vague projects rarely succeed. Choose depth and clarity over scale or novelty: we would rather see a small, carefully validated study than a large prototype or a questionnaire that shows nothing.
Step 7: Write and submit the proposal
Write the proposal with the proposal template and submit it as the Proposal guide describes.
Recommended workflow
| Week | Activity | Outcome |
|---|---|---|
| 1 | Review the project list on Topics & projects, brainstorm and form teams | First concept or a shortlist of topics |
| 2 | Discussion in class, and a first mini-pitch for custom topics | Early feedback and a feasibility check |
| 3 | Refine the question, find data or collaborators, pilot methods | Draft outline and preliminary validation plan |
| 4 | Finalize methods, evaluation strategy and proposal | Proposal ready to submit |
This timeline is a guide. Projects with surveys, clinical collaborations or experimental setups may need to start earlier to leave time for approvals and pilot testing.