Peer Review for Proposal - Group 12: The Fool

[ZeakOptimistic]

Hi MyMedQL team,

We are Group 12. We reviewed your proposal "MyMedQL: Real-Time Patient Vital Monitoring & Anomaly Detection System.”

Overall, we think the idea is strong and very well aligned with a database-focused course. Below are our comments based on the suggested rubric.

---

1. Project originality

What works well

• The ICU-style real-time monitoring use case is meaningful and realistic, and the fact that you connect it to serious database work (triggers, partitioning, stored procedures, etc.) makes the project more interesting than a standard CRUD web app.
• We really like the idea of reproducible demo scenarios (stable → deterioration → recovery) driven by a simulator. That will make teaching, testing much easier.

Suggestions and potential issues

• From an end-user perspective, the system is quite similar to existing monitoring solutions. To highlight originality, it might help to emphasize one “flagship” database/analytics feature that typical systems don’t expose, for example:
  • an “audit view” that clearly shows which thresholds and device assignments led to each alert, or
  • a simple early-warning score / risk index computed via stored procedures.
• It would also help to clarify whether you see this mainly as a clinical tool or more of an educational / research demo. Stating that explicitly would make your main contribution clearer to readers.

---

2. Database and tech choices

What works well

• The planned core entities (Patient, Staff, Device, DeviceAssignment, Vitals, Threshold, Alert) cover the essential objects in this domain and are already described at a reasonable level of detail.
• You explicitly plan to use database features such as composite indexes on (patient_id, ts) and (device_id, ts), triggers for alert creation, stored procedures for analytics, and optional partitioning for the vitals table. This is very much in line with the goals of the course.
• Security choices like bcrypt hashing and parameterized queries make sense for handling medical data.

Suggestions and potential issues

• In the README, the backend and DB stack are written as “Node.js / Express or Python (Flask/FastAPI)” and “MySQL / PostgreSQL (optional TimescaleDB)”. For a 3-week project, keeping multiple options open may spread your effort too thin. We suggest:
  • Committing to one backend (e.g., Express) and one database (e.g., MySQL 8 only) for the actual implementation.
  • Leaving PostgreSQL/TimescaleDB as clearly labeled “future work” or bonus, rather than part of the main plan.
• You mention triggers that update Admission.status and a Notifications table, but Admission and Notifications do not appear in the core entity list. It would be clearer to:
  • either add these tables to the entity list/ERD and explain their role, or
  • drop them from the requirements if they are out of scope.
• Some attributes (like contact_info and device metadata) are stored as JSON. That’s fine, but it would be good to briefly indicate which queries will actually use those JSON field, so it’s clear why they are not fully normalized.

---

3. Clarity of the proposal

What works well

• The functional and non-functional requirements are well separated and detailed (CRUD operations, alert logic, performance targets, security, etc.).
• The three-week timeline with specific deliverables (ERD.png, sql/ddl.sql, simulator, backend, frontend, Docker Compose) gives a clear picture of how you plan to proceed.

Suggestions and potential issues

• It could be helpful to add a short “User flows” section for each role, for example:
  • Doctor: log in → select patient → view last 24h vitals and alerts → acknowledge alert.
  • Nurse: log in → see current alert list → mark alerts as handled.
  • Admin: manage staff, thresholds, and device assignments.
    This would tie the entities, UI, and requirements together more clearly.
• Since you mention encryption and strict RBAC, you might also specify which parts are absolutely required for the course deliverable and which ones are stretch goals.

---

4. Feature evaluation (realism and sufficiency)

What works well

• The planned features (real-time ingestion, alert triggers, stored procedures, dashboard with charts, simulator, RBAC) are more than sufficient to demonstrate meaningful database work and provide a useful system.
• The sensor simulator plus a performance target of 50 inserts/sec with sub-second reads shows that you are thinking about realistic workload, not just static data.

Suggestions and realism check

• The scope is quite ambitious for three weeks, especially with:
  • full RBAC,
  • encryption of sensitive fields,
  • WebSocket or MQTT real-time updates,
  • partitioning,
  • load testing, and
  • a React dashboard with multiple views.
• To avoid over-stretching, it may help to clearly distinguish:
  • Must-have for grading: core tables, basic CRUD, an alert trigger on vitals, at least 1–2 stored procedures and 1–2 views, a simple but functional dashboard, and basic RBAC.
  • Nice-to-have: partitioning, detailed performance benchmarking, full encryption, advanced UI elements, TimescaleDB integration, etc.
• The performance target of 50 inserts/sec sounds reasonable for your demo scale. To make it easier to verify, you could specify:
  • roughly how many simulated devices/patients that represents, and
  • which concrete queries you will use to measure “sub-second reads.”
    That would make your evaluation criteria very clear.

---

5. Positive feedback

• There is a strong database focus: you clearly plan to use indexes, triggers, stored procedures, and possibly partitioning, which fits the course objectives very well.
• The proposal is well structured and easy to follow, with separate sections for originality, requirements, entities, tech stack, and timeline.
• The division of roles within the team (backend, frontend, DB engineer, DevOps/QA) is clear and realistic.
• The idea of a scriptable sensor simulator and deterministic demo scenarios is excellent for reproducibility.

---

Summary

We think your proposal is technically strong and very well aligned with a DB-centric project. The main risks we see are scope creep and a few unclear entities/stack choices. If you commit to a single backend and database, finalize and publish an ERD, and clearly separate must-have vs. nice-to-have features, your plan will look very realistic and convincing.

Hope these comments are helpful as you refine the proposal!