HIPAA Compliance Checklist for Medication Adherence Device Makers

A connected medication adherence device may collect medication schedules, missed-dose alerts, device use, and other sensitive information. Whether HIPAA applies depends on your business relationships and how you handle the data—not simply on the fact that your product is health-related.

Use this checklist to assess your role, identify protected health information, set clear contractual limits, and safeguard data throughout its lifecycle. HIPAA obligations are fact-specific, so confirm your conclusions with qualified privacy counsel.

Determine Whether HIPAA Applies to Your Device Business

Start by mapping who sells, supplies, operates, and supports the device and its connected services. A device maker is not automatically a HIPAA covered entity just because its product collects health-related data. Covered entities generally include health plans, health care clearinghouses, and health care providers that conduct certain standard electronic transactions.

Next, determine whether your company is a business associate. You may be one if, on behalf of a covered entity, you create, receive, maintain, or transmit protected health information (PHI), or provide a service that involves access to PHI. For example, a manufacturer that hosts adherence data for a provider’s patient-monitoring service may have a different HIPAA role from a company selling a device directly to consumers. A vendor’s role depends on its actual functions and relationships, not only on contract labels.

• List each customer, health care provider, health plan, cloud provider, app operator, and support vendor.
• Document whose purposes the service supports and who determines how patient data is used.
• Identify where data is collected, transmitted, stored, viewed, and analyzed.
• Assess each service separately: your business may have different roles across different products or customers.

If your product is offered directly to individuals and you are not acting for a covered entity or business associate, HIPAA may not govern that data flow. That does not mean the information is unregulated; other privacy, security, consumer-protection, or state laws may apply.

Identify Protected Health Information in Device Data

Inventory all data the device and its related services handle. Potentially sensitive data can include a patient’s name or account identifier, medication and dosing schedule, dose confirmations, missed-dose alerts, timestamps, device identifiers linked to a patient, caregiver messages, and adherence reports.

Data is PHI when it is individually identifiable health information held or transmitted by a covered entity or business associate in the relevant HIPAA relationship. Consider the whole data flow: a device identifier or event log may identify a person when combined with an account record, provider roster, or other information. Do not assume that removing a name alone makes a dataset de-identified.

• Map data fields, identifiers, and metadata from collection through deletion.
• Document which information a provider uses to make decisions about a patient.
• Separate HIPAA-regulated data from other data where practical, and record the basis for that classification.
• Review analytics and product-development datasets for identifiers and re-identification risks before using them beyond the original service.

This inventory helps determine what protections, contracts, access limits, and response procedures are appropriate for each dataset.

Establish Business Associate Agreements

If your company is a business associate, establish a written business associate agreement (BAA) with the covered entity before handling PHI on its behalf. A BAA should describe permitted and required uses and disclosures, require appropriate safeguards, address incident and breach reporting, and explain how PHI will be returned or destroyed when the relationship ends, where feasible.

Also account for each subcontractor. If a cloud provider, analytics vendor, customer-support provider, or other subcontractor handles PHI for you, make sure the required written agreement imposes applicable privacy and security restrictions on that subcontractor. A BAA cannot make an otherwise impermissible use permissible; the actual service and data handling must match the agreement.

• Specify which device, app, hosting, monitoring, and support activities are covered.
• Define how the parties will coordinate access requests, amendments, and disclosure-accounting requests.
• Set incident-notification responsibilities and a process for investigating suspected unauthorized access.
• Keep an inventory of BAAs and subcontractor agreements, with owners and review dates.

Define Permitted Uses and Disclosures

Use the BAA and related service documents to state why your business may access PHI—for example, to operate the adherence service, provide contracted technical support, or deliver agreed reporting to the provider. Do not treat access to data as permission to use it for any purpose that could benefit your company.

Distinguish permitted disclosures for treatment, payment, and health care operations from other uses. HIPAA generally permits covered entities to use or disclose PHI for treatment, payment, and health care operations under applicable conditions. The exact rules depend on the parties, purpose, and role. A business associate should follow its BAA and may not use or disclose PHI beyond what the agreement or law permits.

FDA-regulated product safety disclosures require particular care. HIPAA permits certain disclosures by covered entities to entities subject to FDA regulation for purposes such as adverse-event reporting, product tracking, recalls, and post-market surveillance. That permission is purpose-specific; it is not a general authorization for marketing or other commercial use. If you are acting as a business associate, verify that the disclosure is authorized by your BAA or otherwise required or permitted by law before making it.

• Define allowed purposes for each data field or category, not just for the service as a whole.
• Separate service delivery, safety reporting, analytics, research, and marketing workflows.
• Require appropriate authorization or other legal basis before using PHI for an additional purpose.
• Document how de-identified data is created and which uses of it are allowed.

Apply Minimum Necessary Access Controls

Apply the minimum necessary standard where it covers the specific use, request, or disclosure. In general, the standard calls for reasonable limits on PHI to what is needed for the intended purpose. It does not apply to every HIPAA activity: for example, disclosures to or requests by a health care provider for treatment, disclosures to the individual, and disclosures made under an individual’s authorization are among the exceptions. Do not apply the standard as a blanket reason to block information needed for treatment.

For day-to-day operations, give employees and contractors access based on job responsibilities. A support specialist may need a limited view to troubleshoot a device, while an engineer may be able to diagnose a software issue using test data rather than patient-specific records.

• Use role-based permissions and promptly remove access when roles change or employment ends.
• Limit production-data access for development, testing, and analytics.
• Use authentication controls, secure transmission, and safeguards appropriate to documented risks.
• Review access periodically and investigate unusual or unauthorized activity.

Secure Data Retention and Disposal

Set a retention schedule for device records, app data, support tickets, backups, and logs. Keep PHI only as long as needed for authorized services, contractual duties, and applicable legal or regulatory requirements. HIPAA does not create one universal retention period for every record or dataset, so assess other applicable requirements as well.

When a BAA or service relationship ends, follow its return-or-destroy provisions where feasible. If the information cannot feasibly be returned or destroyed, the agreement should address continued safeguards and limit further uses and disclosures to the purposes that make retention necessary. Use secure deletion, media sanitization, or other disposal methods appropriate to the storage medium and risk.

• Include backups, test environments, exported reports, and support records in retention decisions.
• Document deletion responsibilities and exceptions for data that must be retained.
• Ensure access to retained data remains restricted and logged.
• Verify that disposal processes cover devices, removable media, and cloud storage.

Manage Third-Party Sharing and Audit Practices

Maintain a current list of vendors that receive, store, transmit, or can access PHI. Confirm that each party’s role, permissions, and contractual protections match the actual data flow. Reassess vendors when you add a device feature, change a hosting arrangement, enable new analytics, or begin a new type of data sharing.

The HIPAA Security Rule requires covered entities and business associates to protect electronic PHI with appropriate administrative, physical, and technical safeguards. Its requirements include risk analysis and management, access controls, and mechanisms to record and examine activity in systems that use or contain electronic PHI. Choose safeguards based on the risks to your environment; do not treat a security checklist or certification as a substitute for understanding those risks.

• Review access and system logs for suspicious activity and retain evidence needed for investigations.
• Test incident-response procedures, including how you notify covered-entity customers.
• Reassess security risks when the product, data flow, vendor, or threat environment changes.
• Keep written policies, risk assessments, vendor reviews, training records, and remediation decisions.

In short, an effective HIPAA compliance checklist starts with correctly identifying your role, then follows PHI through every device and service workflow. Clear BAAs, purpose-limited data use, risk-based access controls, secure retention and disposal, and regular vendor and audit reviews help support that approach.

FAQs.

When is a medication adherence device maker a HIPAA business associate?

A device maker is generally a business associate when it performs a service for a HIPAA covered entity that involves creating, receiving, maintaining, or transmitting PHI, or otherwise involves access to PHI. A manufacturer that hosts patient-specific adherence data for a provider may qualify; selling a device directly to a consumer does not by itself establish a business associate relationship. Assess the actual service, data flow, and relationship with the covered entity.

When does a device maker need a business associate agreement?

A device maker generally needs a BAA when it is acting as a business associate and a covered entity discloses PHI to it, or it handles PHI on the covered entity’s behalf. The agreement should be in place before the covered entity permits that handling and should address permitted uses, safeguards, incident reporting, subcontractors, individual-rights support, and return or destruction of PHI.

What HIPAA rules apply to patient data from connected medication devices?

If the data is PHI handled by a covered entity or business associate, the HIPAA Privacy, Security, and Breach Notification Rules may apply according to the organization’s role and activity. The Privacy Rule governs permitted uses and disclosures and certain individual rights; the Security Rule covers electronic PHI safeguards; and the Breach Notification Rule addresses notification duties following certain breaches. A device’s connection to the internet alone does not determine whether HIPAA applies.

Can a patient request patient-specific device information?

Potentially. An individual generally has a HIPAA right of access to PHI about them in a covered entity’s designated record set, including qualifying information maintained by a business associate on the covered entity’s behalf. The covered entity is generally responsible for responding, and its BAA should require the business associate to make relevant information available. Whether particular device information is included depends on whether it is PHI in a designated record set; HIPAA does not generally require creation of new information that does not already exist.