Healthcare Compliance Platform

A healthcare employer needed one place to manage compliance and wellness for thousands of employees, each in a different situation. This project combined several systems into one while modernizing the technology, improving processes, and providing a better user experience. The platform has two parts: an internal admin app where the admin team does their work every day, and an employee portal where people see what they need to do, what they have completed, and whether they are compliant for their job. Below, I walk through the high level of the platform, then go deeper on one part, an annual wellness incentive program.

I designed the admin and employee UI in Figma before writing code and used them to get quick feedback and buy-in from the client. It is hard for a client to say what they want or don’t want until they see a visual. A mockup is a quick way to get everyone on the same page and rules out a lot of guesswork. Changing a design is much cheaper than changing a build.

Every card on the portal dashboard is configured in the admin app. The admin team chooses which cards exist, which section each belongs to, the order they appear in, and whether each is active. When priorities change during the year, they change the dashboard themselves.

On the portal, each employee sees only the sections they are allowed to see, which could be one section or all three. The content of each card comes from that person's own data: what they have completed, and whether they are compliant for their job. Changes are made by the admin team and take effect without a code release.

The wellness incentive program is one area I worked on in the app and is a good example of how the whole platform is meant to work: the admin team configures it; employees see the configurations in the portal. Employees complete actions to reach reward levels and earn benefits for completing the program. The admin side gives the admin team full control of how it is set up each year: dates, reward levels and amounts, the steps, the actions employees can choose from, and all the explanatory copy.

Starting a new year does not mean starting over. The admin team clones the previous year's whole configuration, then edits the dates, dollar amounts, and anything else that changed. Actions, reward levels, and steps can be added, updated, or deleted as the program evolves. A History tab keeps an audit log of every action taken in the admin app and who took it.

Employees see exactly what was configured: their current level, what each level earns, and the steps to reach the next one. One of those steps is a log of wellness actions, where people choose from a set of activities to reach the number required. Each action opens a detailed view that explains how to earn it, and some include short interactive quizzes.

The same idea runs through the rest of the portal. Page content is managed in the admin app too, with an edit and a history view for each page, so the admin team can update the words on the portal without waiting for a release.

The portal covers much more than the incentive program. Employees can also connect a health device, see their latest measurements, and chart them over time, with plain-language explanations of what each reading range means.

This is a healthcare system, so access control is built into the platform instead of added on top. Staff and employees sign in through the organization's existing Microsoft single sign-on, with no separate passwords to manage. Scheduled jobs that call the API use their own authentication scheme, separate from the one people use.

Permissions are fine-grained. Each API endpoint declares the one permission it needs, such as reading a particular kind of record, and the API turns the permissions on a user's roles into authorization policies as they are needed. The Angular apps mirror this with route guards that can be combined, so a staff member only sees and reaches the screens and actions their role allows. Secrets and environment settings live in a managed key vault and configuration service, not in the code.

Two smaller safeguards matter in a healthcare setting. The apps sign people out after a period of inactivity and every change made in the admin app is written to the audit log in the same database transaction as the change itself, so a record can never change without leaving a trace.

The system is composed of two Angular applications and two ASP.NET Core APIs, one pair for the internal admin app and one pair for the employee portal. Both APIs utilize the same layers underneath: services, Dapper repositories, SQL. Both Angular apps use the same shared component library. Reusing libraries instead of copying code meant a fix or a new feature in one place showed up in both apps as many patterns were shared between the two.

The front end is current Angular with standalone components and functional route guards. The shared library is a small design system built on PrimeNG: a data table with lazy loading, filters and sorting that persist during a session, CSV export, and row reordering, along with form controls, breadcrumbs, and audit history components. Shared services handle toast messages and HTTP calls, so errors look and behave the same everywhere.

Bulk work was a recurring need. The admin app has about ten file-driven workflows, such as importing users, adding roles, and loading service or reward records. Instead of ten one-off screens, they share one pattern: upload a file, validate it, preview the result, then submit. New imports reuse the same flow.

Audit writes taught me to match the strategy to the size of the job. Small sets of audit events go in as batched inserts, and once a write passes a threshold of 100 rows it switches to a bulk copy, which is much faster for large imports.

One production bug was hard to see. Validation failures return a 400 on purpose, but a malformed request body also returns a 400, and those were being lost among the expected ones. A small piece of middleware now tells them apart, so accidental 400s are logged as real errors. Validation also separates hard errors from warnings, which a user can acknowledge and continue past.

The API has two layers of tests. Fast unit tests mock the data layer at the controller boundary, and a separate suite runs against a real database. The pipeline leaves the slower suite out of the quick run, so every commit gets fast feedback.

The client approved GitHub Copilot for this project, and I used it throughout the two years of development. It sped up the work enough that we regularly finished sprint work early and pulled more into the sprint. Over that time, I built up a lot of hands-on experience with AI-assisted development: where it saves the most time, how to review what it produces, and where my own experience and judgment should override accepting the generated solution to just get a task done. There are many solutions of how a problem can be coded, but knowing if an AI generated solution is not quite right (too complex, not in line with previous coding standards, over-engineered, etc.) or spot on is key to maintaining ownership of a software product while keeping a quick pace of development.

I also supported the launch on site, working alongside the admin team while they moved onto the new system. Overall, I grew and learned a lot from this project and am a better designer, developer, and consultant from this work.