Understanding the AMiON System in a Vocera Integration

The normal process for using AMiON within a hospital environment is to have multiple AMiON schedules, each controlled by a different physician's group or similar organization, under the hospital's umbrella AMiON environment. Schedule data is entered using a desktop tool on Window or MacOS and saved in a file, generally by someone on the physician's group administrative staff. The desktop tool also provides the ability to upload the schedule to the cloud-based AMiON web application. The Vocera AMiON Adapter retrieves schedule information from this web application.

Within a single schedule there are two primary abstractions:

• Staff members - representing a single physician or similar specialist. They are primarily identified by their name and an internal id value. The system also allows several additional pieces of data to be saved. The most import of these for integration purposes are contact "identifiers" such as email address and an external id value.
• Shifts (also known as a service or call service) - representing scheduling time slots for a particular activity to which a staff member will be assigned. They are primarily identified by name and an internal id. They also specify a start and end time, which (with exception of split shifts) applies to all users assigned to that shift. There is also an ability to specify the number of staff members that should be assigned to a shift at a time.

For example, for a Cardiologist physician's group, the staff members would represent the physicians in the group, and there might be shifts for the Daytime On-Call, Evening On-Call, and Overnight On-Call physician(s).

An important special feature of AMiON is the split shift. This allows two or three staff members to be assigned consecutively to a shift slot, with specific time(s) that the responsibility changes from the first staff member to the second (and the second to the third if present). The first staff member's responsibility starts at the beginning of the shift, and the last staff member's responsibility ends at the end of the shift.

Because of the distributed nature of AMiON's data entry, one of the key aspects of the integration will be data standards. This applies in two primary areas:

• Staff member identification
• Shift naming

Staff Member Identification

The Vocera AMiON Adapter is designed to provide three ways of matching AMiON staff member records to Vocera Platform user records (in the following order):

1. If the staff member email address (the staff member's contact info email value) uniquely matches the email address of a Vocera Platform User, that user is considered matched.
2. If the staff member external id (the staff member's contact info ID value) matches a Vocera Platform User's login identifier, that user is considered matched.
3. The adapter attempts to match a Vocera Platform User by name, using the same functionality used by other staff assignment adapters.

Given the general issues with by-name matching, one of the other two mechanisms will generally be preferred. This will require the administrators creating the AMiON schedule data to enter one or both of the identifiers for all of the staff members in their schedule.

For by-name mapping, an additional problem exists: AMiON uses a single field to contain the name with no particular standard for the data in the field. The adapter provides mechanisms to map the single field to Vocera Platform's multiple name fields, but those depend on names being in a single format (or possibly a fixed number of formats). In any format, the full first and last name will generally be required for matching to take place.

Note that using the first initial in staff member names (common in AMiON's documentation) will not generally allow the name mapping to work unless the Vocera Platform also just stores the first initial in the first name field.

Shift Naming

Shift name, along with the schedule name, are the primary pieces of data used by the Vocera AMiON Adapter to identify the on-call speciality for each schedule entry. However, because shifts represent (in part) a particular time slot, most of the time multiple shifts within a single schedule must be mapped to the same on-call speciality.

Most of the time these will be named such that part of the name represents the speciality (unless all of the shifts in the schedule are for the same speciality) and the remainder of the name represents the time slot. However, setting up an integration will be a lot easier if this structure were standardized across all schedules to simplify the matching process.