Luke is a Implementation Engineer at Vocera, it's his job to design databases and build systems for Vocera's customers. He has also trained many of the partner engineers that are out in the field right now, myself included. Given his knowledge and experience, how could I refuse when he graciously offered to write the article below? From here on, in his own words.
Vocera Databases – Who’s Where & Why?
Yea – this post is long. Not War and Peace long, but a Vocera database is a topic huge topic. Vocera systems have a few key components that need to function well together in order to provide a great end-user experience: a pervasive wireless network, great training, and one component that seems to receive the least amount of focus when setting the initial system up – the database. The database in a Vocera system is it’s heart and soul. How well the system functions relies significantly on how well the database is structured and maintained.
I’d like to take a moment to discuss some Vocera database practices regarding the structure. For a Vocera database, there are a few key concepts that contribute to a healthy, scalable, and efficient system:
- Departments, Groups, Group Nesting, and Group Membership
- Call Flows and Call Forwarding
Setting up a Vocera database properly does not take any more time to build, and positions everyone involved for success with the system. A properly structured Vocera database will be easy to administrate and ready to support sustained growth. Admittedly, the examples below are all healthcare related, but very applicable across all industries. Here are some of the keys to Vocera database success:
Groups & Group Membership
Let’s start with Departments and work our way “down”. Departments, simply stated, are they are large groups of people working towards a common goal (typically) in a geographically similar area (a unit/department). Departments can usually be sub-divided into smaller groups by role/position as not everyone in a department usually does the same job – a role-based group. There are typically nurses, techs (nursing assistants), unit secretaries, physicians, etc... Each with a somewhat specific duty to perform. Here are some assumptions and schema tricks to setup each unit/department:
- Departments only have role-based groups as members (almost never users)...
- ICU (department) only has members ICU Nurse, ICU Tech, ICU Unit Secretary, etc...
- Role-based groups (ICU Nurse, ICU Tech, etc.), typically has users as members, and maybe other groups as well, but do not contain special (managerial) role-based groups (ICU Nurse Manager, etc.) as members. This type of group can be static or dynamic with regard to the users that are members.
- Special role-based (managerial) groups (ICU Nurse Manager) are nested as members of the departmental group, but not a member of the “associated” role-based group (ICU Nurse – see the bullet directly above) For example, the ICU Nurse Manager group is not nested within ICU Nurse. Why? Typically, the members of special (managerial) role-based groups have ascended to this role and do not want to receive general calls to the “associated” role-based group, and if they did, would probably not be much help due to their meeting schedules. As such, the ICU Nurse Manager would typically not want to receive calls destined for the ICU Nurse group...
Another key point - almost every department (in healthcare) has a "Charge" or “Supervisor” role in some form and/or title. By default, allow an entire group within the department to add/remove themselves from their particular "Charge" group (dynamic role-based group). For example, all ICU Nurses can add/remove themselves from the ICU Charge Nurse group. By making this permission somewhat broad and allow the entire "nurse" group to add/remove themselves even though there may only be a subset of nurses that will fill this role - it dramatically simplifies administration as the staff that can fill this role may shift regularly...
Group Nesting
Now that we have discussed the different group types, let’s chat about group nesting. Why do this? There is a dramatic shift towards easy administration, exposing the most features to the users (with the least amount of work). Here is a brief example, if we take an ED Department with Nurses, LPN’s, Patient Care Techs, a Charge Nurse, a Nurse Manager, and Physicians:
ED (department)
|_ ED Nurse -----> ED Charge Nurse
__|_ ED LPN
|_ ED Patient Care Tech
|_ ED Physician
__|_ ED Resident
|_ ED Nurse Manager
- The ED departmental group would only have listed on the members tab in the Vocera Administration Console: ED Nurse, ED Patient Care Tech, ED Physician, and ED Nurse Manager.
- The ED LPN group may be nested in the ED Nurse group as they would typically be expected to respond to the same broadcasts as an ED Nurse.
- As with the ED LPN group, the ED Residents are a member of their own group, but nested in the ED Physician group allowing them to receive calls to the ED Physician group or receive broadcasts.
So, why not nest the ED Charge Nurse group within the ED Nurse group? The members of the ED Charge Nurse group (in this example) are already an ED Nurse or they would not have the ability to add themselves to the ED Charge Nurse group. Nesting the group would not hurt anything structurally or feature-wise, but it is redundant - right?
Also, the ED Nurse Manager is typically NOT nested in (a member of) the ED Nurse group as this is typically a person who has “ascended” to a managerial role and will not be providing direct patient care or wish to receive calls destined for the ED Nurse group. If there is an emergent situation, and an urgent broadcast is initiated, it should be to the greater/larger group ED as these situations usually require multi-modality coordination. Make sense?
By nesting groups (i.e. Letting them be a member of another group) there are a bunch of benefits – granting (or denial) of permissions, and subsequently, access to Vocera features. For example, if we refer to our ED example above, by nesting groups, the ED Nurse Manager group is a member of the ED department group. One could deduce that if our end-user Jane Smith is the ED Nurse Manager, therefore a member of the ED Nurse Manager group, and the ED Nurse Manager group is a member of the ED (department group), then Jane Smith is a member of the ED department group. The associated/built-in logic (and permissions) of group nesting flows all the way through to the lowest group level (if A --> B, and B --> C, and C --> D, then A --> D)...
Call Flows
Group Nesting is a big structural database component, Call-Flow is the movement of calls/information through a particular department. Call-Flows within departments, and sometimes between departments/groups, are crucial for the efficient flow of calls and information as well as typically allowing a call end with a live person. Call flows are in many cases, a foreign concept, and may seem a bit abstract to describe. Ask the question "If I call the group and no one answers, is it alright for that call to go to voicemail?" This question should be asked for almost every group. The answer to that question typically depends on the department being interviewed, but usually the answer is – NO... Default call flows can be easily setup, and will typically meet more than 85% of almost any departments needs – first, some assumptions within our setup:
- If I call a "group", I most likely do not know who (particular user) I want to connect with (and in general do not necessarily care who it is), but I expect to reach "someone"...
- If I call a "user" by name, I explicitly know who I want, and it is alright for the call to go to voice-mail...
- Calls to a department (ICU) explicitly forwards ALL calls to the main desk extension of the department.
- Every role-based group (ICU Nurse, ICU Tech, etc...) forwards unanswered calls to the main desk extension of the department or the “Charge” role for the department – ask the question...
- Every dynamic group (ICU Charge Nurse) forwards unanswered calls to the main desk extension of the department.
- Special role-based groups (ICU Nurse Manager) forwards unanswered calls to that person's desk phone or to the main desk extension of the department. By default, forward unanswered calls to their desk phone if an office extension is provided. This allows voicemail to be checked in one location if desired.
- Be careful here though - in order to forward unanswered calls for a Special role-based group to a desk phone to work properly, the special role-based group must be a single person, who every day, when they are at work will ALWAYS be that position (i.e. is not a dynamic rotating role...) and use that particular phone extension, or a group of persons that share an extension. If this is not true, and/or the special role-based group contains more than one member that does not share an extension, forward unanswered calls to the main desk extension of the department.
Database Gotcha’s – yep, there’s plenty...
- Users should ALWAYS be a member of a group, and that group should always be a member of a department.
- At the very least, all users should be a member of a department – either through explicit membership (no recommended) or by being a member of a group, that is a member of the department (recommended).
- Nesting a department in another department will produce unexpected results from the voice recognition standpoint. When calling by first name and department (see the point above) - which department?
- All Groups should forward somewhere – who’s going to check the voicemail for a group that has a couple hundred users?
- When setting up dynamic role-based groups – pay attention to the group that can add/remove themselves. Make sure it is not the same group that you are editing. For example, when editing the ICU Charge Nurse group, when setting the permission for the group that can add/remove itself to that group, make sure not to select the ICU Charge Nurse group – yes, it will let you do that...
- Be sparing with the alternate spoken names for users and groups – a tidy database is an efficient database.
- If not enabling dynamic extensions (no brainer), do not use the same desk extension for multiple users.
- Call-Flows/group forwarding – the recommendations above suggest a maximum of one “hop” before forwarding to the main extension of the department. This is for a reason – forwarding will not happen indefinitely, there is a “timeout” associated with a call. Forwarding too many times assures that a call will not end with a person some number of times...
The list above is by no means inclusive, nor is this post – but very common things to mess up on...
I hope this post is helpful. I’ve built a bunch of Vocera databases over the years, and have focused a bunch of time on finding the right mix between group nesting (structure) and ease of administration. In my experience, it takes almost twice as long to fix one than to set one up well from the get-go...
