When something unexpected happens regarding a patient at a hospital, an emergency is called. If the emergency is so severe that the patients life is on the line, this emergency is called a ‘code blue’. A team of experts will be notified and will arrive on the scene to help unit staff to stabilize the patient.
Our first design challenge and sprint was to consider, “How might we improve the Code Blue team process to be more efficient and effective?” This challenge was undertaken by three groups of three to four students. Our proposed interventions were delivered ten days after our researched was kicked off.
The course of events
9/17 – Project Brief with Johns Hopkins staff
9/21 – Interview Sprint
9/22 – 10/1 All the good stuff (minus 3.5 days at A Better World by Design )
10/1 – Presentations
My favorite part about this kind of work is being invited to dive deep and fast into unknown territory. This project embodied that wholly. We were introduced briefly to the project on a Thursday afternoon. This gave us some time to form some preliminary questions and, in retrospect, would have been the best time to do some comparison research.
The following Monday we were thrown into a very cold room and delivered interviewees in 30 and 15 minute increments for several hours. Through this process we interviewed as a large team and then broke into small groups so that we could conduct more interviews at one time. Before the interviews started we had already determined our team breakdowns so we could distribute ourselves amongst all of the interviews. Exhausted and with blood circulating slower than normal due to the frigid temperatures, we finished the day and regrouped for the rest of our work in small teams.
My team approached the vast amount of information we gathered through a few frameworks, but our main way of looking at the content was through a timeline. A code event can last for 30 min to a few hours, but most of what happens and most of the room for error and confusion occur in the first 15 minutes. We mapped these moments out on a timeline, noting possible points of intervention, points we had particular ideas about and then ultimately the major points on the timeline that our proposed intervention would impact.
In addition to this timeline framing we also…
Identified major questions we still had and articulated assumptions that we needed to work with
Produced a small affinity diagram from within the major points of error/confusion and identified themes
Brainstormed potential interventions
Created an overarching ‘How might we…’ statement that embodied our holistic vision for intervention
How might we capitalize on the organic self-selection process that is critical during a chaotic code event to clarify what roles have been captured with minimal impact during the most critical moments of time?
Articulated specific principles to keep in mind as we designed our intervention
- Preserve organic self-selection
- Define distinct roles
- Indicate who is serving each role
- Assure that leadership roles are filled and by only one person
- Indicate what roles are not filled
- Incorporate a clear Code Coordinator role
- Maintain flexibility of roles for passing off responsibility if necessary
- Minimize added process/time to the existing complex system
The intervention we ultimately came up with addressed the problems that surround definition and clarity of ‘soft roles’ during a code event. Each code event can include 24+ people in and around the patient room. Amongst those people are the code team who are all there to serve very specific roles, but equally important are the unit staff. They are the first responders and know the patient, the floor and the current details of the medical emergency. Our research uncovered a sense of confusion over who was serving what unspoken roles which lead to inefficiency and the potential for error.
We defined 6 key roles that should be accounted for during a code event, defined what responsibilities those roles would have and locked two roles to specific job titles. The rest of the roles can be organically selected by whomever feels up to the responsibility or arrives in the room first.
We designed flexibility into the system. One of the newly designed roles is responsible for helping with the implementation of this new system. It is their responsibility to make sure that roles are assigned and that folks that have stepped into that role have been identified. They are also responsible for clearing out the room when all roles have been assigned and no more help is needed.
The system is anchored around the idea of visual identifiers and physical objects. This has four main functions.
- It clearly indicates what role an individual is playing.
- It allows a person to scan the room to identify who is playing a particular role.
- It requires the individual filling that role to acknowledge their responsibility.
- It allows new people entering the room to see which roles have not been taken yet.
In considering how to build this, we rallied back and forth dozens of ideas and challenges. We considered:
- material: stickers, badges, sashes, arm bands, spray paint, stamps, lanyards, areas on the floor to stand in
- location on the body/visibility: one side only or visible from all sides
- ease of putting the object on: clasps, stretching, over the head, around the arm, peeling stickers
- location in the room: on the cart, on the cart initially and then placed elsewhere, permanently displayed near the door or with individuals before entering the room
- location on the cart: side, top, raised above the cart
- how it was attached to the cart: pockets, hooks, clips
- sanitation: disposable, washable, potential to dangle
Our initial prototype is, in short, double sided disposable badges. They are attached to the side of the code cart (present at every code event) using tight clips. We imagine clips that work like the clips that are used to display small bags of chips and other products at grocery stores. There is no spring mechanism to release, juts a firm pull. Behind the badges is a chart that indicates where each badge goes and clearly indicates it’s absence and therefore that the role is already being covered.
Each role has a different color associated with it, a 1-3 character letter code and the full role title printed on it. Additionally, we imagine an opalescent treatment to the white letters that would make the characters stand out even more.
This was a fast project and there was evidence of that the whole way through. While I was pleased with how in-depth we went with the timeline, problem definition and the nuances of our prototype, we had two clear points of frustration.
We struggled with the huge gaps in our knowledge. The research process was fast. Our method for dealing with this was to articulate the things we didn’t know, make assumptions and design for those assumptions. I think this was a reasonable process decision for a ‘design activity’, but it wouldn’t have held water if the results of our work were going to a paying client. That said, the gaps in our knowledge would have been preventable if the project had been more than a rapid sprint to the finish line.
As we began designing the specifics of our intervention, we questioned everything. About three quarters of the way through it seemed that there were flaws with every element of our design. This too would have been easier to accept if we saw a future of prototyping, testing, modifying, but this project was a one shot deal. The pressure of coming up with the best thing we could took it’s toll on our ability to commit.
If I needed to learn more about code events going forward, I would:
- speak with code event members that were new to the process
- participate/or watch a mock code
- visit the simulation center
- dissect the code cart
- watch someone fill out a shift chart
- shadow a code dispatcher
- sit around a unit long enough to observe an actual code event
- interview code team members at another institution
- try to navigate somewhere complicated by myself
- take an in depth tour of the facilities with the security team
I would talk to the purple people.