Most RPM builds go live in 10--14 weeks. We achieve this by front-loading device SDK evaluation and API feasibility testing in Week 1 so there are no integration surprises mid-build. Pre-validated device integrations: Dexcom CGM (Dexcom Share API and Dexcom G6/G7 Bluetooth GATT protocol for direct device connection), Withings BPM Connect and BPM Core (Withings Health API OAuth 2.0), Omron blood pressure monitors (Omron Wellness API), iHealth wireless scales (iHealth API), Fitbit HR and SpO2 sensors (Fitbit Web API with OAuth 2.0), Apple Health and Google Fit as aggregation sources for multi-device patients. Cellular-connected devices (4G LTE, NB-IoT) transmit readings directly to the ingestion API without requiring the patient's phone to be nearby -- critical for elderly patients or those with limited smartphone capability. You see real device data flowing into the care team dashboard by end of Week 3, not end of Month 3.

Our healthcare engineering team has shipped HIPAA-compliant platforms handling HL7 v2 ADT/ORU message parsing, FHIR R4 resource creation (Observation, Patient, Device, Alert), and wearable device Bluetooth GATT protocol and cellular data transmission. EHR integrations built on: Epic FHIR R4 API (SMART on FHIR OAuth 2.0 with patient-level scopes), Athenahealth REST API v1 with webhook event subscriptions for patient chart updates, Cerner FHIR R4 API via the Cerner Ignite program, and proprietary EHR APIs via HL7 v2 MLLP/TCP integration or Direct Secure Messaging. Vital signs mapped to FHIR Observation resources using LOINC codes (blood glucose: 15074-8; systolic BP: 8480-6; diastolic BP: 8462-4; SpO2: 59408-5; heart rate: 8867-4) so readings flow into the EHR's longitudinal patient record in a standard format that clinicians can access alongside other clinical data. Your EHR integration is a known-quantity deliverable, not a discovery task that extends your timeline.

Alert thresholds, device mix, enrollment flows, and care team notification rules are all configured to your clinical protocols -- not defaulted to industry averages. A cardiac rehab practice has different safe ranges and alert urgency than a diabetes management clinic managing HbA1c and glucose variability. We map your clinical decision logic in Week 1 and build the rule engine around it.

Alert threshold configuration goes beyond simple high/low bounds. The rule engine supports: single-reading threshold violations (glucose below 70 mg/dL triggers immediate alert); consecutive-reading patterns (blood pressure above 140/90 on 3 or more readings in 24 hours triggers a non-urgent care manager notification, not an immediate alert); rate-of-change detection (glucose dropping more than 30 mg/dL in 30 minutes triggers an urgent alert regardless of absolute value); time-of-day contextual rules (heart rate above 100 bpm is normal during daytime activity but alerts at night for post-cardiac-surgery patients); and composite multi-parameter alerts (elevated glucose combined with elevated heart rate in a diabetes patient with cardiac comorbidity triggers a different escalation path than either alone).

Alert routing and escalation logic built to your care team structure: a first-tier alert goes to the assigned care manager; if unacknowledged within a configurable window (typically 15-30 minutes), it escalates to the clinical supervisor; unacknowledged after a second window, it escalates to the on-call physician. Different alert categories route to different people -- a blood pressure alert at 2am might go to an on-call nurse rather than the primary care manager who manages the patient's daytime program.

Device selection and enrollment criteria by condition: patients enrolled on CGM (continuous glucose monitoring) for diabetes management; BPM and pulse oximeter for cardiac and respiratory conditions; weight scale for CHF patients where daily weight is a leading indicator of fluid retention; fall detection wearables for post-fall rehabilitation patients. Enrollment flows are condition-specific so the patient onboarding experience, device pairing instructions, and consent documentation match the program. The 25+ clinics on our RPM platform all run different alert configurations, device combinations, and enrollment flows from the same codebase.

Every RPM system we deliver is HIPAA-compliant by architecture: patient vitals encrypted in transit using TLS 1.3 (with TLS 1.2 as the minimum supported version and TLS 1.0/1.1 disabled) and at rest using AES-256 with envelope encryption (data encryption keys encrypted by AWS KMS or GCP Cloud KMS customer-managed keys). BAA (Business Associate Agreement) signed before development starts -- we do not begin processing PHI without one in place. Audit logging at every PHI access point: each API call that returns patient data logged with the authenticated user identity, the patient record accessed, the timestamp, and the client IP address; logs stored in a tamper-resistant append-only store (AWS CloudTrail + S3 with Object Lock) retained for 6 years per HIPAA audit log retention requirements. Role-based access control enforced at the API layer (not just the UI): care managers see only their assigned patient panel, clinic administrators see all patients in their clinic, and health system administrators see all clinics -- enforced by JWT claims validated on every API request. PHI minimum necessary: API responses return only the fields required for the requesting UI component, not full patient records, minimising exposure in network traffic. Annual HIPAA Security Risk Assessment documentation provided as a project deliverable.

The patient-facing mobile app is designed for the populations most commonly monitored: elderly adults and patients managing chronic conditions who may have limited smartphone familiarity or dexterity challenges. Design choices are clinically informed, not aesthetically default.

Patient app design principles: minimum 48dp touch targets on all interactive elements (Apple HIG and WCAG 2.1 AA compliant); font size minimum 16sp with user-adjustable text size that doesn't break layouts; high-contrast colour scheme (4.5:1 minimum contrast ratio) readable in variable lighting conditions; single-action primary tasks per screen so a patient checking their readings never has to navigate more than 2 taps from the home screen. Device pairing onboarding uses step-by-step photo-guided Bluetooth pairing instructions specific to each device model -- a patient pairing a Dexcom G7 sees different instructions than one pairing a Withings BPM Connect, without having to identify which device they have.

Passive data transmission architecture: for Bluetooth-connected devices, the app collects readings via GATT protocol in the background without requiring the patient to open the app; for cellular-connected devices (NB-IoT or 4G LTE), readings transmit directly to the ingestion API without any patient action. The app's primary job for most patients is to confirm their device is connected, which requires nothing more than seeing a status indicator on the home screen. For patients who need to enter readings manually (blood glucose patients without a CGM), the manual entry flow is a single screen with a numeric keypad -- no scrolling, no navigation.

Care team dashboard design: all enrolled patients displayed in a single-scroll list view with the most recent reading, reading timestamp, and alert status for each patient visible without clicking into the patient record; alert queue surfaced as a persistent banner showing the count of open alerts; patients with open alerts sorted to the top of the list automatically. A nurse scanning 50 patient panels in 90 seconds can identify which patients need action from the list view alone -- clicking into a patient record is for review, not triage. Dashboard accessible on both desktop browser (full-width multi-column layout) and tablet (responsive two-column layout for bedside rounds use).

The platform is architected for 10 enrolled patients on day one and 10,000 a year later without a re-architecture or a database migration. Device ingestion microservice deployed on AWS ECS Fargate or GCP Cloud Run: auto-scales horizontally on incoming reading volume (CPU and SQS queue depth as scaling triggers); each device reading is published to an SQS FIFO queue for ordered, at-least-once processing with a 5-minute deduplication window (prevents duplicate readings from device retransmissions inflating the patient's data record); processed readings persisted to a PostgreSQL database with a time-series partitioning strategy (readings table partitioned by month) so queries scoped to recent data don't scan historical partitions. Alert engine: rule evaluation runs as a separate worker consuming from the readings queue, evaluating each reading against the patient's personalised alert thresholds; alert state machine tracks alert lifecycle (pending, acknowledged, escalated, resolved) preventing re-alerting on the same threshold violation until the reading returns to normal range. Multi-tenant partitioning: each clinic's patient data logically partitioned by clinic_id with row-level security at the database layer; a health system deploying to 20 clinic locations runs a single platform instance with complete data isolation between clinics at the query layer.

Week 1 is structured clinical discovery -- not a kickoff meeting where requirements are collected and handed to engineers. Discovery is an audit of your clinical and technical environment designed to eliminate integration surprises before development starts.

Clinical workflow mapping: we work with your clinical lead and care team to document your patient population by condition and comorbidity, the devices currently issued or under consideration, the alert thresholds your clinical protocols define (not the device manufacturer defaults), your escalation tree (who gets alerted first, second, third, and by what channel -- in-app, SMS, or phone call), and the care team roles that need access to which patient data. A practice managing post-surgical cardiac patients has fundamentally different monitoring requirements than a diabetes management program -- discovery produces a role-specific clinical requirements document, not a generic feature list.

EHR API audit: we document your EHR vendor, version, and API configuration before committing to integration scope. Not all EHRs expose the same FHIR resources: Epic's FHIR R4 sandbox requires SMART on FHIR app registration and patient-level scope approval; Athenahealth's REST API has a different authentication flow and different webhook event types than Epic; Cerner's Ignite program requires a separate registration process. We identify which patient demographics, active medications, and diagnosis codes your EHR API returns, because the RPM alert engine needs comorbidity context (a diabetic patient on insulin has different glucose alert thresholds than a patient managing with diet alone) and that context must come from the EHR.

Discovery deliverables: device integration spec listing each device by model, SDK or API used, data transmission method (Bluetooth GATT, cellular, or patient app bridge), and the reading data structure returned; data schema for the readings, patients, devices, alerts, and care team entities; feature priority list ranked by clinical impact with clinical lead sign-off; EHR integration scope with confirmed API endpoints and data fields. These documents are signed off before a line of code is written and serve as the technical contract for the build.

Weeks 2-4 produce interactive prototypes for both the patient mobile app and the care team dashboard before development starts. Design in RPM is not a visual exercise -- it is a clinical workflow design problem. How a nurse triages 50 patient alerts in 90 seconds at the start of a shift, or how a care manager reviews a patient's 30-day glucose trend during a phone consultation, determines whether the system reduces clinical burden or adds to it.

Patient app prototyping: Figma prototypes at 375px (iPhone SE, the most common device among elderly patient populations in assisted programs) and 428px (iPhone Pro Max) breakpoints. The core patient-facing flows prototyped: initial device pairing with step-by-step guidance; home screen showing most recent reading, trend indicator, and device battery/sync status; reading history view with a 7-day spark chart; manual reading entry flow (for programs that supplement device readings with patient-entered data); and the notification flow showing what the patient sees when they receive an alert that their reading is outside range.

Care team dashboard prototyping: patient list views with sorting and filtering options -- by alert status, by assigned care manager, by last reading timestamp, by condition; individual patient timeline showing all readings across all devices in a single chronological view; alert detail showing the reading that triggered the alert, the threshold that was crossed, the time elapsed since the alert, and the escalation status. The alert queue layout is reviewed by nurses and care managers who will use it daily -- not just clinical leadership -- because the 5-second decision about which alert to address first is a UX problem, not just a clinical one.

Design review process: prototype sessions scheduled with actual care team members (nurses, care managers, and the clinical supervisor) using a structured task scenario approach -- "show me what you'd do if a patient's blood pressure alert came in at 6am" -- rather than open-ended feedback. Each review produces a prioritised change list resolved before the prototype is handed to development. This review cycle happens with your team, not with a surrogate user panel.

HIPAA compliance is built into the data architecture from Sprint 1 -- not a checklist applied during QA. The decisions that determine compliance (where PHI is stored, who can access it, how access is logged, how long data is retained) are made at schema design time, not retrofitted after the build. A system built without compliance in the architecture requires a partial rebuild to comply -- we do not build that way.

BAA established before development: we sign a Business Associate Agreement before any PHI is handled in design sessions, test environments, or integrations. We do not use production patient data for testing -- synthetic test data with structural fidelity to your patient population is generated during discovery for development and QA use.

Database schema design with access controls as first-class entities: every table containing PHI (patients, readings, alerts, audit_logs) is designed with a clinic_id foreign key and row-level security policies (PostgreSQL RLS) enforced at the database layer, not just the application layer. A compromised application credential cannot return cross-clinic patient data because the query itself is constrained by the database's RLS policy evaluating the JWT clinic_id claim. PHI field minimisation: the readings table stores device_id, patient_id, reading_type, value, and timestamp -- not patient name or contact details. Patient demographics are in a separate table with stricter access policies; joined only when the UI requires it, never in bulk exports.

Penetration testing performed by an independent security firm before launch -- included in the project cost, not an optional add-on. The pentest covers the patient app authentication flow, the care team dashboard API endpoints, the device data ingestion API (testing for injection via malformed device payloads), and the EHR integration OAuth token handling. Critical and high findings are resolved before go-live with documented remediation evidence for your compliance records.

Security deliverables provided as project outputs: HIPAA Security Risk Assessment documentation (required by the HIPAA Security Rule §164.308(a)(1)); data flow diagram showing every point where PHI is created, processed, stored, or transmitted; access control matrix showing which roles can access which PHI fields; and audit log retention policy documentation confirming 6-year retention with tamper-evident storage (AWS S3 with Object Lock in Compliance mode).

Two-week sprints with a structured sprint review at the end of each sprint -- attended by your clinical lead, the care team lead, and our engineering and product team. The review is not a progress presentation; it is a working software demonstration against real test data so your clinical team can evaluate whether the system behaves as their clinical protocol requires.

Sprint schedule for a 10-14 week focused RPM build: Sprint 1 (Weeks 1-2) -- backend API scaffold, device ingestion microservice for the first device type, database schema, and authentication. You see real device readings arriving in the API by end of Sprint 1. Sprint 2 (Weeks 3-4) -- alert engine with threshold evaluation, alert state machine (pending/acknowledged/escalated/resolved), and the first version of the care team dashboard showing patient list and alert queue. You see an alert fire when a test reading crosses a threshold by end of Sprint 2. Sprint 3 (Weeks 5-6) -- patient mobile app (iOS and Android, React Native) covering device pairing, home screen, and reading history; remaining device integrations added. Sprint 4 (Weeks 7-8) -- EHR integration, reading write-back to FHIR Observation resources, and patient demographics pull from the EHR. Sprint 5 (Weeks 9-10) -- enrollment flow, patient onboarding, and care team alert notification delivery (in-app, SMS via Twilio, email via SendGrid). Sprint 6 (Weeks 11-12) -- QA, penetration testing, HIPAA compliance review, and go-live preparation.

Each sprint review gives your clinical team the opportunity to adjust alert thresholds, escalation logic, or dashboard layout based on what they see working in context, before those decisions are embedded in a completed system. Alert threshold adjustments that come up in sprint reviews -- "this threshold is generating too many low-priority alerts; can we change it to trigger only on consecutive readings?" -- are resolved in the next sprint, not in a post-launch patch cycle.

The scope document produced at the end of Week 2 discovery defines exactly what is built, what it costs, and when it ships -- and that document is the contract. Fixed-price delivery for a healthcare system is only possible when scope is defined precisely before development starts, not estimated loosely and adjusted as ambiguities surface.

What the scope document contains: a complete feature list broken into must-have (included in the fixed price) and nice-to-have (scoped as optional increments); device integration list with the specific API or protocol used for each device, confirmed during discovery; EHR integration scope with the confirmed FHIR resources and data fields the EHR API exposes; alert configuration specification listing every alert rule, threshold, and escalation path agreed with your clinical lead; data schema showing the tables, fields, and access control rules; and a sprint-by-sprint delivery plan with acceptance criteria per sprint.

Change order process: when clinical teams request additions during development (and they do -- typically 2-4 requests per project), we scope each request as a separate increment with its own fixed cost and timeline estimate. The addition is presented to you with the cost and the impact on the current delivery timeline. You decide whether to add it to the current engagement or defer it to a follow-on phase. We do not absorb undocumented scope additions into the fixed price, and we do not silently extend the timeline. Every change has a written record.

Cost transparency from week one: a focused RPM build (one to two device types, single EHR integration, patient mobile app and care team dashboard) is quoted at $25,000 to $45,000 with the exact number confirmed after discovery. The discovery phase (Week 1-2) is billed separately at a fixed price and the cost is credited to the main build if you proceed -- you own the discovery deliverables regardless. No hourly billing, no time-and-materials escalation, no surprise invoices at week 12 because integration took longer than estimated.

The platform is architected for growth from the first sprint -- the same infrastructure decisions that support 50 enrolled patients in launch month support 5,000 patients without a database migration or infrastructure redesign. This matters in healthcare because patient enrollment typically accelerates: a practice that launches RPM with one chronic disease cohort frequently expands to additional conditions and locations within 12 months, and a rebuild at that point is disruptive to active clinical programs.

Device ingestion horizontal scaling: the ingestion microservice is deployed as a containerised service on AWS ECS Fargate or GCP Cloud Run with autoscaling configured on two signals -- CPU utilisation above 70% and SQS queue depth above 500 messages. At 50 patients with 4 device readings per hour each, the queue depth is negligible. At 5,000 patients with CGMs transmitting every 5 minutes, the queue depth drives additional ingestion instances automatically without manual intervention. Queue-based processing means no readings are lost during traffic spikes: readings are durable in the SQS FIFO queue until processed and acknowledged.

Database growth strategy: the readings table is partitioned by calendar month (PostgreSQL declarative table partitioning with PARTITION BY RANGE (recorded_at)). A query for the last 30 days of readings for a specific patient touches only the current and prior month partitions -- not the full historical dataset. Monthly partitions older than 24 months are moved to cold storage (Amazon S3 via pg_partman) and are queryable via Amazon Athena for historical analytics, reducing active database size without data loss.

EHR integration abstraction: the EHR integration layer is built as an adapter pattern with a common interface (write Observation, read Patient, read Condition) implemented separately per EHR vendor. A practice migrating from Athenahealth to Epic requires updating one adapter file, not rebuilding the RPM platform. New EHR integrations for enterprise clients adding locations are added as new adapters without touching the core platform.

Multi-tenant architecture: a health system operating 20 clinic locations runs a single platform instance with clinic_id row-level security at the database layer. Adding a new clinic location is an administrative configuration, not a deployment -- no new infrastructure is provisioned and no data migration is required. Enterprise clients with multiple clinical programs (diabetes, cardiac, respiratory) run separate device configurations and alert rules per program from the same platform instance.