HIPAA Compliant Software Development: Apps, Portals and Platforms Built Around the Security Rule

Updated October 2026 · Written and maintained by the Progression Agency strategy team

HIPAA compliant software development is the design, build and operation of software that creates, receives, maintains or transmits protected health information in a way that meets the HIPAA Privacy, Security and Breach Notification Rules in 45 CFR Parts 160 and 164. It is for digital health founders, product teams at providers and health plans, and vendors selling software into healthcare, and it produces two things: a working web or mobile product, and the evidence a customer’s security review asks to see, from the risk analysis and audit logs to signed business associate agreements. Progression Agency is based in New York City and works with clients across the United States and worldwide.

What does HIPAA compliant software development cover?

It covers the product and the record around it: the code that handles health data, the cloud and vendor services that store and move that data, and the policies, contracts and logs that prove the safeguards exist. A feature list on its own never makes software compliant, because the rule is written for the organizations that run it.

Covered entities, business associates and subcontractors

HIPAA applies to covered entities (health plans, health care clearinghouses and health care providers that send health information electronically in connection with standard transactions such as claims) and to their business associates. Under the definition in 45 CFR 160.103, a business associate is a person that creates, receives, maintains or transmits protected health information on a covered entity’s behalf, and the definition expressly includes a subcontractor that does the same for a business associate. A software company that builds and runs a patient portal for a clinic is a business associate. The cloud host under that company is a subcontractor business associate. Each one owes the Security Rule’s safeguards.

What counts as protected health information inside an app?

Protected health information is individually identifiable health information held or sent by a covered entity or business associate, in any form or medium. In software that reaches well beyond a diagnosis field. A name, email address, phone number, device identifier or IP address becomes part of PHI once it is tied to a person’s care, condition or payment for care. HHS’s bulletin on tracking technologies uses the example of a clinic’s diabetes app: a glucose reading sent to an analytics vendor along with an IP address or device ID is a disclosure of PHI.

Is any software HIPAA certified?

There is no HHS certification program for HIPAA compliance, as Google Cloud and Microsoft both note on their HIPAA pages, and AWS says no HIPAA certification exists for a cloud provider. A “HIPAA certified” badge on a vendor’s site is not an HHS credential. Ask who issued it, what it covered and when. What a buyer can check is evidence: a current risk analysis, safeguards mapped to the rule, test results and a business associate agreement. We build the technical controls; certification against a private framework, if you want one, remains between you and your auditor.

Does my software need to be HIPAA compliant?

It does if the product handles protected health information for a covered entity, or for one of that entity’s business associates. It usually does not if consumers choose and use the app on their own, although other federal and state rules then take over.

The questions HHS asks about app developers

HHS’s Health App Use Scenarios and HIPAA asks who your clients are, who pays you, and whether a covered entity directs you to create, receive, maintain or disclose patient information. If a provider or health plan hires you to deliver a service through the app, you are a business associate. If a consumer selects the app independently, controls whether data goes to a provider and you have no relationship with that provider beyond an interoperability link, you generally are not, even when the data in the app came from a medical record.

One product, two versions

HHS describes a developer that offers the same records app to a health plan’s members and, separately, straight to consumers. The plan version is covered by HIPAA and the direct-to-consumer version is not, as long as the developer keeps the two sets of data apart. If you plan to sell into both markets, design that separation from the start: separate tenants or databases, separate analytics, and no shared marketing lists. Retrofitting it later means migrating live data under the stricter rule.

An interoperability link alone does not make you a business associate

An app that pulls a patient’s records from a provider at the patient’s request is serving the patient, not the provider. HHS says an interoperability arrangement that exists to support access the consumer starts does not, by itself, create a business associate relationship. The data in that app then sits outside HIPAA, which is why the FTC rule covered further down matters so much to consumer health products.

When the answer is unclear

Have counsel read the contracts and data flows, not the marketing description. The answer turns on facts: who signs the order, who receives the data and who decides what is collected. We classify each project during discovery and build to the rules that apply; nothing on this page is legal advice.

HIPAA compliance software development: the safeguards in 45 CFR Part 164

The Security Rule sets standards in three categories (administrative, physical and technical) plus organizational, policy and documentation requirements. Many standards carry implementation specifications marked Required or Addressable, and a software team touches nearly all of them.

Technical safeguards become product features

The technical safeguards in 45 CFR 164.312 read like a feature list once you translate them. They also explain the questions a hospital’s security team will ask during procurement, so building them in early shortens that review. The table below shows each standard and specification, its status in the rule today and where it lands in a product.

Administrative safeguards the product has to support

Risk analysis, risk management, a sanction policy and information system activity review are all Required under 45 CFR 164.308. Software is what makes the activity review possible: if the product cannot produce access reports, the customer cannot meet that standard. Workforce security and information access management need role-based permissions that can be granted, changed and removed quickly. Contingency planning makes a data backup plan, a disaster recovery plan and an emergency mode operation plan Required, which in a product means tested restores and a documented way to keep working during an outage.

Physical safeguards in a cloud product

Facility access, workstation use and device and media controls sound like office rules. In a cloud product the data center side passes to the hosting provider under its BAA, but plenty stays with you: the laptops and phones your team uses, disposal and re-use of any media that held ePHI (both Required specifications), and a record of where equipment holding ePHI goes.

Policies, documentation and six-year retention

Section 164.316 requires written policies and procedures, written records of every action, activity or assessment the Security Rule says to document, and retention of that documentation for six years from the date it was created or last in effect, whichever is later. Engineering records are part of that evidence: architecture decisions, each risk analysis, security incident records and test results all belong in a store you will still be able to search years from now.

Privacy Rule duties that reach the code

The Privacy Rule shapes features too. The minimum necessary standard means role-based screens that show each user only what the job needs. The right of access requires a covered entity to act on a patient’s request within 30 days, with one extension of up to 30 more, and to provide an electronic copy in the form requested when it is readily producible, so exports matter. Marketing communications that use PHI generally need the patient’s written authorization, which affects how promotional messages are built into an app.

Required, addressable and the proposed Security Rule update

Addressable never meant optional. Under 45 CFR 164.306(d), an addressable specification must be implemented if it is reasonable and appropriate; if it is not, the reasons must be documented and an equivalent alternative put in place where that is reasonable.

What HHS proposed in January 2025

HHS published a proposed rule to strengthen the Security Rule on January 6, 2025, with comments closing on March 7, 2025. It would remove the distinction between required and addressable specifications and, among other changes, require encryption of ePHI at rest and in transit with limited exceptions, multi-factor authentication, network segmentation, a written technology asset inventory and network map, vulnerability scans at least every six months, penetration testing at least every 12 months, procedures to restore critical systems and data within 72 hours, a compliance audit every 12 months, and written verification from business associates at least every 12 months that their technical safeguards are in place.

Where does the proposal stand?

As of October 13, 2026 it is still a proposal. The Federal Register shows no final rule, and the Security Rule sections in eCFR have not been amended since 2013. A final rule could differ from what was proposed, and under 45 CFR 160.105 covered entities and business associates generally have 180 days from a new standard’s effective date to comply.

Building for the proposal now

Most of the proposed items are ordinary good practice, and several cost far less to design in than to retrofit. The security defaults on our healthcare app development page already cover several of them: multi-factor sign-in on top of role-based access, encryption for data both stored and moving, logs of who opened health records, and a penetration test plus dependency scans before release. An asset inventory and network map are cheap to keep when the infrastructure is defined in code from the first sprint.

HIPAA compliance checklist for software development

Use the lists below as a working checklist, phase by phase. They are written for product owners and engineering leads, and each item traces back to a requirement in the rule or to guidance HHS has published. HIPAA compliance for software development is easier to keep than to recover, so the list starts before the first sprint.

Before the first sprint

Most expensive mistakes are made before any code exists, in the choice of vendors, hosting and data model. Settle these first.

• Decide whether HIPAA applies, using HHS’s app scenarios and the contracts you expect to sign.
• Map every place PHI enters, rests and leaves: forms, APIs, logs, backups, analytics, support tools, email and text messages.
• Run and document a risk analysis of every system that touches ePHI, as 45 CFR 164.308(a)(1)(ii)(A) requires.
• List every vendor that will touch PHI and confirm each one signs a BAA for the specific service you plan to use.
• Choose hosting services covered by your cloud provider’s BAA, in an account your organization owns.
• Name a security official, as 164.308(a)(2) requires, and decide who approves access.
• Write the retention and deletion rules before designing the database.
• Keep real patient data out of development and test environments; use synthetic or properly de-identified data.

During the build

Each sprint should leave the product as defensible as it is functional. These items belong in the definition of done.

• Role-based access with least privilege and one identity per person.
• Multi-factor authentication for staff and administrator accounts.
• TLS on every connection, including internal service traffic and webhooks.
• Encryption at rest for databases, file storage, backups and device storage, with keys managed apart from the data.
• Audit records of access, changes and exports, protected from editing and reviewed on a schedule.
• No PHI in application logs, error trackers, URLs, push notification text or analytics events.
• Session timeouts, and a fresh sign-in before sensitive actions such as exports.
• Code review, dependency scanning and secret scanning in the delivery pipeline.

Software HIPAA compliance checklist for the release gate

Nothing ships to real patients until each of these is done and recorded.

• A security test or penetration test completed, with findings fixed or accepted in writing.
• Backups restored in a test, not just taken.
• Break-glass access tested and its audit record reviewed.
• An incident response and breach notification procedure written, with names and contact details.
• Policies and procedures written and stored where they will be kept for six years.
• Signed BAAs on file for every vendor in the data path.
• The privacy notice and app store disclosures matching what the app actually collects.

After launch

The rule asks for ongoing review, not a one-time project, so these become routine.

• Review access reports and audit records on a set schedule and keep a note of each review.
• Update the risk analysis whenever the environment or operations change, such as a new vendor or feature.
• Patch dependencies and operating systems, and re-test after major changes.
• Remove access promptly when a person leaves or changes role.
• Keep the vendor list and BAAs current as tools are added or dropped.

How to make HIPAA compliant software: the build process

The safest products are designed around the data before the first screen is drawn. Our healthcare software development page sets out the order: start from the clinical and administrative workflow and the staff who run it, sort the data and the rules that govern it, plan the architecture and hosting under a BAA, then build in two-week sprints with clinicians giving feedback, test security, and launch with training and monitoring in place.

Discovery: classify the data first

Discovery decides how much of the system needs HIPAA-level controls. A scheduling tool that stores only names and appointment times for a clinic still holds PHI, because an appointment reveals that a person receives care from that provider. Splitting the product into a PHI zone and a non-PHI zone, for example a public website and content library outside it, keeps the strictest controls where they matter and lets the rest of the product use ordinary tools.

Risk analysis: use a method you can defend

HHS’s guidance on risk analysis says the Security Rule prescribes no single method, then lists what any method must cover: scope, data collection, threats and vulnerabilities, current security measures, likelihood, impact, level of risk, documentation and periodic review. Smaller practices can use the HHS Security Risk Assessment Tool, which ONC says is aimed at small and medium providers; larger organizations and product companies can work from NIST SP 800-66 Revision 2, which maps the rule to NIST’s controls.

Architecture: decide where PHI lives

Keep PHI in as few stores as possible, separate it from analytics and marketing data, and decide early whether each customer gets its own database or shares one with strict tenant isolation. Hold encryption keys in a managed key service with access logged. Treat identity as a core service: single sign-on for clinical staff, multi-factor authentication for administrators, and roles mapped to real jobs.

Build: security stories in every sprint

Every feature that touches PHI gets acceptance criteria for access checks, logging and data exposure, and every change goes through review. The OWASP Application Security Verification Standard, whose latest stable release is 5.0.0, works well as a requirements list for web and API code.

Verify: test against published standards

Mobile apps can be checked against the OWASP Mobile Application Security Verification Standard, which organizes controls into storage, cryptography, authentication, network, platform interaction, code quality, resilience and privacy. A penetration test before launch, with findings fixed or formally accepted, gives your customers something concrete to review.

Launch and operate

Go-live includes runbooks for incidents, backups and access changes, monitoring on the audit trail, and a date for the first log review. After launch the work is steady: patching, reviewing who has access, updating the risk analysis when something changes, and keeping the records.

Hosting HIPAA software: cloud providers, BAAs and shared responsibility

A cloud provider that stores or processes ePHI for you is a business associate, even when the data is encrypted and the provider holds no key. HHS’s guidance on HIPAA and cloud computing says that lacking an encryption key does not exempt a provider from business associate status, so a BAA is needed with every host.

Only covered services

A BAA covers named services, not everything a provider sells. On AWS, for example, PHI belongs only in services listed on the eligible services reference, so a developer who wants to add a new managed service partway through a project checks that list first. The AWS HIPAA page, Google Cloud’s HIPAA page and Microsoft’s Azure HIPAA page each explain their own scope.

Shared responsibility in practice

A BAA configures nothing for you. Encryption settings, identity policies, network rules, logging and backups are your side of the line, and HHS notes that customers may ask a provider for extra assurances, such as documented safeguards or audit reports, through the BAA or a service level agreement.

Your account, your data

We set up HIPAA-eligible hosting in your own cloud account, so the data and the account sit with your organization from day one, alongside the code and repositories. If you change developers later, nothing has to be migrated out of someone else’s account.

Can data be stored outside the United States?

HHS says the HIPAA Rules allow a cloud provider to store ePHI on servers outside the United States, provided a BAA is in place and the rules are otherwise met, while noting that the risks to that data can vary greatly by location. Put the location in your risk analysis, and check customer contracts, which sometimes require storage in the United States anyway.

Phones and tablets that reach the cloud

HHS also says providers and business associates may use mobile devices to reach ePHI in a cloud, as long as safeguards protect the data on the device and in the cloud and BAAs are in place with the third parties involved. That brings device management, screen locks and remote wipe into the risk analysis for any clinical app.

Analytics, pixels, messaging and AI: where PHI leaks

The database is rarely the only exit. Every third-party script, SDK and API the product calls is a possible disclosure, and HHS’s bulletin on online tracking technologies treats sending PHI to a tracking vendor without a BAA and a Privacy Rule permission, or the patient’s authorization, as an impermissible disclosure.

Tracking on logged-in pages and inside apps

The bulletin says tracking technologies on user-authenticated pages, such as a patient portal or telehealth platform, generally have access to PHI, and that information collected through a regulated entity’s mobile app generally is PHI. It also says a cookie banner asking users to accept or reject tracking is not a valid HIPAA authorization. On June 20, 2024 a federal court in Texas vacated the part of the bulletin covering an IP address linked to a visit to an unauthenticated public page about health conditions or providers; HHS says it is evaluating next steps, and the rest of the bulletin remains on HHS’s site.

Analytics tools that will not sign a BAA

Google’s Analytics help article on HIPAA says Google makes no representations that Google Analytics satisfies HIPAA requirements, does not offer business associate agreements for it, and that regulated entities must not expose PHI to it. In practice that leaves three choices: keep its tags off logged-in pages and PHI flows, send only de-identified product events to an analytics service that will sign a BAA, or run analytics on infrastructure you control.

Email, text, video and support tools

Every vendor in the path of PHI needs a BAA for the service you buy, and some vendors limit their BAA to particular plans or products, so check the plan rather than the brand. Keep the content of messages minimal: an appointment reminder rarely needs the reason for the visit. Support desks deserve the same care, because screenshots and ticket text quickly fill with patient details.

AI features and model providers

Adding a language model to a HIPAA product generally makes the model provider a business associate when prompts or files carry PHI. Providers now publish what their agreements cover: AWS lists Amazon Bedrock on its HIPAA eligible services reference, and Anthropic says its BAA covers HIPAA-ready services such as its first-party API and Enterprise plans, though not every feature. Check the specific endpoint, model and feature, confirm the data retention settings the agreement requires, and keep PHI out of prompts wherever a de-identified input will do.

HIPAA compliant mobile app development for iOS and Android

A phone adds a device the patient controls, two app stores with their own health rules, and more places for data to rest. HIPAA compliant mobile app development has to cover all three, on top of everything the web product needs.

Data on the device

Store as little PHI on the phone as the feature allows. What must be kept locally goes into encrypted storage backed by the platform keychain or keystore, caches are cleared on sign-out, and screens holding PHI are hidden from the app switcher. Sessions should time out, and a lost phone should be revocable from the server side.

Apple’s rules for health data

Guideline 5.1.3 of Apple’s App Review Guidelines says apps may not use or disclose data gathered in the health, fitness and medical research context, including data from HealthKit and the Clinical Health Records API, for advertising, marketing or other use-based data mining beyond improving health management or health research, and then only with permission. It also says apps may not store personal health information in iCloud and must disclose the specific health data collected from the device. Guideline 1.4.1 asks medical apps that have regulatory clearance to submit a link to it.

Google Play’s rules for health apps

Google Play’s Health Content and Services policy requires regulatory proof or a disclaimer for apps offering medical functionality and a privacy policy covering personal and sensitive data. Every developer with a published app must complete the Health apps declaration, even apps with no health features, and the Data safety form asks you to declare health and fitness data collected through your own code and third-party SDKs.

Push notifications, deep links and screenshots

Lock screens show notification text, so keep it generic and put the detail behind sign-in. Deep links should open to a sign-in prompt, never straight into a record, and URLs should carry no patient data, since web addresses and IP addresses both appear on the rule’s list of identifiers.

Native or cross-platform for a regulated app

Either approach can meet the rule. The choice affects how directly you reach platform security features and how much testing each release needs, which is covered on our native app development and cross-platform app development pages, with platform detail on our iOS app development and Android app development pages.

Questions for a HIPAA compliant mobile app development company

Ask where PHI rests on the device and how it is protected, what goes into push notifications, which SDKs are in the app and which of them sign BAAs, how the app is tested against MASVS, and whose developer accounts and signing credentials the app will ship under. Ours sit in your name from day one.

Breach notification: what the software has to make possible

When something goes wrong, the deadlines in 45 CFR Part 164, Subpart D run from discovery, and the product’s records decide how quickly you can say what happened and to whom.

Encryption that meets HHS’s breach guidance

The notification duties apply to unsecured PHI. HHS’s breach guidance treats electronic PHI as secured when it is encrypted consistent with NIST SP 800-111 for data at rest, or with NIST SP 800-52, 800-77, 800-113 or other FIPS 140-2 validated processes for data in transit, and the key has not been breached. HHS adds that keys should be stored apart from the data they protect. Media destroyed in line with NIST SP 800-88 also falls outside the definition.

Records that let you scope an incident

A business associate’s notice must identify, as far as possible, each individual whose PHI was involved. Without access records that tie each read and export to a user and a patient, that answer becomes everyone in the database. Good audit records shrink both the notice and the cost of sending it.

The four-factor assessment

An impermissible use or disclosure is presumed to be a breach unless a risk assessment shows a low probability that the PHI was compromised, based on at least four factors: the nature and extent of the PHI, including identifiers and the chance of re-identification; who received it; whether it was actually acquired or viewed; and how far the risk has been mitigated. Logs and encryption records are the evidence for those factors.

Reporting to OCR

Breach reports are filed through the HHS Office for Civil Rights breach portal. OCR’s portal page says it investigates all breaches of PHI and Part 2 records that affect 500 or more individuals, and may investigate smaller ones depending on its resources and enforcement priorities.

HIPAA penalties and enforcement for software companies

Business associates answer to HHS directly, not only to their customers. HHS’s cloud guidance says a provider handling ePHI is both contractually liable under its BAA and directly liable for the HIPAA requirements that apply to it, and civil money penalties are set in four tiers by culpability under 45 CFR 160.404.

Two details change how those numbers work in practice. Each day of a continuing violation counts as a separate violation under 45 CFR 160.406. And in April 2019 HHS said that, as a matter of enforcement discretion and pending further rulemaking, it would apply lower annual limits to the three lower tiers ($25,000, $100,000 and $250,000 in the statute’s base figures, against $1,500,000 for uncorrected willful neglect) and use that structure, adjusted for inflation, until further notice. The 45 CFR 102.3 table prints the statutory adjusted amounts, including the same $2,190,294 calendar-year cap for all four tiers; it does not print the lower annual limits that the 2019 notice applies.

Recognized security practices can reduce penalties

Under 42 U.S.C. 17941, HHS must consider whether a covered entity or business associate had recognized security practices in place for at least the previous 12 months when it sets fines, decides audit outcomes and agrees remedies for Security Rule matters. The statute points to practices developed under NIST’s voluntary cyber-risk framework authority and to the health care industry security approaches set under 6 U.S.C. 1533(d), among others. A year of documented practice is worth more than a policy written the week an investigation starts.

How OCR resolves cases

OCR’s breach portal explains that a report can end in technical assistance, a referral to another agency, an investigation, or closure without investigation. After an investigation OCR may negotiate a written agreement with corrective action steps. Software records, logs and test reports are the kind of evidence an entity can show OCR to demonstrate its safeguards.

Other rules that sit beside HIPAA

HIPAA is the floor for covered products, not the only rule. Consumer apps, substance use treatment records, medical device software and state privacy laws each add duties of their own. The Mobile Health Apps Interactive Tool, built by the FTC with HHS’s Office for Civil Rights, ONC and the FDA, walks developers through which federal laws may apply.

Consumer health apps and the FTC

The Health Breach Notification Rule covers apps and connected devices that track diseases, conditions, medications, vital signs, fitness, fertility, sleep, mental health, diet and similar data, where the record can draw information from more than one source and is controlled by or for the user. Amendments took effect on July 29, 2024. The rule does not apply to HIPAA-covered entities, or to anyone acting as a business associate, and violations carry civil penalties under the FTC Act.

Substance use treatment records

Records from federally assisted substance use disorder programs fall under 42 CFR Part 2, revised in a rule effective April 16, 2024. Part 2 now applies HIPAA’s breach notification provisions to Part 2 programs and points to HIPAA’s penalty provisions, and OCR’s breach portal takes Part 2 breach reports. A product serving addiction treatment providers needs consent tracking and redisclosure controls designed in.

Is your app also a medical device?

The FDA’s page on device software functions and mobile medical applications explains that its guidance, first issued in 2013 and updated in 2015, 2019 and 2022, focuses oversight on software that presents greater risk to patients if it does not work as intended. Whether a function is a device is a separate question from HIPAA and needs its own answer before launch.

State health privacy laws

States add their own rules. Washington’s My Health My Data Act requires consent before collecting consumer health data (unless needed to provide a product or service the consumer requested), separate consent before sharing it, and bans geofences within 2,000 feet of in-person health care sites used to track people, collect their data or send them health-related messages, while exempting PHI already covered by HIPAA. Other states have their own statutes, so the data map should record which states your users live in.

How much does HIPAA compliant software development cost?

Published US price bands for this work run from $40,000 for an EHR integration to $600,000 or more for a platform joining several systems. These are market figures, not a Progression rate card, and a quote follows a written scope. Compliance adds design, testing and documentation that an ordinary app does not need, so the same feature set costs more in a regulated product.

What pushes the price up

EHR integrations, the number of user roles, web plus iOS plus Android, audit and reporting screens, AI features, migration of existing records, and a third-party assessment your buyer requires. Each adds design and test time, and the testing scales with the number of places PHI can travel.

What keeps it down

A narrow first release, managed cloud services covered by your provider’s BAA, buying commodity parts such as video, messaging and identity from vendors that sign BAAs rather than building them, and synthetic test data that removes the need to secure development environments like production. Our MVP development page covers how to scope that first release.

Running costs after launch

Plan for maintenance, hosting and vendor plans every year. Our app development cost guide publishes maintenance at about 15 to 20 percent of the build each year as a market figure, and HIPAA products add their own line items: the vendor tiers that include a BAA, log storage for the retention period, and periodic security testing.

How long does HIPAA compliant app development take?

Using the same published bands, a focused scheduling or intake app takes three to six months, a portal tied to an EHR five to eight, and a platform that joins several systems nine to fourteen. Customer security reviews, vendor agreements and app store review run on their own clocks, so start them while the product is being built.

Where projects lose time

Late answers on which vendors will sign a BAA, real data needed for testing that nobody can approve, and a security questionnaire from the first customer that arrives after launch rather than before it. Each is avoidable with an early decision.

Retrofitting an existing product

Bringing a live product into line usually starts with a data map and risk analysis of what exists, then works through vendors, logging, access and encryption in order of risk. It is often faster than a rebuild, but only if the data model can separate PHI cleanly from everything else.

How to choose a HIPAA compliant app development company

Choose on evidence, not badges. A good partner explains which rules apply to your product, shows how its builds meet them, signs the contracts the rule requires and hands you everything you need to prove it later.

Red flags

A claim of HIPAA certification, an offer to drop PHI into tools that will not sign a BAA, no clear answer on audit records, a plan to test with production data, and a quote with no written scope. Any one of these is a reason to keep looking.

Agency, freelancer or in-house team

An agency brings design, engineering, testing and project management in one contract; freelancers can be strong engineers but leave you to coordinate the rest; an in-house team gives control and takes longer to hire. Our pages on hiring dedicated developers and app development outsourcing compare the models in more depth.

What the handover should include

The code and accounts, plus the evidence: a data-flow map, architecture record, vendor and BAA list, test reports and fix log, and runbooks for incidents, backups and access changes. With those, another team can take over, and your next customer’s security review has its answers ready.

Our HIPAA software development work

We take health software from scope to support: patient, clinician and operational products for organizations that handle health data, with the scope agreed in writing before development starts. Typical builds include scheduling and intake apps, telehealth and secure messaging, remote monitoring that reads Apple HealthKit and Android Health Connect, patient and provider portals, and integrations with electronic health records through HL7 FHIR.

Security we build in

These are the defaults on our health builds, as listed on our healthcare app page, in plain terms.

• Access by role, limited to what each job needs, with multi-factor sign-in.
• Data encrypted while it moves and while it is stored.
• Logs that record each access to health information.
• Hosting on AWS, Azure or Google Cloud services that are HIPAA-eligible, under the provider’s BAA.
• Before launch: code review, scans of third-party dependencies and a penetration test.
• Written procedures for responding to incidents and sending breach notices.

Business associate agreements

We sign a business associate agreement when our work involves PHI on a covered entity’s behalf. We classify each project during discovery to decide which rules apply.

Ownership from day one

The code, the data and the cloud accounts belong to you from the first day, and so do the repositories, developer accounts and app signing credentials, so you can move the product, audit it or hand it to another team whenever you choose.

Where this page fits

This page goes deep on HIPAA. For EHR and EMR builds see EHR software development; for video visits see telemedicine app development; for clinical workflow, interoperability and the wider healthcare build see healthcare software development.

HIPAA software development and AI answers

Some buyers now ask AI assistants to explain the rules and shortlist vendors before they fill in a form, so firms offering HIPAA software development are judged partly on what ChatGPT, Claude, Perplexity, Gemini, Microsoft Copilot and Google’s AI Overviews can find and quote about them.

How buyers ask

Questions a buyer might put to an assistant include which companies build HIPAA compliant telehealth apps in the United States, whether their developer needs to sign a BAA, whether they can use a given analytics tool in a patient portal, and what a risk analysis must include; a practice owner’s version is simpler: whether an app they are buying is HIPAA compliant and what to ask the vendor.

What gets cited

For rule questions, the primary sources are HHS guidance, the eCFR text and the cloud providers’ own HIPAA pages. A vendor page that answers the same question accurately, in plain language, and links to those sources gives an assistant something specific to quote. For vendor questions, pages that state services, locations, process and terms plainly are easier to summarize than pages built on slogans.

What to publish so you get named

A security page that maps your controls to the rule, your BAA policy, a subprocessor list, a short data-flow summary, honest answers to the questions buyers ask, and published price bands where you can. Make sure crawlers can reach it: OpenAI documents OAI-SearchBot, Perplexity documents PerplexityBot and Anthropic documents Claude-SearchBot. Google says there are no additional requirements to appear in AI Overviews or AI Mode beyond its normal search guidance.

Ads beside AI answers

Google can show ads above or below AI Overviews, and in some markets within them, though Google says it does not currently show ads within AI Overviews for sensitive verticals such as healthcare. Some assistants show labeled ads next to their answers. An ad buys that placement; it does not buy a place in the answer itself. Our AEO for healthcare and answer engine optimization pages cover the organic side.

Related services

Pages that cover the work around a HIPAA build, from the wider healthcare software practice to hosting, security and marketing.

• Healthcare software development: EHR, interoperability and clinical workflow
• Custom software development company: our full software practice
• Mobile app development company: iOS, Android and cross-platform builds
• Web development services: the web front end and back end
• Healthcare app development: patient, clinician and operational apps
• Telemedicine app development: video visits and secure messaging
• EHR and EMR software development: modules, portals and integrations
• Web portal development: patient and provider portals
• Cloud app development: AWS, Azure and Google Cloud architecture
• DevOps services: pipelines, infrastructure as code and monitoring
• Cloud migration services: moving existing systems into a covered account
• API development: secure APIs and integrations
• Backend development services: data, identity and services
• Web app development: browser-based products and dashboards
• SaaS development: multi-tenant products sold to many customers
• IoT app development: connected devices and the apps that read them
• Software consulting: architecture and build-or-buy decisions
• Website security services: hardening and monitoring for public sites
• AI integration services: model APIs inside existing products
• AI app development: products built around AI features
• Wearable app development: Apple Watch and Wear OS
• Fitness app development: tracking and coaching apps
• UI and UX design services: research, flows and prototypes
• Software development life cycle: how a build runs from start to finish
• Healthcare website design: the public site in front of the product
• Digital healthcare marketing: getting the product in front of buyers
• Healthcare SEO: search visibility for health organizations
• Medical marketing: marketing for medical practices

Frequently asked questions