DigiRezhim
Physician knowledge. Structured workflows.
Clinical nutrition decisions deserve structured tools, deliberate permissions and auditable workflows.
Patient records and nutrition rules need one reviewable workflow.
Physicians need to handle registration, patient context and diet planning in connected steps. Clinical nutrition workflows also depend on scientific rules that must be reviewed rather than hidden inside UI defaults.
- Physician identity and patient context
- Clinical rule exceptions require expert review
Four services, with distinct clinical responsibilities.
DigiRezhim separates public web, doctor and admin views, and API services. Next.js and NestJS use PostgreSQL, Prisma and Redis to connect access control, patient records and nutrition workflow entry points.
- Separate admin and clinical access surfaces
- Structured persistence for physician workflows
Clinical acceptance is not a code-only decision.
Repository documentation covers doctor dashboards and Excel-to-UI rule migration. Medical accuracy, unresolved source-data exceptions and production compliance still need physician and operational verification.
- Evidence: DigiRezhim repository and doctor dashboard
- No unsupported clinical efficacy or certification claims
Behind the decisions.
Explore the implementation context, technical trade-offs and evidence behind the three-part story. Open any chapter to read the full explanation.
0101 / CONTEXTFrom clinical knowledge to usable software.
DigiRezhim is a specialist clinical nutrition platform built around physicians, patient records, nutrition assessment and follow-up workflows.
The repository contains separate web and admin surfaces with distinct APIs. This separation reflects the needs of public users, physicians and administrative operations instead of forcing every role into a single interface.
The product has a documented history of converting scientific workbook logic into structured application forms and rules.
- Physician-first workspace
- Four application surfaces
- Structured nutrition knowledge
0202 / THE PROBLEMHealth workflows are more than forms.
Clinical nutrition work combines medical context, assessments, follow-ups and professional review. Spreadsheets may encode valuable rules, but the information needs explicit validation and traceable interactions when brought into software.
Physicians also require reliable account readiness, medical registration verification, controlled subscription access and visibility into their patient registry.
A polished interface must not conceal missing clinical evidence or imply that a software product is medically certified simply because its pages are present.
- Clinical context integrity
- Professional verification
- Responsible claims
0303 / ARCHITECTUREFour surfaces with defined responsibilities.
The source documents a public web runtime, an administrative web runtime, a public NestJS API and a separate administration API. The supporting stack includes Next.js, React, TypeScript, PostgreSQL, Prisma and Redis.
Service boundaries distinguish what belongs to the physician workspace from platform management. Data storage, session handling and development infrastructure are documented separately from visual components.
The architecture makes the clinical experience part of a larger operational platform, not merely a set of static nutrition screens.
- Next.js and NestJS
- PostgreSQL / Prisma / Redis
- Public and administrative boundaries
0404 / PHYSICIAN EXPERIENCEA dashboard that reflects professional context.
The doctor dashboard reads server-backed identity, profile, verification and subscription state. It displays access information rather than manufacturing a healthy or active account status on the client.
Its patient digest comes from a protected patient-list endpoint, with request error states and authenticated navigation. The interface distinguishes real records from unavailable data.
Profile readiness and professional registration influence what the physician can do. That makes permissions and accurate feedback an essential part of UX, not an afterthought.
- Authenticated dashboard state
- Patient list and digest
- Verification and access status
0505 / CLINICAL PATHWAYSFrom intake to follow-up.
The documented nutrition engine work translates existing scientific material into a series of controlled application pathways for different patient contexts.
Intake, medical history, clinical review, nutrition risk factors and plan building form a longitudinal process. Each step requires careful treatment of missing fields, validation and professional interpretation.
For that reason this case study describes supported source workflows without displaying patient-specific values, sample diagnoses presented as real, or unverified treatment outcomes.
- Structured patient intake
- Configurable decision pathways
- Longitudinal follow-up
0606 / CURRENT STATEClinical confidence must be earned.
The repository documents its software structure, migration history, routes and physician operations. Those are useful evidence of implementation scope.
They do not independently establish regulatory compliance, clinical efficacy, deployment readiness or successful real-world patient outcomes. Each of those questions needs separate specialized verification.
The design goal remains clear: a restrained professional experience where complex workflows are navigable and every consequential state is explained.
- Documented implementation
- Clinical validation separate
- No invented patient metrics
What is actually verified.
The repository documents a clinical nutrition system, an Excel-to-UI migration and physician administration workflows. Production readiness and clinical compliance are not presented as independently certified.
The overview explains documented implementation decisions. Production results and customer outcomes require separate verification.