Smartphones in the Future of Medicine

Dr. Eric Topol is interviewed in this NBC news segment covering iDoctor, a smartphone app with numerous medical uses. “There is too much waste in healthcare” he says, explaining that many medical processes could be done cheaper with devices that most people already own.

iDoctor is not the first app of its kind. Sana, an MIT project to bring open sourced telemedicine to the Android platform, is being used in dozens of countries. While iDoctor and other apps may improve healthcare in North America, the need for this kind of technology is even more pressing in countries with poor healthcare infrastructure. Countries like Thailand, the subject of our pilot project, use decentralized medical records software, meaning that clinics across the country cannot easily or accurately transfer patient records to another hospital if necessary. Many Thai clinics are over-capacity, serving 6-12 thousand patients with only a few doctors. As a result, pressure to keep patient records up to date is put on volunteers from NGOs. Especially in rural areas where there are no medical clinics and access by vehicles is limited, the need for low-cost solutions such as an Android app for telemedicine and remote long term care is absolutely essential in improving the quality of life of many people.

SmartLabs sincerely hopes that technology like iDoctor continues to be developed and gains traction in global markets.

Advertisement

Applications Open for Cohort II!

Dhaka, Bangladesh

SmartLabs is now accepting applications from student developers and project managers for our second cohort! The project will begin in September 2013 and run until December 2013, when we plan to have our solution implemented.

Here is a summary of the project:

In partnership with Em[POWER] Energy Group Ltd., SmartLabs will build and implement an integrated software solution for a co-op of people who collect and sell recyclable materials at the Matuail landfill site in Dhaka, Bangladesh, to effectively negotiate moderated fair prices with merchants. The pilot co-op group will include 40-80 ‘feature phone’ users, equipped with an SMS-based application to respond to designated merchant requests for large quantities of specific scrap materials (i.e. glass, plastic, metal). Merchants will have access to an online interface to make requests.

Scavengers at Matuail are underpaid for their work because they are forced into competition, and they lack facilities for sorting materials and managing inventory. Scrap commodities prices (based on demand from large recycling companies) are highly variable and can change hourly. While Em[POWER] will build an on-site sorting and storage facility, SmartLabs will help the co-op use cell phones to ensure they are earning fair prices, and exercize more power in the supply chain through inventory management. SmartLabs and Em[POWER] want to create a way to eventually guarantee at least a dollar a day in wages to the 6000+ scavengers that live and work in the Matuail landfill.

Apply Now

On Building a Team

While working on our Telemedicine in Thailand project, I’ve learned quite a few things about building a team and managing a talented and diverse group of people.

The first lesson that I learned (the hard way) is that it is often very difficult to get computer science students to work on an extra-curricular project, especially when that project is unpaid. Ultimately, it didn’t really matter that I had an interesting problem to solve and a real client to work with. We weren’t just going to build something and hope that someone would implement it – we had an actual value proposition based on testimonials and extensive research from a non-profit that organizes volunteers for a network of rural medical clinics in Thailand.

Computer science students are in high demand, whether they know it or not. Many of them also like to own the projects that they are working on, or in other words, they all want to be recognized as Co-Founders, and they often have an issue being a subordinate member of a development team. At the same time, there are many other computer science students that actually want to be micro-managed. They want to be given specific instructions and deliverables, and they want to know the exact objective of every one of their tasks. These people are not interested in ‘owning’ the project, they don’t want to be creative, they just want to get results.

The approach that I took to recruitment was that I wanted to work with my developers. I explained that we’d be learning details about the clients needs throughout the project, and new information might change our envisioned solution dramatically. Unfortunately, while this idea interested some candidates, the ones that prefer to have an itemized list of deliverables places in front of them were turned off. Understanding a candidate’s personality was difficult when only based on a first impression at an interview.

Recruitment was the longest process of our entire project this year. It took me 4 months to get a final team together, and that was after several developers dropped out or lost interest, and I was forced to start the recruitment process all over. At one point, we had an incredible team of 12 student developers. But as soon as I gave them time to think about joining the team, and explained that we didn’t fully understand how we were going to solve the problem yet, most of them claimed that they were too busy with school to commit their time.

I believe that hiring talented people is as much about selling yourself and your vision as it is about getting them to try and prove their worth. My main recruitment strategy, given the nature of the project, was to reach out as far as possible into the pool of computer science students at my University. This was done by essentially spamming every computer science student, especially the grads whose names and emails are posted on the faculty website, with a plea to consider joining my team. I also tried to get the students that I had recruited to reach within their own networks. I still see no alternative to this lengthy process.

Now that we’re nearly at the end of our development phase, I can safely say that we have prevailed. I learned that I didn’t need a huge team of developers with different specialties. Dividing up work between a large team and also distributing administrative access to our servers and other services proved to be unnecessary and inefficient. Ending up with a lean team of 4 students that could work together on each of the deliverables reduced the potential for disagreements or redundant work.

The most important lesson that I learned, however, was that hiring a person who is committed and anxious to learn is absolutely always better than a person who has a tonne of impressive experience, and as a result, they act like they have nothing to learn from the project or their teammates, and they remain stuck in their own methods. That kind of person can still be very useful though given their expertise, so I put a few of them on an advisory board that is on call to help us in case we get stumped by some feature.

Some of these lessons only apply to the circumstances of this project, but some of these lessons also apply to the important process of recruitment in general.