1.All proximity trackers applications of today like Aarogya Setu of India or BlueTrace of Singapore demand that each of its users have a BLE enabled smartphone(for example an operating system of KitKat or greater for Android users) and the technique is effective only when large chunks of the population are using this smartphone application. But that cannot be the case for countries/regions with large populations and considerable proportions of low income groups. As a result, a lot many people are left untraced and their contacts with an infected person can be determined only by on-field investigation relying on people’s memories. Also regular app users cannot reap full benefits of it when so many people around are untraced. 2.Moreover, such BLE proximity trackers are region specific, restricting contact tracing for an individual within borders, which can prove to be fatal for international flyers. 3.If a person tests positive for Covid19 he/she must be interviewed by healthcare workers to trace contacts which may have been missed by tracking techniques. But reproducing all interactions accurately from memory is not possible and also healthcare workers have to repeatedly come in close contact with patients. None of the trackers provide any solution in such a case. 4.None of the prevalent applications support accessibility for any kind of people with disabilities. 5.Covid19 contact tracing apps have no utility outside the domain of pandemic control.

What it does

  1. Lazarus app allows multiple users to register on a single smartphone. After sign-in, each user can open up the dedicated interface for his/her account and use all app features including BLE tracker, such that all actions taken, data generated and stored are in accordance to this particular user.
  2. Now suppose user B starts up BLE tracker on his/her interface and leaves. The others cannot record their contacts when they go outside. For this we have a ‘SIGN-IN’ feature to record contact with someone without a smartphone or not registered at all. The smartphone carrying app-user (say user D) can ask for the phone number of the person with no smartphone or account (say person E). D enters this number on its app interface and the interaction between E and D is immediately recorded.
  3. But individuals are not much likely to exchange phone numbers to record contact with every person they meet as the number of dedicated smartphone app users will always be much less than that of shared app users or that of non-registered individuals. To solve this, we have introduced a special type of account called ‘Desk’. Places of close human gatherings like receptions, customer help desks, shops, classrooms, doctor’s clinics can be registered as Desk user in the app by the person-in-charge. This desk operator can keep recording attendances for anybody entering this space with the same Sign-in method mentioned above. This Desk account feature also generates readymade data regarding which places behaved as hotspots, without actually tracking down location of each infectious human-to-human transmission. The Desk user can also use BLE proximity tracker just like individual accounts.
  4. Apart from Sign-in method, QR exchange feature is also available where one user can scan QRs displayed by other users (individuals or “Desk” users) and record contacts.
  5. All the above interaction recording methods (BLE tracker, SIGN-IN feature, QR exchange feature) use an algorithm that generates unique time stamped code for each interaction (individual to individual and desk to individual) that is stored in the account data of the users involved. If an individual falls sick or a desk turns out to be hotspot, all associated past interactions can be easily traced back and the involved users be warned.
  6. To overcome the difficulty in reproducing interaction history from memory, an in-app “Enter Daily Log” option is provided where the user can wilfully enter his daily whereabouts just like maintaining a diary. All the log entries are then filtered by Microsoft Azure’s natural language understanding LUIS model, to extract key information like location, time and person or number of persons interacted with, which is then stored with date stamp.

How I built it

Microsoft Azure AD B2C--for user authentication Azure Functions--for recording human-to-human interactions without BLE, using phoneNo(SIGN-IN feature) Azure LUIS--for analysis of text input in "Daily Log" feature Microsoft Healthcare Bot--for symptom checking Google Cloud Firestore--to store interaction data temporarily for the user without a smartphone(person E in above example) in SIGN-IN feature

Challenges I ran into

Being from a core engineering background, developing a mobile application was not easy. Barring basic programming, algorithm and data structure, database management knowledge, everything else about app development and using cloud resources had to be learnt from scratch. Since I wanted an application that was available on both Android and iOS, I chose Flutter environment for my development process. Though programming and UI design on Flutter were easy to understand, but since Flutter is a fairly new platform, not all required features were available in readymade libraries and integration of Microsoft Azure's cloud services especially required reading a lot of documentation. Use of Bluetooth Low Energy on Flutter also required effort. YouTube videos and open-source Github repos helped a lot.

Accomplishments that I'm proud of

Figuring out cloud services was daunting but it helped in the app's features tremendously and I would like to develop more solutions for social good using cloud services with the right mentorship and support. I learned to push myself through scheduled tasks in order to complete the project. As the project involves a lot of activities happening simultaneously, there was no shortcut for any feature. But I feel happy about myself that I could patiently read through sample codes and documentation an learnt entire concepts in depth, so much so that now I am confident enough to be able to make something for any use case.

What I learned

In the development process I learnt a lot about the futuristic developer friendly cloud services available out there. REST APIs, GET, POST methods were extremely important for the project. My interest in learning Machine Learning technologies for higher studies was also boosted while trying to employ AI/ML for user utilities. I also understood the importance of UI design and enhancement of user-experience for a utility to be effective, whatever be the feature involved. A developer needs to put himself/herself in the target user's shoes, which, in my case, is every human being on this planet.

What's next for Lazarus

  1. With human voice support and Machine Learning, the above Daily Log feature can monitor physical and mental health of user all year round and provide personalized guidance for health issues, even beyond the current pandemic. The app, thus never loses its purpose. Voice support and multi-user support can also make use of the app easier for people with visual or other physical disabilities, that make smartphone use difficult.
  2. We also intend to implement a social media platform which will take up the health issues the users are facing (as evaluated in Daily Log feature) and post them anonymously for other users to view and users who have been verified as medical practitioners can offer suggestions. The suggestions relevant to a user will show up in his/her feed with the qualifications of the practitioner offering the suggestion. Thus the user receives honest medical advice which is not always guaranteed in paid visits where the doctor’s or hospitals’ vested interests can allow for misguidance and foul play.

Built With

Share this project: