HIPAA compliant digital signatures: What is considered an adequate approach?

We have a need to provide a method for electronically signing a medical note (all text) wihin a custom EMR. I am researching the options for this with a desire for a solution that will be compliant, but not overly complex.

The 3 choices that seem to be prevalent are:

1) Signing via currently logged in user
2) Explicit signing via password prompt
3) Hardware-based signature capture

Choice 3 is too costly. Choice 1 has issues with shared workstations. This leaves choice 2. I already have a generic authentication mechanism built-in that prompts the user for the password on a specified Active Directory account. This is done via a WINAPI call. I use this to restrict access to certain parts of our EMR but I haven't used it for electronic signature before.

My question is: Does authenticating against an AD account and documenting the authentication electronically constitute a 'good enough' electronic signature solution or do I have to do something like creating a hash of the data signed and the signature used and store that?

Who is Participating?
arnoldConnect With a Mentor Commented:
It would, the problem you run into with this approach is the determination on when to check/request this password.
The approach you seem to have is trying to secure the data by minimizing exposure for users leaving their workstations unattended.
As the first item you always run into the trouble of how to deal with user leaving their stations logged in and unattended.

I would think a secondary authentication as a means to confirm the modification made would be a better approach which would require the user to enter it only during the preview stage of final submission.
This may complicate your data collection where a user will be entering the data and seen as temporary/transient.

The issue with unattended workstations has to be dealt with a GPO that sets the screen saver on all domain workstations. i.e. 5 minute idle time and require password to regain access.
Making the user fully responsible for data entered at their terminal with their credentials may encourage users to lock their workstation when they leave their station (start+l) is a quick way to do that.
An electronic signature is a mechanism that would identify the person signing.
I.e. you have the logged in user, but to confirm you can request a pair of additional information something that "only" the person would know, i.e. last 4 of Social Security.  Or within the system the user's unique identifier.
A signature capture device is affordable, it all depends on whether the EMR you are using has the capability of incorporating it.
kkammAuthor Commented:
So it is not neccessary to "prove" the data was not tampered with after signing by using something like a public/private key mechanism?
Managing Security Policy in a Changing Environment

The enterprise network environment is evolving rapidly as companies extend their physical data centers to embrace cloud computing and software-defined networking. This new reality means that the challenge of managing the security policy is much more dynamic and complex.

I am not clear what you mean.
The software should maintain a history of who accessed the PCR, and who made modifications to it if any.
The log of activity is how you maintain the chain of transactions.
You should limit the editing.
You may want to use versioning such that if/when changes are made, you can still access a copy of the previously completed PCR.

kkammAuthor Commented:
An audit trail will be a part of this. (Data, user, timesatamp, intent)

We were also leaning towards using a series of separately signed addendums that spawn off of the originally entered data to capture any future data modifications while still maintaining the original. Once signed these records would not be editable again.

The tamperproofing I was referring to would be like an MD5 hash of the data combined with the signing user as components of the hash. I guess this wouldn't really be electronic signature - just security verification.

Does this sound like a viable electronic signature approach?
The same way a person with appropriate access that can modify the content will be able to modify/update the md5 hash.
The reference is straight forward for use of electronic signature as a means to identify/confirm who completed the PCR. There is no reason for an addendum to come from anyone else other than the crew providing services.

I think you are straining to make the thing to be "tamper proof" to a point that you make it unworkable.
One way to make it tamper proof is by generating a md5 hash using a key that is only known to the signer. You can then use the MD5 hash to confirm that there were no changes, but this will prevent the addition/modifications. or you would need to generate a hash at each step.
"provides service a, b, c, d" MD5 hash set of information plus some randomness
"addendum service a included 1,2,3,4
service b included i,ii, iii
service c,d performed the following tasks" MD5Hash using a new or the  set of information plus some randomness

The randomness is needed to make it more difficult to determine what the key used to generate the MD5 hash.

In a way to be on the same page, please clarify what you mean when you say "electronic signature"?

usually people who sign papers, have a copy of what they signed such that if there are pages added or omitted later on, they can always point to the copy they have in their possession as a reference.
kkammAuthor Commented:
'Electronic signature' in our case refers to signing off on a set of physician notes entered into our electronic medical record for each patient visit.

Currently, it is done by applying a macro to the note (straight text) that includes the physician name , the timestamp, and the intent. HOWEVER - there is no authentication involved. I have routines in a library that I can use to authenticate a user based on their Active Directory account but they are currently not linked to any signing mechanism in the main application.

My interest in the MD5 hash was from the standpoint of whether it is required as part of the signing process or simply a voluntary security enhancement.
Can say for certain, but my understanding that the 'electronic signature' is a means by which one can attribute the entry to an individual who made it.
A two set of information i.e. the user's login credentials get them to the data, but to update/save the data, a secondary prompt where the user would enter information only the user knows, would confirm "the identity" of the user.
A user has to be aware that if they shares passwords/information, they are responsible for whatever anyone does in their name.

Is your system wide open or if web based, you can use the NTLM to determine the username the user is logged in with.
Presumably you are maintaining a log outside the changes dealing with who accessed the customer's data and when....
kkammAuthor Commented:
Our system is closed. We maintain an audit record of entries and updates made to various fields in the application. The users are granted initial entry to the application through a domain desktop assigned to each user. Once logged in, however, the user may leave the workstation unattended. If a secondary user then enters new data it would be recorded under the security context of the original user. I need the secondary authentication to at least force the entering user to sign it using a valid security context. If a secondary user does not have knowledge of the passcodes the data they entered would remain either unsigned or rejected altogether.

I gather that a simple password prompt within the application which authenticates against a Windows Active Directory account (via a WinAPI call) would suffice as a starting point for implementing this. Does that sound reasonable?

kkammAuthor Commented:
We actually use an RFID-based system to switch to a non-interactive secondary desktop when the user moves out of range of the workstation. This system is only installed on exam room workstations where there is a lot of shared use.The rest of the workstations are set up with a GPO to lock the station after a period of idle activity.

Due to the workflow in our clinic I am not sure if asking for a password on the initial entry of the note would work. Our providers tend to start the note during a patient visit and then finish it up in a secondary session. Requiring the authentication as part of the signing of the final note makes the most sense.
That's fine, but why not ask for the password when the note is being submitted at the end rather than asking for ID when the secondary note is started??
kkammAuthor Commented:
I suppose I could do that for the security aspect. Principle of least required access ,etc.

Sometimes a Physician Assistant will start the note with a templated structure and the physician will fill in all the subjective details in the secondary session later, so I would still want a separate authentication for the signing of the note as only physicians should be allowed that privilege.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.