In this article
"Is it HIPAA compliant?" is the first question most healthcare clients ask a development company, and the answer they usually get is "yes". That answer is misleading. HIPAA compliance is a property of an organisation and its processes, not a feature a developer can ship. What a development team can do is build software that makes compliance achievable and straightforward to demonstrate. This article separates the two, so you know what to expect from your engineers and what remains your responsibility.
What HIPAA requires, in outline
The Health Insurance Portability and Accountability Act applies to covered entities, such as providers and insurers, and to their business associates, which includes software vendors who handle protected health information on their behalf. Its Security Rule requires administrative, physical and technical safeguards for electronic PHI. The technical safeguards are where software comes in: access control, audit controls, integrity controls, authentication and transmission security. The administrative and physical safeguards are policies, training, risk assessments and facilities, and no codebase can supply them.
We are engineers, not lawyers. Nothing here is legal advice, and the final compliance determination always sits with your counsel and compliance officer.
What engineers can promise
Encryption everywhere PHI travels or rests
Transport encryption for every connection, including internal ones. Encryption at rest for databases, file storage and backups, with keys held in a managed key service rather than in configuration files. Device storage encrypted on mobile, with sensitive data cleared when a session ends.
Access control enforced where it cannot be bypassed
Role-based access defined once and enforced at the data layer, so that a bug in a screen or an API endpoint cannot expose records to the wrong user. Minimum-necessary access as the default, with elevated access granted explicitly and logged.
Audit logs that answer real questions
Every access to PHI recorded with who, what, when and from where, stored separately from application data, protected from modification, and retained for the period your policy requires. The test is whether the log can answer "who viewed this patient's record last Tuesday" without an engineer writing a query.
Authentication fit for the data
Multi-factor authentication for anyone with access to PHI, session timeouts, secure password handling, and integration with your identity provider where one exists. Biometric unlock on mobile is a convenience layer on top of this, not a replacement.
Integrity and availability
Backups that are tested by restoring them, not just by taking them. Versioned records where edits must be traceable. Infrastructure that can be rebuilt from code, so recovery is a procedure rather than an emergency.
Data minimisation by design
The most effective safeguard is not collecting PHI in the first place. Several health products we built work without any identifying data, which removes most of the compliance surface. We cover that approach in a separate article, and it is the first thing we discuss on any healthcare project.
Hosting that supports compliance
Major cloud providers will sign a business associate agreement and offer services configured for HIPAA workloads. We build on those services and document which ones are in use. The BAA itself is a contract between you and the provider, and signing it is your task, not ours.
What engineers cannot promise
- That your organisation is compliant. Compliance includes your policies, your staff training, your risk analysis and your incident response, none of which live in software.
- That a third-party service you integrate is compliant. Each one needs its own agreement, and some popular services will not sign one.
- That the product stays compliant without maintenance. Dependencies age, platforms change their rules, and a risk analysis is required periodically, not once.
- That a feature request is allowed. Exporting records to a spreadsheet, sending appointment details by SMS, or showing a patient's name in a push notification may each be a compliance problem. We flag these; your compliance officer decides.
How we work on healthcare projects
Discovery starts with the data inventory and the minimisation exercise. Architecture decisions are documented with the safeguard each one supports, which becomes the evidence your auditor will ask for. Security testing is part of QA rather than a final step. And we work alongside your compliance counsel from the start, so that review happens on designs rather than on finished code. The medical association networking platform and the community wellness app in our case studies were built this way.
Questions to ask any vendor
- Which technical safeguards will the software implement, and how will each be demonstrated?
- What PHI does the design collect, and what has been designed out?
- Where is the audit log stored, and who can modify it?
- Which cloud services are used, and will each sign a BAA?
- What is the maintenance plan after launch?
A vendor who answers these specifically is one you can work with. A vendor who answers "yes, it is HIPAA compliant" has not understood the question. Our healthcare software development page describes our approach, and we are happy to walk through it with your compliance team.