One access-and-workflow layer over many orphaned healthcare systems
A HIPAA-compliant platform for three kinds of organization: an administrator, one health insurer, and that insurer's provider practices. It gave them one governed view and workflow surface across many separate backend systems, with per-tenant federated login and independent audit + pentest validation.
Anonymized case study. Healthcare. All parties withheld: a third-party administrator, one health insurer it administers, and that insurer's provider practices. No client names, no locations. Engagement led by Ryan Luccioni, principal, as technical lead.
Architecture
The platform is bespoke to one insurer. Its tenants are that insurer's provider practices (many); the administrator and the insurer's own staff are the two oversight roles. One person, a doctor working at more than one practice, can hold access in each, scoped differently by role.
Context
A third-party administrator runs back-office operations for multiple health insurers: it maintains their backend systems. One of those insurers' contracts required a management application, and this platform is bespoke to that single insurer relationship. The application is a place where the provider practices that accept this insurer's plans could log in and do their work: claims, repricing, pre-authorization, billing, queries. The administrator oversaw it and the insurer's own staff worked inside it too.
But the data already lived in a scatter of separate systems: a claims backend, a repricing service, a provider network, communications. The problem wasn't storage. It was access and orchestration: give the right people governed entry to the right systems, in the right way, and let them run workflows across all of it from one place.
Our principal was technical lead and did most of the implementation, directing the firm's engineers and coordinating a client-chosen front-end team plus stakeholders from all three kinds of organization.
The hard part (and it wasn't the code)
Two hard parts, neither of them CRUD:
The human one. Holding requirements from three kinds of external organization with different interests: an insurer, an administrator, medical practices. Driving them to consensus on a regulated system where being wrong is a legal event. That coordination was the work.
The technical one: federated identity as the spine. Every practice, from a large hospital system down to a two-person office, has a different login reality: some have managed SSO, some sign in with ordinary email accounts. So onboarding reached out to each practice's technical contact and let them configure their own login paths and required security level, one or several, and the platform federated all of it. Keycloak ran as a full identity broker over many identity providers, with hierarchical role-based access deciding who could reach which system and do what once inside.
What we built
- An aggregation and workflow layer, not a data store. Little claims data sat at rest; the platform brokered governed access to the systems of record (claims backend, repricing, provider network) and let people commence workflows across them from one view. It reached each system however that system allowed: an API where one was exposed (most of them), direct database access where a system was internal and had none. You integrate with what's in front of you.
- Per-tenant federated identity. Keycloak as identity broker: each tenant configures its own IdP(s) and security posture; a single person can act across multiple practices, scoped per context by role.
- A file-sharing service added later, with resource access granted through Keycloak's authorization rather than a bespoke permission system.
- An architecture-judgment call we'd make again: the build started on a hosted auth product (Clerk) and hit its ceiling, not just on role count, but because the system needed to be a true identity broker federating many per-tenant IdPs, which a hosted simple-auth product structurally isn't. We migrated the whole identity layer to self-hosted Keycloak on-prem. The migration was forced by the architecture, not a preference.
Compliance: proven, not claimed
HIPAA compliance was a requirement, and we don't assert compliance as a claim about our own work:
- Full compliance checklist across access controls, encryption, and audit.
- An independent third-party consultant validated the compliance posture after build.
- An independent third-party penetration test was run against it.
At this scale, self-attested security isn't security. We'd have insisted on the outside audit and pentest even if the contract hadn't.
Outcome
- Delivered the platform an insurer required as a condition of its contract.
- Live across multiple states, hierarchical-multi-tenant by design, more onboarding when we rolled off.
- Passed independent compliance validation and penetration testing.
The reason this one matters isn't the stack. An insurer's lawyers decided the system had to exist, three kinds of organization decided to run on it, and an independent auditor decided it was sound. External parties with something to lose put their weight on it.