Case study 03
in developmentAdmin module
Case access administration for Tiger LIS, scoped zero to one and now in final QA ahead of production release.
Context
The admin module gives client services direct control over facility, account, and user administration in Tiger LIS, including who can see which cases. The role legend built into the module names the Standard User role as the client services team specifically, which is the clearest signal of who this was scoped for.
Before this module, case access was governed by manual overrides embedded directly in Tiger LIS, with no dedicated place to manage facility, account, or user administration at all. That made case access the single biggest HIPAA and compliance risk in the system: it depended on a chain of moving parts rather than a system anyone owned.
The problem
Case access moved every time a physician's relationship to a facility, client, or case changed, and each of those moves ran through a manual override in the legacy system rather than a managed permission. That's where it broke down: physicians routinely lost access to cases that were still theirs to see, not because anyone revoked it deliberately, but because nothing tracked the override once it was made.
Why this and not something else
Case access in healthcare doesn't reduce to a simple permissions table. The module treats conditional case visibility as its own epic rather than a checkbox on a user record, logs every admin action with actor identity and a timestamp, invalidates a user's sessions globally and immediately on deactivation rather than waiting for a token to expire, and enforces a role hierarchy so a Standard User can't grant access a Power User hasn't already been granted.
The simpler path would have been patching role-based access directly into Tiger LIS, which had none. I rejected it: Tiger LIS is a monolith where even quick changes are difficult to ship safely, and building inside it would have tied every future access change to that system's release risk. A separate module meant we could build and ship access control features that had never existed in the LIS at all, and keep iterating on them without touching the legacy system underneath.
Decisions and tradeoffs
I scoped the product from zero: 86 items structured under 8 epics, facility and account management, user management and credentialing, role-based access control, Tiger LIS integration, conditional case visibility, impersonation and support tooling, audit logging and security, and admin UI and navigation.
The requirements that took the most work weren't inside this module at all: a dedicated Tiger LIS API client service layer, credential and access sync back to the LIS, real-time NPI and email duplicate checking, and account-number lookup against existing facilities. Those had to be precise enough to hold across two codebases, not just one.
After the initial build, I ran a structured feedback loop rather than fielding stakeholder feedback ad hoc: I converted it into a formal intake epic that produced 14 refinement stories in a single cycle. Feedback became backlog, not noise.
Constraints
Every admin action needed an audit trail with actor identity and a timestamp, not just a change log. Deactivating a user had to invalidate their sessions globally and immediately, not on next token refresh. Role hierarchy had to be enforced in the data model, not just the UI, so a lower-privileged role can't be scripted into granting access above its own level.
Outcome
The first sprint carried the entire foundation: wizard-based facility setup, user CRUD with duplicate prevention, RBAC, impersonation sessions, and the Tiger LIS integration layer. The module is now in final QA ahead of production release. The business outcome, admin task time reduced, support tickets deflected, onboarding time for new facilities, isn't measurable yet: it will be added once the module ships and there's usage data to point to.
What I'd do differently
Zero to one in an integration-heavy environment means your requirements are only as good as your understanding of the other system. Writing the Tiger LIS integration stories forced the deepest product discovery of the project. The module hasn't reached production yet, so the fuller answer to this question is still ahead of me. I'm looking forward to what it teaches me once it's out.
Open to technical product management roles.