Patient data deserves more care than a plugin gives it
We build and maintain the websites and applications around your practice, and we treat protected health information as the liability it is. We run the development team for a Phoenix clinic, so this is week-to-week work for us rather than a policy page.
What HIPAA actually asks of your website
Protected health information, usually shortened to PHI, is any health information tied to a person who can be identified. A name next to an appointment request counts. So does an email address on an intake form about a specific treatment.
Most brochure pages on a clinic website carry no PHI at all. The risk concentrates in a handful of places: forms, scheduling, patient portals, email, and anything that ships data to a third party. That is where the security rule asks for access controls, audit trails, encryption, and agreements with the vendors who touch it.
The practical version is simpler than the regulation sounds. Know where the data goes, keep the list of people and systems that can reach it short, and be able to show what happened after the fact.
What we do on a project that touches PHI
These are the controls we build in rather than add later, because retrofitting any of them means touching data you would rather not touch twice.
A data map before anything else
Every form, integration, analytics tag, and email route, written down with what it carries and where it lands. Most surprises show up in this step rather than in a breach.
Business associate agreements with the vendors that need them
If a service stores or transmits PHI for you, it needs a signed BAA. We help you work out which of your vendors qualify, and we will tell you plainly what we can and cannot sign ourselves.
Access controls with real roles
Named accounts instead of a shared login, permissions scoped to the job, and an offboarding step that actually removes access when someone leaves.
Audit logging you can answer questions with
Who viewed a record, who changed it, and when. Logs are only useful if somebody can read them under pressure, so we make them legible instead of exhaustive.
Encryption at rest and in transit
HTTPS everywhere, encrypted databases and backups, and no PHI sitting in a spreadsheet on somebody's laptop because it was faster that way.
Vendor selection with compliance in the criteria
When you are choosing a form tool, a scheduler, or a CRM, whether it will sign a BAA belongs in the comparison next to price and features. We run that evaluation with you.
What we are, and what we are not
We are the development team. We build systems that hold up to your compliance obligations, we raise what we find, and we take the handling seriously.
We are not your attorney, your compliance officer, or a certifying auditor. Nobody can sell you a HIPAA certification, because HIPAA does not have one. When a question is legal rather than technical, we say so and work with whoever advises you.
If we find something that looks like an exposure, we tell you and bring in your practice manager and compliance lead rather than quietly patching it. We have done that on a live engagement, including the in-person walkthrough afterward.
Development for a Phoenix clinic
Spectrum Medical Care serves LGBTQ+ patients, people living with HIV, and the communities around them. We run the development side of the practice.
Running the development team for a Phoenix healthcare clinic
Questions we get about this
- Do you work with protected health information?
-
We work on the systems around it, and we take the handling seriously. We review how your hosting, forms, analytics, and integrations move information, and we raise anything that looks like exposure with your practice manager and compliance lead rather than quietly patching it.
If your setup requires a business associate agreement, raise it in the consultation and we will tell you plainly what we can and cannot sign.
- Will you sign a business associate agreement?
-
It depends on what the engagement involves, and we will give you a straight answer before you sign anything. If our work means we store, transmit, or routinely see protected health information, a business associate agreement is appropriate and we will talk it through with you and your compliance lead.
Plenty of engagements do not require one, because the work never touches PHI. We would rather scope it that way when we can.
- Is my whole website covered by HIPAA?
-
Usually not. Your public marketing pages, service descriptions, and staff bios carry no protected health information and are not covered.
The obligations attach where identifiable health information shows up: intake and appointment forms, patient portals, scheduling, chat, email, and any third-party tag that can see those pages along with something identifying the visitor. That is where we concentrate the work.
- Can we run Google Analytics or ad pixels on a healthcare site?
-
Carefully, and not everywhere. The risk is not analytics itself. It is a tag on a page about a specific condition or treatment sending the page address to a third party alongside an identifier for the visitor.
We audit your tag setup, restrict tracking on the pages where that combination is possible, turn off features that collect more than you need, and document what is left. If a vendor will not sign a business associate agreement, it does not get to see those pages.
- What platforms do you support?
-
All of them, in the sense that we've worked across most major and a lot of niche ones. We're most experienced with WordPress, Shopify, and custom Ruby on Rails applications. If your stack is something we haven't worked in before, we'll tell you that on the consultation, and we'll be honest about whether we're the right fit.
Want a read on where your patient data actually goes?
Bring your site, your forms, and the list of tools your front desk uses. In a free consultation we can usually tell you which of them touch PHI and which two or three things we would change first.
If the answer is that you need a compliance specialist rather than a development team, we will say that.