SECURITY & SCOPE
Retrofitted security is a rewrite. We have had to do that rewrite before, which is why the posture came first and the product came second.
PROTECTING PRACTICE & PATIENT DATA
A care team should be able to move the work without opening the whole practice. Matari applies identity, authorization, practice scope and auditability before protected context is returned.
FOR THE PRACTICENecessary context follows the job.Clinicians, patient services and billing teams can work from the same platform with different reach.
FOR SECURITY REVIEWThe caller does not choose the boundary.Practice, membership, role, permission and facility scope are resolved on the server.
PROTECTED RECORD REQUEST
CONTROL PATH · CURRENT PLATFORMREQUESTING CONTEXTCare team · Downtown clinic
PATIENT RECORDProduction access starts with a configured identity provider and an individual staff session—not a password stored by Matari.
WHY IT MATTERSCare teams enter the practice as themselves, not through an anonymous shared doorway.The server derives the selected practice, active membership, role, permissions and facility scope before handling the request.
WHY IT MATTERSA scheduler, clinician and biller can share one system without receiving the same reach.A stable practice tenant key scopes reads, writes, persisted state and private clinical assets. The request cannot choose another boundary.
WHY IT MATTERSA record or recording cannot silently fall through to another practice's store.Security-sensitive actions and supported record workflows produce audit events with the responsible actor and record context.
WHY IT MATTERSPractice leadership can investigate what happened without relying on memory.SCOPED ACCESSPractice tenant · Facility · Patient
AUDITABLEINTELLIGENCE STAYS INSIDE THE REQUESTWhen configured, patient context remains tenant-, organization-, facility- and patient-scoped. Model-backed writes and first-time generations fail closed when the service is unavailable.Patient data is not used to train models shared with other customers by default.
CONTROLS BEHIND THE BOUNDARY
Provider-backed sign-in uses authorization code with PKCE. Matari stores only a hash of its opaque browser session token, rotates CSRF protection, and does not store staff passwords.
WHY IT MATTERSAccess stays tied to an individual identity instead of an unaccountable browser session.
Practice membership, role, permissions and facility scope are resolved server-side. The same tenant key follows database reads, writes and object metadata.
WHY IT MATTERSClinical and operational roles can work together without gaining the same access.
Recordings and patient images stay in private, practice-scoped object storage. Matari verifies the record relationship and practice before issuing a five-minute access URL.
WHY IT MATTERSSensitive media remains usable at the point of care without becoming a public asset.
Assistant requests are constrained by tenant, organization, facility and patient. Model-backed writes and first-time generations fail closed when the configured service is unavailable.
WHY IT MATTERSIntelligence can use active care context without becoming a route around practice access rules or shared-model training by default.