Trust starts
at the boundary.
A healthcare operations platform for independent practices. A small first workflow, with a deliberate foundation.
Independent medical practices
Architecture & implementation
First working vertical slice
Shared infrastructure.
Separate practices.
Care IQ starts with a practical problem: give independent practices a connected home for patient and appointment workflows. Practices can share the platform, but the data boundary between them has to be explicit.
The first slice connects authentication, patient records, and appointment scheduling. That is enough surface area to work through identity, tenant context, relationships, and a usable interface together.
Make the boundary part of the system, then carry it through the workflow.
From identity
to integrity.
Select a stage to follow the practice context through the system.
Establish identity
The request begins with an authenticated identity and an active organization. Identity answers who is making the request; it does not, by itself, define which patient records are accessible.
Identity → authenticated user + organizationWhere does the practice ID come from?
The API resolves the active organization to a practice. It is not selected from an arbitrary practice ID in the request body.
Good choices
have costs.
Architecture becomes more useful when the tradeoffs are visible. These are the consequences of the structure in the current implementation.
01 A separate API boundary +
A versioned interface with data access and practice resolution in one place.
Separate deployment, cross-origin configuration, and care around contracts between the web app and API.
02 Database-enforced isolation +
Tenant policy alongside the data, with the practice included in patient–appointment relationships.
Correct database roles, consistent transaction context, and tests for denied and cross-practice access.
03 One complete workflow first +
A connected path through UI, identity, API, and database before the platform grows wider.
Restraint: features beyond the first patient and appointment slice remain future work.
A foundation
you can point to.
- Authenticated patient creation and listing
- Appointment creation and listing
- Next.js UI and versioned Express REST API
- Practice context, transaction-local configuration, and row-level security migrations
- Composite patient–appointment relationships that include the practice
- Version-controlled schema migrations
Implementation snapshot: the patient and appointment workflow is in active development. This report covers code and schema decisions; measured operational outcomes will be added when available.
Next.js · React · TypeScript · Tailwind CSS
Express · PostgreSQL · Drizzle · Clerk · pnpm
Have a boundary, a bottleneck, or a big next step?
Let’s talk it through ↗