Understanding Vocera Assignment Manager Adapter Operations for Integrations

Initial Assignment State

The Vocera Assignment Manager Adapter receives subscription messages for newly created assignments and checks if they have a state. If not, their state is set to "next" and their assigned_at timestamp is set to the current time (unless already set). To catch new assignments created while the adapter is not running, at startup it also checks for all assignments without a state and updates them using the same rules.

State Transitions

Once a minute, the Vocera Assignment Manager Adapter queries for assignments which need to have their state changed. In particular it looks for:

• Assignments that match one of the start views and which currently have a state of "next".
• Assignments that match one of the end views and which currently have a state of "next".
• Assignments that match one of the end views and which currently have a state of "active".

Assignments found will have their state changed (to "active" for the first group, to "deleted" for the second group, and to "expired" for the third group) and the current time recorded in the appropriate field for the state change ("accepted_at" for the first group and "ended_at" for the second and third groups).

The adapter confirms that there are no queued requests for state change before trying to check for any more state changes to send. This keeps the adapter from queuing the same requests multiple times. When there are still queued events, the adapter audits that it is pausing processing until processing can catch up. When the queued events have cleared, it then audits that processing is resuming.

Patient Based Assignment Management

Patient-based assignments are based on a link to the PATIENTS dataset ("patient"). If the link exists, the assignment is considered patient-based. It is assumed to be set at assignment creation and never updated.

When a patient-based assignment is created (and its state has been initially transitioned to "next"), its location will be checked to see if it matches the patient's current bed (or lack thereof). If it does not:

• If the assignment's state is "active" and has an assigned location, the assignment will be copied as described in Copying Assignments on Location Change in this page.
• Otherwise, the assignment's location will be updated to one mapped to the patient's bed (or no location if the patient does not have a bed).

When a patient's status changes to a non-admitted state, all "active" assignments for that patient will be transitioned to "expired" and all "next" assignments for that patient will be transitioned to "deleted".

When a patient's assigned bed is changed, a location is found or created matching the new bed (if there is one) and their patient-based assignments are updated as follows:

• If the assignment has a state of "next", the assignment record will have its location updated to the identified location (or cleared if the patient is not in a bed).
• If the assignment has a state of "active", the assignment will be copied as described in Copying Assignments on Location Change in this page.

To catch changes that occur while the adapter is not running, at startup the adapter checks all patient-based assignments with "next" or "active" states and:

• If the patient has a non-admitted status, the assignment's state is updated to be "deleted" or "expired" using the same process as if a transition to that patient's admit status was received.
• Otherwise, if the assignment's location is not associated with patient's current bed (including having a location when the patient is not assigned to a bed), the location is changed as if a change in the patient's bed had been received.

Copying Assignments on Location Change

For active assignments (unless the assignment is new and has no current location), the location is changed by expiring the current record and creating a copy of the record with the new location. This process has the following characteristics:

• The original record's key (assignment_id) is changed so new updates from the assignment system will not affect it.
• The original record's state is set to "expired" and its ended at time is set to the current time.
• The new record has the same data as the original record (before updates): key values (assignment_id, level, and interface_id), the external flag, the state (which will be "active"), the start and end dates, and the patient, role, location, and user. No other data will be copied.
• The new record's "assigned_at" and "accepted_at" values will be set to the current time.

Locations to Use for Changes

The locations used for patient-based assignments will be created by the Vocera Assignment Manager Adapter on an as-needed basis based on a patient's bed (and its linked room). The location id will be based on the bed's record id, with a prefix unique to the assignment manager. The location will be linked to the facility for the room, the bed, and the unit for the room. Its name will be derived from the room and bed numbers.

Rate Limiting Assignment Updates

To keep from overwhelming Vocera Platform by flooding it with updates (such as at shift change), the Vocera Assignment Manager Adapter limits the number of updates it will process at a time. The limit is set to 4000 / minute (actually 66 / second). Updates are queued up (with a maximum depth number of 10000) and the queue is checked every second, processing at most the per-second limit on each check. The per-minute limit and queue limits are configurable as interface properties.