Skip to content
Real-time systems

A Video Call Is Not a Clinical Workflow

A real-time telehealth workflow that coordinates guided exercise, movement recording, pain and strength questions, provider collaboration, and tenant-configured assessment behavior.

Written by Montasim
3 min read

The visible feature was only the surface

Remote movement assessment requires more than a video call. Patients and providers must stay synchronized while exercises change, instructions play, recordings start and stop, pain or strength questions appear, network conditions vary, and either participant can leave unexpectedly.

The system also had to respect concrete constraints. Camera, microphone, permissions, network quality, and WebRTC lifecycle events differ across browsers and patient devices. Exercise, recording, pain, strength, queue, and provider-presence state must not leak from one movement or session into the next. Tenant feature flags alter available assessment behavior without allowing unsupported controls to appear or execute. Disconnection, provider departure, stale media, and failed API responses require recoverable states that do not leave patients trapped on a loading screen.

My role covered frontend and real-time workflow engineering within the mymedicalhub team, with responsibility for webrtc sessions, media recording, exercise state, socket.io coordination, tenant features, and failure recovery.

I turned the constraints into boundaries

Next.js routes host tenant-aware telehealth rooms, focused React contexts own socket, recording, media, and error state, Redux coordinates assessment APIs, and Socket.IO synchronizes room and exercise events across participants.

Socket, media, recording, and error lifecycles are separated so one high-frequency concern does not own every room transition.

Recorded previews, questions, and movement state are cleared when the exercise changes so stale clinical media cannot reappear in a new task.

Strength analysis, guidance, and related controls are enabled only when the current tenant contract supports them.

Provider exit, peer disconnect, API failure, and degraded network paths transition to explicit messages and redirects instead of indefinite loading.

The key decision: Give each real-time concern a focused context.

The implementation had to prove the model

I delivered the work across the full path: Contributed to the migration and ongoing development of the Next.js and TypeScript telemedicine experience. Implemented strength-exercise recording and state support, tenant-feature handling, patient/provider messaging, and guided movement UI behavior. Fixed stale movement media, provider-departure loading, invitation validation, queue updates, and other cross-session lifecycle defects. Worked across WebRTC media hooks, Socket.IO coordination, Redux assessment state, authenticated services, and responsive room components.

The result is concrete: Patients and providers can coordinate guided movement and exercise sessions through one real-time room experience. Exercise changes no longer reuse stale recordings or question state from a previous movement. Strength and other tenant-specific workflows can be introduced without forking the telehealth application. Departure, connection, and service failures resolve into clearer recovery or redirect paths instead of trapping the session.

The senior engineering lesson was that solving the visible workflow is only half the job. The architecture must also make constraints, failure modes, evidence, and ownership explicit enough for the next change to remain safe.

Working through a similar challenge?

Share your context, constraints, and timeline to start a focused conversation.

Leave a reply

Respond to the article or continue the discussion.

Ctrl + Enter to post

Your email stays private. Comments are stored securely.