Philterd

Contact Us

Tell us about your stack and the privacy problems you're trying to solve. We typically respond within one business day.

Prefer email? support@philterd.ai

Please do not enter PII or PHI in this form. If you need to share an example, use a sanitized one.

Know your app's PHI risk

A read-only PHI risk assessment for healthcare apps. Findings with locations, a verdict you can show, and a plan to move to managed HIPAA hosting.

A detailed analysis of how your app handles PHI

The report details our findings on how your app handles PHI, with a location attached to every one of them. An example of what you get back is below.

An illustrative first page of an assessment report using invented data. A verdict panel reads Elevated PHI exposure risk, chosen from a three-level scale of Critical, Elevated, and Contained. Three blocking findings follow, each with a severity chip, a file location, and a remediation summary, covering an AWS access key in repository history, patient names and medical record numbers in application logs, and clinical note text sent to a model provider with no BAA. Nine further findings are summarised below, and a footer states that the report is not a HIPAA risk analysis or a compliance certification.

From vibe-coded to production

You built something that works. A clinical intake flow, a documentation assistant, a triage bot, put together fast by a small team or a contractor or an AI coding tool, and it is now in front of people who ask harder questions than your first users did. A health system wants to run a pilot and their security team sent a questionnaire. An investor asked how patient data is handled. Somebody wants you to sign a business associate agreement and you are not certain you can honor it.

This page describes what a PHI assessment of that prototype looks like. It is a representative engagement rather than a fixed package, and the scope is set with you before anything starts. Every deliverable is a finding, a recommendation, or a plan. We do not change your code, rotate your credentials, or touch your infrastructure.

Two panels with an arrow between them. On the left, your prototype as it exists today, covering repositories and git history, the cloud account, logs and storage, calls out to model providers, and the current hosting setup. The arrow between them is labelled read-only review, with a note that nothing in your stack changes. On the right, what you get back, listing a verdict you can put in front of a reviewer, a PHI inventory with counts and locations, a secrets report and rotation runbook, and a migration plan for managed HIPAA hosting.
What the assessment takes in and what it hands back. Everything in the right-hand column is a document, and none of it is a change to your system.

When this engagement fits

This is the right engagement if you have a working app that handles real or realistic patient data, you are facing a specific event that forces the question (a pilot, a diligence process, a BAA, a security review), and you want to know what is actually wrong before someone else tells you. It fits best when you have engineers who can do the remediation work themselves and need a prioritized list rather than a pair of hands.

What we look at

The assessment covers four areas, and every one of them is read-only. Each finding comes with a location attached rather than a general suggestion to go review something.

  • Where PHI actually lives. We work through the code, the exported logs, the file shares, and the document storage in scope, and record where patient data is written, stored, and retained. The output is an inventory with counts and locations, which turns “we should probably check the logs” into a specific number of patient names and the files they are sitting in.
  • Where PHI leaves your boundary. Most prototypes in this category call a hosted model provider directly with raw clinical text. We trace the paths where patient data reaches a third party, including model providers, analytics, error reporting, and support tooling, and check each one against whether a BAA covers it.
  • Exposed secrets. We sweep the repository history, configuration, container images, and client-side bundles for credentials, API keys, and connection strings. Git history matters here more than people expect, because a key removed in a later commit is still sitting in the repo for anyone who clones it.
  • What managed hosting would require. We assess the current deployment against what a HIPAA-eligible hosting arrangement expects, covering secrets management, logging, audit trail, encryption in transit and at rest, and access control. If you are on AWS, we can hand you a HIPAA-shaped target architecture rather than a generic checklist, drawing on the same HIPAA environment guide and AWS reference architecture we publish.
Two panels using invented data. On the left, a patient intake assistant prototype looks unremarkable. On the right, the read-only findings show what sits underneath it. Patient name, date of birth, and medical record number are written to application logs in plaintext, clinical note text is passed to a hosted model provider, and a live cloud credential is hardcoded in a settings file. A note records that locations and counts are reported and that values are never copied out of your environment.
The demo usually looks fine. The findings are what sits underneath it, and every one of them comes with a location. All data shown here is invented.

How the engagement runs

After the intro call, the work follows four phases. Durations depend on how many repositories and services are in scope and how much of the stack is documented.

  1. Scoping and access. We agree on exactly what is in scope, which repositories, which cloud account, which services, and you grant read-only access. Anything outside that boundary is not reviewed, and we say so in the report rather than leaving a silent gap.
  2. Discovery and review. We work through the code and the storage in scope, sweep for exposed secrets, and trace where patient data travels. This phase produces raw findings with file paths and locations rather than categories.
  3. Analysis and hosting evaluation. We rank the findings by severity and work out what each one would take to fix, then evaluate managed healthcare hosting against your actual architecture. We keep partnerships with a range of HIPAA-compatible hosting providers, so the shortlist comes from platforms we already work with rather than from a search results page, and for a conventional web application we can usually point you at a good fit early. For each candidate we cover whether they will sign a BAA, what that BAA actually covers, and what your application would have to change to run there.
  4. Report and walkthrough. You get the written assessment, and we walk your engineers through it live so they can ask questions while the reasoning is still fresh. The recommendations are written to be worked by your own team without us.
Four phases left to right, each with its deliverable. Scoping and access delivers an agreed scope and a read-only access plan. Discovery and review delivers a PHI inventory, a secrets list, and a data-flow map. Analysis and hosting evaluation delivers a severity ranking and a hosting platform shortlist. Report and walkthrough delivers the verdict, a remediation plan, and a live session. A band across the bottom notes that every phase is read-only and that the work happens inside your own environment.
The four phases and what each one leaves you with. Nothing in the sequence changes your code or your infrastructure.

Critical findings do not wait for the report

If we find a live credential, or PHI sitting somewhere publicly reachable, you hear about it within 24 hours through an agreed channel rather than in the report three weeks later.

Whether that rises to a reportable breach is your call to make, and the whole point of telling you early is that you get to make it early.

What usually comes next

Most teams take the report and work it themselves, which is the outcome the engagement is designed for. When the findings point at redaction work, the same open source toolkit is there. Philter handles PHI removal in your pipelines, Philter AI Proxy sits between your application and a model provider so clinical text is redacted before it leaves your boundary, and a full engagement covers the build if you would rather not staff it. None of that is a condition of the assessment.

Pricing

The assessment is fixed price, because the deliverable is fixed. The number depends on how many repositories and services are in scope, which we settle during the intro call. There is no per-record fee and no software cost, since the tooling is our own open source stack.

See the healthcare use case

This page describes a representative engagement. It is illustrative, not a statement of work, and the actual scope, sequence, and schedule are set with you before work begins. The assessment is a technical review and is not a HIPAA risk analysis, a compliance certification, or legal advice.