Background

In my last role working as a house officer in Surgery, I was the most junior member of the team. Therefore, I was often responsible for communicating between departments to arrange things like theatre pre-op assessments, scans, operating theatre space, and getting medical advice from other hospital specialists. In the culture of this hospital, most of this was done by phone rather than e-mail.

Frequently, when I and my colleagues needed to make phone calls, there was unnecessary friction and delay. The telephony setup had some obvious shortcomings, this despite every member of staff carrying a personal mobile phone.

THis is an example of what happened at one of my previous roles, but my experience there was in common with multiple hospitals in which I have worked throughout the UK.

Causes of Delay

The typical workflow is as follows:

1. A task requires user to call a department or individual.
2. Find the department's extension number (usually four digits).
3. Dial the department.
4. Complete the task.

A hospital has many different departments, and the ones we call frequently we tend to remember the number for. For others, we need to find a source of information. Remember, we are using landline phones.

Indeed, in this hospital, this simple task could become a blocker to progress in some circumstances. There few a few ways to get in touch with a department for which we didn't have the contact number.

Switchboard

The definitive source for departmental numbers was the Hospital Switchboard, an actual department staffed by people who could put you through to the person with whom you needed to speak.

(To those of us living in the 21st century, this probably sounds a little anachronistic. That's because it is, lots of things in hospitals are.)

The typical workflow for contacting a department for which you didn't have the extension number involved:

1. Call the switchboard, wait for them to pick up.
2. Ask to be put through to the department.
3. Be put through.
4. Phone rings.
5. Other department picks up.

I identified a number of issues here:

• The switchboard department was usually quick, but could sometimes take up to several minutes to answer the phone at peak times. (Typically these departments are also responsible for daily tests of emergency pagers, and for routing calls from external sources, such as family members looking for patient updates.)
• The switchboard department would usually just connect you to the department you requested. They typically wouldn't tell you the extension number unless you asked. If given this, users could then dial the department they needed directly, bypassing the need to call the operator.
• Sometimes they would make mistakes and connect you to the wrong department.
• Sometimes they could help you find the right department in a more creative way than would be possible by just looking at a list (e.g., the user doesn't know the exact name of the department they need).

But ultimately, we're just adding another person into the chain of making a telephone call, a person who can become busy and make mistakes.

We can compare this to when you use your smartphone in your home life. The process is infinitely simpler:

1. Find contact in list of contacts.
2. Press button to dial.

It doesn't include another person in the process. It doesn't involve a second person. 99% of the time, another person isn't needed.

Printed Directory

Alternatively, printed lists of extension numbers did exist in some offices, usually in the form of an 8th generation photocopy with some handwriting added for updated or changed numbers. These were often incomplete, outdated, or otherwise difficult to read.

In my role, I was often moving between different departments in the hospital, so would often get caught out without access to one of these.

To my knowledge, no widely available electronic copies of the hospital phone directory existed, and no hospital department claimed responsibility for maintaining these.

So where there was an attempt made previously at establishing locally available telephone directories, they appeared to be scattered single person efforts.

Telephones are expensive!

If we look at the initial workflow, the step after obtaining the extension number is to call it. In healthcare straightforward things often aren't.

Most hospital clinical wards, have a surprising lack of telephones for the number of staff working there. These wards have a number of telephones in one or two shared desks or spaces, available for all the department's clinical staff to use. Two or three telephones per 10 staff was typical. Additionally, these phones received calls from other departments, and often had family members placed on hold while whoever picked the phone up went to find out how a patient was doing.

So what? Why is this important? Well this hospital, like most, runs on an internal telephone system. Extensions must be dialed from an internal phone. There was an external number from which one could dial internal departments, but it was not well known or publicised. Indeed, I didn't know about it until after the first version of this project has been completed,

So frequently, when needing to make a call, clinical staff will find all phones in the immediate vicinity engaged. Much like my mother waiting at her street's communal telephone as a child, the choice is do something else and hope the phone is free when you get back, or, if the call is urgent, sit and stare at the current phone user until the phone becomes free. Otherwise, you could walk to another department to use their telephone (but they don't like this).

Problem Statement

So with that little description out of the way, we have our identified shortcomings to address

1. The Switchboard department was sometimes unable to provide fast connection to another department at peak times.
2. No credible or maintained alternate directory of internal telephone numbers existed.
3. Those printed directories which did exist were inconsistent in their content, and barely legible.
4. Those which did exist were kept on certain desks, and therefore not available to staff who don't know where it is kept in a certain department, or are otherwise in transit and could be making a phone call.
5. Low availability of telephones, and no obvious way for staff to use their own phone to contact internal departments.

Nothing groundbreaking, I think we can handle this.

Solution

The solution should provide a remotely updatable telephone directory to all clinical staff, allow them to make calls from their own phones, and be accessible from anywhere. Luckily, this century, most people carry a mobile phone with them, which s our obvious target.

Also touched on is the concern about maintainability. I wanted this to be simple, easy to hand off to someone else to maintain if needed, and provide users a way to crowdsource any changes or issues (e.g, a dept moves and their number changes)

SwiftSwitch, mobile web app.

To address the problems, I created a mobile first web app.

Having been inspired by other similar solutions in the UK, I opted to build a searchable telephone directory. The app features live text search, and clickable entries, which will dial the hospital department from your own phone via their external line endpoint. On pageload, the application generates its list from a csv list of telephone extensions. It generates tel:// links for each entry, allowing dialling internal numbers from the user's own mobile phone. This works because the hospital owns a common number stem where the last few digits route to different departments. (e.g. 01234 33xxxx, where the xxxx is the departmental extension. This sort of system is surprisingly common in hospital throughout the UK at least, presumably due to hospitals being an early user of the telephone system.)

The system is designed to concatenate numbers from constituent country code, common stem, and extension number. This was important for portability between countries and hospital systems.

If the only external line endpoint is of the type where it plays a message such as "please enter the extension, followed by the # key", this can be supported too through the use of ',' in the generated tel:// number, indicating a

Finally, normally dialling external lines are supported too, and highlighted in a different colour.

Access is protected in the MVP via a single shared username/password among staff.

Technology

In building this app I had a few goals in mind.

• I wanted it to be fast to develop and as simple as possible, use minimal frameworks and minimal backend.
• I wanted it to be easily maintainable and be able to be passed on to someone else if needed.
• I wanted to be able to build an MVP very very quickly.
• I wanted it to be non-accessible by the general public.
• I wanted it to be easily adaptable to other similar phone systems.
• I wanted it to be portable, accessible at all times to anyone who needs it.

By keeping things very simple, I was able to create this in only an afternoon.

Speed

By using this app, we are reducing the variability in the time taken to make a call to someone. In a best case scenario, calling the human switchboard may be as good as or slightly slower than using the app. But in a worst case scenario (going from my own experience), the app wins hand down. Although the worst case scenario is not the average case, the use case of hospital telephony needs hgih reliability for potential clinically urgent or emergency scenarios.

Choice of Technology

I decided to go with a very simple web-app for ease of development and cross-platform availability. It includes assets for saving to home screen with a nice icon. The 'app' is basically a simple js script to generate DOM items and concatenate phone numbers from data in a plain csv file. There is also js incorporated to allow for live search, and a basic external CSS library, but little else. It includes a minimally responsive design for use on desktop and phone screen sizes.

Access is protected by HTTP basic auth. From a usability point of view, I think this is acceptable now that iOS finally allows saving these passwords.

Right now, there is only one shared 'staff' username/password combination. For the purpose of getting an MVP off the ground, I think this is fine, though not ideas. The sensitivity of the data is low, but equally, it may be problematic for telephone availability if any member of the public could dial any individual hospital department at will. (indeed, in an ideal work, these calls should probably be screened)

Individual user registration/account flow is something I would consider adding later. I am wary of adding friction for staff wanting to access what is really a simple tool. However, doing so would improve security and add ability for features like roaming favourites and social/community phone number reporting. Perhaps a good compromise would be to not require use auth/login when connecting from a hospital machine or hospital staff network.

For now, in the interest of minimal complexity and speed of development, reporting new or incorrect numbers is just done by adding a button at the top of the list which sends me an email.

Outcomes

People I showed it off to were happy, and many started using it in their day to day life. By eliminating an entire step in making phone calls, times taken to complete these tasks is reduced anywhere from 10 seconds (average time to call switchboard, get an answer, and be put through to the target department) to up to several minutes (peak times). When several calls are made per day, maybe we save 4 minutes per person per week.

However, we now have a tool which makes calling a desired department more isntant and available. At peak times, things are available, which is reassuring to staff. It addresses the situation where all work must be stopped until a phone becomes available. It reduces irritation and disruption. It is an obvious solution to an obvious problem. And it has a pretty icon.

I am pleased to have pushed out a perfectly functional MVP which has improved the lives and productivity of colleagues.

Future Changes

Of course this is the MVP. There are a few obvious changes I would make.

Progressive Web App

The last cached data should still be accessible if the user's phone is offline.

User account system:

I am reluctant to require user logins and the associated ux friction for what should be a very simple tool. However including this would allow for some useful features and better data security.

Collaborative reporting:

A way of reporting number issues, and for other uses to support or dispute people's reports.

Usage Analytics:

Popularity of call destinations could allow a list ordered by most popular. Prompts after a call could ask if the phone number was correct, and thereby encourage better reporting of errors.

Per-user Favourites:

Should be at the top of the list for each user (either serverside/login based or cookie based)

Why not get buy-in from hospital IT?

Honestly, I liked the idea of building on top of the existing system, and within the system's limitations. In past roles I have found getting buy-in difficult, and not something I could afford to devote work time to as someone in a clinical role. Call it a kind of guerrilla IT. Most people working in hospitals feel very disempowered to effect any kind of change to small things affecting work conditions (we were able to get an additional phone after a year of asking). But yes, for this to actually have any momentum and longevity, I really should get hospital IT dept buy-in.