- A clinical researcher named Alejandro. He wants to: a. Input patient measurements to predict clinical output b. Visualize their patient’s data in the context of the rest of the data (for certain variables/features) c. Generate easy-to-interperet visual summary of concerns to share with the patient
Alejandro wants this software to be compatible with the clinical platform. He should not have to clean data himself, change file types, or open jupyter. He is able to interpret clinical data (metabolites, disease markers) but needs visualizations to do so quickly. He would also like to have more simplistic charts to help the patient understand their risk.
- Software engineer, BRENDA. She wants to: a. Diagnose issues with the software. b. Looking for potential security issues. c. Pushing software updates. d. Making the model more generalizable.
BRENDA wants the tool to have descriptive error messages, be well-documented, have accessible version control, and contain usage statistics. She is highly technical.
- Future multi-omics researcher, C. eligans, looking to extend the tools to a different dataset. a. They have a microbiome and metabolome dataset for patients with neurodegenerative diseases. b. They want to visualise the relationships between c. They want to see if they can train a new model, using similar features to predict the status of a cohort of patients with parkinsons, Alzheimer’s, and non-Alzheimer's dementia.
C. eligans needs to know what input features they will be required to have for the tool to work, and have these requirements well documented. They have different microbiome diversities and different metabolic molecules of interest for their disease. They are an experienced multi-omics researcher but have only rudimentary software development skills. They have a modestly sized lab and might have capacity to hire a software engineer/data scientist but want to verify that this tool is worth pursuing before committing to the tool.