The EHPR is an online registry which was first developed to support deployment of Health Authority-employed health care providers during the 2017-2018 wildfire season and was later updated for use during the COVID-19 pandemic. Activation of the EHPR is a proactive step towards ensuring BC’s health care system is best prepared to respond to emergencies of a varied nature, including pandemics, wildfires and floods. It is an online registry of health care professionals who are willing and able to be deployed or hired to support B.C.’s health system response.
All health care providers or health care staff are invited to register. This includes:
- Health authority (HA) employees – both clinical and non-clinical (i.e., trades, administrative, etc.);
- Health care providers in good standing (meet fitness to practice requirements) with their health profession regulatory college or credentialing body, who usually work in private practice and would like to be deployed to work in a HA setting;
- Students, including medical residents and employed student nurses;
- Retired health care providers who are:
- registered on a temporary emergency basis with their health profession regulatory college or credentialing body and are willing to work in a HA; or,
- unregistered but are able to support an emergency response by providing non-clinical care; or,
- unregistered but who meet the requirements outlined in the Provincial Health Officer (PHO) Order to provide or support COVID-19 immunization services – provided the declared public health emergency is in effect.
- Health care providers without a regulatory college or credentialling body (e.g., Respiratory Therapists, Medical Laboratory Assistants, Medical Laboratory Technicians), who have retained membership with their society.
- Runtime environment - NodeJS
- Programming language - Typescript
- Backend API server - NestJS
- Express
- TypeORM
- Swagger
- CHES
- Database - PostgreSQL
- Frontend React framework - NextJS
- Formik
- Tailwind CSS
- class-validator
- Deployment
- GitHub Actions
- Terraform
- AWS CloudFront/S3/Lambda/RDS
Workspace or Package | Description | README |
---|---|---|
apps/api | Backend NestJS API server | README |
apps/web | Frontend NextJS React app | README |
packages/common | Shared library | README |
packages/accessibility | Test Accessibility | README |
packages/scripts | Maintenance utilities | README |
When you create a pull request, be aware that a GitHub action for each project will be executed to check its validity.
-
Install NodeJS 16+ as a runtime environment by nvm
-
Install yarn as a package manager
-
Install and run Docker Desktop
-
Check out the repository
$ git clone https://github.com/bcgov/ehpr2 $ cd ehpr2
-
Install dependencies
$ yarn
-
Define environment variables in .env
Copy .env.example to .env
$ cp .config/.env.example .env
Define variables for database connection.
PROJECT=ehpr RUNTIME_ENV=local POSTGRES_HOST=db POSTGRES_USERNAME= POSTGRES_PASSWORD= POSTGRES_DATABASE=
Database Initialization
The local
.pgdata
folder is mapped to a volume in db container, and it is initialized at the initial launch. If you change env variables to authenticate a db connection, delete.pgdata
so that database could be reinitialized.Slack Integration
SLACK_ALERTS_WEBHOOK_URL=
If SLACK_ALERTS_WEBHOOK_URL is defined and a submission fails with an exception, the error message will be sent to the Slack channel.
The Make
command docker-run
to build and launch containers is defined in Makefile.
$ make docker-run
Containers:
- ehpr_db
- ehpr_common
- ehpr_web
- ehpr_api
Containers are configured by Dockerfile and docker-compose.yml
If you get a DockerException, make sure Docker Desktop is running.
docker.errors.DockerException: Error while fetching server API version: ('Connection aborted.', ConnectionRefusedError(61, 'Connection refused'))
[80774] Failed to execute script docker-compose
It is recommended to run database as a container in any case. On the other hand, you can run common, api, and web as NodeJS instances.
$ make start-local-db
Database Hostname Resolution
POSTGRES_HOST
env is defined asdb
, which is used as a service name in docker-compose.yml. Asapi
uses it to connect to the database and a service name is resolved as an address only in Docker environment, you need to redefine it to resolve it on your local machine. You can set it tolocalhost
if you persistently run the app in this way. Otherwise, add127.0.0.1 db
to/etc/hosts
.
API Calls
NEXT_PUBLIC_API_URL=http://localhost:4000/api/v1
To make successful requests from
web
toapi
, you need to setNEXT_PUBLIC_API_URL
environment variable. It is set by default when using Docker, but if you run the application on its own, you should supply this value by creating a file named.env.local
placed inapps/web
.
$ yarn build
$ yarn start:local
or if you want hot reloading
or want to debug, run apps in watch
mode.
$ yarn watch
In order to make breakpoints work in
watch
mode, setsourceMap
totrue
in tsconfig.json and restart the apps.
Unit and integration tests are run against the API in the CI pipeline on pull request as well as deploy.
Run API unit tests with make api-unit-test
Run API integration tests with make api-integration-test
This command will spin up a postgres container, run the API integration tests, then close the created container.
The application is hosted in the OCIO Cloud platform - AWS LZ2.
In order to access the AWS Accounts for each environment, your IDIRs would have to be onboarded on to LZ2 for the project code bcbwlp
- EHPR
All Deployments to AWS environments are managed through github actions.
The following actions trigger deployments as follows:
make tag-dev
/ Merge to main - Deploy to dev
make tag-test
- Deploy to test
make tag-prod
- Deploy to prod after approval.
The AWS infrastructure is created and updated using Terraform and Terraform Cloud as the backend.
The TFC keys required to run terraform can be found in SSM store in AWS.
Make commands are listed under terraform commands
in make file for initialization, plan and deployment of resources.
Service accounts are created with IAM permissions to deploy cloud resources such as - S3 static file uploads, update lambda function, cloudfront invalidation etc.
Use make tag-dev
to deploy your changes directly in dev environment without a pr if required.
Raise a PR to main
. Once merged, the dev environment will be updated.
For QA testing, run make tag-test
only in the main branch once the code is merged into main branch.
All changes in main are released to production by tagging make tag-prod
along with the version number of the release.
This creates a release tag and also a production tag, deploying to production, once approved by the Leads / DevOps team members.
As a part of the production release approval:
- Validate the latest ZAP scan results to ensure no new vulnerabilites are introduced.
- Review the latest code quality analysis results in Sonar Cloud to ensure no new vulnerabilities are introduced.
All BC gov projects must pass the STRA (Security Threat and Risk Assessment Standard) and maintain the approved SoAR
More details on STRA here
Regular review of ZAP Scan and Sonar Qube results must be performed. Especially before release to production.
Current STRA and SoAR here
Portal should be SSl, process for certificate renewal - Refer