Is Substance Monitoring Case Management Software HIPAA Compliant?

Substance monitoring case management software is not automatically HIPAA compliant just because it is designed for health or recovery services. Whether HIPAA applies depends on who uses the software, what information it handles, and whether the vendor works on behalf of a covered entity or business associate.

Before storing protected health information (PHI), assess the vendor’s safeguards, contract terms, and handling of records protected by 42 CFR Part 2. The software can support compliance, but your organization remains responsible for its own legal obligations and how the system is configured and used.

When does HIPAA apply to substance monitoring case management software?

HIPAA applies to covered entities—such as health plans, health care clearinghouses, and certain health care providers—and to business associates that handle PHI on their behalf. If your organization is neither a covered entity nor a business associate, HIPAA may not apply to it, although other privacy laws or contractual requirements may still apply. See HHS guidance on covered entities and business associates.

Information in a substance monitoring platform may be PHI when it identifies a person and relates to that person’s health or care, and is handled by a HIPAA-regulated entity. Examples can include treatment participation, drug test results, case notes, referrals, appointment information, and care plans. The type of software alone does not determine whether HIPAA applies; the organization’s status and the information flow matter.

Consider who enters the information, who can view it, where it is hosted, whether vendor staff can access it for support, and whether the service is provided on behalf of a covered entity. A consumer-facing service used independently by an individual may have a different HIPAA status than the same service contracted by a health care provider.

What makes a software vendor a HIPAA business associate?

A vendor is generally a business associate when it creates, receives, maintains, or transmits PHI on behalf of a covered entity or another business associate to perform a service. A vendor that hosts PHI, stores it in a cloud environment, or accesses it while troubleshooting may qualify. HHS explains that providing software alone does not make a vendor a business associate if it has no access to the PHI; the service relationship and access determine the answer.

When the vendor is a business associate, the covered entity generally must have a written HIPAA business associate agreement (BAA) in place before allowing the vendor to handle PHI. Cloud service providers that store or process ePHI on behalf of a regulated entity can also be business associates, even if the information is encrypted and the provider does not hold the key, according to HHS cloud-computing guidance.

Ask whether support staff, hosting providers, analytics services, and other subcontractors could access PHI. Business associates must have appropriate written arrangements with subcontractors that handle ePHI on their behalf. A vendor’s marketing statement that its product is “HIPAA compliant” does not establish that your organization has met its own responsibilities.

What safeguards should the software provide for protected health information?

The HIPAA Security Rule requires covered entities and business associates to protect the confidentiality, integrity, and availability of electronic PHI. It requires a risk analysis and reasonable, appropriate security measures; it does not prescribe one universal software configuration for every organization. The HHS Security Rule summary describes the safeguards and the risk-based flexibility allowed by the rule.

When evaluating protected health information safeguards, ask whether the platform supports your security policies and the risks identified in your assessment. Relevant capabilities may include:

• Access management: unique user accounts, configurable permissions, and role-based access controls that limit staff to the information needed for their work.
• Authentication: secure sign-in features, with multifactor authentication considered where appropriate for your risk profile.
• Audit logging: records of access and key actions, with controls that help you review activity and investigate suspected misuse.
• Data protection: safeguards for information stored in the system and transmitted over networks, plus processes to protect data integrity.
• Availability and recovery: backup, restoration, and incident-response capabilities appropriate to your operations.
• Lifecycle controls: processes for granting and removing access, exporting records, and returning or securely disposing of information when appropriate.

Encryption is an important control to assess, but HHS describes encryption under the Security Rule as an addressable implementation specification. That means an organization must determine whether it is reasonable and appropriate for its circumstances and document its decision; if it is not, an appropriate alternative may be needed. See HHS guidance on encryption.

For audit log retention, distinguish the need to record and regularly review system activity from a specific retention duration. HIPAA requires audit controls and review of system activity, but the Security Rule does not set a single retention period for audit logs. Set a period that supports investigations and aligns with your policies and applicable state, program, or contractual requirements. The six-year requirement for certain Security Rule documentation is not a blanket six-year retention rule for every audit log. See HHS risk analysis guidance and its Security Rule documentation guidance.

How should substance use disorder records be handled under 42 CFR Part 2?

HIPAA is not the only law that may apply. 42 CFR Part 2 protects certain substance use disorder records created by federally assisted programs that provide SUD diagnosis, treatment, or referral for treatment. Some Part 2 requirements also apply to organizations that receive those records. Determine whether your program or the records you receive fall within Part 2 rather than assuming all SUD-related information has the same legal status. See HHS’s overview of Part 2 and the current Part 2 regulation.

Part 2 restricts the use and disclosure of covered records. Its updated rule permits a patient to give a single written consent for future uses and disclosures for treatment, payment, and health care operations, subject to the rule’s requirements. A valid 42 CFR Part 2 consent must identify the patient, the information, the authorized discloser, and the recipient or permitted recipient class, among other elements. A broad TPO consent does not replace the separate consent required for SUD counseling notes. See 42 CFR § 2.31 and the HHS Part 2 final rule fact sheet.

The revised Part 2 rule’s compliance date was February 16, 2026. Part 2 also maintains special protections against using or disclosing records in proceedings against a patient without the patient’s consent or a qualifying court order and subpoena. A HIPAA BAA does not, by itself, provide Part 2 consent or authorize every disclosure or redisclosure.

If a software vendor provides services to a Part 2 program, assess the specific legal basis for sharing records with it. Depending on the relationship, a vendor may qualify as a Qualified Service Organization and require a written agreement with Part 2 terms. The Part 2 definitions and applicability provisions describe these requirements in 42 CFR § 2.11 and 42 CFR § 2.12.

Part 2 also requires applicable programs and lawful holders to have formal policies and procedures to reasonably protect patient-identifying information. Its breach provisions apply HIPAA breach-notification requirements to Part 2 programs. See 42 CFR § 2.16.

What should organizations verify in a business associate agreement?

Review the BAA alongside the software service contract. Under HHS guidance, a written agreement should define permitted and required uses and disclosures, require appropriate safeguards, and set out the vendor’s obligations if information is used or disclosed improperly. The agreement should also address subcontractors and relevant support for your privacy obligations. See HHS sample BAA provisions.

Before signing, verify that the agreement clearly covers:

• What PHI the vendor may use or disclose, and for which services.
• Safeguards for PHI, including applicable Security Rule requirements for ePHI.
• How and when the vendor reports security incidents and breaches, and what details it provides to support your response.
• Subcontractors that may handle PHI and the contractual protections they must follow.
• Assistance with applicable individual rights, such as access to or amendment of records.
• Return or destruction of PHI at the end of the service, when feasible, and how protections continue if information must be retained.
• Your ability to terminate the agreement for a material breach, as applicable.

Specify notification timelines that give your organization enough time to assess an incident and meet applicable breach notification requirements. HIPAA’s breach rule sets obligations for business associates to notify covered entities, while Part 2 applies HIPAA breach-notification requirements to Part 2 programs. If the software handles Part 2 records, confirm that the BAA and any applicable Part 2 agreement or consent pathway address those records specifically.

How can organizations assess software security and compliance limitations?

Start with a documented risk analysis that includes the software, its integrations, mobile or remote access, vendor support, data storage, and subcontractors. Ask the vendor for documentation relevant to your assessment, such as its security-control descriptions, incident-response process, backup and recovery practices, audit capabilities, and independent assessment reports. HHS explains that the HIPAA Rules do not expressly require a cloud provider to give customers audit access or security documentation, although customers may request additional assurances through contracts or other documentation. See HHS guidance on cloud provider documentation and audits.

Test the actual product and configuration rather than relying only on marketing claims. Check whether your team can restrict access by role, remove departing users promptly, review logs, export records, manage consent status, and follow your incident procedures. Confirm how vendor support access works and which third parties may receive or maintain data.

Security certifications or audit reports can inform your review, but they do not replace the required agreement or your organization’s own compliance work. HHS states that private certifications do not absolve covered entities of their Security Rule obligations in its guidance on HIPAA security certification. Also check whether state law, licensing rules, or contracts impose stricter privacy, security, or record-retention requirements.

In short, substance monitoring case management software can support HIPAA compliance when its safeguards, configuration, contracts, and workflows fit your organization’s obligations. Confirm the vendor’s business associate status, review the BAA, assess Part 2 protections where applicable, and document your own risk analysis before storing sensitive records.

FAQs

Is substance monitoring case management software automatically HIPAA compliant?

No. HIPAA compliance depends on the organization using the software, the vendor’s role, how PHI is handled, and whether required agreements and safeguards are in place. A product label or vendor statement alone does not establish compliance.

Does a software vendor need to sign a business associate agreement?

If the vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity or business associate, a written BAA is generally required. A vendor that only sells software and has no access to PHI may not be a business associate. Assess the actual service and access model.

Does HIPAA compliance also satisfy 42 CFR Part 2?

No. HIPAA and Part 2 have overlapping but distinct requirements. Part 2 may require specific consent or another permitted legal basis for disclosure and includes restrictions that a HIPAA BAA alone does not satisfy. Assess both frameworks when the records are covered by Part 2.

What should organizations check before storing substance use disorder records in the software?

Confirm whether the records are protected by Part 2, establish the appropriate consent or other permitted basis for sharing them, and determine whether a BAA and any applicable Part 2 agreement are in place. Review role-based access controls, audit logs, vendor and subcontractor access, incident reporting, backups, retention, and secure export or disposal processes before use.