codemonkeys

Correct, the Gravity drag ‘n draw signature field doesn’t work with the HIPAA Forms plugin.

We actually include our own drag ‘n draw signature field in the plugin that you can enable by going to the HIPAA Forms interface in the WP admin dashboard -> Settings Tab -> Form Settings sub-tab and then click on the triangle icon next to your selected form to expand the form settings. Check the show signature box and hit save.

You should now have the signature field at the bottom of your form.

The current version does not allow you create a confirmation email that goes out to the user. The reason we do not allow this is so that any PHI (Protected Health Information) does not get accidentally shared. However we are exploring the possibility of adding a generic confirmation email with a customizable response in a future release.

https://www.hipaaforms.online

Yes, you can select any of your Gravity forms to be HIPAA compliant.

The only caveat is that the free basic option only allows 1 active form but the standard paid option is unlimited forms and form submissions.

To prevent the possibility of passing PHI from the form to an insecure email we only allow the submitter’s first name, last name, email & phone to be passed using magic tags. You have to use an actual email in the “from” email setting and ideally it would be an email using the same domain as your website to prevent it from being flagged as a phishing/spam email. Otherwise if your “from” email uses a different domain you should use an SMTP plugin to ensure it gets delivered.

To redirect the form to another page on submission go to the HIPAA Forms interface, click on the settings tab at the top then click on the form settings sub-tab.

Click on the triangle icon next to the form you want to redirect which will expand that specific form’s settings options.

Under the “Submit Success Handler” section select the “Success Redirect” radio option and enter the url you want the form to redirect to in the input below and hit save.

If you’re getting an error on form submit saying the form was submitted but an email couldn’t be sent then most likely you have a malformed email address set as your “from” email. Most of the time this is due to trying to use magic tags instead of an actual email address here (ie {email}). Under the notifications tab ensure you have a proper email address set there.

You can also set a custom email notification within the specific form settings (same place you added your redirect url) which will over-ride the default notification settings. Again, if you set the email notification here remember to use a proper email address as the “from” email.

Finally, if you use an SMTP plugin to over-ride the default WordPress email function then make sure your SMTP creds are correct and you’re able to send a successful test message.

FYI…

Setting up your email to use TLS usually isn’t enough to satisfy HIPAA compliance.

You would need an E2E encryption solution as the data must be protected both in transit and at rest without the ability for a middle man to view the data.

Here’s some decent information on this type of stuff https://security.stackexchange.com/questions/157292/whats-the-difference-between-end-to-end-and-regular-tls-encryption

You would also need a BAA in place with both email providers (sending & receiving) or if it’s being handled through your own hosting server you would need a BAA with the hosting provider. In fact, you’ll need a BAA with your hosting provider regardless if any PHI will be passed through the website at all.

All IT contractors including you should have a BAA in place with the client as well.

We don’t currently have any plans of integrating Formidable Forms at least in the near future.

Thanks for the review Scott!

We just released V1.9.9 which should fix the both the conditional hidden required fields validation in multi-page/multi-step Gravity forms as well as the advanced address multi-field validation.

We’re looking into this now and will update you once we have it resolved.

We did put a fix into the last release V1.9.8 for this which wasn’t validating conditional required checkboxes/radios properly however this fix probably didn’t get applied to the multi-page form validation when going from one page to another.

We’re also looking into the advanced address field validation handling, my guess is Gravity structures the required option around that field group a little differently than a standard field so isn’t playing well with our validation.

We’ll try and get a fix out for both of these within the next day or two.

This is a very big issue we have at the moment with our subscribers and becoming one of our number 1 support issues.

This is incredibly unintuitive for users because they usually just click the “payment method” tab in their account page and add the new card there thinking it will update the card for the subscription which it doesn’t.

There’s absolutely no way for them to update the card BEFORE it expires so they have to wait for the payment to fail then go through the super confusing flow of clicking “manage” on the subscription, scrolling down to the order history section then clicking the “Pay” button to go through the checkout process again in order to renew the subscription. This seems crazy to me that a paid plugin this popular and widely used hasn’t bothered to put any effort into updating credit cards which everyone has to do every few years and is an issue that can/does result in lost subscribers/revenue.

This is not only causing us to lose subscribers & burn time on support tickets but it’s also embarrassing that we’re using such a clunky unintuitive system in 2018 when everyone just takes for granted that you should be able to do something as simple as updated your credit card’s expiration date on a subscription.

This is a big enough problem for us at this point that we have to reallocate dev time from actually working on our own product to figuring out a way to add credit card update capabilities to Woocommerce subscriptions.

This is most likely an issue with caching.

Wordpress uses a nonce (number used once) to help secure your site during things like form submissions and AJAX calls, although its not really a “number used once” in the traditional sense. Instead this is a hash token that can be used multiple times within a 12 or 24 hour period at which point the nonce will expire. What happens is if your cache expiration is set beyond 12 hours the nonce will also be cached resulting in a validation error as that nonce will have expired.

There are 2 things to look at to solve this problem. The first is to check any caching plugins you may be using such as W3TC, Super Cache, Rocket Cache, etc. Go through the settings and ensure your cache expiration times are set under 12 hours. A good way to ensure this error is due to a caching plugin is to simply deactivate the plugin, clear your browser cache, reload the page and try submitting a form again. If it works with your cache plugin deactivated then you know that’s the issue and its a matter of simply setting the expiration times lower.

If you have no cache plugin or your caching plugin is deactivated & your browser cache has been cleared and you still receive the nonce error then its almost certainly an issue with your host’s server-side caching. Cheap hosting solutions especially can have over-aggressive server-side caching as a way to keep resource usage down and keep those ridiculously low prices.

HostGator especially has been known to have issues with this & it can often be frustrating trying to get them to address the issue. You’ll have to insist that the issue is due to their SERVER-SIDE caching which I believe is Varnish & that the expiration time either needs to be reduced to under 12 hours or disabled entirely.

Be sure to update to the latest release (V1.5.9) as there is an important bug fix for anyone that has updated from versions prior to 1.5.5.

This wouldn’t be possible in the current version.

Currently anyone given either administrator or the hipaa user role would be able to access all submitted forms.

We are implementing the ability to completely separate forms by user role and/or specific users for the next major release so that specific users can only see specific form submissions.

Unfortunately even that option won’t really do what you need since you’re wanting the ability to still allow form data to be viewed by other users but with the e-phi stripped out. To do this we would need to add an option to each form to check if it should strip e-phi and be visible by others while still displaying the full form to the selected doctor then build in the ability to add an identifier to each field in the form to determine what is or isn’t e-phi and then build out the checks when viewing the submitted forms to determine if that user should see the full form or the stripped version.

This isn’t something we foresee building into the general plugin/api as it would add layers of complexity against a limited use case. One thing we’re trying to be very conscious of is usability compared to feature sets with this. It can be easy to go down rabbit holes with something that is already as complex as HIPAA and end up with a user interface that becomes overly complicated with too many settings and options that ends up just confusing the end users.

What you’re asking for is possible but I think we would have to build a custom one-off solution for it. If that’s something you want to explore feel free to give me a call at 715-941-1040 and we can try to scope it out for you.

Thanks!

Spencer