Microservices aren't nouns. You don't create a new microservice every time you see a noun. Microservices should be defined in ways that make sense for microservices, not just because.
And it makes absolutely no sense to do "microservice inheritance". There is no sense having a "users microservice" and a "doctors microservice" that "inherits" from "users".
Microservices are mostly independent and self-contained. Yes, they can sometimes use data from each other, but not heavily. If you find they're constantly interwoven then you chose the wrong microservices to make.
Classic example of microservices are things like billing, authentication, recommendations. They are mostly separate. Something sends a bill to the billing system, and then the billing system handles making sure the user pays their bill. The user logs in with the authentication system, and now they are logged in. Possibly, each other service needs to check to see if the user is still logged in, but that's all they have to do with authentication. The recommendations system needs to know who bought which products together, but it calculates the recommendations by itself. There are points of contact, but each system is mostly doing their own thing. The billing system just needs to know which user is logged in; it doesn't need to know whether they used a password or a security key.
Also notice that microservices do things. The billing system does billing. The authentication system does authentication. The recommendations system calculates recommendations. They don't "manage data", whatever that is. You could say the billing system "manages billing data" but surely it's more logical to say it "does billing"?
Now, your system is a healthcare system, and I presume not a surgery robot, so obviously the system can't "do healthcare" and its purpose is to "manage data" to help the healthcare workers "do healthcare" more effectively.
Note that a service which only manages data is called a "database" and is not usually considered to be a microservice.
One of the main reasons to use a microservice architecture is that different teams can work independently on different microservices. If your company would have a doctors team and a patients team, maybe it would make sense to have a doctors microservice and a patients microservice, but you don't.
Another reason to use microservices is to contain faults - if the authentication service is down then people who were already logged in are still logged in. If the recommendation service is down then people can still watch movies, but they don't see recommendations for other movies. This doesn't happen in your case because "doctors" and "patients" are strictly dependent on "users" for, presumably, every single request.
Conclusion: you probably shouldn't have doctors and patients and users microservices.
In a comment you identified that you could make a search microservice. That would make sense. Search is quite separate from the rest of the app - it just needs the list of doctors, which you could import once per day (to keep it simple and stupid) as it presumably doesn't change very often. Then the search service could operate completely independently. Data import broken? No big problem, search still works but it searches yesterday's data, which is mostly the same anyway. This would be a good microservice.
In a microservice architecture you value separating the microservices more than you value not duplicating the data. Making the search service get the updated doctor list every time someone does a search is considered much worse than letting it have its own copy of the doctor list, because it means the search service stops working if the "doctor list service" is down. When the search service has its own data, it continues working.