The boundary is the feature.
Why practice context belongs inside the transaction.
Identity is the beginning.
An authenticated request tells a system who is asking. In a shared healthcare platform, that is only the first question. The next one is which practice the operation belongs to—and how that answer stays attached to the data access.
Care IQ resolves the active organization to a practice in the API. The frontend can express an intent, but it does not get to choose an arbitrary practice boundary.
Context has a lifetime.
A database connection can outlive a request. That makes the lifetime of tenant context an architectural concern, not a small implementation detail.
The current implementation establishes practice context inside the transaction using transaction-local configuration. The operation gets a bounded context. Data access needs to happen inside that same transaction.
Relationships need boundaries too.
Scoping a row is not the same thing as scoping a relationship. An appointment points to a patient, and that association should carry the practice boundary as well.
Care IQ includes the practice ID in the appointment-to-patient foreign key. The database constrains the relationship, rather than leaving the entire rule to application code.
A safeguard is a starting point.
Row-level security and referential integrity make useful guarantees only within the system that runs them. Roles, permissions, transaction discipline, and negative-path tests still need attention.
The architectural principle is simple: make the important boundary explicit in more than one place, and be precise about what each layer is responsible for.