CARE is a centralized capacity management and patient management system which is a conglomerate of Patients, doctors, hospitals, labs, specialized treatment centres, hospital administrators, shifting control cells etc. Each hospital would have to login and update the information regarding their Assets including bed capacity, health care personnels, current patient count, status etc so that it would be easy for the district administration to get a birds eye view of the entire healthcare system as well as the patients through the smart and intuitive dashboards.

The software is free and open-source available under an MIT License at https://github.com/coronasafe

Create a VPC

Go To: VPC networks > VPC networks > Create VPC network. (link)

1. Enter the following values:

   1. Name: care-vpc

   2. Maximum Transmission unit (MTU): 1460

   3. VPC network ULA internal IPv6 range: Disabled

   4. Subnet creation mode: Custom

   5. Create a new subnet using following values:

      1. Name: cluster-snet

      2. Region: asia-south1

      3. P stack type: IPv4 (single-stack)

      4. IPv4 range: 10.0.0.0/16

      5. Private Google Access: On

      6. Flow logs: Off

   6. Firewall rules: Leave default

   7. Dynamic routing mode: Regional

Equivalent commands:

gcloud compute networks create care-vpc --project=$PROJECT --subnet-mode=custom --mtu=1460 --bgp-routing-mode=regional

gcloud compute networks subnets create cluster-snet --project=$PROJRCT --range=10.0.0.0/16 --stack-type=IPV4_ONLY --network=care-vpc --region=asia-south1 --enable-private-ip-google-access

Reserve a static IP address

Go To: VPC Networks > IP Addresses > RESERVE EXTERNAL STATIC IP ADDRESS (link)

1. Enter the following values:

   1. Name: pip-care

   2. Network Service Tier: Premium

   3. IP version: IPv4

   4. Type: Regional

   5. Region: asia-south1 (Mumbai)

   6. Attached to: None

2. Note down the IP address

Equivalent commands:

gcloud compute addresses create pip-care --project=$PROJECT --region=asia-south1

Setup CI

Setup meta-base

Once the instance is up and dns records are active, visit the metabase url, you would be presented with a new user form where you can create a new admin account

Create 2 storage buckets

GoTo: Cloud Storage > buckets > create (link)

1. Create a publicly accessible bucket for facility images:

   1. Name: <prefix>-care-facility

   2. Location type: Region

   3. Location: asia-south1 (Mumbai)

   4. Default storage class: Standard

   5. Public access prevention: Off

   6. Access control: Uniform

   7. Protection tools: None

2. Create a private bucket for patient data.

   1. Name: <prefix>-care-patient-data

   2. Location type: Region

   3. Location: asia-south1 (Mumbai)

   4. Default storage class: Standard

   5. Public access prevention: On

   6. Access control: Uniform

   7. Protection tools: Retention policy: 7 days

Setup access keys

Go to Cloud Storage > Settings > Interoperability (link)

1. Under Access keys for service accounts, click on Create a key for a service account

2. Click create a new service account:

   1. Name: care-bucket-access

   2. Click “Create and continue”

   3. Role: Storage Object Admin under Cloud Storage

   4. Click "Continue" then "Done"

3. Select care-bucket-access and click on create key

4. Note down the Access key and Secret for later

Configure CORS:

1. Activate Cloud Shell

2. Create a file bucket-config.json with the following contents

[
   {
     "origin": ["https://care.ohc.network", "https://care.coronasafe.in"],
     "method": ["GET", "PUT"],
     "responseHeader": ["*"],
     "maxAgeSeconds": 3600
   }
]

1. Replace the origin with your deployed frontend URLs

2. Apply config for buckets using gcloud cli

gcloud storage buckets update gs://<prefix>-care-facility --cors-file=bucket-config.json

gcloud storage buckets update gs://<prefix>-care-patient-data --cors-file=bucket-config.json

Once the cloud resources are created, we can deploy our applications as Kubernetes workloads. The necessary YAML files can be found as a template in the link below.

Template repo: https://github.com/coronasafe/infra_template

Editing the template repo

Using the template, replace all generic/example values to production values. Let’s go through each folder.

Certificate

1. Replace the example hostnames for ‘dnsNames’ with actual hostnames

Configmaps

1. In care-configmap.yaml, add database configurations and update the hostnames in CSRF_TRUSTED_ORIGINS and DJANGO_ALLOWED_HOSTS

2. In nginx.yaml, update the server_name with hostnames.

Helm

1. Install Helm[Ref]

2. use the static IP created from "Reserve a static IP address" step to replace the IP value in helm/scripts.sh

Ingress

1. Replace example hostnames with actual hostnames

Secrets

1. Update care-secrets.yml

2. Update metabase.yml with metabase db credentials.

Applying Configurations

1. Set the default gke cluster

   1. Get the name using: kubectl config get-contexts

   2. Set the config: kubectl config use-context <name>

2. Run the helm script: bash helm/scripts.sh

3. Use kubectl to apply all the kubernetes yaml files in the following order

   1. Deploy configmaps: kubectl apply -f 'configmaps/*'

   2. Secrets: kubectl apply -f 'secrets/*'

   3. Deployments: kubectl apply -f 'deployments/*'

   4. Services: kubectl apply -f 'services/*'

   5. Clusterissuer: kubectl apply -f ClusterIssuer/cluster-issuer.yaml

   6. Certificate: kubectl apply -f certificate/certificate.yml

   7. Ingress: kubectl apply -f ingress/care.yaml

4. Once ingress is created, kubectl get ingress care-ingress will show the IP of the TCP load balancer.

5. Once the DNS records are added, the SSL will be automatically handled.

Add DNS records

create DNS A records for each domain pointing to the static IP created from "Reserve a static IP address" step

The components required in deploying CARE to any cloud/on-prem infrastructure are listed below.

Cloud Components List for CARE application

1. Virtual Network

2. Kubernetes Cluster

3. Postgres DB

4. Load balancer

Cloud Components List for Metabase (Reporting Software)

1. Virtual Machine

2. Postgres DB

3. Load balancer

Cloud Components for Dev Access

1. Virtual Machine as a jump server

2. Firewall / Network security groups

3. Virtual Machine for VPN

The green components are the basic requirements that we expect a cloud service provider or on-prem infrastructure to provide.

Create 2 databases, care-db and metabase-db

2. Create instance for care:

   1. Instance ID: care-db

   2. Password: <use your own strong password>

   3. Database version: PostgreSQL 14

   4. Cloud SQL edition: Enterprise

   5. Region: asia-south1

   6. Zonal availability: Single zone

   7. Click show zones

   8. Primary zone: asia-south1-a

   9. Click show configurations

   10. Machine configuration: Dedicated core (2 vCPU, 8 GB)

   11. Storage type: SSD

   12. Storage capacity: 20 GB

   13. Enable automatic storage increases: Enabled

   14. Under connections, set

   15. Instance IP assignment: Private IP

       1. Associated networking: care-vpc

       2. If not presented with setup connection dialog, skip to p

       3. Select SET UP CONNECTION for setting up a private service connection and Click ENABLE API

       4. Select Use an automatically allocated IP range

       5. Click create connection

   16. Public IP: Disabled

   17. Under Data protection

   18. Automated backups: Enabled

   19. automated backup window: 2:30 AM - 6:30 AM

   20. Enable point-in-time recovery: Enabled

   21. Days of logs: 7

   22. Enable deletion protection: Enabled

   23. Maintenance window: Sunday

   24. Once the db instance is initialized, create a new database:

       1. Click on care-db > Databases > create database

       2. Enter the db name care

       3. Click create

Repeate the above steps for metabase-db with the following changes

1. Instance name: metabase-db

2. Machine configuration: Dedicated core (1 vCPU, 3.75 GB)

3. db name: metabase

Go To: Kubernetes Engine > clusters > create > standard (link)

1. Cluster basics:

   1. Name: care-gke

   2. Location type: Zonal

   3. Zone: asia-south1-a

2. Node pools > default pool

   1. Number of nodes: 2

3. Node pools > default pool > nodes

   1. Machine configuration: General purpose

   2. Series: E2

   3. Machine type: e2-standard-2 (2 vCPU, 8 GB memory)

4. Node pools > default pool > networking: Network tags: care-gke

5. Node pools > Cluster > Networking

   1. Network: care-vpc

   2. Node subnet: cluster-snet

   3. Network access: Public cluster

   4. Enable HTTP load balancing: Enabled

• Background information is shared with the State Administrator or the District Collector via a representative.

• Live Interaction with Ernakulam War Room to see capabilities.

• Collector Appoints Nodal Officer

• Server Infrastructure is deployed and linked to the domain of your choice at state level.

• Nodal Officer sets up the War Room Operations team

• Training of the Core Team and the staff across the district with the training material and quick reference guides

• Collector to issue the orders to Operationalise CARE at hospitals in the district. (Draft GO’s here.)

• Nodal Officers at healthcare facilities enter data into Care

• Digital war-room with dashboards Go Live with data coming from the field.

Post Go-Live

• Set a weekly review process with the DC heading the meeting.

• Set recurring weekly training sessions by the head of HR.

Summary of Steps

1. Set up the network

2. Set up Database

3. Create storage buckets

4. Create a GKE cluster.

5. Configure GKE workloads.

6. Post setup steps.

CARE infrastructure overview

Most projects on the Coronasafe Network are dockerized and can be easily deployed on various container orchestration services for scalability. This documentation contains instructions for setting up our Care Network project in a production environment on the Kubernetes service provided by Amazon (AWS EKS). The same principles can be applied to other projects under the Coronasafe Network.

For help in setting up a local version of the project for development, see Setting up the project locally

Before deployment make sure that both the care and care_fe repos from the Coronasafe Network Github Organization are forked into the required organization's Account. This step makes it easier for the projects to remain synced, The Care project will keep receiving security updates and features which can be easily synced up with the deployment fork. Any Security issue must be reported to the Coronasafe Network admin before being implemented in any forks.

Summary of Steps

Prerequisites

1. Set up an SMTP server. When a Gov is deploying care, the Gov should provide email gateway credentials along with domains.

2. Set up a Sentry project for error management.

CARE Infrastructure Deployment

1. Create a Virtual Network.

2. Create a PostgreSQL Server. Create database and add PostGIS extension.

3. Create a S3 compatable storage (Since Azure Storage account does not support S3 API) and get credentials for the storage.

4. Create a private AKS cluster.

5. Create a VM instance as a jump server.

6. Create a VM instance as a bastion host, install VPN, and whitelist its IP in the jumpservers network security group.

7. Configure a self-hosted agent (linux) in the jumpserver for CI/CD pipelines.

8. Update configurations for each deployment in their corresponding YAML files.

9. Create the deployments using the CI/CD pipelines from Github.

Metabase Deployment

1. Create a VM instance in the same VNET as CARE.

2. Create a PostgreSQL Server. Create a database for Metabase in it.

3. Create a read-replica of CARE Database for Metabase to read data from.

4. Follow the installation steps from the official documentation.

5. Create a load balancer and expose the service.

Summary of Steps

Prerequisites

1. Set up an SMTP server. When a Gov is deploying care, the Gov should provide email gateway credentials along with domains.

2. Set up a Sentry project for error management.

CARE Infrastructure Deployment

1. Create a VPC.

2. Create a PostgreSQL Server. Create database and add PostGIS extension.

3. Create an Amazon S3 bucket.

4. Create a private EKS cluster.

5. Create a EC2 instance as a jump server.

6. Create a EC2 instance as a bastion host, install VPN, and whitelist its IP in the jumpservers network security group.

7. Configure a self-hosted runner (linux) in the jumpserver for CI/CD pipelines.

8. Update configurations for each deployment in their corresponding YAML files.

9. Create the deployments using the CI/CD pipelines from Github.

Metabase Deploymen

1. Create a EC2 instance in the same VPC as CARE.

2. Create a PostgreSQL Server. Create a database for Metabase in it.

3. Create a read-replica of CARE Database for Metabase to read data from.

4. Follow the installation steps from the official documentation.

5. Create a load balancer and expose the service.

Deployment on EKS involves quite a few steps to setup. This page provides a link in the bottom to a document that can help in creating the necessary resources on AWS. However, do make sure to read the following once before diving right in as it may contain answers to many queries you may have during the setup:

• At all times, the region code for the Mumbai services will be ap-south-1. Make sure to choose this to reduce latency in the services.

• The Step 0 in the article requests to have installed AWS IAM Authenticator. Do note that this will not be "necessary".

• In Step 1, there has been some changes since the article. Choose "EKS Cluster" as the use case while creating the role. The AmazonEKSServicePolicy is no longer required.

• In Step 2 and Step 4, you shall not be able to provide the same URL for uploading the template. Instead manually download the template on your system and upload the template where required.

• In the VPC creation step (Step 2), do provide any valid IP ranges from RFC 1918. Make sure your range does not collide with any other existing VPC.

• In the Node Group creation step (Step 4), execute aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.16/amazon-linux-2/recommended/image_id --query "Parameter.Value" --output text on your command line replacing 1.16 with your cluster's kubernetes platform version. Use the value of the output as the Node Image ID.

• Follow the steps until and including Step 4 only.

Click here to setup the necessary AWS resources for your EKS deployment.

To create a local development setup of the care backend and frontend projects, perform the following steps.

Care Backend

• Install PostgreSQL on your machine. The instructions for the same can be found at https://www.postgresql.org/download/

  • Change the authentication method to md5 instead of peer. The instructions for the same can be found in this StackOverflow Answer

• Install the GDAL and Geos libraries. ( This is required because Care Uses a PostGis database Connection by default, this is to power location fields which can be later be used for better location-based queries ) On Debian/Ubuntu systems, run sudo apt-get install libgdal-dev libgeos-dev python-dev

• Clone the project: $ git clone https://github.com/coronasafe/care

• $ cd care

• Create a virtual environment: $ virtualenv -p $(which python3) venv

• $ source venv/bin/activate

• $ pip install -r requirements/local.txt

• Set the DATABASE_URL environment variable for your Postgres database. ( By default it expects a database with the name "care", only change this variable if your database is named something else )

• Run the database migrations: $ python manage.py migrate

• Create a superuser: $ python manage.py createsuperuser

  $ python manage.py runserver

• The project should be running at http://localhost:8000 API Specs are available at http://localhost:8000/redoc and http://localhost:8000/swagger

Care Frontend

• Make sure you have Node v10 or above installed on your machine.

• Clone the project: $ git clone https://github.com/coronasafe/care_fe

• $ cd care_fe

• $ git checkout master

• $ npm install

• $ npm run start

The project should be running at http://localhost:4000 In order to connect the backend to the frontend, modify proxy target for /api in webpack.config.js

This stage is the actual step where we deploy and run the project on the cluster. Since this will be not be a tutorial on the Kubernetes infrastructure or its advantages, we shall not delve into the details of several files used in this stage.

First, clone the following repository: https://github.com/coronasafe/k8-templates

The repo contains the necessary manifest files required for deploying your care project. The files have been separated into different directories. Take a quick look at the various files in the repo.

We shall now look into what our end deployment looks like.

The requests first come to a LoadBalancer we shall create. This is then balanced across the nginx pods inside our LoadBalancer service. The requests are then routed according to the requested resource. If the route is /api, they are sent to the Backend Service which then distributes it across the Backend pods running one container each with the backend image from ECR. All other requests are sent to the Frontend Service and distributed across the Frontend pods running one container each with the frontend image from ECR.

The services in kubernetes are used to manage deployments. Services are bound to deployments and are responsible for spawning pods using the definitions in the deployments. You can think of deployments like Classes in C++ and pods like Class Instances. The service is also responsible for always making sure a specified number of pods are spawned as defined in it. It is also used to expose the pods inside as a "service" to other services in the cluster. [Syam to Add Docs]

AWS RDS can be used to store your application data. The Mumbai region servers can help in reducing latency for your services. In order to setup an RDS instance, head over to the RDS console and create a new instance. Here are a few things you may need to look out for:

• The instance engine must be chosen as Postgres.

• Choose the Production template

• Choose the settings that are right for your use case.

• Make sure you select the VPC you created for EKS and not any other VPC. The VPC will be immutable after the instance creation.

• The port may be provided different from the standard port of 5432. This can be found in the 'Additional connectivity configuration' subsection under the 'Connectivity' section. While this does not add a huge security advantage, it may be desired.

• Create an initial database inside the instance by giving an 'Initial database name' under the 'Additional configuration' section.

After completion of the instance creation, note the endpoint, port, username, password and the initial database name you provided. Your DATABASE_URL required in the future steps will then be postgres://<username>:<password>@<host>:<port>/<initial database name> and the POSTGIS_URL will be postgis://<username>:<password>@<host>:<port>/<initial database name>.

The following services from amazon are used to power the project.

• Amazon Elastic Kubernetes Service (Eks)

• AWS Elastic Computing (EC2) (2 machines)

• Amazon RDS | Cloud Relational Database (RDS)

• Simple Email Service (Amazon SES)

• Simple Notification Service ( Amazon SNS ) for SMS

• Amazon ElastiCache for Redis

• Simple Storage Service (Amazon S3)

• Content Delivery Network (CDN)

Our EKS deployment consists of running containers with docker images of the care project. The images will be served from a private container registry service provided by AWS called Elastic Container Registry (ECR). To setup the repositories for your care frontend and backend images, head over to AWS ECR console and create a new repository each for the backend and frontend.

Build image

To build the docker image of the care project, first clone the repositories:

$ git clone https://github.com/coronasafe/care $ git clone https://github.com/coronasafe/care_fe

Inside the directory of the project you want to build, use the docker build command for building your required images.

Eg.: If you are in the backend folder, run $ docker build -t care:latest .

After the creation of the image, you can verify it by running $ docker images

The following branches are used for dev and production

Care Backend ( care ) :

master -> Development Branch

production -> Stable Production Branch

Care Fron End ( care_fe )

develop -> Development Branch

master -> Stable Production Branch

Always use stable production builds in production, Keep the fork in sync every 3 days.

Always merge the development branch and test before merging production.

Push the image to AWS ECR

• Visit the ECR console.

• Select the repository you want to push your image to.

• On the top right corner, you should be able to find View push commands

• Follow the steps there to push your docker image to AWS ECR.

Infrastructure Requirements

High Availability Kubernetes Cluster:

• Implement a multi-master Kubernetes cluster with at least three master nodes to ensure high availability and fault tolerance.

• Deploy worker nodes across multiple geo-locations to avoid single points of failure.

Persistent Storage:

• Set up dynamic storage provisioning using custom storage classes and external storage solutions.

• Implement data replication and backup strategies for critical application data, ensuring data integrity and availability.

S3-Compatible Object Storage:

• S3-compatible object storage solution with high availability and scalability features.

• Configure data lifecycle policies for object versioning, retention, and automatic deletion, requiring careful data management.

• Enforce encryption at rest and in transit for all stored objects.

• Implement fine-grained access control using bucket policies, IAM roles, and access keys, ensuring only authorized users and applications can access the stored data.

Auto-Scaling:

• Implement custom Horizontal Pod Autoscalers (HPAs) with custom metrics. Set up Cluster Autoscaler to dynamically adjust the number of worker nodes based on resource utilization.

Security Policies and Network Policies:

• Enforce strict security policies, including PodSecurityPolicies and Network Policies, to control and isolate pods and services.

Custom Ingress Controllers:

• Implement custom Ingress controllers for routing and traffic management, including features like header rewriting, SSL termination, and authentication.

Advanced Networking:

• Configure a custom CNI (Container Network Interface) plugin with strict network policies to enforce micro-segmentation for maximum security.

• Ability to create Network Policy resources to control ingress and egress traffic between pods, making network access more secure.

Custom Resource Definitions (CRDs):

• Support for Custom Resource Definition for adding ClusterIssuers for Letsencrypt Certificate Authority or other certificates manager.

SMTP Server/Service:

An SMTP email server to handle email traffic for the domain the Care application is running on.

Role-Based Access Control (RBAC):

• Enforce fine-grained RBAC policies, ensuring only authorized personnel can access and manage specific resources within the Kubernetes cluster.

Centralized Logging and Error Detection:

• Configure centralized logging with log aggregation and analysis using tools like Sentry.

Secrets Management:

• Utilize advanced secret management solutions like HashiCorp Vault or Kubernetes native Secrets Store CSI Driver for secure storage and distribution of sensitive data.

Backup and Disaster Recovery:

• Establish a backup and disaster recovery strategy, including off-site backups, data snapshots, and automated failover procedures.

Compliance and Auditing:

• Implement Kubernetes audit logging and maintain compliance with industry-specific standards (e.g., CIS Kubernetes Benchmarks) for on-premises deployments.

Documentation and Training:

• Exhaustive documentation, training materials, and runbooks for onboarding and maintaining the Kubernetes setup.

Advanced Backup and Restore Procedures:

• Implement procedures for backup and restoration of the entire Kubernetes cluster, including etcd data, to ensure data integrity during failures.

Database Cluster Setup:

• Deploy a highly available database cluster (e.g., PostgreSQL, MySQL) with multiple read replicas for scalability and fault tolerance.

Data Partitioning and Sharding:

• Implement data partitioning and sharding strategies to distribute database load across nodes, requiring careful data modeling and management.

Database Encryption:

• Enforce encryption at rest and in transit for database data, utilizing advanced encryption methods and key management.

Database Backups:

• Configure automated database backup strategies with incremental and differential backups, ensuring data consistency and reliability.

Automated Failover:

• Set up automated failover mechanisms for the database cluster to minimize downtime in case of node failures.

Database Maintenance Jobs:

• To ensure database performance, schedule and manage maintenance jobs, such as index optimization, vacuuming, and data archiving.

Database Security Policies:

• Enforce strict database security policies, including role-based access control, audit logging, and database-level encryption.

Database Replication Lag Monitoring:

• Monitor and manage database replication lag to ensure data consistency across replicas, requiring timely intervention when lag exceeds thresholds.

Database Version Upgrades:

• Planned database version upgrades with minimal downtime.

Database Scaling:

• Implement auto-scaling policies for the database cluster, dynamically adjusting resources based on workload demand.

Continuous Deployment (CD):

• Set up continuous deployment to automatically promote successfully tested changes to production without manual intervention.

Rollback Procedures:

• Define rollback procedures and automate them in case of deployment failures or issues in production.

Environment Configuration Management:

• Manage environment-specific configurations and secrets separately from the application code.

Monitoring and Alerting:

• Track application performance and set up alerts for anomalies in deployments.

This section covers the environment and its required setup for running the care project in production. This involves setting up the secret keys, encryption keys, PostGIS database URLs etc. The project also employs other services such as Redis for caching and Sentry for logging.

The following list contains variables you will need during the production environment.

Basic Requirments

• Access to 3 subdomains (dashboard, frontend, backend)

Tech Deploy Steps

• Setup the project locally

• Connect domains

• Add state-specific data.

• Test

Refer to the next section to learn how to operationalize CARE, set up teams on the field, and train the teams.

The following are what you'll need for the setup:

• An AWS account with Administrator Access

• A Linux machine

• A decent internet connection

• Git installed on your machine

• AWS CLI

  • Click here for installation instructions.

• Kubectl command

  • Click here for installation instructions.

Once you have the above, move to the next step.

To set up a war-room the infrastructure required is:

• 3 Large screens

• WiFi Requirement: Atleast 100 Mbps speed

• Laptops, one each for data entry staff and 3 extra laptops to control the screens.

• HDMI cables to connect the screens to the laptops

• Ample number of charging points

Setup the Desktop

The setup of the desktop is a fairly straightforward process. This would involve unboxing and installing the UPS, CPU, and Monitor and then Connecting the bundled keyboard and mouse.

Setup Windows

This part is slightly tricky. You need to first connect the PC to the internet via a LAN cable to get started. There will be a check for an update that occurs. As soon as this is complete, you should disconnect the LAN cable.

Set up a local account with the default values mentioned below. Device Name: 10BedICU Spoke User: 10BedICU Contact 10BedICU Installation Co-ordinator to set the Password.

Once the account is set up and logged in to windows, reconnect the LAN network and the installation is complete.

Week 01

1. The relevant Government Orders adopting the system must be issued

2. The district collectors and their teams must be onboarded

3. The server (preferably at state level) must be set up

4. The CARE Nodal team at district level needs to be set up

5. In-depth training to the CARE Nodal team

6. CARE Nodal team to lead training for field level staff

Week 02

1. Data entry from hospitals commence (Capacity and inventory management)

2. Strict enforcement by the Nodal team

3. Amending deficiencies in training

4. Start Patient Management module rolled out

Week 03

1. War room Analytics team gets into action

2. Weekly reviews for continuous optimisation

3. Students cadres for engineering and field operations launched

What is CARE?

CARE is a web-based Hospital management system with special focus on Capacity augmentation and Load Balancing. It is an Open Source software with an MIT license built by a group of volunteers. It can be utilised by anyone for free and it shall remain so forever.

To learn more about CARE and its features, CLICK HERE.

How does CARE work?

CARE connects all healthcare facilities within your region (district/state/country) in one network. The critical details of healthcare assets are entered into the system first-hand by each healthcare facility. This Data is projected on the district level dashboards so that the district team (district collector) has all relevant information to take decisions.

Data Flow in CARE:

Each hospital enters data about the 3 things

• Patients

• Bed capacity and availability

• Oxygen availability and consumption

The data entry at each hospital is closely monitored and enforced by a team appointed by the district collector.

A short 6min video of recurring data entry at any hospital is available here.

A War Room (Control Centre) is set up at the district level where the dashboards are viewed to make quick decisions on the field.

How to operationalise CARE within a district.

1. The district collector issued an order mandating each hospital (government as well as public) to register within CARE and update information on bed capacity and availability every set interval. The latest order by the Ernakulam district collector is HERE for your reference. The order must have the following points:

   • Must provide for setting up of a central COVID Control centre (War room) for the district

   • A CARE Nodal Officer must be appointed.

   • Must mandate that all hospitals within the district register themselves on CARE within the said date and update details at least every 3 hours.

   • A time period must be mentioned within which training of all staff in using CARE must be achieved. The Nodal Officer for Training must be responsible for this.

2. The collector identifies one high level health official (in case of Ernakulam, Dr. Mathews Numpeli, the District Program Manager of Ernakulam, National Health Mission) to be the CARE Nodal officer for deploying the system.

3. Under the Nodal officer, there are the following officers specifically for specific functions:

   1. CARE Enforcement officer: Ernakulam district is divided into 7 Taluks. The PROs of the Health department at each Taluk is responsible for ensuring compliance of the above mentioned Order in point 1. The PROs from Taluks report straight to the PRO of the district. Law enforcement is engaged to deal with any resistance from the field to ensure data entry.

   2. Nodal Officer for Capacity building and Augmentation: This officer identifies exactly where the maximum load on healthcare is and works towards increasing infrastructure like setting up new COVID treatment centres with the support of government and private contributions.

   3. Nodal Officer for Oxygen: This person heads the committee that manages oxygen. The committee has representatives from the department of industries to identify suppliers and ensure supply, the RTO (enforcement) to ensure logistics for the oxygen and also Law Enforcement to ensure safety while transporting the oxygen.

   4. Nodal Officer for shifting: There is one officer specifically to ensure shifting of patients from one hospital to another happens smoothly on CARE. He must liaison with ambulance managers and the RTO to optimise logistics.

   5. Nodal officer for Training and Human Resource Management : This officer will ensure there are enough data entry operators and that training on using CARE is given to all. This officer also manages engagement of volunteers to manage data.

4. The MOs in each Panchayats are held responsible to patient management within their jurisdiction.

5. A district central war-room is set up displaying all the dashboard.

6. The war room has a team of 15 data entry staff continuously monitoring data entry from the hospitals and immediately identifying any lapse.

7. A district level shifting team that works around the clock must be set up to operate shifting. The team must at any point in time have at least 2 doctors, and 8 logistics managers to ensure smooth shifting.

8. There is a Mobile Training Team of 10-15 people for training all users on the field.

CARE: Data collection and enforcement.

At Hospital (Facility) Level:

There must be one person at each healthcare facility to enter the details regarding

• Patients

• Capacity and bed availability

• Oxygen, supply and consumption

The CARE system facing the hospital staff is very easy to use and efficient. The registration of a hospital can be done within 5 minutes while the periodic updation of data takes up less than 5 min. Click HERE to see a demo of the registration and data entry from hospitals

At Panchayat Level:

At panchayat level, the Medical Officers are responsible to update the status of COVID patients under Home Care.

At Taluk Level:

The PROs of health department at each taluk oversees that the data entry happens at each hospital promptly.

At the District Level:

There is a team of at least 15 data entry personnels at the district control room to monitor and ensure accuracy of data collected from the field. They also immediately identify if there is any lapse from any hospital.

The CARE Capacity Dashboards shows when each hospital has last updated their information. The Nodal CARE Enforcement Officer will supervise this system.

Capacity Building

The Nodal person for Capacity Building at the district control room will identify the areas where capacity is lacking using the CARE Capacity Dashboard. The officer engages with private/public organizations to build capacity by setting up COVID treatment centres or increasing the bed capacity of hospitals.

Oxygen Management

There is an Oxygen Committee functioning out of the District Control room. The committee comprises of:-

• Staff of the Department of Industries: These staff coordinate with the suppliers and the industries in identifying resources.

• Regional Transport Officers (Enforcement): The officer arranges for vehicles to transport oxygen in a timely manner

• Law Enforcement: Wherever required, the police must be engaged to ensure safety of transportation of oxygen

The Oxygen Modal Officer coordinates with all the above individuals and gets real time data on availability of oxygen in each hospital, the burn rate etc from the CARE Oxygen Dashboard.

Shifting of patients:

There must be a central shifting team comprising of

• Doctors: To clinically assess and identify which patient must be shifted to which facility

• Logistics Managers: They use the CARE Capacity Dashboards to identify bed availability and arrange for Ambulance for transportation.

NOTE: In Ernakulam, only emergency shifts are executed by the District Central Shifting team. The shifting of patients that are not so severely sick (like shifting a patient from home to a Covid Care Centre etc) are executed at the Taluk Level. If this model is followed, 2 persons at Taluk level to manage local shifting will also be required.

CoronaSafe Network has also developed a logistics management system to control the ambulance systems called the SURAKSHA NETWORK.

Training and HR Management:

Training:

Training is conducted through an online certification course on CARE available HERE.

Training material in the form of videos is also available HERE.

A mobile training team of 10-15 members must be set up to conduct targeted training sessions wherever necessary.

HR Management:

Table of Human Resource Needed:

Technology

Engineering Requirement

Coronasafe Logistics Platform (SuperHero App) is made up of 3 components

1. SuperHero App: Written for Android (Kotlin) and requires at least one experienced Android developer with Kotlin experience

2. Logistics Dashboard: Written in React.JS/Javascript and can be maintained by someone with React.JS experience

3. Backend: Written in Node.JS with POSTGRES database. An experienced backend engineer with knowledge in Node.JS/Postgres and Sequelize ORM can maintain the application. Some knowledge in Firebase and AWS is recommended. The backend is currently deployed on AWS EC2 and the Dashboard is deployed on AWS Amplify. Someone with experience in AWS is recommended for this role.

All information on deploying (tech) the SuperHero Network is available HERE.

Operations

To operationalise the SuperHero Network, follow the Go-Live Checklist below:

• Set up a control centre with at-least one computer

• Identify and assign one smart phone (android) to each of the ambulances

• Identify and appoint a Nodal person to operate the manager console

• Conduct a training session for the ambulance drivers on using the SuperHero App

• Set up and communicate a dedicated helpline number for the drivers to report any concerns

• Ensure all phones have SuperHero App installed and vehicle registration done in the relevant category.

Your SuperHero Network is ready to use!!!

Summary

If you’re an expert in networking, you can follow the below 4 TLDR instructions and configure the Monitors Accordingly

• Identify the IP, subnet mask, and default gateway by using ipconfig in command prompt

• Once the network is identified, ping suitable IP addresses for the BPL monitors and make sure there is no response to ping for that IP before assigning the IP to each of the monitors.

• Assign IPs to the monitors, update the provided Google Sheet with the details[Bed Number, IP address, Subnet Mask, Gateway IP, MAC Number]

• You can request the 10BedICU Coordinator for confirmation.

• Once you receive the confirmation from the Co-ordinator, you can configure the beds in the CNS software as per the BPL Documentation as well

Instructions

1. Press Windows Key ( ⊞ ) + R

4. From this result, we can identify the LAN Network

6. From the above information, identify the network address range In this screenshot, we can see that the IP Address is 192.168.0.145 and the available IP range is 192.168.0.2 - 192.168.0.254

7. Once you’ve identified the IP range, you can start configuring BPL monitor IPs according to the above information

8. Subnet mask and Gateway IP will be the same for the monitor configuration.

9. Start assigning IP addresses for the monitors. Check the availability of the IP by simply pinging the IP from the command prompt. Eg: ping 192.168.0.14
10. In the above example image, you can see that the IP is already assigned to a device and therefore not usable. You can try a different IP until you find a usable IP.

12. After setting the IP Address on the BPL Monitor, you should restart BPL Monitor for the newly set IP to be used.

13. After you restart, you can ping the IP that you used to make sure that the monitor is now reachable over the new IP Address.

14. Once this is done, open the Google sheet for the Hospital you are configuring and fill in the details of the setup you have done. [Bed Number, IP address, Subnet Mask, Gateway IP, MAC Number]

15. Repeat Steps 9 and 14 to assign IPs for all the BPL monitors.

16. Once all the Monitors are configured, and all the IP Addresses are updated in the sheet, you can request this to be verified by the 10BedICU Co-ordinator.

17. After this, you can follow the documentation from BPL to install and set up the CNS software and then add the beds in CNS software.