Bahmni an Open Soured EHR
TLDR;
WHO & WHAT & WHERE
Thoughtworks in Hyderabad and Bangalore, India collaborated with a low resource hospital to transform their physical system to an an open source hospital system, Bahmni. The team need to design new modules, tackle adoption issues, fix current UX issues, and scale to other hospitals globally.
Context
Location and Duration: Bangalore and Hyderabad, India for 8 months
Bahmni is an open sourced, hospital system for healthcare providers in low resource settings. It was originally created for Jan Swasthya Sahyog (JSS) hospital in Chattisgarh India so that practitioners would have a robust way to support and track individual patient needs, but also to provide support services for chronic illnesses like TB and AIDS. Bahmni was later evolved into a global product after founders realized that there was a gap for low cost, open sourced solutions to similar organization’s needs.
HOW ( I CONTRIBUTED )
I worked with my team to create a product vision, goals, and scope for the product. Conducted user research and test to understand the ecosystem of different type of hospitals and create new modules, including to create the new modules Registration, Patient Dashboard, Patient Summary, as well as Prescriptions, and to untangle the current information architecture and user interface interactions.
The problem
I was originally brought on the team to tackle adoption issues, correct existing UX issues, and build new user centric features. As the first designer on the product since its start 3 years prior, my focus was on instilling a user centered methodology, user research and usability testing practices in order to support the 50+ member distributed delivery team.
After my initial analysis I quickly realized we were dealing with 2 significant issues:
The first was a lack of trust with the product resulting the original client doing double work through continuing to use paper records even after adopting our digital solution. And the second was due to the fact that assumptions had been made about how certain clinical and administrative roles functioned. This resulted in imposed workflows on users that did not match their day to day activities. Hospitals and staff were forced to change their processes to match a system that had not taken their daily goals into account.
Bahmni, which had been originally created for a single hospital, struggled to evolve into a product flexible enough for use by hospitals with differing needs and contexts. The approach to evolving Bahmni was done with more focus placed on the integration between the 3 open source tools of which it was built on top, instead of on determining core product functionality and user needs.
Discovery and research
After joining the team, I took steps to understand the evolution of the product by pairing with BAs and QAs to learn the product history and map each client’s user journey. In parallel I performed a heuristic analysis and studied about digital systems in low resource settings, how paper based hospitals transitioned to EMRs and EHRs, and how the creation of EMRs began.
During this period, I also traveled to locations where Bahmni was being used to observe hospital processes through shadowing and performing contextual interviews with members of each department. I interviewed the administration team to understand their original needs and how integrating Bahmni into their services had shaped the hospital thus far. All of this gave me insights into the root causes for the lack of adoption. I discovered that:
Bahmni had been built without a product vision, goals, or metrics for success Bahmni begun as a way to solve issues that originated at JSS hospital, but as it evolved the product was shaped by individual requests from the various hospitals that began using it worldwide. The product was trying to be everything for everyone. As a team we were continuously rolling out features but without a clear roadmap based on metrics that measured the value we were supposed to be creating.
Bahmni caused a bottleneck (in some cases)
Because the system was rigid and forced them to follow a specific workflow many clinicians refused to use it or only partially used Bahmni. The effect of this on our original client for example, was that it caused a bottleneck and forced the hospital to hire more staff in other departments to transcribe paper records made by clinicians into the system. This forced the hospital to keep using paper records, resulting in double work being done and errors during transcription.The information architecture of the product was tangled and inconsistent
Doctors in hospitals with low resources are desperately stretched thin, sometimes seeing hundreds of patients in a day. Those that I interviewed felt that they were spending more time trying to figure out how to traverse through the system without getting lost and understand how to best use the UI at the same time as they were trying to counsel their patients. This resulted in the sentiment that the system was a barrier instead of a support for them to focus on their patients.The UI wasn’t friendly towards low tech-literate users
A high level of investment was required to learn how to use it with, what doctors felt, was not enough in return. Other users like nurses, pharmacists, lab techs, and people in billing learned workarounds or had to keep track of conflicting visual cues in the system to accomplish tasks.
Define
Defining our North Star
I worked with the team to create a product vision, goals, and scope to bring together all of the complex moving pieces of the product and client needs. We also defined personas and core journeys that spanned across multiple clients to begin working towards a more cohesive product. Partnering with our analyst team, I was able to distinguish what needs were common across all of our clients and which were unique to places with specific needs. From this we determined our vision, objectives, core value proposition.
Redesigning the UX
In order to build and ship Bahmni out to the original hospital and then turn it into a global product, the team size had exploded and as a result the experience stumbled. To provide the larger picture to my team I did the following:
Mapped the IA of Bahmni to reveal that there were “multiple doors” and different levels leading to the same place. with different visual cues to get there.
Categorized all of our interaction types and styles and showed that we were using the same visual cues to representing different actions that could be taken. I presented this to the team and provided a synthesis of how this affected our experience.
Together with the analyst team, prioritized the findings and created stories to bring to the new navigation and pages to development.
Putting a Face to our Users
I realized that my team struggled to empathize with our users and their needs. Most of them had never heard from a clinician or technician, let alone see what it meant to use Bahmni in a real setting with all the issues that come up in a hospital on a day to day basis. To bring the users to the team:
I presented the end to end experience of a patient going using photographs to my entire team. This not only changed the mindset of the development team, but also team leaders i.e. tech leads. Click here to read an article I wrote that similarly visualizes a this presentation.
I took steps to ensure the user was represented at each step in the development process. I routinely presented user research data, made sure that new features were explained in terms of how it enables users to complete their goals in story cards, and paired with BA’s during card kickoffs with developers.
I paired with developers to on features. We moved from handing work off to discussing the “why” and “how” of the building the feature.
Putting a face to our users
I realized that my team struggled to empathize with our users and their needs. Most of them had never heard from the clinicians or technicians that we were building for, let alone see what it meant to use Bahmni in a real setting with all the issues that come up in a hospital on a day to day basis. To bring the users to the team:
I presented the end to end experience of a patient going using photographs to my entire team. This not only changed the mindset of the development team, but also team leaders i.e. tech leads. Click here to read an article I wrote that similarly visualizes a this presentation.
I took steps to ensure the user was represented at each step in the development process. I routinely presented user research data, made sure that new features were explained in terms of how it enables users to complete their goals in story cards, and paired with BA’s during card kickoffs with developers.
I paired with developers to on features. We moved from handing work off to discussing the “why” and “how” of the building the feature.
Develop and ideate
By introducing early, rapid prototyping, I was able to quickly validate new features and interaction. The low fidelity prototypes I built helped to unearth unforeseen issues we may have missed otherwise, brought up new questions, and enabled us to continuously learn to check both our business and technical our assumptions. They also provided our clients a tangible example of how their request could be translated from a physical version to a digital one and allowed all of us to discuss complex needs using the same visual example and language. Lastly, they reduced confusion around what we had agreed upon to build and what that featured entailed.
Our solution
In this project ideation and development happened cyclically using Agile development methodologies and continuous delivery. We were constantly feeding our backlog and therefore our development team through a two week sprint cycle. I provided my team lo and high fidelity mockups and prototypes and paired with developers and QAs on stories.
Some of the modules I designed and helped to develop were Registration, Patient Dashboard, Patient Summary, and Prescriptions. I also designed features that surpassed specific modules, including a new information architecture and a cohesive set of interaction patterns, icons, text, notifications, and visual cues. No longer would a nurse travers through one module and unknowing end up in a completely different one. Visual cues would consistently represent one action not multiple. Navigation would be constant and would not appear and disappear depending where the user was.
I also began working on a new visual identity that was cleaner, easier to digest, and more cohesive. I consulted a visual designer in another part of our organization to come up with more modern visual patterns to use, a mood board, and style guide. This was halted after the major owner of Bahmni switched hands within the organization running it.