How Healthcare Companies Use Data Structures to Grow Faster

# Patient index — the primary structure in any
# healthcare system.

class PatientIndex:
    def __init__(self):
        # Primary lookup: patient_id -> record
        self.by_id = {}
        # Secondary indexes for common alternate keys
        self.by_email = {}
        self.by_phone = {}

    def add(self, patient):
        self.by_id[patient["id"]] = patient
        if patient.get("email"):
            self.by_email[patient["email"]] = patient["id"]
        if patient.get("phone"):
            self.by_phone[patient["phone"]] = patient["id"]

    def get_by_id(self, patient_id):
        return self.by_id.get(patient_id)

    def get_by_email(self, email):
        pid = self.by_email.get(email)
        return self.by_id.get(pid) if pid else None

# What this proves in an interview:
# - You know that "fetch patient by id" is the #1 query,
#   and it must be O(1)
# - You understand secondary indexes — the same pattern
#   as a database index, done in memory
# - You keep the indexes in sync (the update path is
#   where bugs live in healthcare systems)

# This is the structure behind patient lookup in
# every hospital system you have ever used.

# Range query — "list all visits for a patient
# between two dates." This is a B-tree problem,
# not a linear scan.

import bisect
from datetime import datetime

class VisitTimeline:
    def __init__(self):
        # Append-only list of (timestamp, visit) pairs,
        # kept sorted by timestamp.
        self.timestamps = []
        self.visits = []

    def add(self, timestamp, visit):
        # Find correct position — O(log n) with bisect
        i = bisect.bisect_right(self.timestamps, timestamp)
        self.timestamps.insert(i, timestamp)
        self.visits.insert(i, visit)

    def visits_between(self, start, end):
        # O(log n) to find the start, then a slice
        lo = bisect.bisect_left(self.timestamps, start)
        hi = bisect.bisect_right(self.timestamps, end)
        return self.visits[lo:hi]

# What this proves in an interview:
# - You know that range queries need sorted data,
#   not a linear scan
# - You use bisect (which is binary search) to keep
#   insert and query fast
# - You understand why this matters: a patient with
#   10 years of visits should still return "last year's
#   visits" in milliseconds

# In production this is usually a B-tree-backed SQL index,
# but the reasoning is identical.

# Referral graph — model doctors and referrals as a
# directed graph. Very common in healthcare analytics.

from collections import defaultdict, deque

class ReferralGraph:
    def __init__(self):
        # adjacency list: doctor_id -> [referred doctor_ids]
        self.edges = defaultdict(list)

    def add_referral(self, from_doctor, to_doctor):
        self.edges[from_doctor].append(to_doctor)

    def reachable_specialists(self, doctor, max_hops=3):
        """Which specialists are reachable within N hops?"""
        visited = {doctor}
        queue = deque([(doctor, 0)])
        specialists = set()

        while queue:
            current, hops = queue.popleft()
            if hops > 0:
                specialists.add(current)
            if hops == max_hops:
                continue
            for neighbor in self.edges[current]:
                if neighbor not in visited:
                    visited.add(neighbor)
                    queue.append((neighbor, hops + 1))

        return specialists

# What this proves in an interview:
# - You model relationships as a graph, not as rows
# - You use BFS — the right tool for "reachable within N"
# - You bound the search with max_hops, which is how
#   production systems avoid runaway queries on large graphs
# - You know why "who referred whom" cannot be modelled well
#   as a simple list

# Referral network analysis is a real use case — it lets
# healthcare companies find gaps in specialist coverage,
# optimise patient routing, and identify referral bottlenecks.

# Emergency triage — a max-heap on severity.
# The next patient to be seen is the most urgent one.

import heapq

class TriageQueue:
    def __init__(self):
        # We invert severity because heapq is a min-heap.
        # severity 10 = most urgent, 1 = least urgent.
        self._heap = []
        self._counter = 0  # tie-breaker for FIFO within same severity

    def add_patient(self, patient_id, severity):
        # Push negative severity so the highest priority
        # comes out first.
        heapq.heappush(self._heap, (-severity, self._counter, patient_id))
        self._counter += 1

    def next_patient(self):
        if not self._heap:
            return None
        neg_severity, _, patient_id = heapq.heappop(self._heap)
        return patient_id, -neg_severity

# What this proves in an interview:
# - You know that triage is a priority problem, not FIFO
# - You use the counter to keep FIFO order within
#   the same severity level (a real-world requirement)
# - You handle tie-breaking explicitly — the subtle part
#   that pure "sort by severity" gets wrong

# In a real ER, this is the structure behind "who goes
# next" — and it changes minute by minute as new
# patients arrive and severities are re-assessed.

# Bed allocation — interval tree to find a free bed
# in a given time window.

import bisect
from collections import defaultdict

class BedAllocator:
    def __init__(self, num_beds):
        # For each bed, a sorted list of (start, end) intervals
        # representing occupancy. Using sorted lists + bisect
        # approximates an interval tree — good enough for
        # hundreds of beds; production would use a real tree.
        self.occupancy = {i: [] for i in range(num_beds)}

    def book(self, bed, start, end):
        intervals = self.occupancy[bed]
        i = bisect.bisect_right(intervals, (start, end))
        # Simple overlap check — the real version would use a
        # proper interval tree, but the reasoning is identical.
        if i > 0 and intervals[i - 1][1] > start:
            raise ValueError("Overlapping booking")
        if i < len(intervals) and intervals[i][0] < end:
            raise ValueError("Overlapping booking")
        intervals.insert(i, (start, end))

    def first_free_bed(self, start, end):
        for bed, intervals in self.occupancy.items():
            # Check if the requested window overlaps any booking
            i = bisect.bisect_right(intervals, (start, end))
            if (i == 0 or intervals[i - 1][1] <= start) and (
                i >= len(intervals) or intervals[i][0] >= end
            ):
                return bed
        return None

# What this proves in an interview:
# - You know that "first free bed" is an interval overlap
#   problem, not a simple equality check
# - You use sorted lists + bisect to keep operations fast
# - You understand the trade-offs (simple version vs.
#   real interval tree)
# - You can explain why naive "for each hour, for each bed"
#   approaches break at scale

# Healthcare companies use this pattern for beds, surgical
# suites, and equipment — anywhere scheduling overlaps
# matter.

# Trie — fast prefix search for ICD-10 diagnosis codes.
# Healthcare coders search by typing a few characters;
# they expect instant suggestions.

class ICDTrie:
    def __init__(self):
        self.children = {}
        self.code = None  # full code at leaf

    def insert(self, code, description):
        node = self
        for ch in code:
            if ch not in node.children:
                node.children[ch] = ICDTrie()
            node = node.children[ch]
        node.code = (code, description)

    def search_prefix(self, prefix):
        """Return all codes starting with prefix."""
        node = self
        for ch in prefix:
            if ch not in node.children:
                return []
            node = node.children[ch]
        return self._collect(node)

    def _collect(self, node):
        results = []
        if node.code:
            results.append(node.code)
        for child in node.children.values():
            results.extend(self._collect(child))
        return results

# What this proves in an interview:
# - You know that prefix search is a trie problem, not a
#   LIKE query problem
# - You can explain why "SELECT * WHERE code LIKE 'E11%'"
#   is much slower than a trie
# - You understand that ICD codes are hierarchical
#   (E11.9 is a child of E11), which matches the trie shape
# - You can name the time complexity: O(prefix + results)

# Healthcare UI coding tools rely on this pattern to give
# coders instant feedback as they type.

# Union-Find — patient cohorts for population health
# and risk scoring.

class UnionFind:
    def __init__(self):
        self.parent = {}
        self.rank = {}

    def add(self, x):
        if x not in self.parent:
            self.parent[x] = x
            self.rank[x] = 0

    def find(self, x):
        # Path compression — flatten the tree as we go
        if self.parent[x] != x:
            self.parent[x] = self.find(self.parent[x])
        return self.parent[x]

    def union(self, x, y):
        rx, ry = self.find(x), self.find(y)
        if rx == ry:
            return
        if self.rank[rx] < self.rank[ry]:
            rx, ry = ry, rx
        self.parent[ry] = rx
        if self.rank[rx] == self.rank[ry]:
            self.rank[rx] += 1

    def cohort_size(self, x):
        root = self.find(x)
        return sum(1 for p in self.parent if self.find(p) == root)

# What this proves in an interview:
# - You understand union-find and path compression
# - You can explain why it's faster than naive BFS for
#   repeated grouping queries
# - You know healthcare use cases: grouping patients by
#   provider, geography, or condition for cohort analysis
# - You can name the near-constant time complexity

# Union-Find is used heavily in population health to answer
# questions like "how many patients in this risk cohort
# are also covered by this provider network?"