Project Structure

Here is an annotated version of the project structure.

concept-to-clinic
├── compose The compose folder contains all of the configuration for Docker, including development and production. It defines docker containers for two separate applications (interface and prediction) that are both run by `docker-compose up`.
│   ├── interface Docker configuration for the interface application.
│   │   ├── Dockerfile-dev Development Docker configuration for the interface application.
│   │   ├── entrypoint.sh The script that is called when the docker container is finished setting up.
│   │   ├── gunicorn.sh Called by the Dockerfile to run the application in production.
│   │   └── start-dev.sh Called by the Dockerfile to run the application in development mode.
│   |── prediction Docker configuration for the prediction application
│   │   ├── Dockerfile-dev Development Docker configuration for the interface application.
│   │   ├── gunicorn.sh Called by the Dockerfile to run the application in production.
├── docs A Sphinx project with all of the documentation for the application (Contents collapsed for this view).
├── interface The frontend and backend that a clinician will interact with. Contains a Django project using the Django Rest Framework for the backend, and a Vue.js frontend project.
│   ├── assets Static assets that are served, such as javascript, css, and images.
│   │   ├── css Project-specific stylesheets.
│   │   │   └── project.css The project stylesheet
│   │   ├── images A folder for any static images that need to be displayed in the interface.
│   │   └── js A folder for project-specific javascript.
│   ├── backend All of the backend code that controls the application.
│   │   ├── api Provides the REST api for the application. The frontend communicates with the views in this applicaiton.
│   │   │   ├── migrations When the database schema changes (because a model changed) we need to create migrations, which are auto-generated code snippets to update the database to the new schema. These are generated by `manage.py makemigrations` and applied with `manage.py migrate`. These should never be edited by hand. (Folder collapsed).
│   │   │   ├── __init__.py `__init__.py` tells Python this directory is importable. No code lives in this file.
│   │   │   ├── apps.py Configures the API application.
│   │   │   ├── serializers.py Describes how the django rest framework should turn models (objects) into JSON.
│   │   │   ├── tests.py Keep testing, my friends.
│   │   │   ├── urls.py Describes the API endpoint URLs.
│   │   │   └── views.py API endpoints that accept requests from the frontend and handle them.
│   │   ├── cases This component is an abstraction for a single patient (i.e., a "case"). It also has models for the candidates (potential nodules) and nodules (confirmed nodules).
│   │   │   ├── migrations When the database schema changes (because a model changed) we need to create migrations, which are auto-generated code snippets to update the database to the new schema. These are generated by `manage.py makemigrations` and applied with `manage.py migrate`. These should never be edited by hand. (Folder collapsed.)
│   │   │   ├── __init__.py `__init__.py` tells Python this directory is importable. No code lives in this file.
│   │   │   ├── apps.py Configuration for this component.
│   │   │   ├── factories.py Code to generate example instances of the models. This will be used by the tests.
│   │   │   ├── models.py The models that describe how Python objects map to what is stored in the database.
│   │   │   └── tests.py Test, test, test, test!
│   │   ├── images This component contains abstractions for a DICOM image, including both the image series and
│   │   │   ├── migrations When the database schema changes (because a model changed) we need to create migrations, which are auto-generated code snippets to update the database to the new schema. These are generated by `manage.py makemigrations` and applied with `manage.py migrate`. These should never be edited by hand. (Folder collapsed).
│   │   │   ├── __init__.py `__init__.py` tells Python this directory is importable. No code lives in this file.
│   │   │   ├── apps.py Configuration for the images component.
│   │   │   ├── factories.py Code to generate example instances of the models. This will be used by the tests.
│   │   │   ├── models.py The models that describe how Python objects map to what is stored in the database.
│   │   │   └── tests.py Get the test on.
│   │   ├── static Application to serve static content pages.
│   │   │   ├── __init__.py `__init__.py` tells Python this directory is importable. No code lives in this file.
│   │   │   ├── apps.py Configuration for static content pages.
│   │   │   ├── tests.py Tests are good.
│   │   │   └── urls.py URLs for the static content pages.
│   │   └── __init__.py `__init__.py` tells Python this directory is importable. No code lives in this file.
│   ├── config Configuration for the interface Django application.
│   │   ├── settings The settings for the Django application.
│   │   │   ├── __init__.py `__init__.py` tells Python this directory is importable. No code lives in this file.
│   │   │   ├── base.py These settings are shared across all configs (though can be overridden).
│   │   │   ├── local.py Settings for local development.
│   │   │   ├── production.py Settings for production environment.
│   │   │   └── test.py Don't stop testing.
│   │   ├── __init__.py `__init__.py` tells Python this directory is importable. No code lives in this file.
│   │   ├── urls.py Overall URLs for the project. Includes the URLs from the individual components.
│   │   └── wsgi.py The WSGI configuration.
│   ├── frontend Code for the frontend of the user interface.
│   │   └── index.html Initial index page with simple Vue.js application.
│   ├── requirements Configuration specific requirements (Python packages) for the interface application.
│   │   ├── base.txt The shared packages for both local and production. Most dependencies will live here.
│   │   ├── local.txt The packages that are only used in development. (E.g., debugging tools)
│   │   └── production.txt The packages that are only used in production.
│   ├── manage.py The manage.py file provides commands for interacting with the Django application.
│   └── requirements.txt The main requirements file (which by convention is in the top level folder). This simply points to the production requirements.
├── prediction The prediction application. This is a microservice that returns predictions for various ML tasks for a given DICOM image. This separates the machine learning models from the interface application code.
│   ├── data Use this folder to store DICOM images for use in testing and training models. This folder is ignored by git, so the contents won't be synced to the repository.
│   │   └── test Tests for the data.
│   ├── requirements Requirements (Python packages) for the prediction application.
│   │   ├── base.txt Common packages that will be used for both local and production.
│   │   ├── local.txt Packages that are exclusively used in local development.
│   │   └── production.txt Packages that are exclusively used in production.
│   ├── src The source code for the prediction application. This application is a Flask application (as opposed to the Django application for the interface). This lightweight framework is good for serving simple endpoints and letting us focus on the algorithms.
│   │   ├── algorithms Code for the three machine learning tasks: identification, classification, and segmentation.
│   │   │   ├── classify The classification model. For a centroid of a given nodule, determine the probability that it is concerning.
│   │   │   │   ├── assets The assets folder should contain the fully trained model stored in a serialized state. These can be quite large, so this is managed by git-lfs.
│   │   │   │   ├── src The src folder contains the code necessary to train the model from scratch. It won't be executed by the endpoint, but it is required to keep track of the details of the model that solves this task.
│   │   │   │   └── trained_model.py The trained_model.py file provides a simple, one method API to make predictions. It loads the serialized model from assets and then makes the necessary predictions.
│   │   │   ├── identify The identification model. For a given DICOM image, return potential nodules.
│   │   │   │   ├── assets The assets folder should contain the fully trained model stored in a serialized state. These can be quite large, so this is managed by git-lfs.
│   │   │   │   ├── src The src folder contains the code necessary to train the model from scratch. It won't be executed by the endpoint, but it is required to keep track of the details of the model that solves this task.
│   │   │   │   └── trained_model.py The trained_model.py file provides a simple, one method API to make predictions. It loads the serialized model from assets and then makes the necessary predictions.
│   │   │   └── segment The segmentation model. For a given DICOM image and set of centroids, predict per-pixel values for the image representing if it is cancerous.
│   │   │   │   ├── assets The assets folder should contain the fully trained model stored in a serialized state. These can be quite large, so this is managed by git-lfs.
│   │   │   │   ├── src The src folder contains the code necessary to train the model from scratch. It won't be executed by the endpoint, but it is required to keep track of the details of the model that solves this task.
│   │   │   │   └── trained_model.py The trained_model.py file provides a simple, one method API to make predictions. It loads the serialized model from assets and then makes the necessary predictions.
│   │   ├── preprocess Any shared preprocessing code that more than one model will use for prediction can be refactored into this folder.
│   │   ├── tests Tests for the model prediction endpoints.
│   │   │   └── test_endpoints.py Tests the endpoints.
│   │   ├── __init__.py `__init__.py` tells Python this directory is importable. No code lives in this file.
│   │   ├── factory.py Creates and configures the Flask application.
│   │   ├── utils.py Helpful utilities for the views.
│   │   └── views.py Describes the API endpoints and routes requests to the appropriate ML model.
│   ├── config.py Configuration for the Flask application.
│   └── requirements.txt Root folder requirements.txt points to production by convention.
├── tests Tests that exercise the entire architecture (i.e., both applications in tandem.)
│   ├── assets Any large files that are required by the tests for execution.
│   └── test_docker.sh Simple shell script to test that the Docker configuration is working for developers.
├── CHALLENGE_RULES.md The rules for the Concept to Clinic challenge.
├── CODE_OF_CONDUCT.md The code of conduct for the Concept to Clinic challenge.
├── CONTRIBUTOR_LICENSE_AGREEMENT.md The contributor license agreement for the project.
├── LICENSE The license for the project.
├── README.md The top-level README for the project.
├── local.yml Docker configuration for the local development environment.
├── production.yml Docker configuration for the production environment.
├── requirements.txt All of the requirements.txt for the project, including docs. Points to the requirements.txt for both of the projects.
└── setup.cfg Configuration for the project for packages that accept configs. Currently configures style guides for flake8.