Project Summary

This group research project, composed of myself and two other students, was developed to explore how medical diagnosis training simulation could be improved using procedural generation. As a lead programmer on this project, I designed and implemented the procedural generation algorithm that generated patient scenarios, wrote the associated documentation, helped develop the statistical analysis system, and co-authored the (unpublished) research paper.

Project Purpose

Through our research, we determined that existing medical diagnosis training simulations had some shortcomings. We found that the best training simulation available, which involved using specially trained actors, was cost-prohibitive and inflexible and existing computerized solutions failed to capture the complexity of a real-life patient scenario.

With this knowledge, we hypothesized that a key weakness of existing computer simulations was that their patient scenarios were one-dimensional, resulting in testing that mostly focused on memorization. A real-life patient is more complicated as they have a history consisting of events that can effect their chances for developing, and resisting, various ailments. For example, factors such as past illnesses, living conditions, economic standing, education, family relations, etc. can make a patient more or less likely to experience physical or mental illness. Taking these factors into consideration when simulating patient scenarios could provide more meaningful medical training that could facilitate more than just memorization testing, introducing greater nuance and ambiguity by simulating causality.

Application Development

To test this hypothesis, we developed a medical diagnosis training application in Unity where a trainee could interview a procedurally generated patient, choose a diagnosis, and review the accuracy of their decision.


Following is a high-level list of the key components that I completed for this project:

  • Detailed, modular Patient model
  • Expandable collection of Life Events with associated preconditions, effects, and probability modifiers
  • Dynamic probability system which takes multiple factors into consideration to determine the chance of an event taking place
  • Life Event system which determines if an event takes place based on the following factors:
    • Past events in the patient's history
    • Hereditary events in the patient's parent's history
  • Procedural Generation algorithm that utilizes the Life Event system to construct a patient's history from birth to the doctor's appointment date
  • Planner which builds the patient scenario by generating the patient, their parents, and their children
  • Procedural Generation Manager component which provides a suite of planner settings in Unity to customize the patient scenario


Simulating a Dynamic Patient

To simulate a patient, I first worked with my team to develop a sufficiently detailed patient model. As the central goal to this project was to generate a patient that meaningfully influenced the quality of diagnosis training, I designed a system which produced the patient's history as a collection of life events applied chronologically.

By determining the probability of event occurrences based on existing conditions, this Life Event system simulated cause and effect, giving each event context. As a result, the medical event that brought the patient to the doctor's office could have many factors influencing its inception, the expression and severity of its symptoms, and its overall duration.

To further deepen the aspect of causality, I also designed the system to take hereditary events into consideration. By generating the patient's parents first, then taking their histories into consideration when processing the patient's history, life events with a hereditary aspect can become more likely.

The following patient output reports show the detailed results produced by this system.

The following class diagram shows the structure of the codebase I built to produce the aforementioned results.

Statistical Analysis

A key challenge when developing a system based heavily on probability is ensuring that the results it produces make sense. To this end, I developed a testing program to produce a large batch of patients to be fed into a system that my team developed to export the results to an Excel spreadsheet for analysis. We then set up the spreadsheet to do automatic calculations and display the relevant data including the average and standard deviation for ranged values, the counts and occurrence rates for events, and a combined number to give the batch of patients an overall diversity rating. This analysis helped us identify behavior that didn't make sense, like rare diseases occurring too frequently, and adjust event probabilities to get more realistic results.


As a Computer Science research project, our goal with this project was to develop a hypothesis and then build an application to test it. While the heart of this application was the planner that I developed, several other components were needed to create the context to effectively test it. These components, which my teammates developed, included locating and placing 3D assets to build the doctor's office scene, implementing a dialog system, developing a patient names database for the planner to pull from, and a clipboard UI to display the information collected from the patient.

When interviewing a patient, the player must discover the particulars of the scenario by asking questions, with the data collected being automatically recorded on an on-screen clipboard. When the player has exhausted their options or feels that they have enough information to submit a diagnosis, they select the suspected ailment from a list of possibilities and a message is displayed evaluating their choice.

Final Thoughts

University research projects are often developed over time as they get passed from one team to the next, each further developing and innovating on the previous work. As this project started a novel approach to diagnosis, we laid the groundwork for future development by building a proof of concept that demonstrates the project's potential. While I would have loved to continue development, refine the procedural generation system, add features that I had to cut to keep the scope in reach, and get to see how medical students reviewed our work, it's satisfying to know that I made a meaningful contribution to a project that will continue to grow and realize its potential through future research.


Have questions about my projects or work experience?
Think I'd be a great match for your team?
Feel free to reach out!