Secure intake forms, patient-facing portals, and custom web applications designed with HIPAA considerations from the first line of code — not bolted on afterward. The focus is practical: minimum-necessary data collection, access control, encryption decisions, logging, vendor and BAA review, and documentation your Privacy or Security Officer can evaluate.
How I think about this work — and where the shortcuts quietly live.
Many web vendors are comfortable saying “HIPAA-compliant.” Fewer are careful about what that should mean at the web-system level: where PHI enters, where it is stored, what gets logged, who can access it, which vendors are involved, and what your Privacy or Security Officer would need to verify later. HIPAA is broader than code, but code can either support the program or quietly undermine it.
I am a webmaster and web developer, not a HIPAA law firm or full compliance department. I do not produce your Notice of Privacy Practices, train your clinical staff, or own your enterprise risk analysis. What I do is build and maintain the web-facing components — intake forms, portals, API integrations, dashboards, and internal tools — with the safeguards that belong in those layers, documented in ways your Privacy and Security Officers can review.
The work is grounded in practical principles learned from building and maintaining systems that may touch sensitive health-related data. Collect only the minimum necessary data. Avoid PHI in logs, emails, analytics, caches, and staging environments. Separate identifiers from payloads where feasible. Document what happened, who had access, and which vendors were in the chain, so your compliance team has something concrete to evaluate.
This page describes how I approach the technical web components of a HIPAA-covered or HIPAA-adjacent system. It is not legal advice, does not describe every HIPAA obligation, and does not replace your Privacy Officer, Security Officer, HIPAA consultant, or counsel. My role is to make the web layer safer, clearer, and easier for those people to review.
Replacement for paper intake, PDF-by-email workflows, or generic form builders that are not appropriate for PHI. HIPAA-aware from day one: scoped data collection, access-controlled retrieval, careful storage choices, logging, and a clean handoff to your EHR or clinical workflow where appropriate.
Portals for patients, members, or program participants — with role-based access, secure messaging where appropriate, document exchange, and an admin interface designed to reduce unnecessary PHI exposure. Built with session safeguards, logging, and reviewable access patterns from the start.
Purpose-built web applications for internal and external use — scheduling, reporting, intake routing, care coordination tools, and integrations with EHR-adjacent systems. Architected for minimum-necessary data flow, documented for compliance review, and maintainable by your team.
For organizations that already have web systems touching PHI and want a clear technical read on the web layer. I review forms, portals, APIs, third-party components, hosting, logs, caching, and vendor chain, then produce prioritized findings your Security Officer or compliance lead can evaluate.
Technical safeguards I can implement directly, plus operational documentation your compliance team can own.
I do not conduct your HIPAA risk analysis, author your Notice of Privacy Practices, train your clinical staff, or provide legal advice on HIPAA. These are distinct functions that belong to a HIPAA consultant, your Privacy Officer, and your counsel respectively. I coordinate with those roles; I don’t replace them.
When I sign, what that means in practice, and what it doesn’t mean.
A Business Associate Agreement is commonly required under HIPAA when a vendor creates, receives, maintains, or transmits Protected Health Information on behalf of a Covered Entity or another Business Associate. For web systems where my role involves PHI access or handling, I sign a BAA as part of the engagement setup before PHI is exchanged.
A BAA is not a checkbox. It defines obligations around safeguards, permitted uses and disclosures, breach notification, and subcontractors. The contract matters, but it does not make a system compliant by itself. The system design, hosting choices, access patterns, workforce practices, and client-side policies still have to match the risk.
| I sign a BAA when | The engagement involves access to, processing of, transmission of, or storage of Protected Health Information as part of the system being built or maintained — even if that access is indirect (e.g., database administration, log review, debugging production issues). |
|---|---|
| A BAA is not required when | The engagement is purely on non-PHI surfaces — a marketing website, a public-facing informational resource, an analytics tool on non-PHI pages. I will tell you plainly which category an engagement falls into. |
| Vendor BAAs I support | I prefer infrastructure and application vendors that offer reviewable BAA terms for the services actually being used. Vendor availability and contract coverage are confirmed during scoping rather than assumed from marketing language. |
| Your BAA template or mine | Happy to execute on your template subject to reasonable review. If you don’t have one yet, we can work from a standard template as a starting point — but your counsel should review it before execution. |
Rough shape for a new HIPAA-aware build or portal project. Timelines vary with scope.
I meet with your Privacy Officer, Security Officer, and operational owners to understand the workflow, the data involved, and the regulatory context. We identify what’s PHI, what isn’t, and what belongs at the edges versus the center of the system. Fixed-fee proposal and draft BAA follow within a few business days.
Data flows, trust boundaries, access controls, audit-logging strategy, vendor and BAA chain, environment topology. Produced as a document your Security Officer can sign off on before any code is written.
Build proceeds in reviewable increments, with security and accessibility checks at each checkpoint. PHI does not touch staging, development, or test datasets. You review progress on real milestones rather than at a single end-of-project handoff.
Final security review (headers, CSP, auth flows, audit log verification, vendor posture), accessibility audit against WCAG 2.2 AA, and a go/no-go conversation with your Security Officer.
Documentation package, admin training, and — optionally — a retainer for ongoing updates, monitoring, and the steady patching cadence that a HIPAA-aware system requires to stay that way.
Yes, for engagements that involve PHI. I’ll execute your template subject to reasonable review, and I’m happy to offer a standard template as a starting point if you don’t have one. Engagements that don’t involve PHI (e.g., marketing site work) generally don’t require a BAA, and I’ll tell you clearly which category yours falls into.
Yes — and this is a common engagement. Generic form builders (most of them) aren’t HIPAA-aware and will not sign a BAA, which means using them for any flow that collects PHI is a compliance problem and a legal exposure. I build purpose-built intake forms on infrastructure that can sign a BAA, with your existing branding and workflow integrations preserved.
I default to infrastructure that offers BAAs and a mature HIPAA-aware posture — commonly AWS or Google Cloud, with specific services selected for their eligibility. I can work within your existing cloud environment if you already have one configured for HIPAA, and I’ll flag components that don’t belong in that environment.
Usually, yes — depending on what your EHR exposes. Most modern EHRs offer FHIR or proprietary APIs that I can integrate against; some have limited APIs that constrain what’s possible. I assess this early in discovery and will be honest about what a clean integration looks like versus what would require an awkward workaround. I do not market myself as an EHR specialist, but I have done EHR-adjacent integration work.
No. A HIPAA risk analysis is a broader organizational exercise that properly belongs to a HIPAA consultant working with your Privacy and Security Officers. I scope the web-system portion, document what I’ve built, and coordinate with whoever is leading the broader risk analysis. If you don’t currently have someone in that role, I can make introductions to practitioners I’ve worked alongside.
I don’t put PHI in development, staging, or test environments — ever. Development environments use synthetic data; staging environments, if they exist, are likewise populated with non-PHI fixtures. Production PHI stays in production, access is controlled and logged, and debugging flows are designed around not needing PHI to reproduce most issues.
Two paths: continue on a maintenance retainer, which covers security patching, dependency updates, and the steady operational care a HIPAA-aware system needs — or take handover and run it internally. In either case, the system is documented for your Security Officer, and the admin interface is designed for someone other than me to operate it.
Whether you’re replacing an insecure intake form, building a patient portal, integrating with an EHR, or assessing what you already have — a 30-minute conversation is the cleanest way to tell whether we’re the right fit.
I respect the confidentiality of anything you describe on a first call; a BAA isn’t required for a discovery conversation, since discovery calls don’t involve PHI.
I’ll send a short set of questions beforehand so the call is useful from the first minute.
