A patient and care-team portal developed from a college Computer Architecture & Parallel Processing (CAPP) project, aligned with SDG 3 — Good Health and Well-being.
The application provides accounts, durable care records, appointment requests, private doctor/patient conversations, and follow-up tasks. Its original dark artwork, glass surfaces, Instrument Serif headings, GSAP transitions, and Lenis scrolling remain. Simulation and the Java multithreading laboratory are disabled by default and can be enabled explicitly for teaching.
The portal workflows save and retrieve actual user-entered information. Automated risk scores still use simplified teaching rules and are not validated for clinical decisions. Public hosting, clinic/provider onboarding, account recovery, delivery services, and an operational privacy/security review remain separate work; a code update does not activate those services.
| Area | Features |
|---|---|
| Patient | Registration, login, profile, six vital signs, saved history, risk scores, own alerts |
| Doctor | Patient search, risk filters, latest readings, full profile details, recent history, alert acknowledgement and resolution |
| Administrator | Patient creation/edit/deletion, doctor account creation/access revocation, statistics, performance experiments |
| Monitoring | Periodic synthetic measurements, scenario selection, chart, persisted readings and threshold alerts |
| Processing | Actual sequential loop and ExecutorService thread pool; 100, 500, 1,000, 5,000 or 10,000 records |
| Measurement | Wall time, process CPU time, active tasks, thread schedule, speedup, time saved, result checksum verification |
| Charts | Latest risk distribution, recent records/alerts, execution time vs dataset size, speedup vs size, mode comparison |
| Access control | BCrypt passwords, server sessions, CSRF protection, role checks, patient ownership checks, immediate disabled-account revocation on next request |
| Care record | Allergies, history, visit questions, medication list, trends, printable summary, CSV export |
| Appointments | Patient requests, assigned-doctor/admin confirmation, cancellation/completion, overlap checks, calendar export |
| Messages | Patient/addressed-doctor/admin access only, replies, unread tracking, paginated history, disabled-doctor protection |
| Follow-up | Personal or care-team tasks, due dates, overdue indicators, complete/cancel/reopen, version checks |
| Practice tools | Disabled by default; explicitly enabled admin synthetic profiles and measured benchmarks |
The default database is embedded H2 on disk. MySQL is not required. The previous Python implementation is retained only in legacy/ and is not used by the rebuilt application. The browser-only fallback and illustrative benchmark numbers have been removed. Read Patient portal research, Deployment without MySQL, and the classroom demo guide.
Requires Docker with Compose.
cp .env.example .env
# Edit .env: set your database passwords and an admin email/password.
docker compose up --buildOpen http://localhost:8080. The Docker image serves the React application and Java API together, so session cookies and CSRF tokens share one origin. Embedded database files are retained in the health-data volume. No default administrator password is embedded in the app.
ADMIN_EMAIL and ADMIN_PASSWORD create an administrator on the first startup for that email. Use a password of 12–72 characters. Later changes to those variables do not reset an existing account. Sign in as administrator to create doctor accounts; patients self-register.
docker compose down stops the services while retaining records. Deleting the database volume deletes those records. For a public deployment, put the application behind HTTPS, set COOKIE_SECURE=true, and provide secrets through the hosting platform.
Requirements: Java 21, Maven 3.9+, and Node.js 22. No database installation is needed. Set JAVA_HOME to a Java 21 installation if another Java version is the system default.
Export the data directory and bootstrap settings in your shell:
export DATA_DIR="$PWD/local-health-data"
export DATABASE_PASSWORD='your-database-password'
export ADMIN_EMAIL='your-admin-email@example.com'
export ADMIN_PASSWORD='your-admin-password-at-least-12-characters'
mvn -f backend/pom.xml spring-boot:runThe backend listens on port 8080. Practice tools default to disabled. Set PRACTICE_TOOLS=true only for classroom demonstrations or the complete browser verification suite. JPA creates/updates the schema; a maintained production deployment should use reviewed migrations.
The previous explicit demo profile remains available for existing local demo files:
mvn -f backend/pom.xml spring-boot:run -Dspring-boot.run.profiles=demoThis uses backend/data/ and a blank local database password, for compatibility with earlier local demos. For new work use the default configuration and DATA_DIR above. The application never silently switches storage when an API call fails. Hosted deployments must use the documented persistent disk and protected database settings.
In another terminal:
npm ci --prefix frontend
npm run dev --prefix frontendOpen http://localhost:5173. Vite proxies /api to port 8080. The optional frontend/.env should use VITE_API_URL=/api; cookies and API calls are designed for the same origin. No API keys belong in frontend environment variables.
sh scripts/build.sh
java -jar backend/target/smarthealth-2.0.0.jarThe same database/admin environment variables apply. The combined JAR serves the UI at port 8080 and supports direct navigation to every application page.
The historical vercel.json still builds the static frontend. A static Vercel deployment alone cannot run this Java application with durable storage. Use the combined container/JAR on a Java-capable host with a persistent disk. A missing backend is shown as a connection error, never replaced with fake results. See the optional Render blueprint and deployment instructions.
- Register a patient, create a profile, and enter normal example readings: HR 75, BP 115/75, temperature 36.8°C, SpO₂ 98%, glucose 90, breathing 16/min.
- Save another reading with SpO₂ 88%. Its educational risk becomes Critical and a low-oxygen alert appears.
- Sign in as a doctor created by an administrator. Find that patient, inspect history, acknowledge and resolve the alert.
- Open Monitoring, select the patient, and start the critical oxygen scenario. Pause it after a few readings. These are explicitly marked as simulations in history.
- Open Processing as doctor/admin. Compare the supported dataset sizes using the same seed and thread count. Repeat each run; inspect charts, schedule, CPU information, and the history table.
- Explain why parallel execution may be faster for larger workloads and slower for smaller ones. Do not promise a speedup on every machine.
ParallelHealthProcessor generates an immutable seeded dataset. Each task performs the same six vital checks and a disclosed CPU-only mixing loop of 12,000 iterations. That loop models computational work for teaching; it is not a clinical algorithm. Its result contributes to a 64-bit checksum, preventing the calculation from being discarded as unused.
- Sequential mode loops through the dataset on one thread.
- Parallel mode submits one
Callableper record to a fixed pool and collects everyFuture. The pool is shut down in afinallyblock. - Timing uses
System.nanoTime(). Dataset generation and database writes are outside the timer. Parallel timing includes pool creation, submission, and result collection; shutdown occurs afterward. - A 50-record sequential warm-up precedes the measured run. Comparisons measure sequential first, then parallel. JVM compilation, order, other applications, CPU limits, and scheduling overhead can influence results.
- Both modes must produce identical checksums before a comparison is saved. The server enforces this using full-width Java integers; the browser receives checksums as strings to preserve precision.
speedup = sequentialTime / parallelTime;timeSaved = sequentialTime - parallelTime. Negative time saved is displayed honestly.- Only one benchmark runs per server instance at a time. Other attempts receive HTTP 409. Thread count is limited to 1–32, defaulted in the UI to the server's available logical processors (capped at 32).
- Thread charts show actual timings for the first 100 records; every record is still processed. CPU time is process-wide, includes other JVM work, and may have coarse resolution. CPU load is a recent sample, not a per-run utilization measurement.
- Benchmark charts use the latest comparison per dataset size from the most recent 100 saved runs. They start empty. Check thread counts before comparing points.
All thresholds are simplified teaching rules, not validated medical guidance. Each normal parameter scores 0, warning 60, critical 100. The rounded mean is raised to at least 26 for any warning or 76 for any critical parameter. This gives an explainable score without hiding an isolated critical signal.
| Score | Status |
|---|---|
| 0–25 | Normal |
| 26–50 | Attention Required |
| 51–75 | High Risk |
| 76–100 | Critical |
Exact parameter thresholds and boundary tests are in HealthAnalyzer.java and HealthcareIntegrationTest.java. Alert states are New → Acknowledged → Resolved; staff can also resolve directly. A resolved alert cannot be reopened through the transition endpoints.
# Backend integration, authorization, validation, risk boundaries, and all dataset sizes
mvn -f backend/pom.xml test
# Frontend production compilation
npm run build --prefix frontend
# End-to-end: start the app with a test-only administrator first
cd frontend
npx playwright install chromium
E2E_ADMIN_EMAIL='admin@example.test' E2E_ADMIN_PASSWORD='local-test-password-123' npm run test:e2eThe end-to-end test uses a dedicated test/demo database and creates synthetic patient/doctor accounts. It covers registration, profiles, readings, critical alerts, monitoring, role access, care records, medication lists, exports, appointments, a real benchmark, and pages at 375/768/1440px. Use PLAYWRIGHT_CHANNEL=chrome to test with installed Chrome, and APP_URL=http://localhost:8080 to test the combined JAR. CI also restarts the application and verifies that saved information survives.
The test profile creates and drops tables in a separate in-memory database. Never point TEST_DATABASE_URL at your application database. The compatibility database driver remains available for existing installations, but the default application, Docker Compose, hosted blueprint, and CI do not require MySQL.
backend/ Java 21 / Spring Boot application and integration tests
frontend/ Existing React UI, new authenticated pages and browser tests
docs/ Architecture, API reference, requirements and academic report
scripts/build.sh Build the React UI into an executable Java application
Dockerfile, compose.yaml Combined application with persistent embedded storage
legacy/ Archived Python backend and former UI verification scripts
Read Architecture, API reference, and PBL report for presentation and implementation details. The supplied prompt ends at the beginning of section 15; the About page and report cover the stated computer architecture concepts without assuming missing requirements.