HIPAA compliant software development company
We build and harden healthcare software that handles protected health information: patient and clinician apps, APIs, AI features and data pipelines. Every Security Rule safeguard is designed in and tested, from access control, MFA and audit logs to encryption, backups and BAA-covered hosting. You receive the evidence your security review, your auditors and your customers' vendor questionnaires ask for.
Review your HIPAA safeguardsFor US health tech startups, digital health companies, providers and payers building or hardening software that stores, processes or transmits ePHI. Updated September 26, 2026.
Minimum necessary data, consent and approved input paths
MFA, role-based permissions, tenant isolation and break-the-glass review
Encryption at rest and in transit on BAA-covered services only
Tamper-evident audit logs, tested backups and incident runbooks
Illustrative workflow · scope tailored to your environment
The short answer
Software supports HIPAA compliance when it implements the Security Rule's technical safeguards (access control, audit controls, integrity, person or entity authentication and transmission security) everywhere ePHI is stored, processed or sent. It must run only on services covered by a Business Associate Agreement, and be operated under the administrative and physical safeguards of the organization that owns it. HHS does not certify software; compliance is shown through a documented risk analysis, implemented controls and evidence that they work.
Read our HIPAA checklist for developersStart with the real problem
Teams encrypt the database and still expose PHI: patient names in error-tracker payloads, diagnosis codes in analytics events and tracking pixels, full records in application logs, production data copied to staging, lab values in push notifications and email, and chart text sent to an AI API that has no BAA. We map every path PHI takes through the product and its surrounding tools, then close each one with a control and a test.
What we build
Each product type exposes PHI in different places. We design the safeguards around where the data actually goes.
Mobile and web apps for intake, messaging, records, video visits and remote care, where PHI sits on personal devices and passes through notifications.
Telemedicine app developmentWorkspaces and SMART on FHIR apps that read and write clinical data inside hospital and practice systems.
Custom EHR developmentPlatforms that collect readings from Bluetooth and cellular devices and turn them into clinician alerts and billable data.
Remote patient monitoring softwareFHIR, HL7 v2 and X12 interfaces that move PHI between your product, EHRs, labs, payers and partners.
FHIR integration servicesDocumentation drafting, summarization and triage that send clinical text to language models.
Healthcare AI solutionsPipelines, warehouses and analytics that combine PHI from many sources.
Healthcare data engineeringYour starting point
You are starting a healthcare product and want the safeguards designed in rather than retrofitted. We map the PHI boundary and access model before the first sprint.
Your team built a prototype, often with an AI app builder or low-code tool, and now needs real patients on it. We add authentication, MFA, encryption, audit logging and BAA-covered hosting, and fix what the prototype skipped.
A health system or payer sent a vendor security questionnaire or requires a review before go-live. We close the engineering gaps and assemble the evidence the reviewer asks for.
The Engineering Engagement
Workstreams are selected around your priorities. Each comes with an output your team can inspect, test and own.
Inventory every place ePHI enters, is stored, is processed and leaves the product, including logs, queues, backups, analytics and support tools, and rate the risks as the Security Rule's risk analysis requires.
Multi-factor authentication, role- and attribute-based permissions, tenant isolation, unique user IDs, automatic logoff, emergency access with after-the-fact review, and tested revocation.
TLS 1.2 or higher in transit, AES-256 encryption at rest for databases, files, backups and queues, keys in a managed KMS with rotation, and secrets out of code and CI logs.
Record who viewed, created, changed, exported or deleted which record and when, in tamper-evident storage with access restricted to reviewers, plus alerting on unusual access.
Scrub PHI from logs, traces, error reports and analytics; keep tracking technologies off authenticated pages; and use only vendors that sign a BAA for any service that touches PHI.
Deploy on HIPAA-eligible AWS, Azure or Google Cloud services under a BAA, with network segmentation, hardened images and every environment defined in Terraform or equivalent.
Encrypted backups with tested restores, a contingency plan, dependency and code scanning in CI, and support for your penetration tests.
Compare your options
Where you add the safeguards decides what they cost and how convincing the evidence is.
| Safeguards built in | Retrofit before launch | Compliance tool only | |
|---|---|---|---|
| What it covers | Product, infrastructure and the tools around them | Gaps found late in an existing codebase | Policies, training and questionnaires, not the code |
| Audit logging and access control | Designed into the data model and APIs | Added around existing endpoints; gaps are common | Not implemented by the tool |
| PHI in logs, analytics and AI calls | Blocked by design and tested | Found and scrubbed case by case | Not detected |
| Evidence for security reviews | Produced by the pipeline as you build | Assembled under deadline | Documents without technical proof |
| Cost shape | Part of normal delivery | Rework and delayed launch | Subscription plus the engineering gaps it cannot close |
A compliance platform helps run the program; the product itself still needs engineered safeguards. We often connect both.
Expertise is in the decisions
Decide which services, stores and vendors may ever hold PHI, and keep everything else outside that boundary by design. A smaller boundary means fewer BAAs, fewer controls to evidence and a faster security review.
Prove that a wrong tenant, an expired session, a revoked user or an unapproved export is blocked, with automated tests. A successful login demo is not an access-control test.
HHS proposed in January 2025 to make encryption, multi-factor authentication, asset inventories and regular vulnerability scanning required rather than addressable. We build to that standard now so a final rule does not force rework.
The software carries the technical safeguards. Your organization owns the administrative program: risk management decisions, workforce training, policies, sanctions and contracts. We document which control sits where, so nothing falls between the two.
AWS, Azure and Google Cloud sign a BAA covering only their HIPAA-eligible services, configured by you. We keep PHI inside that list and configure each service to the safeguards it needs.
Timeline
Designing safeguards into a new product adds little to the schedule. Hardening an existing product depends on what the audit finds.
Map PHI flows, rate risks and design the security architecture.
Implement access, encryption, logging and infrastructure controls with tests.
Configuration scans, restore tests, redaction tests and support for penetration testing.
Production release on BAA-covered services, monitoring and incident runbooks.
Delivered work
Client names are withheld; each is a real engagement. Our open-source work is public on GitHub.
Audited and closed inherited security gaps in an app that had passed through several vendors before any new feature shipped, then kept releasing provider records and wearable data to the app stores.
Recording is refused without consent on file, audio is transcribed and only the text reaches the language model, and every clinician decision on a draft is audited.
Patient-reported outcomes captured on a body map, gap-recovering health-data sync and a clinician view of weeks of outcomes,.
Every value on a case report form traces to a person, a time and a reason under an audit trail that cannot be edited, with consent tracked per participant.
A headless EHR with SMART App Launch and Da Vinci CRD, DTR and PAS servers, with OAuth scopes and token handling in public code you can review.
From discussion to delivery
Data flows, vendors, BAAs and the split between product and organizational controls.
Security architecture and safeguard backlog reviewed with your security lead.
Controls implemented with automated tests for both allowed and denied access.
Configuration evidence, test results, runbooks and open risks with named owners.
We agree the scope, dependencies, acceptance criteria and commercial model before implementation. Your existing team can stay involved throughout.
Find the right starting point ↗Before you commit
Software supports HIPAA compliance when it implements the Security Rule's technical safeguards (access control, audit controls, integrity, authentication and transmission security) for all ePHI, runs only on BAA-covered services, and is operated under the owning organization's administrative and physical safeguards, backed by a documented risk analysis.
No. HHS does not certify software or vendors for HIPAA. Compliance is demonstrated through a risk analysis, implemented safeguards, policies and evidence. We sign BAAs, we are ISO 27001:2022 certified, and we deliver the technical evidence your reviewers and auditors ask for.
Yes. We sign BAAs with covered entities and business associates, and we host PHI only on cloud services covered by a BAA with you or with us.
Cost depends on the product's size, the number of PHI flows and third-party services, the integrations, and whether we are building new or hardening an existing codebase. We give a fixed-scope estimate after a short discovery, with safeguards broken out so you can see what each one costs.
Only services your cloud provider lists as HIPAA eligible and covers under its BAA with you. AWS, Microsoft Azure and Google Cloud each publish that list. We keep PHI on eligible services and configure each for encryption, logging and access control.
Yes. Prototypes built quickly or with AI app builders usually lack MFA, audit logging, encryption settings, tenant isolation and BAA-covered hosting. We audit the code, fix or rebuild the parts that handle PHI and move it to a production environment with the evidence to show for it.
Who accessed which patient's data, what they did (view, create, update, export, delete), when, from where, and the outcome. Logs must be protected from alteration, readable only by authorized reviewers and reviewed regularly. HIPAA requires related documentation to be kept for six years.
Under the current Security Rule encryption is an addressable specification, and HHS proposed in January 2025 to make it required. In practice we encrypt all ePHI at rest and in transit, because properly encrypted data also falls outside the breach notification requirement if it is lost.
Only with vendors that sign a BAA for the specific service, or after PHI is removed. HHS guidance warns that tracking technologies on authenticated pages can disclose PHI. We scrub PHI from telemetry, keep trackers off authenticated pages and route AI calls through BAA-covered model endpoints.
We use your identity provider or a managed service for MFA, assign permissions by role and attribute, isolate tenants at the data layer, set automatic logoff, provide emergency access with after-the-fact review, and test every denied path in CI.
Yes. We close the engineering gaps the questionnaire exposes, produce the architecture and data-flow diagrams, encryption and access evidence, and the answers reviewers look for, including for EHR vendor app reviews.
HIPAA applies when you are a covered entity or handle PHI on behalf of one as a business associate. Direct-to-consumer apps outside that relationship fall under the FTC Health Breach Notification Rule and state laws such as Washington's My Health My Data Act. We design for the rules that apply to your model.
A useful first conversation
Tell us what exists today, who uses it and where the workflow breaks. We’ll discuss the scope, access dependencies and the next practical step.
A product overview and a de-identified workflow are enough to start. No patient records or credentials are needed.
These are independent reference sources, not endorsements. Applicability, platform access and current requirements are confirmed for your project.
