| Table of Contents |
|---|
What is
...
HIPAA
The Health Insurance Portability and Accountability Act (HIPAA) is a federal regulation developed by the U.S. Department of Health and Human Services, covering ‘health’ related data use.
Its not related to GDPR, but here as a close related topic. See https://www.atlassian.com/trust/compliance/resources/hipaa for more context.
Atlassian Platform
...
HIPAA support
Atlassian provides comprehensive privacy and security protections that enable customers to operate Atlassian products in compliance with HIPAA.
...
In the https://support.atlassian.com/organization-administration/docs/understand-hipaa-compliance-for-atlassian-products/ page. There you will find about how you sign a Atlassian Business Associate Agreement (BAA) with Atlassian and how you would configure the Atlassian Products to safeguard data that Atlassian hold.
Marketplace Apps
...
HIPAA support
Marketplace apps are not in scope for the Atlassian signed BAA. Our cloud app JEMHC has no concept of HIPPA HIPAA data and categorizations that you make on the Atlassian Product, we don’t extract/store data ourselves, the bare minimum information is stored (i.e. email addresses/personal names) for inbound/outbound auditing purposes. JEMHC is a tool, you can use it to extract data from the ‘source’ email content and store in your Jira instance in those pre-defined HIPPA HIPAA fields.
The https://support.atlassian.com/organization-administration/docs/the-hipaa-implementation-guide/ page states that:
All third-party apps integrated with Atlassian products also need to be operated in a HIPAA-compliant way. This means you must have a signed Business Associate Agreement (BAA) with all relevant third-party apps.
As we see it, enabling HIPPA HIPAA is done at the Atlassian Product (Jira/Confluence) level in order to apply “protection” to specific typed/identified/tagged data holding entities like Jira Custom Fields, limiting search and (I we expect) remote access from apps like JEMHC.
...
HIPAA compliance
According to https://www.atlassian.com/trust/compliance/resources/hipaa/requirements there is no official HIPPA HIPAA certification. As yet we have not been audited for HIPPA HIPAA compliance.
We are currently on a SOC2 compliance journey, do not have capacity for HIPPA HIPAA compliance as well. Once we have SOC2, HIPPA HIPAA will be possible.
How We/JEMHC enable
...
HIPAA compliance
Based on https://www.atlassian.com/trust/compliance/resources/hipaa/requirements, in the fullness of time, we will complete the following:
Risk management
Reduce risks and vulnerabilities, conduct periodic technical, and nontechnical evaluations in response to environmental or operational changes
We perform a risk assessment annually that include the identification, assessment, assignment, acceptance, remediation, and other relevant management activities, to ensure we operate within the agreed upon risk appetite and relevant legal and regulatory requirements. We continuously evaluate the design of controls and mitigation strategies, including recommending changes in the control environment. We maintain a risk and controls matrix within our Governance, Risk, and Compliance (GRC) tool.
Workforce security
Background screening and proper termination procedures
...
Formal sanctions exist and are employed for individuals failing to comply with established information security policies and procedures.
Information access management
Authorization of access for employees who work with ePHI
...
OS lock after 5m of inactivity. A screensaver is enforced with a requirement to enter a password to unlock it.
Incident response management
Audit logging/detection (including monitoring of login attempts)
...
recording every action, when managing an incident, into the Incident Management System under an incident ticket. Records must include:
incident start time
incident description
severity
services affected
impact
number of affected customers
root cause
actions taken
affected SLOs (capabilities impacted)
associating problems, where possible, with the underlying cause and/or grouping them together into parent incidents
completing a Post Incident Review (PIR) after Major and Critical Incidents
Security responsibility
Identify an individual responsible for the development and implementation of the HIPAA security compliance program
Andy Brook, CEO
Privacy responsibility
Identify an individual responsible for the development and implementation of the HIPAA privacy compliance program
...
UK: dpo@dataguard.co.uk , you can also use privacy@thepluginpeople.com to talk to us about privacy issues.
Security awareness and training
User awareness training
To do.
Contingency planning
Procedures to enable continuation of critical business processes
...
In support of contingency plan components, we assess services and systems for their criticality annually.
Business associate contracts
Business Associate Agreements contain satisfactory assurances that your data will be appropriately safeguarded by Atlassian and third party suppliers
We have Data Processing Agreements in place with all our sub-processors. BAA’s have not yet been progressed.
Physical security and endpoint controls
Safeguard physical facilities and equipment from tampering or theft
...
We wipe any laptop returned before it is redeployed or disposed. A lost/stolen laptop procedure is also in place to ensure data is not stolen.
Policies and procedures
Retain documentation for 6 years from the date of its creation, or the date when it was last in effect
...
Our Privacy Policy can be found here.
Transmission Security
Security measures to ensure that ePHI is not improperly modified
...
JEMHC (user) and JEMHC (system) IM notifications are only made using SSL protocol.
How to use JEMHC/support to
...
minimize HIPAA Impact
Being HIPPA HIPAA certified has challenges for us as an Email processor /sender, we need PHI (Email Addresses) for core functionality. We don’t specifically ‘know’ what data you store, so can’t specifically ‘redact’. We are not HIPPA HIPAA certified at this point. The following would be seen as the ‘technical measures’ our app has that could be applied for HIPPA HIPAA compliance.
The JSM notification templates we use include a limited subset of fields that notifications include, so overall JEMHC measures in place that support HIPPA HIPAA could be viewed as:
We limit what field we send in notifications (not all changed fields would be sent), you can add more fields specifically.
You can enable/disable inline images and attachments to be sent (at all)
You can enable/disable email-user support (that stores email addresses in custom fields where no portal user / Jira user is desired), Email Addresses are PHI, are a HIPPA HIPAA data category, for HIPPA HIPAA compliance, you’d probably have to not use this feature
You can enable/disable attachment of the raw Email to the issue, again for HIPPA HIPAA compliance you’d probably have to not use this feature.
If an inbound mail is not processed, a ‘fwd’ mail is sent to the Profile > Forward Users, linking to the Audit record involved. If you have disabled auditing the full mail is attached to avoid data loss. The full mail obviously contains IP addresses, recipient addresses, full content etc.
If you flag a mail for support in auditing, an issue is created in our support system referring the audit record. Only such flagged mails (its processing Report, your Profile) are available to all our support staff via a back-office app, through which data downloads can occur, such data is burned when support tickets are closed out.
Edge Cases
Webhook containing data about issue events (that drive JEMHC notifications) are kept for a short time, but still are available to System administrators, can be ‘saved’ as Preview Contexts for Template Set previews.
Auditing retains copies of Inbound and Outbound mail for 30days, this is available to System administrators. You can opt-out of auditing but make it hard for you to diagnose processing problems, and will prevent you from performing simple recovery actions (e.g. Jira user not allowed to comment) and will impact our ability to help with problems you may encounter.
Support
For HIPPA HIPAA compliance, for support purposes, you would need to ensure we don’t get PHI data. It means the onus is on you to re-create emails to demonstrate problems. The impact of the following will be that our ability to deliver great support will be hindered, a cost of HIPPA HIPAA compliance.
NOT send us an email containing PHI
NOT attach an email containing PHI to a support case
NOT use the “Flag for support” feature at all, to prevent any all PHI data from being exposed to use in support.
NOT send/attach the REPORT from processing a real email, as this may contain PHI.
Further Reading
Business Associate Agreement
BAA’s require legal oversight, we do not have one at this time.
Further Information
If you need more, feel free to log a support ticket with us:
...