...
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 continue to populate that 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 Marker.
Male/M → Male
Female/F → Female
Transmasculine/Transman → Transgender
Transfeminine/Transwoman → Transgender
Prefer to Specify → 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
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!
The portal is looking directly at the sex field (albeit as translation values).