This post on my nutrition project using the Board Rounds app appeared on the Penn Medicine blog 12/21/2016.

Harnessing Big Data to Count Calories in the ICU

December 21, 2016

 | by Johanna Harvey

Feeling hungry is a signal from our bodies to our brains that we need fuel to be healthy. But some patients in the intensive care unit (ICU) with traumatic brain injuries or other complications are not able to express or even sense hunger. Often, these patients are connected to tubes that deliver enteral nutrition (EN), a liquid formulation of nutrients delivered to the GI tract.

EN has been shown to have a positive impact on the recovery process, from reducing infections to shortening the length of hospital stays to promoting faster cognitive recovery. But, EN is only beneficial if patients are receiving enough nutrients to counterbalance their energy expenditure – even immobile patients burn calories through normal biological functions like breathing and thinking. However, the average patient only receives about 50 percent of their daily calorie needs, meaning that many patients in the ICU are at risk for malnutrition.  That’s where David Do, MD, a software developer and Neurology resident at Penn, and his fellow researchers come in—they are working on software that will make it easier to track a patient’s nutritional needs and make sure they are getting enough daily calories to help them recover properly.

I sat down with Do to ask him a few questions about the software he is developing and how it will help patients.

Q: Why is nutrition so important for ICU patients?

A: Nutrition is actually a really important part of the recovery process for anyone who is sick. Think about it: even with the common cold, general treatment advice is to rest up and get plenty of food and fluids to help you heal. This is even more important for people who are critically ill and/or in the ICU. 

Patients who are underfed have a higher risk for muscular breakdown and have more trouble fighting off infections. Most of my patients in the Neurointensive Care Unit are in the hospital for a week or longer and in that time it's possible for serious nutrient deficiencies to occur that could ultimately impact the recovery process.

Q:  Why are some ICU patients under-nourished?

A: Normally, our bodies tell us when and how much we need to eat through our sense of hunger. But patients with brain injuries, swallowing malfunctions, or who are on ventilators, can’t tell us when they feel hungry. Instead, they have to rely on clinicians to deliver the right amount of nutrients through feeding tubes.

Q: What challenges to do care teams face when trying to ensure patients receive proper nourishment?

A: Critically ill patients have really complicated medical problems and care teams are often focused on these pressing issues. Unfortunately, sometimes this means that nutrition can fall to the bottom of the list of needs. To make things more complicated, each patient has different needs, meaning they need customized nutrition plans that often require complex calculations. Getting the nutrition levels correct can be challenging for clinicians who are balancing many complicated care needs for several patients. That’s why we created our Enteral Nutrition Calorimeter software—to make it easier for care providers to give patients the nutrients they need to support the recovery process.

Q: How does the software work?

A: This project is really about how we can leverage data that we already have through electronic medical records (EMR) to improve care. In the Calorimeter project, we designed custom monitoring software that tallies the patient’s intake and, based on the nutritional content of the feed, determines how many calories and grams of protein the patient has received. We then estimate each patient’s energy expenditure to determine who received enough. We use this data to provide constant feedback to clinicians by sending automated secure messages to the right person at the right time.

Q: What results have you seen so far?

A: Right now, we are going through the design phase. Our early investigations have helped us map out the obstacles to feeding. We even tried placing a clinician on daily rounds who was dedicated to optimizing nutrition, which improved feeding rates dramatically. While the extra attention may not be sustainable or scalable, we identified several barriers that are addressable through automated methods. We are working on crafting and testing messages to see what makes clinicians respond the most.  

Q: As a resident, how you were supported by Penn faculty to move this project forward?

A: The Neurology faculty have been tremendously supportive of this project, especially the Neurointensive Care faculty who were eager to help design and adopt our solution in their unit. Penn Medicine has become a great environment for interdisciplinary collaborations and innovations, especially for residents. Since I first arrived at Penn more than three and half years ago, I’ve seen a tremendous investment in infrastructure and technology that now allows us to rapidly build and test tech-enabled interventions and applications that will improve patient care. 

Do and his fellow researchers were recently awarded funding for their project through Penn’s Innovation Accelerator Program. Now in its fourth year, the Innovation Accelerator Program from the Penn Medicine Center for Health Care Innovation supports promising ideas from faculty and staff across departments and roles at the University of Pennsylvania Health System in their efforts to develop, test, and implement new approaches to care. This year’s program is co-sponsored by UnitedHealthcare.

The research team includes John Chandler, MD, Neurocritical Care Physician; Joshua Vanderwerf, MD, Neurology Resident; Jennifer McKenna, CNSS, Clinical Dietitian Specialist; Bethany Young, RN, Clinical Nurse Specialist; Susan Kennedy, CNSS, Clinical Dietitian Specialist; Kai Holder, Research Assistant; Davis Hermann, Design Strategist, and Diane Dao, Innovation Intern

Read More

Simple problem list

Introduction

Tools for physician workflow (e.g. "signout" and "handoff" applications) often neglect the fact that actionable items are tightly associated with plans and problems. Here I designed a Problem List app where problems are identified for billing and other purposes, and items with square brackets are interpreted as checklist items. Using a simple markdown language prevents users from having to update information in two places.

This project is open source: https://github.com/davehdo/simple-problem-list 

Features

• a simple markdown language with two-way binding produces interactive checklists that automatically convert [] to [x] and vice versa
• client side framework gives a seamless experience without pauses for loading

Future directions

• version control and conflict management for multiple users
• allow users to assign ICD codes to problems using autocomplete

Technologies

• Backbone.js 
• Twitter Bootstrap

Below is the user interface for entering the plan in free text. 

After saving, problems are considered separately and actionable items are pulled to the checklist on the side.

After plans are set for the day, actionable items can be seen and checked off from a list view.

Read More

Clinical visualizations - Antiobiotic grid

Physicians need to be able to understand the history of antibiotics given in order to make decisions about broadening antibiotics, narrowing antibiotics, and administering the correct duration of therapy. The standard EMR's medication administration record is not optimized for these needs (Figure 1).

Figure 1: EMR's medication administration record

Problems of the current visual display include

1. Difficult to tell at a glance what antibiotics a patient is currently on
2. Difficult to tell how long a patient has been on antibiotics for
3. The need to scroll
4. Visual sparseness

The first step in our redesign is to use a filter to select the antimicrobials. The second is to reduce the visual sparseness of the grid by grouping by day (Figure 2).

Figure 2

While this view is cleaner than the original, we lost some information about sequence due to grouping--for example, it's not clear what the dose progression of vancomycin has been. To fix this problem, we can create multiple time bins daily, experimenting with three daily time bins (Figure 3) and four daily time bins (Figure 4).

Figure 3: Grouping by up to three time bins daily

Figure 4: Grouping by up to four time bins daily

For the purpose of conveying antibiotic history, three time bins seems to have the best balance of chronology while limiting sparseness. Finally, for visual simplicity, we remove gridlines and lightly shade every other day (Figure 5).

Figure 5: Final design for an antibiotic grid to help make management decisions

Read More

Hospital census tracking

Problem
Patient census in the hospital is dynamic--patients are seen by many different teams throughout their stay, and these interactions can be difficult to track. Time of admission and time of discharge do not tell the entire story. Accurate census data is important in order to staff services appropriately.

Solution
We used "service lists" from our EMR in order to infer when patients were being seen. These service lists are maintained by providers and includes lists of patients for consult teams and primary teams. They are accessible in real time through an API run by our IS Department and an archive of these lists is stored by our Data Science Department. We used these data to trend the number of consults and admissions over time, with no added work or manual entry.

Credit
Visualization and design: David Do
Back end: Eugene Gitelman
Data Science Department: Corey Chivers and others
IS Team

Read More

Designing Better Clinical Views

Designers: David Do, Eugene Gitelman, Ian Oppenheim, Jason Maley, and Barry Fuchs

The dashboard concept has been around for a long time, but dashboards still see limited adoption in medicine. Why is that so? How can we be different? By thinking about dashboards firstly through the provider’s eyes, and secondly as a platform, we address several key barriers to adoption:

• Simplicity – in these examples, we allowed ourselves to be inspired by paper notes and diagrams that doctors use. We plot data on trendlines and we can put data side-by-side to examine the interplay of assessments and interventions.
• Designability – A straightforward interface lets providers design and share dashboards. The respiratory dashboard is not only informative but also instructive, training users to dichotomize “oxygenation” and “ventilation”. Other specialists in the hospital may have analogous lessons.
• Tweakability – as we learned in the Carealign process, not all data are of equal importance. The most time consuming part of construction happens after the design, finding the right study names, filtering and “massaging” data (e.g. formatting to fit the fishbones). This dashboard platform lets users make instantaneous adjustments.

Figure 1: Respiratory view is informative and instructive, helping users think about ventilator settings in terms of “Oxygenation” v “Ventilation”.

Figure 2: Each view is designed to answer a particular question. The ID view should contain all the data that an infectious disease specialist uses in order to make an antibiotic decision.

Figure 3: A quick glance at the Quality Indicators view shows patients with foley catheters or indwelling lines

Figure 4: Users can become designers by defining their own views, choosing the types of data to be displayed in each panel

Figure 5: Diabetes views

Read More

Agent - EMR data straight to your phone

Introduction

Agent is a project I am leading at the Hospital of the University of Pennsylvania. Healthcare providers who directly interact with patients can use this app to receive up-to-the-minute results through Push Notifications. 

Aside from streamlining workflow, the Agent platform offers the ability to improve care by delivering targeted notifications based on data. Interventions that would have previously required extensive IT resources to build can now be implemented and tested in a week's time.

Examples of how this can be applied:

• Antibiotics medications often expire without provider awareness, leading to missed doses. Agent alerts providers when it's time to renew a medication.
• Previously there was no automated notification for when patients arrive on the floor. Agent ensure providers are aware so patients can be seen immediately.

The possibilities are limitless. The goal of Agent is to create an environment where people can design, test, and iterate on process improvements. This is where Agile Development meets medicine. 

Agent Landing Page

We needed a way to communicate to administrators the benefits of the new technology to gain support. We also needed a way to onboard beta testers with email confirmation and a survey.

Components

Blog

Multistep sign up process with email confirmation, survey

Technologies

Ruby on Rails
simple-rss gem
CSS
jQuery

Read More

Users want seamless, not necessarily same: The swiss army knife principle

My hospital underwent the transition to EPIC in the Emergency Room this week. We phased out a homegrown system, EMTRAC, which was developed in-house with plenty of input from the providers who used it. My immediate impressions were as follows:

The positive changes

• Medications carry over automatically (there used to be a separate login)
• Past medical history carries over automatically

The negative changes

• There is so much superfluous information on the screen at the wrong time (Ebola screening, glascow coma scale when its not relevant, tetanus booster date, harm screen)
• Content has been separated onto multiple different screens. The old system was fine tuned so you'd scroll from top to bottom to quickly get the story, from vitals, to labs, to medications, to prose. now they are paginated and you have to find the story.
• The bed board is too small. It was previously big, clear, and projected on a large screen to quickly find open beds and locate patients

The swiss army knife principle: all-in-one is not always better. This image is courtesy of Amazon.com, where you can buy one of these.

A common complaint by providers in any institution is that there are "too many systems" and "too many logins". They want systems to "talk to each other", and they want all their interactions "to be on the same system". Off the top of my head, there are at least ten systems I use regularly that do a particular job in the hospital, a system with many moving parts.

• Allscripts Sunrise EMR for inpatients
• EPIC EMR for outpatients
• EMTRAC emergency department EMR
• Navicare for bed management
• Cerner for labs
• The radiology system
• Penn image exchange for uploaded disc images
• Pennrolodoc for consultant directory
• Cureatr for secure text messaging

As our hospital transitions to a single system to control all tasks, a swiss army knife system, we lose the fine-tuning, the specialization, and we risk ending up with a single system that does none of the jobs as well. One clear example of this phenomenon happened when we replaced a number of systems related to residency scheduling, duty hour tracking, and procedure signoff with a single software package earlier this year.

Despite the words they use, what users are asking for is not for everything to be on the same system. They are, instead, asking for a seamless experience. How is this seamless experience possible with so many systems? We should be inspired by the companies that have solved integration problems in consumer web. Here are some of the apps and services I use in my personal life:

• iPhone calendar and contacts
• Google calendar and contacts
• Facebook
• Dropbox
• Google documents
• Evernote
• RSS reader
• Blogger

These services work together well enough to avoid the user feeling the redundancy. My calendars synchronize between multiple devices, I can access my friends' birthdays from Facebook in my calendar too. Last year I snapped hundreds of photos with my iPhone, which upload to my Dropbox, from where I curated them for an album of "Best of 2014". My mobile RSS reader compiles feeds from my favorite online publications so I can read them on the go. The keyword here is seamless experience, and its possible across an infinite number of systems. To make this possible, each of the software applications need to provide an application programming interfaces (API), and to ideally use some kind of standard health vocabulary. There is also work needed to integrate these products.

My hospital has taken several steps toward providing this seamless experience through its Medview application, which grabs data from multiple clinical information systems and acts as a hub that provides these data to a series of new apps that use these data. Providers can now use a handheld app to access data on a patient that includes lab data, vital signs, and notes. Soon we will have another app that alerts providers of new data in real-time. The benefits include but are not limited to a good user experience. Once this architecture is established, the number of apps can grow exponentially--and the more apps, the better. There is tremendous potential once we unleash the data to build apps for predictive analytics, population management, and novel research. The future of medicine is open data, and the institutions that move in that direction first will reap the rewards. 

Read More

Connexus: Mobile clinical data display

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.

Read More

Smart Watch Assistant for the Elderly

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

Read More

Framework for ICU Dashboards

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.

Read More

Rolodoc: a dynamic consultation directory for hospitals

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 

Read More