Projects, designs, and writings on health IT

2014-09-28

Connexus: Mobile clinical data display

8:05 PM Posted by David, MD No comments


I helped design the Connexus App at the Hospital of the University of Pennsylvania as a member of the Design Team. Connexus is a data visualization app for healthcare providers to access patient data, now deployed to thousands of nurses and doctors at the hospital. The goal was to aggregate data from multiple clinical information systems to give providers a comprehensive overview of a patient when on call.

Designers

S. Airan-Javia, D. Leri, E. Gitelman, me

Problems With Existing Apps

The existing clinical app was difficult to use because it was designed around the data rather than the user--the nested tree structure required too many taps to get to the data.

In order to see an MRI, the user needed to 1) type a PIN, 2) search the patient by name, 3) tap “Radiology”, 4) tap “MRI”, and 5) finally see the result. It was reasonably useful for finding a single result for a single patient, but it failed to facilitate the tasks that providers would need to use it for:
  • Admitting – when a provider does not yet know about a patient and needs to look up all labs, imaging, vitals, and notes. Doing this on the prior app required the user to click through many categories of data, making it less feasible.
  • Covering – when a provider is taking care of fifty patients, he/she cannot afford to click through each patient. He/she needs a live feed of all the lab results as they are reported.
  • On call - when a provider is called to the bedside for an unfamiliar patient, he/she needs a 30-second comprehensive overview of high-yield data, including vital sign trends, and microbiology data.
  • Rounding – when a team is discussing the medical plan for a patient, providers need many quick data lookups to assist in decision-making.

The Design Process


We focused our design on the user stories listed above. On a white board, we drew one view at a time based on our stories. This approach helped us build a minimum viable product (MVP). This app was built on a few design principles for usability.
  • Design for mobile first -- designing for a phone screen forced us to simplify views
  • Minimize page-flipping -- to avoid a major pitfall with EMRs
  • Display data succinctly -- e.g. for medications, use SubQ, BID, and other accepted abbreviations (see figure below)
  • Search fields rather than categories -- Google employs this idea in many of its products including Gmail
  • Convention over customization – medical software companies often sell customizable views in place of user-centered design but we wanted to build a product suitable for 80% of use cases.

The Final Product


Using these design principles and a minimalistic approach, we piloted and launched the app, which is now widely used in the hospital. This was the first app at the hospital that was designed and built with the collaboration of clinicians and IT specialists, a formula that will be important for designing secure but usable apps in the future.

2014-09-22

The Political Economy of Hackathons

3:36 PM Posted by David, MD 1 comment
This post originally appeared in The Health Care Blog


Two thousand hackers from 50 universities around the world came to the University of Pennsylvania last weekend, where they were fed, housed, given toothbrushes, Red Bull drinks, and proceeded to create the most innovative and creative software and hardware hacks to date. The event was PennApps, the nation’s largest and longest-running collegiate hackathon. In 48 sleepless hours, people built new ways to interact with iPhones, smart watches, and flying drones. Microsoft and Google were recruiting engineers. Intel even released a new electronics board for the event.
This event was also the debut of PennApps Health, which will hopefully be a part of this event from now on. The turnout was impressive. Epic Systems, Independence Blue Cross, and Mainline Health each presented specific healthcare challenges and rewards. Their presence motivated at least 35 teams to compete in health challenges. Here are the main takeaways from this event:
1. Healthcare hacking is less sexy than device hacking
At open-ended hackathons, the “popular” crowd usually pursues high tech hacks e.g. virtual reality and other cutting edge devices. One group, for example, wired up a motorized skateboard so it could be controlled wirelessly with gestures. Another group created a Google Glass app for the blind that recognized, and spoke aloud, the names of objects in front of the wearer.

Healthcare, on the other hand, is less amenable to this style of hacking. There are many reasons for this, including the fact that data are proprietary, patients don’t want to pay for health, and hospitals are still trying to solve very basic needs. My hospital, for example, is currently trying to solve two-way text messaging and automated schedule creation. The problems we face in health care fail to draw innovate designers and developers to the field.
2. More providers need to be involved 
One of the attention-grabbing apps was Scolio, an iPad app that screens for scoliosis based on shoulder and hip angulation using a front-on photo and the iPad’s built-in level. Nevermind that the USPTF recommends against routine adolescent screening for idiopathic scoliosis because it causes more harm than benefit. And nevermind that the decreased sensitivity from analyzing a photo compared to a scoliometer would only exaggerate the over-diagnosis.
Apps like these need physician guidance in order to find the appropriate problem, before they will ever see adoption in healthcare, and event before physicians will be willing to recommend them to their patients.
These hackathons have a substantial way to go before they produce commercializable products and spinoff companies. Part of the impetus is that healthcare entities are cautious—often unwilling to face inevitable challenges in security, software support, and liability. That is why we need to attract top engineering and design talent at events like these. Healthcare providers, need to identify the problems and guide them in the right direction.
David Do, MD is a physician at the Hospital of the University of Pennsylvania and CTO of symcat.com.

2014-09-21

Fit For Care: the impact of social networking on exercise.

I started a program at The Johns Hopkins School of Medicine with several other classmates to evaluate the impact of social networking on exercise. The project included building a social networking website where users could log in weekly to update the number of minutes they exercised. We obtained IRB approval and enrolled 160 medical students in the study. We published our results in Southern Medical Journal.

Impact of a Fitness Intervention on Medical Students
Amanda Morris, MD, David Do, BS, Rachel Gottlieb-Smith, BS, Julie Ng, BS, Amit Jain, MD, Scott Wright, MD, Robert Shochet, MD
South Med J. 2012 Dec;105(12):630-4

Source Code

Available upon request

Specific Challenges

  • Provide a frictionless interface where users could log in to track the number of minutes they exercised each day
  • Allow users to self-assign teams and see the progress of their teammates
  • Allow users to visualize the progress of their own teams compared to other teams.
  • Share nutritional tips

Technologies

Ruby on Rails

Publications

http://sma.org/southern-medical-journal/abstract/2012/1200/impact-of-a-fitness-intervention-on-medical-students/

2014-09-16

Smart Watch Assistant for the Elderly

9:57 PM Posted by David, MD , No comments
Project for Penn Apps X Hackathon 9/12-9/14/2014

This project is open source

Dashboard (Web App): https://github.com/davehdo/felldown
Pebble Source Code (C): https://github.com/Abhipray/HelpiFell
Collaborators: Abhi S (Rice), Lily W (Rice), Jen C (UT), Yevgeniy G

Introduction

We built a "Safety Alert" watch for the elderly. In addition to a "panic" button, however, we utilized the smart watch sensors and user interactions to track metrics that give doctors and caregivers more insight into the unseen. While there are plenty of health tracking devices and apps available, I wanted to target neglected metrics that are more relevant to clinical decision-making than, say, steps. 

For example:
  • falls
  • missed medications
  • hours of sleep
  • daily weights (for people with failure to thrive or heart failure)

The elderly often have falls at home due to poor vision, diminished sensation in the feet, and slow reaction time. These falls can go unnoticed but the number of falls an elderly person has at home can make them at higher or lower risk for intracranial bleeds, especially when taking a blood-thinning medication. 

Falls in the elderly are a huge cause of morbidity, costing $30 billion/yr. Falls lead to intracranial bleeds and broken bones. Hip fractures in particular have morbidity. One in five hip fracture patients over 65 die within 1 year of injury (http://www.cdc.gov/homeandrecreationalsafety/falls/fallcost.html).

The Solution

A Smart Watch that detects falls, alerts family members, and gives a live view through a web dashboard. The dashboard highlights several key metrics for doctors. This watch is designed for users over age 65 who live alone or spend part of the day unsupervised. Additionally, family members can track the events in a dashboard.

Technologies Used

Pebble Watch, C, Ruby on Rails 4, Twilio API, Sendgrid API




2014-09-02

Guide to Hacking the Healthcare System

9:31 PM Posted by David, MD No comments
By DAVID DO, MD AND CRAIG MONSEN, MD

Originally appeared in The Health Care Blog on 2014-07-30

We are residents and a software developers. Before starting residency, we spent time as software developers in the startup community. We were witness to tremendous enthusiasm directed at solving problems and engaging people in their health. The number of startups trying to disrupt healthcare using data and technology has grown dramatically and every day established healthcare companies appear eager to feed this frenzy through App and Design Competitions.

When we started residency, the restrictiveness of data and reliance on decades-old technology was grossly apparent. Culturally, hospitals are an environment of budgets and deadlines that are better suited towards maintaining the status quo than promoting the creative process. Hospital IT departments harbor a deep cover-your-rear-end mentality and are incentivized for two things: first, keep systems running, and second, prevent security breaches. Perhaps rightly so–privacy and security need to be prioritized–but this environment has delayed them from facing the inevitable challenges of effectively using their own data and investing in new tools, including ones that could improve the triple aim of greater quality care with greater patient satisfaction and lower cost.

In the future, as hospitals and health systems become more accountable for the long term outcome of patients, we are optimistic that they will innovate as much out of cost-cutting necessity as for providing a better product to patients. We have little evidence that established players can power innovation solely on their own engines and expect many of the solutions will come from problem-solvers outside medicine. Doctors and patients will choose from an arsenal of apps to interact with the health information in EMRs. These healthcare apps come in three major categories: education, workflow, and decision support.

Patient Education Apps
Patients are the most underutilized resource in health care. After a hospital visit, discharge summaries and medication lists that we send patients home are entirely disconnected from the tremendous amount of educational health material available to them for free on the Internet. Many patients are discharged from a hospital with more than ten medications, and rarely will they begin the instruction necessary to fully understand the indications and dosing instructions for each. Imagine sending a patient home with a smart medication list that reminds them when to take each medication, along with a description of why its beneficial. Discharges are just one opportunity where patient education can be improved and there are just as many efforts to improve education during outpatient visits and even before patients see the doctor in the first place.
The promise: Better patient education results in better patient engagement, compliance, and less ineffective care
Existing apps and services: iTriage (symptom-checking), Aircare (post-discharge continuing education), Emmi Solutions (procedure informed consent)
Data sets available for developers: Visible Human Project API, Pillbox API, Medline Plus, to name a few
Data sets not yet available: Individualized patient history and medication lists
Prior app Competitions: Health Design Challenge (http://healthdesignchallenge.com/), RWJF Aligning Forces for Quality App Challenge, Cigna Innovation App Challenge.

Workflow Apps
Hospitals pay tens of thousands of dollars for data-management applications that do a fraction of what Google Docs, for example, can do. There are many areas in the hospital for which niche software can make a huge impact, many of which are basic data-management or communication applications that allow collaboration and are HIPAA-compliant. Another area is in data visualization; current off-the-shelf EMRs organize data vertically (by the way they were collected, e.g. labs, radiology, nursing flowsheets, vital signs, etc). To make accurate medical decisions, doctors need to view data horizontally (e.g. to make a decision about fluid status, providers need to see elements from all over the categories above), which is challenging in the current systems. EMRs have been engaged to solve the health care enterprise concerns: security, billing, and data persistence, often at the cost of clinician efficiency. The backlash is already apparent and there will be a growing opportunity to use technology to make care delivery more efficient.
The promise: With better workflow tools and data visualization, physicians spend less time with technology and more time with patients.
Existing apps and services: Cureatr (provider-provider text messaging), Aidin (one-click discharge planning), Box (HIPAA-compliant cloud storage)
Data sets available for developers: N/A
Data sets not yet available: specific to the project
App Competitions: none

Decision Support Apps
Hospitals and health systems collect tremendous amounts of data from patients including vital signs, laboratory results, and imaging. The sheer volume of data prevent providers from integrating everything to make optimal decisions. Decision support often takes the form of using data from many patients to predict the needs of an individual patient. For example, when a patient develops sepsis or requires intubation, retrospective analysis often reveals clues of impending deterioration. Predictive analytics could help detect these conditions earlier and warn providers. Similarly, apps synthesizing hospital-wide microbiology data in real-time could help providers choose effective antibiotics earlier.
The bottom line: Using technology to synthesize large amounts of data can lead to better patient outcomes and safety
Existing apps and services: there are numerous publications on medication dosage-checking, Lockheed Martin is piloting sepsis-detection at several institutions, Explorys does population management
Data sets available for developers: Medicare claims data, HCUP
Data sets we need access to: ICU data sets (exist, but are generally for closed research)
App Competitions: Heritage Health Prize

David Do, MD is a resident at the Hospital of the University of Pennsylvania. Craig Monsen, MD is a resident at the Brigham and Womens Hospital. They are agile software developers and founding members of Symcat.com.

Framework for ICU Dashboards

8:50 PM Posted by David, MD , No comments
A project at the Hospital of the University of Pennsylvania

Given the multitude of monitors and ventilators in the ICU, doctors inevitably face a Data Overload problem. These are the sickest patients in the hospital, and clinical decisions often need to be made quickly. Barry Fuchs, the director of the MICU at Hospital of the University of Pennsylvania, asked me to design a dashboard. As he describes it, there should be a series of comprehensive views for each organ system. The Infectious Disease view, for example, should contain precisely the information an infectious disease consultant would use to decide what antibiotics to use. There would be views for a patients cardiopulmonary, hematologic, and neurologic statuses as well.

This problem elucidates a fundamental flaw of EMRs--an organizational scheme carried over from the days when everything was on paper. Even in electronic form, data are often organized the way they were collected rather than the way they will be interpreted, imposing a severe limitation on clinical decision-making. My preliminary designs are below.













Maslow’s Hierarchy of Health IT

4:49 PM Posted by David, MD No comments
Reblogged from http://thehealthcareblog.com/blog/2014/07/03/maslows-hierarchy-of-health-it/

Maslow’s Hierarchy of Health IT
By DAVID DO, MD



EMR adoption is skyrocketing, in no small part due to government incentives. The office of the national coordinator lauds this hockey-stick curve as a success. Advocates promise electronic records will improve patient care, reduce mistakes, and save healthcare costs. At the same time, doctors love to complain about implementation cost and poor usability. How can we reconcile these differing opinions? The truth is they are describing very different technologies. EMRs, the way they are implemented now, will not accomplish these goals. In fact, early adopters can become stuck at a rudimentary level of functionality, and the extensive feature lists described by meaningful use criteria fail to address the most basic needs for patient care.

I have been at medical institutions at different levels of technological development. Each has a different attitude toward the EMR; for some its loathing, others longing. Some devote resources to try to improve it, but others give up. I realized the parallels with Maslow’s Hierarchy of Needs, people are motivated to attain something only after their very basic needs have been fulfilled. So are EMRs good or bad? Well, it depends on where you are on the hierarchy.

The figure above describes the steps to building a technology infrastructure that will lead to improved patient care. Yes, incentives help us achieve some very basic needs, but the problem is that decisions and investments we make now will determine the ceiling as well.

Step 0. Paper Charts
Explanation: We’ve heard the horror stories of interpreting handwritten notes and the errors that occur with handwritten medication orders.

Step 1. Make it digital
Explanation: The conversion from paper to digital charts involves electronic charting, order entry and documentation. The major advantage is accessibility.
An analogy: Research used to be done at the library with volumes of journals. Now we can search Pubmed and Wikipedia.
Are we there yet? Yes. All EMRs, by definition, offer this, and the majority of Meaningful Use Measures define digitization of different types of data. But you don’t need a commercial EMR to accomplish this—the most basic setup would be a series of Word documents on a shared hard drive (which many departments still use)

Step 2. Make it aggregate data (dashboard)
Explanation: Before this level, the data exist electronically, but are still organized in a way that mimics the paper chart. Here, data are displayed in dashboards, organized by usage (e.g. admitting, covering, discharging, etc) or thought process (e.g. hemodynamics, infectious, etc) rather than how they were collected.
Are we there yet? Not quite. Commercial EMRs have “custom views” that are cumbersome and limited. Microsoft Amalga, or homegrown solutions like the SMART platform at Harvard and MedView at Penn sift through EMR databases to retrieve and aggregate data (bypassing the commercial EMRs) to enable custom views.

Step 3: Make it communicate
Explanation: Doctors commonly request that their systems should “talk to each other” for better usability (e.g. single sign-on, pre-populating forms)(). Perhaps more importantly, poor exchange of data hinders new apps for quality improvement (Provider error prevention: online total parenteral nutrition calculator. Lehmann et al, Proc AMIA Symp. 2002:435-9).
Analogy: e-commerce websites can extract payment from Paypal, so users do not need to enter credit card information repeatedly.
Are we there yet? No. Meaningful use describes e-prescribing and secure messaging, but communication between applications is lacking (and therefore the capacity to build apps is too). The standards for data exchange exist (e.g. RESTful APIs), but EMRs are more interested in keeping data in a silo.

Step 4: Make it synthesize data
Explanation  Existing EMRs flag lab values in a rudimentary way, using absolute thresholds. This leads to alert fatigue and misses the big picture. Instead, alerts can be more sensitive and specific by the following methods:
- using trends: a rising White Blood Cell count is more informative than the actual level. A low platelet count is less significant if it has been at this level for a long time.
- personalizing: hemoglobin ranges differ by gender, and creatinine differs by age
- using multiple variables: disseminated intravascular coagulation is often detected by hemoglobin, platelets, fibrinogen, and several other lab values
Analogy: Your bank tells you when there is suspicious activity.
Are we there yet? No. Meaningful use specifies simple decision rules, medication interactions, and patient reminders (for preventive health and followups). No EMR, however, utilizes trends in data, and some have argued they have no reason to .

Step 5: Make it predict
Explanation: If I knew my patient was going to get intubated or get started on antibiotics tomorrow, I might give him diuretics or start antibiotics today. Often in retrospect we see signs that should have alerted us to impending deterioration.
Are we there yet? No commercial EMR offers prediction, and they way they are structured actually inhibit development of these tools, using math models or machine learning because data are sequestered. There are implementations at my institution that alert for sepsis, acute lung injury, and acute kidney injury when certain lab and vital sign criteria are met, but there’s no platform to make this process scalable. Some companies are attempting to apply machine learning

Step 6: Self-actualization
Explanation: This is the point at which my EMR has become a collection of tools that enable my job as a doctor. Here we realize the promises of improved safety, outcomes, and costs.
Are we there yet? Perhaps one day

Rolodoc: a dynamic consultation directory for hospitals

4:40 PM Posted by David, MD , , 1 comment
Notes on a project I started at the Hospital of the University of Pennsylvania, now being used by providers in all departments.

The Problem

The hospital paging system was decades obsolete. In order to contact the on-call person for any specialty service, one had to dial the operator, wait on the telephone, and eventually be forwarded to a number, which was often the wrong one. (Not to mention they were still using beepers.) One had to go through this process several times throughout the day.

The Solution

Design a mobile app that contained a list of the people on call, and updated daily, allowing people to make calls directly from the app.

The project included a schedule API that would serve the calendars for all the services.
  • Tranquilapi (source code available upon request, still need to abstract away some hardcoded passwords)

And the app itself, which was a mobile-friendly website that used the API
  • Pennrolodoc.com (source code available upon request)

This system was quickly adopted without much publicity and is now used by all physicians in the hospital

Specific Challenges

  • Gathering many disparate schedules and scraping the data from different systems (COAST, Amion, Webexchange)
  • Ensuring the data are secure by whitelisting the IP addresses used by the hospital, and using logins for users outside this wall
  • Allowing people to override the schedule if it was incorrect
  • Accounting for missing data (some schedules would only list people on the very first day of their 2-week blocks, implying they were on the entire week)
  •  Making the app feel fast despite relying on remote data (using backbone.js framework to generate pages client-side, using jQuery mobile for a better mobile experience)
  • Getting backbone.js to play nicely with jQuery mobile (a non-trivial task given they both want to handle hash routing)
  • Being compatible with IE7 (which hospital computers use)

Technologies


Ruby on Rails, Javascript, jQuery mobile, backbone.js, devise for authentication




Usage Statistics

3/2015 Update: 5605 usages per week (Mar 8-14 2015)
1/2016 Update: Over the past 12 months, we have continued to grow
78,653 calls placed directly from the app (215 per day)
40,182 text pages sent direction from the app (110 per day)
747,961 pageviews across 198,016 unique devices (2,049 pageviews across 543 unique devices per day)







10/2017 Update

We're still seeing growth after year 4