...
This data was moved to the person-scoped fields on 10/1 (sex and gender 20241002-132730.xlsx), which are what are being used in the Slate hosted applications:
...
The VMCAS mapping was updated to go directly to these fields/prompts on that same day (after the great majority of files have already come through, but there will still be a few to test on).
...
Gender Marker Prompts: M, F, X, Decline to State
Gender Identity Prompts: Male, Female, Transmasculine/Transman, Transfeminine/Transwoman, Other, Non-binary, Decline to State
Gender Identity and Gender Marker cannot flow to Slate as they are until the fields in SIS and the feed (whether through Denodo or Kafka) includes them. Sex currently flows, so it seems least disruptive to Path of least resistance is continue to populate the sex field with some concatenation of marker and identity and let it flowthat field based on Marker and Identity data, then have students confirm their data upon matriculation.
Rules:
Coalesce: Identity first, then legal. How does that look for mapping?
Male/M → Male
Female/F → Female
Transmasculine/Transman → Transgender
Transfeminine/Transwoman → Transgender
Other → Other
Non-binary → Nonbinary
Decline to State → blank
X → Indeterminate/Intersex/Unspecified
text fields (”other” description) may be brought into Slate, but cannot go to SIS
~~~~
In the applications we control, should we be asking for “other”, even if we cannot send that to SIS? Is it just performative? Elizabeth Storrs ask Hope!The portal is looking directly at the sex field (albeit as translation values).