Video Visits at Scale


How to Connect Hospitals Working In a Silo?

I was tasked with designing a platform that could scale video visits across an entire hospital group and connect to the existing systems used by hospitals to manage inpatient visits.

These systems are unbelievably closed, opaque, and are generally deployed with custom features that make them unique. An hospital group (health system) is often a consolidation of many clinics and hospitals formerly independent. Each of them uses system working in a silo and huge resources are spent to get them to work together.

Many of these systems have built-in video conferencing solutions. But a patient who is hospitalized in one clinic can’t have a video consultation with a doctor in another clinic because both clinics use different systems.

We had to conceive a video conferencing solution that could run in parallel to any hospital system and would be agile enough to adapt to any type of visit workflow.


Inpatient Visit: The Specifics

An outpatient visit involves a sequence of interactions with multiple staff members (e.g. front desk, nurse, doctor). The number of interactions and the task performed is a function of the type of visit performed. And the sequence of interactions is enshrined within the visit management systems used by the hospital. The queue of an inpatient visit had considerably more variables than our "classic" video conferencing system could cope with.


The Limits of Video Conferencing

Our video application handled visits in the same way a single doctor would receive patients in her consultation room. She called the next patient in line when the previous patient had left. If she had to leave the room for a nurse to perform an examination she had to contact a specific nurse, ask the patient to step out, let the nurse in, and only then the patient would be called back. It was a "one doc - one patient" interaction. We needed to make it suitable for an "any doc to one patient" interaction.


Give Them A Room

We abstracted the inpatient visit to its most essential components and found that the central component of a visit was the patient. Inspired by the final step of a hospital consultation— where the patient is left in the examination room and several staff members take turns to enter the room and perform a specific task—we found that every patient should have their own personal and permanent video room.  


The Appointment Calls The Shots

Then we found the appointment to be in fact the organizing entity that passed on the key to the room to the relevant staff. By retrieving an appointment definition from the hospital we could line up all the participants according to their roles and order of appearance. In doing so we would minimize human input regarding transfers of session ownership.

We now needed to organize a queuing system that would be robust enough to handle the plethora of potential issues related to video conferencing.


A Board Game about Queues

We modeled the visit--in the form of a board game--to test realistic interaction scenarios.

We then introduced typical issues associated with video conferencing and medical visits. We accounted for technical problems but also staffing issues. We found inspiration in the way large airports manage flows of staff and passengers. It was the first time anyone in the designer team was genuinely excited by TSA queues.


Patients Who Vanish And Reappear

We had to make a queue system that worked for a patient who could unexpectedly disappear from the queue or the consultation. A hospital visit is emotionally charged, so patient and doctor don't have much patience for troubleshooting teleconferencing issues.

We noticed that when there was an emerging problem during an in-person visit, troubleshooting was done organically: if a doctor failed to show up the nurses and admins would talk to each other and make calls to resolve the issue. With video visits and staff working remotely we needed to integrate a solution to resolve emerging issues.

To manage these issues we conceived a three-tier safeguard:

1 - an interface that informs about the user status, and highlights issues and their known origins

2 - priority lines that help staff reroute patients to where they need to be

3 - a parallel communication channel allowing staff and patients to communicate independently from the planned consultation with messaging or VoiP.  



The final step of this three-month project was to translate the theoretical research into a mock-up that we would give to our health system partners for review.

After building an exhaustive list of experience and feature requirements the team built clickable wireframes that demonstrated the primary paths for handling a visit.

Our intention was to dive relatively deep and produce a mock-up that reproduced a realistic consultation flow while demonstrating how emerging issues would be resolved. We role played a number of scenarios simulating a disconnection, a rerouting, a missing staff member.

The prototype was presented to our our development partners and was well received.

The project was then passed on to a development planning phase and involved a deeper technical assessment of the features we proposed.