backend API

[sunayg]

The e-consult API and doctor onboarding process are currently not scalable. Given that data is being written in a JSON file and is also dependent on google sheets/forms for data entry.

My suggestion is to use MongoDB to store data. Also, since we are still in the early stage of the dev process, we should not build on top of vanilla node js/express instead use a framework like NestJS and Typescript. It will help us rapidly build a stable and scalable backend along with documented & debuggable code.

I have refactored the current backend API code in this repo here. I didn't fork the repo as it was a complete rewrite anyway. If you all agree, we can host move the repo to the eConsult and continue development.

The swagger docs can be viewed on localhost:3000/api-docs after launching with npm run start:dev

[debosmit-git]

Appreciate your work. The Current Doctor database is fairly small and we see scaling nowhere beyond 1:1000, Doctors to Patient Ratio. However, this is a necessary step for Patient Database when we do so. And we will be surely incorporating this. Added as a To-Do

[sunayg]

I'd like to continue further developing this. Do we have any idea about data we want to capture in the patient database? In addition to that, I will also integrate the prescription module that vibhor made has been working on.

[monikakatiyar18]

Hi there! The team here is doing a wonderful job. This concept is completely wonderful, in such times of crisis.

Putting in some thoughts here. Hope that would be okay.

Since this feature would contain patient & doctor sensitive information, are there any plans in place to secure the data? I was forwarding the link to my doctor friend, when the disclaimer about any mishaps related to info submitted, caught my attention. Any possibility or hint of data leak w.r.t. application could deter healthcare professionals to register.

Few suggestions: Similar to HIPPA compliant softwares, all patient and doctor critical data could be encrypted using strong algorithms, decoupled and stored in such a way that access to the database shouldn't provide easy access to decode. We can discuss more on this.

Enabling SSL on database & the application along with securing the instance where the application/database would be deployed should be taken into consideration. For linux based systems, there are instance hardening scripts in place to protect the system against unwanted attacks.

Mongo db or any other database would be a better option than google sheet & more secure as well.

[debosmit-git]

We have shifted to Airtable from Google Sheets, which is adequately secure.

The word of caution is for Doctors responsible for the interaction they are about to have on the Platform live on the platform.

Security is the topmost priority for the project after versatility.