Can someone please explain what a Proxy user in HealthShare can and can not do?

Hi -

In HealthShare clinician user specifications (as well as in the the clinical viewer), there are locations for specifying "proxy" user(s), but there doesn't seem to be anything in any of the documentation that explains what this actually means/enables.

  • 0
  • 0
  • 191
  • 2
  • 3

Answers

There is a modicum of documentation on this in my 2016.2 release:

Proxies:
If you selected the clinician check box, you may add proxies, who are other users who may assume the patient/clinician relationships of this user. The proxy user must already have been created. To add a proxy:
  1. Click Add...
  2. Search for a user (as described below).
  3. Click the link in the row for the selected user.
To delete a proxy, select the name from the list and click Delete.
Note that the Proxies section is hidden unless the Clinician check box is selected.
 
In the 2009.1 release notes:
Identification Services
Clinician Registry
Proxy User Accounts
HealthShare now supports proxy user accounts that are authorized by clinicians to assume some portion of their account credentials. With version 2009.1.2, a proxy user may only assume the patient relationships defined for the clinician for which they’re acting as a proxy.
 
In the 2010.2 release notes:
Patient Search Portal
Results Filter
The search portal now includes two types of results filter:
  1. Relationship — HealthShare displays search results where the clinician has the specified relationship with the patient, for example:
    • any
    • primary
    • referring
    • consulting
    For proxy users, the relationship of the clinician whom the proxy is supporting is used as the result filter.

 

In [ Running a HealthShare Information Exchange ]  >  [ Information Exchange Security Guide ]  >  [ User Authentication ]:

Information Exchange employs a federated authentication model that supports single sign-on for Information Exchange users. By creating various authentication domains, you can tie several different domain-specific login IDs to a single Information Exchange user ID. The user’s privileges may depend on which domain they log in from, however.
 
The same login ID in different authentication domains may refer to different user IDs.
Authentication in Information Exchange is centralized to a single user registry at the Registry. This also acts as a clinician registry, listing all clinicians, whether or not they are Information Exchange users.
Information Exchange also supports the notion of a proxy user, an individual who is authorized to log in in place of one or more clinicians and who enjoys the same clinician/patient relationships as the clinician. Frequently, this would be an assistant to a clinician logging into Information Exchange in order to pull down a patient record at the clinician’s request.

 

To answer your question about what can a proxy user do/not do: proxy users are users in their own right and can do/not do whatever they have been set up to access in that context. In addition to that,  they assume the patient relationships of the clinicians that they are supporting as proxy. While the proxy relationship allows access to the patient record it would not grant privileges beyond the role of the underlying proxy user account.

Thanks for the thorough explanation of this subject. Documentation about proxy users has been difficult to track down. I do have an additional question about proxy users and how they related to subscriptions, however. From the IE Security Guide you quoted above: [emphasis added]

Information Exchange also supports the notion of a proxy user, an individual who is authorized to log in in place of one or more clinicians and who enjoys the same clinician/patient relationships as the clinician. Frequently, this would be an assistant to a clinician logging into Information Exchange in order to pull down a patient record at the clinician’s request.

Should a clinician's proxy inherit a relationship-based subscription to which the clinician has subscribed? We've seen some inconsistent behavior around proxies and subscriptions, and I'm not sure what the expected behavior actually should be.

For example, in our test environment, it appears that simply making User B a proxy for User A will not include User B in notifications from A's relationship-based subscription, even though B is supposed to assume the relationships of A. Additionally, if we use User B's email in place of A's (for cases where the clinician does not wish to receive the notifications), User B receives an error after following the link and logging in because they are not authorized to view the document. This seems to contradict the statement in the Security Guide which states that proxies are authorized to log in on behalf of a clinician. Is this expected behavior?

I'm hoping someone in the community who has some experience with proxy users will chime in here, since either I seem to be misunderstanding how they're supposed to be set up and used, or they don't work as they're described. The little documentation there is about these types of user account designations seems to contradict the behavior I'm seeing.

As an experiment, I created a clinician user account called UserA and set him up as both "Active" and "Clinician" in the Clinician/User Registry, then linked him to his Access Gateway account, where he has the role of %HS_Clinician. I then defined a relationship of "Primary" with 4 test patients. When I login as UserA and go to his Clinician Portal, if I click on Relationships and choose Primary from the drop-down, I see all 4 test patients just as I would expect to. (Interestingly, I'm using HS version 2016.2.1 and I don't see the option to use Relationships as a results filter unless I navigate away from Patient Search and return several times. Eventually it will show up as an option.) When I do a patient search using the relationship filter of Primary as the only search criteria, I see only the 4 patients I linked to UserA, which again is expected behavior.

To set up a proxy, I created a user account called UserB following the same steps as above, but since proxies are described in the documentation as possibly being administrative staff, I gave UserB the role of %HS_Clerical and did not tick the Clinician box in the Clinician/User Registry. However, leaving this box unchecked made it impossible to define UserB as a proxy for UserA. Apparently, proxies must be set up as Clinicians in the registry, because as soon as I did this, I was able to find UserB and make him a proxy for A. I didn't define any relationships for UserB.

I then logged in to the Access Gateway as UserB to view my relationships, and there were none. I performed a patient search using relationships "Primary" and even "Proxy," and again, I found nothing. So apparently, simply designating UserB as A's proxy did nothing--no relationships were inherited (or "assumed" as the documentation says) and nothing was transferred. They're just two different accounts.

I can correct this to some extent by logging in as UserB and manually defining Proxy relationships with those 4 patients, which is perhaps what I'm supposed to do, but this seems to defeat the purpose of designating a proxy in the first place. That's not assuming existing relationships; it's defining new ones. This may seem reasonable for these 4 patients, but what if this were a clinical assistant who was to act as a proxy for a clinician who had 97 patients? Do these need to be manually linked to the proxy user one by one? I could use the option to move the relationships from one user to the other, but that literally moves them and UserA will no longer be their Primary. 

Am I setting the proxy up correctly, or are there additional permissions or account settings that need to be set for the patient relationships to be assumed by the proxy?

Hi Matt,

I tried out the example you had given using the HealthShare demo users Sam Farrell and Proxine Jones, whom you may have guessed is set to be a proxy for Sam. I got similar results to you so was none-the-wiser, which led me to ask the HealthShare development team. This is their response:

Proxy users were invented to support a very limited use case – a clinician filling in for another clinician.  The only functionality that they enable relates to how consent is applied to managing relationships.  In order for someone to create a patient-clinician relationship, they either need the general security resource that allows them universal rights to do this - %HSAdmin_RelationshipManagement, or they need some sort of consent to access the patient record.  This consent can be granted if the user/clinician has MPI level consent to access any of the patient’s records, or if there already is an existing patient/clinician relationship for them.  Proxies impact the latter – if they are acting as a proxy for another clinician, then it instead checks if there is an existing patient/clinician relationship to that clinician.

For Proxine, in order for her proxy relationship to take effect, she needs to assert that she is acting as a proxy.  To do that, she would go into the patient search UI, and click the Proxy link at the top of the search page.  This lets her assert that she is acting as a proxy for Sam (or if she has been allowed as a proxy for some other clinician, she can select them instead).

The assertion in the documentation that a non-clinician could be set as a proxy is wrong and I have requested a correction to that. As you correctly pointed out, the only users that can be assigned as proxies for a clinician are other clinicians. I hope this provides the answer that you were looking for.

Hi Jan,

Thanks a lot for this explanation. This explains the behavior I was seeing, and I have a much better understanding of how proxies are supposed to be used. After setting up UserB as a proxy to UserA, I logged in as UserB and searched for patients using only the "Primary" relationship filter and found nothing. I then clicked the Proxy link on the Patient Search page as you described and chose UserA and performed the same search, and this time I saw all the patients who had UserA as a Primary, which is exactly what I would expect to see. I think what I found initially confusing is that I was expecting to see an indication of these relationships in the Clinician Portal, but they only seem to be apparent when performing a patient search. 

I think this also answers my original questions regarding proxies and relationship-based subscriptions: the proxy relationship does not automatically include the proxy in the same subscriptions as the clinician to whom they are a proxy. It appears to only apply to searching and viewing patient records during an active section after "claiming" the proxy relationship.

Thanks again for your response.