Q:

Confused by ASP.NET Identity and IdentityDbContext

It's been a while since I've done any serious work using ASP.NET authentication and I'm a bit rusty. Especially now that ASP.NET Identity is the in thing. I'm hoping I can explain what I'm doing and have someone tell me why and where my assumptions are wrong or if they're not wrong. 
The application I'm building is going to be HIPAA compliant, and as such I cannot store any personally identifiable information in the database. So I spent some time looking at how ASP.NET Identity works, noting things like my ApplicationUser (which inherits from IdentityUser), as well as the ApplicationDbContext (inheriting from IdentityDbContext). I read a couple MSDN articles and so forth. 
I then noticed that IdentityDbContext seems to be tied to the AspNetUsers table in the database. I then noticed something concerning for me in the AspNetUsers table since I'm writing an application which cannot store anything personally identifiable: Email and PhoneNumber columns. 
So I wanted to remove those. I looked under the hood a bit and saw that the AspNetUsers table is mapped to the DbSet property of IdentityDbContext (see here). TUser is ApplicationUser, which inherits from IdentityUser. And IdentityUser has Email (see here). 
So...after all of that...my question is this: if I want to create my own version of AspNetUsers WITHOUT phone number / email address / etc. I will have to create my own implementation of IUser in place of IdentityUser, correct?
Are there any particular gotchyas I'm going to run into doing this, then, or should this be a fairly straightforward task? Am I going to gut a lot of pre-written code by just wanting to remove Email from the database? 
Personally, to me, it seems unreasonable that the Email property is part of any fundamental class associated with user identity -- especially when ASP.NET Identity is being touted as something highly flexible (it would seem more reasonable to me to just have people add their own Email property to the auto-generated ApplicationUser class). 
It may seem silly for me to worry so much about a column I could just write anything into, but for anyone who has ever had to deal with HIPAA regulations it can strike paranoia into your heart (and want to do everything you can to remove anything which could even be mistaken as holding onto personal information). 

A:

Getting rid of a phone number should not be a problem. Removing Email field would be a bigger pain, as it is used by the framework. 
I'd implement my own IUserStore (and all related) classes. Look on this post for initial guidance: http://odetocode.com/blogs/scott/archive/2014/01/20/implementing-asp-net-identity.aspx
Then get Identity source code with their UserStore and gut out all the bits that require email to be present.

