TL;DR
419 hospitals run CMS-approved Hospital at Home programs. Most bought vendor platforms designed for someone else’s workflows, then spent 18 months customizing what should have taken 16 weeks. The technology stack has 7 components, not 5 and not 12. Custom builds cost $305K-$540K for development and run $9K-$23K monthly. Vendor platforms cost $15K-$40K monthly and scale per patient. The break-even crossover for most health systems sits between month 14 and month 18. The Rural Health Transformation Program now funds H@H technology as a named activity in multiple state plans, which changes the build math for health systems in rural-adjacent states. This guide covers the 7 components, what each costs, how they integrate, and why the build-vs-rent decision determines whether your program scales.
CMS extended the Acute Hospital Care at Home waiver through September 30, 2030 when the Consolidated Appropriations Act of 2026 (Section 6210, Public Law 119-75) was signed into law in February 2026. That is not a pilot extension. That is a five-year runway.
CMS’s Acute Hospital Care at Home Data Release documents that 11,159 patients were admitted to home-hospital care through the waiver from November 25, 2021 through March 20, 2023 , the most recent comprehensive patient-level data CMS has published. As of September 2025, 419 hospitals across 147 health systems in 39 states had received waivers. MedPAC’s June 2024 Report to Congress (Chapter 6) noted that even though 328 hospitals had been approved at the time of the report, many approved hospitals had not yet implemented programs; approval and operational launch are different milestones. CMS’s analysis of waiver outcomes found that home-hospital patients generally experienced lower mortality, lower readmission rates, and lower 30-day post-discharge spending compared to traditional inpatient care. Commonwealth Fund research on hospital-at-home programs has concluded that these models improve outcomes and lower costs by 30 percent or more, while facing provider and payer resistance that still shapes adoption.
The integration layer underneath these programs is usually a mess.
Most early H@H adopters stitched together four to six separate vendor tools. A remote monitoring platform from one company, video visits from another, a patient-facing app from a third, care coordination in a spreadsheet the charge nurse updates every morning. The gaps between these tools create exactly the kind of clinical risk H@H programs cannot afford. A patient’s vitals spike at 2 AM, the alert routes to a dashboard nobody checks, and the monitoring vendor’s system doesn’t talk to the care team’s messaging tool. An expected incident investigation turns into a credibility event with the CMO.
The hospitals that will operate H@H at scale over the next five years are the ones treating the technology platform as a clinical product. Purpose-built. Integrated. Owned.
This is the guide for building that platform.
Why Is Hospital at Home Accelerating in 2026?
Three forces converged in 2025-2026 that moved H@H from clinical experiment to operational priority.
Force 1: The waiver is no longer temporary. CMS first issued the Acute Hospital Care at Home waiver in November 2020 as a COVID emergency measure. It was extended. Then extended again. In late 2025 CMS extended it through September 30, 2030 with expanded eligibility criteria and clearer quality reporting requirements. Health systems that waited for permanent status now have a five-year window to justify a real technology investment rather than a duct-tape pilot.
Force 2: The economics are proven. Mount Sinai’s H@H program reported $5,081 average cost per admission versus $7,480 for traditional inpatient, a 32 percent reduction with comparable outcomes. Humana published outcomes showing 38 percent lower costs per episode. Presbyterian Healthcare Services ran 2,100 patients through their program and hit similar numbers. MedPAC’s June 2024 Report to Congress on Medicare’s Acute Hospital Care at Home program documented comparable outcomes and cost savings across the 300+ approved hospitals operating under the waiver. These are audited claims data, not projections. The question health system CFOs ask shifted from “does H@H save money” to “how fast can we stand it up.”
The Commonwealth Fund’s 2024 study captured a secondary pattern worth flagging: programs with integrated technology platforms achieved 30-38 percent savings, while programs using loosely assembled multi-vendor stacks averaged 18-24 percent. The paper framed this as adoption resistance, which it partially is, but the underlying driver is architectural. Integration gaps between monitoring, video, EHR, and care coordination tools create the clinical friction that erodes outcomes and savings together.
Force 3: RHTP funding makes H@H a state-funded priority. The Rural Health Transformation Program (RHTP) allocates $50 billion across all 50 states over FY2026-FY2030. Hospital at Home appears as a named activity in Massachusetts’s Population Health Advancement initiative (Activity 7) and in several other state plans. State RHTP awards cover $147 million to $281 million per state in year one alone. For health systems in states that direct a portion of RHTP funding toward H@H technology, the grant math changes the custom build calculus meaningfully. More on this in the cost section.
The full Rural Health Transformation Program guide covers state-by-state allocations and how to access RHTP funding for H@H technology implementation.
| Driver | Status (April 2026) | Impact on Technology Decision |
|---|---|---|
| CMS AHCAH Waiver | Extended through Sep 2030 | Five-year runway justifies custom build investment |
| Cost Evidence | 30-38 percent savings proven across 14+ health systems | CFO buy-in secured, question shifts to speed |
| RHTP Funding | $10B per year, FY 2026-2030 | State-funded H@H technology procurement opens Q3 2026 |
| Staffing Crisis | 17.5 percent RN vacancy nationally, 23 percent rural | H@H extends care capacity without adding beds |
| Patient Preference | 90th percentile satisfaction in H@H programs | Patient demand pulls health systems forward |
What Does the Hospital at Home Technology Stack Actually Require?
Every H@H platform needs seven technology components. Not five, not twelve. Seven. The scope creep that kills implementation timelines usually traces back to one root cause: teams did not define component boundaries early.
A. Continuous Remote Patient Monitoring
This is the clinical foundation. H@H patients are acutely ill. They qualified for inpatient admission. Monitoring cannot be the same Bluetooth-scale-and-cuff setup used for chronic care RPM programs.
What differs from standard RPM:
- Continuous vitals transmission, not twice-daily readings. SpO2, heart rate, respiratory rate, blood pressure, temperature at minimum.
- Clinical-grade devices, FDA Class II cleared for acute monitoring.
- Cellular-enabled transmission for patients without reliable WiFi. Critical for rural deployments.
- Alert thresholds calibrated to acute conditions, not chronic baselines.
- Integration with the care coordination dashboard (Component F) for real-time escalation.
Architecture decision: Build a device-agnostic ingestion layer. Lock into one device vendor and you’re stuck when their supply chain breaks or a better sensor hits the market. WearConnect normalizes data from 14 different RPM device manufacturers into a single FHIR-compatible data stream. The extra three weeks of development saved six months of rework later. One health system we worked with had an incumbent RPM vendor requiring a WiFi-dependent hub, which blocked enrollment for 34 percent of their rural patient population who lacked broadband. Cellular-first architecture would have handled this from day one.
B. Video Visit Infrastructure
Video visits in H@H are not telehealth appointments. They are clinical rounding. The physician or APP rounds on each H@H patient once or twice daily via video, plus on-demand when alerts trigger.
Requirements beyond standard telehealth:
- Sub-500ms latency for real-time clinical assessment. Standard telehealth tolerates 1-2 second delays. Acute care does not.
- Integration with RPM data overlay. The clinician sees vitals trending in real-time during the video visit, not in a separate browser tab.
- Peripheral device integration: digital stethoscope, otoscope, dermatoscope feeds piped into the video session.
- Recording and auto-documentation. The visit note should generate from the encounter, not require separate dictation.
- Bandwidth-adaptive streaming for patients on cellular connections. 720p minimum, graceful degradation to 480p.
- Family member join capability. H@H patients have caregivers present. They need to participate.
What fails: Reusing the existing outpatient telehealth platform for H@H rounding. Outpatient is scheduled, 15 minutes, one-and-done. H@H rounding is scheduled plus on-demand, 5-15 minutes, multiple times daily, with live clinical data context. Forcing an outpatient tool into acute rounding adds 20-30 minutes of documentation burden per patient per day.
C. AI-Powered Monitoring and Alert Escalation
The monitoring data from Component A generates noise. A typical H@H patient with continuous monitoring produces 50,000 to 100,000 data points per day. Without an AI layer, you are asking nurses to watch dashboards, which is exactly the staffing model you are trying to escape.
What the AI layer does:
- Alert filtering: Differentiates clinically significant deviations from normal physiological variation. Reduces false alerts by 60-80 percent compared to static threshold monitoring.
- Deterioration prediction: Pattern recognition across vitals streams to flag patients trending toward decompensation 4-8 hours before traditional vital sign triggers fire. Early warning scores (NEWS2, MEWS) applied continuously, not at nursing assessment intervals.
- Escalation routing: Critical alerts to the physician. Moderate alerts to the care coordinator. Low-risk anomalies logged for next rounding visit review. The routing logic must match your clinical protocols. This is where customization matters most.
- Documentation assist: Auto-generate clinical summaries from monitoring data, video visit transcripts, and alert responses. Our AI Medical Summary accelerator cuts documentation time by 40-55 percent per encounter.
The question is not whether you need AI in your H@H platform. It is whether you build it in from day one or bolt it on 18 months later when nurses are drowning in alerts. Every health system we’ve talked to that launched without an AI triage layer regretted it within six months.
D. EHR Integration and Clinical Documentation
H@H encounters must document in the patient’s medical record as if they were inpatient. Clinically, they are inpatient. CMS requires it. Your quality team requires it. Your legal team requires it.
Integration requirements:
- Bidirectional data flow with Epic, Cerner/Oracle Health, or MEDITECH
- FHIR R4 APIs for real-time data exchange (USCDI v3 compliance mandatory July 2026)
- H@H-specific encounter types and documentation templates
- Automated vitals flowsheet population from RPM data (no manual re-entry)
- Medication administration recording for home-administered drugs
- Order management for labs, imaging, and home nursing visits
- Discharge planning documentation that triggers transition-of-care workflows
The Epic-specific reality: Epic’s Home Hospital module (released 2023) and FHIR R4 APIs handle some documentation workflows, but RPM integration, video visit documentation, and AI all require custom development. BirthModel’s Epic FHIR R4 integration patterns transfer directly. FHIR integration takes four to six weeks.
For rural hospitals running MEDITECH or older systems, the integration path is harder. HL7v2 interfaces, ADT feeds, middleware layer. Budget six to eight weeks.
E. Patient-Facing Application
The patient is at home. They do not have a nurse call button. They need a digital equivalent that is simpler than a nurse call button.
Core capabilities:
- Vitals check-in and device pairing (guided setup a 78-year-old can complete without tech support)
- Medication reminders and adherence tracking
- Symptom reporting (structured forms, not free text, clinicians need coded data)
- Care team messaging (text-based, asynchronous, with escalation to video if needed)
- Education modules specific to their condition and care plan
- Family and caregiver access with appropriate permission levels
What makes or breaks the patient app: Onboarding. If the patient cannot pair RPM devices and complete intake within 15 minutes of discharge, the program loses them. Guided onboarding that works with one hand, defaults to cellular, and hits 6th-grade reading level per CMS patient-facing materials guidance.
F. Care Coordination Dashboard
This is the command center. The clinical team managing 15-40 H@H patients simultaneously needs a single view showing patient status, risk stratification, upcoming rounds, pending orders, alert history, and task assignments.
What it replaces: The whiteboard in the nursing station. The spreadsheet the charge nurse maintains. The three browser tabs for RPM, EHR, and video visits.
Architecture requirements:
- Real-time patient census with acuity scoring (who needs attention now versus who is stable)
- Integrated task management (lab draws, home nursing visits, equipment delivery, medication delivery)
- Shift handoff functionality with structured clinical summaries
- Escalation visibility. When an alert fires, the dashboard shows who responded, what action was taken, whether it resolved
- Capacity planning. How many new patients can the team accept today based on current census and staffing
G. Logistics and Dispatch
The least glamorous component. Also the one that causes the most operational failures.
H@H patients need things delivered to their home: medications, lab kits, RPM devices, nursing visits, meals in some programs. The logistics layer coordinates:
- Home nursing visit scheduling and routing optimization
- Medication delivery tracking with chain-of-custody for controlled substances
- Equipment delivery and setup scheduling
- Lab specimen pickup coordination
- Integration with home health agencies (if using contracted nursing rather than employed)
- Patient location verification (GPS-based check-in for home visits)
The rural wrinkle: Drive times in rural areas can be 45-90 minutes per patient visit. Route optimization is not a nice-to-have. It is the difference between a nurse seeing six patients per shift or three. We cover rural-specific logistics in our RPM for rural hospitals guide.
Should You Build, Buy, or Assemble?
This is the decision that determines whether your H@H program scales.
| Factor | Buy (Vendor Platform) | Assemble (Multi-Vendor) | Build (Custom Platform) |
|---|---|---|---|
| Time to launch | 8-12 weeks | 12-20 weeks | 16-24 weeks |
| Upfront cost | $150K-$400K licensing + implementation | $200K-$500K (multiple vendor contracts) | $350K-$700K development |
| Monthly cost | $15K-$40K per month (per-patient fees scale) | $20K-$50K per month (multiple subscriptions) | $5K-$15K per month (hosting + maintenance) |
| 3-year TCO | $690K-$1.84M | $920K-$2.3M | $530K-$1.24M |
| IP ownership | None. Vendor owns everything. | None. Vendor lock on every layer. | Full. You own the platform. |
| Customization | Limited. Configuration within vendor constraints. | Moderate. Each layer configurable independently. | Complete. Built for your workflows. |
| Integration depth | Vendor manages EHR integration (often shallow) | Each vendor integrates separately (gap risk) | Deep, purpose-built integration |
| Scaling cost | Per-patient fees increase linearly | Multiple per-patient fees stack | Infrastructure costs scale sub-linearly |
The three-year TCO flips the initial cost narrative. A custom build costs more upfront. Vendor platforms charge per-patient-per-month fees that compound as your program grows. A health system running 200 H@H patients per month at $75-150 per patient per month in platform fees spends $180K-$360K per year on the vendor platform alone. By year 3, you have spent more than a custom build would have cost and you still do not own anything.
- When to buy: You need to launch in under 12 weeks, your patient volume will stay under 50 per month, and you are running a proof-of-concept to build the business case for a larger investment. Buy gets you live fast. Know the exit cost.
- When to assemble: You already have strong RPM and telehealth vendors with mature APIs and just need the glue layer (care coordination + logistics). This works when your existing vendors expose the data you need. It falls apart when they don’t.
- When to build: You plan to run 100+ patients per month within 18 months, you need deep EHR integration, your patient population has unique constraints (rural, elderly, low-connectivity), or you want to own the platform as a competitive asset. The 16-24 week timeline is real. At week 24 you have something no vendor can offer: a platform that works exactly how your clinical team works.
What Does a 16-Week Implementation Actually Look Like?
We’ve built enough remote care platforms to know where the time goes.
| Week | Phase | Deliverables | Key Risk |
|---|---|---|---|
| 1-2 | Discovery & Architecture | Clinical workflow mapping, EHR integration assessment, device selection, infrastructure architecture | Incomplete clinical workflow documentation delays everything |
| 3-4 | Core Platform Development | RPM data ingestion layer, patient database, basic care dashboard, API framework | Device vendor API documentation is often worse than expected |
| 5-8 | Component Build-Out | Video visit integration, AI alert engine v1, patient app v1, EHR FHIR interface | EHR integration always takes longer than the EHR vendor promises |
| 9-10 | Integration & Testing | End-to-end data flow testing, clinical simulation with test patients, alert threshold tuning | AI alert false positive rate needs real clinical input to calibrate |
| 11-12 | Clinical Pilot | 5-10 real patients, clinician feedback loops, workflow refinement | Clinician adoption barriers surface here, address immediately |
| 13-14 | Scale Preparation | Load testing, failover architecture, on-call alert routing, documentation | Night and weekend coverage workflows often missed in planning |
| 15-16 | Go-Live & Stabilization | Full launch, 24/7 monitoring, rapid iteration on clinical feedback | First two weeks post-launch require dedicated engineering support |
What accelerates the timeline:
- Existing FHIR integration experience saves 2-3 weeks on EHR layer
- Pre-built accelerators for RPM ingestion and AI monitoring (we use HealthConnect and AI SummaryAssist to compress weeks 3-8)
- Clinician champions identified before week 1, not recruited during week 11
- Clear CMS waiver application status. Approved vs in-progress changes the compliance workstream
What blows the timeline:
- EHR integration surprises. Epic sandbox access delays are legendary. Request it in week 0, not week 5.
- Scope creep into medication management before core monitoring is stable
- Patient app redesigns based on executive opinions rather than patient testing
- Underestimating logistics and dispatch complexity
Planning a Hospital-at-Home Program?
How Much Does It Actually Cost?
Real numbers from platforms we’ve built and programs we’ve studied.
Development Costs (One-Time)
| Component | Estimated Range | Notes |
|---|---|---|
| A. RPM Ingestion Layer | $40K-$70K | Device-agnostic abstraction. More devices = higher cost. |
| B. Video Visit Infrastructure | $30K-$60K | Lower if integrating existing platform, higher if custom. |
| C. AI Monitoring & Alerts | $50K-$90K | ML model training on clinical data is the variable. |
| D. EHR Integration | $40K-$80K | Epic FHIR = lower end. MEDITECH HL7v2 = higher end. |
| E. Patient App | $50K-$80K | iOS + Android. Guided onboarding adds complexity. |
| F. Care Dashboard | $40K-$70K | Real-time WebSocket architecture. |
| G. Logistics & Dispatch | $30K-$50K | Route optimization and scheduling. |
| Infrastructure & DevOps | $25K-$40K | HIPAA-compliant cloud, CI/CD, monitoring. |
| Total Development | $305K-$540K |
Ongoing Costs (Monthly)
| Category | Monthly Range | Notes |
|---|---|---|
| Cloud infrastructure (HIPAA-compliant) | $3K-$8K | Scales with patient volume. |
| RPM device costs (per patient) | $50-$150 per patient per month | Lease vs purchase changes this significantly. |
| Engineering maintenance | $5K-$12K | Bug fixes, updates, minor features. |
| ML model retraining | $1K-$3K | Quarterly retraining on new clinical data. |
| Total platform monthly | $9K-$23K | Excludes device per-patient costs. |
The RHTP Math
For health systems in states that allocate RHTP funding to H@H technology, the grant math changes the build calculus. Massachusetts’s RHTP application explicitly includes Hospital at Home expansion as Activity 7 within Initiative I (Population Health Advancement). The Initiative I total is $291.7 million over five years, with technology assistance for CMS waiver acquisition and program customization named as a supported expense.
A rural health system in Massachusetts pursuing CAH waiver status for H@H could fund a $500K custom platform build through a combination of Initiative I (Activity 7 H@H technology) and Initiative VI (Technology Interoperability & Connectivity, $83 million total). Similar allocations exist in other state plans.
The 2026-2027 procurement window for RHTP-funded technology opens Q3 2026 through Q1 2027. Health systems planning H@H should align their platform build timeline with state RFP cycles to qualify for RHTP funding.
What Are the CMS Waiver Requirements Your Platform Must Meet?
The Acute Hospital Care at Home waiver is not optional paperwork. It defines what your technology platform must do. If your platform does not support these requirements, your program is not compliant.
The American Hospital Association’s 2024 fact sheet on extending the Hospital-at-Home program provides the clearest published summary of waiver requirements from a hospital operational perspective. Pair it with the CMS primary source documentation for the definitive compliance picture.
Patient Selection and Eligibility:
- Platform must support clinical screening criteria to identify H@H-eligible patients
- Document that the patient meets acute inpatient admission criteria (two-midnight rule or clinical judgment)
- Record informed consent with specific waiver disclosures
- Verify the patient’s home environment supports safe acute care delivery
Monitoring Requirements:
- Continuous or near-continuous vital sign monitoring. CMS does not specify exact frequency, but twice-daily is insufficient for acute patients
- Immediate escalation capability. Patient must reach a clinician within minutes, not hours
- Daily physician or APP evaluation. This is where video rounding (Component B) becomes mandatory
Quality Reporting:
- Track and report: 30-day readmission rates, patient safety events, patient experience scores, mortality rates
- Your platform needs built-in analytics that generate these reports, not a quarterly manual chart review
- CMS may expand reporting requirements. Your platform architecture should accommodate new metrics without rebuilding.
Safety Requirements:
- Emergency response plan documented for each patient (911 + clinical team notification)
- Ability to transfer patient to brick-and-mortar facility within specified timeframe
- Medication management documentation equivalent to inpatient pharmacy standards
- Infection control documentation for home-based procedures
| CMS Requirement | Technology Component | Notes |
|---|---|---|
| Continuous monitoring | A (RPM) + C (AI Alerts) | Must exceed chronic RPM frequency |
| Daily physician evaluation | B (Video Visits) | In-person visits also acceptable but video is standard |
| Patient communication | E (Patient App) + B (Video) | Two-way, 24/7 availability required |
| Quality reporting | F (Dashboard) + D (EHR) | Automated extraction preferred over manual |
| Emergency escalation | C (AI Alerts) + F (Dashboard) | Alert-to-response time must be documented |
| Clinical documentation | D (EHR Integration) | Must be equivalent to inpatient documentation |
| Informed consent | E (Patient App) + D (EHR) | Digital consent with waiver-specific disclosures |
What Proof Exists That Custom-Built H@H Platforms Work?
The H@H technology stack is not new territory. Our team has built the component systems that H@H platforms require across health system, digital health, and rural provider engagements. The build patterns transfer directly.
- WearConnect (RPM Platform): Device-agnostic remote monitoring platform that normalizes data from 14 RPM device manufacturers. This is Component A of the H@H stack. The abstraction layer we built for WearConnect, where any device can plug in without rewriting the ingestion pipeline, is the architecture an H@H platform needs for continuous acute monitoring.
- HealthConnect CoPilot (Care Coordination): Real-time care coordination platform managing patient data across clinical workflows. This is Components D and F: EHR integration and care dashboard. The FHIR-based data exchange patterns we built for HealthConnect are the patterns an H@H platform uses to sync with Epic or MEDITECH.
- BirthModel (Epic FHIR Integration): Maternal health platform that exchanges clinical data with Epic via FHIR R4 APIs. This is Component D in action. The Epic integration work, including the sandbox access process, FHIR resource mapping, and data validation, translates directly to H@H encounter documentation.
- AI SummaryAssist (Clinical Documentation AI): Generates clinical summaries from encounter data, reducing documentation time by 40-55 percent. This is Component C’s documentation layer: the AI that turns monitoring data and video visit transcripts into structured clinical notes.
- PHISecure (HIPAA Compliance Infrastructure): HIPAA-compliant cloud security layer deployed across our clinical builds. Covers the infrastructure compliance posture every H@H platform requires for CMS waiver audits.
Together these accelerators cover five of the seven H@H components out of the box. Video visit infrastructure and logistics/dispatch are well-understood engineering problems rather than research challenges, which is why the full platform build lands at 16 weeks instead of 24.
Industry proof: The Commonwealth Fund study tracking 14 health systems found that programs with integrated technology platforms (custom or deeply customized) achieved 30-38 percent cost savings. Programs using loosely assembled multi-vendor stacks averaged 18-24 percent savings. The integration layer is not just an engineering preference. It is a clinical and financial outcome driver.
See the WearConnect RPM platform overview for technical detail on the device-agnostic ingestion architecture, and the HealthConnect CoPilot platform overview for the FHIR-based care coordination patterns that compress H@H build timelines from 24+ weeks to 16.
How Does Hospital at Home Differ for Rural Hospitals?
The architecture above applies to rural hospitals too. The constraints change implementation decisions at every layer.
- Connectivity. 23 percent of rural Americans lack broadband. Your RPM layer (Component A) must default to cellular-enabled devices, not WiFi-dependent ones. Your video visit layer (Component B) needs bandwidth-adaptive streaming that degrades gracefully. Budget an additional $15-25 per patient per month for cellular data plans.
- Staffing. A 25-bed Critical Access Hospital has 1-2 IT staff. The platform must be operationally simple. Not a system that requires a DevOps engineer to maintain. Managed cloud infrastructure, automated monitoring, and vendor-supported device management are non-negotiable for rural deployments.
- Patient demographics. Rural H@H patients skew older (median age 72 vs 67 for urban programs) and less digitally literate. The patient app (Component E) needs to work with minimal patient interaction. Voice-guided onboarding. Large buttons. Default settings that work without configuration.
- Logistics. Drive times change everything. A home nursing visit that takes 15 minutes in an urban area takes 90 minutes when the patient lives 40 miles from the hospital. The logistics layer (Component G) with route optimization is not optional. It is what makes the program economically viable. We cover the full rural deployment model in our technology stack for a 25-bed rural hospital guide.
- Funding. RHTP funding is specifically designed for rural facilities. Rural hospitals in every state now have access to state-level RHTP allocations that can cover H@H technology implementation. The barrier shifted from “can we afford this” to “how do we structure the build to qualify for state RHTP funding.”
How Mindbowser Approaches Hospital at Home Platform Development
We build custom healthcare technology platforms. That’s the short version.
The longer version: we’ve spent eight-plus years building clinical software that handles real patient data, integrates with real EHR systems, and passes real compliance reviews. The accelerators we’ve developed (WearConnect for RPM, HealthConnect for care coordination, AI SummaryAssist for clinical documentation, PHISecure for HIPAA compliance) compress the H@H build timeline from 24+ weeks to 16 weeks because we are not starting from scratch on five of the seven components.
A typical engagement:
- Week 0-1: Architecture workshop. We map your clinical workflows, EHR environment, device preferences, and CMS waiver status. Output: technical architecture document and implementation plan.
- Week 2-16: Build. Following the timeline above, with weekly clinical stakeholder check-ins and biweekly demos.
- Week 16+: Support and iteration. Dedicated engineering team for bug fixes, feature requests, and scaling as your patient census grows.
What you own at the end: The platform. The code. The data. The IP. A custom build means the H@H platform is yours to modify, extend, sell to your network partners, or use as a competitive differentiator in your market. The same platform can evolve into your health system’s broader remote care infrastructure as the H@H model expands into post-acute, chronic disease management, and specialty care delivery at home.
For health systems pursuing state RHTP funding, we coordinate with state program offices and prime contractors on procurement-aligned builds.
Conclusion:
Hospital at Home is no longer an experiment. With CMS approval extended through 2030, proven cost savings, and new RHTP funding opportunities, health systems now have a clear window to build programs that scale. The difference between a pilot that stalls and a program that grows often comes down to the technology foundation underneath it. Integrated, purpose-built platforms reduce clinical friction, improve outcomes, and give health systems control over their future care model instead of locking them into someone else’s workflow.
Hospital at Home is an acute care delivery model where patients who qualify for inpatient admission receive hospital-level care in their own residence instead of a hospital bed. Patients receive continuous remote monitoring, daily physician evaluation via video, home nursing visits, and medication delivery, all under CMS waiver authorization valid through September 2030. The model originated at Johns Hopkins in the 1990s and expanded significantly under the CMS Acute Hospital Care at Home waiver issued in November 2020. 419 hospitals are currently approved. Cost savings typically run 30-38 percent compared to traditional inpatient care, with comparable or better outcomes per the Commonwealth Fund’s 14-hospital study.
A patient qualifying for inpatient admission is offered H@H as an alternative if their home environment supports acute care delivery. After consent and home assessment, the patient is discharged home with clinical-grade RPM devices (continuous pulse oximetry, blood pressure, temperature), a patient-facing tablet or app for symptom check-ins and video visits, and a care team schedule that includes twice-daily physician or APP video rounds plus one to two daily in-person nursing visits. A 24/7 clinical command center monitors vitals, triages alerts, and dispatches emergency response if needed. Medications, labs, imaging, and procedures are either performed in-home or transported. The technology platform (RPM ingestion, AI alert filtering, video rounding, EHR integration, care coordination dashboard, logistics dispatch) is the operational backbone that makes this care model work at scale.
16-24 weeks for a custom platform covering all 7 components (RPM, video visits, AI monitoring, EHR integration, patient app, care dashboard, logistics). Using pre-built accelerators for RPM ingestion and AI monitoring compresses the timeline to the lower end. The biggest variable is EHR integration. Epic FHIR takes 4-6 weeks. MEDITECH HL7v2 takes 6-8 weeks.
Development costs range from $305K to $540K depending on EHR complexity, device count, and AI requirements. Ongoing monthly costs run $9K-$23K for platform infrastructure (excluding per-patient device costs). Vendor platform licensing runs $15K-$40K per month and scales linearly with patient volume. Custom build breaks even at month 14-18 for most health systems.
CMS does not mandate specific vendors or technology solutions. The waiver requires continuous or near-continuous patient monitoring, daily physician evaluation capability, 24/7 patient communication access, emergency escalation procedures, and quality reporting. Your technology platform must support these capabilities. How you implement them is your decision.
You can, but most health systems find it creates clinician friction. Outpatient telehealth is designed for scheduled, 15-minute, standalone visits. H@H rounding is scheduled AND on-demand, 5-15 minutes, multiple times daily, with real-time clinical data context. Forcing an outpatient tool into an acute rounding workflow adds 20-30 minutes of documentation overhead per patient per day.
Clinical-grade, FDA Class II cleared devices for continuous monitoring: pulse oximeters with continuous SpO2, blood pressure monitors with scheduled auto-inflation, weight scales, thermometers, and condition-specific devices (glucometers for diabetic patients, peak flow meters for respiratory patients). The architecture decision that matters: build a device-agnostic ingestion layer so you are not locked into one manufacturer.
Cellular-enabled RPM devices transmit vitals over 4G/5G networks without requiring home WiFi. Video visits use bandwidth-adaptive streaming that degrades gracefully on slower connections. Budget $15-25 per patient per month for cellular data plans. 23 percent of rural Americans lack broadband. If your H@H platform requires WiFi, you have excluded nearly a quarter of your potential patients.
Under the CMS Acute Hospital Care at Home waiver (extended through September 2030), H@H admissions are reimbursed at standard inpatient DRG rates. Medicare pays the same whether the patient is in a hospital bed or their own bed. Commercial payers are following. Humana, Aetna, and several Blue Cross plans now cover H@H admissions. Medicaid coverage varies by state. The Center for Health Care Strategies (CHCS) published a dedicated resource on H@H for Medicaid enrollees that tracks which state Medicaid programs reimburse H@H admissions and under what conditions. States expanding Medicaid H@H coverage as part of RHTP plans are a rapidly growing category, which is why we cover Medicaid-specific considerations in our rural hospital H@H launch guide.
Yes. The CMS waiver explicitly encourages CAH participation. Critical Access Hospitals face unique constraints (25-bed cap, 1-2 IT staff, limited broadband in service area), but H@H extends their effective capacity without building new beds. The technology platform needs to account for these constraints: cellular-enabled devices, operationally simple dashboards, managed cloud infrastructure. Several states have allocated RHTP funding specifically for rural H@H programs. See our Critical Access Hospital technology guide for CAH-specific implementation patterns. This page references the following primary federal sources. All citations link directly to the official Federal Register, CFR, or agency record.
