01
What enters Bitewing?
Customer-approved reimbursement sources needed for review, starting read-only.
Trust
Know exactly what Bitewing can see—and what it cannot.
Bitewing reads the reimbursement sources you already depend on and shows where the actual adjudicated allowed amount does not match the governing contract. It works alongside your PMS, clearinghouse, and RCM team.
BAA before PHILeast privilegeRead-only startSecurity package available
Boundary readingNo PHI in public examples
Can inspect
- Customer-approved reimbursement sources
- Contract and payer context needed for review
- Claim rows needed for reimbursement review
Not by default
- No PMS write-back
- No public PHI examples
- No cross-customer PHI training
Data boundary map
Sample data - no PHI
Customer systemsOutside Bitewing
Customer-approved sources
read-only to start
Contract context
provided by the customer
Review inputs
only what the service needs
Secure transfer
Crosses: customer-approved sources
Not by default: no write-back to PMS by default
Bitewing tenant boundarycustomer-scoped review
Tenant boundary
customer-scoped processing
Source-backed findings
evidence remains attached
Review controls
held until human approval
Audit loggingaccess, reviewer decisions, exports, support access
Tenant boundary
Crosses: only the data needed for review
Not by default: no public PHI examples or cross-customer PHI training
Outside boundariesConfigured per customer
Security review
details shared through the package
Logged support access
time-bound and role-bound
Customer outputs
approved findings and exports
Approved outputs
Crosses: reviewed findings and exports
Not by default: no PHI sale or public reuse
What enters
Customer-approved sources needed for reimbursement review, starting read-only.
What stays distinct
Customer sources, source-backed findings, human review, support access, and customer outputs are kept distinct.
What gets logged
Boundary crossings, reviewer decisions, exports, and support access write to audit logs.
Data boundary
Direct answers for security reviewers.
This page names what enters, what leaves, who can access it, and what is never reused. The same twelve questions every reviewer asks, answered in order.
Want the underlying controls in writing? Request the security package — it carries the questionnaire categories, BAA template, and gated materials path.
Request the security package02
How does it enter?
Connector, upload, secure transfer, shared folder, or customer-approved API path.
03
Where is it processed?
A logical tenant boundary for that customer. Public examples use synthetic data only.
04
Where is it stored?
Source records and derived findings only as needed for the contracted service and customer agreement.
05
How is it separated?
Tenant partitioning, role-bound access, and source pointers scoped to the customer.
06
Who can access it?
Customer roles and logged internal break-glass access for support or engineering review.
07
What is logged?
Access, administrative actions, reviewer decisions, exports, and support access.
08
What leaves Bitewing?
Customer-approved findings, exports, and workflow outputs.
09
How is third-party processing reviewed?
Covered in the security package and live technical review when relevant.
10
How long is data kept?
Handled under the customer agreement and BAA; deletion requests go through the support/security path.
11
What is de-identified?
Cross-customer learning uses de-identified aggregates only when allowed.
12
What is never used?
No cross-customer PHI training, no sale of PHI, no pooled customer examples in public pages.
| 01 | What enters Bitewing? | Customer-approved reimbursement sources needed for review, starting read-only. |
|---|---|---|
| 02 | How does it enter? | Connector, upload, secure transfer, shared folder, or customer-approved API path. |
| 03 | Where is it processed? | A logical tenant boundary for that customer. Public examples use synthetic data only. |
| 04 | Where is it stored? | Source records and derived findings only as needed for the contracted service and customer agreement. |
| 05 | How is it separated? | Tenant partitioning, role-bound access, and source pointers scoped to the customer. |
| 06 | Who can access it? | Customer roles and logged internal break-glass access for support or engineering review. |
| 07 | What is logged? | Access, administrative actions, reviewer decisions, exports, and support access. |
| 08 | What leaves Bitewing? | Customer-approved findings, exports, and workflow outputs. |
| 09 | How is third-party processing reviewed? | Covered in the security package and live technical review when relevant. |
| 10 | How long is data kept? | Handled under the customer agreement and BAA; deletion requests go through the support/security path. |
| 11 | What is de-identified? | Cross-customer learning uses de-identified aggregates only when allowed. |
| 12 | What is never used? | No cross-customer PHI training, no sale of PHI, no pooled customer examples in public pages. |
Security posture
The controls behind the boundary.
These are the control categories Bitewing operates against. The security package carries the detail, scope, and current state of each one.
Security posture
Control categories
Sample data · no PHI
Tenant isolation
Encryption in transit and at rest
Audit logging
Access review
Export review
Data lifecycle controls
Response process
Details provided under the security package.
Send the questionnaire to your security team.
Request the package or reach the engineering review path at security@bitewing.ai.