Effective electronic health records

In todays world where in most industries the standard of user experience is pretty high, the healthcare sector is somewhat of a black sheep. A quick google research is enough to understand how precarious the situation for medical professionals is when it comes to software. One of my favourite articles on the topic was written by Atul Gawande and published in the New Yorker: Why doctors hate their computers.

At the Hôpital du Valais we design and develop our own applications which are used within a medical software that is bought from an external provider. This case study is about the challenges and opportunities of this approach.


Interviews with doctors
Writing user stories
Designing flows
Defining a UI framework
Handover to development



the main software of the hospital is purchased externally but can be complemented by other applications


Since I was the first designer to join the hospital, there was no one who could give me an overview of the design issues related to the electronic health record. To get an idea, I analysed the existing solutions and I found the following problems:

Applications were designed with paper forms in mind

Large parts of the software are little more than digitised paper forms. Advantages of software, such as the reuse of information in other places or the possibility to display data in different ways at a mouse click are not used.

Solutions are created in silos

Many of the forms were created at the request of users. And there was no instance who took care of streamlining existing solutions for new users instead of adding new ones every day. The result is an unmanageable number of forms.

Basic interaction design principles are violated

So far, at the hospital there hasn’t been any position dedicated to user experience and accessibility. Many of the forms have recurrent information and functions, but there is no trace of standardisation.

Defining a UI framework

We decided to work with Google Material Design (Angular Material). Material Design is one of the richest design languages, optimised for touch usage and widespread. The last point was important because the medical staff has to work with a wide range of software on a daily basis and we wanted to offer them something that they were familiar with.

Defining standards

One of the first challenges was to create standards without knowing which elements of the electronic health record we were going to re-design in the future. During my analysis, I found out that there are two types of recurring information on the forms. On the one hand, there were functionalities that existed on several forms (such as printing or a history of modifications) , on the other hand, there were important patient information such as allergies that were displayed repeatedly.

I created a layout with header and sidebar which could accommodate these features but would also leave some flexibility for further development.

header and sidebar which may contain recurring information and functionalities
extended sidebar, which can be closed for use on small screens and kept extended on big screens

Creating meaningful data connections with FHIR®

FHIR is a standard for health care data. We decided to work with FHIR because it would allow us to define relationships between different data points in the patients medical record. This would allow us to show certain information in specific contexts which would reduce the need for doctors to re-write information in different places.

For example, if a transfusion reaction is documented on the transfusion form, it could be displayed automatically as a “Complication” on the problem list.

Defining an information hierarchy

So far, information was organised per type of data – exam results with exam results, interventions with interventions etc.

My research however has shown that doctors miss the possibility to gain an overview of a patient. The new structure should therefore show a high level of detail of several types of data and give the opportunity to zoom in on more detailed information from there. There are two ways to achieve this that seem to work well for the doctors workflow.

On the one hand, data can be structured following the idea of the problem oriented medical record (POMR). Showing exam results and interventions under the problem they are related to. This allows doctors to easily observe the development of the different conditions of a patient.

On the other hand, informations can be organised chronologically. This allows the medical professionals to obtain a rich image of the patients current situation.

before: information is organised by type of data
after: high-level information on one screen with the possibility to dig deeper for details

Concept: Split-screen

The idea is to offer the doctors the two different views mentioned above. One part of the screen is dedicated to information organised per problem the other part is a chronological display of data. From each view the doctors should have the possibility to reach more detailed information.

I built several prototypes for different scenarios in Figma, which are now used for tests and further discussion.

What’s next?

This is work in progress. The next steps will be to conduct additional usability tests with physicians of different departments of the hospital and to further develop the visual language.