Changes between then and now
Signup Workflow - HelloWorks
Referral Workflow - HelloSign
General Questionnaire Workflow - HelloSign
The email which is sent to doctor when his/her account is made via a hospital
Old referral email which I had made myself but it had some security issues
Emails sent in order to test the API calls
Number of Helloworks API calls made
One of the errors which is listed during login.
Email containing the OTP to set a new password
Forget password functionality for hospitals
Getting a proper health facility is a dream for all. Not all government/private hospitals have good facilities, equipment, or experienced staff to take care of the people of that city. The issue can be resolved if all the hospitals work collaboratively and ensure good facilities are provided to all. So, making a collaborative space for hospitals where they can refer patients easily, and maintain their records can prove to be very beneficial to society. Along with this if doctors and sole patients can also be benefitted from that platform then it would be great.
What it does?
Note: In the video I have talked about the landing page's playground section which includes disease search (using web scraping) and COVID-19 stats section. For covid stats there is a FETCH button to initiate the call but for disease searching you have to provide the name and hit enter key and then results will be displayed accordingly.
As my project provides a platform for three entities (Patient, Hospital, Doctor), according to the entities the functionalities vary.
Undoubtedly the most equipped entity in terms of functionality & utilities. It can do the following things:
a. Use the forget password functionality by getting an OTP via email.
b. As time progress, the hospital's infrastructure may increase i.e. number of beds/doctors/ICUs/oxygen cylinders may increase. So by using PROFILE PAGE they can do so easily.
c. Maintaining & updating patients' records has been oversimplified & thus it takes less time to manage them. A patient can be added by going to the table page (using the + icon) & metrics like disease_category, age, phone number, status, email, etc can be filled in.
d. Along with each patient, any number of test reports can be added. Any pdf/jpg/jpeg file can be uploaded as the report along with the description.
e. Referral is one of the promising features of the application. Firstly the hospital can use the SEARCH & SORT functionality to see only desired options & then use HELLOSIGN EMBEDDED TEMPLATE & see the request before sending it.
f. Referral stats are also shown with all of the required information & status of the referral request.
g. Status of a critical patient can be changed to stable/green by clicking on an icon. Removal of a patient can also be done by clicking on the RECOVERED button.
h. Each hospital is responsible for adding doctors to its accounts. While adding a new one they have to provide information like name, email, profile picture, and specialization (bones, eyes, nerves, heart). If a profile picture is not provided, a demo picture will be picked up according to gender.
Whenever a new doctor is successfully attached to a hospital, an email will be sent to the doctor's email & will be having login credentials. This aspect makes the life of doctors super convenient because the doctor has not had to worry about creating an account/remembering login credentials. That email will help him so that he/she can only focus on attending to patients via online mode.
i. Whenever a sole patient request an appointment then the request comes under the SCHEDULE section and the hospital has to accept/reject the request. If accepted, the sole patient will be notified by two emails. One mail is for intimation purposes and another is a result of HELLOSIGN's signing request for a General Questionnaire.
j. Gone are those days when Touch & Type was used to be the only way to interact with the website. In this app, the hospital entity can use its voice to do anything. That anything includes logging out, navigating between pages, filling out the patient details form, deleting a patient, and much more. Due to the time constraints of the video, I haven't even talked about the Alan-powered AI vice assistant but I have dropped a 3 minutes video in the GitHub repository so that one can understand its effect and impact.
2. Sole Patient
Just to be clear, sole patients are those patients who will use the app to schedule appointments with doctors of various hospitals. Following are the functions:
a. Can use the Profile page to change the registered details.
b. On the dashboard, apart from the registered details there is a filter where one can get to know which doctors of a particular specialization are available/registered.
c. If for specialization, there are multiple doctors in a particular hospital then the patient can also view them and can send the request for the appointment.
d. Status of each referral request can be seen and if accepted the patient can chat with the doctor.
e. The common chat window refreshes after every 30 seconds to fetch the latest data and the patient can ask questions to the doctor and can also view the prescription provided by the doctor.
The least/minimal UI is for a doctor in which the accepted appointments are shown and the doctor can chat with a particular patient and can also view his/her filled General questionnaire. A total of 5 prescriptions can be posted and can also be deleted.
How I built it
From the picture captioned as Changes between then and now, it is clear that I have worked a lot to change an existing project into a complex one, and finally, I can say that I have done that successfully.
At the start of this event, I was having only the hospital entity but then I added the other two entities ie Patient and Doctors. So, I have to completely revamp the architecture of the application. I also added the voice-assistant functionality after that. The inclusion of HelloSign provided a method for adding more reliability and the great functionality of e-signing. So let's have a look at how I integrated HelloSign Beta SDK and Helloworks API into the application:
Whenever a new user is registering on the application then the Hellowork API call is made so that a signing request can be sent to the user. The form which I have used here is basically the Agreements Form and the workflow is depicted in the picture captioned as Signup Workflow - HelloWorks.
As this template can be called by either the patient or hospital, the file create_instance.php ensures that the correct workflow id, participants id and merge fields array is used and grabs the fields accordingly. Also specifies the custom redirect_url and callback_url.
getWf.php is the file that is called upon signing of the agreement. So, it captures the users' response and accordingly deletes or forwards the user to the correct place.
The callback handler file, in this case, is call.php. And whenever the workflow is completed it runs the API endpoint which gives the zipped version of the signed document. So, this file unzips it and stores it locally on the server for future reference. I have saved it because the signer doesn't get a copy of the signed form as it is in the case of HelloSign.
HelloSign Usage (Referral Request):
The workflow can be seen from the picture captioned as Referral Workflow - HelloSign
Before making an API request to the server, I have to store the information in a tabular way in the database and that is done by the file detail_extraction.php.
As there are about 8 merge fields in the referral template that I have used, so signReq.php passes the data for the merge fields, setups the callback URL, and also redirect_url. Also, I have made sure that if the user closes the signature request then the necessary actions are taken place and the same can be seen in the script tag of the file.
Test.php collects the users' choice that either the agreement has been accepted or rejected. And according to it, the processing takes place. rejection leads to account deletion.
HelloSign Usage (General Questionnaire for patients):
Reason behind it?: As a patient's appointment with a doctor is fixed then a doctor generally needs to know the patient's medical history which may include a description of allergies, severe injuries, and stuff like that. So, this request will make the patient tell those to the doctor by filling up a pdf and that pdf is completely responsive and expands according to the input chosen by the patient. The workflow can be seen from the picture captioned as General Questionnaire Workflow - HelloSign.
The origin of this request is the notify.php page.
gq.php is the file making the call and gathering information like metadata, custom fields value, and other SQL commands.
callHandler.php ensures in this case that the local version of the signed GQ is available so that both the doctor and patient can view it. I know that the signer gets the signed copy of a HelloSign instance but in this case, I wanted the doctor to view the document. And if I use the API endpoint to dynamically get the signed document then after 3 days the document is removed from your server. So, that is why I stored the document locally.
Challenges I ran into
Initially the referral request was using a custom email template (not any external service like HelloSign) and in this way, I was exposing a lot of data values which was hampering the app's integrity. So, I incorporated HelloSign to ensure that the eSigning functionality helps me.
As I was new to the entire platform of HelloSign, I executed almost 150+ HelloSign calls and 100+ HelloWorks API calls. I was struggling with how to set up custom fields, and prepare the UI for embedded templates. The major challenge was understanding how the callback functionality works for the HelloWorks API because in the case of HelloSign callbacks there is a piece of detailed information in the documentation but for Helloworks it was not the case. I knew that there is a payload object in the request headers but I tried for a long time to see how to grab those.
Accomplishments that I'm proud of
For the last 3 to 4 weeks, I have dedicated my entire time to this project and I am proud of the fact that my project is not just using HelloSign for a single use case but I am using two use cases of HelloSign and one of HelloWorks. And I am sure of the fact that this project is ready to serve the world with the help of its various functionalities and being a very different healthcare-sector-related application this can save the lives of millions. This project not only has great functionality attached to it but is also equipped with the best UI and user experience for sure.
The last and most important thing is that by using a simple langauge that is PHP (some also say that php is outdated and one can't do much with it ) I have achieved almost everything which makes a beautiful UI based website equipped with tons of amazing functionalities. I haven't even used any framework, everything is implemented from scratch. By using php, I haven't compromised with the following best practices of good software designing:
1. Dry Principle: There are instances in the project where I needed a same sort of page for various functions and entities, so I used the parameters to hide and view the same page with different layout for each function. In this way I used a single way for 2 to 4 things. For example, the profile.php page covers 4 things like updating hospital details, adding test reports, adding a new patient and referring patient.
2. Keep It Simple, Stupid: By the help of most basic langauge I have presented a complex application. So, it's great for me. **