Healthcare Software Development in the USA: HIPAA, FHIR and AI
HIPAA is only the start. A practical map of the US rules that shape healthcare software in 2026, from FHIR mandates to FDA's view of clinical AI.
The US is the largest digital-health market, and its rules come from several directions at once. HIPAA governs providers, payers and their vendors. The FTC and states cover consumer health apps that fall outside HIPAA. ASTP/ONC and CMS are pushing standard FHIR APIs and penalising information blocking. FDA decides when clinical software, including AI, is a medical device.
This guide summarises our research into the rules a US healthcare software team should design for in 2026. It draws on our own work, including engineering for the senior-care platform A Place For Mom. It is engineering guidance, not legal advice. The cross-market overview is on our healthcare page.
HIPAA: know whether you are in scope
HIPAA applies to covered entities (providers, health plans and clearinghouses) and to their business associates. The Security Rule requires administrative, physical and technical safeguards for electronic PHI. The Breach Notification Rule requires notice without unreasonable delay and no later than 60 days after discovery. Two points matter for architecture:
- Your cloud provider is a business associate. HHS guidance says a provider that stores or processes ePHI is a business associate even without the encryption key. You need a BAA, and you must stay within the services it covers.
- Every vendor in the data path counts, including logging, error tracking, email, analytics and AI model APIs. If PHI could reach a vendor, it needs a BAA or the PHI needs to be removed first.
The Security Rule is also changing. HHS proposed its first major rewrite on 6 January 2025. Among other changes, it would make encryption, multi-factor authentication and network segmentation mandatory. Reporting in 2026 indicates final action has slipped, and the current rule stays in force. We already build to the proposed baseline, because it is good practice and it avoids rework later.
Outside HIPAA: FTC and state health-data laws
Many consumer health and wellness apps are not covered by HIPAA, and that does not leave them unregulated. The FTC amended its Health Breach Notification Rule in 2024 to cover health apps and similar technologies, and unauthorised disclosures, such as sharing data with advertising platforms, count as breaches. States are adding their own rules. Washington's My Health My Data Act, in force since March 31, 2024 for regulated entities, protects consumer health data outside HIPAA, including data from wearables.
For consumer products such as a fitness or wellbeing app (see Ealthiness, which we built), this means:
- No tracking pixels or third-party SDKs that receive health data unless the user has explicitly authorised it.
- A consumer health data privacy notice where state law requires one, plus consent flows that are specific and revocable.
- Breach runbooks that cover the FTC and state notification paths, not only HIPAA.
Interoperability: FHIR APIs and information blocking
Federal policy now requires standard APIs. The ONC HTI-1 final rule made USCDI v3 the baseline for certified health IT as of 1 January 2026 and added transparency requirements for decision support interventions. The CMS Interoperability and Prior Authorization final rule requires impacted payers to build FHIR-based APIs, including Patient Access, Provider Access, Payer-to-Payer and Prior Authorization APIs, with compliance dates generally beginning on 1 January 2027.
The other side of this is enforcement. Under the 21st Century Cures Act, information blocking is prohibited, and a 2024 HHS rule set disincentives for providers found to have committed it. Policy is still moving: in December 2025 ASTP/ONC proposed the HTI-5 rule, which would remove or revise many certification criteria and update the information-blocking regulations. We track it, but we design to the stable core: HL7 FHIR R4, US Core profiles and SMART on FHIR authorization.
Clinical AI and the FDA
The first question for any clinical AI feature is whether it is a medical device. FDA's Clinical Decision Support Software guidance, revised in January 2026, sets out how it applies the 21st Century Cures Act criteria that exclude some CDS from device regulation. Features that analyse medical images or signals, or that drive time-critical decisions without letting the clinician review the basis, are much more likely to be devices.
For AI that is a device, FDA has published lifecycle expectations. Its December 2024 final guidance on predetermined change control plans lets manufacturers pre-authorise planned model updates. Its January 2025 draft guidance on AI-enabled device software functions covers data management, model description, validation, performance monitoring and cybersecurity. Our engineering response:
- Classify each AI feature against the CDS criteria before design, and record the reasoning.
- Keep the clinician in control: show the inputs and basis for every suggestion, and log overrides.
- Version datasets, models and prompts, and keep evaluation reports, so a later submission does not mean reconstructing history.
- Monitor performance in production and treat drift as an incident.
Our AI in healthcare service and our guide to HIPAA- and GDPR-compliant AI go deeper on de-identification, hosting and audit trails.
Minimum necessary, audit trails and de-identification
Three HIPAA ideas shape day-to-day engineering more than any others. First, the minimum necessary standard: each role, service and API scope should see only the PHI it needs. Second, auditability: every access to a record should be attributable to a person or service, timestamped and stored where application admins cannot quietly edit it. Third, de-identification: development, testing, analytics and many AI features can run on de-identified data, which takes them out of HIPAA's scope altogether when done by HIPAA's defined methods.
In practice we build role-based access with attribute checks for sensitive record types, write an append-only access log separate from application logs, and run a de-identification step before data reaches lower environments or model prompts. Engineers work with synthetic or de-identified data by default, and production access is time-limited and logged.
How we build for the US market
- US regions, HIPAA-eligible services and a signed BAA for every component that touches PHI, including AI providers.
- Security to the proposed baseline: encryption everywhere, MFA, segmentation, asset inventory and regular vulnerability testing.
- FHIR-first integrations with US Core and SMART on FHIR, with scopes kept to the minimum necessary.
- Event-driven, observable infrastructure that holds up under nationwide traffic. That was the brief for our work on A Place For Mom, built on Next.js, Node.js and AWS Lambda, SQS and SNS.
- Privacy-safe product analytics that never send PHI or consumer health data to ad tech.
If you are planning a US healthcare product, from a patient app to an EHR-integrated AI assistant, our mobile and AI teams can help you scope it. Get in touch.
