Is Survivorship Care Plan Software HIPAA Compliant?

Survivorship care plan software is not automatically HIPAA compliant simply because it is designed for healthcare or advertises security features. Whether a particular use requires a business associate agreement (BAA) depends on who uses the software, whose behalf the vendor acts on, and whether the service creates, receives, maintains, or transmits protected health information (PHI).

Even when a BAA is required, signing one does not by itself make the software or an organization compliant. The organization must assess its data flows, vendor responsibilities, and safeguards as part of its broader HIPAA obligations.

When does survivorship care plan software require a BAA?

A covered healthcare provider generally needs a BAA when a software vendor performs a service on the provider’s behalf that involves creating, receiving, maintaining, or transmitting PHI. A vendor that hosts, stores, or processes identifiable survivorship care plans for a healthcare organization will generally be a business associate, even if its staff do not routinely view the records.

The same principle applies when a business associate hires another service provider—such as a cloud service provider—to handle PHI. That subcontractor may also be a business associate and must agree to applicable safeguards and restrictions. HHS describes these obligations in its Business Associates guidance.

Look at the actual relationship and data flow, not just the product label. A vendor’s claim that its service is “HIPAA ready” or that it offers a BAA is not proof that your specific configuration, staff practices, and use of the software meet HIPAA requirements.

What protected health information can a survivorship care plan contain?

A survivorship care plan may contain diagnoses, treatment history, medication information, test results, follow-up recommendations, and other health details. When information connects these details to an identifiable person, it may be PHI when held or transmitted by a covered entity or business associate.

Identifiers can appear in more places than a patient-name field. Dates, contact details, record numbers, free-text notes, attached documents, or other information that identifies—or could reasonably identify—a patient may matter. HHS explains that the HIPAA Privacy Rule’s de-identification standard applies to both structured fields and recognizable identifiers in free text in its guidance on HIPAA de-identification.

Removing a name alone does not establish de-identification. HIPAA recognizes two methods: Safe Harbor, which requires removing specified identifiers and having no actual knowledge that remaining information could identify the person, or Expert Determination, which requires a qualified expert to document that identification risk is very small under the circumstances.

How does cloud hosting affect HIPAA obligations?

Cloud hosting does not remove HIPAA responsibilities. If a cloud service provider creates, receives, maintains, or transmits electronic protected health information (ePHI) on behalf of a covered entity or business associate, it generally has business associate obligations and the parties need an appropriate BAA. HHS states that this applies even when the cloud provider stores only encrypted ePHI and lacks the decryption key. See HHS guidance on HIPAA and cloud computing.

Encryption is an important safeguard, but encryption alone does not address every HIPAA requirement. It does not, for example, replace risk analysis, access and administrative controls, contingency planning, or protections for data integrity and availability. Organizations must assess ePHI risks and select reasonable and appropriate safeguards for their circumstances. HHS explains these responsibilities in its Security Rule risk analysis guidance.

Map where information travels and persists: the application, hosting environment, backups, support tools, integrations, analytics, and any subcontractors. Confirm which party is responsible for each safeguard rather than assuming that the cloud vendor or software company handles every obligation.

What safeguards and terms should a BAA include?

A BAA should clearly define what the vendor may and must do with PHI, limit other uses and disclosures, and require appropriate safeguards for the information. For ePHI, it should address the vendor’s applicable Security Rule duties and explain how responsibilities are divided between the organization and the vendor.

Review the agreement for provisions covering:

• Permitted uses and disclosures of PHI, including restrictions on uses outside the services being provided.
• Safeguards to prevent unauthorized use or disclosure, and reporting of impermissible uses, disclosures, or security incidents.
• Breach notification obligations, including how and when the vendor will notify the organization so it can assess and meet its own duties.
• Subcontractor safeguards requiring subcontractors that handle PHI to accept applicable restrictions and protections.
• Support for individual rights and the covered entity’s duties concerning access, amendments, and accounting of disclosures, as applicable to the services.
• Return or destruction of PHI when the agreement ends, where feasible, and continued protection if return or destruction is infeasible.
• Access to relevant records for the government’s compliance review and the organization’s right to address or terminate the arrangement for a material violation.

These topics reflect the required contract elements described in HHS’s sample business associate contract provisions. The agreement should also be specific enough to coordinate incident reporting, secure data export, backup handling, and termination procedures. A BAA does not replace the organization’s risk analysis or other HIPAA responsibilities.

When may a software vendor not be a business associate?

A vendor may not be a business associate if it does not create, receive, maintain, or transmit PHI on behalf of a covered entity or business associate. For example, a person may independently choose a consumer service for personal use without a healthcare provider engaging the vendor to perform a function on the provider’s behalf. The details of the relationship and data flow determine the result; the product’s marketing category alone does not.

HIPAA also recognizes a limited conduit exception for entities that transmit PHI, with only transient storage incidental to transmission. A service that persistently stores or processes ePHI generally does not fit that exception merely because it cannot view encrypted records. HHS explains the distinction in its cloud computing guidance.

If the information is properly de-identified under a HIPAA method, it is no longer PHI under the Privacy Rule. But simply removing names or replacing them with codes may not be enough; assess the relevant identifiers and the remaining risk of identification before treating data as de-identified.

How can organizations assess software compliance and data flows?

Start by documenting what information enters the software, who enters it, where it is stored, who can access it, and where it is sent. Include copies, exports, backups, support access, integrations, analytics, and subcontractors. This data-flow map helps determine whether the vendor is acting as a business associate and identifies where ePHI risks may arise.

Then review the proposed BAA alongside the vendor’s service description and security documentation. Ask which safeguards the vendor and its subcontractors provide, how incidents are reported, how data is backed up and restored, how access is managed, and how PHI is returned or destroyed when the relationship ends. Check that the agreement covers the services and configuration your organization will actually use.

Finally, incorporate the software into your organization’s risk analysis and risk management process. HHS describes risk analysis as an assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI; it is an ongoing organizational responsibility, not a vendor certification. See HHS guidance on risk analysis.

In short, survivorship care plan software may require a BAA when it handles identifiable health information on behalf of a covered organization. Assess the full data flow, confirm the vendor and subcontractor terms, and evaluate safeguards as part of your own HIPAA program; neither a BAA nor encryption alone establishes compliance.

FAQs

Does survivorship care plan software need a BAA?

Usually, when a covered entity or business associate engages the vendor to create, receive, maintain, or transmit PHI on its behalf. A vendor that stores or processes ePHI for an organization will generally need a BAA, including when it cannot decrypt encrypted data. The specific relationship and services matter.

Does encryption alone make cloud-hosted software HIPAA compliant?

No. Encryption helps protect ePHI, but it does not replace a BAA when one is required, risk analysis, other appropriate safeguards, or the organization’s broader HIPAA responsibilities. Cloud hosting arrangements should also address applicable subcontractors, incident reporting, backup and recovery, and data access.

Is removing a patient’s name enough to de-identify a care plan?

No. Other identifiers may remain in structured fields, dates, free text, or attached documents. HIPAA de-identification requires meeting either the Safe Harbor method or the Expert Determination method; removing only a name is not, by itself, sufficient.

What should a BAA cover when software stores survivorship care plans?

It should define permitted and required PHI uses and disclosures; require appropriate safeguards; address incident and breach reporting; flow applicable restrictions to subcontractors; support relevant individual rights and compliance duties; and provide for return or destruction of PHI at termination when feasible. It should also explain how the parties coordinate responsibilities for the actual service.