Short answer
RaftLabs built PDC, a remote patient monitoring platform for a US healthcare startup, enrolling 25+ clinics in 60 days (client-reported) with support for 4+ wearable device types including CGM and BPM monitors. The platform provides real-time vital sign alerts, role-based access for admins, providers, patients, and specialists, and AWS-backed storage on HIPAA-eligible infrastructure under a signed BAA. Built in 14 weeks, it serves pre- and post-surgery patients as well as elderly patients receiving at-home care.
The situation
A team of healthcare entrepreneurs came to us with a specific problem. Elderly patients and post-surgery patients were making in-person clinic visits they did not need. The visits were scheduled not because the patient needed to be seen, but because the provider had no other way to check on them. There was no system to collect health data at home, send real-time alerts, and give providers visibility without a face-to-face appointment.
They wanted to build one.
We built PDC, a remote patient monitoring platform on HIPAA-eligible infrastructure, in 14 weeks. Patients receive wearable health monitoring devices. The platform reads data from those devices, stores it securely on HIPAA-eligible AWS infrastructure under a signed BAA, and shows providers a real-time view of their patients' health with alerts when readings change. Separate logins for admins, providers, patients, and specialists keep access properly controlled. The client reported that 25 clinics had enrolled within 60 days of launch.
Getting a patient enrolled in a monitoring program is the easy part. Keeping them engaged, and keeping the alerts meaningful, is what determines whether the software actually delivers. An alert that just says abnormal gets dismissed as noise, and something real gets buried in it.
Engagement
The PDC engagement
- Client
- A team of healthcare entrepreneurs building remote patient monitoring for elderly and post-surgery patients
- What we built
- PDC, a remote patient monitoring platform: wearable devices transmit readings, providers see real-time vitals with threshold alerts, role-based portals for admins, providers, patients, and specialists
- Delivery
- 14 weeks
- Stack
- HIPAA-eligible AWS services, SQS, role-based access control
- Status
- Live. 25+ clinics enrolled within 60 days of launch, per the client
Before and after
What changed
- Providers had no way to monitor patients between visits, requiring frequent in-person appointments
- No real-time health data from wearable devices: everything was self-reported or measured at the clinic
- Providers missed early warning signs because they only saw data when the patient came in
- Administrative tasks around at-home care were entirely manual: no automated tracking or documentation
- No role-based access control for multi-provider care teams: all users saw everything
- High operational costs from unnecessary in-person visits that monitoring could have replaced
- Wearable devices send readings continuously to the platform throughout the day
- Providers see real-time vital signs and receive automatic alerts when readings cross thresholds
- Early warning signs trigger alerts before a situation becomes an emergency
- Administrative workflows for at-home care management are built into the platform
- Separate role-based portals for admins, providers, patients, and specialists control what each user sees
- Patients stay home more; providers manage larger panels without more staff
What we had to solve
HIPAA compliance from the first line of code
There is no "add HIPAA compliance later" option in healthcare software. Every architectural decision, where data is stored, how it moves between services, who can access what, has a compliance dimension. We had to design the data model, access controls, and infrastructure around HIPAA requirements before building any features. That meant HIPAA-eligible AWS services, SQS queues for secure data transmission, and role-based access control as a foundational system layer, not an afterthought.
One data pipeline for multiple wearable device types
Continuous glucose monitors (CGM) and blood pressure monitors (BPM) transmit health data in different formats on different schedules. Building a platform that reads, normalizes, and stores data from both, and can add future device types without rebuilding the pipeline, required a flexible data ingestion layer. SQS message queuing handled the burst traffic from multiple simultaneous device transmissions without data loss.
Proof
What the build delivered, and what this page can't claim
Delivery facts from a 14-week build. Enrollment figures are client-reported; no clinical outcomes or billing figures were available for this review.
| Result | What changed | Period or context | Evidence and limitation |
|---|---|---|---|
| Time to launch | 14 weeks to a HIPAA-designed platform | HIPAA-eligible AWS services, secure SQS transmission, role-based access as a foundational layer | Project-recorded. Compliance was designed into the architecture from the first line of code, not added later |
| Device support | 4+ wearable device types on one ingestion pipeline | Continuous glucose monitors and blood pressure monitors normalized into one store, with room for future device types | Project-recorded |
| Adoption | 25+ clinics enrolled within 60 days of launch | The client enrolled providers onto the platform after launch | Client-reported. No clinical outcome or billing figures were available for this review |
the build
What we built
The platform connects the patient's wearable device to their provider's dashboard, with real-time alerts in between.
Readings transmit automatically all day: the device does the work, the patient just wears it
Patients receive wearable health monitoring devices, such as blood pressure monitors and continuous glucose monitors, that connect directly to the PDC platform. Readings transmit automatically throughout the day without the patient doing anything manually. The device does the work; the patient just wears it.
Providers respond to abnormal readings before they become emergencies
Providers see each patient's latest readings in real time. When a reading crosses a clinical threshold, such as blood pressure too high or glucose out of range, the platform sends an alert immediately. Providers can respond to potential issues before they become emergencies, without waiting for a scheduled visit.
Each team member sees only the patients and data appropriate to their role
Admins, providers, patients, and specialists each log in to their own portal with the access level appropriate to their role. Patients see their own data. Providers see all their enrolled patients. Admins manage the platform. Specialists see patients specifically referred to them. Access is separated by role, not just password.
Patient's primary physician and specialist both see the same device data, no manual data transfers
Patients can share their health data with multiple authorized providers simultaneously. If a patient sees both a primary care physician and a specialist, both can monitor the same device data with appropriate access. The platform handles data sharing within the care team without requiring manual data exports or transfers.
The lesson
The visit was the workaround
The appointments this platform replaces were never the care. They were scheduled not because the patient needed to be seen, but because the provider had no other way to check on them. The visit was a workaround for a missing system. Once the system exists, the visit stops being necessary, and both sides get their time back.
But the system only works if it earns the provider's attention. Care coordinators in monitoring programs report reviewing hundreds of alerts a day, most not actionable, and a team trained to ignore alerts is a team that misses the real one. So the thresholds, the reasons attached to each alert, and the way alerts land in the provider's day are not refinements. They are the difference between a monitoring program and a noise machine.
How it runs
- React
- The provider dashboard needs to show live patient data as readings arrive. React's component model makes it practical to build a real-time dashboard that updates without reloading the page.
- AWS Lambda
- HIPAA-eligible serverless backend that handles the variable load of multiple patients sending device data simultaneously. No idle infrastructure between monitoring windows.
- PostgreSQL
- Patient records, reading history, and access logs all needed structured, queryable storage with audit trails. PostgreSQL handles this reliably at the data volume a multi-clinic platform generates.
Common questions
Remote patient monitoring (RPM) is a model where patients use wearable devices at home, such as blood pressure monitors, glucose sensors, and pulse oximeters, that send health data to their provider continuously. Providers track patients between clinic visits and can act early when readings change, without requiring the patient to come in.
Every architectural decision was made with HIPAA in mind from the start. We used HIPAA-eligible AWS services for all data storage and processing, implemented SQS queues for secure data transmission between the wearable data pipeline and the application, and built role-based access control as a core system layer. HIPAA was a design constraint, not a final checklist item.
The platform currently supports continuous glucose monitors (CGM) and blood pressure monitors (BPM), with the data ingestion architecture built to add additional device types without rebuilding the pipeline.
14 weeks from kickoff to a live platform on HIPAA-eligible infrastructure. We followed two-week Agile sprints with daily communication, testing in development, testing, and staging environments before any feature went to production.
This case study covers the original build of PDC: the monitoring infrastructure, wearable device integration, real-time alerts, and role-based portal. The AI-enhanced version is a separate project where we added an AI layer on top of this foundation. The AI layer automates patient triage, risk stratification, and monthly reporting, all capabilities built on top of the monitoring platform described here.
Related work
More case studies
AI-driven remote patient monitoring app development for chronic care management
AI integration in the remote patient monitoring app enhances efficiency by automating data analysis and providing personalized insights through wearable health monitoring devices such as CGM and BPM. This advancement has reduced clinical decision-making time by 20% (client-reported), supporting virtual care management, particularly in chronic care scenarios.
Telehealth app for virtual primary care for everyone, regardless of location
We built a telehealth app that reduced ER visits by 60% (client-reported). This web app, coupled with FDA-approved diagnostic peripherals, enables physicians to provide remote care from anywhere, at any time.
Centralized car marketplace app for vehicle sales
The new intuitive marketplace, SWD is attracting both buyers and sellers. With 3x faster listings and smarter bidding, users can close deals quicker and experience a smoother car buying and selling experience.