Microsoft has put a lot of effort into making your environment secure, however, that still does not absolve you of some things that you still have to configure.
Here is an example (using the examples in the SDK) of showing PHI:
Notice that you can essentially see EVERYTHING in that message, including that ever-so-important PHI.
There are a few things that you can to to remove/restrict access to that PHI.
Because there is the ability to see PHI in non secure places, Microsoft has a couple of places that you use to secure that data, based on your security policy. In some instances, the security stops at the firewall, if an intruder gets past the firewall, they have the keys to the kingdom. This security policy is fine for most instances, (thank goodness)! In my case, the last thing I want to do is have to peel off the layers of security to simply figure out that an element is missing from the HL7 message. At 2:00 am I simply want to log in and find out what is going on, what the error is, and fix it.
However, there are some out there that either do not trust their network admins, want to make troubleshooting harder, don’t trust their co workers, or were forced to implement additional security around PHI. For those, here are a few things that are available to increase security around PHI>
The first would be to turn off Event Logging and possibly choose SQL where more restrictions can be managed.
(Remember to restart the Audit and Logging Service)
Another would be to simply restrict who can have access to the event log in the first place, this can be done by changing the following key in the registry (did you see my disclaimer on the right side of this blog?)
Hive: HKEY_LOCAL_MACHINE
Key: SYSTEM\CurrentControlSet\Services\EventLog\Application
Name: RestrictGuestAccess
Type: REG_DWORD
Value: 1 Restrict access to Application log
But if you really want to get fancy, you can simply add the following entry into the BizTalk Server Operators group in Active Directory and restrict everyone else: (click to enlarge)