Business Associate Agreement Policy

NovraScale does not sign Business Associate Agreements. We build the sites we run so that no protected health information reaches any system we operate. This page describes that architecture so your compliance officer can evaluate it. Whether NovraScale is a business associate of your practice is a determination you and your counsel make against your own workflows. It is not one we make for you.

1. The short version

A BAA is required whenever a vendor creates, receives, maintains, or transmits Protected Health Information (“PHI”) on behalf of a Covered Entity. We build healthcare engagements so that none of those four things happen on our side: every clinical path on the sites we run ends at a system the practice operates, never one we run. That is an architecture we can show you, not a legal conclusion we are asking you to take on trust.

2. What NovraScale handles

For the two healthcare practices whose sites we run, NovraScale operates these surfaces. None of them accept or store PHI:

• The public marketing website (homepage, about, services, location pages)
• On both of our live mental health builds, no form at all. Adult & Child Counseling and Psychiatric Center and New Leaf Mental Health each route every patient-initiated contact to a phone number or to the scheduling or patient platform the practice itself uses. Neither site has a form, an input field, or a user account
• Local SEO setup and Google Business Profile
• Hosting, security patches, SSL renewals, and uptime monitoring for the marketing site

We do not build web forms, lead tracking, or review-request outreach for a healthcare practice: each would put patient identities into a system we operate.

A free-text field on a healthcare practice’s website can receive clinical detail no matter how the field is labeled, and by the time it is submitted it has already been transmitted and stored. We cannot promise to intercept that. It is why the design we recommend for a covered entity is a site with no free-text field at all, and why every clinical path on the sites we run points at a system the practice operates.

3. What your BAA-covered systems handle

Everything clinical routes through systems you (the Covered Entity) own and operate, under your own BAAs with those vendors. Typical examples:

• Patient intake forms that ask about symptoms, medication, or insurance: hosted in your EHR or a BAA-covered intake platform (e.g. Jane, SimplePractice, IntakeQ, Healthie)
• Appointment scheduling that ties a patient identity to a clinical visit type: your EHR or a BAA-covered scheduler
• Patient communication (email, SMS, or portal messaging) through a BAA-covered platform (e.g. Spruce, OhMD, your EHR’s portal)
• Insurance verification, billing, claims, telehealth video
• Anything that creates, receives, maintains, or transmits PHI

The marketing site we run links out to those systems: for example, the “Book an Appointment” button on your homepage opens your BAA-covered scheduler. The handoff is intentional: PHI starts the moment a real patient identity meets clinical data, and that moment happens on your infrastructure, not ours.

4. Why we draw the line here

A BAA is not a checkbox; it is a binding agreement that puts real penalties in play and requires the signing vendor to operate under the HIPAA Security Rule. Most marketing work never touches PHI, and whether a BAA is needed turns on exactly that. Signing one anyway would mean promising safeguards our engagements are not built to carry, or quietly accepting risk neither side has priced in. Neither is acceptable.

5. What this means for a practice whose site we run

If a compliance officer at a practice whose site we run asks whether we sign a BAA, the answer is no, and the reason is the architecture above rather than a reluctance to engage with HIPAA. The engagements we run are designed to keep PHI cleanly on the practice’s side of the line, and Section 7 says what we do when a practice needs more than that.

Where a practice needs PHI to land on the site itself, for example a clinical assessment running on the public domain rather than in a patient portal, we are not the right vendor and we say so rather than building it.

6. Analytics and third-party tags

We run Google Analytics 4 on the sites we build. On a mental health practice, the tag replaces the condition name in the page address and title before anything is sent, so a visit to a page about a specific condition reaches Google as a generic condition page. Service pages, such as medication management, are reported under their own address. Google Signals is off, and where a practice links a Google Ads account, ads personalization is off on that link. We do not place Meta, TikTok, or LinkedIn tags on a healthcare practice’s site. Google will not sign a BAA with anyone, so the control is to send it nothing that names a condition.

7. When a practice needs more than this

Some practices want intake, patient messaging, or call answering running on the site itself. NovraScale does not take that work. We do not operate PHI-bearing surfaces, we do not execute Business Associate Agreements, and we do not quote an engagement that would require either. Clinical intake, patient messaging and anything else that carries PHI belongs in the practice’s own EHR, scheduling platform, or patient portal, under the practice’s own BAA with that vendor. Where a practice already runs those systems, we link to them. Where it does not, choosing one is the practice’s decision with its own counsel and vendor, not ours. That holds for the practices whose sites we already run: if one asks for work that would put PHI in our hands, we decline that work rather than sign.

What we will not do is run the architecture above and sign a BAA against it anyway. The BAA would be describing controls that are not there, and a BAA you cannot rely on is worse than not having one.

8. Questions

Compliance questions or requests for clarification: legal@novrascale.com.