Resources
https://data.ucop.edu/files/documents/amcas-gender-identity-mapping-for-gad.pdf
| Expand | ||
|---|---|---|
| ||
In the current process in which we load to the staging area of SIS, regardless of any other data, if the SSN is found on a pre-existing record in SIS, the record will go to suspend status, and only when a user makes the determination that the new record is the same person as the pre-existing one will a match be made. So it wouldn’t matter if the student had a new gender, as long as the admissions user is able to figure out that it is indeed the same person. Open question: (asked, but unanswered) Under what circumstances does gender get overwritten in SIS or a new row created? Is a new gender row ever created? |
random note: in Slate, the delivered sex field is going to have a great deal of data in it, since we have been using it from the beginning . Merging newer records into older records may generate phantom values in this field, and we need to be very careful not to be using those values when they have not been maintained.
The required ‘legal sex’ v. optional ‘preferred gender’ in the CAS systems is a decent entry point to thinking about sex/gender as a core data point within the Tufts data ecosystem.
...
| Expand | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
“You should answer the gender question based on the gender with which you identify, which may or may not be the sex you were assigned at birth. Gender Identity is a separate, optional question intended to draw out additional layers of student body diversity, including diverse perspectives from applicants who have experienced major life events or transitions related to their gender identity.” In AMCAS, the reference table for this past 2024 season has the following values:  Code: SELECT * FROM AmcasDES.amcas.REFERENCE_Gender WHERE APPL_YEAR = 2024 ORDER BY DISPLAY_SEQ  The 2024 applicant data also has a "sex" column: Code: SELECT sex,COUNT(*) AS cnt FROM [AmcasDES].[amcas].[AMCAS_Applicant] WHERE app_year = 2024 GROUP BY sex ORDER BY cnt desc
I also see 2024 applicant data on gender identity. I'm currently ignoring this data in terms of SIS and Stuart: Code: SELECT gender_identity_code,gender_identity,COUNT(*) AS cnt FROM [AmcasDES].[amcas].[ApplicantPersonalInfo] WHERE app_year=2024 GROUP BY gender_identity_code,gender_identity ORDER BY COUNT(*) desc
For interfacing with SIS, the SQL view uses these values: O, U, M, F, U CASE WHEN vw.GENDER = 'Another Gender' THEN 'O' WHEN vw.GENDER = 'Decline to Answer' THEN 'U' WHEN vw.GENDER = 'Man' THEN 'M' WHEN vw.GENDER = 'Woman' THEN 'F' ELSE 'U' END AS SEX And lastly, Stuart supports these values currently, though Bruce suspects this will change very soon: Code: SELECT DISTINCT sex, gender.Gender FROM student st INNER JOIN register re ON re.StudentKey = st.StudentKey LEFT JOIN gender ON gender.GenderCode = st.Sex WHERE re.RegType = 'DegreeProgram' AND sex IS NOT null
|
| Expand | ||
|---|---|---|
| ||
Dental is unusual in that there is no automation from the 3 CAS systems (ADEA, AADSAS, PASS) and the local Qualtrics application; Mario does a data upload to SIS. ADEA/AADSAS
|
Summary sheet of all incoming admissions data: https://tufts.box.com/s/y1e60u11oob8gv2blbmoeljkzmo78y0b
Slate to SIS
This is mapped from the delivered, person-scoped Sex field in Slate.
To get data into that field,
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 → non-binary
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 and in TUH that will update the delivered ‘sex’ value with a concatenated Identity/Marker value; the Assign Sex field for SIS interface queries are set to run between 2-4 pm to get the updates before data is pulled for SIS. If gender does not match withinThese run to the Trigger: Person - Sex source format.
When copying over the query, the ‘extended’ export value Helen had set in the concatenated sex export gets reset to “default”. The mapping existed for M and F, but NB value was not mapped anywhere. 12/2 Updated both the mapping, so NB flows correctly, but also updated the export values.
TUH Assign Sex field for SIS interface query was started on 11/27/2024.
12/2 reviewed imports and updated anyone with an NB value by hand on their application record, since it had not been mapped
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!
SIS
Everything ultimately has to flow into SIS.
...
There are also user-defined options to capture pronouns and gender identity--these are updated manually.
...
Is not sent to Powerfaids or for Students to or from HR.