In OuhscBbmc/usnavy-billets: Matching Billets and Officers

This report demonstrates one approach to optimally match officers and ER billets. The project is under the initial direction of Richard C. Childers, CDR NPC, PERS-4415, with advisement from Alvin Roth.

# cat("Working directory: ", getwd())
  library(knitr)
  opts_knit$set(root.dir='../../')  #Don't combine this call with any other chunk -especially one that uses file paths.

# cat("Working directory: ", getwd())
opts_chunk$set(
  results    = 'show', 
  comment    = NA, 
  tidy       = FALSE,
  fig.width  = 4, 
  fig.height = 4, 
  fig.path   = 'figure-png/'
)
# dpi = 400,
# out.width = "650px", #This affects only the markdown, not the underlying png file.  The height will be scaled appropriately.

echoChunks <- FALSE
options(width=100) #So the output is 25% wider than the default.
read_chunk("./analysis/select-1/select-1.R") #This allows knitr to call chunks tagged in the underlying *.R file.

#Put presentation-specific code in here.  It doesn't call a chunk in the codebehind file.

Summary

Background

To increase billet assignment transparency, and to give members and commands more control of the process, 2017 & 2018 Navy Emergency Medicine Billets have been assigned using a detailing marketplace. This is a pilot project within the Navy's larger effort to modernize the personnel system.

A list of available billets will be published in the summer of 2016/2017 for physicians to compete for. At the same time, a list of officers/physicians up for orders will be made available for commands to recruit. In January, rank lists from officers and commands will be submitted and run through the deferred acceptance algorithm. The algorithm, used in the National Resident Matching Program, will optimize a match between officer and command.

What follows is a demonstration of the algorithm using theoretical data.

Notes

1. The current demonstration covers r nrow(ds_officer_roster) officers, r nrow(ds_command_roster) unique commands, and r sum(ds_command_roster$billet_count_max) total possible billets. In the specialty of emergency medicine, the term "command" and "hospital" can almost be used interchangably. Almost all commands are located in a single command, and each command/hospital can have multiple billets.
2. The four simulated datasets are viewable and editable online.
   • roster of the commands.
   • roster of the officers.
   • rankings inputted from the commands.
   • rankings inputted from the officers.
3. Although there can be multiple billets per command, an officer ranks the global command, instead of a specific billet. Similarly, the command ranks an officer, instead of a billet ranking an officer. The billet capacity of a command is considered during the matching process.
4. The following survey adequately addresses the current project needs, which involves only a few dozen commands and officers in one specialty. The survey framework would need to be generalized and scaled out, depending on the additional volume and types of specializations. https://bbmc.ouhsc.edu/redcap/surveys/?s=7XNAFK337W

Sources

1. This demonstration was developed primarily by Will Beasley, Assistant Professor of Research, University of Oklahoma College of Medicine, Department of Pediatrics. The code developed for the billet marketplace project is open source and available online.
2. The project members are appreciative of the open source matchingMarkets R package, (independently developed by Thilo Klein since 2013) that implements the Gale-Shapley (1962) Deferred Acceptance Algorithm. For further discussion, see Roth (2007) Deferred Acceptance Algorithms: History, Theory, Practice, and Open Questions and the 2012 Nobel Prize material.
3. The most recent version of this demonstration report is available in the public repository. (An alternate location is also available.)

Unanswered Questions

1. How should the process be adjusted to accommodate issues like (a) recent tours overseas, (b) seniority, and (c) cliques? Our current plan is to set some a priori points, and approximate it with a transformation. The transformed rankings are fed into the matching algorithm.
2. How should spousal placement (and other hard restrictions) be handled? We are currently investigating what will happen if the other (nonacceptable sites) are left blank for the officer, and fed into the matching algorithm.
3. How should 'subjective retirement thresholds' be handled? For instance, suppose an officer will retire if they don't match to San Diego. If they're matched somewhere else and retire, how should their assigned billet be filled? Does the algorithm need to be run another time? If so, several runs might be required (if other people's thresholds fail on subsequent runs), which is undesirable.
4. How can we adjust the process to match members married to other active duty members (COLOs) or enrolled in the Exceptional Family Member Program (EFMP) who have limited billet-assignment options. That is, some members will have to be matched to certain billets even if those commands do not rank them highly.
5. How can we adjust the process to allow members to not match? Specifically, some members have no obligation to stay in the Navy and can elect to get out if they do not get their preferred pick. How do we allow this without affecting the integrity of the algorithm?
6. How do we incentivize less desirable commands?
7. How do we mitigate the advantage on-board members may have in securing an extension or retour?

Answered Questions

1. --

Raw Rankings

These two tables represent the raw/initial rankings provided from each command (in the first table) and from each officer (in the second table). No adjustments have been made yet to the rankings.

In the first table (i.e., "Input from Each Command"), each row represents a single command's preferences; each column represents a officer being ranked. In constrast, in the second table (i.e., "Input Provided from Each Officer"), each row represents a single officer's preferences; each column represents a hopsital being ranked.

Results

Pre-screen

Commands and officers must be excluded from the matching algorithm if none of their choices ranked them back.

Preference

Matches

The skinny table below shows the pairs of command--officer matches. Notice that not all entities were matched. This is because there were r sum(ds_command_roster$billet_count_max) total billets (across r nrow(ds_command_roster) unique commands), but r nrow(ds_officer_roster) officers. This is only the essential information. See the following section for a comprehensive table.

Display

The final table shows the indices of only the successful matches, along with the following information:

• the hopsital ID and name (command id and command name),
• the maximum number of billets for a command (billet count max),
• the officer ID and name (officer id and officer name last),
• the preference expressed from the command for the officer (preference from command)
• the preference expressed from the officer for the command (preference from officer)

In this demonstration, notice that not all commands filled every billet.

Unmatched

There were r nrow(ds_command_unmatched) commands which didn't match to at least one officer. Similarly, there were r nrow(ds_officer_unmatched) officers which didn't match to at least one command.

Desirability

Finally, the desirability of the the entities can be represented several ways. Perhaps the simplest is plotting how each entity ranked each other. In the first graph, each column represents the rankings received by an officer; the diamond represents the officer's mean rank. If all commands believed the officer was the best fit for them, all r nrow(ds_command_roster) blue dots (as well as the diamond) would be at $y$=1. The second graph is similar, but reflects the desirability of each command, from the officer's perspective. These blue points are distributed more evenly than in the real world, because the preference data was (simply) generated.

Session Information

We would like to address any questions or suggestions during any stage of the evaluation. Please contact Richard C. Childers, CDR NPC, PERS-4415.

For the sake of documentation and reproducibility, the current report was rendered on a system using the following software.

cat("Report rendered by", Sys.info()["user"], "at", strftime(Sys.time(), "%Y-%m-%d, %H:%M %z"))
sessionInfo()

OuhscBbmc/usnavy-billets documentation built on April 7, 2024, 12:32 a.m.