The problem with remote monitoring
The need for remote health solutions has grown, especially since the pandemic, and it has pushed digital monitoring and telehealth forward quickly. Most of that monitoring still depends on a device. Wearable sensors bring their own problems: people stop wearing them, and not every patient can get or manage one.
A facial scan removes that step. Someone with a smartphone and an internet connection can take a reading without anything being attached to them, which makes regular monitoring easier to keep up.
A reading on its own does not change anyone's care, though. It has to reach a doctor in a form they can act on quickly, and the doctor needs a way to respond. AvatarX was built around both sides of that exchange: patients track their own vitals, while doctors invite, monitor and proactively manage their patients in one system.
What we knew before we built
No before-and-after baseline is published for this product, so this page does not offer an improvement figure. What can be stated is the shape of the problem the build had to answer.
- 0
- Wearables or extra sensors a patient should need to take a reading
- 2
- Audiences with different jobs: patients taking scans and doctors acting on them
- 1
- Platform carrying vitals, medication details and messages between them
That set three requirements for the work. A patient with no technical background had to be able to complete a scan unaided. A doctor had to be able to read a patient's status and respond without leaving the platform. And sensitive health data had to stay protected at every step between the two.
The approach we chose
The product is split into two portals with different jobs, joined by shared APIs so that a scan taken on one side is available for review on the other.
- User portal. Patients scan their face, get feedback on their vitals, and see visualizations or recommendations.
- Doctor portal. Clinicians invite patients, monitor their health data in real time, and prescribe care remotely.
The journey through those portals runs in four stages:
- Register. The patient signs up and completes a first face scan, which gives them baseline metrics.
- Invite. A doctor invites the patient to the monitoring portal and gains access to their vitals.
- Monitor. The patient scans regularly, prompted by the app or at the doctor's request, and each result is sent through and visualized for review.
- Respond. The doctor reviews trends, shares prescriptions or health tips, and exchanges secure messages with the patient, all within the platform.
What we built
Our contribution was full-stack development: the backend APIs, the frontend for both portals, and the integration between them.
A facial scan that returns health vitals
Video-based AI algorithms analyze facial image data to estimate metrics such as heart rate, respiratory rate and stress level. That layer combines facial recognition SDKs with custom AI models, and the scan flow guides the patient through it and on to their report.
APIs between the two portals
The backend is a set of REST APIs built on Node.js and Express.js, with Knex and PostgreSQL underneath. They carry data between the user and doctor portals, and were designed around secure transmission and keeping the doctor's view accurate in real time.
Responsive interfaces for both audiences
The frontend is built with Next.js, Tailwind CSS and JavaScript, and works across devices for patients and doctors alike. A patient is walked through a scan and a report; a doctor gets a view organized around the people they are monitoring.
Avatar-based views for quick decisions
Doctors see patient data through simplified avatar graphics rather than raw tables alone, so a patient's status can be read at a glance. The same idea serves patients, where a visual result and a direct feedback loop are meant to keep them engaged with their own care.
Medication sharing inside the workflow
Doctors can share medication details and prescriptions, follow a patient's progress and communicate with them from inside the product, so that this part of remote care does not depend on a separate tool.
A scan only helps if a patient can finish it without help, and a reading only helps if a doctor can act on it.
The guardrails around health data
This product handles sensitive health data, and a doctor may act on what it shows. Controls were therefore part of the build rather than something added afterwards.
- Encryption. Data is encrypted at rest and in transit.
- Access controls. Strict controls limit who can see a patient's data, and a doctor's access to a patient's vitals follows the invitation and enrollment step.
- Secure communication. Messages and medication details between doctor and patient stay within the platform.
- A doctor in the loop. The app presents estimates. Reviewing them and deciding on a prescription remains with the doctor.
- Testing across conditions. Scan results have to be tested and calibrated across varied lighting, backgrounds and skin tones before they can be relied on.
- Privacy standards as a design reference. HIPAA and related privacy standards informed the encryption and access design. As on our healthcare page, we do not describe a system as “HIPAA compliant” as a generic feature, because compliance depends on the organization, its contracts, data flows and use.
What was reported
This page reports what was built, not measured outcomes. The product is designed to make a difference in three areas, and each of these is an intended effect rather than a measured result:
- Accessibility. Monitoring without a physical device extends vital-sign tracking to people with a smartphone and an internet connection.
- Clinical decision support. Real-time data gives doctors more to work with when personalizing treatment and managing a patient's health proactively.
- Patient engagement. Visual avatars and direct feedback aim to raise patients' awareness of their health and support adherence to their care plan.
What stays hard
Four challenges shaped this work, and any team building a product of this kind should plan for them.
- Accuracy and reliability. Keeping facial-scan metrics consistent across varied lighting, backgrounds and skin tones is the central challenge, and it takes extensive testing and calibration to stay clinically relevant.
- Privacy and data security. Sensitive health data has to be encrypted and kept behind strict access controls, measured against HIPAA and related privacy standards.
- User experience. Vitals scans and doctor interactions have to stay straightforward for people with no technical background, which takes deliberate design of each flow.
- Scalability. Many scans and doctor-patient sessions can run at once, which calls for efficient APIs and real-time data pipelines.
Where it could go next
These are possible directions, not shipped features: integration with wearables, a wider range of biometric data such as emotion and chronic conditions, and predictive analytics for preventative care.