HMS recently announced to our customers the launch of the Patient Logic suite of enterprise clinical and financial systems. A key consideration for Patient Logic products is an unwavering commitment to workflow and visual design. The user experience with Patient Logic products is shaped by four fundamental design principles. In this and my next three posts, I will take you inside our design process.

There are four fundamental design considerations for Patient Logic:

• Fierce reduction of clutter (this post)
• Content, not chrome
• Visual perception
• Clarity

Hospitals are busy and full of interruptions competing for attention. For the work of clinicians, anything non-essential to reviewing patient status, planning care or performing interventions is not only poor design, it is dangerous. Thus, our first design principle is to reduce clutter.

Reducing clutter refers to eliminating screen elements unrelated to patient information or decision making. Every item is on a screen because someone, whether that person is a physician on our advisory board or a product designer, has successfully defended its purpose.

Perhaps surprisingly, a relatively small subset of patient information is required to quickly access the state of a patient. By reducing clutter, we are able to present the patient chart so that abnormal and critical items are immediately recognizable. Access to additional information is never more than one tap or click away. Non-urgent information is displayed, but does not compete with important information for the clinician’s attention.

Reducing visual clutter doesn’t end with data presentation. We scrutinize every workflow in the same manner. As a result, Patient Logic products bring information to you when and where you need it. For example, when customers asked to copy lab results from the chart into a note, we thought that was a cluttered workflow. In Patient Logic, it is one tap to view the lab results, another tap to indicate the results you want in your note, and the user then can comment on the values.

No screen flipping. No cut and paste. No remembering what values you want to add to your note.

We didn’t end our drive with visual design and workflow. Even our software architecture and implementations follow this pattern. We constantly refactor our software to simplify and remove sources of confusion. This allows us to rapidly respond to change. Look for additional posts explaining how Patient Logic design principles are changing the way people view an EHR.

I’ve written several posts outlining how we engage customers in our development process. In this post, I will present an example of this in practice.

From the product development perspective, medication ordering is a particularly interesting workflow. This is a complex process by nature; we don’t want our solution to add complexity. One of the more challenging questions is, “What information regarding current orders does a physician need to effectively manage medications?”

We initially approached this like most vendors; we displayed lots of information to avoid forcing users to “click” to find details. Internally, we debated the necessary key information, goals of a physician reviewing current medication orders, and what actions a physician would likely want to take.

We were left with two divergent approaches, both grounded in solid arguments. One approach displayed a maximum amount of information to avoid clicks. A second approach emphasized minimal information with quick access to order details on demand.

Fortunately for us, we have a physician advisory board comprised of both HMS customers and physicians who use other systems. We developed four variations for viewing current medications orders. At an on-site meeting, we presented these four options and asked each physician to individually rank their preferred visualization.

Two solutions rose to the top. We facilitated a discussion about preferences, focusing on perceived differing needs. During this discussion, the physicians shared variations in practice, patient conditions, and most importantly, what needs unfold the vast majority of the time. The discussion ultimately moved the group to a clear consensus. With our physician advisory board in agreement, we have strong reason to believe our design will be usable, effective, and efficient.

Design decisions like this occur literally thousands of times during the development of each release or new product. Many are fairly clear (regulatory, HMS experience, existing design approaches). But when developing new workflows or improving existing workflows, early customer outreach is a key component to the HMS user-centered design approach.

This is the third in a series of posts regarding how HMS is integrating customers into our product development process. This post focuses on how we are accomplishing this.

Our first step is to identify the projects for which we want additional input. Typically, we focus on larger initiatives that are complex and require an extensive understanding of workflow, such as Physician Documentation.

The second step is to identify participant characteristics. Working with our account management team, we use a variety of criteria to identify candidate organizations, including:

• Bed size
• Geographic location
• Diversity of HMS applications in use
• Length of HMS system use
• Experience with non-HMS systems Number of facilities in the organization (1 versus 10 versus 100…)

This allows us to obtain a cross section of facility types that improve the odds of HMS building and delivering a system that meets the needs of our diverse customer base. Once we select candidates, they are asked to participate in project overviews and demonstrations. From there, they are asked to join online demonstrations to review and provide input at various stages of the development process.

These ongoing relationships allow us to gain insight and feedback over the life of the development project. This also forms an initial pool of potential beta candidates.

As HMS evolves this emerging process, we continue learning how to improve it and make it as effective as possible. Customers who agree to participate are helping us and their peers in other hospitals as we move our product suite to the next level.

In an earlier post, I mentioned the importance of access to real users in real situations doing real work. This access is the basis for understanding the context in which HMS software operates ― also known as your world.

Real users are clinicians performing tasks for which the system is built. They are on the front lines using HMS software to accomplish the larger goals of your organization. I’ll use patient-care outcomes (versus something like claims processing) as an example. HMS will want direct access to physicians, nurses and other related disciplines. The steps to establishing a trusted relationship are:

• Initially meet in very small (1-3 person) groups
  The intent is to introduce the scope of the project and ground rules for HMS observations. We want to assure both parties agree on limitations and other considerations. We want to mutually answer questions such as: Are we focused on physician ordering or the broader task of reviewing the patient chart? May we spend time at the nursing station observing charting patterns? What example material may we review and bring back for further analysis?
• Direct observation of patient-care delivery
  Subject to ground rules, HMS shadows users through their tasks. For example, we may spend hours at a nursing station observing workflow and information needs. During this time, we may ask nurses to explain their goals and how they are using the system to accomplish those goals.
  
  Through observation and dialogue, HMS creates a model of what users do. This becomes design input to the next software release. Emphasis is placed on what is (and what is not) being done versus what is reported during interviews.
• Post-observation feedback
  HMS may follow up to clarify our findings during design. Ideally, HMS will demonstrate conceptual design models and early stage implementations to validate we are addressing user needs.
  
  Far from being a generic design review, this is a collaborative discussion about observed workflow and the HMS response. It prevents HMS from working “in a vacuum” and guarantees a collaborative development opportunity.

As with patient care, there is more to collaborative software development than meets the eye. In my next post, I’ll highlight the mechanics of how HMS solicits and determines the organizations and users with whom we attempt to work.

Software development requires collaboration with users if we expect to develop effective solutions. Notice I didn’t say with customers. As the story about selling dog food goes, there is a difference between the customer and the user. Most customers of dog food are not also users.

Why is collaboration a challenge?

First, users are busy: busy taking care of patients; busy processing claims and keeping cash flowing; busy trying to reduce stress without adding more tasks like explaining their jobs to strangers. Secondly, those of us on development teams are afraid that we might have to really listen and understand the users’ world. Afraid that our “great ideas” won’t survive real use.

Well, that was motivating, huh? There is hope, however. Here are a couple of steps that drive collaboration:

Software customers can help drive collaboration by allowing vendors access to real users in real situations doing real work. You can provide input when vendors request it. In a world as complex as healthcare, the only people who truly understand how work gets done are those who do it. For software vendors to provide useful, safe and effective systems, we need access to these people. Any productivity lost to collaboration will be recouped in better system design for future use.

If we as vendors want true collaboration, we must understand that users’ time is precious. We must prepare design concepts that provide viable system ideas. We also need to involve users early enough to allow the feedback to influence the development process. I’ve collaborated with user groups when design concepts were nothing more than sketches on paper.

Collaboration at these early stages builds confidence that the vendor is listening and that the solution will work in real use. In the coming months, look for additional posts describing how HMS development processes are evolving to ensure collaboration with users.