AI systems for care delivery, built to survive review.
Healthcare is the environment we know best. The constraints are not obstacles to design around — they determine the architecture, and we treat them that way from the first diagram.
Three classes of system, three different obligations
What HIPAA requires of a system depends on what the system touches and who uses it. We scope each of these differently.
Patient-facing applications
Portals, intake, scheduling, and messaging where the patient is the user. The hard problems are authentication, consent, and making sure a patient can never reach another patient's record.
Individual access rights, minimum necessary disclosure, secure authentication, breach notification readiness, and accessibility so that access rights are real for every patient.
Clinical decision support
Systems that inform a clinician's judgment: risk stratification, documentation assistance, retrieval over clinical literature, and structured summarization of a chart.
Audit controls over who saw what, integrity controls on the data feeding the model, and a documented review path so the clinician remains the decision-maker of record.
Back-office automation on PHI
Claims, prior authorization, eligibility, coding support, and revenue cycle work — high-volume, repetitive, and full of protected health information.
Role-based access, workforce clearance, business associate agreements with every downstream vendor, and retention limits that are enforced rather than documented.
Where we stand on FDA and Software as a Medical Device
This is the question that stops most AI-in-healthcare projects late, when it is expensive. We raise it at the start.
Software can cross into being a regulated medical device depending on what it claims to do and how much the user is expected to rely on it. Broadly, software that informs clinical management while leaving the clinician able to independently review the basis of the recommendation sits differently from software that directs treatment or that a clinician cannot reasonably second-guess. The distinction turns on the specific claims, the intended use, and the degree of automation — not on whether the system uses AI.
Our position
We are software engineers, not your regulatory counsel. What we do is design so the question stays answerable: intended-use statements written before code, claims kept narrow and documented, the clinician's ability to review the basis of every output preserved in the interface, and a record of model versions and evaluations that a regulatory consultant can actually work from.
If a project looks like it may fall under device regulation, we say so early and recommend you bring in regulatory counsel before we build. We would rather lose the scope than hand you a system you cannot lawfully deploy.
Nothing on this page is legal or regulatory advice. Classification depends on your specific intended use and claims, and should be confirmed with qualified regulatory counsel.
What we hand over for your vendor due diligence
When your security team or your client's compliance officer reviews us as a vendor, these are the artifacts we provide. You should not have to chase your developer for them.
- Business Associate Agreement, executed before any PHI is shared
- System architecture diagram with the PHI boundary marked explicitly
- Data flow documentation: what is collected, where it rests, how long it is retained
- Access control model: roles, permissions, and how access is granted and revoked
- Encryption summary: in transit and at rest, with key management described
- Model documentation: intended use, evaluation results, known limitations
- Audit logging specification: what is recorded, retention, and how to query it
- Subprocessor list for anything in the delivery path
- Incident response and breach notification procedure
- Secure development practices: review, dependency management, secret handling
If your reviewer needs something not on this list, ask. If it exists, we will send it; if it does not, we will tell you that instead of improvising.
Read the Trust & Security pageBring us the constraint, not just the feature
The most useful first conversation is the one where you describe what regulates you. Tell us the setting and the obligation, and we will tell you what is buildable.
Talk to our team