Medical Device AI Compliance in Los Angeles: FDA SaMD, HIPAA, and What It Costs to Build

Los Angeles has one of the densest medtech clusters in the country — device companies and digital health startups along the Westside and Santa Monica, Caltech and JPL spinouts in Pasadena, and the Irvine and Orange County corridor where several of the largest device manufacturers keep engineering teams. Almost every founder we meet from those neighborhoods now has an AI feature on the roadmap, and almost every one asks the same two questions in the first meeting: "Is this a medical device?" and "Is HIPAA enough?" The answers change the architecture, the timeline, and the budget by an order of magnitude, so this article walks through them in plain language. It is not legal or regulatory advice; every product described here should be reviewed with regulatory counsel or a consultant before a line of code is written.

When AI software is a medical device

The FDA regulates software based on intended use, not on technology. Software that is intended to diagnose, treat, mitigate, prevent, or cure disease — or to affect the structure or function of the body — meets the statutory definition of a device, whether it runs in a scanner, a phone, or a browser tab. Software that meets that definition without being part of a hardware device is Software as a Medical Device (SaMD), a category the FDA regulates through the same risk-based framework it applies to physical devices. An AI model that reads a retinal image and flags likely diabetic retinopathy is SaMD. An AI model that reminds patients about appointments is not.

The gray zone in between is where LA startups live, and it is defined by two exemptions that are easy to overread.

The Clinical Decision Support exemption

The 21st Century Cures Act carved certain clinical decision support (CDS) software out of the device definition, and the FDA's guidance explains how it interprets that carve-out. Broadly, software may fall outside device regulation when it does not process medical images or signals from in-vitro diagnostics or monitoring hardware, displays or analyzes medical information, supports (rather than replaces) a healthcare professional's recommendation, and lets that professional independently review the basis for the recommendation rather than relying on the software. All of those conditions have to hold together. In practice, the "independent review" condition is where AI products struggle: a model that outputs a risk score without showing its inputs and reasoning, or one that is intended for time-critical decisions where a clinician cannot realistically double-check it, tends to look like a device to the FDA regardless of how the marketing describes it.

The general wellness policy

The FDA has also said it does not intend to enforce device requirements for low-risk products intended only for general wellness — encouraging healthy activity, sleep, stress management, or weight — as long as they do not make disease claims and do not pose a safety risk. The moment a wellness app says it detects, screens for, or manages a named condition, it has left that policy. Many consumer health AI products in Santa Monica and Venice sit on exactly that line, and the copy on the landing page matters as much as the code.

• Likely not a device: scheduling and intake agents, documentation drafting reviewed by a clinician, billing and prior-auth automation, general wellness coaching without disease claims.
• Possibly exempt CDS, review with counsel: guideline-based suggestions to clinicians where inputs and logic are transparent and the clinician can independently verify them.
• Likely a device: image or waveform analysis, triage or risk scores intended to drive clinical action, dosing recommendations, anything a patient acts on directly for a named condition.

FDA pathways at a high level

If the product is a device, the regulatory pathway depends on its risk class and whether something similar has already been cleared. Three pathways cover most AI SaMD.

• 510(k) premarket notification: the applicant demonstrates that the device is substantially equivalent to a legally marketed predicate. Most AI SaMD to date has reached the market this way, and finding the right predicate is often the first strategic decision.
• De Novo classification: for novel low-to-moderate risk devices with no suitable predicate. The FDA creates a new classification, which can later serve as a predicate for others — a meaningful position for a first-mover.
• Premarket approval (PMA): for the highest-risk devices, requiring clinical evidence of safety and effectiveness. Rare for early-stage AI startups and outside the scope of what a software partner alone can carry.

Predetermined Change Control Plans for AI models

Historically, retraining a cleared model could trigger a new submission, which is incompatible with how machine learning teams actually work. The FDA's Predetermined Change Control Plan (PCCP) framework addresses this: the applicant describes, in the original submission, the specific modifications it plans to make — retraining on new data, performance tuning, certain input changes — along with the methods it will use to validate them and how it will manage the associated risks. If the FDA accepts the plan, changes inside its boundaries can be made without a new submission. For an AI product this is a design decision that has to be made before the first submission, and it has direct implications for how your data pipeline, versioning, and validation harness are engineered.

FDA and HIPAA regulate different things

Founders often treat FDA clearance and HIPAA compliance as two levels of the same ladder. They are not. The FDA regulates whether a device is safe and effective for its intended use — the model's performance, its failure modes, the software's lifecycle, and the manufacturer's quality system. HIPAA regulates the privacy and security of protected health information handled by covered entities and their business associates — who can see patient data, under what contract, with what safeguards, and what happens when it leaks. A device can be FDA-cleared and still violate HIPAA if it ships PHI to a model provider without a BAA. A HIPAA-compliant workflow tool can be perfectly lawful under HIPAA and still be an unapproved device if it makes diagnostic claims.

The practical consequence is that an LA medtech company usually needs both tracks, and they are owned by different people. The regulatory lead owns the FDA file; the security officer owns HIPAA. A development partner needs to produce artifacts for both. The HIPAA side — BAA chain, Security Rule safeguards, risk analysis, audit logging — is covered in depth in our HIPAA-compliant AI checklist, and the local specifics for HIPAA-compliant AI in Los Angeles are on the service page. This article stays on the device side.

IEC 62304 and the software lifecycle the FDA expects

IEC 62304 is the international standard for medical device software lifecycle processes, and the FDA recognizes it as a consensus standard. It does not tell you how to write code; it tells you what has to exist around the code. Software is assigned a safety class — A, B, or C — based on the severity of harm a failure could cause, and the class determines how much rigor is required in planning, requirements, architecture, detailed design, unit implementation, integration testing, system testing, release, and maintenance. Class C software, where a failure could contribute to death or serious injury, requires the full set; Class A can be lighter.

For an AI product, 62304 forces a few uncomfortable but useful conversations. Which parts of the system are the "medical device software" and which are supporting infrastructure? How is the model itself treated — as a software unit with its own requirements and verification, or as configuration data? What is the SOUP (software of unknown provenance) list — every open-source library, every cloud service, every model runtime — and how are their known anomalies tracked? A team that has never done a regulated build tends to discover these questions during the submission. A team that has done them structures the repository, the CI pipeline, and the documentation to answer them from day one.

Cybersecurity is now a premarket expectation

Since 2023, federal law has given the FDA explicit authority to require cybersecurity information for "cyber devices" — devices that include software, connect to the internet, and could be vulnerable to threats. The FDA's premarket cybersecurity guidance describes what it expects to see: a threat model, a security architecture, a software bill of materials (SBOM), evidence of security testing, and a plan for monitoring and patching vulnerabilities after the device is on the market. For cloud-connected AI SaMD, this is not a checklist appended at the end; it shapes the deployment architecture.

• Threat model: documented attack surfaces including the API, the model endpoint, the update mechanism, and any clinician or patient interface — with prompt injection and data poisoning treated as first-class threats for LLM-based components.
• SBOM: a machine-readable inventory of every third-party component and its version, generated by the build pipeline rather than by hand.
• Secure update path: signed releases, rollback capability, and a documented process for pushing a security patch without breaking the cleared configuration.
• Postmarket plan: who monitors vulnerability disclosures for your SOUP list, how fast you patch, and how you notify customers.

California adds CMIA and CCPA/CPRA

Building in Los Angeles means answering to California law as well. The Confidentiality of Medical Information Act (CMIA) governs medical information held by providers and by businesses that offer software or hardware to consumers for managing medical information — a definition that reaches many digital health apps that would otherwise sit outside HIPAA. CMIA carries a private right of action, so exposure is not limited to regulators. The California Consumer Privacy Act as amended by the CPRA generally exempts data already governed by HIPAA and CMIA, but it applies to the consumer data around the edges — marketing analytics, account data, wellness data that is not medical information — which a consumer-facing AI product almost always collects. California has also begun legislating directly on AI in healthcare, including disclosure obligations when generative AI is used in certain patient communications. Counsel licensed in California should map these to your specific product; the point here is that "HIPAA compliant" is not a complete answer for a Santa Monica or Pasadena company.

Design history documentation: the file that outlives the code

The FDA's quality system requirements — now aligned with ISO 13485 — require design controls and a design history file (DHF) that shows the device was developed under a controlled process: user needs, design inputs, design outputs, verification that outputs meet inputs, validation that the device meets user needs, risk management (typically under ISO 14971), and design reviews at each stage, all traceable to each other. For AI SaMD, the DHF also has to explain the training data, the performance metrics and their acceptance criteria, how the model was evaluated on data it did not see, known limitations and subgroup performance, and how the PCCP, if any, will be executed.

This is where the difference between a software agency and a regulated software partner becomes visible. An agency delivers working software. A regulated build delivers working software plus a traceability matrix from every requirement to its tests, version-controlled design documents, risk analysis linked to mitigations in the code, and release records that a reviewer can follow without talking to an engineer. The documentation is not overhead on top of the engineering; on a device project it is roughly a third of the engineering.

The most expensive sentence in medtech is "we will do the documentation once the product works." By then the design decisions that needed to be recorded are three refactors old, and the team is reconstructing a history instead of keeping one.

— Rocket Systems Team

Working with a partner who has done regulated builds

Most LA medtech startups cannot justify a full in-house regulated software team before their first clearance, so they pair a small internal core — usually a clinical lead, a regulatory consultant, and a technical founder — with an outside engineering partner. The partner needs to be evaluated differently from a normal custom software vendor. Ask whether they have worked inside a 62304 lifecycle before and can show a redacted traceability matrix. Ask how they treat the model as a controlled artifact — versioned training data, reproducible training runs, frozen evaluation sets. Ask whether their engineers can write a design input that a regulatory reviewer would accept, not just a user story. Ask how they separate device software from non-device software in the architecture so that the scheduling module does not drag the whole system into Class B. Our general guide to evaluating an AI development company covers the rest; for device work, add "show me your last regulated deliverable" to the list.

Geography still matters for this kind of work. Design reviews, risk sessions, and usability testing with clinicians go faster in a room. We run discovery and design reviews on site for teams across Los Angeles, Pasadena, and Orange County, with engineering executed by our Yerevan team under the same documented process.

What regulated AI software costs to build

Budgets divide cleanly along the device line. Non-device AI that handles PHI — intake, scheduling, documentation drafting, referral triage — is a HIPAA project, and our HIPAA-compliant AI development engagements for that tier start at $7.5k, including the BAA, risk analysis, and compliance package. Device-adjacent software — a companion app for a cleared device, a clinician dashboard that displays device output, an AI module that will be submitted as part of a larger system — requires the QMS documentation described above: design controls, 62304 lifecycle artifacts, risk management file, SBOM, and traceability. Those builds run $25k–$80k and up depending on safety class, integration surface, and how much of the QMS the client already has. A full AI SaMD submission, with clinical validation and a regulatory consultant driving the file, is a larger program where the engineering partner is one line item among several.

Engineering time for regulatory-savvy engineers on our team starts at $15 per hour, which is what makes the documentation-heavy portion of a device project affordable for a seed-stage company. Teams that want to hold the QMS internally and staff the build can hire AI developers who have worked inside a 62304 process and plug them into their own design controls. Either way, the regulatory consultant and counsel are separate costs and should be in the budget from the first month, not the last.

Scope the regulatory path before the architecture

If you are building AI for a device, a companion app, or a clinical product in the Los Angeles area, we offer a free 30-minute discovery call with an engineer who has worked on regulated software. You leave with a written scope, an estimate, a PHI data-flow outline, and a candid read on which parts of your product look like a device and should go to counsel first. We sign the BAA before we see any patient data.