Resource Corner Blog

Bridging the Users & Developers Gap in EHR Software Development

Like
Tweet
Share

Software Developers can often become disconnected to those using their software, through no fault of anyone. Bridging the gap from developers to those in behavioral health services is critical to TenEleven’s approach to EHR software development.

My Story

I once worked as one of the few developers of an internal custom Enterprise Resource Planning (ERP) system, which is a suite of applications that integrate the process flow of a business through multiple departments such as accounting, billing, purchasing, sales, manufacturing, human resources, etc. Because we were a medium sized business, there were less employees between the development team and the customer.  This was convenient and eye-opening because as developers we could listen and see first-hand how the software was being, or was going to be used.

Since switching from ERP to Electronic Health Record software development, my team deals with over ten thousand users across many databases.  The growth is substantial, and the need for multiple points of contact with the customer (help desk, testers, project managers) is apparent.  What becomes more difficult is the developers’ direct interaction with users and view of their process.

Luckily, there are ways to bridge the gap when the developers’ access to their user base is limited. 

Understand User Roles

Knowing and understanding how a certain role fits within a behavioral health setting is important for a developer of behavioral health software to know while designing functionality and an interface for that user.  Understanding all that their job function involves can lead to a leaner application more tailored to include anything helpful, and exclude what’s not.  While this is also done through gathering requirements, sometimes there are holes in the requirements.  Or there are requirements that just don’t seem right.  Understanding more about the user’s role can give developers a better idea of what to watch out for.

Knowing the role helps developers understand what decisions the user faces in the scenario they’re developing.  Knowing what that user does daily gives a better idea of what else could possibly be automated as well to streamline processes. It also helps with knowing when to bring up certain design decisions such as how permissions should work for a specific role.

Create Personas

To better understand the type of user that plays a role in an organization, a persona can be created to represent a person in that role.  A persona is a made-up person that is given a name, some demographics, and a quick description of their professional background.  This can include other characteristics such as what their job goals are and how they currently use the system.  Any characteristic that conveys what they must deal with can be included in the persona.

Personas can be used to represent the multiple types of people that typically fill roles in a behavioral health setting.  Personas help developers feel empathetic towards users when making decisions about how to implement user stories in ways that will satisfy their needs and bring them closer to their goals.  When a user story is written for creating new software or a software enhancement, knowing the role that the software is being written for can give the developer an idea of the job function. Reading multiple personas for that role can give them an even better idea of what may be going through a user’s mind when they use the new functionality.

David Gordon’s blog post “Sal the Floor General” is an excellent example of a character that could be used as a persona in EHR software development for behavioral health software, and even has a full story behind him. He gets the reader into the day and mind of that employee, which helps the reader to live a workday through Sal’s eyes. 

Bridging the Gap

Understanding roles and creating personas are the closest that I can come to understanding the role of a behavioral health clinical staff member without shadowing each end user for at least an entire day.  This would be very time consuming and impractical with the number of users we have.

The big picture of a behavioral health organization’s process is something that everyone involved in EHR software development for behavioral health should understand.  It is important to have that knowledge in the back of one’s mind while designing for pieces of that process.  When designing user interfaces and functionality, it is important to understand all you can about the customer you are designing for.  This makes your job as a developer easier and their experience as a user easier.

See what's new in the Resource Corner