Digital health founders
Startups that need HIPAA-ready architecture before their first health system customer.
HIPAA Compliant Software Development
HIPAA compliant software development
Most HIPAA problems start in the architecture: PHI copied into logs, test databases or vendors nobody signed a BAA with. Agnotic Technologies builds healthcare software with PHI data flows, access control, audit logs, encryption and BAAs designed in from the first sprint.
PHI data flowsAudit loggingEncryptionBAAs in place
Trusted by global innovators
What is HIPAA compliant software development?
HIPAA compliant software development is building healthcare software so that protected health information is only collected, stored, shared and logged in ways the HIPAA Privacy and Security Rules allow. Agnotic Technologies maps every PHI data flow, then builds access control, audit logs, encryption and vendor BAAs into the product from the first release.
There is no official HIPAA certification for software. Compliance is an ongoing duty of the covered entity and its business associates, so we build the controls and evidence your teams need. For the rules themselves, see our guide to HIPAA requirements for software teams.
What does a HIPAA-ready architecture show your reviewers?
A map of where PHI goes, who can access it, what is logged and which vendors hold a BAA: the evidence a hospital security review or an auditor asks for.
What do we build into a HIPAA-ready product?
Controls built as features, so they work in production and produce evidence for reviews.
PHI data flow map
Every place PHI is collected, stored, sent and logged, kept current as the product changes.
Access control
Roles, least-privilege access, single sign-on and multi-factor authentication.
Audit logging
Who viewed or changed which record and when, stored so it cannot be quietly edited.
Encryption
TLS in transit and encryption at rest, with keys managed in your cloud's key service.
Safe environments
Synthetic or de-identified data in development and test, so PHI stays in production.
Breach readiness
Monitoring, alerting and an incident runbook that supports your breach notification duties.
Who it is for
Who builds HIPAA compliant software with us?
Most of our HIPAA work is for one of these teams.
Telehealth and RPM products
Products that handle video, messages and device data with PHI.
Teams fixing an existing product
Products that grew fast and now face a security review or audit.
AI healthcare products
Teams adding AI features that must handle PHI safely.
Vendors and BAAs
Which cloud and AI vendors need a BAA?
Any vendor that creates, receives, maintains or transmits PHI for you is a business associate. These are the ones we check first.
- Cloud hosting: AWS, Google Cloud and Microsoft Azure each offer a BAA that covers their HIPAA-eligible services only, so we build on those services
- LLM and AI providers: some offer a BAA for specific products and plans; no PHI is sent to a model until one is signed
- Email, SMS and video vendors that carry appointment details or messages
- Analytics, logging and error tracking tools, which often collect PHI by accident
- Support and ticketing tools where staff may paste patient details
- Backup and disaster recovery services
Reference architecture
What does a HIPAA-ready cloud architecture look like?
The layout we start from on AWS, Google Cloud or Azure, adjusted to your product.
Users
- Patients
- Clinicians
- Admin staff
Identity
- Single sign-on
- Multi-factor authentication
- Role-based access
Application
- API with access checks
- PHI minimized per feature
- Audit logging
Data
- Encrypted database and storage
- Managed keys
- Backups under the BAA
Vendors
- HIPAA-eligible cloud services
- AI providers under a BAA
- No PHI in analytics
Compliance-First Healthcare App Development Services Backed by Global Standards
01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Rules that apply
Which rules apply to HIPAA compliant software?
Agnotic claims no certification. We build so your product can meet these rules and pass your reviews.
| Rule | Who sets it | What it means for the build |
|---|---|---|
| HIPAA Security Rule | HHS | Administrative, physical and technical safeguards for ePHI |
| HIPAA Privacy Rule | HHS | Use and disclosure limits, and the minimum necessary standard |
| Business Associate Agreement | HHS (HIPAA) | A signed BAA with Agnotic and with every vendor that touches PHI |
| Breach Notification Rule | HHS | Detection, logging and an incident process that supports notification |
| Interoperability and information blocking | ONC (ASTP) and CMS | Data exchange through standard APIs such as HL7 FHIR, published by HL7 International |
Partner checklist
What should you ask a development partner about PHI access?
Ask a development partner five things before it touches PHI: when the BAA is signed, which engineers get access, whether PHI reaches non-production systems, how access ends at offboarding, and how fast it reports a breach. Clear answers mark HIPAA-ready delivery.
Is the BAA signed before any PHI access?
A good answer is yes, with no exception for a quick look at production. 45 CFR 164.504(e) lists what the agreement must commit the vendor to, including reporting security incidents, passing the same terms to subcontractors and returning or destroying PHI when the contract ends.
Which named engineers get access, and to what?
Ask for the list of people who will touch PHI and the role each one holds. Access should follow least privilege and the minimum necessary standard in 45 CFR 164.502(b): an engineer fixing one report does not need the whole patient table.
Does PHI ever reach development, test or laptops?
It should not. Development and test run on synthetic or de-identified data, and nobody copies production records to debug an issue. Ask the partner how it reproduces a production bug without PHI.
How is access removed when someone leaves the project?
The HIPAA Security Rule asks for procedures that end access to ePHI when a workforce member's arrangement ends (45 CFR 164.308(a)(3)(ii)(C)). Expect a same-day routine: accounts disabled, keys and tokens rotated, and the removal logged.
What happens if the partner finds a breach?
A business associate must tell the covered entity without unreasonable delay and no later than 60 calendar days after discovery (45 CFR 164.410). Ask who on their side makes that call, how they detect an incident and what the notice will contain.
Scope and effort
What drives the scope, timeline and cost of HIPAA compliant development?
We do not quote before we understand these.
How much PHI
The more PHI a product handles, and the more places it goes, the more controls and testing it needs.
Integrations
Each EHR, lab, payer and vendor connection adds a data flow to secure and a BAA to check.
Existing product
Adding controls to a product already in use takes more work than building them in from the start.
AI features
AI that sees PHI needs BAA-covered providers, logging and review steps.
Security reviews
The depth of your customers' security questionnaires and audits.
Security Rule safeguards
Which HIPAA safeguards become engineering tasks?
The Security Rule groups its requirements into administrative, physical and technical safeguards. These are the ones that turn into work in the code and the cloud.
| Safeguard | What the rule asks for | What we build |
|---|---|---|
| Access control | Unique user IDs and access limited to what each role needs | Role-based access, single sign-on, session timeouts and emergency access procedures |
| Audit controls | Record and examine activity in systems that contain ePHI | An audit log of every PHI read and write, exportable to your security tools |
| Integrity | Protect ePHI from improper change or destruction | Validation, versioning and checks that records were not altered |
| Authentication | Verify that a person is who they claim to be | Multi-factor authentication and secure credential handling |
| Transmission security | Guard ePHI sent over networks | TLS everywhere, with encryption at rest using managed keys |
| Risk analysis | Assess risks to ePHI and manage them | Threat modeling, a PHI inventory and fixes tracked to closure |
Facts and sources
Which rules and facts shape HIPAA compliant development?
Short facts we design around, each linked to its primary source.
The HIPAA Security Rule requires administrative, physical and technical safeguards for electronic protected health information.
Source: 45 CFR Part 164 Subpart C (eCFR)A HIPAA covered entity may share protected health information with a business associate, such as a software vendor, only under a business associate agreement that commits the vendor to safeguard it.
Source: 45 CFR 164.502(e) and 164.504(e) (eCFR)The HIPAA Security Rule requires an accurate and thorough risk analysis of the potential risks and vulnerabilities to the confidentiality, integrity and availability of ePHI.
Source: 45 CFR 164.308(a)(1)(ii)(A) (eCFR)The HIPAA Breach Notification Rule requires covered entities to notify affected individuals of breaches of unsecured protected health information, and business associates to notify the covered entity.
Source: 45 CFR Part 164 Subpart D (eCFR)
Frequently Asked Questions
No. HHS does not recognize any private HIPAA certification. Compliance is the ongoing responsibility of the covered entity and its business associates; we build the controls and the evidence that show how the product meets the rules.
AWS, Google Cloud and Microsoft Azure each publish a list of services covered by their BAA. We build PHI workloads only on those services, under a signed BAA, and keep PHI out of everything else.
Yes, if the AI vendor will receive PHI. Some AI providers offer a BAA for specific products and plans. Until one is signed, we keep PHI away from the model, for example by de-identifying data first.
Yes. Agnotic signs a business associate agreement before any PHI is shared with our team, and we keep PHI out of development and test environments.