Case Study 1: IRIS for Health
Navigational Whiplash
InterSystems
Background
I am helping an integration engineer connect the different systems in a hospital and investigate connection failures. A physician may request an x-ray on their system, and that request needs to be received by the x-ray department. When the x-ray department performs that x-ray, those images need to be sent back to the physician. There are thousands of messages being sent in a hospital every day–from a nurse requesting a meal service for an inpatient to the billing department processing insurance for patient discharge. This is interoperability: and when it breaks, patient care suffers.
​
This case study is part of a larger project. Click here for an introduction.​​
Setting the Scene​
In this case, Jennifer has connected the x-ray department to the physician's office. She routes the data through a "logic endpoint". This endpoint determines which physician office the data will send to. For example "if the data contains the tag "Dr. Morris", it will be sent to Dr. Morris's office. Furthermore, the logic will also transform the data. The x-ray department records their patient IDs with a prefix 1-12345. However, Dr. Morris's office records the IDs as 12345, so that prefix needs to be removed.
Problem
Jennifer needs to gather information to troubleshoot, but this information is scattered across many different areas of the product. Furthermore, prospective customers always notice the scattered information across different tabs and constant clicks.
Jennifer has learned that x-rays aren’t making it from the x-ray department to the physician. She suspects it’s because the ID prefix isn’t being removed.
To investigate, she double-clicks the routing endpoint responsible for routing data from the x-ray department to the physician. The system opens a new tab that shows the routing logic. Each piece of logic contains a transformation. She starts to double click each one, opening a new tab each time. Five tabs later, she finds the transformation she’s looking for. But she’s not done: before making changes, she needs to check where else this transformation is used. This information exists on a different page in the product. In order to do this, she’ll need to open the main menu on a new tab, then open a table showing all connections in a new tab.
Why This Matters
Jennifer is constantly navigating to a new page every time she needs new information. She quickly loses her orientation in the app, and takes multiple tries at clicking on the original tab she needs.
Solution
I made one page serve as the "anchor" page. All other app pages are accessible from the anchor page.
The routing logic now visually expands to show the rules and transformations embedded within. For the first time, Jennifer has a visual of how the transformations connect to the rest of the system.
Instead of opening a new tab to see the transformation details, it will open in a preview panel that splits the screen in half. The user can adjust the panel height or open it in a new tab to work on it in a full screen. Jennifer can stay in her main view until she decides to work in a new tab.
Impact
This first redesign established a new navigation standard across the product. It reduced the amount of tabs that needed to be opened by 85% and reduced the number of clicks by 66%.
This change improved users’ ability to understand system relationships. A few users commented, “This makes it much easier to visualize where things are going”. Our sales engineers commented, “Thanks for fixing the tabs problem”.
​
This case study was part of a larger project. View the next case study.