HIPAA business associate: our security model and BAA process
Dental Revenue Desk’s owner states that the company will sign a business associate agreement before PHI is exchanged and commits to access controls, MFA, device policies, training, audit logs, and breach procedures. The delivery team is based in Pakistan and works US business hours. Legal and security review remains a gate before the first PHI exchange.
Published July 21, 2026
BAA before PHI — the owner-stated policy
Dental Revenue Desk’s owner states that a business associate agreement will be signed before PHI is exchanged, including before a live pilot. A preliminary workflow review is intended for practice, software, volume, and process information; do not submit patient information during that review.
HHS's Summary of the HIPAA Security Rule states: "Before permitting a business associate to create, receive, maintain, or transmit ePHI, a regulated entity must have in place a contract or other written arrangement." Under HITECH a business associate is also directly liable for Security Rule compliance, breach notification, and minimum-necessary limits. The final BAA, signing entity, security implementation, and operating evidence still require legal and security review. See where the BAA sits in onboarding.
- Workflow review. Discuss the practice and proposed workflow without patient information.
- Legal and security gate. Review the operating controls and complete the agreement and BAA before PHI.
- Live setup and verification. Begin only after the BAA and required technical validation are complete.
The current evidence boundary
The owner commits to access controls, but the site does not yet publish an account model, permission set, provisioning method, revocation process, or system-specific access design. It also does not establish where data is stored, whether local copies are technically prevented, or how logs are made available to a client.
Those details require evidence and review before live use. The public product scope remains narrower: Dental Revenue Desk offers insurance verification and generic, owner-authorized write-back into the client practice management system. See the write-back qualification.
Owner-stated security commitments
The table below records what the owner has stated as policy or intent as of July 2026. It is not an attestation that each control is implemented or tested, and it is not a substitute for legal and security review. As a useful benchmark, NIST SP 800-66r2 notes that covered entities are "permitted to require more of their business associates" in the BAA. See the claims policy behind every statement on this page.
| Control | Current status and evidence boundary |
|---|---|
| BAA before PHI | Owner-stated policy: Dental Revenue Desk will sign a business associate agreement before PHI is exchanged. Legal review and the signing entity remain pending. |
| Access controls | Owner-stated commitment. The account model, permissions, provisioning, revocation, and implementation evidence remain pending legal and security review. |
| Multi-factor authentication | Owner-stated commitment. Covered systems, enforcement method, recovery flow, and implementation evidence remain pending security review. |
| Device policies | Owner-stated commitment. Device standards, management tooling, storage rules, and implementation evidence remain pending security review. |
| Privacy and security training | Owner-stated commitment. Curriculum, cadence, completion records, and implementation evidence remain pending review. |
| Audit logs | Owner-stated commitment. Log sources, event coverage, retention, review cadence, and client visibility remain pending review. |
| Breach procedures | Owner-stated commitment. Escalation, containment, notification timing, roles, and implementation evidence remain pending legal and security review. |
| Access geography | Owner disclosure: the delivery team is based in Pakistan and works US business hours. Geographic and contractual risk must be reviewed before PHI is exchanged. |
These are commitments pending review, not certifications, attestations, or implementation evidence.
Why we publish no HIPAA-certified badge
HHS states that the Security Rule has no standard or implementation specification requiring a covered entity to certify compliance, and that HHS does not endorse or otherwise recognize private organizations’ certifications regarding the Security Rule. Dental Revenue Desk does not claim an HHS endorsement or certification. Its BAA-before-PHI policy and the commitments on this page remain pending legal and security review.
A badge is not a signed agreement, and it is the cheapest thing on a vendor's website to produce — which is why it is worth reading as a warning sign before you place the call: the compliance badge as a red flag you can spot on any vendor's website.
Where the team works — disclosed, not buried
Dental Revenue Desk's delivery team is remote and based in Pakistan, working US business hours. The owner states the security commitments in the table are intended to govern the service, but implementation evidence and the legal effect of the cross-border workflow remain review items before PHI is exchanged.
OCR, on ePHI held outside the United States, cautions that "outsourcing storage or other services for ePHI overseas may increase the risks and vulnerabilities to the information or present special considerations with respect to enforceability of privacy and security protections over the data." Dental Revenue Desk discloses its access geography so that risk is one your reviewer weighs rather than discovers: what HIPAA actually says about PHI accessed outside the United States. State law and your PMS vendor's agreement may add restrictions of their own; Dental Revenue Desk gives no legal advice and expects your reviewer to check both.
Breach response
Dental Revenue Desk’s owner commits to a breach-response procedure. The exact escalation, containment, reporting roles, notification timing, and implementation evidence remain pending legal and security review. HHS's Breach Notification Rule sets the floor: a business associate "must provide notice to the covered entity without unreasonable delay and no later than 60 days from the discovery of the breach." That is an external legal outer limit, not a published Dental Revenue Desk response-time promise.
Two things we state plainly
Do not submit PHI through website forms. The forms are intended for practice and workflow details, and the website is not an approved PHI channel. Validation rejects obvious patient-data patterns, but it cannot prove that an address is a work email or that every otherwise allowed string is free of patient information. The privacy policy describes the form data and current controls.
An eligibility response does not guarantee payment.CMS states that "an eligibility response from a health plan does not guarantee that the health plan will reimburse the provider for health services when a claim is submitted." A Dental Revenue Desk breakdown reflects what the carrier reports; final adjudication rests with the payer.
Ending the engagement: terms still under review
Dental Revenue Desk has not published a verified access-revocation workflow, a deprovisioning deadline, or a statement about which party performs each termination step. Those details must be resolved in the reviewed operating and security documents.
Retention, return, destruction, and permitted-retention terms are also not yet published. HHS's sample business associate agreement provisions provide model language, but HHS expressly describes the sample as optional and it is not evidence of Dental Revenue Desk’s current contract. These terms require legal and security review before PHI is exchanged. The commercial terms that remain open are listed on the pricing page.
What to ask any verification vendor
If a verification vendor will create, receive, maintain, or transmit PHI on a practice’s behalf, get these questions answered in writing:
- Will you sign a BAA before any access is provisioned — including trials and pilots?
- Who exactly will access our system: named individuals, or shared logins?
- What modules do you need, and will you accept access scoped to only those?
- Is MFA required on every account that reaches our system?
- Where is the team physically located, and is that disclosed in writing?
- Will you identify every subcontractor or offshore staff member who handles our PHI, and are they bound by the same agreement?
- What device policy governs the machines used for our data?
- What privacy and security training does the team complete?
- What is the breach procedure, and where are notification obligations documented?
- How is access revoked when a team member leaves or the engagement ends?
- What happens to our patient data when the engagement ends — returned, destroyed, or retained?
- Do you carry cyber liability coverage, and will you name the limits in writing?
Dental Revenue Desk currently distinguishes owner-stated commitments from the questions that still require legal, security, or technical evidence. The commercial and operational half of the same review — turnaround, pricing, write-back, and exception handling — has its own list: the questions to ask a verification vendor before you sign.Request the BAA process →
Frequently asked questions
Do you sign a BAA before accessing our system?
Dental Revenue Desk’s owner states that the company will sign a business associate agreement before PHI is exchanged, including for a pilot. The legal entity, final form, and supporting security evidence remain pending legal and security review.
Where is your verification team located?
Dental Revenue Desk's owner states that the delivery team works remotely from Pakistan during US business hours. That geography is disclosed so the practice can include it in its risk analysis and review any contractual, state-law, or vendor restrictions before PHI is exchanged.
Who provisions access to our practice management system?
The public source material does not specify who provisions access, the account type, the permission set, or the revocation workflow. The owner commits to access controls, but implementation details and evidence remain pending review.
Can we see who accessed our system and when?
The owner commits to audit logs. The log source, event coverage, retention period, review cadence, and client visibility are not yet published and remain pending security review.
Should we send patient details through your website to get started?
Do not submit patient information through the website forms. They are intended for practice and workflow details, and the website is not an approved PHI channel. Validation rejects obvious patient-data patterns, but it cannot prove that an address is a work email or that every otherwise allowed string is free of patient information.
What happens to our patient data when the engagement ends?
Dental Revenue Desk has not yet published its retention, return, destruction, or access-revocation terms. Those provisions must be resolved in the legally reviewed BAA and operating documents before PHI is exchanged. HHS sample BAA language is a model, not evidence of Dental Revenue Desk’s current contract.
Are you HIPAA certified?
HHS states that the HIPAA Security Rule does not require covered entities to certify compliance and that HHS does not endorse or otherwise recognize private organizations’ Security Rule certifications. Dental Revenue Desk does not claim an HHS endorsement or certification. Its BAA-before-PHI policy and security commitments remain subject to legal and security review.
Bring your compliance reviewer to the call
Use the workflow review to discuss the proposed BAA, security evidence, access questions, and Pakistan delivery model. Do not submit patient information through the website or during a pre-BAA review.