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

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