RCMTask security & HIPAA posture
RCMTask is back-office software for medical practices, and we operate as your Business Associate under a signed BAA on every paid plan. Patient identifiers are encrypted by the application with AES-256-GCM before they ever reach the database, under a key wrapped by AWS KMS. Documents are stored in Amazon S3 under a dedicated customer-managed KMS key. Changes and administrative actions are written to an append-only audit log protected by a SHA-256 hash chain, so tampering is detectable rather than merely prohibited. Production runs in AWS us-east-1, in the United States.
BAA on all paid plans · AES-256 field-level + KMS · TLS 1.2/1.3 · Hash-chained audit log · US-hosted (us-east-1)
Four specifics worth checking against any vendor you evaluate.
Ask whether they dropped the plaintext.
Most systems add encryption alongside the data that is already there. We migrated ours and then permanently dropped the plaintext columns from the schema — patient name, date of birth, phone, email, and the insurance policy, group and subscriber identifiers — with the encrypted columns set NOT NULL, so a plaintext write to those fields is no longer expressible. No legacy copy of those fields remains.
Ask whether tampering is detectable, or just prohibited.
Our audit log is append-only, enforced by database triggers rather than by convention, and every entry carries a SHA-256 hash of itself chained to the entry before it. Altering, deleting or reordering a historical row does not merely violate policy — it breaks the chain, and the break is detectable at a specific row. We ship an integrity check that walks the whole chain and reports either verified or the exact sequence number where it broke, and we will run it live, on screen, in your evaluation call.
Ask what their fax records store.
Inbound faxes on RCMTask carry no OCR text, no extracted patient name and no date of birth — those columns do not exist in the schema. What is stored is a link to a patient record, a de-identified summary, non-identifying tags, and a one-way hash of the file contents for duplicate detection. The document body lives only as an encrypted PDF in S3, and you set the retention period per practice, defaulting to the HIPAA six-year window.
Ask what grants clinical authority.
On RCMTask, denying a records request or reviewing sensitive content requires a clinical licence — MD, DO, NP, PA or RN — recorded on the account, not a job title and not an administrator's discretion. Licences carrying an expiry date are enforced and fail closed.
How we protect your patient data.
Encryption at rest
Patient names, dates of birth, contact details, insurance and subscriber identifiers, and stored credentials are encrypted by the application itself with AES-256-GCM — a fresh initialization vector and authentication tag per value — under a data key wrapped by AWS KMS and unwrapped only in memory at start-up. The previously plaintext columns were permanently dropped from the schema, so no unencrypted copy of those fields remains. The service refuses to start in production if the encryption key is unavailable. Uploaded documents and faxes are stored in Amazon S3 with server-side encryption under a dedicated customer-managed KMS key; an upload that cannot reach that key fails rather than falling back to unencrypted storage. The underlying database volume and its automated backups are encrypted at rest by AWS under a customer-managed KMS key.
Encryption in transit
Every connection is encrypted with TLS: browser to application, application to database, and application to our internal cache. The database connection does not merely use TLS — it verifies the database server's certificate against a pinned certificate-authority bundle in production, so a redirected or impersonated database endpoint is refused rather than trusted. Our public endpoints negotiate TLS 1.2 or 1.3 and refuse TLS 1.0 and 1.1.
Tamper-evident audit trail
Every audit entry carries a SHA-256 hash of itself chained to the entry before it, and the audit tables carry database triggers that refuse updates and deletes outright — so a historical row cannot be quietly rewritten through the application, and any break in the chain is detectable at a specific row. We ship an integrity check that walks the entire chain and reports verified, or the exact sequence where it broke. Document access is logged three ways: who opened it, who downloaded it, and — the one most systems omit — who was refused. Changes to patient, document, task, records-release, user and access-grant records, and administrative actions, are recorded with the acting user, the affected record, the field changed, the before and after values, the IP address and the timestamp. We do not delete audit records, and we will produce them for you on request.
Least-privilege access
Titles do not grant clinical authority — credentials do. Denying a records request, or reviewing sensitive content, requires an MD, DO, NP, PA or RN licence recorded on the account by your practice administrator; we do not perform primary-source verification, and licences carrying an expiry date are enforced and fail closed. Those decisions run through a central authorization engine that denies by default: if no rule exists for an action, it is refused, and permission composes role, per-practice capability grants and clinical licence rather than a single role string. The rest of the platform is gated by role and practice-scope middleware on every request. Per-location isolation and rank-based seniority gating are available on request for multi-site practices.
Tenant isolation
Every request into RCMTask carries an explicit practice scope, and that scope is applied to the queries that request makes — tenancy is a property of the request, not a filter a developer remembers to add. A request for a record outside your practice returns a not-found rather than a permission error that would confirm the record exists. A limited set of platform-administration and system-audit operations runs on a separate privileged connection and is authorised in the application layer instead — we would rather tell you that than let you find it.
Authentication
Sign-in runs on Auth0 — RCMTask never stores or handles your users' passwords. Every API request is independently validated; a session is not trusted because a previous request was. Multi-factor authentication is required: our identity provider enforces it at sign-in, and our API independently re-checks it on every single request — a request whose token carries no proof of MFA is refused, so the second factor cannot be bypassed by replaying a session. Your administrators can also see MFA enrolment across your whole workforce and pull an enrolment-rate report for your own risk analysis.
Hosting and data residency
Production runs in AWS us-east-1, in the United States. PHI is stored in Amazon RDS and Amazon S3 with AWS KMS-managed encryption — both HIPAA-eligible services, covered by our executed AWS Business Associate Addendum. The database runs Multi-AZ with automated daily backups. Our application compute tier currently runs on AWS App Runner, which is not on the AWS HIPAA Eligible Services list; we are migrating it to Amazon ECS on Fargate, which is. In the meantime, patient identifiers are encrypted by the application before they reach any datastore, so the compute tier never holds a durable plaintext copy of them. We disclosed this here rather than let you find it, and we will share the current status on request.
Store-nothing fax pipeline
Inbound faxes are classified by AI without persisting their contents. The fax record carries no OCR text, no extracted patient name and no date of birth — those columns deliberately do not exist. What is stored is a link to a patient record, a de-identified summary generated under a Safe-Harbor instruction and filtered before storage, non-identifying tags, and a one-way hash of the file contents for duplicate detection. The document body lives only as an encrypted PDF in Amazon S3. Classification and text extraction run on Amazon Textract and Amazon Bedrock inside our own AWS account, in US regions, under the same Business Associate Addendum as the rest of our AWS footprint — your PHI is not sent to a third-party AI vendor.
When something goes wrong, RCMTask stops rather than degrades.
If the encryption key is unreachable, the service refuses to start rather than writing plaintext. If the document storage key is unreachable, the upload fails rather than falling back. If a clinician's licence has expired, the clinical action is refused rather than allowed. If we cannot determine whether your practice has an executed BAA, we block the PHI write rather than assume yes. Each of those is a deliberate decision to fail closed, and each is enforced in code rather than documented in a policy.
HIPAA policies, generated and versioned for you.
When you finish setup, RCMTask generates a standard HIPAA policy set on your practice's behalf and files it in your compliance binder as downloadable PDFs — Notice of Privacy Practices, Privacy and Security Officer designations, sanction policy, workforce training plan, risk-analysis starter, security-incident response procedure, minimum-necessary and uses-and-disclosures policies, patient-rights procedure, access and audit-control policy, contingency plan, business-associate register and a records-release SOP. There is no policy-by-policy adoption step: the set is applied for you, each one recorded as a dated attestation naming who adopted it. The officer designations are pre-filled to the person who completed setup — review and re-attest them to the people you actually intend, because those are your §164.530(a) and §164.308(a)(2) designations. You can customise any policy later in the Compliance Center, and each customisation is written as a new attestation linked to the one it replaces, so your compliance record shows who changed what, when, and which version they acknowledged. These are starter policies drafted to the Privacy, Security and Breach Notification Rules, and each template says on its face that your counsel should review it before formal adoption — which is what any competent policy set says, because a policy your lawyer has not read is not your policy. What we remove is the blank page and the version-control problem: generated, attested, dated and versioned from day one, instead of a folder of Word files nobody can date.
A BAA is available on every paid tier.
Activation
Click-through BAA executed at activation: your signer's typed name, IP address and timestamp are captured as an electronic signature under the E-SIGN Act (15 U.S.C. §7001) and applicable state UETA. The executed PDF is generated at the moment of signing and filed in your compliance binder, downloadable at any time. The agreement runs the §164.504(e)(2) required elements — permitted uses, safeguards, subcontractors, breach notification within the §164.410 outer bound, individual access and accounting, HHS audit cooperation, and return-or-destroy on termination.
Enterprise
Negotiated BAA tailored to your legal review. Sent on request to security@rcmtask.com.
Sandbox
The free Sandbox tier is for evaluation with demo data, and the boundary is enforced in code rather than promised in a policy. Until a practice activates and executes a BAA, RCMTask refuses to create patient records, appointments, clinical tasks, documents or imports — the API returns a BAA-required error, not a warning. New practices land pre-BAA by construction; there is no code path that creates an active practice by accident. And if the gate cannot determine your status for any reason, it blocks the write rather than assuming yes. Our fax and partner-API endpoints sit outside that gate today; closing them is on our roadmap, and until it lands we ask evaluation accounts not to route live patient documents through them.
Who else touches your data.
A current list of the subprocessors used to provide the RCMTask service, and their role in the service, is available on request to security@rcmtask.com.
What we do not have yet.
We are a 2026 company, and here is what we would tell you in diligence anyway. Each of these sits on our risk register with a named owner — the same register your own risk analysis will ask us about.
No SOC 2, no HITRUST — and no HIPAA certification, because none exists.
HHS does not certify or endorse software; a vendor claiming a HIPAA certification is telling you something about themselves. A SOC 2 Type II is on our roadmap and we will publish the date when it is booked, not before. In the meantime we answer your questionnaire directly, in writing, and walk your team through the controls live — including the ones on this list.
No third-party penetration test report, and no published uptime SLA.
We will tell you exactly what testing we do run, and we would rather commit to a number we can hold on our worst week than publish one that looks good on our best.
No automated security monitoring, alerting or on-call rotation yet.
Our scheduled background jobs are currently disabled, which means our statutory-deadline sweeps and SLA digests do not run automatically today, and our backup restore process has not yet been formally tested. Deadline tracking in the product is surfaced in your work queues rather than pushed to you, and we will tell you when that changes.
No customer-managed SSO federation or SCIM provisioning.
You sign in with email and password or with a Google account today. If federation to your own identity provider matters to your organisation, tell us, because it affects our roadmap.
If something on this list matters to your organisation, ask us about it directly — we will give you the current status, the target date, and what compensates for it today.
Security questions
Is RCMTask HIPAA compliant?
There is no HIPAA certification for software — HHS does not certify or endorse products, and compliance is a property of your practice's program, not of any vendor's app. What we can tell you is what we do. We act as your Business Associate under a signed BAA. Patient identifiers are encrypted by the application with AES-256-GCM under a KMS-wrapped key before reaching the database, and documents are encrypted in S3 under a dedicated customer-managed KMS key. Changes, administrative actions and document access are captured in an append-only, hash-chained audit log we will produce for you on request. Clinical authority is gated on a recorded clinical licence rather than a job title, through a default-deny authorization engine. And we generate and version the HIPAA policy set your compliance program needs. Ask us for our current security posture summary and our open remediation items, and we will send both.
Where is data stored?
Stored in AWS us-east-1, in the United States, in Amazon RDS and Amazon S3 — both HIPAA-eligible services.
Who at RCMTask can see our PHI?
Access to your practice's data is limited to authorised personnel who need it to provide and support the service, under the minimum-necessary standard, and every access is recorded in your audit trail. Rekha Technologies works with a delivery and support team located in India, engaged as a subcontractor under a written agreement; authorised members of that team may access customer PHI remotely for that purpose. Your PHI is stored in the United States and is not replicated outside it — this is remote access, not offshore storage. If your organisation or your payer contracts require US-only access to your PHI, tell us before contracting and we will confirm in writing whether we can accommodate it for your account.
How is data encrypted?
Three layers. The application encrypts patient and insurance identifiers with AES-256-GCM before they reach the database, using a data key wrapped by AWS KMS and unwrapped only in memory at start-up. Documents and faxes are stored in Amazon S3 with server-side encryption under a dedicated customer-managed KMS key, and document links are signed and expire in fifteen minutes — there are no permanent public URLs to a patient document. The database volume and its automated backups are encrypted at rest by AWS. In transit, all connections use TLS; our public endpoints negotiate TLS 1.2 or 1.3 and refuse 1.0 and 1.1, and the application verifies the database server's certificate against a pinned certificate authority.
Do you offer SSO and MFA?
You can sign in with email and password, or with a Google account. You may also see a Continue with Microsoft option — that is our own staff directory and is not available to customer users. Customer-managed SAML or OIDC federation to your own Microsoft Entra or Okta tenant, and SCIM user provisioning, are not available today; if you need them, tell us, because it affects our roadmap. Multi-factor authentication is required on every account: our identity provider enforces it at sign-in and our API re-checks it on every request, refusing any request whose token carries no proof of MFA. Your administrators can see MFA enrolment across your workforce.
Do you use AI, and does our PHI train anyone's model?
We use AI to classify inbound faxes and extract fields from documents. It runs on Amazon Textract and Amazon Bedrock inside our own AWS account, in US regions, covered by the same Business Associate Addendum as the rest of our AWS footprint — your PHI is not sent to a third-party AI vendor, and under AWS's published data-privacy commitments for Bedrock your content is not used to train models. The fax pipeline is also store-nothing by design: extracted text is used in memory and never written to our database.
How do I report a security issue?
Email security@rcmtask.com. We monitor that address during US business hours and aim to acknowledge within one business day. Confirmed incidents are handled under our incident-response procedure, including any notification obligations under our BAA and 45 CFR §164.410.
Can we audit / review the platform before signing?
Yes. We will send a sample Business Associate Agreement and our current subprocessor list, and we answer security questionnaires directly — send us yours and we will work through it with you, line by line. We are also glad to walk your team through the audit trail, including the hash-chain integrity check running live, and the access model.
Talk to our security team.
Send us your security questionnaire and we will work through it with you, line by line. Or book twenty minutes and we will screen-share the live product: the audit trail with its integrity check running, the access model, and how a records request is gated on a clinical licence. We will also send our current subprocessor list and a sample Business Associate Agreement.