How to make an app HIPAA compliant

An app can support HIPAA-compliant use, but the assessment must cover its intended use, connected services, agreements, safeguards, and clinic procedures—not just its features. Start by following patient information through the complete workflow.

HIPAA guides

Can an app be HIPAA compliant? Start with its intended use

The useful question is: Can this app support our proposed use of patient information, under the agreements and configuration we will actually use? That is more specific than asking whether the product has a compliance badge. See what HIPAA compliant means for the distinction.

Consider two hypothetical clinic tools:

• An appointment tool receives patient names, contact details, and reasons for visits.
• A staff announcement tool contains only office closure notices and supply-delivery updates.

Assess the information in each workflow rather than assuming both tools have the same obligations because a clinic uses them.

Use this evaluation framework:

• Identify the information involved.
• Establish applicable obligations.
• Check agreements and covered services.
• Review and configure safeguards.
• Confirm operational readiness.

HIPAA Compliant Wiki reports vendors’ published terms and controls; it does not audit software or certify an organization’s compliance. This guide is not legal advice, a complete compliance program, or approval to handle protected health information (PHI).

Map where patient information enters, moves, and stays

Describe the workflow before reviewing feature lists. Use a worksheet like this:

Record	Questions to answer
Information collected	Which fields, attachments, images, or message contents will people enter?
Purpose	Why does the clinic need each item?
Users	Who submits, views, edits, downloads, or administers it?
Storage	Where does the original information stay? Where might copies exist?
Recipients	Which staff members, outside parties, or services receive it?
Connections	Which integrations, APIs, or optional features process it?
Exit paths	How do exports, deletion, account closure, and recovery work?

For example, a patient might complete an intake form that sends a submission to a clinic inbox. A receptionist might then save an attachment in shared file storage.

Mark the form service, email service, and file-storage service separately. If an automation transfers the attachment, add that service too. Do not stop the map at the app’s interface.

For mobile use, ask about device storage, camera uploads, downloaded files, notification previews, device backups, and what happens if a phone is lost.

Also ask whether patient information could enter analytics events, crash reports, support tickets, test environments, or AI features. These are investigation questions—not assumptions that every app sends information to those destinations.

Use patient data security basics to support the broader review.

Check applicable obligations and BAA coverage

Determine the clinic’s role, the developer’s role, and each service provider’s role before deciding which agreements are needed. Distinguish an app independently chosen by a consumer from one operated for a clinic; “medical app” branding alone is not an applicability assessment.

Treat business associate agreement (BAA) review as a separate task from reviewing security features.

Subject to applicable exceptions, covered entities need business associate agreements with their business associates, and business associates need downstream agreements with subcontractors handling PHI on their behalf; these agreements do not replace safeguards or permit otherwise prohibited disclosures.

For every service in the data map, check:

• Plan: Does the agreement apply to the subscription being purchased?
• Service scope: Which products and functions are covered?
• Exclusions: Are optional features, integrations, or other services outside that scope?
• Execution: What must happen before the agreement takes effect?
• Downstream services: What do the terms say about subcontractors and connected providers?

Use this guide to check a vendor BAA’s plans, covered services, and exclusions.

Suppose a reminder service receives appointment details through an automation provider. Review both services and their respective roles. Do not approve the automation merely because the reminder service has an agreement.

Review app safeguards without treating them as a compliance checklist

For every control, ask: What does the vendor provide, what must the clinic configure, and what evidence shows it works?

The following are evaluation areas, not a statement that every listed implementation is universally mandatory.

HIPAA requires administrative, physical, and technical safeguards, including access control, audit controls, integrity, authentication, and transmission security; encryption and automatic logoff are addressable specifications requiring a documented assessment, not freely optional features.

Area	Vendor evidence to request	Clinic decision or test
Access permissions	Role descriptions and administrative controls	Can reception staff access scheduling information without seeing unrelated files?
Authentication	Available sign-in controls and setup instructions	Which controls will apply to staff and administrators?
Sessions	Session-management and revocation behavior	What happens on a shared workstation after a user leaves?
Account removal	Offboarding steps and access-revocation behavior	Can a temporary worker’s access be removed across active sessions?
Encryption and files	Documentation covering transmission, storage, uploads, and downloads	Does the documented scope match the proposed workflow?
Audit information	Available events, access methods, and export options	Can the clinic investigate a relevant access or configuration change?
Retention and deletion	Options, limitations, and treatment of copies	Which settings fit the clinic’s documented needs?
Recovery	Backup and restoration arrangements	Who requests restoration, and how would restored access be checked?

A receptionist and a temporary billing worker may need different access. Test those roles separately instead of relying on an administrator’s demonstration.

Ask vendors to demonstrate controls where possible. A statement such as “permissions available” does not explain which records a role can see or what happens after access is revoked.

The distinction between HIPAA eligible versus HIPAA compliant is useful here: availability of a service or control is not the same question as readiness of the configured workflow.

Check mobile and connected-service risks separately

Picture a clinic phone used by different reception staff. Review what happens when an appointment notification appears while the phone is locked, someone downloads an attachment, or the device goes missing.

Ask:

• Can notification previews expose patient details?
• Can staff distinguish their accounts on a shared device?
• Where do downloads and camera uploads remain?
• Could device backups include app information?
• Can access be blocked without recovering the phone?
• What happens to existing sessions after an account is disabled?

Do not assume the answers are the same across mobile and web versions.

For a custom app, inventory hosting, storage, messaging APIs, analytics, support services, SDKs, and other components. Give each component an owner and a documented decision about the proposed data flow.

For a purchased app, examine integrations and optional features separately. Request evidence of their contractual coverage rather than extending the main product’s coverage by assumption.

Give AI its own review: identify the provider, connected model, information sent, agreement scope, and settings. An AI feature’s presence in the interface is not evidence that it is approved for the same information as the rest of the app. Use the guide to review AI tools before sharing PHI.

Put clinic procedures around the app

Assign responsibility for access approvals, configuration changes, vendor reviews, and staff questions. Avoid leaving these decisions with an unnamed “IT team.”

Document onboarding and offboarding around the actual workflow. For example, show reception staff which fields to use, where attachments belong, and how to report an unexpected recipient. Include device practices for staff who use phones or shared workstations.

Prepare questions for incident handling and recovery:

• Who receives a report of a lost phone or misdirected file?
• Who can disable access and preserve relevant records?
• How does the clinic contact the vendor?
• What notification responsibilities appear in the applicable agreements?
• Who authorizes restoration and checks access afterward?

Keep organizational assessment separate from the app’s feature list. A permission control does not identify the clinic employee responsible for approving access.

Applicable duties include risk analysis and management, workforce security training, access management, incident response and documentation, backup and recovery planning, and periodic evaluation; business associate agreements must address applicable security obligations and incident reporting.

Use a readiness checklist before launch—and after changes

Use the checklist to collect evidence and expose open decisions—not to produce an automatic approval.

Question	Evidence	Owner	Unresolved issue
Is the data map complete?	Workflow diagram and service inventory	Workflow lead	Unmapped transfers or copies
Have applicable obligations been established?	Documented applicability assessment	Privacy or compliance lead	Unconfirmed party roles
Are necessary agreements executed?	Executed agreements and acceptance records	Contract owner	Missing signatures or unclear applicability
Does service scope match the workflow?	Plan details, covered-service terms, exclusions	IT or procurement lead	Optional features not addressed
Is access configured and tested?	Role settings and test results	App administrator	Excess access or unclear revocation
Is mobile handling understood?	Device, notification, and download tests	IT lead	Local copies or shared-device questions
Are operating procedures ready?	Named owners, training materials, incident contacts	Practice manager	Missing procedures or responsibilities

Before introducing real patient information, demonstrate the proposed workflow with synthetic data. Test permissions, notifications, exports, and account removal. Check what a receptionist, temporary staff member, and administrator can each do.

Treat missing evidence as unresolved rather than interpreting silence as approval. Consult vendor BAA availability and service scope for sourced, dated vendor information, then compare it with the exact plan and services under consideration.

Revisit the assessment when plans, features, integrations, data flows, or vendor terms change. Follow what to do when a vendor changes its BAA terms when contractual coverage changes.

Published by Chanty, Inc.; ownership and commercial interests do not determine category placement.

Frequently asked questions about HIPAA app requirements

Can an app be HIPAA compliant?

Evaluate whether it can support HIPAA-compliant use for a specific workflow rather than treating compliance as an unconditional product property. Review the information involved, agreements, covered services, configuration, and clinic procedures.

What features should I look for in a healthcare app?

Look for documented access controls, authentication options, session management, account removal, encryption, file handling, audit information, retention options, and recovery arrangements. Ask how each works and who configures it. This is a practical evaluation list, not a declaration that every feature is universally mandatory.

Does every medical app need to meet HIPAA requirements?

Not automatically. Assess the intended use, the information involved, and the roles of the clinic, developer, and other parties. Do not decide applicability from a “health” or “medical” label alone.

Is encryption enough to make an app HIPAA compliant?

Do not approve a workflow on encryption alone. Also assess access, connected services, agreement scope, configuration, and operational responsibilities. Encryption documentation should describe what it covers, rather than serving as a substitute for that review.

Is a signed BAA enough to approve an app for PHI?

Treat the agreement as part of the evidence, not the entire approval. Confirm that it applies to the actual plan, services, and workflow, then review configuration and clinic responsibilities.

How do HIPAA requirements apply to mobile apps?

Start with the same applicability and workflow assessment, then examine device-specific paths: notifications, camera uploads, local storage, downloads, backups, shared devices, and lost-device access. Do not replace those questions with a claim of separate mobile HIPAA certification.