Using DX with Protected Health Information (PHI)
DX helps organizations understand and improve developer productivity by analyzing engineering productivity, software usage patterns, and employee feedback. This page explains how our service is intended to be used, and what to do if your organization works with Protected Health Information (PHI).
In brief: DX is not intended for processing, storing, or transmitting Protected Health Information (PHI). Because our service is not designed for PHI workflows, we do not offer Business Associate Agreements (BAAs) for DX.
How DX is intended to be used
DX is designed to help engineering organizations gain better understanding about how their teams work. The service collects and analyzes information from connected engineering systems, DX-native product surfaces, customer-supplied imports, and AI-assisted analysis features. Common categories of data that DX processes include:
- Connected engineering tools: Metadata such as titles from issues, work items, pull requests, merge requests, commits, reviews, labels, custom fields, users, teams, repositories, projects, and related metadata from tools such as Jira, GitHub, GitLab, Azure DevOps, and Linear.
- DX-native and customer-supplied data: Snapshot answers and comments (survey insights from your developers), PlatformX responses and event metadata (in-the-moment feedback from the users of their internal tools), Studies responses (targeted developer surveys), catalog entity descriptions and properties, custom data, and custom metric metadata.
- AI Code Insights data: Commit metrics, repository metadata, file-level attribution metrics, installation and status data, session metadata, and scrubbed session messages when transcript capture is enabled.
- DX AI and Data Studio data: AI-generated summaries, SQL generation, comment summaries, and analysis over engineering data, subject to DX AI and Data Studio access controls.
This information helps organizations identify trends, improve developer experience, and better understand how engineering teams collaborate and deliver software. The service is intended for organizational and operational data, not healthcare information about patients.
What this means for you
DX is designed for engineering metadata, and PHI should not typically be included in such data. If your organization uses DX, avoid submitting information that includes Protected Health Information (PHI).
For example, you should not use DX to collect, upload, or analyze:
- Patient medical records
- Clinical notes
- Diagnoses or treatment information
- Health insurance information
- Laboratory or imaging results
- Employee survey responses that include PHI
- Files or documents containing patient identifiers together with health information
If your organization needs to process PHI as part of a developer productivity or workforce analytics program, DX is not the appropriate service for that workflow.
Business Associate Agreements (BAAs) aren’t necessary to use DX
A Business Associate Agreement (BAA) is a contract used when a service provider processes Protected Health Information (PHI) on behalf of a HIPAA covered entity or another business associate. Because DX is not intended to process PHI, a BAA is not necessary to use this service and we do not offer a BAA.
Remove PHI before using DX services
We recommend that you take all necessary precautions to ensure that PHI is not sent to DX services. Some best practices include:
- Keep PHI out of upstream engineering tools. Do not put PHI in issue titles, work item descriptions, pull request descriptions, commit messages, labels, custom fields, branch names, survey comments, AI prompts, AI transcripts, or custom data payloads that may be sent to DX.
- Use non-PHI identifiers. Use internal ticket IDs, anonymized references, or other non-PHI identifiers instead of patient names, medical record numbers, health conditions, treatment details, or other health information.
- Limit connector scope. Configure service accounts, project access, repository access, and allowlisted fields so DX imports only the projects, repositories, teams, and custom fields needed for engineering reporting.
- Review custom data imports. Validate Data Cloud API payloads, catalog properties, event metadata, and custom tables before sending them to DX.
- Disable transcript capture for AI Code Insights if needed. AI Code Insights transcript capture is optional and off by default. If AI conversations could include PHI, keep transcript capture disabled for your organization. See FAQs for more information.
- Restrict sensitive data surfaces. Limit AI Code Insights transcript visibility, DX AI chat access to individual contributor data, and Data Studio access to trusted administrators.
- Train users and admins. Document which upstream fields are connected to DX and instruct developers, managers, and admins not to enter PHI into those fields. We strongly recommend regular training and monitoring to ensure relevant individuals comply with these policies.
FAQs
Quick reference
| Your intended use | Is DX appropriate? |
|---|---|
| Measuring software delivery performance | Yes |
| Understanding developer workflow trends | Yes |
| Running employee engagement surveys | Yes |
| Collecting patient information | No |
| Analyzing clinical records | No |
| Storing or transmitting PHI | No |
| Processing healthcare data that requires a BAA | No |