User (Actor) data shared across Domains / Microservices

Question

I have read through a number of posts on Software Engineering but am unable to find a suitable solution for the problem my team and I are trying to solve.

We are building a system where we have multiple Actors / Personas, for example: an application user, patient, staff member, practitioner etc.

As you can imagine each of these entities share common attributes and also have their own unique attributes.

When a user signs up to our system we create their account on an IAM server we are using, in this case Auth0. The above Actors are also Roles that are assigned to each account in Auth0.

The way the system was built initially is that if you are a Practitioner and now also want to be a Patient, then two records exist in the system, which seems inefficient.

We are looking to rework the User design in the system and want to know what the best approach would be for this.

We can have a single User Service, this would be responsible for creating and managing the Users in the IAM application, setting the required roles and updating the metadata that is required for AuthN and AuthZ, this would also store all the common attributes for each User Type.

We could then create an entity in the other services that link back to the User with a User ID. Any changes, for example to Patient information, that would need to be added to Auth0 could be sent to the User service via an Event.

The main issue we have is when it comes to searching, as the data that could be searched over can exist in two separate applications. If the above design seems appropriate, would the best option be to then add an aggregation service that handles just search? This too would end up duplicating data, this store or search engine would then also need to be kept up-to-date.

Is there perhaps another approach to this that has been implemented? This seems to be a common problem when it comes to Users in particular.

Thank you in advance for any advice.

UPDATE - 24/06/22 Hi @BerinLoritsch

Thank you for you answer, I believe I haven't described my problem correctly.

We have 3 microservices, each governing separate, rather complex domains.

• Patients and all Medical Data
• Practitioners and Staff Members
• Mobile Application Users (the mobile app has a subscription component that allows anyone not just Patients, to get useful medical information), I apologise if this seems vague, as I am under NDA.

There are 4 "DB" entities, an AppUser, Practitioner, Staff, Patient.

Across the 3 Microservices we are storing a large amount of duplicate information for example:

• First Name
• Last Name
• Email Address
• Telephone Numbers
• etc

But each model also has a large amount of unique attributes assigned to one another.

With the above in mind, let me explain what I consider our "Worst Case Scenario"

Given the way the API is currently designed. If a Practitioner would like to see another GP, they would create a Patient entity (this role would also be assigned to their IAM profile), and if they wanted to use the Mobile Application, then another entity would be created (role also assigned in Auth0).

So if they update their information in one place we need to update it in 3 other locations. The data models also don't know about one another.

So the design I proposed consolidates all the Common Information as well as API interaction with Auth0 into a single application, while storing all the unique domain specific information in each of the relevant Microservices with a userId key that links back to the User model (new model that would be added).

But if the information is segmented like this, then we fetching or searching the data needs to be "joined" across microservice boundaries, so we could create a new application that deals with this in isolation.

Please let me know if I am still not clear.

@BenCottrell thank you for your response, I shall do some research on data governance.

Answer 1

The way the system was built initially is that if you are a Practitioner and now also want to be a Patient, then two records exist in the system, which seems inefficient.

It is inefficient, but it is necessary.

There are use cases where it makes sense to reduce duplication of user data. It might be perfectly acceptable in a sales application. But medical records are extremely sensitive, and trying to reduce some inefficiency for patients who also happen to be practitioners is walking a risky line, and could lead to problems that you don't want.

How often do you have users with multiple roles? This sounds like an edge case (perhaps for testing?), and more often than not, it's not worth redesigning your system around them.

Running afoul of HIPAA or other laws because of bugs or data leaks could lead to hefty fines and major backlash from patients.

Will it be frustrating for practitioners to update their data as both a practitioner and patient? Yes. But make those processes as simple as possible.

In my current role, I help build a user-facing product. I am also a user of that product. My employee records and user records are completely separate, and it's not a problem for me. In fact, I expect that those records will be separate.

Source: I have helped build medical information systems at multiple organizations.