Shared records carry organization context and are designed for server-side authorization and selective disclosure.
Security claims should be earned—not styled into a badge.
CLR RX is being designed for workflows that may involve protected health information and other sensitive operational data. The target control environment follows HIPAA-aligned administrative, physical, and technical safeguard principles. Formal compliance, certification, penetration-test, and audit claims will be published only after the corresponding work is complete and independently supportable.
Risk analysis, policies, workforce training, BAAs, incident response, vendor review, and control evidence must accompany the software.
CLR RX is not presently represented as SOC 2 certified, HITRUST certified, independently penetration tested, or production HIPAA compliant.
Built around how health information is actually protected.
The HIPAA Security Rule calls for administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of electronic protected health information. The software is one part of that system; contracts, people, procedures, configuration, and ongoing risk management matter equally.
Identity + access
Tenant-aware authorization, minimum-necessary role design, MFA and SSO integration path, session controls, support-access approvals, and recurring access review.
Audit + accountability
Event coverage for permitted record access, exports, order state, administrative actions, overrides, support sessions, deletions, restores, and integration events.
Data protection
TLS in transit, encrypted managed storage expectations, secret references instead of credentials in source, secure file storage, backup design, retention controls, and disposal procedures.
Application security
Secure headers, restrictive browser policy, input validation, prepared database statements, rate-limit path, dependency review, change control, and security testing before production.
Incident readiness
Documented triage, containment, evidence preservation, recovery, post-incident review, customer communication, and breach-assessment workflow.
Vendor governance
Data-flow inventory, subprocessor review, security requirements, business-associate agreement tracking when applicable, renewal evidence, and termination procedures.
Know where data enters, why it moves, who can see it, and when it leaves.
Consent and minimum-necessary information begin the record.
Identity, role, and tenant boundaries determine access.
Verified recipients and secure transport govern movement.
Audit evidence, retention, and response close the loop.
The platform coordinates. Qualified parties remain qualified parties.
Licensed providers remain responsible for medical judgment and prescribing. Pharmacies and outsourcing facilities remain responsible for compounding, dispensing, facility practices, licensure, product eligibility, and their other regulated functions. Laboratories remain responsible for testing and result release. Clinics remain responsible for their workforce, policies, notices, authorizations, access decisions, payer obligations, and lawful use of the platform.
When CLR RX acts as a business associate, the relationship and permitted uses of protected health information must be defined in a written business-associate agreement. Production integrations require separate contracting, credentials, validation, monitoring, and incident procedures.
Policies and notices
Design choices and policy drafts do not by themselves establish legal compliance. Before production use involving regulated data or transactions, CLR RX will require counsel review, documented risk analysis, control implementation and evidence, applicable agreements, workforce procedures, production vendor review, configuration validation, security testing, and ongoing governance.