Projects, designs, and writings on health IT

2015-12-21

Clinical visualizations - Antiobiotic grid

11:28 AM Posted by David, MD , , No comments

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

2015-11-24

Hospital census tracking

10:08 PM Posted by David, MD , 1 comment

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

2015-09-03

A Call for Innovators

10:16 PM Posted by David, MD , No comments

This weekend, 1500 hackers will descend upon Philadelphia to try to change the world at the 12th gathering of PennApps, the nation's largest collegiate hackathon. These college students will identify real-world problems, form teams and pull all-nighters to design and build technological solutions that solve them in less than 48 hours. Since last year, PennApps features a health component, which promises prizes for notable healthcare innovations.

Innovation is a hot topic for hospitals these days, in large part due to a changing landscape of reimbursement that includes quality-based adjustments, disease-related groups, and withheld payments for hospital-acquired conditions and readmissions. Administrators and providers understand they must adapt, but they often lack the design skills and the technical skills to implement change in this era defined by the digitization of medicine. That is why their survival depends on startup companies and the wave of technological innovation fueled by talent seen at hackathons like these.

Innovators, if you are reading, here is what healthcare needs from you. Forget the wearables, the quantified self, and automated diagnosis. There are more pressing needs that often require adaptation of ideas already proven in consumer web. Here are some ideas:

  • Trello for patients - There is tremendous emphasis on decreasing length of stay because each day in the hospital is expensive. Streamlining the processes is difficult. Imagine an automobile factory in which every product is completely different and requires a different subset of skilled mechanics. This is the type of factory that a hospital resembles. Patients often stay extra days to see a specialist. Hospitals need tools that coordinate and streamline schedules for providers, patients, and social workers. Those familiar with project management will know that tools like Kanban or apps like Trello can help keep projects on time. 
  • Google Analytics for Provider-specific Prescribing habits - Another component of increasing value is eliminating unnecessary testing. The amount of testing varies tremendously by provider; there is scant evidence about when and how often a patient should get blood draws, and consequently most patients in the hospital get them once daily. A platform that allows providers to see their prescribing habits and patient outcomes compared with peers would be essential in helping them change.
  • Patient-based Twitter or Slack - Communications between providers exist in many forms, including written notes in the chart, text messages, telephone calls, and emails. The nature of healthcare is team-based, with members of the team entering and exiting at various points in care. Providers need a way to be involved in this ongoing conversation, perhaps similar to an internal Twitter in which they can hash-tag the patient's name, allowing more providers to be part of the conversations. 
  • Airline Price Predictor for illness severity - In a setting with many patients and providers, it's difficult to know who needs more resources at any given time. Despite the digitization of vital signs and other parts of the medical record, there are few good predictors for clinical events like sepsis and intubation. Most of the tools currently in place are built to respond to problems rather than predict them.
  • Kayak for Pharmaceuticals - When patients are discharged with medications like antibiotics, the insurance approval process can take days. Further, upon approval, providers and patients may discover they face copays in the $1000s. Providers need realtime lookups for pricing so they can choose an alternative medication that is covered by the patient's insurer. Some companies, like Eligible API have started to offer data services to help solve problems like these.

There was never an era that had so many gatherings of problem solvers and innovators. Healthcare must tap into this talent pool. Stay tuned to see what comes out of PennApps.

2015-06-12

Designing Better Clinical Views

5:50 PM Posted by David, MD , , , No comments
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

2015-05-25

Mednote: a note-taking app that builds a medical ontology while you use it

5:35 PM Posted by David, MD No comments

Introduction

Mednote is a lightweight medical note-taking app that builds a medical ontology while you use it. I built this and used it during medical school when trying to organize the vast differentials and arrays of supporting evidence for different diagnoses.

This web-based app has an interface similar to Evernote. Users can create a page to take notes on a particular concept, like 'chest pain'. Within the body of the text, users denote relationships with other medical terms, which gets extracted from the text and placed into the sidebar. As you build pages and connections, linkages develop, allowing you to navigate back and forth between concepts. On the 'chest pain' page, as an emergent property, you can see the different causes, and recommendations on which examinations or tests to run to differentiate them.

Source code

Open source
https://bitbucket.org/davehdo/mednote2

Technologies

Ruby on Rails



The index of terms



The chest pain page

The differential diagnosis for chest pain is inferred from the body of the text





2015-05-24

Agent - EMR data straight to your phone

11:14 AM Posted by David, MD , , , No comments

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












2015-03-24

Popular hospital services

5:11 AM Posted by David, MD No comments
Here are some of the latest analytics on Rolodoc:


Popular Services

  1. GI gut consult "6,727"
  2. Cardiology consult "5,089"
  3. Neurology consult "4,775"
  4. ID (Infectious Disease): General Consult "4,655"
  5. Interventional radiology (IR) consult "4,548"
  6. General surgery (ESS) consult "4,195"
  7. Renal general consult "3,590"
  8. Cardiology: EP Consult "3,098"
  9. Neurosurgery Consult "2,884"
  10. Orthopedic Surgery Consult "2,865"
  11. Radiology reading rooms (Radphone App) "2,743"
  12. Heme/Onc Consult: Benign Heme "2,695"
  13. Renal ICU consult "2,615"
  14. Urology Consult "2,596"
  15. ENT consult (ear-nose-throat) "2,083"
  16. Renal Transplant Consult "2,033"
  17. Psychiatry consult "1,990"
  18. GI liver consult "1,916"
  19. Central lab "1,759"
  20. Diabetes consult "1,733"
  21. Dermatology consult "1,698"
  22. Palliative care consult "1,622"
  23. Rheumatology consult "1,607"
  24. ID approval pager "1,526"
  25. Microbiology lab "1,503"
  26. Pulmonology consult "1,460"
  27. Endocrine consult "1,378"
  28. Sympac Anesthesia Pain Service Consult "1,372"
  29. Heme/Onc Consult: Solid Oncology "1,371"
  30. ID (Infectious Disease): Transplant ID Consult "1,308"
  31. PICC Team "1,294"
  32. OB/Gyn Consult "1,291"
  33. Plastic Surgery Consult "1,256"
  34. Procedure service consult "1,250"
  35. Cardiac surgery consult "1,232"
  36. ID (Infectious Disease) Consult "1,204"
  37. Ophthalmalogy (optho) consult "1,200"
  38. Heme/Onc Consult: Liquid Oncology "1,173"
  39. Vascular Surgery Consult "1,090"
  40. Physical & occupational therapy "1,072"
  41. Pathology consult "1,053"
  42. Bed management 994
  43. Allergy Immunology consult 966
  44. Medicine Consult Pager 938
  45. ID (Infectious Disease): Oncology ID Consult 929
  46. Interventional pulm consult 845
  47. Radiology MRI scheduler 838
  48. Thoracic Surgery Consult 763
  49. OMFS Consult 663
  50. STAT phlebotomy 659

User growth


Fluctuations based on time of day and day of week


Correlations with weather





2015-02-22

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

8:51 AM Posted by David, MD , , No comments
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. 

2015-02-17

Can Tech Change Physician Behavior?

9:39 PM Posted by David, MD No comments
Providers in the hospital order many more lab studies on patients than medically necessary. A common practice during a patient's admission is to order a set of labs and, with one click, copy ahead to an entire week. It has become a part of the culture--ordering labs a week ahead of time--and contributes heavily to unnecessary costs. Many have proposed to remove this copy feature. I think that is unwise--it fails to address the fundamental problem, and in fact it creates news problems. Here's why:

1. Copying is necessary
In a survey of residents in the hospital, people reported that the intervention would make it harder to care for critically-ill patients, including trending hemoglobin in a bleeding patient, sodium in a hyponatremic patient, or DIC labs in a cancer patient. It takes at least five clicks and several key presses to order a single lab in our inpatient EMR. Providers already spend a substantial part of their days working in the EMR, and to order these labs for a census of eight patients could take up to ten extra minutes daily. I have heard, however, that not all institutions have a copy feature, so we should be able to live without it. EMRs vary in usability, and most (like our outpatient EMR) require fewer clicks than the inpatient EMR we currently use.

2. Efficiency matters
Disabling the copy feature may very well decrease the total number of labs ordered--but so would an intervention that requires house staff to draw all their patient's labs. Efficiency is critical. The average intern work day is a nonstop stream of orders, documentation, and telephone calls. An efficient EMR means that they spend more time talking to and examining patients and thinking about the big picture.

I liken this problem to one in the outpatient EMR. EPIC progress note templates encourage cookie-cutter exams of questionable reliability. The destruction of templates would probably lead to more accurate notes but at the expense of time. The fundamental problem here is a lack of time, and documentation is poor not because of templates but because providers rush through documentation to keep pace with their clinic day. 

3. Its a barrier 
Great technological solutions should make it easier to do the right thing rather than raise barriers. The true problem with lab overuse is a lack of thought. The solution, therefore, would be to prompt people to think about it. Some teams, for example, have pioneered the use of a rounding checklist. One question on this checklist is, "does the patient need lab studies tomorrow?". If not built in as a part of rounds, perhaps we could send an electronic notification that tells the provider exactly which labs are ordered for their patients. This prompts the user to think briefly about each item. 

Instead of asking our technology to make it harder to order labs, we should ask our technology to make it easier for the provider to order the labs he/she wants.  

Residents want to reduce the number of lab draws. They want to save their patients from the discomfort, and they want to avoid incidental findings. When I have the luxury of extra time, I think about which labs i need and cancel unnecessary ones. Work load often prevents them from being thoughtful about the labs they order. We can provide them the tools to be better doctors, rather than adding an obstacle to ordering labs.