Medication Reconciliation Software Vendor Security Risk Assessment Checklist

Medication reconciliation software may handle protected health information (PHI), connect to your electronic health record (EHR), and influence clinical workflows. Assess the vendor’s security controls alongside the way your organization will configure, integrate, and use the product.

Use this checklist to document evidence, identify gaps, assign follow-up actions, and decide whether the vendor’s risk is acceptable for your intended use. HIPAA requirements apply according to the parties’ roles and the circumstances; the checklist’s additional security questions are risk-management practices, not automatic HIPAA mandates.

How should you classify a medication reconciliation software vendor’s risk?

Start by mapping what the software does and what information it handles. Determine whether it creates, receives, maintains, or transmits PHI on your organization’s behalf, and identify the data flows between the software, your EHR, pharmacies, health information exchanges, hosting providers, and other connected services.

A vendor that handles PHI on behalf of a covered entity may be a business associate; a subcontractor that handles PHI for a business associate may also have business associate obligations. A cloud provider can qualify even if it cannot view encrypted data. Confirm the relationship based on actual services and data flows, rather than relying on the vendor’s label. See HHS guidance on business associates and HHS guidance on cloud computing.

Classify the vendor’s risk using factors such as the sensitivity and volume of information, the breadth of access, the number of integrations and subcontractors, the effect of an outage, and the consequences of incorrect or unavailable medication data. Document the rationale and the controls that reduce the risk. HHS describes risk analysis as assessing risks and vulnerabilities to ePHI and their likelihood of occurrence; the analysis can include an inventory of systems and applications, classified by risk. See HHS guidance on Security Rule risk analysis.

• List the PHI and other sensitive data the software can access, store, or transmit.
• Record each integration, data exchange, hosting service, and subcontractor in scope.
• Assess whether the software supports a critical care process and what happens if it is unavailable or produces incomplete data.
• Identify the vendor’s security contact, service owner, and escalation path.
• Record known risks, compensating controls, open issues, and the person responsible for accepting or remediating each risk.

Which HIPAA safeguards and agreements should you verify?

If the vendor is your business associate, put a Business Associate Agreement (BAA) in place before it handles PHI. The BAA should define permitted and required uses and disclosures, require appropriate safeguards for PHI, address reporting, and require applicable subcontractors to accept the required restrictions. It should also address return or destruction of PHI at termination when feasible. Review the actual contract against HHS’s business associate contract provisions and 45 CFR § 164.504(e).

Clarify how your organization and the vendor divide security responsibilities. For example, document who configures user access, protects administrative interfaces, monitors logs, manages encryption keys, restores data, and notifies the other party about incidents. HHS advises cloud customers and providers to clarify their respective Security Rule responsibilities in writing; the required division depends on the service and the parties’ risk management plans. See HHS cloud computing guidance.

Verify the vendor’s process for conducting and updating its risk analysis, managing identified risks, reviewing system activity, responding to security incidents, and maintaining contingency plans. The HIPAA Security Rule requires regulated entities to conduct risk analysis and risk management, and to implement security incident procedures and contingency planning. The organization remains responsible for assessing its own environment and the safeguards it relies on; vendor materials can inform that work but do not replace it. See 45 CFR § 164.308 and HHS’s Security Rule summary.

Ask for relevant policies, assessment summaries, independent audit reports, penetration-test summaries, and remediation evidence. Treat these as due-diligence requests, not as documents HIPAA universally requires a vendor to provide: HHS explains that the HIPAA Rules do not expressly require a cloud service provider to give customers security documentation or audit access. Your organization may seek additional assurances based on its risk analysis and contract. See HHS guidance on cloud-provider documentation and audits.

How can you assess identity and access controls?

Check whether the software limits ePHI access to authorized users and supports unique user identification, appropriate permissions, and audit controls. Evaluate both ordinary user access and vendor or customer administrative access. The Security Rule sets access-control and audit-control standards; the particular safeguards you rely on should reflect your risk analysis. See HHS’s summary of HIPAA technical safeguards.

• Review role-based access control (RBAC) and confirm permissions align with job responsibilities and the minimum access needed for each workflow.
• Ask how accounts are approved, changed, disabled, and periodically reviewed, including vendor support accounts and emergency access.
• Confirm whether multifactor authentication is available or required for remote access, privileged accounts, and access to sensitive administrative functions. Treat this as a risk-based security review, not a stand-alone claim that HIPAA universally names MFA as a required control.
• Inspect audit-log examples for user identity, timestamps, access to patient records, changes to medication data, administrative actions, and failed access attempts.
• Ask how the vendor protects audit logs from unauthorized change and how your organization can retrieve and review them.
• Test that access is removed promptly when staff leave or change roles, and determine how the vendor handles its own workforce access and support sessions.

For products using SMART on FHIR, review the requested API scopes and whether they are appropriately narrow for the workflow. SMART App Launch uses OAuth scopes to communicate access requirements, but you should verify how the vendor’s actual scopes, user context, and EHR configuration work together. See the HL7 SMART App Launch scopes and launch context guidance.

What data protection and integration security evidence should you request?

Ask for a data-flow diagram that shows where PHI is collected, processed, stored, backed up, and transmitted. Identify the systems and organizations involved, the types of data exchanged, and the controls in place at each boundary. Use the diagram to check whether the vendor’s description matches your planned configuration.

• Review encryption protections for data in transit and at rest, and ask how the vendor manages encryption key management, including key access, separation of duties, rotation, backup, and revocation.
• Confirm retention periods, deletion processes, backup handling, and how the vendor addresses data that cannot be returned or destroyed at contract termination.
• For every interface, review authentication, API authorization scopes, token handling, transmission security, error handling, and logging. Ask how access is restricted to the records and functions the integration needs.
• Request the vendor’s vulnerability management program overview, including how it identifies, prioritizes, remediates, and verifies vulnerabilities, and how it handles unsupported or end-of-life components.
• Ask whether security testing covers the product and its integrations, and request a summary of findings and remediation status appropriate to your review.
• Check whether non-production environments, support tools, and test data are protected from unnecessary exposure to PHI.

HIPAA’s risk-analysis guidance identifies encryption, transmission protection, and data integrity as matters to consider in selecting security measures based on risk. Do not assume that an encryption statement alone demonstrates adequate protection: HHS notes that encryption does not itself preserve ePHI integrity or availability. See HHS risk-analysis guidance and HHS cloud computing guidance.

How should you evaluate incident response and business continuity?

Request the vendor’s incident-response procedures and clarify how the vendor will contact your organization, preserve relevant evidence, contain an incident, and support investigation and recovery. Confirm who receives notices, what information the vendor will provide, how updates are delivered, and how the parties coordinate response responsibilities.

The BAA should address the vendor’s reporting obligations. Under the Breach Notification Rule, a business associate must notify the covered entity of a breach of unsecured PHI without unreasonable delay and no later than 60 calendar days after discovery, subject to the rule’s provisions. That outer limit is not a recommended operational target: agree on a shorter contractual notification window where appropriate so your team has time to investigate and meet its own obligations. See HHS breach notification guidance and 45 CFR § 164.410.

For continuity, review backup and restoration procedures, recovery priorities, downtime communications, and disaster recovery testing evidence. Ask for test dates, scope, results, identified gaps, and corrective actions. Establish whether recovery targets fit your organization’s needs and what manual or alternate workflow staff will use if the application or an integration is unavailable. HIPAA contingency planning includes data backup, disaster recovery, and emergency-mode operations; see 45 CFR § 164.308(a)(7).

How can you validate medication reconciliation workflow integrity?

Test the software with representative scenarios before go-live and after material changes. Include admission, transfer, and discharge workflows, as well as incomplete records, duplicate entries, conflicting sources, and delayed or failed interface messages. Verify that users can identify what changed, where information came from, and whether an action is pending or complete.

• Confirm that medication records and related patient data are associated with the correct patient and encounter.
• Test that additions, discontinuations, dose changes, and other edits are recorded with an identifiable user and timestamp.
• Check how the product displays discrepancies and whether it distinguishes unresolved items from changes that a clinician has reviewed.
• Verify that interface errors, duplicate messages, retries, and out-of-order updates do not silently overwrite or omit information.
• Test that clinicians can review and resolve discrepancies according to your organization’s workflow, and that the resulting decision is documented.
• Confirm that medication information can be retrieved and reconciled during downtime or after restoration without losing or duplicating changes.

These checks support safe workflow validation; they do not replace clinical review or your organization’s procedures. AHRQ describes medication reconciliation as comparing medication information across care transitions, identifying discrepancies, clarifying unintended differences, and documenting the outcome. See the AHRQ Medications at Transitions and Clinical Handoffs toolkit.

How often should you reassess vendors and manage offboarding?

Set a reassessment schedule based on the vendor’s risk tier, the sensitivity and volume of data, the criticality of the service, and the evidence available. Reassess sooner when the vendor changes its product, hosting, subcontractors, integrations, ownership, or security controls, or after a significant incident or unresolved finding.

HIPAA requires regulated entities to periodically evaluate the effectiveness of security measures and regularly reevaluate risks; it does not establish one universal annual vendor reassessment interval. Use a documented, risk-based cadence and event triggers, and record the reason for the schedule. See HHS’s Security Rule summary and 45 CFR § 164.308.

When ending the relationship, coordinate clinical data continuity and security tasks with the vendor and internal system owners. Follow the contract and applicable retention obligations while documenting each step.

• Revoke user accounts, service accounts, API credentials, tokens, certificates, and remote support access.
• Disable integrations and confirm that data exchange has stopped as intended.
• Export or transfer records needed for continuity, then verify receipt and integrity with the receiving system.
• Obtain confirmation of PHI return or destruction where feasible, including relevant copies and subcontractor-held data; document any infeasibility and the continuing protections that apply.
• Reconcile final invoices, open incidents, unresolved risks, and any remaining support or access obligations.
• Retain the BAA, assessment evidence, approvals, offboarding records, and updated risk documentation according to your organization’s retention policies.

HIPAA requires a BAA to provide for return or destruction of PHI at termination when feasible; if that is infeasible, the BAA must extend protections and limit further uses and disclosures. See HHS business associate contract guidance and 45 CFR § 164.504(e).

In summary, assess the vendor’s role, data flows, safeguards, integrations, clinical workflow impact, and recovery capabilities using documented evidence. Pair a suitable BAA with risk-based technical and operational review, reassess when risk changes, and plan offboarding before the service ends.

FAQs

When does a medication reconciliation software vendor need a Business Associate Agreement?

A BAA is generally needed when the vendor meets HIPAA’s definition of a business associate by performing a covered function or service for a covered entity that involves creating, receiving, maintaining, or transmitting PHI on its behalf. A subcontractor that handles PHI on behalf of a business associate may also require a BAA. Determine the relationship from the actual service and data flows, not simply from whether the vendor can view the data. See HHS business associate guidance.

What evidence should a vendor provide for a security risk assessment?

Request a scoped assessment or summary showing the systems and data in scope, identified threats and vulnerabilities, risk ratings, safeguards, remediation plans, and open issues. Supporting evidence may include policies, relevant independent assessment reports, penetration-test summaries, vulnerability remediation records, access reviews, incident-response documentation, and recovery-test results. HIPAA does not universally require a vendor to provide its security documents or permit customer audits; make evidence requests and access rights part of your risk-based procurement and contract process. See HHS risk-analysis guidance and HHS cloud-provider guidance.

How often should healthcare organizations reassess vendor security?

Use a documented, risk-based schedule and reassess when material changes or incidents may affect risk. HIPAA calls for periodic evaluation of security measures and regular reevaluation of risks, but does not set one universal annual interval for vendor assessments. See HHS’s Security Rule summary.

What security steps should be completed when offboarding a vendor?

Disable accounts and credentials, stop integrations, transfer and verify necessary records, and confirm PHI return or destruction where feasible. Document any information that cannot feasibly be returned or destroyed and ensure required protections continue to apply. Also close out support access, open incidents, and unresolved security issues. See HHS BAA guidance and 45 CFR § 164.504(e).