Matrixcare is the market leader among home health and senior living EHR platforms for larger and enterprise-scale organisations. Its cloud architecture, clinical documentation depth, and billing integration are mature. It maintains SOC 2 Type 2 certification, provides a Business Associate Agreement, and operates a security programme consistent with the expectations of a major healthcare software company. When home health agencies that use Matrixcare call me following a security incident, the Matrixcare platform itself is never where the breach originated. The breach is always in the environment around Matrixcare — the devices, the email, the credentials, the networks that connect to the Matrixcare application from outside its secure perimeter.
This is not a criticism of Matrixcare. It reflects a truth about every cloud-based clinical application: the application boundary is where vendor security ends and agency security begins. The security work that a home health agency must do around Matrixcare is not different in kind from what it must do around any other EHR. But it is work that must be done — documented, implemented, and verified — before the agency can claim a complete HIPAA Security Rule compliance programme.
Understanding the Matrixcare Security Architecture
Matrixcare operates its application in a cloud environment with dedicated infrastructure for healthcare clients. The security controls within that environment — network security, database encryption, application authentication, access logging — are Matrixcare's responsibility under the BAA. The controls outside that environment — the devices that connect to Matrixcare, the email systems that receive Matrixcare notifications, the networks that carry Matrixcare traffic from the clinical user to the application, the credentials that clinical staff create for their Matrixcare logins — are the agency's responsibility.
A useful mental model: Matrixcare is a secure facility. Every security control inside that facility is well-managed. But every person who enters and exits that facility carries data with them on devices that leave the facility and travel through environments you cannot control. Securing the facility's interior does not secure what enters and leaves through the door.
The Four Security Layers Every Matrixcare Agency Must Build
Layer 1: Endpoint Security for All Matrixcare Access Devices
Pull up your Matrixcare active user list. Count the distinct device types accessing the platform: Windows laptops in the office, Mac laptops for clinical directors, iPads and Android tablets for field clinical staff, personal iPhones for the scheduling coordinator who checks the platform between visits. Each of these is an ePHI access point the agency must secure. The 2026 mandatory requirements — behavioral EDR, full disk encryption, MDM enrollment — apply to every one of them. An agency with 85 Matrixcare users may have 140 or more devices accessing the platform. Every one requires documented security control verification.
Layer 2: Identity and Authentication Architecture
Matrixcare supports integration with enterprise identity providers including Microsoft Entra ID and Okta. SSO integration is the architecture that produces the most comprehensive and most maintainable security posture: one identity provider enforces MFA across Matrixcare and every other connected application, and one deactivation action terminates access across all integrated systems when a staff member leaves.
Without SSO integration, Matrixcare authentication is managed within the Matrixcare admin console. In this configuration, confirm that Matrixcare's native MFA settings are enabled and enforced for all users, that password policies meet the minimum length requirements of NIST 800-63B (12 characters minimum), and that there is a documented process for Matrixcare account deactivation that is triggered the same day an employment relationship ends.
Layer 3: Email Security Around Matrixcare Notification Traffic
Matrixcare generates email notifications to users — system alerts, task assignments, clinical flags, and administrative messages. The email accounts that receive these notifications are ePHI-adjacent communication channels that require the same layered email security as any other clinical communication pathway. Anti-impersonation protection that specifically recognises Matrixcare sender domains and flags emails from similar-but-not-identical domains is a targeted protection against the Matrixcare impersonation phishing campaigns that have targeted home health agencies in recent years.
Layer 4: Network Security and Data Transmission Verification
All data transmitted between your users and the Matrixcare platform should be encrypted in transit. Verify with your Matrixcare account team that your specific deployment uses TLS 1.2 or higher for all connections — this should be confirmed in writing and retained as HIPAA compliance documentation. For field staff accessing Matrixcare from patient home WiFi networks, cellular data is preferred over patient WiFi as a more controlled and more security-predictable connection pathway.
Protecting your home health agency starts with understanding exactly where you stand today. ShieldForce delivers a free, no-obligation HIPAA Risk Assessment — thirty minutes with a healthcare cybersecurity expert who has spent three decades inside this industry. You will leave with a clear picture of your gaps, your priorities, and what a fully managed security programme looks like for an organisation exactly like yours.
→ Schedule Your Free HIPAA Risk Assessment — shieldforce.io/hipaa-assessment
→ Explore Home Healthcare Cybersecurity — shieldforce.io/home-healthcare
→ View Transparent Pricing from $35/user/month — shieldforce.io/pricing-comparison