You spent months evaluating risk adjustment software. You compared features, checked references, negotiated pricing. You asked about accuracy rates, integration capabilities, and user experience. You probably didn’t ask detailed questions about security and compliance.
That’s a problem. Because the risk adjustment software you’re implementing will handle some of your organization’s most sensitive data. PHI from thousands of members. Provider information. Financial data. Coding decisions that could be questioned in audits years later.
When that data gets breached or mishandled, “we didn’t ask the right security questions” won’t be an acceptable explanation to CMS or your board.
The Cloud Deployment Blindness
Most modern risk adjustment software is cloud-based. That’s great for accessibility and scalability. It’s also a security risk if you don’t understand where your data actually lives and who can access it.
Is your data in a dedicated environment or shared infrastructure? Shared infrastructure is cheaper for vendors, but it means your data is on the same servers as other organizations’ data. If someone else’s account gets compromised, there’s potential exposure to your data.
Where are the data centers physically located? Some cloud providers store data internationally to optimize performance. If your PHI is being stored or processed in countries with weaker data protection laws, you’ve got a compliance problem.
Who has administrative access to your environment? The vendor’s engineers need some access for support and maintenance. But do they have audit trails showing every time they accessed your data? Can they see actual member information or just system logs?
Most organizations don’t ask these questions during evaluation. They assume “HIPAA compliant” means secure. HIPAA compliance is the baseline, not the gold standard. You need to understand the specific security architecture, not just trust that the vendor has it figured out.
The Subcontractor Problem
Your risk adjustment software vendor probably uses subcontractors. Cloud hosting providers, data processing services, offshore development teams. Each subcontractor is a potential security vulnerability.
The vendor might have excellent security practices, but if they’re using a third-party AI service to process your clinical notes and that service has weak security, your data is exposed.
Ask your vendor for a complete list of subcontractors who will have any access to your data. Ask what security requirements they impose on those subcontractors. Ask if they audit subcontractor security or just take their word for it.
I’ve seen organizations discover months after implementation that their vendor was using an offshore development team with direct access to production data for debugging purposes. The vendor saw this as normal. The organization’s security team had a heart attack.
The Data Retention Nightmare
When you eventually switch risk adjustment software vendors, what happens to your data? Most contracts have vague language about data deletion after termination.
But “deletion” means different things to different people. Does the vendor delete your data from production systems but keep it in backups for years? Do they truly scrub all your data from all systems, including disaster recovery environments and development copies?
If they don’t properly delete your data, you’ve got ongoing liability for PHI that’s sitting on systems you no longer control. When that vendor gets breached two years after you’ve left, your members’ data could be exposed.
Before you sign, negotiate specific data deletion requirements. Within 30 days of contract termination, the vendor must delete all your data from all systems including backups, provide written certification of deletion, and allow you to audit deletion if you choose.
The Integration Security Gap
Risk adjustment software integrates with your EHR, claims system, and other platforms. Those integrations create security vulnerabilities if not properly designed.
Are the integrations using secure, encrypted connections? Are credentials stored securely? When integration credentials get compromised (and they do), how quickly can you revoke access?
Some vendors build integrations that require overly broad access to your source systems. They might need to read clinical notes from your EHR, but the integration they built requires full read access to your entire EHR database. That’s lazy security design that creates unnecessary risk.
Insist on least-privilege integration design. The risk adjustment software should only have access to the specific data it needs, nothing more. If there’s a breach, the exposure is limited.
The Audit Trail Requirements
Risk adjustment software should log everything: who accessed which charts, what coding decisions were made, when data was exported, what configuration changes occurred. These logs aren’t just useful for security. They’re essential for RADV audit defense and compliance.
But many vendors implement minimal logging. They track major actions but not details. When you need to prove three years later that a coder had appropriate access to documentation supporting a specific HCC, you can’t produce the evidence.
Ask vendors to demonstrate their audit logging. Don’t accept general assurances. Have them show you actual logs. Ask how long logs are retained. Ask if you can export logs for your own retention. Ask if their logs meet your compliance requirements for healthcare data handling.
The Vendor Security Incident Response
When (not if) your vendor experiences a security incident, how will they handle it? Will they notify you immediately or wait to investigate first? Will they provide details about what data was potentially exposed or give you vague assurances?
Vendor security incident response should be detailed in your contract. If there’s a breach involving your data, you need notification within 24 hours, not when they feel like telling you. You need detailed information about what happened so you can assess your own breach notification obligations.
I’ve seen vendors delay breach notifications for weeks while they “investigated,” leaving their customers unknowingly out of compliance with HIPAA breach notification requirements. That’s unacceptable.
The Certification Question
Many risk adjustment software vendors claim they’re HIPAA compliant or HITRUST certified. Verify those claims. Ask for copies of recent security audit reports. Ask when their last penetration test was conducted and whether you can see the results.
Some vendors use phrases like “designed to meet HIPAA requirements” or “implements HIPAA safeguards.” That’s weasel language suggesting they haven’t actually been audited or certified.
If security matters to you (and it should), work only with vendors who can produce recent third-party security certifications and audit reports. The vendor who won’t show you their security audit results is hiding something.
Security isn’t glamorous and it’s not what gets highlighted in sales presentations. But risk adjustment software handles extraordinarily sensitive data. One breach can cost millions in remediation, regulatory penalties, and reputation damage. Ask the hard security questions before you sign, not after you’ve been breached.
