Skip to content
Rafael Rodrigues
Rhino Federated Computing·2024–2026·Federated AI · Healthcare

The operating system for federated clinical AI

Designing and building the controls that let hospitals run AI on data they can never move.

Product designDesign systemsFront-end

01The problem

In life sciences and healthcare, the most valuable data is the data that can never leave the building. Patient records, clinical results, and proprietary research stay locked inside each institution behind privacy and regulatory walls. Rhino lets teams train and run AI across all of it without the data ever moving. The users are researchers, data scientists, and healthcare administrators at hospitals and pharma companies, and what is at stake is whether a study can run at all.

The power needs guardrails, and the guardrails are a workflow problem. Standing up one federated project means chaining a dozen dependent steps: enroll sites, map each institution's schema to a common model, set permission policies, stage code, and execute across machines you never see. Any wrong step leaks nothing but breaks everything. My job was to make that multi-step, high-stakes pipeline legible enough that people would trust it and adopt it.

02My role

I led product design across the platform for two years and owned the end-to-end workflows: projects, federated datasets, schema mapping, permissions, code execution, and the compute and site-health surfaces around them. I set the interaction patterns, drove the scoping calls with the PM, and iterated screen by screen with engineering so what I designed matched what the system could actually enforce. I also owned the design system that held it all together.

03The approach

The hardest surface was schema mapping, where each site's raw tables have to be reconciled to OMOP and FHIR before anything can run. I sat in on sessions with data engineers at partner institutions and watched them map schemas in spreadsheets. The recurring failure was losing track of which fields were still unmapped across dozens of tables. That insight reframed the design from a form into a stateful checklist that always shows mapped, unmapped, and conflicting fields, so a user can leave and resume without losing the thread.

Because the context is privacy-sensitive, I treated trust as a first-class design concern and built for the states that are usually ignored: partial and failed mappings, sites that drop offline mid-run, permission-denied and audit views, empty states that explain the next action instead of showing a blank table, and loading states for compute that can take hours. I kept color from being the only signal so status stayed legible for color-blind users, and I met contrast targets across the app. To make v1 shippable I deliberately cut automated schema suggestion and a visual policy-builder from scope. Both were large modeling problems, and getting the manual, auditable path right mattered more than automating it early. Underneath the features I rebuilt the foundation into a single semantic token system so the product could support light and dark modes and the team could move faster.

04What I built

Structured project dashboards, federated dataset management, the granular permission system, and the data-mapping tools aligned with OMOP and FHIR, plus the usage and compute surfaces and the design system they all draw from. The interface in these screens is the one that shipped, built on the same components engineering uses in production.

Scope was negotiated tightly with the PM and engineering. Because permissions are enforced server-side and evaluated per site, engineering could not confirm what a given user was allowed to do until the request resolved. Rather than block the UI, I designed optimistic permission states with a clear reconciling indicator and a graceful fallback when a site denied access, so the interface stayed honest about what it did and did not yet know.

05Outcome

The platform shipped and now consolidates fragmented clinical data into structured, governed intelligence, and the design foundation carried the product into enterprise healthcare partnerships. On top of it the company secured over $20 million in funding.

After launch, support threads and follow-up interviews kept pointing at the same friction: teams stalled on schema mapping and filed tickets to the data team to unblock a project. V1 had shipped a functional but linear mapping path, so for v2 I reworked it into the resumable, always-visible-state model and added inline validation at the point of error. Cohort and dataset setup that used to stretch across days dropped to under an hour, and the mapping tickets that had been routed to the data team largely stopped.

06Reflectionoptional

I would have invested in the semantic token system earlier, before the feature work piled up on the old styles, and I would have run the mapping interviews before v1 instead of after, since that one insight reshaped the most important workflow in the product.

Interfaces

The interface that shipped.

22 screens from the work. Click any image to view it full size.