top of page

Impacting Melanoma Tumor Boards & Research

01

Introduction to
Teams & Roles

Our Team

Michelle Lee

Client Liaison;
Technical Coordinator

Ginny Zhao

Documentation Lead

Cindy Liu

Research Coordinator

Eric Li

Design Coordinator

Lead the design process of generating concepts from research insights
Create wireframes to conceptualize design ideas
Refine prototypes based on clients and users feedback

Client Team -

Dr. Bryan Carroll

Dermatologist;
Mohs Surgeon

Dr. Amy Blake

Dermatology Resident

Dr. David Xiong

Dermatology Resident

Dr. Scott Mahlberg

Dermatology Resident

Dr. Emma Larson

James Xu

Mom & Baby Goose

Cutaneous Oncology Fellow

Medical Student

Our Real Client

02

In order to provide comprehensive treatment for melanoma, a type of skin cancer, our client, Dr. Bryan Carroll and his team at University Hospitals at Case Western University hold tumor board meetings every week to discuss specific patient cases and determine treatment plans. Beyond such clinical routines, they also conduct research to understand the effectiveness of current treatments.

Considering that our client is not an EHR company, we felt that directly dealing with EHR records might not be immediately impactful to our clients. We also thought changing healthcare privacy regulations to allow cross-center sharing would be outside the scope of an HCI capstone project. However, we did identify an opportunity in impacting how various NCCN centers have different tumor board practices. With this narrowed down space, we set out to create a single digital system that streamlines local tumor board documentation and workflow. By achieving standardization in a local setting, the same process can be adopted at other cancer centers to facilitate future data unification.

Understanding the Problem

In our research phase, we talked with people who coordinate and gather data for tumor boards, three specialists who attend the meetings, a technologist who manages the systems used by the doctors, and three researchers who would like to know the results of tumor boards. The main problem we found out is that there’s a disconnection between the clinical practices at the tumor board and melanoma research, which leads to duplication of work. The isolated processes cost a lot of time and effort for both the tumor board coordinators and researchers. The coordinator needs to sift through various records, charts, and doctor’s notes to compile the patient reports. Meanwhile, researchers follow the same procedures to extract research needed data.

For this digital platform, we ideated several features that can minimize the effort of data entry and facilitate tumor board discussions. Those features included automating data entry and exports, NCCN guideline searching, publications searching, filtering and comparing cases, and retrospective analysis. We created sketches and storyboards to visualize our ideas and speed-date them with specialists to spark conversations about their needs.

CONTEXT

The tumor board coordinator (TBC) needs to prepare this week’s cases that will be presented at the tumor board.

PROBLEM

The patient’s information is scattered across emails and EHR pages that she has to sift through.

SOLUTION

The system guides the tumor board through a form to enter relevant information and formats it into a presentation and PDF report.

RESOLUTION

The TBC selects the final treatment plan decision on the system which automatically updates the PDF report, consolidating patient information in a structured manner.

Storyboard 1

Automating Data Entry and Exports

Storyboard 2

Filtering and Comparing Cases

storyboard2.png

CONTEXT

Specialists gather virtually for their regular tumor board conference.

PROBLEM

The surgeon wants to review past cases in a holistic view and provide a surgical summary for future reference.

SOLUTION

Using the system, the surgeon filters and compares past cases by searching key words, including stages of melanoma or anatomical locations.

RESOLUTION

He now finds it easy to summarize past surgical experiences and even find potential areas of improvement for future cases.

03

Discovering NAVIFY & Pivoting

During our research, we came across a system called NAVIFY that aimed at facilitating the tumor board process. We decided to delve into how NAVIFY works, so we interviewed 3 specialists who worked with NAVIFY and 1 Executive Representative of NAVIFY. After conversations, we found out that NAVIFY does provide some functions that we ideated. Most importantly, NAVIFY integrates with any EHR, making it accessible across departments and eliminating the effort required for data entry and exports. NAVIFY also has features such as clinical trial matching, NCCN guidelines visualizations, and targetted publication searching. However, we did notice a light at the end of the tunnel — NAVIFY does not do everything. Needs such as filtering and comparing patient cases and retrospective analysis of patient data were not included in NAVIFY.

After discovering and exploring NAVIFY, we pulled ourselves up by the bootstraps and generated potential options we could pursue. After several discussions within our team and with our clients, we pivoted to a new goal of developing a database that streamlines the tumor board workflow, makes it easy to store and extract patient data to create research registry, and can be flexible enough to adapt to changes in the NCCN guidelines and allow new fields to be created in the database.

With the newly set goal of transforming clinical melanoma tumor board documentation into research-ready data, we first visualized the University Hospitals' workflow. We observed that two processes are occurring: tumor board report preparation and data extraction for research. These two processes both consist of someone digging through multiple hospital digital systems, including Electronic Health Record, department-specific software, and Google Drive, to gather relevant data. According to our client, there is an overlap in the data for tumor boards and the data needed for research.

Thus, we speculate that it is possible to consolidate the two efforts into a single database — what we are calling, the MELAbase.

Before

After

04

Our next step is to understand the workflows of a tumor board coordinator and researcher and the specific data fields that are needed for this database.

We first investigated the workflow of a tumor board coordinator. We asked the coordinator to bring in de-identified examples of all the things they digitally “touch”, and with these items, we created checkpoints so that they could recall how they got from screen to screen. This allowed us to create a timeline with all of the tasks they complete for the tumor board. To ensure that sure we did not miss any of the coordinator’s tasks and to build off of the work we already did to create the timeline, we asked the tumor board coordinator to print out this timeline, take it to work, and do diary check-ins. Every time they sat down to do a tumor board related task, we asked them to check the timeline.

Understanding Workflows & Data Fields

For researchers, we asked them to bring all the de-identified screens they use and artifacts they make while building a research registry. We found the same doctor’s note (highlighted by purple border) that appears in the tumor board coordinator workflow. Both of them read the same doctor’s notes and extracted some of the same pieces of data such as melanoma stage and pathological diagnosis. This validated our assumption that there was a redundancy in the work of tumor board coordinators and researchers.

TBC

Researcher

Seeing that one-time data entry that would be useful for both the tumor board and researcher, we dived in to figure out what overlapping data fields are between the tumor board reports and a potential melanoma research registry. We conducted a data audit of the two artifacts and listed out all the pieces of data along with their formats. We then made a Venn diagram to illustrate the data fields. The highlighted part is the data fields that the tumor board coordinator enters into MELAbase. From the graph, we noticed that the data needed for the research registry, in general, is more granular.

Simplifies the tumor board reporting process & generates research-ready data

05

Lo-Fi Wireframes & Data Entry Prototypes

After understanding different data needs for tumor boards and research, the question became: How should the data be populated in MELAbase? After a discussion with our clients, team MELA decided that this platform, MELAbase would not collect all the information relevant to researchers; rather, it would give them a headstart and pointers for where to look. Although the tumor board process does not generate all the data fields that researchers are interested in, the ability to quickly access the tumor board data would greatly reduce the researcher’s workload. In particular, we envisioned the tumor board coordinator being the primary user, where they enter well-defined data fields found from various sources. Later, the researchers can quickly access the aggregated patient data when they are doing research.

Since MELAbase would primarily store tumor board data, we tried to hone in on the entry format for each data field of the tumor board report, so that they can be recorded in a structured way that would be easily searchable. We started our prototype with Google Forms, breaking down the minimally formatted word document template into sections. We continued the iteration with Qualtrics, which allows for more flexible and dynamic formatting. We conducted usability tests with 4 physicians and researchers in order to test out: 1) whether we covered all the data fields, 2) whether they are formatted in a structured way, and 3) how to further parse some data fields.

Lo-Fi Wireframes

Data Structure & Formats

06

Finally, we identified some key interfaces that we wanted to focus on for our prototypes, including the patient list, individual patient records, and tumor board page, as well as some key interactions which include editing/updating patient information and searching/filtering patient cases. We went through three rounds of iterations and user testings before settling on our final prototypes, which have three key features targeting our user needs: reducing clicks with autogeneration, well-organized data fields, and powerful searching,

Final Prototype

1

2

3

Reducing Clicks with Autogeneration

Well-Organized Data Fields

Powerful Searching with Key Words

Prototype Demo

Researcher searching for patient cases

Tumor Board Coordinator filling out form

Patient List

  1. Clicking on “Add a new patient” takes the coordinator to an empty patient form (edit mode).

  2. Clicking on “Sort by”, the coordinator can sort the patient list by recently add/edit (default state), patient last name A-Z, or patient last name Z-A.

  3. Clicking on an exising patient takes the coordinator to the patient’s individual record (read mode).

  4. Clicking on the “Name” tab does the exact same sorting function as in the “Sort by” menu: clicking once sorts by A-Z, clicking a second time sorts by Z-A, and clicking a third time returns to default (recently add/edit).

  1. Clicking on the “Status” tab, the coordinator can filter the patient cases by specific patient status(es), which makes it easy to bring up certain cases for update.

  2. Typing in “pathology report” in the search bar adds a special “PATH” bracket that looks up filters (within the PATH bracket) only within the pathology report section of the patient record.

  3. Filters can be customized with specific criteria within the search function, and can be removed easily.

  4. Alternative search options will pop up to match the word(s) the researcher types in, with the top being the one with the most number of cases. For certain search options the researcher can customize by entering certain ranges or selecting certain criteria.

Tumor Board

  1. Clicking on the checkboxes for the upcoming tumor board, the coordinator can assign the patient with the departments that need to be consulted with for that patient.

  2. Clicking on the “three dots” to the right of the patient, the coordinator can edit the patient record, move the patient to the top of agenda, remove the patient from this agenda, or change the conference date for the patient.

  3. Past tumor board agendas are in read-only mode and are no longer editable.

  4. Clicking on the “Present” tab, the coordinator enters the presentation mode of the upcoming tumor board (in our future roadmap).

  5. Clicking on the patient name also takes the coordinator to the patient record.

  6. Dragging on the “six dots” to the left of the patient can move the patient to another place of agenda.

Patient Record

Edit Mode

  1. Clicking on the “+” tab creates a new page with customizable title for this section for every new evaluation.

  1. When the coordinator selects the T, N, and M stages, the overall stage and melanoma 5-year survival rate will be autogenerated according to the NCCN guideline.

  2. After selecting the suggestion for this patient, a keyword label that summarizes the suggestion will be autogenerated for ease of reference and searching.

Patient Record

Read Mode

  1. Clicking on the “three dots” next to the patient, the coordinator can edit/update patient record (go to edit mode), export the patient record as a report, or delete the patient record.

  2. The overall stage and melanoma 5-year survival information is brought to the top in the read mode and stays fixed (along with patient name and ID) for ease of reference.

  1. Typing in keywords in the search bar above the pathology report enables searching through the report.

  2. Clicking “Highlight all”, keywords in the search bar can be highlighted with a color.

bottom of page