Medical Entities Creation Flow
What was the problem?
Performance medicine at its most basic is centered around recording data. Clubs have a legal obligation to document all medical data and notes on their players, and many are required by their league to use a specific EMR. The work conducted by doctors, physiotherapists, athletic trainers, and others in these clubs consists of both hands-on work with athletes and recording of that hands-on work, as well as injuries, notes, diagnostics, and more. Unfortunately, it is the latter aspect that results in late hours, with practitioners spending hours in the evenings catching up on these notes and medical data that must be recorded. In order for performance medicine to have a positive impact on the lives of these practitioners and justify the cost of change, we need to streamline these processes, tailor them to the specific needs of each sport, and provide them with more time in their day.
Why was it so important to get this flow perfect?
Many EMRs used by sports are traditional clinical EMRs which are not suited for or designed for the sporting environments in which they are used where practitioners require different information around the event which caused an injury.
The previous EMR capabilities in the Kitman product relied on long modals with all fields and details being mandatory. During research we found that this not suit our users needs, that they weren’t always sure what an injury was when it happened until scans were ordered and therefore some data was either being guessed on creation of injuries or some injuries never made it to the system. From conversations with our data science team there were also issues with the quality of the data from the guessing and missing data, but also from how the form was set up.
What were the biggest issues to solve?
There were three aspects to how we allowed practitioners to create items that needed to be figured out:
Format
We knew from our customer research that the long scrolling modal for creating injuries wasn’t working but we also learned that users wanted to reference other data while creating injuries, notes, and diagnostics. We explored a number of different patterns including cards within the the athlete or squad page, as shown in the gallery below, iterating through each quickly while highlighting the pros and cons of each format before deciding on a side panel.
The side panel allowed users to navigate through the EMR and reference other items while in the creation flow as well as allowing for the future capability of collapsing to allow them to open another side panel and create something else. This was useful for when they’re in the middle of writing notes for one athlete when another comes to their office, allowing this multitasking and jumping between tasks mirrored how they worked day to day rather than being more rigid in their flows like traditional EMRs.
Content
In addition to finding a new way of housing the creation forms we also needed to take a look at how the data was inputted. We knew from our research that the form itself was too long so we decided to look at how we could make it more managable, breaking it into contextual sections. We knew injury surveillance looked at what happened and how it happened so they were the logical starting points as well as the initial information of whether it was a new injury or illness or a recurrence, the athlete affected, and the date. We had also heard from users that they wanted the ability to add items at the time they were creating the injury and customise this on an injury by injury basis, whether it be a note or a diagnostic, so we added an additional information section where these could be added. This left us with four sections:
Initial details
Diagnosis information
Event information
Additional information
Location
In Kitman’s previous EMR capabilities as well as traditional EMRs the practitioner has to enter the athlete/patient’s file in order to create an injury or note etc. This works fine in a GP practise where doctors are seeing patients in 15 minute blocks and focusing on that person and their notes. However, in a sporting context where athlete’s are approaching the practitioners in the treatment room or in the hallway having to go into their file adds clicks and time that these practitioners don’t want to spend waiting on things to load.
For this reason we looked to allow users to create these notes at the three different levels in the EMR:
On the roster/squad level
At the athlete level
Within individual injuries, diagnostics, etc
Testing - did we get it right?
Moving all creation flows from modals to side panels was a big change and not one to be taken lightly so multiple user tests were carried out. The main questions we had for testing were:
Is the form intuitive?
Are the sections/questions in the logical order?
Is the side panel preferable over a single page form?
Should the editing of injuries occur in the side panel or on a page?
With editing there was a concern that reopening the side panel to edit could confuse the practitioner, especially with the different sections. Inline editing on the injury overview page was seen as a better solution, however, with engineering time being at a premium we needed to be 100% sure that building the edit functionality on the injury overview was what customers wanted.
Our testing found that the side panel was the preferred option for creating the injury, with 5 of the 6 practitioners selecting that option, but all 6 choosing the inline edit option as the preferred pattern.
Result
This flow was implemented for all entities in performance medicine, including injuries, illnesses, notes, diagnostics, concussion assessment, etc. User feedback was very positive, with practitioners noting the ability to create these entities from multiple places was particularly useful. They also liked the ability to reference other data while creating new injuries or notes. Users appreciated the way the form was divided into four sections for injury and illness creation, as it allowed them to focus on the diagnosis and event information in context.
