A clear starting point
for the platform.
Thanks for sharing the documents. I have reviewed the MOH PX flow and the technical guide generated from it. I am using the guide as a starting point and choosing the implementation that fits the work best.
Start with the complete process
I am keeping the first version focused on the main survey workflow. The aim is to make it useful from the start and keep it easy to maintain, then build on it as the needs become clearer.
In the first version
- Selected services and versioned survey templates
- One import format and one message provider
- Validation, recipient selection, and safe retries
- Saved drafts, access permissions, and basic reports
- Verified calculations, backups, and recovery
Room to add later
- More sectors and source integrations
- Several messaging channels
- AI analysis of comments
- Advanced survey and formula builders
- Detailed improvement-plan workflows
What I am taking from the MOH flow
More than one way to receive data
The document describes APIs, uploaded files, and sources that provide completed survey responses directly. I am accounting for both service records and imported responses in the initial design. It also separates validation, sampling, SMS surveys, and phone surveys.
Scheduling belongs to the service
The Mawid example sends an SMS three hours after receiving a record, with dispatch every thirty minutes between 6 AM and 10 PM. Manual uploads use an hourly schedule. I am using these as examples for scheduling, rather than applying one fixed schedule to every service.
Keep contact details separate from results
The reference describes deleting Excel files after processing, storing names only for inpatient and pediatric inpatient services, and deleting names and phone numbers after six months while retaining survey results. I am working these points into storage and deletion, including files and backups.
Source: MOH PXMP Data Operation Flow v1.0, collection diagrams and data lifecycle policies. The timings and retention periods describe the reference operation. The schema below is my proposed design, not a schema supplied by MOH.
The technical direction
I am choosing around the actual workload and the tools I can maintain comfortably. The technologies in the generated guide are suggestions; they do not lock us into one stack.
PostgreSQL with PrismaInitial direction
PostgreSQL fits the surveys, invitations, answers, and reports. Prisma should make normal database work easier to write and maintain with a TypeScript backend. I will still handle organization isolation, relationships, and reporting queries explicitly.
React / Next.js and the backendBeing defined
I am choosing between React with a separate backend and Next.js with the main backend logic in one application. NestJS is a reasonable option if the backend needs that structure. I am keeping business rules in one place and avoiding unnecessary applications.
Background tasksBeing defined
Imports and sending invitations will run in the background. I am comparing a queue that uses PostgreSQL with Redis and BullMQ. Using our existing database could mean fewer services to maintain. Either approach needs durable progress, safe retries, and a way to check uncertain message-delivery outcomes.
Scoring and report historyBeing defined
I am keeping calculations separate from the screens, in a shared library initially. I am working through missing answers, N/A, weights, and rounding, then checking reference examples. Each measurement run will record its rules and deidentified inputs so the result can be explained later.
File storage and operationsBeing defined
I am working through private file storage, hosting location, retention, expected capacity, running costs, and recovery. Uploaded files and personal details need an intentional lifecycle. Backups need a tested restore procedure.
The parts I am working through
These are the next design tasks I am taking forward. I will document the choices and check them against the workflow as the first version takes shape.
- Visits and contact details
Keep repeat visits separate and handle shared phone numbers without treating a phone number as a unique visit.
- Imports and corrections
Define the format, required fields, validation errors, duplicate handling, and corrected records.
- Selection and timing
Record eligibility, sampling, send windows, and the rules for avoiding repeat invitations.
- Delivery and survey progress
Keep message attempts, provider results, response progress, and link expiry separate.
- Saving answers
Make drafts recoverable after an interrupted connection and repeated submissions safe.
- Calculations and reporting
Define score rules, response-rate counts, minimum group sizes, and the inputs included in each report.
- Access and deletion
Limit staff access and remove personal details without losing useful survey results.
- Running the platform
Work through hosting, storage, capacity, costs, backups, support, and handover.
The initial database design
Sources and import batches lead to service visits. Contact details sit separately so they can be deleted. Published survey versions contain the questions; invitations track delivery; responses hold the answers. Completed responses can also enter directly from a source.
This is the core model, not the complete production schema. All owned data is organization-scoped. Authentication, audit, queue, and full sampling tables are omitted from this view. Personal links will be removed when retention requires it; retained measurement inputs must be deidentified.
What ready will mean
Before calling the first version ready, I will check the full workflow with representative data. Counts and calculations should match, permissions should work, interrupted answers should resume, background tasks should recover, and backups should restore.
I am keeping the number of services small and documenting how to run and restore the system. The source code, setup instructions, and operating notes will be ready for handover.
This brief describes the planned build. It does not claim the production platform is already implemented.