01 PERSONAL SITE
/
← RESEARCHER

Interscalar medicine / long-form research note / January 2025

Rehabilitation OS — an Operating System for Patient Recovery

Recovery rarely occurs inside one institution, one profession, or one software product. A person may move from an acute hospital to inpatient rehabilitation, outpatient therapy, primary care, home exercise, community services and work while laboratory systems, imaging archives, electronic health records, wearable devices, patient-reported measures, insurers and equipment suppliers each preserve only a fragment of the process. The result is not merely fragmented data. Goals become detached from interventions, interventions from outcomes, and preventable organizational failures from the clinical record.

The proposed Rehabilitation OS is a coordination layer for this longitudinal process. It connects existing systems, people and devices around an auditable sequence of goals, observations, decisions, actions and outcomes. “OS” is a metaphor for shared services and orchestration, not a claim that one program should replace every electronic health record or control every clinical decision.

The need is large: a Global Burden of Disease analysis estimated that at least one in three people worldwide could benefit from rehabilitation at some point during an illness or injury (R1; PMID 33275908). Scale makes coordination important, but scale does not validate a particular platform. Rehabilitation OS is therefore a testable design proposal, not an established clinical technology or a new medical specialty.

WHO’s Rehabilitation 2030 initiative similarly calls for rehabilitation across the life course, integration at all levels of health care, equitable access, multidisciplinary capacity, and stronger health-information systems using functioning and ICF data (O17). This is a health-system mandate, not an endorsement of an “operating system” product or of continuous digital monitoring.

A working definition

Rehabilitation OS is a standards-based, patient-centred orchestration environment that maintains a longitudinal, versioned record of recovery-related events; links those events to agreed functional goals and care plans; supports communication and bounded decision support; and makes responsibility, provenance, uncertainty and outcomes visible across settings.

It is not, by definition:

  • a replacement for hospital EHR, laboratory, imaging, scheduling or billing systems;
  • a data lake that copies every available datum into one repository;
  • a wearable-device dashboard;
  • an autonomous therapist or a universal AI model;
  • a blockchain; or
  • a guarantee that connected data will improve outcomes.

The operating-system analogy is useful only if it identifies concrete platform services: identity, permissions, semantic translation, event transport, versioning, goal and workflow state, notifications, audit, application interfaces and observability. It becomes misleading when it implies a single vendor, a universal clinical ontology, or a central authority that silently overrides local practice and patient choice.

Why rehabilitation requires a longitudinal coordination layer

An ordinary encounter record answers, “What was documented at this visit?” Rehabilitation also needs to answer:

  • What matters to the patient, and how was that goal agreed?
  • What could the person do in a standardized assessment and what did they actually do at home?
  • Which intervention was planned, delivered, modified, declined or unavailable?
  • Was a missed session caused by pain, transport, cognitive difficulty, caregiver burden, scheduling failure or a choice to stop?
  • Which observation triggered a decision, who was responsible, and did the action occur?
  • Did function, participation, safety or quality of life change, and for how long?

The World Health Organization’s International Classification of Functioning, Disability and Health (ICF) supplies a defensible semantic frame. It treats functioning as an interaction among body functions and structures, activities, participation and environmental factors; it was endorsed by the World Health Assembly as an international standard in 2001 (O1). An ICF-based problem-solving form has been proposed to focus multidisciplinary work on patient-relevant problems, modifiable factors and shared responsibility (R2; PMID 12405874).

ICF does not prescribe software architecture, and a code does not substitute for a conversation. Its value here is to prevent the system from reducing recovery to biomarkers or exercise counts. A stronger leg is a body-function change; walking across a room is an activity; returning to work or family life is participation; stairs, transport, assistive products and another person’s support are environmental conditions. The same clinical capacity can produce different real-world outcomes in different environments.

The event ledger: the central but not exclusive component

The original concept places an event ledger at the centre. A safe interpretation is a longitudinal, append-preserving and versioned clinical event record from which current views can be derived. It should preserve the original statement, later correction, author, timestamp and reason for change. It must not freeze clinical errors forever or present superseded information as current.

A minimally useful event envelope contains:

Field Purpose
Event identity Globally or locally unique identifier; duplicate-detection rules
Patient, episode and plan Whose trajectory and which rehabilitation episode or pathway
Event type and clinical code Observation, goal, task, intervention, result, adverse event, access barrier, correction
Effective time and recorded time When it happened versus when it entered the system
Source and actor Patient, caregiver, clinician, device, algorithm or administrative system
Context Location, assistance, device used, pain, fatigue, environment and assessment protocol
Value and units Structured result plus original representation when necessary
Status and certainty Planned, in progress, completed, not done, unknown; confirmed, estimated or patient-reported
Provenance Origin, transformation, software/model version and responsible organization
Data quality Completeness, calibration state, plausibility flags and reason for missingness
Goal and causal links Which goal, plan, preceding observation, decision or action it relates to
Access and consent metadata Applicable purpose, permission, sensitivity and retention rule
Correction relationship supersedes, amends, entered-in-error or disputed status

The distinction between effective time and recorded time is essential. A fall reported two days later, a laboratory result posted after discharge and an exercise session synchronized after loss of connectivity have different implications. Likewise, “exercise not recorded,” “exercise not attempted,” “exercise stopped because of chest pain” and “exercise unavailable because the device was not delivered” are not the same event.

The ledger is not necessarily one physical database. A federated implementation may retain imaging, waveforms or raw sensor streams at their source and store normalized summaries, identifiers, hashes, provenance and retrieval permissions in the coordination layer. This reduces unnecessary duplication and supports data minimization. Nor does the ledger require distributed-ledger technology: conventional versioned databases and signed audit trails can satisfy most requirements with less complexity. Blockchain would need a separate, demonstrated requirement such as distrust among writers that cannot be handled through governance and access control.

One timeline, three different records

The phrase “event log” can hide three records with different purposes, readers and retention rules:

  1. The clinical event ledger contains observations, goals, decisions, actions, corrections and the derivation of the current clinical view. Clinicians and patients may need to see and contest it.
  2. The security audit record answers who viewed, changed, disclosed or exported information and under which authorization. It must preserve evidence, has restricted readership and should not be rewritten merely because a clinical statement was corrected.
  3. Operational telemetry records queues, retries, latency, device connectivity, software errors and service health. Engineers need it to diagnose failures, but a retry or dropped packet is not automatically a clinical fact.

FHIR reflects part of this separation: Provenance describes how a clinical resource came to be, while AuditEvent records security-relevant activity (O4, O5). Operational telemetry needs its own governed store and a deliberate promotion rule: only a clinically meaningful technical failure—such as a sensor outage that invalidates a promised monitoring service—should generate a patient-linked clinical or coordination event. Mixing the three layers risks displaying infrastructure noise as illness, exposing sensitive audit data to ordinary users, or deleting accountability evidence when a clinical error is amended.

From events to a recovery contract

The system becomes clinically useful when it connects events to an explicit, revisable plan. A recovery contract is not a legal promise by the patient and must not become a compliance score. It is a structured agreement describing:

  • a patient-prioritized outcome;
  • the baseline and measurement method;
  • target state, time horizon and acceptable range;
  • planned interventions and responsible participants;
  • safety limits and escalation rules;
  • resources and environmental assumptions;
  • review date and conditions for revision; and
  • the patient’s right to change priorities or decline optional monitoring.

HL7 FHIR already contains relevant building blocks. Goal describes a desired state and is commonly evaluated by Observation; CarePlan connects goals with planned and performed activities; Task, ServiceRequest, Procedure, QuestionnaireResponse, Communication, Provenance and AuditEvent represent other parts of the loop (O2, O3, O4, O5). FHIR is an exchange specification, not a complete workflow, user interface or clinical governance model. Local profiles, implementation guides and terminology bindings remain necessary.

Goals should not be treated as inherently therapeutic. A Cochrane review of 39 studies involving 2,846 rehabilitation participants found very low-quality evidence for some psychosocial benefits but no consistent evidence that goal setting improved activity, participation or physical function (R3). The platform can make goals traceable and collaborative; whether a particular goal-setting process improves outcomes remains an empirical question.

The intervention is not the appointment

An event ledger can faithfully record that “physical therapy occurred” and still leave the treatment itself as a black box. Discipline, billing code, device name, exercise label and session duration do not reveal what the clinician or patient did, which function they intended to change, how the activity was progressed, or why it was expected to work. This is not a minor documentation problem: without treatment specification, similar labels can conceal different interventions and different labels can describe materially similar ingredients.

The Rehabilitation Treatment Specification System (RTSS) is a theory-driven framework proposed to describe treatment through three linked elements: a target—the aspect of functioning intended to change directly; one or more ingredients—the clinician, system, patient or caregiver actions selected to change it; and a hypothesized mechanism of action connecting ingredients to the target (R20; PMID 30267669). Related work argues that this structure could improve design, reporting, replication and synthesis because conventional categories such as “gait training” or “three hours of occupational therapy” do not identify active treatment content (R21; PMID 30267666).

A Rehabilitation OS should therefore distinguish five objects rather than compressing them into a completed appointment:

Object Question it answers Example
Patient goal What change in life matters to the patient? Walk independently to the nearby shop
Treatment target What function is this intervention intended to change directly? Increase paretic ankle dorsiflexion during swing
Ingredients and dose What actions are delivered, by whom, how much and with what progression? Task-specific stepping with cueing; 30 minutes; assistance faded by a defined rule
Hypothesized mechanism Why should those ingredients change that target? Repeated task practice and feedback improve motor control
Delivery and response What was actually delivered, adapted, omitted and observed? 22 minutes completed; stopped for pain; cueing not faded; home transfer not yet observed

The distinctions prevent two common errors. First, a valued participation goal is not necessarily the direct target of one treatment component: many targets, services and environmental changes may contribute to returning to work. Second, treatment fidelity is not patient obedience. The system should record both whether planned ingredients were delivered and whether the patient could or chose to engage, including reasons such as pain, competing care, inaccessible instructions or clinician modification.

The need is empirical as well as conceptual. A systematic review of 12 randomized trials covering 1,588 participants in technology-enabled remote or hybrid cardiac rehabilitation found that none fully reported all 12 TIDieR intervention items; the median was eight, with details, dose and modification among the weaker areas (R23; PMID 37899659). This study assessed reporting completeness, not whether RTSS improves care, and its cardiac-rehabilitation scope does not establish the same deficit everywhere.

RTSS itself has limits. It is a specification framework, not a proven universal ontology, a causal proof or an interoperability standard. In a survey of 111 professionals who had explored RTSS, frequently reported barriers included complexity, limited resources, access to knowledge and confidence in using the framework (R22; PMID 36306923). The sample was self-selected and the study did not test patient outcomes. A practical implementation should begin with a small number of high-value treatment classes, reuse data already needed for care, allow narrative exceptions and measure added documentation time.

WHO SMART Guidelines offer a complementary precedent for turning narrative recommendations into software-neutral workflows, core data dictionaries, decision logic, indicators and functional requirements (O21). The current WHO publication catalogue does not identify a general rehabilitation SMART Guideline, so this is a method to learn from—not a ready-made Rehabilitation OS specification or WHO endorsement of RTSS.

Six architectural layers

1. Sources and adapters

Hospital EHRs, laboratory and imaging systems, pharmacy, scheduling, rehabilitation equipment, patient applications, questionnaires, wearables and payer or social-care systems remain systems of record for their domains. Adapters validate identity, units, timestamps, device status and authorization before translating data. Failed messages and partial synchronization are first-class events, not silent omissions.

2. Semantic normalization

Transport interoperability is insufficient if two systems interpret the same field differently. LOINC identifies health observations, measurements and documents (O6); SNOMED CT supplies a broad clinical terminology and emphasizes that semantic interoperability depends on both terminology and information architecture (O7); ICF represents functioning and context. Mappings need versions, owners, tests and a way to preserve the source term. A forced mapping that loses clinically important meaning is worse than an explicit unmapped value.

3. Longitudinal event and state services

The ledger stores versioned events; projections create current medication, goal, task, risk and trajectory views. The openEHR reference model is relevant prior art: it distinguishes event from persistent compositions, records who, when, where and why, and keeps clinical content in version-controlled compositions with change-set contributions (O8). ISO 13940:2015 provides a system of concepts for continuity of care and semantic interoperability; a second edition was still under publication when this draft was prepared, so claims should continue to cite the published 2015 edition until the replacement is formally available (O9).

4. Goal, workflow and decision-support services

Rules compare actual events with plan state and produce prioritized work, not merely alerts. Simple deterministic checks should be preferred when they answer the question: an overdue equipment order or missing follow-up appointment does not require machine learning. Models may estimate trajectory or risk only when their context of use, input quality, uncertainty, subgroup performance and action pathway are defined.

5. Role-specific applications

Patients, caregivers, therapists, physicians, nurses, coordinators and administrators need different views of the same process. A patient may need the next agreed action, progress in meaningful language and a way to explain a missed task. A therapist may need change since the last review, source data and exceptions requiring attention. An operational lead may need unresolved handoffs without access to unnecessary clinical detail. SMART on FHIR demonstrates a standards-based approach to substitutable applications over EHR data, although production interoperability still requires local implementation work (R4; PMID 26911829).

6. Governance and control plane

Identity, role and attribute-based access, consent, purpose-of-use, retention, audit, terminology and model versions, incident management, service-level ownership and decommissioning belong in the architecture, not in an appendix. The system must support correction, disagreement and appeal. A patient’s interpretation can coexist with a clinician’s interpretation without being overwritten as “noise.”

The operating loop

A minimal closed loop is:

shared goal → baseline → plan → event capture → interpretation → bounded action → outcome → review or revision

Each transition needs an owner and a timeout. An alert with no accountable recipient is not a safety mechanism. A recommendation without an available action is not decision support. A measurement without a defined response may be surveillance rather than care.

For example, a decrease in daily walking can produce several branches:

  1. Confirm that the device was worn, synchronized and validated for the metric.
  2. Ask about pain, fatigue, falls, illness, weather, assistance and changes in routine.
  3. Compare home performance with clinic capacity and the patient’s baseline.
  4. If a safety threshold is crossed, route to an accountable clinician within a defined time.
  5. If the cause is logistical, assign transport, scheduling or equipment work rather than a clinical escalation.
  6. Record the action and later test whether the trajectory or patient-prioritized outcome changed.

Temporal order supports investigation, but it does not establish causation. If a therapy change precedes improvement, natural recovery, regression to the mean, concurrent treatment and selection may still explain the result. Comparative effectiveness claims require a protocol, a comparator and methods appropriate to causal inference; target-trial principles are one way to expose avoidable time and selection biases in observational data (R5; PMID 27237061).

Patient-generated data need a clinical intake contract

Patient-generated health data (PGHD) include measurements, symptoms, questionnaires and contextual information created primarily by patients or their devices outside a clinical encounter. Standards can make these data transportable. A SMART-on-FHIR implementation integrated validated patient-reported outcomes into three EHR platforms across 18 ambulatory sites, showing multi-site technical feasibility (R14; PMID 34279660). A broader PGHD pipeline has also been specified around acquisition, aggregation, context, standardized units and downstream clinical use (R15; PMID 35142627).

Interoperability does not answer the clinical questions: who asked for the data, how often anyone looks, what quality is sufficient, what result triggers action, and what happens outside service hours? Before Rehabilitation OS accepts a feed, the patient and responsible service should have a clinical intake contract specifying at least:

  • metric and intended clinical question, not merely a vendor field name;
  • instrument or device, version, placement, calibration and evidence for this population;
  • expected schedule and the distinction among absent, delayed, declined and technically failed data;
  • context required for interpretation, such as assistance, pain, environment or exercise protocol;
  • units, aggregation window, source fidelity and rules against silently replacing raw values;
  • named reviewing role, realistic review interval and out-of-hours statement;
  • thresholds, confirmation steps, available actions and escalation time;
  • whether unsolicited data are accepted, summarized, redirected or not monitored;
  • retention, amendment, export, secondary-use and revocation rules; and
  • a plain-language explanation that the channel is or is not suitable for emergencies.

This contract protects against a common semantic trap: “uploaded” does not mean “reviewed,” and “reviewed” does not mean “clinically actionable.” Interviews with 20 stakeholders in remote-monitoring programs identified digital literacy, wearable accuracy, interpretation, interoperability and weak quality-assurance processes as connected problems (R16; PMID 32025644). A 2025 health-system report therefore framed PGHD governance around expectations, staffing and workflow, user experience, and health-information management (R18). That report is valuable practice evidence, but it is a single-centre sociotechnical commentary based on workgroups, not a trial of patient outcomes.

The contradiction matters: integrating more home data may close information gaps while opening a responsibility gap. If staffing cannot meet the advertised review window, the ethical response is to narrow the feed or the service promise—not to make the patient responsible for detecting that nobody is watching.

What existing evidence supports—and what it does not

Evidence supports components of the concept, not the complete Rehabilitation OS.

Remote rehabilitation can deliver care in selected settings. In an assessor-blinded randomized noninferiority trial of 124 adults 4–36 weeks after stroke, dose- and intensity-matched home telerehabilitation produced arm-motor improvement comparable with in-clinic therapy (R6; PMID 31233135). This supports the feasibility of a supervised home pathway for a defined population and intervention. It does not prove that all telerehabilitation, passive monitoring or integrated platforms are equivalent to in-person care.

Wearables can add a view of everyday performance. Free-living activity profiles from 2,001 people with knee osteoarthritis were associated with categories of standardized walking and sit-to-stand performance (R7; PMID 30394876). Capacity and real-world performance, however, remain distinct. A device can count movement without knowing whether the activity was safe, meaningful, painful or assisted.

Measurement quality is uneven. A review of 237 free-living wearable-validation results found substantial methodological variation and classified 72.9% as high risk of bias under its decision framework (R8; PMID 35679106). A digital measure therefore requires verification, analytical validation and clinical validation for its stated context of use, not just a consumer-device accuracy claim (R9; PMID 32337371).

Standards make exchange and reuse possible, not correct by default. FHIR, openEHR, SNOMED CT, LOINC and ICF can reduce bespoke integration and semantic loss. They cannot resolve an ambiguous goal, an invalid instrument, incorrect patient matching, conflicting local policies or missing accountability.

A larger event log is not automatically a learning health system. Reusable data require identifiers, metadata, provenance, controlled access and explicit semantics; the FAIR principles formalize findability, accessibility, interoperability and reuse at a high level (R10; PMID 26978244). Clinical learning additionally requires valid designs, governance, feedback and evidence that changes improve care.

Practical scenarios

Scenario 1: transition from stroke unit to home

Before discharge, the team records a patient-prioritized activity and participation goal, standardized motor and cognitive assessments, communication needs, caregiver capacity, equipment, medication and follow-up. The system checks that the home program, device delivery, therapy appointment and escalation contact are assigned. At home, the patient reports fatigue and task difficulty; a validated sensor supplies activity summaries. A fall, sudden neurological symptom or repeated failure to contact follows a safety pathway. Lower-than-planned activity without danger triggers a conversation, not an automatic label of non-adherence.

Scenario 2: recovery after knee surgery

The plan contains pain, wound, range-of-motion, walking and participation checkpoints. A motion sensor may document prescribed exercise, while patient reports describe pain, sleep and confidence. If range improves in a supervised test but daily walking falls, the system asks whether swelling, fear, weather, device non-use or social constraints explain the difference. The clinician may adjust the plan; automatic exercise progression should be limited to a validated low-risk protocol with explicit stop rules.

Scenario 3: chronic progressive disease

Improvement is not always the correct target. The contract may specify maintenance of transfers, communication, energy conservation or participation for a defined period. A stable score can represent success against expected decline. The system should avoid penalizing a patient or service because biology makes linear improvement impossible.

Scenario 4: organizational failure

The patient misses therapy because authorization is pending and transport was cancelled. A conventional dashboard may show “non-compliance.” The event model records the prescription, authorization request, unresolved payer response, transport cancellation, patient notification and missed session. Responsibility shifts to the process owner, and the outcome can be analyzed as an access failure rather than a behavioural defect.

Scenario 5: multidisciplinary review

Instead of each profession presenting separate notes, the review starts with the patient’s goals and unresolved deviations. The team sees which observations are confirmed, which conflict, which data are missing, what actions were completed and what decision is required. The shared view does not erase discipline-specific records; it provides a common, auditable projection over them.

Counterarguments

“A modern EHR with FHIR already does this.”

Some EHRs can implement much of the proposal, and building a separate platform may be wasteful. The defensible claim is not that Rehabilitation OS must be a new product; it is that rehabilitation needs explicit cross-setting goal, event, provenance and accountability services. These may be implemented as native EHR modules, a regional interoperability service or a federated application layer. A new platform is justified only if it improves measurable gaps without duplicating authoritative systems.

This is true if raw technical events are exposed as the clinical record or corrections are poorly represented. The response is separation: preserve provenance and revision history, derive a clinically reviewed current state, distinguish disputed and entered-in-error data, and define which events are legally authoritative. Event sourcing is an implementation option, not a moral requirement.

“Continuous monitoring improves safety.”

Sometimes, but it also creates false alarms, surveillance and unreviewed liability. Clinical alert research shows that repeated low-value alerts and complexity reduce acceptance; alert fatigue cannot be solved by adding another inbox (R11; PMID 28395667). Monitoring should be proportional to risk, time-limited when possible and tied to staffed response capacity.

“More data will make the algorithm fairer.”

Volume does not correct a biased target. A widely used population-health algorithm produced racial bias because healthcare cost was used as a proxy for health need (R12; PMID 31649194). Rehabilitation data can encode unequal access to therapy, devices, housing, transport and paid leave. Context variables should generally trigger support, not justify withholding care.

“Automation will release clinicians for human work.”

It may, but poorly designed integration shifts clerical work, reconciliation and alert review onto clinicians and patients. Time saved, time added, work transferred and work left undone must all be measured. Automation should first target reliable administrative handoffs and summarization; higher-risk autonomous clinical actions need stronger evidence and controls.

“Patents demonstrate that the concept is mature.”

Patent documents show that related ideas have been disclosed: wearable-guided exercise management (P1), home rehabilitation integrating sensors, patient-specific models and a virtual coach (P2), a platform spanning clinician, therapist and home interfaces with external-system integration (P3), remote adjustment of a personalized cardiac-rehabilitation plan from ECG, physiologic and patient-feedback data (P4), and adaptation of gait or balance training from wearable-derived “compliance” and everyday-activity improvement indexes (P5). Google Patents displayed P5’s European application as withdrawn while listing later family applications, illustrating why publication number, jurisdiction, family and status must not be collapsed into “the patent exists.” A patent is not peer-reviewed clinical evidence, regulatory authorization, product availability or freedom to operate. Claim scope and current legal status require jurisdiction-specific professional analysis.

Safety, privacy and equity risks

  1. Patient mismatch and duplicate identity. A correctly measured event assigned to the wrong person can be more dangerous than missing data. Identity reconciliation, source confirmation and rollback procedures are safety controls.
  2. Semantic drift. Units, code versions, instrument editions and local meanings change. Mappings must be versioned and regression-tested.
  3. Invalid or out-of-context measurement. A step count, range-of-motion estimate or questionnaire may not be valid for the device, population, language, placement or home environment.
  4. Missingness mistaken for normality. Disconnection may reflect poverty, cognitive or motor impairment, hospitalization, device failure or disengagement. “No signal” must not default to “no risk.”
  5. Alert fatigue and diffusion of responsibility. Every actionable signal needs priority, recipient, timeout, escalation and closure. Suppression rules require safety review.
  6. Automation bias and self-fulfilling pathways. Staff may defer to a forecast; a pessimistic classification can reduce therapy and help produce the predicted poor outcome.
  7. Unequal representation and proxy discrimination. Performance must be evaluated across relevant age, sex, disability, language, socioeconomic, racial or ethnic, device and site groups. Small groups should not disappear into an overall average.
  8. Domestic surveillance. Video, audio, location and continuous movement can expose intimate routines and other household members. Collect the minimum necessary data, prefer on-device derivation when possible and offer a meaningful non-digital pathway.
  9. Cybersecurity and availability. Ransomware, credential theft, malicious device data or a cloud outage can interrupt care. A safe degraded mode and recovery plan are clinical requirements.
  10. Vendor lock-in. Proprietary event schemas, inaccessible audit history and non-exportable patient goals defeat the coordination purpose. Contracts should require export, terminology/version disclosure and safe termination.

ISO 81001-1:2021 frames safety, effectiveness and security across the health-software lifecycle (O10); IEC 81001-5-1:2021 specifies secure lifecycle activities (O11); IEC 62304 covers medical-device software lifecycle processes (O12); IEC 62366-1 addresses safety-related usability engineering (O13); and ISO 14971:2019 provides the general medical-device risk-management framework (O14). Applicability depends on intended use, product boundaries and jurisdiction; listing standards is not a claim of conformity.

Patient-facing companion apps can also be assessed against ISO/TS 82304-2:2021, which defines quality requirements and a quality-label framework for health and wellness apps across their lifecycle (O22). It can inform procurement and app assessment, but a label does not establish that a rehabilitation measure is clinically valid, that a recommendation improves outcomes, or that medical-device obligations do not apply.

If software supplies patient-specific recommendations or drives care, regulatory classification must be assessed function by function. IMDRF N41 separates valid clinical association, analytical/technical validation and clinical validation for Software as a Medical Device (O15). The FDA’s January 2026 clinical decision-support guidance illustrates how intended user, purpose and whether a professional can independently review the basis of a recommendation affect U.S. device analysis (O16). It does not determine status in the EU, Russia or another jurisdiction.

Accessibility is part of clinical safety

The population most likely to need Rehabilitation OS includes people with motor, visual, hearing, speech, cognitive and fatigue-related impairments. Accessibility therefore cannot be postponed to interface polish. If a person cannot report chest pain, understand a changed plan, use the identity check or reach a human after an alert, an inaccessible interface becomes a clinical hazard and a biased measurement instrument.

The baseline should combine WCAG 2.2’s testable web requirements (O19) with telehealth-specific requirements in ITU-T F.780.2 (2023), developed with WHO for services used by people with disabilities and older people (O18). At product level this means keyboard, switch and screen-reader operation; captions and text alternatives; sufficient target size and contrast; plain-language and pictorial modes; time extensions; asynchronous communication; low-bandwidth and offline recovery; and a telephone, paper or in-person path that does not punish the patient. A caregiver or proxy needs explicit delegation, scope, expiry and an audit trail—not the patient’s shared password.

Accessibility is also situational and must be tested with the intended users. In a study of 111 people with multiple sclerosis, clinicians identified low technology literacy, cognitive impairment and fall risk as barriers to telerehabilitation even while valuing reduced travel and scheduling flexibility (R17; PMID 36545648). A 2025 review of telehealth for people with disabilities found potential benefits but few intervention studies and substantial limits in study quality and reporting (R19; PMID 39352119). These findings support hybrid service design, but they do not estimate the comparative effectiveness of a universal accessibility bundle. The design implication is narrower: a successful remote pathway among connected volunteers does not demonstrate equitable access for the people excluded before enrollment.

A realistic implementation sequence

Phase 0: define the service, not the platform

Choose one population, transition and failure mode—for example, unresolved discharge tasks after stroke. Map the existing workflow, authoritative systems, safety incidents, patient burden and staff capacity. Define what will not be automated.

Phase 1: a read-only longitudinal view

Integrate a minimal set of goals, assessments, appointments, equipment and patient-reported events. Preserve source links and provenance. Test patient matching, time semantics, accessibility, translation and reconciliation before generating recommendations.

Phase 2: accountable tasks and low-risk rules

Add ownership, deadlines, escalation and closure for administrative and care-coordination gaps. Measure whether tasks are completed earlier and whether workload moves to another group.

Phase 3: patient communication and optional home data

Co-design accessible interfaces; provide non-smartphone alternatives. Add only validated measures with a stated purpose and retention period. Let patients annotate, correct or dispute events.

Phase 4: bounded decision support

Introduce transparent rules or models for a defined decision. Conduct silent prospective evaluation first, then small live evaluation with safety monitoring, human-factors analysis and subgroup reporting. DECIDE-AI provides a useful reporting framework for early live evaluation of AI-supported decisions (R13; PMID 35584845).

Phase 5: comparative impact evaluation

Compare the service with current care using patient-important functional and participation outcomes, safety, access, caregiver burden, clinician workload, total cost and equity. A before-and-after dashboard improvement is insufficient if case mix, secular trends or selective adoption explain it. For studies that acquire outcomes remotely, FDA’s 2023 guidance on digital health technologies offers useful questions about fit-for-purpose selection, verification, validation, usability, data retention and participant risk (O20). Its scope is clinical investigations; it is methodology support, not a rulebook or authorization for routine rehabilitation care.

How success should be measured

Success is not the number of integrated devices or stored events. A balanced evaluation should include:

  • patient outcomes: function, participation, quality of life, goal relevance, adverse events and sustained benefit;
  • access and equity: time to therapy, unresolved barriers, dropout and outcomes across prespecified groups;
  • process: closed-loop completion, handoff failures, time from signal to appropriate action and proportion of alerts with no response;
  • measurement: completeness, source agreement, correction rate, device uptime and clinically important missingness;
  • human factors: patient burden, accessibility, trust, disputes, clinician time, interruption and workarounds;
  • model performance, if used: calibration, discrimination, uncertainty, subgroup error, out-of-distribution behavior and net benefit;
  • economics: implementation and operating cost, resource displacement, caregiver time and cost per additional functional outcome;
  • resilience: downtime, recovery, security incidents and performance in degraded mode.

Predefined stopping rules should cover unexpected harm, discriminatory allocation, unmanageable alert volume, systematic identity errors and failure to respond within the promised service window.

Conclusion

Rehabilitation OS is strongest when treated as an architecture of responsibility rather than a promise of total automation. Its core is not a giant database or an omniscient model. It is a traceable relationship among what the patient values, what was planned, what actually happened, what the system inferred, who acted and whether that action improved life outside the clinic.

The event ledger can make recovery legible across scales—biology, function, behaviour, environment and organization—but it must preserve uncertainty, correction and dissent. A ledger that records appointments without treatment targets, ingredients, dose and actual delivery can coordinate logistics yet still cannot explain what was done or support credible learning about treatment. Standards can make components exchangeable, but they cannot supply clinical validity or governance. Sensors can extend observation into daily life, but they can also turn absence into suspicion and the home into a monitored ward. Algorithms can prioritize attention, but they can reproduce unequal access and overwhelm the people expected to respond.

The practical claim is therefore modest and testable: a standards-based, patient-centred coordination layer may reduce lost context and unowned failures in rehabilitation. It earns the name “operating system” only if it remains interoperable, contestable, safe under failure and demonstrably better than the fragmented process it replaces.

References / Список литературы

This is the verified source register for both language versions. The original register was checked on 28 July 2026; new and cited URLs were rechecked on 29 July 2026. DOI, PMID and patent publication identifiers are included when available. Standards pages are official bibliographic records; several full standards are paywalled. Patent status shown by aggregators is not a legal opinion.

Peer-reviewed rehabilitation, measurement and methods

  • [R1] Cieza A et al. Global estimates of the need for rehabilitation based on the Global Burden of Disease study 2019. The Lancet (2021). DOI 10.1016/S0140-6736(20)32340-0; PMID 33275908. Global need estimate, not evidence for a software platform.
  • [R2] Steiner WA et al. Use of the ICF Model as a Clinical Problem-Solving Tool in Physical Therapy and Rehabilitation Medicine. Physical Therapy (2002). DOI 10.1093/ptj/82.11.1098; PMID 12405874.
  • [R3] Levack WMM et al. Goal setting and strategies to enhance goal pursuit for adults with acquired disability participating in rehabilitation. Cochrane Database of Systematic Reviews (2015), CD009727. DOI 10.1002/14651858.CD009727.pub2; Cochrane evidence page.
  • [R4] Mandel JC et al. SMART on FHIR: a standards-based, interoperable apps platform for electronic health records. Journal of the American Medical Informatics Association (2016). DOI 10.1093/jamia/ocv189; PMID 26911829.
  • [R5] Hernán MA, Robins JM. Specifying a target trial prevents immortal time bias and other self-inflicted injuries in observational analyses. Journal of Clinical Epidemiology (2016). DOI 10.1016/j.jclinepi.2016.04.014; PMID 27237061.
  • [R6] Cramer SC et al. Efficacy of Home-Based Telerehabilitation vs In-Clinic Therapy for Adults After Stroke: A Randomized Clinical Trial. JAMA Neurology (2019). DOI 10.1001/jamaneurol.2019.1604; PMID 31233135; publisher full text.
  • [R7] Agarwal V et al. Inferring Physical Function From Wearable Activity Monitors: Analysis of Free-Living Activity Data From Patients With Knee Osteoarthritis. JMIR mHealth and uHealth (2018). DOI 10.2196/11315; PMID 30394876.
  • [R8] Giurgiu M et al. Quality Evaluation of Free-living Validation Studies for the Assessment of 24-Hour Physical Behavior in Adults via Wearables: Systematic Review. JMIR mHealth and uHealth (2022). DOI 10.2196/36377; PMID 35679106.
  • [R9] Goldsack JC et al. Verification, analytical validation, and clinical validation (V3): the foundation of determining fit-for-purpose for Biometric Monitoring Technologies. npj Digital Medicine (2020). DOI 10.1038/s41746-020-0260-4; PMID 32337371.
  • [R10] Wilkinson MD et al. The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data (2016). DOI 10.1038/sdata.2016.18; PMID 26978244. General data-stewardship principles, not clinical outcome evidence.
  • [R11] Ancker JS et al. Effects of workload, work complexity, and repeated alerts on alert fatigue in a clinical decision support system. BMC Medical Informatics and Decision Making (2017). DOI 10.1186/s12911-017-0430-8; PMID 28395667. General CDS evidence, not rehabilitation-specific.
  • [R12] Obermeyer Z et al. Dissecting racial bias in an algorithm used to manage the health of populations. Science (2019). DOI 10.1126/science.aax2342; PMID 31649194. General health-algorithm evidence, not rehabilitation-specific.
  • [R13] Vasey B et al. Reporting guideline for the early stage clinical evaluation of decision support systems driven by artificial intelligence: DECIDE-AI. BMJ (2022). DOI 10.1136/bmj-2022-070904; PMID 35584845.
  • [R14] Wesley DB et al. A novel application of SMART on FHIR architecture for interoperable and scalable integration of patient-reported outcome data with electronic health records. Journal of the American Medical Informatics Association (2021), 28(10):2220–2225. DOI 10.1093/jamia/ocab110; PMID 34279660; AHRQ citation record. Demonstrates implementation feasibility across 18 ambulatory sites and three EHR platforms, not patient-outcome superiority.
  • [R15] Zeng B et al. Standardized Integration of Person-Generated Data Into Routine Clinical Care. JMIR mHealth and uHealth (2022), 10(2):e31048. DOI 10.2196/31048; PMID 35142627. Conceptual pipeline and standards analysis, not an effectiveness trial.
  • [R16] Abdolkhani R et al. Patient-generated health data management and quality challenges in remote patient monitoring. JAMIA Open (2019), 2(4):471–478. DOI 10.1093/jamiaopen/ooz036; PMID 32025644. Qualitative interviews with 20 stakeholders; useful for failure modes, not prevalence estimates.
  • [R17] Gopal A et al. Accessibility to Telerehabilitation Services for People With Multiple Sclerosis: Analysis of Barriers and Limitations. International Journal of MS Care (2022), 24(6):260–265. DOI 10.7224/1537-2073.2022-002; PMID 36545648. Single-practice observational and qualitative evidence; supports barrier analysis, not universal effectiveness claims.
  • [R18] Griffin AC et al. A sociotechnical approach to defining clinical responsibilities for patient-generated health data. npj Digital Medicine (2025), 8:270. DOI 10.1038/s41746-025-01680-5; PMID 40355597; publisher full text. Single-health-system commentary based on sequential workgroups; operational guidance, not comparative outcome evidence.
  • [R19] Park HN et al. The Use of Telehealth for People With Disabilities: A Systematic Literature Review and Narrative Synthesis. Journal of Advanced Nursing (2025), 81(3):1241–1258. DOI 10.1111/jan.16470; PMID 39352119. Reports potential benefits alongside few intervention studies and heterogeneous quality.
  • [R20] Hart T et al. A Theory-Driven System for the Specification of Rehabilitation Treatments. Archives of Physical Medicine and Rehabilitation (2019), 100(1):172–180. DOI 10.1016/j.apmr.2018.09.109; PMID 30267669. Foundational conceptual description of RTSS; not a clinical-effectiveness study.
  • [R21] Van Stan JH et al. The Rehabilitation Treatment Specification System: Implications for Improvements in Research Design, Reporting, Replication, and Synthesis. Archives of Physical Medicine and Rehabilitation (2019), 100(1):146–155. DOI 10.1016/j.apmr.2018.09.112; PMID 30267666. Theory and research-reporting argument; proposed benefits require empirical evaluation.
  • [R22] Van Stan JH et al. Rehabilitation Treatment Specification System: Identifying Barriers, Facilitators, and Strategies for Implementation in Research, Education, and Clinical Care. Archives of Physical Medicine and Rehabilitation (2023), 104(4):562–568. DOI 10.1016/j.apmr.2022.09.021; PMID 36306923. Cross-sectional survey of 111 self-selected professionals; identifies implementation barriers, not patient outcomes.
  • [R23] McGrath A et al. Completeness of intervention reporting in randomised trials of technology-enabled remote or hybrid exercise-based cardiac rehabilitation: a systematic review using the TIDieR framework. Disability and Rehabilitation (2024), 46(19):4350–4358. DOI 10.1080/09638288.2023.2274887; PMID 37899659. Twelve trials, 1,588 participants; evaluates reporting completeness rather than RTSS or platform effectiveness.

Official classifications, interoperability specifications and standards

  • [O1] World Health Organization. International Classification of Functioning, Disability and Health (ICF). Official WHO classification page. Endorsed by WHA 54.21 on 22 May 2001.
  • [O2–O5] HL7 FHIR Release 4. Official resources: Goal, CarePlan, Provenance, AuditEvent, plus Observation, Task and QuestionnaireResponse.
  • [O6] LOINC. Official LOINC site. International standard for identifying health observations, measurements and documents; implementation and licensing conditions should be checked for the deployment context.
  • [O7] SNOMED International. Using SNOMED CT in Clinical Information. Official practical guide. Licensing and national extensions vary by territory.
  • [O8] openEHR Reference Model, EHR Information Model. Official current specification. Relevant for event/persistent compositions, context, contributions and versioning.
  • [O9] ISO 13940:2015, Health informatics — System of concepts to support continuity of care. Official ISO record and edition history. The page showed edition 2 under publication for August 2026 when checked; it was not treated as already published in this draft.
  • [O10] ISO 81001-1:2021, Health software and health IT systems safety, effectiveness and security — Part 1: Principles and concepts. Official ISO record.
  • [O11] IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle. Official ISO/IEC bibliographic record.
  • [O12] IEC 62304:2006+A1:2015, Medical device software — Software life cycle processes. Official IEC record.
  • [O13] IEC 62366-1:2015+A1:2020, Medical devices — Part 1: Application of usability engineering to medical devices. Official IEC record.
  • [O14] ISO 14971:2019, Medical devices — Application of risk management to medical devices. Official ISO record.
  • [O15] International Medical Device Regulators Forum. Software as a Medical Device (SaMD): Clinical Evaluation. IMDRF/SaMD WG/N41FINAL:2017. Official IMDRF page.
  • [O16] U.S. Food and Drug Administration. Clinical Decision Support Software: Guidance for Industry and FDA Staff. January 2026, docket FDA-2017-D-6569. Official FDA guidance page.
  • [O17] World Health Organization. Rehabilitation 2030 initiative. Official WHO initiative page. Ten action areas include equitable service delivery, multidisciplinary capacity, rehabilitation data in health-information systems and stronger evidence; this is policy direction, not platform validation.
  • [O18] ITU-T F.780.2 (V2) (04/2023), Accessibility of telehealth services. Official ITU recommendation record. In-force accessibility requirements for telehealth services used by persons with disabilities and older persons; developed with WHO.
  • [O19] W3C. Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation; latest published Recommendation linked here is dated 12 December 2024. Official specification. General web-accessibility baseline; conformance does not by itself establish clinical usability or safety.
  • [O20] U.S. Food and Drug Administration. Digital Health Technologies for Remote Data Acquisition in Clinical Investigations: Guidance for Industry, Investigators, and Other Stakeholders. December 2023, docket FDA-2021-D-1128. Official FDA guidance page. Applies to clinical investigations, not routine-care authorization.
  • [O21] World Health Organization. SMART Guidelines. Official WHO initiative page; official publication catalogue. Provides software-neutral layers for translating recommendations into workflows, data dictionaries, decision logic, indicators and implementation guides. No general rehabilitation package was identified in the catalogue checked on 29 July 2026.
  • [O22] ISO/TS 82304-2:2021, Health software — Part 2: Health and wellness apps — Quality and reliability. Official ISO record. Defines lifecycle quality requirements and a health-app quality label; it does not replace clinical validation or jurisdiction-specific medical-device requirements.

Patent documents: thematic prior art, not evidence of clinical benefit

  • [P1] US9919198B2, “Automated physical therapy systems and methods.” Granted 20 March 2018; wearable motion sensor, patient application, prescribed exercise and clinician communication. Patent document. Google Patents displayed the U.S. patent as active when checked; legal status requires independent verification.
  • [P2] US10130311B1, “In-home patient-focused rehabilitation system.” Granted 20 November 2018; sensors, patient-specific biomechanical and neurocognitive models, virtual coach and augmented-reality feedback. Patent document. Google Patents displayed the patent as active when checked; legal status requires independent verification.
  • [P3] WO2021121381A1, “Rehabilitation management system and method.” Published 24 June 2021; clinician, operator and home interfaces, rehabilitation prescriptions, patient-generated data and external-system integration. Patent document. The PCT publication itself is not a grant; national-phase rights and current status must be checked separately.
  • [P4] US11942203B2, “Systems and methods for providing and managing a personalized cardiac rehabilitation plan.” Granted 26 March 2024; externally worn monitoring device, individualized exercise sessions, ECG/non-ECG information, patient feedback and dynamic plan adjustment. Patent document. Google Patents displayed the U.S. patent as active when checked; status, claim scope and freedom to operate require independent legal analysis.
  • [P5] EP4094684A1, “Rehabilitation method.” Published 30 November 2022; wearable monitoring during training and everyday life, compliance/improvement indexes and adaptation of gait or balance training. Patent document. Google Patents displayed this European application as withdrawn and listed later family applications, including WO2022248529A1; family members and current rights require separate official-register review.