Preventa Wellness
Fractional CTO and co-founder — ongoing since 2019, across both Preventa entities
A HIPAA-compliant preventive health platform with AI retinal image analysis. Eric has served as Preventa's fractional CTO since 2019, now through IN2Labs, and has a financial interest in the company beyond the engagement fee — disclosed here because it is not an arm's-length client relationship.
Visit preventawellness.comAt a glance
- Our role
- Fractional CTO and principal engineer, ongoing since 2019 — first at Preventa Medical Corporation, continuing at Preventa Wellness
- Engagement history
- Continuous since 2019. CTO of Preventa Medical Corporation, where Eric was also principal investigator on NSF SBIR Phase I #1941226, and CTO of Preventa Wellness — the commercial continuation of the same work under a separate corporate structure.
- Disclosure
- Paid fractional CTO engagement. Eric is also a co-founder and has a financial interest in Preventa beyond the engagement fee. Not an arm's-length client engagement.
- Product owner
- Preventa (the client owns the product and the IP)
- Regulatory scope
- HIPAA — protected health information (PHI)
- Platform
- Flutter, cross-platform, on HIPAA-eligible cloud services
- AI component
- Retinal image analysis for preventive health insights
The challenge
What made this hard
Preventa Wellness needed to put AI-assisted retinal image analysis in front of real patients. That combination — medical imagery, machine learning, and consumer-grade UX — puts protected health information into every layer of the system at once. Health data is the one domain where "mostly secure" is not a defensible position: the architecture has to satisfy regulators, hospital security teams, and patients simultaneously, and the decisions that determine whether it does are made in the first weeks of the build, not retrofitted before an audit.
The approach
Treating PHI as an architectural constraint, not a checklist
Most teams discover HIPAA late, then try to bolt compliance onto a system that was designed without it. That is where the expensive rewrites come from. We inverted the order: the boundary around protected health information was drawn before the first feature was built, and every subsequent decision — where images live, which services can read them, what gets logged, what crosses a network hop — was evaluated against that boundary.
Practically, that meant identifying exactly which data elements constituted PHI, keeping them inside a narrow set of services, and making sure every vendor that could touch those services was covered by a Business Associate Agreement. Any component that could not be BAA-covered was designed out of the PHI path rather than granted an exception.
Encryption, access control, and audit logs that are actually queryable
PHI is encrypted at rest and in transit. That part is table stakes, and every vendor claims it. The part that distinguishes an audit-defensible system is access control and logging: who touched which record, when, and through what path — and whether you can answer that question quickly when someone asks.
Audit logs are only useful if they can be searched under pressure. We built logging as structured, queryable records tied to identity and resource, rather than as an append-only stream nobody can interrogate. Role-based access controls sit in front of PHI reads so that permission is granted per-role and per-resource instead of being implied by a successful login.
Running AI inference without widening PHI scope
Retinal images are PHI. Any AI pipeline that processes them inherits the full regulatory scope of the data, which rules out the casual approach of shipping images to whichever inference API is most convenient. The pipeline had to stay inside infrastructure the client controls and a BAA covers.
I designed the image-handling path so that the analysis runs against controlled storage with explicit, logged access, and so that the surrounding analytics and product telemetry operate on de-identified data. Product questions get answered without every dashboard becoming a PHI system.
One Flutter codebase, without the cross-platform tax
Preventa is a Flutter application, which let a single codebase serve multiple platforms — the right economics for a company that needs to reach patients broadly without funding three parallel native teams.
Cross-platform only works when it is architected deliberately: a real state management layer, declarative navigation, and a design system shared across surfaces. Done that way, the codebase stays one product rather than three diverging ones that happen to share a language.
Outcome
What shipped
- A HIPAA-compliant platform running in production, owned outright by the client
- PHI encrypted at rest and in transit, with BAA coverage across the vendor stack
- Structured, queryable audit logging and role-based access controls over PHI
- AI retinal image analysis running inside controlled, BAA-covered infrastructure
- A single Flutter codebase serving multiple platforms
- Architecture documented so the client is never locked in — they own the code, the cloud accounts, and the IP outright
Stack
More work
PriceHarvest
A Flutter web app that tracks prices across retailers and tells shoppers the moment to buy — co-developed by IN2Labs.
GhostX
A suite of free browser tools whose privacy guarantee is structural rather than promised: the single-file tools have no upload endpoint at all, and the sharing flows are end-to-end encrypted with a key the server never receives.
Building something like this?
Free 30-minute technical review. Tell me where you're stuck — we'll tell you what it takes.
Book a 30-min technical review