New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify user roles / permissions #10

Open
jasonaowen opened this Issue Apr 27, 2017 · 25 comments

Comments

@jasonaowen
Contributor

jasonaowen commented Apr 27, 2017

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

This comment has been minimized.

Contributor

jasonaowen commented Jun 23, 2017

@brainwane brainwane changed the title from System administrator should not be able to view enrollments to Limit sys admins', service agents' ability to view enrollments Aug 3, 2017

@brainwane brainwane changed the title from Limit sys admins', service agents' ability to view enrollments to security: Limit sys admins', service agents' ability to view enrollments Aug 3, 2017

@brainwane

This comment has been minimized.

Contributor

brainwane commented Aug 3, 2017

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.
several-enrollments

@brainwane brainwane changed the title from security: Limit sys admins', service agents' ability to view enrollments to security: Limit sys admins', service agents' ability to view, edit enrollments Aug 3, 2017

@brainwane

This comment has been minimized.

Contributor

brainwane commented Aug 7, 2017

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.

@kfogel kfogel changed the title from security: Limit sys admins', service agents' ability to view, edit enrollments to Limit sys admins', service agents' ability to view, edit enrollments Sep 6, 2017

@cecilia-donnelly cecilia-donnelly added this to the December deliverables milestone Oct 2, 2017

@jasonaowen

This comment has been minimized.

Contributor

jasonaowen commented Oct 2, 2017

@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

This comment has been minimized.

Contributor

brainwane commented Oct 2, 2017

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

This comment has been minimized.

cecilia-donnelly commented Oct 5, 2017

@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

This comment has been minimized.

Contributor

jasonaowen commented Oct 5, 2017

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

This comment has been minimized.

cecilia-donnelly commented Oct 5, 2017

@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.

@cecilia-donnelly cecilia-donnelly added this to To Do in MVP Dec Oct 10, 2017

@jasonaowen

This comment has been minimized.

Contributor

jasonaowen commented Oct 10, 2017

@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

This comment has been minimized.

Contributor

jasonaowen commented Oct 10, 2017

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

This comment has been minimized.

Contributor

brainwane commented Oct 10, 2017

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

This comment has been minimized.

chj124 commented Oct 11, 2017

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

This comment has been minimized.

cecilia-donnelly commented Oct 11, 2017

@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

This comment has been minimized.

Contributor

kfogel commented Oct 13, 2017

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

This comment has been minimized.

cecilia-donnelly commented Oct 13, 2017

@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.)

@cecilia-donnelly cecilia-donnelly moved this from To Do to In Progress in MVP Dec Oct 13, 2017

@kfogel

This comment has been minimized.

Contributor

kfogel commented Oct 13, 2017

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 cecilia-donnelly moved this from In Progress to To Do in MVP Dec Oct 23, 2017

jasonaowen added a commit that referenced this issue Nov 1, 2017

Do not allow system or agent to see enrollments
Remove the system administrator (who can create and edit users) and the
service agent (whose role is currently being reconsidered) from the list
of roles with full access to enrollment data. Viewing the list of
enrollments as a user with either role should show an empty list, and
trying to view an existing enrollment (such as by going to a known URL)
will show an error to the user and log an "Access Denied" exception.

Note that visiting https://localhost:8443/cms/ops/viewDashboard will
still show recent events, which are things like "NPI 1234567893 was
approved". The links in these events do not work. We'll need to consider
if and how we want the recent events panel to work for the various
roles.

Issue #10 Limit sys admins', service agents' ability to view, edit
          enrollments

jasonaowen added a commit that referenced this issue Nov 2, 2017

Further restrict agents and system administrators
Lock down operations like reviewing enrollments, setting categories of
service, seeing admin details of agreement documents, or editing help
items to only be allowed for service administrators (like the `admin`
user).

Issue #10 Limit sys admins', service agents' ability to view, edit
          enrollments

@cecilia-donnelly cecilia-donnelly moved this from To Do to Done in MVP Dec Dec 14, 2017

@cecilia-donnelly cecilia-donnelly removed this from the December deliverables milestone Dec 15, 2017

jasonaowen added a commit that referenced this issue Dec 21, 2017

Allow system role full access for processing
When I removed access from the system role in
83f2cbc, we didn't understand how
pervasive the PSM used the system role for internal processing. The
first visible problem was that the post-processing of a submitted
enrollment application failed, as the post-processing code no longer had
permission to read or modify the application, but this was not the only
problem.

We will continue to change internal processing code to no longer require
the system user to have full access, but in the meantime, restore the
functionality of the system to unblock development of other issues.

This partially reverts commit 83f2cbc.

Issue #10 Limit sys admins', service agents' ability to view, edit
          enrollments
Issue #546 Post processing fails on submitted enrollment applications
PR #524 Restrict agents and system administrators
@cecilia-donnelly

This comment has been minimized.

cecilia-donnelly commented Jan 23, 2018

@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

This comment has been minimized.

cecilia-donnelly commented May 29, 2018

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.

@cecilia-donnelly cecilia-donnelly referenced this issue May 29, 2018

Closed

Add authn/authz to FHIR API #847

3 of 3 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment