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 coverageCoverage defined and reviewed route by route before activation
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
Support and engineering access
approval and controls documented per deployment
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
Security-sensitive API activity and selected operational actions are logged today. Coverage is documented route by route and reviewed against each deployment before activation. The security package identifies current scope and any deployment-specific limits.
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?
Access is limited to authorized customer roles and approved internal support or engineering access. The applicable approval, time-bound access, and logging controls are documented for each deployment.
07
What is logged?
Security-sensitive API activity and selected operational actions are logged today. Coverage is documented route by route and reviewed against each deployment before activation. The security package identifies current scope and any deployment-specific limits.
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
How is cross-customer use governed?
Bitewing's policy prohibits pooling or reusing customer data across customers by default and prohibits using customer PHI to train a cross-customer model. Any separately authorized cross-customer use must be documented in the applicable agreement and activated only after the required data-use and provider-route controls are verified.
12
What is never used?
Bitewing's policy prohibits the sale or public reuse of customer PHI and prohibits using customer PHI for cross-customer model training.
| 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? | Access is limited to authorized customer roles and approved internal support or engineering access. The applicable approval, time-bound access, and logging controls are documented for each deployment. |
| 07 | What is logged? | Security-sensitive API activity and selected operational actions are logged today. Coverage is documented route by route and reviewed against each deployment before activation. The security package identifies current scope and any deployment-specific limits. |
| 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 | How is cross-customer use governed? | Bitewing's policy prohibits pooling or reusing customer data across customers by default and prohibits using customer PHI to train a cross-customer model. Any separately authorized cross-customer use must be documented in the applicable agreement and activated only after the required data-use and provider-route controls are verified. |
| 12 | What is never used? | Bitewing's policy prohibits the sale or public reuse of customer PHI and prohibits using customer PHI for cross-customer model training. |
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.