Name that thing: What should I call a 'person' in a case management system?

Question

Think of a system that manages details about people--a case management system tracking hospital patients, or a CRM tracking phone calls by customers, or an insurance provider's system that tracks care recipients, which include the insurance holder and their dependents. In the above system model, what do you call the 'person' to whom you are connecting your activities?

For example, one instance from above--the insurance provider. As the provider, you need to track a variety of people contextually--primary insurance plan holder and their dependents. One or more of those 'people' could be a patient in relation to health insurance. The database is modeled so that those various groups of 'people' are all the same thing to the system. I need a good word for that. Right now the system is using 'Person', which feels awkward to me...

Answer 1

In your above example, the term 'customer' would cater for most instances.

That said, why can't your system cater for industry-specific jargon for each person? Most industries have a different term for their primary customer so why can't your database variable be changed on a per-install basis?

Let's say someone installs your Case Management System, why can't part of that installation/configuration process be, "Set the name of customers in this system: ". This way I can set 'patient', 'client', 'customer', 'subject' or even 'suspect'.

That would make your system relevant across most industries.

Answer 2

Given you are looking for a general term to a range of user types, you may want to consider using a term other than "customer". Your system will likely have different states for customers and the various people associated with the account, for instance, a current customer might need to be distinct from a former customer, and dependents, though technically customers, are probably referred to differently because they may not be authorized for core account functions.

If you are looking for a single term, customer might be sufficient. If you have individual usage scenarios that focus on users of different types, you may want to use terms that are specific to each of the major types.

Answer 3

For the typical role of an user, UML uses the word actor.

(emphasis mine)

An actor in the Unified Modeling Language (UML) specifies a role played by a user or any other system that interacts with the subject.

An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), but which is external to the subject.

Actors may represent roles played by human users, external hardware, or other subjects. Actors do not necessarily represent specific physical entities but merely particular facets (i.e., “roles”) of some entities that are relevant to the specification of its associated use cases. A single physical instance may play the role of several different actors and a given actor may be played by multiple different instances.

If you are, for instance, modeling a log table for "people" taking actions in your system, you could abstract them to "actors" so, in addition to users, you can reference other systems (like "internal", a known web service request or even the request's IP).

It is also, in my opinion, easy to understand for lightly tech-educated users if you show a field with such label in a table.

---

Edit: I slightly misread the question so this answer is not 100% appliable to OP's case, but I still think it may be valuable.

Answer 4

I would say "subject".

The word has a clinical/research vibe but it's more versatile than "customer."

Answer 5

I would suggest "consumers" with a simple number after to clarify which service.since they are paying for services provided. Consumer fits.