HIPAA-aware Customer Service configuration on Dynamics 365

A patient-access centre, a payer's member-services desk, or a medical-device support line running on Dynamics 365 Customer Service handles protected health information (PHI) on every interaction. HIPAA does not certify software; it makes the covered entity responsible for administrative, physical, and technical safeguards and makes its vendors business associates. Dynamics 365 can be configured to support those safeguards well, and misconfigured to undermine them just as easily. This guide covers the decisions that matter. For the industry picture see Dynamics 365 for healthcare.

Start with the agreement

Microsoft offers a HIPAA business associate agreement covering Dynamics 365 and the Power Platform as part of its online services terms, and the organisation's compliance team should confirm it is in place for the tenant before any PHI is loaded. The agreement covers Microsoft's obligations for the platform. It says nothing about the customer's configuration, the ISV apps installed in the environment, or the partner's access during implementation — each of those needs its own assessment, and the partner needs its own business associate agreement.

Minimum necessary, implemented

HIPAA's minimum-necessary principle maps directly onto Dataverse security:

• Security roles scoped to what each team does. A scheduling agent does not need the clinical-notes column; a billing agent does not need the case history of complaints. Build roles from the standard Customer Service roles downward, removing table privileges, rather than upward from a blank role.
• Business units or hierarchy security to separate facilities, regions, or service lines where staff should not see each other's patients. The hierarchical security guide covers the options.
• Column-level security for the PHI columns that live on otherwise broadly readable records — date of birth, member identifiers, diagnosis fields on a case. The field-level security guide describes profiles. Keep the number of secured columns small; every one is an ongoing maintenance item.
• Record sharing disabled or restricted where possible. Ad hoc sharing is how minimum-necessary quietly erodes.

The design mistake is modelling PHI on the contact record's main form where every licensed user can see it. Put clinical or claims detail on a related table with its own privileges, and keep the contact record to identity and communication preferences.

Audit everything that touches PHI

Enable Dataverse auditing at the environment level, then on the tables and columns holding PHI, including read access auditing where the organisation's policy requires access logs. Set the audit-log retention to match the policy — the retention period is configurable, and the default may be shorter than a compliance team expects. Route the audit data to Microsoft Purview or a SIEM if the organisation reviews access centrally; the Purview guide covers the connection. Audit logs that nobody reviews satisfy the letter of the rule and none of its purpose; agree who looks at them and how often.

Channels: chat, voice, and what gets stored

Omnichannel adds transcripts and recordings, which are PHI the moment a patient types a symptom or says a date of birth.

• Chat transcripts are stored in Dataverse with the conversation. They are subject to the same security roles and retention rules as any other record; make sure the roles that can read conversations are the ones that should.
• Voice recordings and transcriptions are stored in the environment's storage and follow its retention settings. Decide whether recording is on by default, whether agents can pause it (for card payments and sensitive disclosures), and how long recordings are kept. Consent announcements are configurable and required in many states regardless of HIPAA.
• Data masking rules in the Customer Service admin centre mask patterns in chat messages — card numbers by default, with custom patterns available. Adding patterns for social security numbers and member identifiers is a sensible step; masking cannot catch free-text symptoms, so it is a control, not a solution.
• Pre-chat surveys should collect the minimum needed to route, not a medical history.

Copilot and AI features

Copilot in Customer Service drafts responses, summarises cases and conversations, and answers from the knowledge base. The data it reads is governed by the user's permissions and stays within the Microsoft service boundary, which is why it can be used with PHI under the business associate agreement in a way that pasting a case into an external tool cannot. The decisions are organisational: whether summaries containing PHI should be generated and stored on the case, whether agents may use draft responses for clinical questions (usually no), and whether Copilot features are enabled per role. Enable narrowly, document the decision, and review the Copilot across Dynamics 365 guide for what each feature touches.

Email and documents

Email from Customer Service goes through Exchange Online, and the organisation's Purview sensitivity labels, encryption rules, and data-loss-prevention policies apply. Two habits: no PHI in subject lines, because subjects appear in notifications and logs; and case emails to patients limited to what a secure portal cannot deliver. Attachments on cases live in Dataverse or SharePoint depending on configuration; if SharePoint, the site's permissions must mirror the Dataverse roles or the minimum-necessary work is undone.

Integration with the EHR

Customer Service is not the clinical record. The pattern that keeps the boundary clear is the EHR as the system of record for clinical data, with Dynamics 365 receiving the minimum needed for the service task — appointment details, coverage status, a reference number — through FHIR-based integration, often via Azure Health Data Services and the Microsoft Cloud for Healthcare data model. Replicating the chart into Dataverse for convenience creates a second PHI store with a second set of controls and is the most common architectural mistake. The Cloud for Healthcare guide describes the data model and the connectors.

Ongoing

Access reviews through Entra ID at least quarterly, a documented process for terminating access the day someone leaves, a check of every new solution import for new tables holding PHI, and a breach-response run book that names who pulls the Dataverse audit logs. None of this is product configuration, and all of it is what an assessor will ask for first.