I think the main achievement of hackathons can be measured not by what apps are developed–reportedly, few are commercialized and maintained–but by people who find each other. The Blue Button Innovation Challenge brought together a lot of professionals who had never met before, and many formed teams that created really fun and useful apps that make you think, “Why hasn’t anyone done this yet?”
I came down on Saturday morning of the hackathon, missing Friday’s keynote by Beth Israel Deaconess Medical Center CIO John Halamka but viewing the initial pitches, picking up the excitement and the good cheer that allowed everybody to ignore the nasty wet snow that we’d have to deal with on the way home.
The air was crackling with innovation and the meeting room, an elongated rectangle, could barely hold the line of people making pitches. I thought there were too many generals and not enough soldiers, but several teams ended up with a nice balance of clinicians, programmers, and designers–total strangers at the start.
During the hackathon, Ajay Major blogged about the kickoff and the development itself. Afterward, I talked to all four winning teams and learned how their experience and dreams blended into viable applications.
The winners spanned an interesting range of applications: mostly for clinicians rather than consumers, but one (HOMEfield) for use out literally in the field; some fairly self-contained, others tapping into external resources; some tied tightly to interesting and innovative hardware while others web-based. Blue Button actually didn’t play a big role in many of the apps, but Blue Button’s “get it out there fast and simple” attitude pervaded the winning teams.
HOMEfield: making quick decisions under pressure
One of today’s pressing health care issues (in the sense that it appears a lot in the press) is the high rate of concussions in sports. After a fall or collision, the team must make a quick decision: can the player return to the game? Should he wait out the game on the bench? Or even get medical treatment? Professional teams keep sports doctors on the field, but plenty of child and amateur teams lack this guidance.
Current methods of evaluating head traumas out in the field are insufficient and miss many dangerous concussions. Even the many sensors being suggested in helmets can indicate only how hard the impact was, and where. The actual effect on the brain is not well represented. Studies have challenged the accuracy of these devices.
HOMEfield, one of the MedStart Hackathon winners, decided to go directly for the discernible effects of concussion–in particular, eye movements–through a procedure called a head ocular movement exam (from which the name HOMEfield comes). Research has established that when the eye follows a curving or zigzag line, a healthy individual does so with different patterns from someone who has suffered a brain trauma. It is not hard for a computer program to distinguish a healthy pattern from a dangerous one. It simply has to display a circle or a jagged line and record the eye movements of the individual.
The challenge for HOMEfield was to carry out eye-checking on a cheap, easily available device. Their successful demo at the hackathon was done on a laptop, coded in Python using the OpenCV library. The process of checking the user’s eye and returning a result took only 30 seconds. The team’s pitch at the hackathon, embedded below, shows the difference between a healthy and problematic eye scan.
Most modern phones and tablets have a front-facing camera with enough resolution to capture the eye’s position in detail (at least a megapixel—with better resolution likely to come in future devices), so the trick is to get enough data from the camera to track eye movements. If necessary, HOMEfield will create a dedicated device.
Teams could record a baseline for each athlete, in order to have a known pattern to compare her to after an injury. Or teams could just compare athletes to some standard, default pattern for a healthy brain. Over time, people of different demographics (for instance, different ages) could be scanned and the app could offer a whole library of appropriate patterns for eye movements.
In addition to its use for rapid decision-making on the playing field, HOMEfield’s app might be useful for EMTs, in emergency rooms, by law enforcement officers, and perhaps eventually even in the home, as recovering head injury victims check their progress. The team is currently looking at incubators and considering the Health Challenge sponsored by GE and the NFL.
ArmMe: order out of chaos
It was the testimony of a cancer survivor and a doctor that led the team that developed ArmMe to settle on cancer as their focus. Anyone who has gone through the long, agonizing journey of cancer (yourself or for a family member or friend) knows that the endless succession of doctor visits, treatment sessions, and changes in drugs and doses–all in mood of fear and doubt–can be overwhelming. And of course, you’re always carrying your own documents from one doctor to another. ArmMe mobilizes the patient to fight back.
The ArmMe app provides data in two directions, from doctors to patient and back again. On the provider side it gathers data through Blue Button and delivers it to the patient, integrated into a simple visual map. On the patient side, it accepts input such as whether she is taking her medication and what bad effects she’s feeling. At some point, ArmMe may also be able to take data directly from health and fitness devices.
A big question for the app, as developer Danny Kent told me, was how much information to present to the patient. Giving all the test results and related considerations would just drown out what the patient really needs. A perfectly balanced team–cancer survivor, physician, med students, data scientist, and developers–was about to tune the information displayed. ArmMe pares it down to something understandable even by someone without a high-school degree–but also allows the chemistry PhD to drill down into details.
ArmMe benefited from the back-end presented by Datuit representative Gordon Raup. Its SafeIX Platform translates of data from Blue Button into JSON, exposing it to applications through a RESTful interface. Among the services ArmMe may make use of is the integration with consumer fitness devices and a window into articles about health from Healthwise. I may write a feature about SafeIX later.
ArmMe will also be customizable to serve the US’s 19 million cancer patients, because the physical characteristics and treatments for different cancers vary greatly. The app is being developed as web browser app, and may be ported to native platforms later. They are going to the http://gordon.tufts.edu/competitions in April. Their market includes pharmacies, pharmaceutical companies, and health care providers. Because the app is hoped to improve patients’ adherence to treatment plans, all these companies should be motivated to support it.
SimplyID: a contemporary approach to error prevention
Most readers will have heard of the potentially life-saving uses of bar codes at Veteran Affairs medical centers, now a common technique at in-patient facilities. Allegedly invented by a nurse after seeing scanners at a supermarket, this mechanism involves a bracelet bearing a unique bar code on each patient. Before administering medicine, a nurse always scan barcodes on both the bracelet and the medicine container. A back-end computer system then makes sure the medicine is going to the right patient.
The SimplyId team (Lev Raslin, Ioannis Smanis, Lauren Arbetman, and Xining He) have updated and broadened this mechanism to replace specialized bar code scanners with everyday mobile devices. Each bracelet has a unique ID in its Low Energy Bluetooth (BLE) transmitter, and an electronic patient health record can be associated to the bracelet upon patient intake via a hospital’s existing record management system. Because the bracelet is Bluetooth-enabled, it can communicate with consumer devices such as tablets.
Each staff person with the authority to treat patients carries a mobile device requiring a login. Once the clinician logs in, the device can check whether he or she should have access to a patient. The clinician need only linger in close proximity to the appropriate patient, and if authorization is granted, the patient’s information shows up on the tablet. As patients move from room to room or department to department, the right data always accompanies them. A separate encryption key is assigned to each patient.
In this way, patient information can be securely stored on computers in the hospital, and can be viewed by any authorized staff person who approaches the patient. No data except the ID is stored in the bracelet. So when the patient leaves the hospital, the bracelet can be reused simply by assigning a different patient health record.
The SimplyID team intends to market the technology to payers, who can then offer it to health providers as part of their services.
Preventive Health Tools: strengthening the primary clinical intervention
Medical tests follow the “stitch in time” maxim. A huge number of people who die of cancer or stroke could be saved if they got the right test at the right time. Preventive health is an area amenable to programming solutions, too. The Agency for Healthcare Research and Quality (AHRQ) has set up a sophisticated National Guideline Clearinghouse gathering recommendations from all manner of medical organizations. A program could submit relevant information about a patient (age, gender, chronic conditions, and so forth) and return a list of tests the patient should get.
This is what Bryan Bordeaux, a primary care physician, came to the hackathon to accomplish. It was his first hackathon but he came away with a prize and a mandate to develop Preventive Health Tools. Currently, a physician or other staffer must key in the data. Hopefully, future medical systems will be able to interact with the guidelines site automatically through a mechanism such as Blue Button.
Dr. Bordeaux developed this tool to scratch his own itch. Doctors can’t remember when a patient should get a test based on the welter of demographic criteria that go into such a decision. Although the resources required to build the application were modest, his organization could not do it because (as Bordeaux notes wryly) the priorities of the IT department do not focus primarily on improved patient care, and any initiatives they do take on must go through lengthy internal approval processes.
For now, the application is web-based. Eventually, dedicated mobile apps will be designed for patients, health insurers, and other interested parties.