Enabling the future of medical reports
Background
Despite great progress in medical technology over the past 50 years, some things remain unchanged. Writing and collaborating on medical reports and diagnoses for imaging exams are two examples.
Reports are commonly written or dictated in plain text and saved in proprietary systems or and even Word files.
To prevent repetition, doctors often have their own local ”library” of pre-written reports as templates for common diagnoses.
A radiologist's learning curve is quite long. Writing reports takes years to become second nature.
Given the different writing styles across individuals or institutions, extracting and comparing reliable data or statistics from a large volume of reports is practically impossible.
Learning curve • Scale • Productivity • Errors and imprecisions • Research • Data
A first version of Smart Reporting's product was born from academic research in the field of structured reports.
In this model, a decision tree for each type of exam, body part and diagnosis is used to write the report, like a conditional questionnaire.
Its reception at demos was extremely positive and the company received its first rounds of investment.
This initial idea turned into an outstanding product with incredibly powerful features, but it also had limitations that had to be overcome.
This was the context in which I joined the company.
Onboarding and first impressions
Joining Smart Reporting was my first contact with this domain and most of these concepts.
There was a lot to learn and understand before being able to actively contribute: the routine of doctors, how the product worked and why it was built that way.
Interviews • Demos • User journeys • Stakeholder mapping • Empathy map
Key Findings
It was evident that some constraints were technical, such as making the the content more scalable and fixing a number of usability issues, but others were cultural or conceptual:
Some advantages of the product did not seem to outweigh such a paradigm shift among more senior radiologists.
Finding 1
There was JUST ”too much UI” on the existing product. It was intimidating and dense.
In order to succeed, accommodating for a broad spectrum of professionals, the starting point of a report should be as close as possible to a blank sheet of paper.
Content should be the star while support for speech recognition and writing structure facilitate in a way that is as adaptable, intelligent and integrated as possible.
This clutter was a known issue and there were already some ”zen mode” concepts to fix this.
Finding 2
Additionally, it was important to be able to use as little screen real estate as possible.
The reporting software competes with the space needed to visualize patient information and exam images side by side – even though most doctors use 2 or more monitors.
Finding 3
The existing interface needed a lot of scrolling and clicks to be used.
As the majority of radiologists have one hand busy while operating a SpeechMike microphone, this system should not rely on the classic mouse + keyboard pairing, and instead be usable with any combination of these devices.
Additional Requirements
Some features were already planned and had to be taken into consideration for this new version, such as:
The editor was going to be embedded in the software suites distributed with the MRI/CT machines of different vendors. In this case, the responsiveness and the real estate used by the editor would be an additional constraint.
These software suites and new AI tools would inject content into the report, which must be clear and visible to users.
Challenges
From these findings and requirements we – PM, key developers and myself – had many ideas but also even more questions that weren't easy to answer.
The biggest risk on this project was that there wasn't a good way to prove most of our assumptions and hypothesis without investing months of design and development.
Not many things could be tested or validated with static screens, interactive prototypes or quick-and-dirty proof of concepts
We did all of this, but real success depended on building something that brings more value and is useful and usable in real practice.
Ideas and solutions
1. Sidebar
The sidebar was redesigned to be an interface element entirely based on progressive disclosure: selected or inserted content can lead to new questions and to more details that weren't initially visible. It works as:
an input element
a navigation menu
a summary of the report
We presented and iterated on this idea multiple times with senior radiologists and some of our users (quali).
This milestone was enough to reach parity with the previous version (mouse or keyboard input) and a foundation for the next versions.
We presented and iterated on this idea multiple times with senior radiologists and some of our users (quali).
This milestone was enough to reach parity with the previous version (mouse or keyboard input) and a foundation for the next versions.
2. Interactive Values
Different parts of structured text also have different superpowers: in some cases, a measure or value is expected, in others, one or multiple values can be selected.
Additionally, there are interactive images to help find certain diagnoses.
This feature adds an important redundancy: it allows users to add and select (structured) values both from the sidebar and directly from the report, using the mouse or keyboard.
Support for dictation was implemented in parallel.
3. Context-aware autocomplete
The editor also provides contextual guidance as the doctor types or dictates text, behavior similar to a modern code editor.
Following the structure for the type of report being written, the editor only suggests options that make sense within each section of the text.
Testing
A usability test lab was built within Smart Reporting and tests were conducted by a third-party company.
Participants were gathered from different hospitals and clinics in Bavaria and varied in their responsibilities and levels of experience.
In addition to the final reports with recommendations, the sessions were recorded from three perspectives – participants, screen and eye-tracking – which provided us with important insights for the next iterations.
The overall results were very positive.
Outcomes
The Report Editor has been successfully integrated into GE and Siemens Healthineers systems – securing long-term revenue and partnerships.
Full or partial reports can be inserted or extracted in real time – such as measures, patient information and diagnostic suggestions by AI – through multiple types of integrations (FHIR, HL7).
Other vendors are in the process of integration. The Report Editor is also being integrated with other Smart Reporting product lines.
Conclusion
The biggest goal of this project was making a great editor for both senior and junior doctors – a feeling that ”there's no way back” to other tools. I think we were successful in that.
All the powerful features were built around the report. For the most experienced doctors, it is as familiar and straightforward as possible and works as an aid to their workflow, such as a technical reference and a proof reader.
For less seasoned practitioners, it shortens their learning curve and let them report as fast as a senior doctor dictating.
It also opens space for AI and RIS/PACS integrations and data analysis.
Some learnings
It is great when it is possible to leverage customers and their resources as co-innovation partners.
There are some cases when even the MVP is still quite big. Creating strategies to reduce risk is key, as the cheapest software is the one you don't have to build.
In projects like this, pairing with developers is the only way to get all the micro-interactions, behaviors and use-cases right.
”Never” design or implement a text editor from scratch. The same goes for dropdown menus and other system controls.
Supporting legacy browsers (IE 11) and legacy systems takes time and is often underestimated.