HIPAA Compliance Guide for Connected Insulin Pump Manufacturers

When HIPAA Applies to Connected Insulin Pump Manufacturers

Making or selling a connected insulin pump does not, by itself, make a manufacturer subject to HIPAA. HIPAA applies to covered entities—health plans, health care clearinghouses, and certain health care providers—and to business associates performing specific functions or services for covered entities that involve protected health information (PHI). A manufacturer’s role and the way it handles information matter more than the fact that its product is connected. See HHS guidance on covered entities and business associates.

Data may be PHI when it identifies an individual and is held or transmitted by a covered entity or business associate. Electronic protected health information (ePHI) is PHI in electronic form. Information collected directly by a manufacturer through a consumer-facing app is not automatically HIPAA-regulated just because it relates to a person’s health; assess whether the manufacturer is acting for a covered entity and whether the data is handled on that entity’s behalf.

Manufacturers should map what information their pumps, apps, cloud platforms, and support systems collect, where it flows, who can access it, and for whom the manufacturer processes it. That data-flow analysis helps determine whether HIPAA applies to a particular service or relationship.

When Manufacturers Become Business Associates

A connected insulin pump manufacturer may qualify as a business associate when it performs a function or service for a covered entity that involves using or disclosing PHI. For example, a manufacturer could be acting as a business associate if a health care provider engages it to host or analyze patient pump data, operate a remote-monitoring service, or provide technical support that uses PHI on the provider’s behalf.

The manufacturer is not necessarily a business associate whenever it receives patient information. HHS explains that a medical device company may, in certain circumstances, provide health care by supporting a provider or patient with respect to a particular patient’s device. Other permitted disclosures, such as certain disclosures to a device company subject to FDA jurisdiction, may also fall outside the business-associate relationship. The specific purpose and context of access determine the analysis. See HHS guidance on disclosures to medical device company representatives.

Assess each relationship separately, including whether the manufacturer is performing work on behalf of a covered entity, whether it is using PHI to carry out that work, and whether a specific HIPAA permission or exception applies. Do not assume that a product’s data connection—or a manufacturer’s access to some patient information—settles the question.

What Business Associate Agreements Must Cover

When a manufacturer is a business associate, the covered entity and manufacturer generally need a written business associate agreement (BAA) or other compliant written arrangement. The agreement must describe permitted and required uses and disclosures of PHI, restrict other uses and disclosures, and require appropriate safeguards for ePHI. See 45 CFR § 164.504(e) and HHS guidance on business associate agreements.

A BAA should fit the actual service. It should address, as applicable, security safeguards, incident and breach reporting, subcontractors that handle PHI, cooperation with individual rights requests, access to relevant records for compliance review, and return or destruction of PHI when the arrangement ends, if feasible. A business associate must also ensure that relevant subcontractors agree to applicable privacy and security restrictions.

A BAA is not a general permission to use patient data for any business purpose. The agreement should limit access and use to the authorized service and should not authorize a use or disclosure that would violate the Privacy Rule if made by the covered entity.

When Manufacturer Representatives May Access Patient Information

A representative’s access should have a defined, permitted purpose and be limited to the information needed for that purpose. HHS recognizes that a provider may, in certain circumstances, disclose PHI to a device company representative to support the appropriate use or adjustment of a device for a particular patient. A representative’s presence or access is not, however, blanket permission to view records unrelated to that support.

If the manufacturer is performing a function or service on behalf of a covered entity that involves PHI, a BAA may be required. In other situations, a covered entity may be able to make a permitted disclosure without a BAA—for example, under a HIPAA provision that applies to the particular disclosure. The covered entity and manufacturer should identify the applicable basis before granting access; where required, the covered entity must also apply the minimum-necessary standard.

Practical controls include role-based access, individual user accounts, time-limited credentials, supervision when appropriate, activity logging, and documented procedures for requesting, approving, and ending access. These measures help ensure that access matches the representative’s specific task.

HIPAA Safeguards for Electronic Protected Health Information

When a manufacturer acts as a business associate and handles ePHI, the HIPAA Security Rule requires administrative, physical, and technical safeguards to protect its confidentiality, integrity, and availability. The required risk analysis is an important starting point: identify the ePHI the organization handles, the systems that process it, and the risks and vulnerabilities that could affect it. See 45 CFR § 164.308.

Administrative safeguards include security policies, workforce access management and training, security-incident procedures, contingency planning, and periodic evaluation. Physical safeguards address access to facilities and workstations and the handling of devices and media containing ePHI. Technical safeguards include access controls, audit controls, authentication, integrity protections, and transmission security. The applicable requirements are set out in 45 CFR § 164.310 and 45 CFR § 164.312.

An addressable specification is not simply optional. An organization must assess whether each addressable specification is reasonable and appropriate in its environment; if it is not, the organization must document why and implement an equivalent alternative measure when reasonable and appropriate. Encryption is one such addressable specification under the technical safeguards provisions. See 45 CFR § 164.306.

These HIPAA safeguards apply to ePHI handled by a covered entity or business associate; they are not a complete medical-device safety or cybersecurity program. Manufacturers should also evaluate device-specific security and patient-safety risks, including those that may not involve PHI.

Managing Cybersecurity Risks Across the Pump Lifecycle

Connected insulin pump security requires attention throughout design, testing, deployment, maintenance, and retirement. Manufacturers should assess how vulnerabilities could affect both data and the pump’s essential functions, then define controls and processes for monitoring, remediation, and communicating security issues. FDA’s current medical device cybersecurity guidance provides recommendations for device design, labeling, and cybersecurity information in premarket submissions; it is FDA guidance, not a HIPAA rule.

A cybersecurity risk assessment should consider the whole system, not just the pump itself. Relevant components may include wireless links, glucose sensors, phone apps, cloud services, clinician portals, update mechanisms, and third-party software. Evaluate the potential for unauthorized access, altered or unavailable data, disrupted connections, compromised updates, and security weaknesses in supporting services.

For an insulin pump, the assessment should connect each plausible attack path to a patient-safety outcome. Consider whether a compromise could interfere with delivery settings, cause too much or too little insulin to be delivered, suppress or delay alerts, or make glucose and dosing information unreliable. FDA has warned that certain vulnerabilities in a specific insulin pump system could, if exploited, result in the pump delivering too much or too little insulin. That warning illustrates why risk depends on the affected device and its design; it does not establish that every pump has the same vulnerability. See the FDA safety communication on the MiniMed 600 Series system.

Document how the manufacturer evaluates vulnerabilities, prioritizes mitigations, tests updates, monitors postmarket information, and communicates with users and health care organizations. Coordinate cybersecurity response with safety, quality, regulatory, privacy, and clinical teams so that a fix does not create new hazards or compromise safe device operation.

Connected Insulin Pump Security Practices and Limitations

Use security controls proportionate to the risks identified for each system and its users. Depending on the design, practices may include strong authentication, least-privilege access, protected communications, secure update processes, logging and monitoring, vulnerability testing, and safeguards against unauthorized changes to dosing-related settings. Validate controls against realistic use conditions, including connectivity failures and recovery scenarios.

Plan for safe operation when a phone, app, cloud service, or network connection is unavailable or compromised. Make user alerts and fallback instructions clear, and ensure that security mitigations do not prevent users or clinicians from recognizing a device problem or responding to it. FDA has also highlighted safety concerns when users may miss alerts from smartphone-compatible diabetes devices because of phone settings or other changes; see the FDA alert about missed safety alerts.

No single safeguard eliminates all cyber risk, and a HIPAA program does not establish that a medical device is secure or safe. HIPAA obligations depend on whether the organization is a covered entity or business associate and whether the information is PHI; FDA device guidance and applicable device requirements address a different regulatory context. Keep those analyses distinct while coordinating them where the same system handles patient data and controls safety-critical functions.

Summary: A connected insulin pump manufacturer is not automatically subject to HIPAA. Determine whether the manufacturer handles PHI on behalf of a covered entity, use a compliant BAA when the relationship requires one, apply the relevant Security Rule safeguards to ePHI, and assess cybersecurity risks across the pump’s lifecycle with patient safety in mind.

FAQs

Does making or selling a connected insulin pump automatically make a manufacturer subject to HIPAA?

No. Manufacturing or selling a connected pump alone does not make a company subject to HIPAA. HIPAA generally applies to covered entities and business associates; a manufacturer’s obligations depend on its role and whether it performs covered work involving PHI on behalf of a covered entity.

When does a connected insulin pump manufacturer qualify as a business associate?

A manufacturer may qualify as a business associate when it performs a function or service for a covered entity that involves using or disclosing PHI—for example, hosting or analyzing patient data for a provider. The specific service and circumstances matter, and certain permitted disclosures or device-support activities may not create a business-associate relationship.

Is a business associate agreement required when manufacturer staff access patient information?

Not in every situation. A BAA is generally required when the manufacturer performs a covered function or service on behalf of a covered entity that involves PHI. Some other disclosures may be permitted without a BAA under a specific HIPAA provision. The parties should determine the purpose and legal basis for access before it is granted.

What cybersecurity risks should manufacturers assess if an insulin pump is compromised?

Assess whether an attack could change or disrupt pump operation, interfere with insulin delivery, suppress alerts, falsify or expose patient data, disrupt connected sensors or apps, or compromise updates and supporting services. Evaluate both the likelihood of exploitation and the potential severity of patient harm, then test and document appropriate mitigations.