The Biointerfaces Interlaboratory Committees, the student organization for the Biointerfaces Institute at the University of Michigan, organized and executed an 8 hour “BioHackathon” on the broadly defined clinical topic of ‘Aging.’ The event began with experts in the field (a clinician and an engineer) highlighting the areas of greatest need in which engineers could improve the lives of the aging population. Attendees separated into teams based on shared interests in pursuing specific needs, and rapidly developed need statements and solution models to help the elderly. Solutions ranged from a smart toothbrush to help detect pneumonia in early stages, to small clothing pads to help reduce the impact of falls on hip fractures. Based on a follow-up anonymous internet survey, the attendees indicated they enjoyed the event, and would likely attend a similar event in the future. We conclude by reflecting upon the event, and suggest ways in which we could improve the style of the event for future hackathons. Introduction This manuscript documents a hackathon for engineers at any academic level (undergraduate, graduate, post-doctoral, faculty), which focused on identifying areas of need and possible solutions for a presented clinical dilemma. The biohackathon was organized and executed by a student group consisting of graduate and postdoctoral trainees in the Biointerfaces Institute at the University of Michigan (the Biointerfaces Interlaboratory Committees). This was the first hackathon organized by the Biointerfaces Interlaboratory Committees. The goal of the hackathon was to encourage interdisciplinary collaboration to solve biomedical problems. We also examined the utility of a relatively short term (approximately 8 hours) hackathon in discovering a previously unknown area of biomedical research, need statement development, and fast-paced solution design. The student organization designed the hackathon to last 8 hours, encompassing five individual sections of the event to prepare and set up participants for success: outlining the clinical problem, active brainstorming, idea pitching and team forming, need research and need statement development, model solution planning. We selected aging as the clinical dilemma for our inaugural hackathon. We believed aging would be a topic that any attendee would be interested in pursuing, due to the ubiquity of aging to the human experience, the rapid increase in the aging population in the United States, and that aging offers a myriad of needs across multiple scales (e.g. cellular, organ-system, the individual, and societal levels) which engineers could help meet. Furthermore, attendees would have the option to pursue their solutions beyond the 8 hour time limit of the hackathon, due to the wide array of faculty at the University of Michigan whose research could benefit the aging population, and various opportunities in the local Ann Arbor area with which to test their solutions (e.g. assisted living facilities, a University of Michigan-affiliated Osher Lifelong Learning Institute). In this manuscript, we will first describe each main section of the hackathon. Then, we will briefly describe the attendees, the needs they identified, and the solutions they came up with to address their identified needs. Lastly, we will briefly discuss how the attendees received the event, based on an online follow-up survey. Methods Outlining the clinical problem To provide attendees with a background on the current clinical and engineering perspectives on aging, the event started with brief talks from experts in the field of aging: a clinician with experience medically treating the aging population, and an engineer that has studied clinical phenomena which commonly affect aging populations. Dr. Raymond Yung, the Director of the Geriatrics Center and Institute for Gerontology at the University of Michigan, first spoke on his experience treating older patients and the biggest areas of need he has found in his medical practice. Then, Dr. James Ashton-Miller, Research Professor in Mechanical Engineering and Director of the Biomechanics Research Laboratory at the University of Michigan, discussed the types of projects and solutions his research team has studied, and which open scientific questions he believes would benefit greatly from engineering innovations. This included in particular an introduction to the Aging2.0 Grand Challenges in aging, which are: Engagement & Purpose; Financial Wellness; Mobility & Movement; Daily Living & Lifestyle; Caregiving; Care Coordination; Brain Health; and End of Life [1]. Following the experts’ presentations, the attendees took turns asking questions to either clarify aspects of the experts’ experiences, or to further their own understanding of the disease states and personal challenges the experts discussed. Active brainstorming After learning about the clinical problem from the experts, participants broke into small groups of two or three attendees to actively brainstorm. Each small group was given a set of sticky notes to write aspects of the problem on which they were interested in working (e.g. a need they want to work on, a technique they’re interested in using, etc.). Then, they placed the sticky notes on the wall, and the experts and event coordinators reorganized the notes into clusters of notes that shared a similar theme, which allowed participants to gauge how many other participants were interested in a particular idea. Idea and pitching and team forming After active brainstorming, each participant took time to read the other sticky notes, to see others’ ideas on solving problems related to aging. After each participant had time to read others’ notes, each attendee took turns describing which problem they would be most interested in working on. Participants then formed teams based on shared interests. Need research and need statement development After forming teams, the attendees next focused on developing a need statement that clearly articulated the problem they wished to solve. We asked the attendees to be sure their need statements included an outcome to measure success, and an appropriately defined population based on the need. We also reminded them to make sure their need statements did not contain an embedded solution, to ensure their model solution planning would not be biased towards any single solution. During need statement development, the attendees were reminded to conduct basic market analysis and research currently available solutions to the need, to help refine their need statements. Model solution planning After refining their need statements, the teams began planning out the solutions to their needs. We gave purposefully vague requirements for what should constitute an adequate ‘model solution.’ We did not want to preclude teams from pursuing any solution, regardless of whether or not it would be conceivable to prototype in the relatively short 8 hour timeframe of this hackathon. Therefore, we allowed teams to submit nearly anything as a final model solution, ranging from a flow chart of a clinical workflow or a high level description of their solution, to a computer aided design (CAD). Assessing attendee enjoyment of the event We sent a non-mandatory, anonymous follow-up survey via email to each attendee the morning following the hackathon. We sought to gather feedback about how much the attendees enjoyed the event, if they would attend a similar event in the future, and ways we could improve the event. We asked five questions in total: would you attend a similar biohackathon in the future?; how would you rate your enjoyment of the event?; would you rather the event have been shorter or longer?; do you have any suggestions for topics of future hackathons?; do you have specific feedback on this event? The first three questions were multiple choice, while the final two were short answer to allow for specific feedback. Results Attendees We had 21 individuals attend the hackathon. Three faculty members attended the first two and a half hours of the event as experts. Two graduate student members of the Biointerfaces Interlaboratory Committees served as organizers. Sixteen individuals served as attendees to the hackathon, including graduate students from five different engineering departments (Mechanical Engineering, Biomedical Engineering, Macromolecular Science and Engineering, Chemical Engineering, and Electrical Engineering and Computer Science), a post-baccalaureate student, and a faculty member. Name Role Academic position James Ashton-Miller Expert Research Professor of Mechanical Engineering Loubna Baroudi Team 3 Masters student, Mechanical Engineering Barry Belmont Team 1 Lecturer, Biomedical Engineering Natacha Comandante-Lou Team 4 PhD student, Biomedical Engineering Jesus A. Castor-Macias Team 1 Masters student, Biomedical Engineering Kathleen E. Finn Team 2 PhD student, Biomedical Engineering Dorsa Haji Ghaffari Team 2 PhD student, Biomedical Engineering Robert D. Graham Organizer PhD student, Biomedical Engineering Beomseo Koo Team 2 PhD student, Biomedical Engineering Jacqueline Larouche Team 4 PhD student, Biomedical Engineering Benjamin Y. Li Team 4 Incoming MD/PhD student Ying Liu Team 3 PhD student, Macromolecular Science and Engineering Anjali MIttal Team 3 PhD student, Chemical Engineering Zachariah Sperry Organizer PhD student, Biomedical Engineering Shengpu Tang Team 1 Masters student, Electrical Engineering & Computer Science Nathaly Villacis Team 3 Masters student, Mechanical Engineering Megan Weivoda Expert Assistant Professor of Dentistry Raymond Yung Expert Director, Geriatrics Center and Institute of Gerontology Hans Zander Team 2 PhD student, Biomedical Engineering Yingying Zeng Team 3 PhD student, Macromolecular Science and Engineering Muru Zhou Team 4 PhD student, Macromolecular Science and Engineering Table 1 ​ : An alphabetical list of the hackathon attendees, their role in the hackathon (e.g. attendee, expert), and their affiliations at the University of Michigan. Team 1: Jesus Castor-Macias, Shengpu Tang, Barry Belmont Team 1 pursued the problem of medication errors in elderly populations, particularly medication errors associated with taking the incorrect dosage. Their background research indicated that nearly 80 percent of older adults take at least 2 prescription drugs, and that 26 percent of cases of medication errors (e.g. incorrect dosage) cause harm [2]. Therefore, they identified a need to reduce the incidence of adverse effects resulting from incorrect medication dosage in the aged population. Team 1 proposed a pill dispenser that will use a wearable sensor to determine how much medication to dispense. They anticipate the advantages of this solution would be dispensing the correct amount of medication every time to prevent incorrect dosing, and the use of wearable sensors to tune the dosage over time when a patient might not be able to see a physician often enough to titer out medication dosage. They anticipate that one of the drawbacks of this solution model is that it is not fully closed-loop. It is possible that the patients could forget to ask the dispenser to produce their medicine. Identified need ​ : Need a way to reduce incidence of adverse effects of medication due to improper dose in older patients (≥65 years old) with diagnosed cardiovascular disease. Proposed solution ​ : A pill dispenser which dispenses an appropriate dose of medication based on a patient’s physiology as measured by a wearable sensor. Solution model ​ : ● What data do/can we collect using the wearable? What’s the frequency of collection ○ The wearable could/should be a “standard” wearable (e.g., a Fitbit, an Apple Watch, etc.) ○ Perhaps we could even try to garner a consortium of wearable device manufacturers to facilitate use ● How often do we dispense drugs? ○ As often as prescribed and/or until measured hemodynamic parameters are within a certain range of “ideal”/”optimal” physiology (e.g., MAP of 120/80, HR of 70, etc.) ● How do we map physiological data to personalized prescription? ○ Retrospective studies from a few academic research institutions to form the training set ○ Clinical trials to validate trained model, possibly refine algorithms ○ Working closely within the FDA’s new Digital Health Initiative ○ Prospective studies in-house studies on beta-level invited consumer groups (e.g., within a few assisted living communities) ● Do we need additional info about user’s existing disease conditions, other medical history? ○ Ideally, yes, but initially I think rough indicators of health will suffice (e.g., basic comorbidities, height/weight info, etc.) ● What if user forgets to acquire/take the drugs? ○ While the device cannot know whether the person has ingested the drugs, the device should be able to determine whether the drugs have been taken from the receptacle in which they are disposed ○ If drugs remain in the receptacle for “too long”, warning lights should alert the user to their err. Depending on the type of error and overall sophistication of the machine, a user could, for example, push a button that informs them of their next steps. The device could also potentially “recirculate” the drugs if they have not be interacted with and a “dose corrected” amount (compensating for the drugs not taken last time) could be dispensed next time. ■ A possible danger in the latter approach is the possibility the patient took drugs from a source other than the pill dispenser ○ I think this system also has the advantage that, if the patient forgets, then for the next dispense it can detect (through physiological monitoring) and attempt to compensate for that. Team 2: Dorsa Haji Ghaffari, Hans Zander, Beomseo Koo, Kathleen E. Finn Team 2 pursued the problem of lower social health in senior citizens, particularly in their self-worth stemming from their contribution to society. Their background research indicated that one’s sense of purpose in life can have strong effects on mental health [3]. Therefore, they identified a need to increase the sense of contribution to society in the retired population. Team 2 proposed a software the can provide in-home volunteering opportunities for retired persons to teach skills to others, without having to leave their homes. Examples of skills that retired people can teach include language, cooking, reading, and personal skills. They anticipate the advantages of this solution would be accessibility for nearly any senior citizen and teaching and improving the lives of others is an effective method of improving one’s sense of contributing to society. They anticipate that some of the drawbacks of this solution model is that some senior citizens struggle with or become discouraged by some technologies, and that rural areas with poor internet connections may struggle to adopt this technology. Identified need: ​ We need a way to increase the sense of contribution to society in a retired population confined to their home. Proposed solution: ​ A software to provide in-home volunteer opportunities for the retired population to teach identified skills to others, that can be used with existing webcam, microphone, and screen technology. Figure 1 ​ : Team 2’s model solution: a flow chart of how their software would operate. Team 3: Anjali Mittal, Ying Liu, Nathaly Villacis, Yingying Zeng, Loubna Baroudi Team 3 pursued the problem of detecting early-stage pneumonia. Their background research indicated that pneumonia incidence increases with age, and poses significant costs on the United States healthcare system [4]. Therefore, they identified a need to detect pneumonia at stage one in nursing home residents to mitigate the spread of disease. Team 3 proposed a smart toothbrush head which can detect bacteria present in saliva, coupled with a handle that can measure pulse rate and blood oxygen saturation level. They anticipate the advantages of this solution would be daily monitoring of one’s bacterial health, and the familiarity of a toothbrush would likely improve patient compliance. They anticipate that some of the drawbacks of this solution model is that some senior citizens might not brush their teeth frequently, and that some forms of pneumonia are not caused by bacteria. Identified need: ​ Need a way to detect pneumonia at stage one in nursing home residents to mitigate the spread of the disease among residents. Proposed solution: ​ A wifi-enabled smart toothbrush head to collect saliva and get oral bacterial count, toothbrush handle to measure pulse rate, and blood oxygen saturation level. Figure 2 ​ : Team 3’s model solution: a CAD model (left) and functionality flowchart (right) of their smart toothbrush Team 4: Benjamin Li, Jacqueline Larouche, Muru Zhou, Natacha Comandante-Lou Team 4 pursued the problem of fall-induced hip fractures in the elderly. Their background research indicated that hip fractures are associated with excess all-cause mortality for both men and women [5]. Therefore, they identified a need to reduce the number of hip fractures due to falling in senior citizens. Team 4 proposed a novel pad comprised of non-newtonian impact hardening material, which would absorb much of the force generated by a fall. They anticipate the advantages of this solution would be a lightweight non-obtrusive device that would encourage patient compliance, and a low projected cost. They anticipate that one of the drawbacks of this solution model is that there would still be a chance of injury though the majority of the force from falling would be mitigated. Identified need: ​ Reduce the number of hip fractures due to falling in individuals over 65 years old in the United States. Proposed Solution: ​ Pads composed of impact hardening material, such as D3O or shear-thickening fluid, that cover an individual’s hips such that if that individual falls, the material hardens and absorbs the majority of the shock to prevent hip fracture. Said pads will be thin and fit into pockets sewn onto insides of pants or underwear. Figure 3 ​ : Team 4’s model solution: a schematic of their proposed hip-protecting pads. Attendee feedback on the event We sent out an email follow-up survey the morning following the event. Of the 16 attendees, 6 filled out the survey for a success rate of approximately 38 percent. All 6 responders (100%) marked that they would attend a similar hackathon in the future. All 6 responders (100%) marked “I liked it,” in response to “How would you rate your enjoyment of the event.” One responder (16%) marked that they would prefer a shorter hackathon (2-3 hours in total duration). One responder marked that they would have preferred a longer hackathon (12-24 hours in total duration). One responder marked that they would have preferred a much longer hackathon (24 hours or more in total duration with weekly or monthly follow-ups with each team). One responder suggested Scoliosis as a possible topic for future hackathons. Three responders provided specific feedback about the event. Specific feedback included more specific direction about the process of making a clear and concise need statement, which aspects of background market research are required, and shifting the time window of the event from 12:00 pm to 8:00 pm to 9:00 am to 5:00 pm. Discussion Identified needs and proposed solutions Each team developed a clear and concise need statement accurately synthesizing a problem facing the aging population. Interestingly, each team identified needs affecting different aspects of the older population (e.g. social health, hip fractures). Each team appeared to capitalize on the expertise of its members in selecting an approach with which to tackle the problem of aging. All of the identified needs could be traced back to one or more of the areas of need outlined by the experts’ presentations at the beginning of the hackathon. This suggests to the organizers that beginning the hackathon with presentations from experts in the field is an effective way to catalyze excitement for the topic, but also helps ensure that the teams all select projects which, if fulfilled, would provide tangible benefit to the target population. Based on the relatively short duration of the hackathon, the organizers did not expect any team to develop a working prototype over only 8 hours, which led to our vague definition of what constituted a ‘solution model.’ The final models ranged in type from a written description to operational flow-charts to illustrations and CAD models. However, we were very pleased with the thought and effort each team put in to designing their solution models. All participants have agreed that this manuscript represents a public disclosure of their solution models for intellectual property (IP) purposes, and do not wish to pursue the solutions to market at this time. Participants were given the option of withholding any of their work from publication to pursue IP protection, but none chose to do so. This could be considered a weakness of the event, as it did not directly generate a means to bring clinical solutions to market. Based on anecdotal evidence from other hackathons, however, the number of solutions actually brought to market from these events tends to be small. By publicly documenting the hackathon and generated solutions, we feel that the event has a greater potential impact on the community. We are also confident that any innovator wishing to build on the proposed solutions in the future, including any of the participants, would likely generate additional IP for protection of a final product. Attendees perception of the event Based on the results of an anonymous survey, the attendees seemed to enjoy the hackathon, and would likely attend a similar event in the future. One of the aspects that the organizers were conscientious of when planning the hackathon was the duration of the event. Ultimately, we decided that the event would last 8 hours so it would more easily fit into a typical work day. Based on survey results, some attendees would like to attend a longer hackathon of a similar format. A longer hackathon would give more opportunity for solution design refinement, and possibly prototyping. However, we wondered during planning whether or not a 12 hour or longer hackathon would dissuade some graduate students from attending, based on their already busy schedules. One responder indicated they would be interested in a shorter hackathon, on the order of 2 to 3 hours. However, one of the features of this hackathon that we believe to be a strength was involving faculty experts in the field. A shorter hackathon would require much shorter presentations from faculty, which could prevent attendees from understanding the full spectrum of need areas of the presented problems. On the other hand, it could be possible to have a series of ‘mini-hackathons,’ where the hackathon would take place during one 2 to 3 hour event every week. This would be more difficult from an organizational perspective, but pursuing projects over a longer period of time could increase the likelihood that teams would pursue commercialization of their solution models. It would also allow time for the creation and iteration of 3D printed physical solution models. One attendee recommended ‘Scoliosis’ as a possible topic for future hackathons, while other recommendations range from ‘mental health’ to ‘cancer.’ Strategies to improve future hackathons The overall positive response to the hackathon suggests to the organizers that it could be a good candidate for a recurring event (e.g. one per semester, or one per academic year). However, there are several areas we believe we could improve to increase the quality of the experience for the attendees. One area would be in the advertising of the event. Using the word ‘hackathon’ to describe the rapid need-finding and ideation that this event entailed could have been a misnomer. Some attendees indicated that ‘hackathon’ made them expect more of a software focus for the event. Therefore, when advertising future events, we will consider using other phrases such as ‘design expo’ or ‘idea incubator,’ and to include a detailed description of the design and schedule of the event. We had initially planned to include a patient or patient advocate in the group of ‘experts,’ but we were unable to find a representative in time. A future event should include input and perspectives from the target population to improve the final solution models. Additionally, since scientific manuscripts are not a particularly accessible means of communicating with the general public (including the target population), a future hackathon should include an effort to communicate discovered needs and solution models with short video ‘pitches’ to be dispersed on a publicly accessible website. We believe that the event could further be improved by a more detailed description of need statement development at the beginning of the event. For this first iteration of the hackathon, we gave a brief description of what a need statement is, and some examples of good and bad need statements. In the future, we believe it is a good idea to go into more detail about developing a need statement, and how background and market research can be used as a tool to better refine need statements in order to best set up solution models. We believe giving more specific direction with regards to performing market research at the beginning of the event would be an effective way to expedite need statement development, and potentially improve the overall quality of need statements. For this event, we only required each team to submit one need statement and a model solution. In future events, we may add in additional requirements centered around the market for their solutions (e.g. market size, annual costs, etc.). Additionally, while each team performed extensive research to inform their solution model, there was little effort to organize or report the sources that helped shape their final solutions. A future hackathon report should include these sources either directly as