Ask your own question of an open dataset, answer it in a public repository, and write it up as a structured abstract
Step 1 · The question
Your own question on an open dataset, written up as a short abstract.
This lab is yours. You choose a question, answer it with an open dataset using what you learned in Labs 1 to 5, and write it up as a structured abstract: the 250 to 300 word summary that conferences such as AUR, RSNA and SIIM ask for, divided into fixed headings. The result is a portfolio piece: a public GitHub repository with your notebook, a short README and the abstract, something concrete to show a mentor when you ask to join a research project. With a mentor's help, it can become a real submission.
A good first question is small, can be answered with data you can actually get, and has a clinical "so what". Some that work well: how much does the Lab 4 model's accuracy drop if you train it on a quarter of the images? Does a different MedMNIST dataset, such as BreastMNIST (breast ultrasound) or OrganAMNIST (abdominal CT), behave the same way? How well does a keyword rule find another finding in the Lab 5 reports? The Research Lab page lists more open datasets. There is no personal dataset and no number to check here; step 5 collects your repository address and your abstract.
By the end of this lab you can:
Step 2 · The idea
A structured abstract is the shortest complete version of a study, and many readers will read nothing else. Academic Radiology, the journal of the Association of University Radiologists, uses four headings: Rationale and Objectives (why it matters and what you asked), Materials and Methods (data, analysis and measures), Results (the main numbers, with the counts behind them) and Conclusion (the answer, claiming no more than the results show). Writing it early is a good test of your question: if you cannot fill the Results heading with a number your analysis will produce, the question is not sharp enough yet.
Draft each section in its own box; the word count adds them up. Look at the example if you want a model, then write your own. When it is ready, copy it into the report back below.
For AI studies, reviewers also look for the items in reporting checklists such as CLAIM (the Checklist for Artificial Intelligence in Medical Imaging): where the data came from, how it was split, how the reference standard was set, and how the model was tested. You do not need to tick every item for a first project, but your README should answer those questions.
Peer review is the last part. On GitHub it happens through pull requests and issues: a pull request proposes a change to someone's repository and lets reviewers comment on it line by line, and an issue is a comment thread about the project as a whole. Ask a classmate or mentor to review your repository, and review someone else's in return.
Step 3 · Warm-up
Two short checks on reading an abstract the way a reviewer does. They are not graded and always show the explanation.
A project tested a model on 624 X-rays and found 86% accuracy. Which conclusion does that result support?
One test set from one hospital supports a claim about that test set and not much more. Clinical use would need testing on other hospitals' images and in a real workflow, and a comparison with radiologists would need radiologists reading the same images. Overclaiming in the conclusion is the most common reviewer complaint about student abstracts.
Drag these four sentences into the order they appear in a structured abstract.
Rationale and Objectives, then Materials and Methods, then Results, then Conclusion. Each heading answers one reader question in turn: why ask, how did you look, what did you find, what does it mean. Notice that the Results sentence holds numbers only, and the Conclusion does not go beyond them. (The figures here are for illustration.)
Step 4 · Notebook
The notebook Lab_6_Your_Project.ipynb is a template rather than a lesson. It has a cell for your question and why it matters, a setup section that loads a MedMNIST dataset (or your own choice of open data), headed sections for your analysis that reuse functions from your toolkit.py, an AI-use log for any code an assistant wrote, and a cell that prints the numbers for your Results. Most of the work is Reuse and Direct the AI: you know the methods by now, so the skill is putting them together and checking them.
Type it into the template's first cell:
GITHUB_USERNAME = "your-username"
Colab needs a Google account. It opens the course's copy of the notebook; follow "Save your work to GitHub" below to keep your own.
Tick each part off when you finish it. Your ticks show as progress on the Research Lab map.
Every task in the notebook is tagged with one mode. In Write tasks you write a few lines yourself from an empty cell, with a hint and a hidden solution. In Fill in tasks most of the code is there and you complete the blanks. Reuse tasks import a function you wrote in an earlier lab from your own toolkit.py, the way real projects grow. In Direct the AI tasks you ask an AI assistant (Colab's built-in one is suggested, but any is fine) to write the code, paste it in, run the test cell, and note in the AI-use log what you asked and what you had to change. Fix tasks give you code "written by an AI" with one realistic mistake to find. Read tasks ask you to put lines in order or predict what code will print before you run it.
Early labs lean on writing code yourself, because that is how the basics stick. Later labs lean on reusing your code, directing an AI and checking its work, because that is how research code is written now, and checking is the part a person must still do.
Your project gets its own public repository rather than living in your fork of the course, so a mentor can see it on its own.
pneumonia-external-validation), make it Public, and tick Add a README file.your-username/your-repo, branch main. Save again whenever you finish a part.toolkit.py into the new repository too (on GitHub: Add file > Upload files), so the notebook runs for anyone who opens it.Step 5 · Report back
Enter the address of your public project repository and paste your structured abstract. Both are saved with your course progress, and the lab is marked finished on the Research Lab map. Nothing is scored; the reviewer who matters is the mentor you show it to.