When I went to my first healthcare technology conference, Health 2.0 (2009), the energy in the air was palpable.  Everyone thought their "remote patient monitoring with a social network so you're always connected with your physician" app was going to revolutionize healthcare delivery.  With hindsight, it's safe to say that the majority of these companies missed the mark.  Although not short on imagination or technology, they missed a fundamental understanding of healthcare technology adoption.  Radical change does not sell to the healthcare masses.  To understand why it's important, look at the mindset of the clinicians and the healthcare organizations.

Right now, clinicians have the same mindset that consumers had when we were using Windows '95; they expect technology to fail.  Not only do they expect it to fail, they expect it to get in the way.  Every new go-live will bring with it hours of training, workflow disruptions, new systems to learn, and added work to their plate.  The healthcare organizations feel the same way as most projects go over budget, cause months of headaches, and lead to upset clinicians.

Radical change is not accepted because everyone has seen what happens with poorly implemented technology.  Instead, what you should be doing is focusing on the one piece that solves a current need for healthcare organizations.  Then do it - really well.  Healthcare organizations can swallow incremental changes because that one piece, done well, will provide them the efficiency, workflow, and quality gains they are looking for.  

Bottom line: Selling incremental change over radical change will greatly increase your likelihood of success.  

Healthfinch is looking for a lead developer and lead UI designer to add to our team.  Both jobs are located in Madison, WI but remote is also an option.

Lead Developer

We focus on apps and tools that add-on to electronic medical record to improve patient safety, reduce administrative overhead on clinical staff, and save organizations time and money.  Our ultimate goal is to make lives easier for clinicians and better for patients; it's as simple as that.

We'll hire an intern for the spring, but only if you're able to go full-time after your internship ends.

Requirements include:

• Knowledge of Rails/Javascript/Coffeescript
• Strong experience with modern web development
• Understanding of the MVC design pattern

Extra credit if:

• Starcraft APM 50+
• Experience integrating with EMRs
• Working knowledge of HL7
• Experience designing and testing RESTful APIs
• Interest in working with large amounts of data and analytics

Benefits include:

• Competitive salary
• Stock options
• Great working environment
• And that's just the beginning!

If you think you're up to the challenge send something to [email protected] that proves it. This can be a code sample, github profile, URL for an app you built, or anything else that you're proud of.

Lead UI Designer

At Healthfinch you will be working in healthcare, an industry which is in desperate need of a design revolution.  In fact, that's why we founded Healthfinch because we believe good design can make all the difference.  You will be designing applications and experiences through tools which add-on to the electronic medical record.  Our ultimate goal is to make lives easier for clinicians and better for patients; it's as simple as that.  This could include everything from designing a new portion of our existing application (RefillWizard), coding your new designs, tightening up the copy, creating marketing pages to better convey what we are about, doing a little client work (implementation), or maybe even working in the sales process.  We are going to be expecting a lot out of our designers, so make sure your up to the challenge!

Requirements include:

• Being able to create mockups/sketches
• Performing user testing on those mockups
• Turning those mockups into hi-fi application designs
• Coding those designs in HTML and CSS
• Strong command of the English language
• Willingness to stand by your design decisions
• Passionate about solving problems in healthcare
• Love of Apple products

Extra credit if you:

• Can code in Javascript or have other web development experience (we use Rails)
• Have experience in healthcare IT
• Have ever sold anything
• Read Hacker News

Benefits include:

• Competitive salary
• Stock options
• Great working environment
• And that's just the beginning!

If you think you're up to the challenge send something to [email protected] that proves it.  This can be application designs, mockups, copy, or anything else that you're proud of (don't be shy!).  

A while back I mentioned that HIT usability was so problematic, the Government was starting to get involved (See post, "War on EMR usability").  Now, we have a much better ideas of what this mean with the recent release of the NIST document "Technical Evaluation, Testing, and Validation of the Usability of Electronic Health Records".

After reading this, I must start with a question.  What is the purpose of this document? Is the goal of the article to educate vendors on best practices? Will this report serve as a foundation for evaluating usability of EMR systems that will be published to consumers? Without this end point in mind, it’s hard to judge the merit of the report.

Waterfall design, really?

With that said, the methodologies outlined in the report contain little groundbreaking information, but is a rehash of what is considered best practices in the field of human-computer interaction. My major problem with the report is the emphasis placed on a “waterfall model of design” (see Figure #1).

First and foremost good design is a process. It is not something that can done once or injected at the very end of the development cycle. You can’t put “lipstick on the pig” and call your software usable. The best design companies have taken these principles to heart very early in the design process by constantly testing and modifying their product. Design is iterative. When you wait until the very end of the development process to run usability tests with your users you’re going to find problems – lots of problems. At that point, what is a vendor going to do? Miss a shipment deadline or send less “usable” code? I’m going to guess the former. Add to that, the usability testing will uncover major code rewrites often times requiring starting from scratch. Don’t make the mistake of assuming usability is going to uncover only aesthetic problems. This report needs to place a greater emphasis on iterative, rather than a once-through (waterfall) design process.

Developers != Designers

If you’re going to improve vendor design, it has to begin with an internal commitment to value designers and what they contribute to the product development process. They cannot be an afterthought. There are very few companies with this mindset. Almost all HIT companies are developer-driven, so the first thought, and one that is promoted in this report, is to turn developers into designers. This will not work! A developer and a designer require two fundamentally different skill sets that are not easily transposed. Developers are trained to think rationally and analytically; design requires empathy for the user.

Trained designers have a hard enough time in HIT because most of them are not clinicians. It’s much easier for a designer to create a new social network because we have used them. It’s much hardly for HIT designers to judge the value of the solution. That is why it is crucial to have a clinician apart of the design process. They can add the insights that the designer could never see. It’s hard enough for a trained designer to develop useful solutions in the HIT space, yet alone asking a developer to do the same.

I don’t think that vendors are going to change to this designer-centric development process voluntarily, so how is this report going to push them?

Some other thoughts

Why test applications in a sterile user testing environment? One of the biggest problems in HIT is that software is not designed with the clinical workflow in mind. How often have you seen a software tool that supports the interruptions that are common in a clinician’s day? By keeping the software in a controlled environment everything will look fine, but once it's in the wild the problems will show themselves.

The highlight of the report for me, were the HIT examples in the Appendix. They did a great job of capturing healthcare use cases.

When testing task competition times, why not assume expert users? If expert users are assumed then software can be used to model the time to competition based on spacing of buttons, number of clicks, system lag, keystrokes, etc. This will give an accurate, reproducible competition time estimates across vendors. Right now, untrained EMR users will be the test subjects, but as stated in the report EMRs are not “walk-up-and-use applications”. My guess is without training they will have difficultly even completing the tasks!

We have been slowly rolling out the public beta of RefillWizard over the past couple weeks and to get everyone up to speed we wanted to put together a short video for how refill protocols work within RefillWizard.

This video is intended for consumption by refill prescribers.  It will discuss how refill protocols are structured and how they can be edited.

We all know that HIT moves at a glacial pace, but are there similar industries that have taken a similar trajectory and now with history in their rear-view might provide some insights into the future of HIT?  I think I've found one.

ERP is Born

In 1990, Enterprise Resource Planning (ERP) was born when the Gartner Group first coined the acronym to describe a software package that integrated the entire working of a company into a single application.  The goal was to facilitate the flow of information from all parts of the business including finance, manufacturing, and sales.  The ERP system leapt to the forefront as the Y2K bug approached - legacy systems needed to be replaced and the newly create ERP systems fit the bill.  As the Y2K bug came and went, companies realized these ERP systems, while promising in theory, were far from perfect.  Likewise, ERPs became infamous for negative ROI and implementations which were over budget and took longer than expected (seeing the similarities to HIT yet?).  Digging through archives my favorite article talks about how many of the ERPs installations were delayed to the point of not being able to meet the drop-of-the-ball deadline.  Anyone think this is going to happen as the meaningful use deadlines approach?

In the early years, the ERPs made automating the back office logistics their priority, but as time passed they began to focus more on the front-office functions such as supporting the sales staff via a customer resource management (CRM).  For those unfamiliar, the CRM is an application for documenting interactions with customers.  Or for the more software-oriented, think of ERP as the backend and CRM as the front-end.  However, these front-end applications were constantly victimized by poor usability and fragmentation (how about now?).

A New Age of CRMs

However, it took the internet, and simplification of communication to usher in a new age of CRMs.  One company emerged, Salesforce.  Salesforce leveraged the changing forces in the enterprise market to create a highly popular web-based CRM.  It leveraged the foundation laid by the ERPs, utilized the web and its business models, and promised to end software burden for its users.  What happened next is well, history.  Salesforce has taken off, and as of this writing, they are a $15B dollar company with over 100,000 customers.

As I heard this story, I could not help but make comparisons to healthcare.  Briefly summarizing:

1. The Y2K bug, much like the HITECH Act, will provide the stimulus for an enterprise foundation to be laid.  Although the merits of both of these events can be questioned, the sole fact remains, their respective industries will be changed as a result of this external stimulus.
2. Both current ERP and EMR systems are becoming known for negative ROIs and being over-time and budget.
3. Finally, the front-end systems were both notoriously unusable.

Seems like the perfect storm for the healthcare version of Salesforce.  Who/what will it be?

Note: I've tried my best to convey facts, so if there are any errors below, I apologize.  If anyone out there was involved with any of the companies I mentioned, I would love to hear from you.

From my recent talk at the UX Masterclass, a user experience conference put on by the folks at User Centric.  

I recently had an opportunity to talk with arguably one of the best software designers in the web space, Jason Fried.  I'm crossing industries here, so for those of you in healthcare (and totally isolated from the tech space) Jason is the co-founder of 37signals, a Chicago-based company focused on building collaborative tools for small businesses.   They build some great products.  We use Backpack on a daily basis to keep track of our internal discussions.  Let's just say if Jason (and 37signals) were focused on healthcare, as an industry we would be much better off than we are now.  I've always admired his laser-focus to his product and making the lives of his users better.  Needless to say, I have quite a bit to learn from him. 

When I first found out I was going to meet with Jason, I figured our meeting was going to be a little Q&A - exchange the typical pleasantries, but Jason would have none of it - he wanted to get to work.  So before I knew it I was in the middle of a design session with Jason Fried.  This is what I learned.

The original design

(download)

Click here to download:

i-had-a-design-session-with-jason-fried-this-is-what-i-learned-zdoAkAcAFIfgoulJjqsv.zip (1.66 MB)

Below I will give examples which will reference the above designs.  See the updated design at the bottom of the post.

Lesson 1) Too much jQuery == You're doing it wrong

Javascript (in particular, jQuery) is an amazing tool for web developers.  The technology has made the previously unthinkable possible in a couple lines of code.  So what do software designers do?  Use it - too much.  This causes them to to lose focus and overlook the actual purpose of the application.  Instead the designer builds an application to look good, rather than to be usable.  Excessive use of jQuery is indicative that your design is getting too complex.  Case in point...

Example

I needed a way to collect information about the medications from the user.  In order to minimize the screen real-estate, I decided to hide and show input fields based on which medication was selected.  To handle this I created medication cards, which when clicked would display the associated inputs for the particular medication.  The user would have to cycle through all the medication cards to fill out all the information.  I thought it was a clever design...

However, Jason quickly pointed out that this design was likely going to result in major usability problems.  No established convention exists for this design; there is no precedent to click each card.  Rather, the user would likely click the continue button (which leads to the next page), leading to an incomplete form submit.  The other medication cards would go unnoticed.

Jason's thoughts: Most of the "best" applications could be run using technology from 10 years ago.

Lesson 2) Edge cases will show design flaws

Fancy designs are nice, but for them to be functional you have to think about the edge cases.  What's going to happen when your user pushes the application to the extreme?  Does your design scale gracefully or does it fall apart?

Example

Patients often require multiple medications to be refilled at once.  During user testing, we found that medications were commonly refilled in batches of 2 or 3 medications.  Thus, we originally designed it to handle (roughly) that number of medications.  However, we neglected the extremes of the application.

We were limited to only four medications at once.  There was no way to add additional medications to the design without some fancy jQuery animation!  This was not a limit of the technology, but of the design.

Also, when refilling one medication the design fell apart.  The medication card analogy didn't make sense when only one medication was present.

Jason's thoughts: Get rid of the unnecessary design, keep the application design simple.  

Lesson 3) Use English when communicating to your users

Use language to your advantage; it is the common thread that ties all of your users together.  Often times as designers we get too caught up in trying to over simplify the content of our application until we get to the point where it no longer makes sense.

Example

After entering the information about the medication, the results of our application are a set of instructions for the clinician to follow.  Obviously it's very important that we communicate those instructions as succinctly as possible.  Yet, I was using phrases like "Filled by Team" or "Fulfill then Notify", which made sense to me, but to a new user were ambiguous.  

Jason's thoughts: If you were in a conversation and you spoke the text would it make sense?  No?  Then it should not be on your website.

The new, improved design

(download)

Click here to download:

lessons-learned-from-a-design-meeting-with-jason-fried-FoGoyuyaofJzDajIlcjG.zip (512 KB)

Based on the suggestions from Jason, I completed a redesign of the three pages.  The first page remains relatively unchanged.  The second and third were completely revamped. 

Following Jason's suggestions I completely eliminated the medication card design and replaced it with a more conventional vertical layout.  The vertical layout allows the user to see all of the required input fields without clicking, and eliminates the ambiguity as to what needs to be clicked.

Rather than using ambiguous section headings, I've replaced the entire screen with a set of instructions.  These instructions are written out as complete sentences, rather than fragments (or headings).  

You can further explore our redesign by checking out our demo.  If you like this, please upvote this on Hacker News.

If you want to keep pace with our redesign of Health IT, follow us on Twitter.

Government involvement in usability has been the talk recently at HealthFinch as Lyle is gearing up for his presentation at the NIST Usability Workgroup.  In case you're not aware, EMR usability is so problematic the government is exploring ways to get involved.  As you might imagine the topic is a very sticky subject, especially EMR vendors, as the topic conjures images of committee-centered design and EMRs being worse of then they already are now.  

However, when you think objectively about it, I believe the government can be part of the solution, if done correctly.  I want to lay out my guidelines for government involved in Health IT usability.

Brief Introduction to Usability Testing

Before getting into my recommendations a brief background in usability testing is required.  Usability testing can be roughly broken into three types: (1) heuristic evaluation, (2) expert user testing, and (3) novice user testing.  Although each of these are not explicitly "usability" testing, for the sake of simplicity I'm going to lump them together.  

Heuristics

Goal: General software usability

Usability heuristics, or discount usability testing, is a process developed by Jakob Nielsen to rapidly and cost effectively test the usability of a user interface.  In this method, Nielsen defines ten "rules of thumb" for all interfaces whether it's a game on an iPad or a state-of-the-art enterprise EMR system.  Remarkably these suggestions have held through years of scrutiny.  In a heuristic evaluation, a usability expert performs a detailed evaluation of the user interface to find heuristic violations.  Next, the violations are given a severity rating to prioritize the fixes for the developer team.  Some of the most commonly violated heuristics in HIT include:

• Recognition rather than recall - Minimize the cognitive load on the clinician by storing more information in the system, rather than in the head of the user.
• Aesthetic and minimalist design - If it is not important, don't put it on the screen!  I can't tell you how many times I've seen lab results, problem lists, or a medication interaction listed in a table format with poor information display.  Rather than taking up screen space with this low information density data, it's better to use techniques such as Edward Tufte's sparklines.
• Error Prevention - User interfaces should prevent errors from occuring in the first place.  What happens when this heuristic is not followed?  Alert fatigue.

Expert User

Goal: Quantitative prediction of task completion time

Using a technique called User Performance Modeling, the time it will take for an expert to complete a task on a particular user interface can be determined.  These models predict the completion time based on parameters such as button size/spacing, number of clicks, and load times.  The best tool I've used for this modeling is CogTool from Carnegie Mellon.

Novice Testing

Goal: Learnability, Find major design flaws

Novice testing is the process of asking a new user to complete a given task.  It generally goes like:

1. Find a representative task for your system (e.g. fill a new order for Lipitor, refill the prescription, change the prescription)
2. Ask a novice user to perform the task
3. Tell the user to "think aloud" (e.g. verbalize their thought process)
4. Record major breakdowns in the process (e.g. can't find a button, unfamiliar wording, etc.)

Don't let the relative simplicity of this process fool you, it can be very powerful for finding flaws in design.  In the design of our newest application to automate medication refills, we went through a major redesign after each round of our user testing.

Usability Heuristics for Government Intervention 

Do not design EMR software

Let's take that off the table immediately.  Although platform oversight on software design can work (Human Interface Guidelines from Apple), design is not a core competency of the government.  Putting government regulation on the design process would inhibit rather than promote usability.  As such, any government involvement in usability cannot present an "ideal EMR" and require evaluation against that "ideal EMR".

Evaluate objectively, not subjectively

This goes hand-in-hand with the previous recommendation, but if the government is going to evaluate usability (ala KLAS), then all metrics need to be objective rather than subjective.  A common misconception is that usability is subjective.  In fact, it's not.  Usability is a fairly exact science.  User experience, which is often confused with usability, deals with more the subjective measurements, such as more the "look and feel", rather than objective measurements.  Good evaluation criteria would be metrics such as heuristic violations or task completion time.

Don't allow for over-optimization

Give an engineer a metric to optimize, and they will optimize it, potentially to the detriment of the overall system.  What this means for usability testing, is that you cannot test on a single metric such as "time to complete a new order".  If you're going to test on completion time then the tasks need to changed so that over optimization does not occur.

Open the eyes of consumers

The most important outcome of a government intervention in usability is to promote consumer level awareness.  If clinicians are aware of usability problems, vendors are going to compete on usability.  It might be wise to piggy back on existing consumer satisfaction surveys, such as the reports from KLAS to increase consumer awareness on usability.

Let the market flourish

Let's face it, in a properly functioning market, the customer will pick the best products, and the winners will rise to the top.  Do you ever hear Steve Jobs complaining about the usability of iOS Apps?  From the lack of usable HIT products, you could assume potential innovators are being left on the outside looking in.  If you want usability (and innovation) to flourish, open healthcare environments such as SMART Platforms, need to be continually pushed.

Focus on the "big five tasks"

Clinicians spend the majority of their days completing five tasks - orders, results, messages, prescribing, and notes.  If you make these processes more usable, clinicians are going to be happier and more productive.  Whatever intervention is selected, it would be wise to focus on these particular need areas.

The EHR Usability Report Card 

I've taken the liberty of complying all of these suggestions into a potential usability report card for EMRs.  The report card highlights the heuristic violations of three fictitious vendors in the "big five tasks".  The greater the number of violations the poorer the overall usability of the system.  While this report is not perfect, I believe it best exemplifies the processes the government needs to take in its "War on EMR Usability."

If you buy that healthcare can be improved by IT (an argument for another day), then the time to set the foundation for the future is now. Healthcare is notoriously slow to innovate, but why?  From the eyes of a company trying to do just that, let's look at why the normally fast-paced world of IT gets brought to a halt in healthcare.

Traditional HIT applications are difficult to deploy. 
From the business-end alone, it takes business partnerships, integration contracts, HIPAA agreements, and service contracts to get an application into the hands of users.  On top of that, implementation costs are orders of magnitude more than it cost to originally design the product.  Software licenses can run 10% of the entire application cost, with the remaining 90% going to implementation, support, and hardware [1].  For big vendors with the available resources these costs can easily be passed off to the customer, but the small vendor with the limited resources can not afford to take on these responsibilities.  Therefore they must either partner, give up, or find the money to proceed.  While this model is making some vendors wildly profitable, it puts incredible barriers on potential HIT innovators.

HIT Apps need patient data.
Any application worth purchasing is going to require patient data.  The days of being able to build a successful medical reference application have come and gone.  The future of HIT innovation will be fueled by patient data.

The problem is we have made data difficult to get.  The industry is littered with potential options such as CCD, HL7, data warehouses, and HIEs which developers can use to power their application.  The problem is they're all flawed, and this flaw will inhibit the growth of your product moving forward. 

In conclusion,
High deployment costs + No Data = No innovation

After receiving the SHARP grant, the Harvard team led by Kohane and Mandl set out to solve this problem through the creation of a technology they coined, SMArt Platforms.

What is a SMArt Platform?
The best way to think about SMArt is as a wrapper around existing electronic medical record systems.  No matter the underlying system being wrapped around, the same data gets exposed to the developer.  Rather than having to integrate with an Epic system, then revamp that integration for Cerner, the SMArt wrapper maintains the connection.  The developer builds the application to be SMArt-compliant once, then as long as the vendor has SMArt you can easily plug-and-play.

Once completed, SMArt is proposing to build an App Store for Healthcare that will serve as a point of deployment for HIT developers.  Once a hospital agrees to use the App Store, the developer now has a distribution channel in place.

Now lets look at our equation:
Low deployment costs + Available data = Innovation

Imagine the future where all it takes is a developer (and a clinician) to work together, then release an app to the App Store, and SMArt handles the rest.  Apple has shown it, and hopefully SMArt will embrace it - take the burden off the innovator and innovation will flourish.

[1] Wang et al. A cost-benefit analysis of electronic medical records in primary care. Am J Med (2003) vol. 114 (5) pp. 397-403

After a very long wait (and many billable hours by the lawyers) we are happy to officially add a new member to the HealthFinch team - Dr. Lyle Berkowitz.  Lyle is currently a practicing physician as well as the Director of the Szollosi Healthcare Innovation Program. 

Being on the front-lines, Lyle experiences the problems with HIT first-hand.  With these insights from Lyle, we are able to understand the problems clinicians are facing, then we can focus on creating technology which solves those problems.

The first time we heard about Lyle Berkowitz was at the Mayo Clinic Transform conference where he talked about the death of EMR 1.0.

With Lyle we were fortunate to find a physician that held the same core beliefs as the original HealthFinch team.  So moving forward, our mission remains unchanged - we will continue to develop medical software which makes the jobs of clinicians easier.

The first application we will be releasing as a new team is RefillWizard, an application which assists clinicians in automating the cognitive processes associated with medication refills.  Lyle speaks to this problem at 7:34 in the above video.  Medication refills are a common but under-addressed problem in HIT (PCPs can receive up to 15 per day).  Without adequate solutions, administrative tasks, such as medication refills, are increasingly consuming the time of clinicians.   

The goal of RefillWizard is to capture the refilling protocols of clinicians and translate them into application logic.  With this logic, the application can become the facilitator rather than the inhibitor of a more effective clinical practice.  Using the application, we hope the clinical staff can become empowered to help in the process, lessening the burden on the physician.

We are currently accepting requests to become beta users for RefillWizard.  If you're interested let us know here.  Follow our blog, as well as our twitter feed to stay up-to-date on the latest updates on RefillWizard.