Case study

Encoding complex care protocols into guided workflows

Turning different medication-program requirements and nurse protocols into configurable software behavior.

Organization: Human Care Systems, Inc.
Role: Associate Software Engineer
Timeframe: 2020–2021

Patient-support programs often look simple from the outside: onboard a patient, provide information, communicate with them, and support treatment adherence.

Underneath, different pharmaceutical programs can have different protocols, treatment stages, tasks, prompts, and information requirements. At Human Care Systems, my work involved turning those program rules into configurable software behavior.

01 · The product problem

One platform had to express different care programs.

A shared product needed to support distinct protocols and treatment stages without making every client implementation an entirely separate product.

Conceptual model

The configuration problem

Shared platform

Different programs

Different protocols

Different treatment stages

Configurable product workflows

The same product foundation needed to support meaningful differences between programs.

02 · My role

Translate rules into full-stack behavior.

As an Associate Software Engineer, I translated nurse protocols and medication-program requirements into workflows supporting patient onboarding, communication, medication management, and treatment-stage-dependent behavior.

That meant connecting interface states, backend rules, and care-team workflows rather than treating each feature as an isolated screen or endpoint.

4+pharmaceutical clients served by the platform

03 · Platform thinking

Configuration instead of duplication

Shared capabilities could stay reusable while program rules expressed distinct requirements. This reduced the need to rebuild the same product foundation for each implementation.

Conceptual model

Shared foundation, distinct workflows

Shared platform

Configurable rules

Program A

Workflow A

Program B

Workflow B

Program C

Workflow C

This is a product concept, not a claim that the platform provided a no-code system.

04 · Translation

From protocol to product behavior

The central product task was translating a domain expert's protocol into requirements the interface and backend could represent consistently.

Conceptual model

Translating domain rules

Clinical / nurse protocol
Product requirement
Business rule
Interface + backend behavior
Care-team workflow

Each step makes an implicit protocol more explicit and testable.

What I learned

Requirements become real as system behavior.

Working on configurable healthcare workflows taught me to think about the connection between business rules, user experience, and technical architecture. A requirement is only complete when the system can represent it and a person can use it.