How to ensure HIPAA compliance in Jira and Confluence using Atlassian Marketplace apps

Understand the data

To comply with HIPAA, healthcare companies must start with understanding what data is going into and out of their systems and what medical information they are storing, especially with regard to protected health information (PHI). PHI is any information within a patient's record that could be used to identify them and was created or used within the context of healthcare.

The following information will help healthcare companies comply with HIPAA rules in Jira and Confluence using Atlassian Marketplace apps.

HIPAA identifiers

Names
Dates, except year
- All elements (except year) for dates that are directly related to an individual, including birth date, admission date, discharge date, death date, and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older
Telephone numbers
Geographic data
- All geographic subdivisions smaller than a state, including street address, city, county, precinct, ZIP code — and equivalent geocode — except for the initial three digits of the ZIP code if, according to the current publicly available data from the Bureau of the Census:
  - The geographic unit formed by combining all ZIP codes with the same three initial digits contains more than 20,000 people
  - The initial three digits of a ZIP code for all such geographic units containing 20,000 or fewer people is changed to 000*
Fax numbers
Social security numbers
Email addresses
Medical record numbers
Account numbers
Health plan beneficiary numbers
Certificate/license numbers
Vehicle identifiers and serial numbers, including license plates
Web URLs
Device identifiers and serial numbers
Internet protocol (IP) addresses
Full face photos and comparable images
Biometric identifiers (i.e. retinal scan, fingerprints)
Any unique identifying number or code

If any of the above data is paired with one or more of the other data points and used by a healthcare provider or used in a health plan, it's considered PHI. Under HIPAA, PHI stops being PHI if it’s stripped of identifiers that can tie the information to a specific person. If the above identifiers are removed, then it’s no longer PHI. In that case, HIPAA rules no longer apply.

17 restricted zip codes, per HIPAA

How to de-identify data

De-identifying health information means ensuring the information does not identify an individual, and there is no reasonable basis to believe that the information could be used to identify an individual.

There are two basic ways to de-identify data:

Expert Determination

You can use the Expert Determination method to ensure HIPAA compliance when using Jira and Confluence. In this method, a person who understands how to make the information non-identifiable scrubs the data and determines when the remaining data cannot be used alone or with other data available in the Jira issue/project/instance or Confluence page/space/instance to identify someone.

There is no specific professional degree or certification program for designating experts. Expertise may be gained through various routes of education and experience.

When data has been de-identified, no one should be able to look at the reference number, search for it in an instance, and find other results with that piece of information in it that also include someone's address, name, social security number, or other points above — the very act of looking makes it covered again by HIPAA.

How to determine what data is considered PHI

Principle	Description	Examples
Replicability	Prioritize health information features into levels of risk according to the chance it will consistently occur in relation to the individual.	Low: Results of a patient’s blood glucose level test will vary High: Demographics of a patient (e.g., birth date) are relatively stable
Data source availability	Determine which external data sources contain the patients’ identifiers and the replicable features in the health information, as well as who is permitted access to the data source.	Low: The results of laboratory reports are not often disclosed with identity beyond healthcare environments. High: Patient name and demographics are often in public data sources, such as vital records -- birth, death, and marriage registries.
Distinguishability	Determine the extent to which the subject’s data can be distinguished in the health information.	Low: It has been estimated that the combination of year of birth, gender, and 3-digit ZIP code is unique for approximately 0.04% of residents in the United States 9. This means that very few residents could be identified through this combination of data alone. High: It has been estimated that the combination of a patient’s date of birth, gender, and 5-digit ZIP code is unique for over 50% of residents in the United States 10,11. This means that over half of U.S. residents could be uniquely described just with these three data elements.
Assess risk	The greater the replicability, availability, and distinguishability of the health information, the greater the risk for identification.	Low: Laboratory values may be very distinguishing, but they are rarely independently replicable and are rarely disclosed in multiple data sources to which many people have access. High: Demographics are highly distinguishing, highly replicable, and are available in public data sources.

The Expert Determination method is a high lift and can be subject to error. For that reason, we recommend enterprises follow the Safe Harbor method where possible.

Safe Harbor

The Safe Harbor method is the removal of the 18 HIPAA identifiers listed above. In the Safe Harbor method, no parts or derivatives of any of the listed identifiers can be disclosed — not even the last four digits of a social security number, for example. Some elements can be stripped of identifying aspects, like dates, or anonymized.

Elements of dates that are not permitted for disclosure include the day, month, and any other information that is more specific than the year of an event. For example, using the date, “January 1, 2009” isn’t allowed but it can be reported in a de-identified data set as “2009.” The same goes for ages over 89; rather than list the year of birth exactly, you could say a person was born “on or before 1920.”

These are just two examples of how the identifiers can be handled; actual guidelines can be found in the HSS article, Methods for de-indentification of PHI.

Marketplace app handling of PHI

The below tables will help you understand, in two phases, how Atlassian Marketplace apps handle the identifiers mentioned above so that you can find the best fit for you.

The first table shows which apps are preconfigured to remove data, which apps allow for custom search criteria, and which apps are completely manual. Next, the table lists what each app considers when scanning for PHI. Finally, the table shows which specific data points are configured out-of-the-box and which must be manually configured.

Click here to see the entire data table

Marketplace App Name (Product)	Bug Bounty (?)	Type	Method	Custom Search	Reversible	What it looks at within the Atlassian product	Out of the Box	Custom Templates
PII Protector (JSW)	NO	Safe Harbor: Hide or Erase	Automated	YES	YES	Out of the box, PII Protector for Jira scans issue summary, description, comments and history. If you want to scan additional custom fields that contain free-form text data, you can add them in PII detection rules by specifying them in Custom fields field.	Template has 5 data points selected: Email Credit card numbers Phone Number IP Address Postal Address The following can simply be selected on that OOTB template: US social security numbers (SSN) International phone numbers Canadian, British and Irish postal addresses IBAN numbers VAT numbers National Provider Identifier (NPI) Medical Record Number (MRN) Vehicle identification number (VIN) Swiss social security numbers Canadian social insurance numbers (SIN) French INSEE codes British national insurance numbers (NINO) Finnish personal identity codes (HETU) Swedish personal identity numbers Norwegian birth numbers Czechian birth numbers Polish identification numbers (PESEL) Danish personal identification numbers (CPR) Spanish national identification number (DNI) Netherlands identification number (BSN / Sofi) Israeli ID number (Mispar Zehut)	Customized searching by Regex expression. The vendor is extremely open to improvement requests.
PII Protector (C)	NO	Safe Harbor: Hide or Erase	Automated	YES	YES	Page, blog post, comment, old content versions, attachments
Attachment Checker (JSW)	NO	Safe Harbor: Limit	Automated	YES	NO	Attachments on issues	Whitelisting / Blacklisting file types Limiting the number of attachments per issue Restricting attachments with duplicate file names Scanning attachments for viruses Notification for attachment events Restrict user groups from downloading attachments Log attachment download
Attachment Checker (C)	NO	Safe Harbor: Limit	Automated	YES	NO	Attachments on pages	Whitelisting / Blacklisting file types Scanning attachments for viruses Notification for attachment events File size limits per user group Scheduled jobs to scan for quotas Log attachment download View disk usage and enforcing attachment quotas by space
GDPR and Security (JSW)	NO	Safe Harbor: Anonymize	Automated	YES	NO	system fields of the text type (Summary, Description, Comment) system fields of the user type (Creator, Reporter, Assignee, Comment Author Attachment Author, Worklog Author, Watcher, Vote) custom fields of the text type (Epic Colour, Epic Name, Grid, Root cause, Test field, Text Field (multi-line), Workaround) custom fields of the user type (Approvers, CAB, Change managers, User, Request Participant, Approvals) history fields (History, History Authors)	Standard international & EU phone numbers Social Security/National IDs for all of EU Email addresses Standard credit card numbers International Bank Account Number (IBAN) Internet Protocol version 4 (IPv4)	Customized searching by Regex expression.
GDPR and Security (C)	NO	Safe Harbor: Anonymize	Automated	YES	NO	Pages, blog posts, entire spaces	Customized searching by Regex expression.
Nightfall DLP DC (JSW) Nightfall DLP DC (C)	NO	Expert Determination	Manual	YES	NO	In order to more accurately detect potential PHI, Nightfall has introduced specific new Detectors that allow for specialized combinations of criteria in text and files.	No preconfigured templates but it does allow for specialized combinations of criteria based on HIPAA.	https://docs.nightfall.ai/docs/creating-detection-rules

The next table summarizes how the Atlassian Marketplace apps handle the 18 points of identifiers — with an additional line for credit card numbers — and whether it’s out of the box () or must be created as a custom search ().

Atlassian Marketplace apps for HIPAA compliance

Identifiable Information	PII Protector (PIIP)	General Data Protection Regulation (GDPR)	Attachment Checker	Data Leak Protection (DLP)
Dates, except year
Telephone numbers
Geographic data - street address
Geographic data - city
Geographic data - country
Geographic data - precinct, ZIP
FAX numbers
Social security numbers
Email addresses
Medical record numbers
Account numbers*
Health plan beneficiary numbers*
Certificate/license numbers*
Vehicle identifiers and serial numbers, license plates*
Web URLs*
Device identifiers and serial numbers*
Internet protocol (IP) addresses
Full-face photos and comparable images**	?
Biometric identifiers**	?
Any unique identifying number or code*
Additional parameter: Credit Card Numbers

* The generalization of data points requires configuration to meet all use cases.

** The searching of attachments may account for these file types.

Atlassian Suggestion

Given the needs of a healthcare company within an enterprise Atlassian environment, you may want to use a combination of PII Protector and Attachment Checker for Jira and Confluence.

Was this content helpful?

Connect, share, or get additional help

Atlassian Community