External Authentication - Securing PHI and Client-sensitive Information

[rkmullis]

I'm posting this is the Healthcare forum, as well.

I'm curious to know if other health care-related companies have implemented two-factor authentication for external users in order to protect PHI and other client-sensitive information. As currently designed, HTTPS and and a VPN provide encrypted communications, but if a user ID and password are compromised, there's no secondary challenge to the authentication process.

IP access controls are another option, and we could redirect external users from the ServiceNow login page to a two-factor authentication portal, first.

I'm curious to learn how other companies in this space have managed this.

[pjordan430]

We have not implemented two-factor authentication, however PHI related to Service-Now has been a widely discussed topic in my department. I would suggest consulting with your Compliance department to see if a two-factor system is even necessary.

If an ID and password is compromised by the user, I would think that the liability then falls on the user for their lack of responsibility. If the ID and password is compromised due to malware or something similar, then the liability should fall on whoever is in charge of security.

We approached the PHI problem by attaching a separate custom form to the Incident form and created a button called "View or Add PHI" to access this PHI form. There we have encrypted fields where non-role users can add PHI. We also moved the "attachment" option to this PHI form and have encrypted this as well. Once an end user has attached or added PHI, the encrypted fields are no longer visible to the end users. Only users containing the ITIL role are able to see these encrypted fields. We try and discourage all users from entering PHI in any other Incident fields besides the encrypted ones; however that will never work 100% of the time. This approach is not well liked by our IT users or end users for that matter since it takes more time to enter information into a ticket.

Some employees in my department find this PHI situation to be very complicated and see a need for further action, while others disagree. The main problem is that it is hard for us as IT employees to truly know how to approach the PHI issue and absolve ourselves from liability. I strongly suggest discussing this situation with your Compliance department to get a better understanding of how to approach PHI in Service-Now.

[chrisgillham]

We have implemented two-factor authentication using an Installation_Exit script that calls a custom built web service we built and host, which invokes a PhoneFactor call. The Installation_Exit script only causes two-factor authentication for users in certain roles and based on IP location to help minimize impact while on the corporate network and only is needed when on foreign networks.

Chris Gillham
Maritz
chris.gillham@maritz.com

[davidcmccourt]

Hello Paul,

I would be very interested as to how you managed to implement this. Ie how did you manage that users can enter text into encrypted fields without having the encryption context associated to their user.

Any help you can give would be excellent.

Thanks in advance,

Dave.

[WilliamHazelrig]

Dave,

We wound up dismantling our PHI-protection system when we got word from Compliance that their interpretation of HIPAA did not require us to secure and audit PHI to nearly the same degree in ServiceNow as we would in a system whose primary purpose is to handle PHI. However, before we dismantled it, here is an outline of how we tackled the problem, including the encryption issue:
1) We segregated PHI into a separate form from Incident, related to it.
2) Access to that form was via a UI Action which logged an audit that the current user had opened that record.
3) We had an ACL on the PHI form which denied read access unless that audit was present and dated within the last 30 minutes. It's actually a little more complicated since our design had "PHI Items" in a separate form and those were an embedded list on the PHI form, but if we had it to do over again we'd have kept the PHI all on one form, and mostly in the format of a Large String field, with the exception of a few key patient identifier fields; the human process efficiency gained would be well worth the database inefficiency.
4) We had an encrypted and an unencrypted field pair; the customer would submit data via the unencrypted field of the pair, and the form's encryption status was tracked in a separate true/false field.
5) Because the customer would need to be able to see the PHI he or she had entered until the issue was resolved to his or her satisfaction, the data would be left in the unencrpyted field until the Incident was actually Closed (not just Resolved).
6) We set up a Business Rule on a separate "automation" table, which was triggered on the insert of a record into that table, that would scan for all PHI records where encryption status was false but the related Incident was Closed, perform the encryption (including attachment encryption), and update the record in the first pass. In the second pass, the business rule would verify that the encrypted field data matched the unencrypted field data; there were occasional failures in the process and we don't want to delete the unencrypted data if the encrypted field didn't get properly set. If the second pass found no issue with a record, it would clear the unencrypted fields and set the encryption status flag to true, then update that record again. We then had a simple ASP.Net command-line program running on a timer from here, which would log in with credentials having the appropriate Encryption Context, and insert a record into the "automation" table; we did it that way because a timed job running in ServiceNow does not operate in a user context, and hence would have no access to the Encryption Context.