New post
AllAccepted answers
Jan Jachnik · Jul 17, 2018

Hi Murillo,

I have repeated the steps that you have described. The export of the components of the production is of just the items that you specify - so the project file, which is a list of pointers, and not the things pointed to by the project file. If you want to create an XML file that contains all of the items pointed to within the project you should export it from Studio. You can do that from the Tools >> Export... menu item, or by right clicking on the Project file in the Workspace and selecting Export.

Jan Jachnik · May 31, 2017

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.

Jan Jachnik · May 26, 2017

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.

Jan Jachnik · Nov 9, 2016

Hi Scott,

One way would be to use an Ensemble production in a separate namespace to take your example HL7v3 messages and send them into the required service of your HealthShare production. See the Ensemble HL7 Version 3 Development Guide, which provides an introduction to Ensemble HL7v3 capabilities in Chapter 1 with an example production described in Chapter 2. You can copy the example production from the ENSDEMO database and run it with the example messages that are provided in Chapter 3.

Hope that helps.

Jan Jachnik