Web Development Practices

What are web development practices?

Web development practices are the repeatable methods a team uses to build and operate web applications well: version control and code review, automated testing, security controls, accessibility checks, performance budgets, continuous delivery and monitoring. Healthcare web development practices add HIPAA safeguards, consent and tracking controls, and accessibility to a legal standard on top of the general set.

Where healthcare changes the defaults

• Data: A contact form or appointment request can contain PHI, so the same safeguards apply to the website as to the portal.
• Third parties: Analytics, chat widgets and ad pixels are vendors that may receive identifiable data.
• Users: Patients in pain, on old phones, with low vision or low literacy, and clinicians between patients.
• Downtime: A booking site that is down costs visits. A clinical web app that is down costs safety.
• Audit: Someone will ask who saw which record and when, and the logs must answer.

Why do web development practices matter now?

• Technical safeguards are law: The HIPAA Security Rule's technical safeguards at 45 CFR 164.312 require access control, audit controls, integrity protection, person or entity authentication and transmission security for systems holding ePHI.
• Tracking tools are under scrutiny: HHS OCR issued a bulletin on online tracking technologies in December 2022 and revised it in March 2024. In June 2024 a federal court in Texas vacated part of it, and HHS withdrew its appeal in August 2024, so pixels on health pages remain a risk-based decision rather than a settled rule.
• Accessibility has deadlines: The HHS Section 504 rule adopts WCAG 2.1 Level AA for the web content and mobile apps of recipients of HHS funding. A May 2026 interim final rule moved the compliance dates to May 11, 2027 for recipients with 15 or more employees and May 10, 2028 for smaller ones.
• Password rules changed: NIST SP 800-63B-4 (July 2025) requires passwords used alone to be at least 15 characters, forbids forced periodic changes and requires new passwords to be checked against a blocklist of common and compromised passwords.
• The threat list was updated: The OWASP Top 10:2025 adds Software Supply Chain Failures and Mishandling of Exceptional Conditions, and keeps Broken Access Control at number one.
• Speed is measured: Google's Core Web Vitals rate a page good at the 75th percentile when Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less and Cumulative Layout Shift is 0.1 or less.

Which practices belong in a healthcare web project?

The diagram groups the practices into six areas and shows where each is checked in the delivery pipeline. Every area has a healthcare-specific rule next to the general one.

• Code and review: Version control, small pull requests, a second reviewer for anything touching PHI or authentication, and no secrets in the repository.
• Security: Encryption in transit and at rest, role-based access, short sessions with re-authentication, dependency scanning, a software bill of materials and regular penetration tests.
• Privacy: A data inventory for every form and script, consent before non-essential tags, and no PHI in URLs, logs, analytics events or error reports.
• Accessibility: WCAG 2.1 AA as the legal floor and WCAG 2.2 as the engineering target, checked by automated scans and by people using assistive technology.
• Performance: Core Web Vitals budgets in the build, images sized and compressed, and server rendering for content that must be found and read.
• Delivery and operations: Automated tests in a pipeline, staged releases, feature flags, monitoring with alerts, tested backups and a written incident plan.

How do teams apply web development practices step by step?

Teams apply web app development practices by setting the rules first and automating them into the pipeline, so every release is checked the same way. The order below is the one we follow on a new healthcare web project.

• 1. Inventory the data: List every page, form, script and integration and mark which ones touch PHI.
• 2. Set the standards: Write the team's security, privacy, accessibility and performance rules on one page and link them from the repository.
• 3. Automate the gates: Linting, unit and integration tests, dependency and secret scanning, accessibility checks and a performance budget run on every pull request.
• 4. Design with the users: Prototypes tested with patients and staff, including screen reader and keyboard users.
• 5. Build in thin slices: One journey, such as request an appointment, from form to EHR, before the next.
• 6. Harden before launch: Penetration test, tracking review, backup restore test and an on-call rota.
• 7. Measure in production: Real-user Core Web Vitals, error rates, audit log reviews and accessibility complaints.
• 8. Revisit quarterly: Dependencies, certificates, third-party scripts and the regulatory calendar.

Which practices matter most for patient-facing websites?

A practice website is the first system most patients touch, and its forms are often the first place PHI enters. The practices below stop the common leaks and keep the site usable for everyone.

• Treat forms as PHI intake: Encrypt, store in a controlled system, and never email form contents in plain text.
• Review every tag: Know what each analytics, chat and ad script collects and on which pages it runs. Keep them off authenticated pages.
• Publish accessible content: Headings in order, labels on inputs, captions on video and contrast that passes.
• Make booking fast: Server-rendered pages, few scripts and a booking flow that works on a slow phone.
• Keep location and provider data structured: Schema.org markup so search engines and assistants read it correctly.

Which practices matter most for clinical web apps?

Clinical web apps carry more PHI and sit inside busy workflows, so the practices shift from privacy on public pages to access control, logging and failure handling.

• Authenticate and authorize properly: Single sign-on where possible, role-based permissions and break-glass access that is logged and reviewed.
• Time out safely: Short idle timeouts that save work and hide PHI on shared workstations.
• Log every access: Who viewed or changed which record, when, and from where, kept tamper-evident.
• Integrate by standard: SMART on FHIR for launch inside the EHR, FHIR R4 for data, HL7 v2 only where the system offers nothing else.
• Fail visibly: If a result or order cannot be saved, say so immediately. Silent failure is a safety event.
• Test the slow path: Clinical users will open the app on a hospital network with filtering and old browsers.

What are web development practices best practices?

If the six areas above are the categories, these are the specific habits that make web development practices best practices in a healthcare team.

• Write the rules down: One page of security, privacy, accessibility and performance standards that every reviewer can point to.
• Automate what can be automated: Scanners, tests and budgets in the pipeline, so a human review is spent on judgment.
• Review tags like code: A third-party script needs the same approval as a dependency.
• Default to server rendering: Content that must be found, read and indexed is in the HTML, not loaded by script.
• Rehearse failure: Restore a backup, rotate a certificate and run the incident plan before the real event.
• Keep a regulatory calendar: Accessibility deadlines, security rule changes and vendor API retirements with an owner.

What are the common mistakes in healthcare web development?

• Pixels on the portal: Marketing tags added to authenticated pages, sending identifiers to ad platforms.
• PHI in the URL: Patient identifiers in query strings that end up in logs, browser history and analytics.
• Accessibility at the end: A scan before launch instead of design and testing throughout, so fixes are expensive.
• Password policy from 2010: Forced rotation and complexity rules that NIST now advises against.
• One environment: No staging tenant for the EHR integration, so the first real test is production.
• No restore test: Backups exist but nobody has restored one, which is the moment the contingency plan fails.
• Unowned dependencies: Libraries years out of date with no scanner and no one responsible.

What do web development practices mean for your build plan?

• Scope of PHI: A marketing site with a contact form needs less than a portal, but both need the privacy review.
• Accessibility target: WCAG 2.1 AA conformance work and ongoing testing, with the 2027 and 2028 dates in mind for funded entities.
• Integrations: Each EHR, scheduling or payment connection adds design, test tenants and monitoring.
• Security program: Penetration testing, dependency management and incident response are recurring costs, not one-off tasks.
• Pipeline investment: Automated gates cost time up front and save it on every release after.
• Operations: Monitoring, backups, certificate and dependency renewals and a named owner.

If the project is part of a wider plan, our healthcare software development guide covers how to scope and staff it, and our digital transformation guide covers the program around it.

How Agnotic can help

Agnotic Technologies is a software development services company. We build web software for specialty practices, management services organizations and digital health companies: patient-facing websites and portals, clinical web apps and the pipelines that keep them secure, accessible and fast. We work in your repositories and leave your team with practices they can keep.

Sources

• 45 CFR 164.312: HIPAA Security Rule technical safeguards
• HHS OCR: Use of online tracking technologies by HIPAA covered entities and business associates
• HHS: Section 504 final rule (45 CFR Part 84) fact sheet
• NIST SP 800-63B-4: Digital Identity Guidelines, Authentication and Authenticator Management
• OWASP Top 10:2025
• web.dev: How the Core Web Vitals thresholds were defined
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• HL7: SMART App Launch