Simulating a Health-Tech Marketplace (into the multiverse) — SimPy
The Problem
I am a Product Manager for Wheel. We empower virtual care clinicians to work with greater flexibility, while providing digital health companies with the infrastructure and clinical workforce they need to deliver scalable, virtual care services nationwide. We provide the technology platform AND a network of clinicians. Every day, Wheel routes thousands of consults to a nationwide network of clinicians. It’s a living, breathing marketplace where we influence our supply to take on-demand consults. Starting a marketplace can be a lot of gut-science and sweat equity.
Evolving a marketplace to crawl, walk, learn, and run itself creates a lot of questions…
Q’s:
- How much supply do we need?
- What if our demand increased by X?
- Who is least/most critical to the network?
- What should we pay for a visit? How much can a clinician expect to earn?
- What is the ROI of a specific incentive?
- What if we routed differently? What algorithm is best?
- What if clinician A had a different license set or client set?
- What is the expected wait time for a patient at a given moment?
- Switchback Experiments — Parameter tuning.
The Network
A clinician in our network can be licensed in 1 state, 6 states, or they can be licensed in 23 states; a clinician can only see a patient in the state in which they are licensed. Each clinician in our network serves a different subset of clients and each client may have many insurers they work with. This creates a complex network and scheduling problem. For those new to Telehealth that means you could have a Nurse Practitioner that lives in Texas who can provide care in 15 other states they are licensed in. How do you provide timely care to patients in 50 states in a way that is cost effective?
Think about it this way: What is more complex?
- A network of clinicians with one state, one client, and one insurer
- A network of clinicians with every state, client, and insurer that exists
- A network of clinicians with a mix of states, clients, and insurers?
Option 1: simplifies how we understand capacity but it is also costly, especially if you don’t have enough demand for every hour of the day to fill a clinicians time.
Option 2: this would be amazing. Unfortunately each state has different regulations around how a Nurse Practitioner can practice. Some have strict geographical constraints. It makes this option impossible.
Option 3: the most complex and most likely option. The pros are the network effects of many licensed clinicians. The cons are the sub-set of networks this creates.
Below is a simplified depiction of our supply (clinicians) and demand (consults). How do you choose which clinician should take the consult? What order should the consults be taken in?
Visualizing the Network
Each red dot below represents a consult (patient needing care) and each of the dots surrounded by walls are the clinicians. What you don’t see are the characteristics of that consult and clinician. Each of these red dots can only be taken by a clinician with the right license and client set, they also have to be online (non-black dots). You will notice online clinicians sitting idle, while others are consistently utilized. These are the network effects at play in a given moment of time.
How do you supply plan for demand in a B2B Marketplace when it has these characteristics:
- It’s on demand — can be created at any instant OR can be scheduled ahead of time.
- No visibility into why demand might increase or decrease (we don’t know what our clients spend on marketing)
- A mix of low volume and high volume states — what should you do if you have a .012% chance of getting a consult in Texas on a Tuesday at 8AM?
Simulation
I like to think of a simulation like the multiverse. It isn’t an exact replica of what happened nor is it a crystal ball. It is more like a parallel universe that you can replay 1000 times. In Python we leverage a package called SimPy to simulate discrete events.
Marketplace Simulation
ChatGPT’s explanation of SimPY: SimPy is a process-based discrete-event simulation framework based on standard Python. It provides the modeler with components of a simulation model including processes, for active components like customers, vehicles or agents, resources, for passive components that form limited capacity congestion points like servers, checkout counters and tunnels, and events, which are discrete occurrences at specified times and upon which activities may be contingent (like the end of a process).
The Basics of SimPy:
There are a lot of great resources available if you are interested in learning more about the basics of SimPy. Unfortunately, SimPY’s documentation tends to be thin, they have some examples on their website but it can be quite the hurdle to jump into. I am not going to give an introduction to SimPy in this article — these folks below are invaluable in getting started in SimPy.
Below are some amazing resources that got me started.
Great article — intro to Simpy
This is the ultimate resource — Dr. Daniel Chalk — I watched these videos a ton. His Github is immensely helpful.
Chat GPT: Honestly, it stumbles through SimPy quite a bit but I couldn’t have built my simulation without it’s help.
In the next article, I will talk about some key requirements for simulating my Marketplace and what makes it different from traditional discrete event simulations.
