...
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. For more details on that project see [].
at some point
Mapping from Slate Identity/Marker to Slate Sex for consumption by SIS:
Coalesce: Identity first, then legal. How does that look for mapping?Marker.
Male/M → Male
Female/F → Female
...
text fields (”other” description) may be brought into Slate, but cannot go to SIS~~~~
...
Automated update of “sex” field within Slate
Create Scheduled Query SFTP Process
Using the work Helen did in TUSMGP as a model, there is now an automated query in Vet that will update the delivered ‘sex’ value with a concatenated Identity/Marker value. The DVM cycle is over, but this is working on data from the Slate-hosted applications, which are asking for Marker and Identity.
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!