Industry

Healthcare

Client

Tekhne SA

Year

2023

Affiliate Portal for Transitory Members Between Health Insurance Providers

Web portal for managing the registration and transfer of transitory affiliates based on agreements between different social health providers across the country.

The Challenge

This project emerged from the need to organize the registration of transitory members moving between social health providers (often across provinces), based on pre-established agreements. It was developed as part of a larger ongoing system, so the technical architecture (a web app with a side panel) had already been defined by the development team due to technical requirements.

The Process

Discovery phase

Discovery phase

Discovery phase

User Research and Data

To give context, this software enables the management of affiliate reciprocities based on formal agreements between different social health providers. These agreements specify the coverage rules for each case. Without agreements, there’s no reciprocity. There was no pre-existing platform for this kind of management—it was a clear development opportunity. The dev team had drafted an early structure and brought us in at that point to collaborate and iterate.

Discovery phase

Discovery phase

Discovery phase

Insights

In our first analysis, the main screen featured a sidebar showing only the list of health providers, with unclear actions beyond adding a new provider or downloading data. Since the providers were always the same and didn’t change, we proposed automatically syncing them from the organization’s database—removing the need for manual entry and reducing operational time.

Users could initiate transfer requests from either their origin or destination healthcare provider — requiring dual-entry logic

The system had to allow users to start a request from either their current (origin) or target (destination) healthcare provider. This flexibility added complexity to the backend flow and required clarity in how roles and permissions were managed across institutions

Users could initiate transfer requests from either their origin or destination healthcare provider — requiring dual-entry logic

The system had to allow users to start a request from either their current (origin) or target (destination) healthcare provider. This flexibility added complexity to the backend flow and required clarity in how roles and permissions were managed across institutions

Users could initiate transfer requests from either their origin or destination healthcare provider — requiring dual-entry logic

The system had to allow users to start a request from either their current (origin) or target (destination) healthcare provider. This flexibility added complexity to the backend flow and required clarity in how roles and permissions were managed across institutions

Each affiliate transfer required a pre-existing agreement between institutions before the request could proceed

Transfers were only valid if a formal agreement (convenio) already existed between the two entities. Without this contract in place, the request could not be processed

Each affiliate transfer required a pre-existing agreement between institutions before the request could proceed

Transfers were only valid if a formal agreement (convenio) already existed between the two entities. Without this contract in place, the request could not be processed

Each affiliate transfer required a pre-existing agreement between institutions before the request could proceed

Transfers were only valid if a formal agreement (convenio) already existed between the two entities. Without this contract in place, the request could not be processed

Every transfer request had to be manually reviewed and approved or rejected due to additional documentation checks

Staff from both entities were responsible for manually validating documents and eligibility for each transfer request. This was not an automated workflow — human intervention was required

Every transfer request had to be manually reviewed and approved or rejected due to additional documentation checks

Staff from both entities were responsible for manually validating documents and eligibility for each transfer request. This was not an automated workflow — human intervention was required

Every transfer request had to be manually reviewed and approved or rejected due to additional documentation checks

Staff from both entities were responsible for manually validating documents and eligibility for each transfer request. This was not an automated workflow — human intervention was required

Develop phase

Develop phase

Develop phase

Wireframes, Flows, Conceptualization

Organizing the Registration of Transitory Affiliates Once access to key data was clear, we focused on how to structure and categorize the registration of transitory affiliates. The developers had not yet explored this, so we began with general diagrams to understand the problem. One key complexity: affiliates could request reciprocity either at the origin or destination health provider. Internally, this was referred to as "departing" or "arriving"—which created confusion depending on who was managing the request. Some providers also processed requests manually, which added to the variability. Understanding the Complexity To better grasp the situation, we created diagrams mapping different scenarios and actors involved: the affiliate, the origin provider, and the destination provider. Through this, we identified a major confusion: terms like “sent” and “received” requests didn’t always align with “departing” or “arriving” affiliates. For example, someone might send a request but end up receiving the affiliate.

Develop phase

Develop phase

Develop phase

Unfolding the solutions

Iterating on the Language Even after sharing the system with stakeholders and developers, confusion persisted—particularly around terms like "sent" requests. After multiple iterations, we landed on a simpler and more effective distinction: internal vs. external affiliates. Internal: members of the provider’s own network. External: affiliates from other providers. This clarified responsibilities. For example, if someone from our network requests coverage in another province, they’re still internal. If someone from another provider approaches us for coverage, they’re external. Iterating Through Wireframes Once we resolved the language and flow challenges, we moved into wireframing multiple UI options. After reviewing technical constraints with developers, we agreed on using tabs to distinguish request types. One early wireframe allowed users to approve or reject requests directly from the main screen, but we ultimately opted for a secondary window triggered by a "respond to request" button to keep the interface cleaner. Final Design The final interface clearly grouped all requests requiring a response, displaying a count of pending requests so users could quickly take action.

What We Learned The use of information architecture diagrams proved extremely helpful in making sense of multiple edge cases and shaping a coherent solution. Another key insight was the importance of language: poor semantics can compromise an entire system’s clarity. Defining terminology clearly and aligning team understanding early on is essential. What Could Be Improved The UI for request management could be further refined to better highlight key information and streamline actions.

‹ Debt Payment and Refinancing

Other Projects.