A Security Risk Assessment Guide for Chemotherapy Dose Calculation Software Vendors

Kevin Henry

Risk Management

Published Updated

9 minutes read
Share this article
A Security Risk Assessment Guide for Chemotherapy Dose Calculation Software Vendors

What does a security risk assessment cover for chemotherapy dose calculation software?

A security risk assessment examines how threats and vulnerabilities could affect the confidentiality, integrity, and availability of electronic protected health information (ePHI). For chemotherapy dose calculation software, assess those security outcomes alongside risks to calculation integrity and clinical availability: unauthorized changes, incorrect or incomplete inputs, unavailable results, and delays in reviewing or acting on orders.

Map the full data flow, including user devices, application services, databases, backups, support tools, cloud environments, and connections to electronic health records or pharmacy systems. Include ePHI the vendor creates, receives, maintains, or transmits, and identify service providers or subcontractors that could access it. HHS explains that the HIPAA Security Rule requires covered entities and business associates to assess risks to ePHI, but a vendor’s HIPAA status depends on its role and access—not simply on selling software. HHS guidance on risk analysis and HHS guidance on software vendors and business associates provide details.

Document risks, likelihood and potential impact, existing safeguards, residual risk, owners, and corrective actions. Revisit the assessment when material changes occur, such as a new interface, hosting arrangement, software release, vulnerability, or security incident. HIPAA does not set one universal reassessment interval; HHS describes risk analysis as an ongoing process that should be updated as needed. HHS risk analysis guidance

How can vendors identify and prioritize cybersecurity threats?

Start with a current inventory of software, infrastructure, data flows, external dependencies, and trust boundaries. Use threat modeling to consider how an attacker or operational failure could affect accounts, calculation services, databases, interfaces, software updates, and support access. Include accidental changes and misuse—not only external attacks.

Prioritize scenarios by likelihood and impact. For chemotherapy workflows, consider whether an event could expose patient information, alter a dose-related value, obscure a warning, or make the software unavailable when clinicians need it. Rank findings using a documented method, then assign owners, target dates, and verification steps for remediation. HHS identifies likelihood and potential impact as factors in evaluating risk to ePHI. HHS guidance on assessing risk

Maintain a vulnerability management program that receives and assesses vulnerability reports, tracks affected versions and dependencies, tests fixes, and communicates mitigations and support timelines to customers. If the product is a medical device subject to applicable FDA requirements, determine the obligations that apply to its specific regulatory status. FDA guidance addresses cybersecurity risk management for relevant devices, including postmarket monitoring and remediation; its recommendations and statutory requirements apply in their respective scopes. FDA cybersecurity guidance for medical devices

How should vendors protect patient data in storage and transmission?

Apply protected health information safeguards across the data lifecycle. Limit the patient information collected and retained to what the service needs; separate production data from development and test environments; restrict access to backups and logs; and securely dispose of data when retention is no longer authorized or needed.

Use well-managed encryption at rest and in transit for ePHI, with protected keys, controlled key access, and documented rotation and recovery procedures. Protect service-to-service connections as well as user connections, and verify that backups and exported files receive safeguards appropriate to their contents. HIPAA requires technical measures to guard against unauthorized access to ePHI during transmission; encryption is an addressable implementation specification, not a universal one-size-fits-all prescription. If an addressable specification is not reasonable and appropriate in a particular case, the regulated entity must document that determination and implement an equivalent alternative when reasonable and appropriate. HHS summary of the HIPAA Security Rule

Minimize sensitive details in application logs, support tickets, and diagnostic exports. Where vendor personnel may access a customer’s PHI to provide a service, define permitted uses, safeguards, incident reporting, and subcontractor responsibilities in the appropriate business associate arrangements. HHS notes that a software vendor that needs access to PHI to provide its service may be a business associate. HHS software vendor FAQ

Which access controls and system interfaces need review?

Use unique user identities, strong authentication, least-privilege permissions, and timely account deactivation. Apply role-based access control so users and service accounts receive only the permissions needed for their duties. Review privileged access separately, limit vendor support access by time and purpose, and log access to sensitive records and security-relevant actions. HIPAA’s Security Rule addresses access control, authentication, and audit controls for systems containing ePHI. HHS Security Rule overview

Review every clinical system interface security boundary, including APIs, message queues, identity services, EHR connections, pharmacy systems, and remote support channels. Authenticate connected systems, authorize the data and actions each connection can use, validate message structure and values, protect data in transit, and monitor failed or unusual exchanges. Test that duplicate, delayed, out-of-order, or malformed messages do not silently create inconsistent patient or order records.

Agree with each healthcare organization on interface ownership, permitted data, error handling, logging, and escalation contacts. Test changes against customer-approved workflows before deployment, and document how interface failures are detected and reconciled. Keep security controls and configuration instructions understandable for organizations that must deploy and operate the product within their own environments.

Ready to assess your HIPAA security risks?

Join thousands of organizations that use Accountable to identify and fix their security gaps.

Take the Free Risk Assessment

How can dose calculation inputs and alerts support error prevention?

Protect the integrity of both the data and the calculation path. Validate required fields, units, ranges, timestamps, and the relationship between patient information and the applicable calculation method. Flag missing, stale, conflicting, or implausible values for review rather than silently substituting defaults. Make it possible for authorized users to see which inputs and software version produced a result.

Test calculation logic against approved specifications, including boundary cases, rounding behavior, unit conversions, and updates to supported protocols or rules. Verify that a software change does not unintentionally alter previously validated results. FDA’s clinical decision support materials distinguish among software functions and explain that regulatory treatment depends on the function and context; vendors should assess their own product’s intended use and applicable status rather than assume every calculation tool is treated alike. FDA clinical decision support software FAQs

Design alerts to identify the specific issue and provide a clear next step, such as verifying an input or consulting an authorized clinician. Test that alerts appear when expected, are not suppressed by interface failures, and remain distinguishable from informational messages. Preserve an auditable record of relevant inputs, results, alerts, overrides, and changes, with access limited to authorized users.

What evidence should healthcare organizations request from vendors?

Ask for evidence that matches the product, deployment model, and risk—not only a general security statement. Useful materials include a system and data-flow overview; a summary of the risk assessment and remediation process; access-control and encryption descriptions; vulnerability disclosure and patching procedures; security test summaries; incident response contacts; backup and recovery arrangements; and supported-version and end-of-support information.

Request a software bill of materials (SBOM) when relevant, along with a process for identifying affected components and communicating mitigations. FDA’s current cybersecurity guidance describes SBOM-related expectations for manufacturers of cyber devices subject to section 524B; applicability depends on whether the product meets the statutory definition and the circumstances of the submission. Do not represent an SBOM or a vendor document as proof of overall HIPAA compliance. FDA cybersecurity guidance

Confirm whether the vendor or its subcontractors will access, maintain, or transmit PHI, and establish the appropriate written terms before enabling that access. HHS explains that a vendor’s role depends on its functions and access to PHI, and that a business associate contract is required when the relationship meets the applicable definition. HHS software vendor FAQ

Evaluate the evidence against your own environment and risk requirements. A training certificate, audit report, security questionnaire, or product certification—if offered—does not by itself establish that your organization or every deployment is HIPAA compliant.

How should vendors plan and test for downtime?

Define how the software behaves during an outage, cyber incident, interface failure, or loss of connectivity. Document who declares downtime, how customers are notified, which functions may continue safely, and how users return to normal operation. Set recovery priorities and objectives with healthcare organizations, taking account of clinical workflow and the system’s role; do not imply that one fallback process is appropriate for every facility.

Develop and test a downtime contingency testing plan with customer participation. Exercise realistic scenarios such as unavailable authentication, interrupted interfaces, corrupted data, and restored service with queued messages. Confirm that authorized teams can recover data and service, reconcile records and orders, identify duplicate or incomplete transactions, and preserve audit trails. NIST describes contingency planning as including recovery procedures and alternate processing methods, with plans informed by testing and lessons learned. NIST contingency planning resources

Agree with the healthcare organization on clinical procedures for orders during an outage. Direct users to the organization’s approved downtime workflow and authorized clinical personnel; do not prescribe an improvised dose or assume that a local paper or manual process is safe without facility approval. Resume normal software use only through a defined recovery and reconciliation process.

In summary, a useful assessment connects cybersecurity safeguards with calculation integrity, clinical system interfaces, and service availability. Vendors should document risks, test safeguards and recovery procedures, and give healthcare organizations clear evidence and operational guidance.

FAQs

How often should vendors reassess security risks for chemotherapy dose calculation software?

Reassess when changes or events could materially affect risk, such as a major release, new interface, hosting change, newly disclosed vulnerability, or security incident. Establish a periodic review schedule appropriate to the product and its operating environment, but do not treat one interval as a universal HIPAA requirement. HHS says the Security Rule does not specify a single frequency for risk analysis and describes it as an ongoing process. HHS risk analysis guidance

What security evidence should a healthcare organization request from a software vendor?

Request a product and data-flow overview, relevant risk and security test summaries, vulnerability and patch management procedures, access and encryption details, incident response contacts, backup and downtime plans, supported-version information, and an SBOM when applicable. Also clarify whether the vendor or a subcontractor will access PHI and whether a business associate agreement is needed for the arrangement.

How should vendors protect dose calculation data shared through system interfaces?

Authenticate connected systems, authorize each interface’s permitted data and actions, encrypt transmissions, validate message formats and values, and monitor interface activity. Test how the software handles malformed, duplicate, delayed, or interrupted messages, and provide a documented process for detecting and reconciling failed exchanges.

What should happen to chemotherapy ordering during a software outage?

Follow the healthcare organization’s approved downtime procedures and escalation path, including review by its authorized clinical staff. Vendors should make outage status and recovery instructions clear, avoid presenting an unapproved workaround as safe, and support orderly restoration and reconciliation before normal software workflows resume.

Share this article

Ready to assess your HIPAA security risks?

Join thousands of organizations that use Accountable to identify and fix their security gaps.

Take the Free Risk Assessment

Related Articles