Making a change to enterprise data model

To support our diversity and inclusion mission, we need to make changes in how we collect, store and analyze demographic/identity data, e.g., gender identity, race/ethnicity, etc. We don't have an MDM technology in our architecture, so this impacts all of our major enterprise systems (proprietary student, SAP, Salesforce, etc.) Has anyone out there undertaken this kind of implementation project and would you be willing to share your roadmap? Sponsorship here would be CDO with DG as the catalyst, however PMO and systems work would be like "any other" IT project. We see much more of this "data alignment" in our future so want to get it right as quickly as possible. Any advice, suggestions and especially lessons learned would be appreciated!

Lauren Himml, Data Governance Program Manager, Boston University ([login to unmask email])

Hi Lauren!   

Did we ever work together at BU?

I recommend this article:   https://www.wired.com/story/the-battle-to-get-gender-identity-into-your-health-records/ to start with.

I recommend that you make sure people can enter their data the way they want.  There is also strange interaction between racial identifiers and how you report data to IPEDS.  If someone selects "White" and "Black" it gets reported to IPEDS as "Two or more".   I feel this is an ethical issue for students who feel strongly on how they are represented to the federal government.  I think it is reasonable to let them know so they can adjust.  Someone who identifies as bi-racial may want to be reported as "Black" rather than "Two or more".

The other requirement for administrators to "guess" at race and sex to report this data is fraught with risk.  I think there should be a flag to indicate if this information was self reported or input by administrators.  I seem to remember SAP didn't have a flag for this.

I hope this helps!  I'm happy to discuss in detail if you want privately.

-Jeff

Hi Jeff!

No, I think you were leaving just as I was getting some traction in building the program. I had the benefit of a clean slate, but had to build from a dead stop, so there was considerable ramp-up time. That was a great article, thank you! Your insights are valuable, and most were discussed as we included a 360 degree view of stakeholders in our development of our Sex and Gender Identity data collection questions. We are a ways away from actual adoption, we’re still in the “build” phase from a systems standpoint but I’m hopeful we won’t meet with resistance. In fact the frustration is that we can’t do this sooner.

Now that we have our first approved (governed) University data elements, the BU Terms and data definitions for Sex and Gender Identity I'm tasked with some high-level planning for how to roll out our new-and-improved (future state) data elements. Alas, BU does not have a master data approach in its data architecture, and we're not like Epic with one stored location but tons of uses. So I'm hoping I might learn from someone who may have undertaken a similar challenge of multiple places/procedures for the same data...

Hope you are well, and stay safe,

Lauren

I don't know the intricacies of your problem, but I always recommend not changing history.  If you have gender code values of "female" and "male" and now want to add a value of "other" (just to make the example easy), you have to recognize that you're starting "other" on a particular date and it wasn't available earlier.  It's about tying effective and expiration dates to your code values.