Security is an architecture decision. Here is ours.
Caretech's controls sit where they cannot be worked around by the code that calls them: in the authorization layer every request has to cross, in the gate that decides whether work may be confirmed, and in the database itself. A rule that lives only in application code is a convention. A rule the database enforces is a property of the system.
What follows is the security program and the architecture it runs on, the seven-stage chain every AI-assisted output travels, the regulatory position, and the scope of the platform stated precisely. Where an enterprise security team needs more than a page, the Security & Architecture Pack answers in writing.
Nine domains, one architecture.
The trust position at a glance, for technology leaders and security teams deciding whether the depth below is worth their afternoon. Each domain is enforced somewhere specific, and each is argued in full further down.
Security by design
Controls sit where they cannot be worked around — the authorization boundary, the confirmation gate, and the database itself.
Privacy
Privacy-by-design as development practice, with HIPAA, the HITECH Act, GDPR and the India DPDP Act 2023 in view; which obligations apply is settled by product, jurisdiction, data and contract.
Identity & access
One identity per person, least privilege, and role-based access control wherever data is read or changed. Multi-factor authentication governs administrative and privileged access.
Data protection
Tenant isolation enforced by PostgreSQL row-level security, set per transaction — one tenant's rows are unreachable from another tenant's session.
Encryption
Data is encrypted in transit and at rest.
Auditability
Who did what, and when. Clearances, refusals, approvals and corrections are recorded, so each can be reconstructed months later.
Responsible AI
Every AI-assisted output travels a seven-stage governance chain and stops at a qualified person, with the underlying data and the basis shown alongside.
Secure development
Structured development and review, with the review part of the schedule rather than a favor asked at the end of it.
Resilience
Fail-safe by design: the service refuses to start if its database role could bypass isolation, systems are monitored, and security-relevant events are logged and reviewed.
Enforced at the boundary, at the gate, and in the database.
A healthcare platform is judged on what it refuses to do, and a refusal is worth exactly as much as the place it is enforced. Each control below is specific enough to be checked, and each one is the reason a security team can hand this platform data.
In the program
- Access follows least privilege: one identity per person, exactly the permissions their role carries, and role-based access control applied wherever data is read or changed.
- Administrative and privileged access requires multi-factor authentication.
- Data is encrypted in transit and at rest.
- Systems are monitored, and security-relevant events are logged and reviewed.
- Software is built through structured development and review, with the review part of the schedule rather than a favor asked at the end of it.
At the boundary
- Roles hold at the boundary rather than in the caller: a scheduler cannot request a shift on a worker's behalf, a worker cannot confirm their own request, a scheduler cannot approve a timecard, finance cannot void an invoice, and an auditor can read payroll without being able to export it.
At the gate
- Credential requirements are checked at request, at confirmation, at clock-in and at acceptance, with expiry judged against the date of the shift being worked rather than the moment of the click. Clearances and refusals are both recorded, so why a clinician was refused on a given date still has an answer months later.
- A double-booking is refused at the confirmation gate: no assignment is written and the shift stays open for someone else, while a legitimate back-to-back 07:00–15:00 then 15:00–23:00 is allowed. The calendar shows the same conflict before the click that the gate enforces at the click — one rule with two callers.
- A timecard cannot be approved over an unresolved meal-break violation; the approver is told exactly what to fix and the correction path stays open. A geofenced clock-in outside the radius is retained as evidence rather than discarded.
- Overtime follows the jurisdiction the work happened in. A tenant rule set below the federal 1.5× floor — or California's 2.0× for double time — is raised to the statutory floor, and the correction is written into the explanation an auditor reads. Rules resolve as at the work date, so a timecard corrected in September for July work is paid under July's rules.
In the database
- Tenant isolation is enforced by PostgreSQL row-level security, with the policy forced onto the table owner and the tenant set per transaction — so it dies with the transaction and cannot leak across a pooled connection. The service refuses to start if its database role can bypass it.
- The same work cannot be billed twice, because the database refuses the second claim — not a check in application code that a later caller could route around.
- Traceability for key system activity — who did what, and when — so a clearance, a refusal, an approval or a correction can be reconstructed long after the shift it belonged to.
The deep version, in writing.
A security review runs on specifics, so the specifics are written down. The Security & Architecture Pack sets out the platform's isolation, permission and audit design at the depth enterprise security teams work at, and it is available on request.
Tenant isolation, in detail
How PostgreSQL row-level security is applied: the policy forced onto the table owner, the tenant set per transaction so it dies with the transaction and cannot leak across a pooled connection, and the startup check that refuses to run if the database role could bypass it.
The permission model
The role-by-action matrix in full: what a scheduler, a worker, an approver, a finance analyst and an auditor may each read, write and confirm — and the boundary where each rule is enforced, rather than the caller that is trusted to follow it.
Audit trail design
What is written for every clearance, refusal, approval and correction; who may read it; and how a decision — including a refusal — is reconstructed months after the shift, the timecard or the invoice it belonged to.
The pack also covers how encryption in transit and at rest is applied, how least privilege and multi-factor authentication govern administrative access, and how development and review are structured.
The platform watches the data. You decide about the patient.
One sequence, applied wherever analytics touch care, and the spine of every Caretech AI feature: data, validation, AI and analytics, rules and context, human oversight, action, traceability. It is a design rule rather than a policy statement, because each stage changes what has to be built.
Data to traceability, in seven stages
Data
- A reading, a document, a request, a result — captured with its context and its source, through a known path
Validation
- Structure, completeness, provenance and range checked against what the record already holds, before anything is derived from it
AI & analytics
- Trends and thresholds produce indicators — a flag, a shortlist, a ranking. Never a conclusion
Rules & context
- Eligibility, policy, reference range, jurisdiction, role and setting shape the output before anything is offered to anyone
Human oversight
- A qualified person reads the indicator, with the underlying data and the basis for it visible alongside, and decides
Action
- Only what the person decided is carried into the workflow — a schedule, a report, a care plan, an escalation
Traceability
- What was produced, who reviewed it, what they decided and when is written down
Every output stops at a person who is qualified to act on it.
Caretech surfaces indicators and drafts for a qualified professional to review, confirm or reject, with the underlying data and the basis for the output shown alongside it. It does not diagnose, does not treat, does not decide, and is not a substitute for professional medical judgment.
Caretech AI may use artificial intelligence, machine learning, automation or analytics to support healthcare workflows, data organization, reporting, triage assistance, operational insights, workforce matching, document processing or decision support.
AI-generated outputs may be incomplete, inaccurate, biased, outdated, or inappropriate for certain clinical or operational contexts. All AI-assisted outputs should be reviewed by qualified human users before being relied upon.
Caretech AI does not represent that AI outputs are error-free or suitable for final clinical decision-making unless expressly validated, approved, and contractually designated for a specific regulated purpose. Users should not rely solely on AI-generated outputs for diagnosis, treatment, medication management, emergency decisions, or patient safety-critical actions.
No Caretech AI product holds regulatory clearance, approval or certification for a clinical purpose in any jurisdiction, and no accuracy figure, benchmark or model name appears anywhere on this site, because none has been established.
What Caretech builds against, and what a contract settles.
Caretech AI holds no third-party security certification today and publishes no audit report. Its regulatory position is awareness of the HIPAA, HITECH Act, GDPR, India DPDP Act 2023 and applicable U.S. state privacy frameworks — stated as awareness of those frameworks rather than compliance with them — and which obligations apply depends on the product, the jurisdiction, the data and the contract. No accreditation is claimed in any care setting, in correctional healthcare or elsewhere: reporting supports an organization's own obligations rather than discharging them.
Compliance obligations also arise contractually — from covered entities, business associates, processors and healthcare partners — and those are settled in an agreement rather than on a website. No Business Associate Agreement is asserted or offered here, and nothing on this site states where data physically resides, per jurisdiction or per tenant.
The India DPDP Act 2023 requires a data fiduciary to publish the contact details of a designated Grievance Officer. That designation is pending. Privacy and data-protection correspondence reaches Caretech AI at compliance@caretechai.com.
Found a security issue? Report it to security@caretechai.com — the address is published machine-readably at /.well-known/security.txt, and every report reaches the engineering owner directly.
Caretech AI's quality commitment is structured development and review processes, documented system workflows, privacy-by-design and security-by-design principles, and role-based access control. It sits under a written limit, quoted here as it is written: "Unless specifically certified, cleared, approved, or contracted for a regulated clinical purpose, Caretech AI products should not be considered a substitute for professional medical judgment, diagnosis, treatment, emergency care, or direct clinical decision-making."
Nothing Caretech AI has designed is currently certified, cleared, approved or contracted for a regulated clinical purpose. Healthcare providers and licensed professionals remain responsible for clinical decisions, patient assessment, medical treatment, and compliance with applicable laws and professional standards.
Purpose and lawful basis
Purpose-based processing, and consent or other lawful grounds where applicable. Customers remain responsible for determining their own lawful basis and for the notices and consents their use requires.
Rights and retention
Support for data subject and data principal rights where applicable — access, correction, deletion and portability workflows — plus data retention management and subprocessor management where applicable.
Roles, defined by contract
Depending on the service relationship, Caretech AI may act as a data processor, service provider, or independent controller. The applicable role should be defined in the customer agreement or data processing agreement.
Scope, stated precisely.
Where the platform's edge is, named exactly. Each line below is a scope statement about the product, and each applies everywhere on this site.
What a credential check establishes
A credential check compares the documents and dates held on a profile against a configured list of requirements. It is not primary-source verification, not a license board lookup, not an exclusion or sanctions screen, and not a background check. It does not establish that a license is genuine, current or unrestricted. Licensure verification and the hiring decision remain with the organization.
Working time and travel
No rest-period rule, no minimum gap between shifts and no fatigue model. No travel contracts, housing stipends or per-diem handling. Working-time obligations stay with the employer who owns them, and no assignment is made without a person confirming it.
Prescribing and medicines
No prescribing, e-prescribing, medicines-supply or medication decision function is offered in any area of the platform. Prescription coordination means moving a workflow, never authoring or authorizing a prescription.
Regulated interpretive functions
Caretech surfaces indicators and drafts for a qualified professional to review, confirm or reject, with the underlying data and the basis for the output shown alongside. It does not release an interpretation of a laboratory result without a clinician authoring it, does not present a score, stratification or prediction of an individual's clinical risk as a finding, and states no accuracy, sensitivity or specificity figure for anything.
Scope set with counsel, per market
Caretech's scope in each market is set with regulatory counsel before a line is written — against the United States clinical-decision-support carve-out, EU MDR Rule 11 and India's medical device rules. Software that interprets a clinical result is a regulated device in all three jurisdictions, and where a feature would fall inside a medical-device definition it is not built until counsel has said so in writing.
Monitoring, detection and emergencies
Caretech is not a continuous monitoring service, not a medication safety system and not a fall detection system. Readings are not watched: nobody on Caretech's side is on the other end of a device waiting for a value to change. Alerting routes a signal to a named person and records the response — it is a coordination tool and not an emergency response service, and no claim of supervised or uninterrupted observation is made. In a medical emergency, contact local emergency services.
Student records and school settings
Caretech AI publishes no FERPA or COPPA compliance position, and none should be inferred. Which statute governs a district's records is settled with the district's counsel before design begins. No wellness or mental health screening of students is offered; a medication administration log is documentation, not a clinical safety control.
Behavioral, rehabilitation and post-acute scope
No risk score of any kind, for any patient, at any point. No crisis prediction — crisis response is a clinical service delivered by people. No validated outcome-instrument reporting, no outcome measurement dashboard and no remote therapy modality. Scheduling, documentation, care plan tracking and care team communication are workflow software; the clinical service delivered through them is the organization's.
Markets, not a footprint
India and the United States are the markets Caretech builds for, and the platform is designed for the requirements of both. No office, delivery center, hosting region or physical presence in either country is claimed anywhere on this site.
Integrations
Caretech is interoperability-ready and API-first, and exchanges data with electronic health record, laboratory, imaging and device systems on open standards. Every integration is scoped, agreed and built for the customer's own estate, and no third-party product is named anywhere on this site as a partner or a shipping connector.
Payroll and billing
Approved time generates a provider import file for a payroll provider. Caretech operates no payment gateway, performs no payroll processing or tax handling, and produces no general-ledger export. Payout visibility means a clinician can see pay information and completed shifts.
The statements in full.
Each page below publishes the company's own text with its hedges intact, and marks the places where an answer is still outstanding.
HIPAA statement
Where Caretech AI may support organizations subject to HIPAA, what clients remain responsible for, and what Caretech AI does not guarantee.
02GDPR statement
The privacy principles supported where GDPR applies, the roles Caretech AI may take, and what customers remain responsible for determining.
03India DPDP Act statement
What Caretech AI intends to support under the Digital Personal Data Protection Act, 2023, and the Grievance Officer designation now pending.
04Medical & AI disclaimers
Medical, AI use, data security, third-party integration and website profile disclaimers, published in full.
05Terms of Use
The acknowledgments that apply to using this website, and what this site does and does not offer.
Request the Security & Architecture Pack.
One document, setting out the architecture above in detail — tenant isolation, the permission model, the audit trail design — together with the data-protection position and the full scope inventory. Ask through the contact page and it comes in writing.