If you need help setting this platform up, please email me at brandon.cummings@berkeley.edu, we are more than happy to help set this up for any city.
-Brandon
This platform was created for local cities or municipalities to help manage corona virus testing sites. This platform accomplishes 3 main goals:
If symptoms are present, the user will be shown a map that shows all local testing sites, and a google map link to direct them to the site.
For all testing sites, there is a portal to keep track of number of tests administered and number of patients in line.
Full admin suite to create/edit testing site officials, testing sites, and a dashboard for analytics to gain real time insights.
Some local cities will not immediately see the need for more public testing centers and will need a digestible way of analyzing this solution. To aide with that, we created a slide deck to explain why cities should implement this platform.
Please see the self hosting guide.
Because installing dependencies is such a pain, we've bootstrapped this thing for you!
bin/setup
# for all options:
bin/setup -h
being sure to follow any instructions it gives you. After you've done that you should have:
- the following soft dependencies installed: PostgreSQL, Heroku Toolbelt, etc...
- the correct version of Ruby installed and activated
- hard dependencies (via
Gemfile
) installed - a local
.env
file for setting ENV Vars - databases created w/schemas loaded for both
development
andtest
environments. - seed
development
databases
You can set some optional ENV Vars to tweak the way the app runs, or simulate the app running on other platforms.
In development and test, you should configure these via a .env
file.
DATABASE_URL
: set to mimic the behavior of setting the database connection on Heroku. (Default to usingconfig/database.yml
)DB_REAPING_FREQUENCY
: how often (in seconds) the database connection pool should be reaped. (Default =10
)WEB_CONCURRENCY
: set the number of Puma worker process to run. (Default =2
)RAILS_MAX_THREADS
: set the number of Puma threads & ActiveRecord's connection pool size. (Default =5
)
There are also some required ENV Vars that you'll need to set for all environments.
GOOGLE_API_KEY
: the API key used to render Google Maps.RECAPTCHA_SECRET_KEY
andRECAPTCHA_SITE_KEY
: used to render the reCAPTCHA element on index page. RECAPTCHA_SITE_KEY
Further there are some required ENV Vars that you'll need to set in production
.
These are covered in more detail in the self-hosting docs.
These can also be overridden in local development
and test
environments via your .env
file.
DEFAULT_MAP_CENTER_LAT
: the latitude of the default center of your mapDEFAULT_MAP_CENTER_LON
: the longitude of the default center of your mapRAILS_APP_ROOT_DOMAIN
: the HTTP host to use when generating URLS for emails, assets, etc... (Default =localhost:5000
)SEND_GRID_API_KEY
andSEND_GRID_USERNAME
: for sending emails.
We use a Procfile
to declare all of the processes we use.
This includes starting the Rails app (via the Puma web server).
Use Heroku-local to start/stop all of the processes in the Procfile
:
heroku local:start
NOTE: You can shut everything down by hitting ^C
(that's Control
+ C
).
Point your browser/client at http://localhost:5000 to see the app in action!
With the app running, you should be able to sign in with the seeded admin account admin@example.com
and the password password1234
.
In order to see the Site Official View, you will need to create a new User and Host through the Admin view.
-
Go to the “Testing Sites” tab to create a new Host.
-
Go to the “Location Officials” tab and create a new User.
NOTE: The User your create must be associated to the Host you just created. Also be sure the host address is correctly populated by Geocoder by checking the fields “latitude” and “longitude”.
This platform can be used the following way.
A local government IT team sets up the platform and designates where in the city a testing site will be located and how many officials will work at each location.
The city will market to the citizens the url of the site, the citizen can self diagnose symptoms and find a testing site if needed.
There are two main actions that can occur in the testing site officials view, increasing the number of test kits used, and keeping track of people in line waiting to receive a test kit.
If there are 3 individuals working a testing site, one can be administering the test, one can be capturing the patient information and updating the number of test kits used through the platform, and one can be keeping the line count up to date and organized.
The admin view allows for new testing sites and testing site officials to be created/updated, as well as showing in real time the number of test kits used, total wait time and testing sites that may need additional resources, per testing site.