The original report suggests it was a problem in Ensemble 2016.1 but I tested with Ensemble 2016.3 and it appeared to be OK. I found the problem with HealthShare 2017.1 and it is documented as fixed in Ensemble 2017.2. I tested in HealthShare 2017.2.1 and it works correctly.
It appears that there was a bug in the export method which meant that the deployment export file included just the contents of the project file and not the items referenced in the project file. This has now been fixed but it affects the HealthShare version that Murillo is using and which I had also tested with.
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.
Searching on "anonymization" in the documentation reveals information about the Feeder Gateway Production, which carries out anonymization for the purpose of analytics. It may not be using DTL but if your goal is anonymization then this would seem to fit the bill.
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.
There is a modicum of documentation on this in my 2016.2 release:
In [ Running a HealthShare Information Exchange ] > [ Information Exchange Security Guide ] > [ User Authentication ]:
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.
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 theEnsemble 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