Clarify user roles / permissions

[jasonaowen]

As a system administrator, I should only be able to work with user accounts; everything else should be unavailable.

Currently, if I log in as a system administrator, and go to the address of a valid enrollment (eg http://localhost:9080/cms/provider/enrollment/view?id=11), that enrollment is shown.

Instead, I should receive a 404 Not Found (not a 403 Forbidden, as that reveals that the enrollment URL is otherwise valid).

[jasonaowen]

Possibly related code.

[brainwane]

I've just verified that a service agent can view and edit draft and pending enrollments submitted by a different service agent or by a provider user. This is probably not the desired behavior.

In the screenshot below, the logged-in user submitted one of the enrollments; the other two come from other accounts.

[brainwane]

When fixing this, please update the relevant part of psm-GitHub/psm-app/docs/userhelp/source/service-admin-help.rst to reflect that system admins can no longer view enrollments.

[jasonaowen]

@cecilia-donnelly and I just discussed what service agents should be allowed to do, and we realized that we might not actually have any requirements around service agents! This might just be a holdover from the original implementation that we hadn't looked at critically. @cecilia-donnelly will double-check to make sure there aren't any requirements that specify or imply service agents, and then I will remove or disable the service agent role and associated UI.

[brainwane]

I recognize that we don't want to have any types of users that we do not need to have.

However, I would be wary about removing the role. As I mentioned on psm-dev, I believe there will be people helping providers enroll -- state employees/contractors, independent consultants like AddVal, office admins at loosely organized group practices or shared medical offices, and staff at insurance companies which offer Medicaid-related health insurance plans. These people will be analogous to brokers, navigators, or resellers. And "service agent" is a reasonable sort of role for this kind of person. If we take out the "service agent" role, then a person who's filling out this form on someone else's behalf, at scale, would need to create a provider account, even though they're not a provider, and that feels incongruous to me.

[cecilia-donnelly]

@jasonaowen, @brainwane, in conversations I've since had with states it appears there is a concept of this "agent" role, but it's different from how I was originally conceiving it. It appears that a provider has an account, and then they can delegate an agent account to manage their account. Often this person is an office manager, which I hadn't realized. Sometimes the "agent" might be someone manning a helpdesk at a state. @brainwane, I have asked and haven't heard anything about insurers playing this role -- maybe that only happens in different states from the ones I've talked to.

[jasonaowen]

Interesting! It sounds like there are two use cases:

• additional accounts related to a provider account, as the provider doesn't want to share a single username+password with multiple staff
• one agent may be the delegate for many providers, maybe someone working for the state, maybe as a service paid for by the providers.

This suggests to me kind of the structure we were initially imagining, but with additional limitations/permissions, and with the ability to both grant and revoke access (and probably some audit logging / security notifications around that).

I also imagine that in the first use case, the office manager might prepare an enrollment, save it as a draft, and the provider would review it and sign it.

@cecilia-donnelly: how accurate is all this stuff I just made up? Are there more wrinkles around this? Which pieces, specifically, do we need to do for December, and which should we split off into a new issue for a future milestone?

[cecilia-donnelly]

@jasonaowen I think the first use case is definitely true. The second one seems right too -- someone could be in this "helpdesk" role at the state, who should be able to gain access to the enrollments submitted by many providers.

Agreed with more grant/revocation abilities and with auditing! There are tons of requirements around auditing that we have slated for later in the roadmap, but getting a jump on that would be helpful.

For December, we need to limit the abilities of our existing "service agent" role to a more appropriate scope, and you and I should talk about whether it makes sense to turn it into use case (1) or (2).

My notes about this from today's meeting: Service agents:

• Are there entities that handle enrollments for multiple providers?
  • (State 3 told us last week that providers can "assign certain functions" to agents)
  • State 1: in their portal, the entity can enter demographic information and then assign a person in their office who would handle management
  • but they don't usually allow that during enrollment? More often it's just one person entering the information
  • ask for managing employee info, who is entering the info, and ask them for an attestation that they have the right to do so

Service admins:

• Do state reviewers often edit applications on behalf of providers? (i.e., call a provider about a mistake and then correct it?)
  • State 1: contact provider and ask for corrections/changes to be made in writing, and then the provider rep (state side person) can make the change
  • State 2: could be a provider customer service representative who might make the change right away, but would still require information from provider
  • rep can enter info from a missing document, but the provider needs to fwd the doc to be attached to that app
  • customer service can add/change info but not necessarily approve a provider

And see also @chj124's comment about this.

[jasonaowen]

@cecilia-donnelly and I talked a bit today about this. Here's what we're thinking right now:

• Providers should be able to delegate the ability to create a draft enrollment to one or more agents. For example, a single doctor might have multiple admins, and each should be able to enroll / renew.
• Multiple providers should be able to delegate the ability to create a draft enrollment to an agent. For example, multiple doctors might work with a billing service that helps them enroll.
• An agent should, therefore, be able to start an enrollment (but not submit it), and indicate somehow that it is on behalf of a particular provider if more than one provider has delegated to them.
• At some point (after the MVP?), we should implement full friend requests, where either side can initiate a delegation relationship and the other side can confirm it, and then later these relationships can be revoked.

We still need to think more about a few things:

• How do we handle multiple accounts for group providers? I expect that they would like some redundancy, so that if Robin the admin quits, the hospital doesn't lose access to the PSM. This implies a kind of peer relationship, where multiple people are equally responsible for a group provider.
• Can an account be both a provider and an agent? Robin the hospital admin sounds like a natural candidate for helping a doctor working at that hospital enroll.
• Can an agent prompt a provider to make an account? Can a provider prompt an agent to make an account?

We also have a somewhat similar situation with service admins, where we will (post-MVP) want to allow them to mark some enrollments as in-process so as to avoid duplicated work. For example, Jamie and Sam both work for the state, and can see the list of pending enrollments; Jamie should be able to "claim" an enrollment, and Sam should either not see that enrollment or see that it is already claimed. As we build out the functionality for providers/agents, we should consider whether it can and should be generalized to also include service admins.

[jasonaowen]

After thinking about it further, I propose something a bit simpler than reworking service agents for the MVP:

• we effectively disable service agents, and don't use them
• give a provider the ability to share an enrollment (draft or otherwise) with another provider

Each enrollment already has created_by, changed_by, and submitted_by fields in the database; we can add an Enrollment-User link table to handle permissions, so that each person in the link table can see/edit/submit that enrollment. I think we probably need that link table even in the more complicated cases described above, so this should be a useful step toward that more complex future, while being easier to implement and hopefully meeting the immediate need.

@cecilia-donnelly, others, what do you think?

[brainwane]

My gut feel is that:

• a service agent role is necessary in the long run
• if we, in the short run or the long run, allow providers to delegate certain kinds of rights to certain other providers as proxies, we'll need to heavily signpost and visually signify "this isn't your enrollment application you're working with, it's a proxy"

[chj124]

Most (if not all) applications are not submitted by a provider, but by an office manager/agent, and yes, this should be captured at time of application entry Through the screening process everything is verified, including the permissions of the agent which pretty much include the same privileges as the provider Individual applications for each provider billing for services is required. This makes it easy to track the agent/provider relationship A group/facility should only have one record A provider has one account Whoever registers with the system creates their own account. If a provider has not registered when an admin/agent wants to enter an application then a shell account should be created for them but it may not be necessary to activate it for external access. If a provider tries to access the system and there is a shell account there already, then their needs to be a verification process in place to allow the provider to activate their account. Whoever logs in has associations to groups, facilities, providers. If a provider must have a valid and authorized account to enter an application then the admin will impersonate the provider and create their account for them. If an org is shortsighted as to how/who manages their data and that one-person leaves, there should be a procedure in place for the Org to provide evidence to remove/replace a person. Providers apply (even in a group, may add all providers but will be individual application for each provider) and individual providers will be enrolled or not for the group/facility A provider is approved as himself to provide services and any bill on his behalf will be accepted or A provider can be approved to provide one or more services at one facility and bills for that provider/facility /services will be accepted or A provider can be approved to provider separate set of services at different facilities and bills for those service/provider/facility combinations will be accepted.

With that being said, I’m not sure in our adjudication process today that the facility is taken into account. I believe (and I am waiting for confirmation) the reality is, a provider bills for a service delivered to a client. It the provider is enrolled in a plan to provide that service, the client has a need for the service, and (when needed) the client was approved for the service, then the bill will be processed.

[cecilia-donnelly]

@jasonaowen, I don't want to disable service agents, even temporarily. I think it's fine to give them the same set of permissions as providers for now, but as @brainwane says, we'll need to have agents in the future.

we can add an Enrollment-User link table to handle permissions, so that each person in the link table can see/edit/submit that enrollment. I think we probably need that link table even in the more complicated cases described above, so this should be a useful step toward that more complex future, while being easier to implement and hopefully meeting the immediate need.

Right, I agree this is a useful step. I don't quite see why it would be easier for a provider to share with another provider than with an agent, though. Let's just have providers share with agents right away. For MVP, agents will be functionally the same as providers, but we'll maintain two separated roles which is what we want in the long term. Am I missing something that makes that more complicated than sharing with other providers?

---

And @chj124, this: "Whoever logs in has associations to groups, facilities, providers." is what I was asking about in #413 -- what's the difference between groups and facilities?

[kfogel]

I've read (well, maybe skimmed in some cases) all the thread so far. I think we might get some more clarity if we disentangle two concepts:

1. A "Provider" is an entity for which there is a record in the system. That is, the PSM is a screening system and what it screens are Providers, so naturally there is such a thing as a Provider record. Conceptually, a Provider is one "row" in the main table in the main database (I realize it could be more complex than that in the actual implementation -- I'm just talking about conceptually here).

2. A "User" is a login account in the PSM. Different Users have different permission sets: some Users might have full edit rights on multiple providers, other Users might have limited edit rights and only on one Provider, etc, etc.

(Shorthand for @cecilia-donnelly: this is same as the "Participant" / "User" distinction we make in TTM, and I'm just proposing we make it in the PSM too.)

Now, it might be that the common case is that a Provider is associated with just one User, who has full edit rights on that Provider, and it may even be that in this common case, the person or people who log in as that User are themselves unaware of this internal distinction we're making. But, reading the above comments, I feel like a lot of decisions and discussions would get simpler if we start making this distinction consistently throughout the PSM.

[cecilia-donnelly]

@jasonaowen and I had a long talk about this in IRC on Wednesday. We haven't come to final conclusions. I'm capturing the highlights here -- when you're reading, note that this is one entry in an ongoing conversation (which will continue in this issue / the mailing list / chat).

Essentially the question is whether "agent" needs to be a separate role from "provider," for the system. If they both have the same powers (create, edit, save, share, and submit enrollments), then no. If there is a difference (e.g. agents cannot "own" an enrollment, they can only work on one that is owned by a provider), then yes.

The highlights from our conversation:

• We know we need to disable agents current powers (they can do admin tasks right now, which is wrong)
• Are agents just a special kind of provider? (from a technical perspective, not a business perspective) That is, is "agent" a thing that you are or a thing that you do?
• How much should we be thinking ahead toward adding more management features to the PSM? Should that influence how we treat agents now?
• Can we flag certain providers as agents, instead of having a whole separate role? What would the consequences of that be? (Should agents have different restrictions based on provider type of the enrollment? Does an agent for a dental clinic have different permissions than an agent for an individual dentist?)
  • @kfogel raised this, and it's a reasonable question -- it does complicate matters quite a bit!
• Briefly: two or more accounts should be able to have access to a single enrollment (I'd add that one is the "owner" and the others have "manager" type permissions on that enrollment, but we didn't discuss that.)
• Information should be shared on a per-enrollment basis, not a per-user basis (a provider might have multiple enrollments, each of which they share with a different set of agent(s))
• Agents would need to have some way to attest that they can submit information on behalf of the provider (possibly a radio button that asks whether they're submitting an enrollment on their own behalf or on behalf of a provider, and shows a different form based on their answer -- like we currently do for private/primary practice)
• We like the idea of an agent or a provider starting an enrollment and having a "share" link that allows them to enter an email address. The owner of the email address would get a message inviting them to log in or register for the PSM to view/edit the enrollment.
• One question for states from all this is "Is it important for a provider to have their own account on the system, and to have enrollments linked to that account?" (versus an implied situation where an agent has sole control/access over the enrollment and the account) "If so, why?" (Note that we saw @chj124's comment about "shell accounts," which seems to us to imply that it is important for a provider to have their own account, even if they never use it.)

[kfogel]

Thanks for the summary, @cecilia-donnelly . I realize that you were writing it simultaneously with my most recent comment, above it, and so it mostly doesn't incorporate what I was saying.

However, once I read your summary through the lens of the Provider / User distinction, many of the questions raised go away or have IMHO clear resolutions. For example, if someone (User A) is filling out a Provider's enrollement form, and wants to invite someone else to help, then User A enters that new person's email address, and when the recipient gets it and accepts the invitation, now new User B is created. User A continues to have whatever permissions she originally had w.r.t. that particular Provider's enrollment submission, and User B has whatever permissions come with that type of invitation (maybe User A selected the permissions manually, or maybe User A chose a stock type of invitation that comes with a know set of permissions -- which may or may not be the same set of permissions that User A has -- but these are now UI issues to be resolved within a fairly simple conceptual framework).

So I guess I'm offering a counter-proposal to your summary paragraph, in which you wrote:

Essentially the question is whether "agent" needs to be a separate role from "provider," for the system. If they both have the same powers (create, edit, save, share, and submit enrollments), then no. If there is a difference (e.g. agents cannot "own" an enrollment, they can only work on one that is owned by a provider), then yes.

Instead, I would say:

Essentially, a Provider has no role within the system. Providers are the objects that are manipulated within the system. Only Users can do the manipulating, and different Users may have different permitted manipulations they can do w.r.t. different Providers, and w.r.t. creating or inviting new Users. An "agent" is just our shorthand for a particularly common type of User.

[cecilia-donnelly]

A "Provider" is an entity for which there is a record in the system. A "User" is a login account in the PSM.

I think the entity in the system that we consider users to have rights on (and that we screen) is actually an enrollment, not a provider.

A "User" is a login account in the PSM. A Provider is a type of User with certain permissions. An "Enrollment" is an entity for which there is a record in the system.

And I see your point about this being a "Provider Screening Module," not an "Enrollment Screening Module," ha. However, if Alice has a license to practice as a Dentist and is perfectly well suited (and approved!) to do that but fills out an enrollment as a Home Health Aide (work she is not licensed to do), that enrollment will be rejected. It's not that Alice-the-person has been screened and rejected, it's one specific enrollment (of which a user might have multiple) that we screen.

So, what are the rights of different kinds of users on a given enrollment? That's my tweak on the question -- I like your formulation, @kfogel. We still need to decide which manipulations are allowed when you write that "different Users may have different permitted manipulations." I understand your desire to not fret so much about "agent users" vs. "provider users," and I think it's the same feeling that @jasonaowen is having -- let's give users rights to "own" or "manage" enrollments, edit them, share them, submit them. I think that's good enough to go on for now. Down the road, we do need to understand what permissions different groups of users should have.

Does that make sense, @kfogel, @jasonaowen? Does it move us forward at all?

---

@jasonaowen and I came up with some concrete features we can implement without having made all of these decisions.

• [ ] remove the "agent" role's admin-like abilities
• [ ] grant the "agent" role the permissions that the "provider" role has currently
• [ ] Let multiple users link to a given enrollment
• [ ] Give users a "Share" option in the "Action" column on their dashboard (which currently only appears if they have existing enrollments)
  • [ ] On click, Share pops up a modal which allows them to enter the email address (or username) of a user to share the enrollment with.
  • [ ] Currently we'll only allow them to share enrollments with existing users, though later we'll allow them to invite new users.

Jason points out that we may be able to use "Categories of Service" as an example.

[kfogel]

@cecilia-donnelly +1 to all of this. The main update, I think, is let's use the term "enrollment" (for what I was calling "provider"), and we now all agree that a "provider" is just one possible type of "user". We might find it useful, at some point, to actually stop using the term "provider" to refer to a type of user -- having that term be a kind of user might just cause confusion for Alice the Dentist who is doing her own enrollment, and for PSM devs, and for state service reps (who, of course, have their own types of users).

The reason I say that is that a "provider" is an entity that already exists out in the real world. Unlike enrollments and users, which are PSM-specific, the provider is the person or organization out there who actually provides care to patients. So maybe we banish that term from being used to describe a type of PSM user, in order to keep it distinctly meaning the entity out in the real world for which an enrollment is created.

We may not even need a term for that default type of account. It's just the "default type of account": it has full permissions within one enrollment.

[chj124]

Be realistic An agent (admin at providers facility) will most likely create the account for the provider. User is an Entity but so are all the specialization of user and they all have a record in the system. Ideally this should connect to a Master Person Index (MPI) and hold basic information. User User <- Provider User <- Agent (just a user acting on other behalf) User <- Admin (just a user acting on other behalf) User <- System Admin Provider is the main specialty that requires additional information. Provider apply, are reviewed, and possibly approved. If approved an enrollment record is created. Need to track all history and changes. Agent is a specialty that does require additional info as well. Who are they approved to help. Need to track all history and changes. Admin, same as agent. Realistically, an agent/admin is going to access the system and create a user account (as the provider). They will then start an application. Must have provider account to start this process. Logged in as the provider they may, or not, tell the system to allow them as an agent/admin. They can then logout as the provider and wait for their email to log in themselves, create an account if needed, and continue adding information to the providers application. The only variation I would see here is that when the admin/agent creates the providers user account, instead of starting the application, there could just be a question in account settings that identifies them as a provider. Then email for admin/agent could be added. They can access system and start application. We find this to be common, the admin/agent doesn’t necessarily have an account, they just impersonate the provider. Application is an Entity. It exists separately, has states, status, and a life span. Need to track all history and changes. Enrollment is a should be a separate entity as well. A separate record for each program (possible to have more than one) with the necessary information to identify the program, services approved, as well as effective dates and when to trigger a review. Agents… I think the role should still exist so that if desired their role could be limited in some way. To start off with they would have the same rights as a provider. The only difference is they must have a list of providers they can access. (managers) Re… a provider might have multiple enrollments, each of which they share with a different set of agent(s) Its true they may apply to provide different services at different times. Would they just clone and update their original application? Or enter a new one? I don’t think there is an issue with adding a new admin for the new application that just means the provider application must be started before and admin/agent is assigned. I think it makes more sense to have this at the provider level. Once an application is entered and submitted, an admin/agent may NOT change it. It could be cancelled and they could resubmit another one but once submitted it can only be changed by a State Worker or designated Fiscal Agent. Account… We need to link information together and be able to control security. To do this all users must have an account. Because of this, you will find that the admin/agent creates the provider account and not one for themselves. Accounts are also important for analysis, and linking the data to other systems. There must always be a way to tie every user (provider included), and every application for every provider, and every enrollment record back to a MPI. Remember that the Provider Screening Module is a small part of a larger enterprise. There are other provider management functions that exist outside of PSM. There are also several other vertical applications that will depend on data from PSM. It is important to realize the implication to the clients who are receiving care from providers who applied to provider services in PSM, and could be denied there too.

[chj124]

I am concerned about the architecture/design of the PSM There are many things that today, would make the system unusable 1) A provider must be licensed within a state to do business a. The provider is screened b. The state issues this approval c. Done by the States Medical Practice Board 2) A provider must apply to perform/bill for services under Medicaid a. Applications must be review and information verified b. Providers must be screened i. Requirements vary by type of service they have applied to provide c. The facility they practice at may need to be screened, depends on the risk associated with the type of service they are applying to provide d. Application and screening approval does not mean they will be enrolled e. Done by States Fiscal Agent and State staff (The State staff associated with the Plan/Program like Medicaid) 3) A Plan (like Medicaid) a. Can set limits on how many dentists there are i. Could be set state wide ii. Could be set geographically b. Limits are set by specialty c. Application could be denied initially in (2) if there is no need d. The plan also determines the application, screening, and enrollment criteria 4) Other Plans a. Same as (3) b. Defines set of approved provider type allowed to apply

So, for us…. 1) Everyone is a user with an account and has an account record 2) Providers have an account record and a provider record 3) Each application has a record 4) Documents must be unloadable as part of the application process 5) PSM should interface with a document management system (of the user’s choice) 6) Application is tied to the Provider record 7) A provider’s application has to be submitted before we will work on it 8) A submitted application is frozen 9) A provider/admin/agent could upload an additional document, or add a note with information that would reference the application 10) The state worker could then attach a note and/or document to the application so it can be processed 11) Besides background checks, plan policy, information validation, a scheduled site visit may be needed 12) The system should show the need and have a record for each site visit 13) After all the above is verified and reviewed, a provider may be enrolled 14) A provider can have multiple enrollments 15) Each enrollment must have its own record 16) With the enrollment and the plan, there are approved rates that the provider can bill for 17) We have to have a way to tie the provider, to the enrollment, which should indicate the plan and therefore the rates Just a few requirements 😊

[cecilia-donnelly]

Hey @chj124, thanks for the detailed feedback! I'll summarize, respond, and ask a few questions here.

We all agree that agents will be filling out the application for providers. @jasonaowen and I are now thinking that instead of roles, we'll give user accounts different kinds of permissions. An account might have permission to create other accounts (currently the "system admin" role), or just to edit one application (what we were terming an "agent"). As I understand it, that agrees with what you're suggesting -- "when the admin/agent creates the providers user account, instead of starting the application, there could just be a question in account settings that identifies them as a provider." A given account will have permission to share access to a given application with another account, e.g. a provider with an agent.

I hear what you're saying with the application/enrollment distinction. I think it's just a matter of terminology, not a process difference. Currently in the PSM we use the term "enrollments" for "applications," for historical reasons. I agree that "applications" is a more precise term for what we're handling. Right now, this is strictly a screening module, so we don't handle the true enrollment of a provider into any program, be it Medicaid or something else. That's something we're certainly looking into managing in the future, but we don't do it right now -- as you mention, there are other management modules in the system. We may consider it technical debt that we call applications "enrollments" in the PSM right now.

Account… We need to link information together and be able to control security. To do this all users must have an account. Because of this, you will find that the admin/agent creates the provider account and not one for themselves. Accounts are also important for analysis, and linking the data to other systems. There must always be a way to tie every user (provider included), and every application for every provider, and every enrollment record back to a MPI

Right, this is a useful point! We do want to discourage agents from simply impersonating providers because it is important for auditing that each person have their own account in the system.

I am concerned about the architecture/design of the PSM. There are many things that today, would make the system unusable

As you know, the PSM is a work in progress and we're taking your feedback into account when planning the roadmap to 1.0. More specifically, I'm not clear on what would currently make the system unusable for VT -- can you clarify? Even in this early form, the PSM meets most of the requirements in your comment. The screening requirements that we do not yet meet are the following:

• Interfacing with a document management system
• Allowing a provider to add notes with additional information after submitting an application
• Site visits: flagging the need for one and giving space for notes on the visit itself

These are in the PSM's roadmap, and will be added.

Some of the requirements you mention are more management-side, as I understand them:

Allowing a plan to set limits on a given specialty

After the provider is screened, they may not be enrolled because there are already enough providers of their specialty. However, it seems to me that it's still worth having them pass the screening portion even if they aren't allowed to enroll until space opens up in the plan.

With the enrollment and the plan, there are approved rates that the provider can bill for We have to have a way to tie the provider, to the enrollment, which should indicate the plan and therefore the rates

Rates are part of provider management. Again, the PSM may well expand to include more provider management requirements, but we aren't including those now.

Does that address your architecture/design questions, @chj124? Are there other concerns you have?

[chj124]

Thanks @cecilia-donnelly and the fact the PSM is the Screening module that is an important distinction.

For PSM to be part of the bigger modular enterprise it makes it important to get this right.

Since a common requirement, and a CMS certification requirement, is Role Based Access Control (RBAC). Giving “user accounts different kinds of permissions” is RBAC and I would encourage you to keep this. I realize the actual roles in PSM are pretty limited but still needs to be part of the central RBAC system.

The application/enrollment terminology issue may seem trivial, but when it comes to dealing with state departments you will find they hold fast to “their way” of doing and speaking. Since screening is specifically part of the application process it would be best to bite that bullet now and not use the term enrollment.

So, PSM handles the application process, verification of data, and back ground checks, right? It will then make available a list of providers who have had their applications approved.

That means that the enrollment actually happens outside PSM. From the MITA perspective EE05 Determine Provider Eligibility is the limit of PSM.

MITA process EE06 Enroll Provider must be handled subsequent to PSMs screening approval.

On the accounts comments, I agree but getting the actual provider to do anything is wishful thinking. Beyond having a mechanism for them to provide a doc on their letter head that they sign attesting to what they are applying for x, y, and z I would not expect them to do anything else. Having a process for the agent to manage things from one account is certainly best.

Since the services a provider is applying to provide are specific, and each service may have different application and screening requirements, how do you handle that?

Since a provider can apply and there may not be room for them, verifying the information anyway should be an option. Screening a provider may have a cost associated with it and no one will want to spend additional funds unnecessarily.

Your comments did address some issues, i have raised a couple more.

[cecilia-donnelly]

@jasonaowen and I are looking at attribute based access control (ABAC) type permissions. ABAC allows finer granularity than RBAC, but will still give us the flexibility to use RBAC if we so choose -- it just doesn't lock us into set roles, nor does it force us to have an ever-growing list of roles with specific sets of permissions. @chj124 I think this should meet the certification requirements for RBAC (because we'll be able to grant certain kinds of accounts the same sets of permissions, as we would with role-based auth), while making it easier for us to make permissions changes in response to the needs of different states. What do you think?

We're using Spring in this project, and spring-security has some built in ability to handle ABAC. Since we know we need to upgrade Spring anyway, we're going to turn to that first (see #219), which will allow us to use their new features as we update the accounts system.

---

@chj124 in response to some of your other comments:

I agree about using the right terminology for different audiences, and I am trying to use the term "application" in general, now that I know it's preferred. I opened #485 about that.

Since the services a provider is applying to provide are specific, and each service may have different application and screening requirements, how do you handle that?

We have the provider choose a "provider type" as the first field on their application, and the form they fill out is different based on that provider type. The biggest differences are between individual and organizational provider types (the latter have space for beneficial owners, for example), but each provider type is asked for a license that corresponds to that type.

Since a provider can apply and there may not be room for them, verifying the information anyway should be an option. Screening a provider may have a cost associated with it and no one will want to spend additional funds unnecessarily.

So you're suggesting that when a provider enters their provider type, they see a message that says "[Plan/program] is not enrolling new [provider type]s right now. Do you still want to proceed with the screening process?" or something similar? Then they could decide whether to pay to be screened or not. I'm sure we could do something like that. I've opened issue #486 for this.

Your comments did address some issues, i have raised a couple more.

I'm glad we're getting there!

[cecilia-donnelly]

@jcunard notes that our help documentation is behind. It still thinks that service admins have the ability to add/edit/manage service agents. We changed this, so only system admins have the right to manage other user accounts. We'll need to update the help docs accordingly.

[cecilia-donnelly]

Hey @slifty @kfogel -- this long issue holds the conversation that Jason, CJ, and I had a while ago about permissions. Hope it helps give some more context.