Televisit Vital Signs: A Guide for Clinical Informatics Teams

Clinical informatics teams sit at the intersection of clinical practice, data architecture, and technology implementation. When a health system adopts camera-based vital sign capture for televisits, the clinical informatics team owns the critical work of ensuring that physiological data captured through rPPG technology flows correctly through clinical systems, meets data governance requirements, supports clinical decision-making, and produces actionable analytics.

This guide covers the technical and governance considerations that clinical informatics professionals need to address when implementing televisit vital signs. It assumes familiarity with health data standards, EHR configuration, and clinical workflow design.

Data Standards for Camera-Based Vital Signs

Camera-based rPPG technology captures four primary vital sign parameters. Each must be mapped to appropriate clinical data standards for interoperability and semantic consistency.

Heart Rate. LOINC code 8867-4 (Heart rate). Units: beats per minute (/min). FHIR resource: Observation with category "vital-signs" and code from the vital signs panel. This is the most straightforward mapping -- heart rate is a universally standardized vital sign with well-established coding.

Heart Rate Variability. HRV is more complex from a standards perspective because multiple HRV metrics exist (SDNN, RMSSD, pNN50, LF/HF ratio). The most commonly used time-domain metric for clinical purposes is SDNN (standard deviation of NN intervals), LOINC 80404-7. RMSSD (root mean square of successive differences) maps to LOINC 80405-4. The clinical informatics team should work with clinical stakeholders to determine which HRV metrics are clinically relevant for their use cases and map accordingly. For most televisit applications, SDNN or RMSSD provides sufficient clinical utility.

Blood Oxygen Saturation (SpO2). LOINC code 2708-6 (Oxygen saturation in Arterial blood) or 59408-5 (Oxygen saturation in Arterial blood by Pulse oximetry). Units: percent (%). For camera-based SpO2, a distinction should be made from traditional pulse oximetry. Some health systems create a separate vital sign row or observation code to indicate the measurement method (camera-based versus contact pulse oximetry). This is a governance decision that should be made explicitly, as it affects how providers interpret the data and how it appears in trend views.

Stress Index. There is no universally adopted LOINC code for a composite stress index derived from HRV analysis. Health systems have several options: use a local code mapped to their EHR's vital sign or flowsheet framework, use the Baevsky Stress Index which has emerging standardization in HRV research literature, or decompose the stress index into its component HRV metrics and store those individually. The clinical informatics team should document the chosen approach and ensure that the stress index value is interpretable by clinicians with appropriate reference ranges.

FHIR Vital Signs Profile. For health systems implementing FHIR-based interoperability, camera-based vitals should conform to the FHIR Vital Signs Profile (part of US Core). Each vital sign measurement is represented as a FHIR Observation resource with the "vital-signs" category, appropriate LOINC coding, the patient reference, the encounter reference (linking to the televisit encounter), the effective date/time of measurement, and the value with units (valueQuantity). Additionally, the Observation resource should include a method element indicating that the measurement was obtained via camera-based rPPG, and a device element referencing the measurement system. This metadata is important for clinical interpretation and audit purposes.

EHR Integration Patterns

The integration architecture for televisit vital signs depends on the health system's EHR platform, telehealth infrastructure, and integration middleware.

Pattern 1: HL7v2 ORU Message Feed. The most widely supported integration pattern for incoming vital sign data. The rPPG measurement system generates an HL7v2 ORU (Observation Result) message containing the vital sign values, which is routed through the health system's integration engine (Rhapsody, Mirth Connect, Microsoft Health Integration Services) to the EHR.

Key ORU message design considerations include patient identification (MRN matching in PID segment), encounter linking (visit number in PV1 to associate vitals with the correct televisit encounter), observation coding (OBX segments with appropriate LOINC codes, units, and reference ranges), timestamp accuracy (OBR and OBX timestamps reflecting the actual measurement time during the visit), and result status (final versus preliminary, depending on governance policy).

This pattern works with virtually every EHR and requires standard integration engine capabilities. The primary implementation effort is message mapping, testing, and validation.

Pattern 2: FHIR API Integration. For health systems with mature FHIR infrastructure, vital signs can be posted directly to the EHR's FHIR endpoint as Observation resources. Epic's FHIR R4 APIs support writing vital sign Observations, as does Oracle Health's FHIR implementation.

FHIR integration offers advantages in data richness (full Observation resource with provenance, method, and device metadata) and standards alignment but may require more sophisticated authentication (OAuth 2.0, SMART on FHIR) and may have different throughput characteristics than batch HL7v2 feeds.

Pattern 3: Direct EHR API Integration. Some EHRs offer proprietary APIs specifically designed for vital sign ingestion. Epic's Incoming Results interface and Oracle Health's CareAware platform are examples. These APIs may offer tighter integration with the EHR's native vital sign workflows (automatic flowsheet population, immediate availability in Storyboard) but are platform-specific.

Pattern 4: Middleware/Platform Integration. For health systems using telehealth platforms that already integrate with the EHR (for visit scheduling, documentation, etc.), vital sign data can flow through the existing platform integration. The rPPG SDK is embedded in the telehealth platform, and the platform handles downstream EHR communication through its existing integration channels.

The clinical informatics team should evaluate patterns based on existing integration infrastructure, implementation timeline, data latency requirements (vitals should be available in the EHR within seconds of capture, not hours), and maintenance burden.

Data Governance Framework

Camera-based vital sign data requires a governance framework that addresses consent, data quality, retention, access, and secondary use.

Consent. Patients must be informed that their device camera will be used to capture vital signs during the televisit. The consent model should address what data is captured (vital sign measurements derived from facial video analysis), how data is processed (on-device processing -- Circadify's approach processes facial video locally on the patient's device, with only numerical vital sign values transmitted), what data is stored (derived vital sign values in the EHR, not raw video), and how data is used (clinical care, documentation, quality improvement).

Most health systems can incorporate camera-based vitals consent into their existing telehealth consent framework rather than requiring a separate consent process. Legal and compliance teams should review the consent language to ensure it covers the camera-based measurement modality.

Data Quality Validation. Not every vital sign measurement will meet quality standards. Environmental factors (poor lighting, excessive patient movement, low camera quality) can affect measurement reliability. The rPPG system should provide a confidence score or quality indicator for each measurement. The clinical informatics team should establish policies for how measurements are handled based on quality indicators.

A recommended approach is to define three quality tiers. High confidence measurements are stored as standard vital signs and displayed without qualification. Medium confidence measurements are stored with a quality flag and displayed with an indicator that alerts the provider to interpret with appropriate context. Low confidence measurements are not stored in the clinical record, and the encounter is flagged as "vitals not captured" to maintain documentation accuracy.

Retention. Vital sign data captured via rPPG should follow the same retention policies as other vital sign data in the EHR. There is no special retention requirement for camera-derived versus device-derived vital signs. The raw facial video used for on-device analysis is not retained -- it is processed in real-time on the patient's device and discarded. Only the derived numerical values persist.

Access Controls. Vital sign data from televisits should be governed by the same role-based access controls as other clinical data. No additional access restrictions are typically needed unless organizational policy distinguishes between vital sign data sources.

Secondary Use. Televisit vital sign data is valuable for quality improvement, population health analytics, and clinical research. Secondary use policies should explicitly include camera-based vitals within the scope of existing data use agreements, IRB protocols, and analytics governance. The measurement method metadata (indicating camera-based derivation) should be preserved in secondary use datasets to support appropriate analysis.

Clinical Decision Support Rules

Camera-based vital signs enable CDS rules that were previously impossible for virtual visits because the input data did not exist.

Abnormal Value Alerts. Configure alerts for vital sign values outside normal ranges. Recommended starting thresholds (to be refined by clinical leadership) include heart rate below 50 or above 120 bpm, SpO2 below 92%, and HRV metrics below established population norms for age and sex. These alerts should integrate with existing CDS frameworks (Epic BPA, Oracle Health discern rules) and follow organizational alert governance policies. Start with conservative (less frequent) alerting and adjust based on clinical feedback to avoid alert fatigue.

Trend-Based Alerts. For patients with longitudinal virtual visit data, configure alerts for significant changes from baseline. A heart rate increase of 20 bpm from a patient's established baseline, or a drop in SpO2 of 4 or more percentage points from prior readings, may warrant clinical attention even if the absolute values are within normal range.

Risk Stratification Rules. Combine televisit vital sign data with other clinical data elements to support risk stratification. For example, a patient with heart failure, elevated heart rate trend across the last three virtual visits, and declining HRV may warrant intensified follow-up or medication adjustment.

Medication Management CDS. For patients on medications that affect heart rate (beta-blockers, calcium channel blockers, antiarrhythmics), camera-based heart rate during virtual visits provides objective data for medication management CDS rules. Alerts for excessive bradycardia or inadequate rate control can trigger medication review recommendations.

Reporting and Analytics Dashboards

Clinical informatics teams should build reporting capabilities that support operational monitoring, clinical quality measurement, and population health insights.

Operational Dashboard. Track the technical performance of vital sign capture across the virtual care program. Key operational metrics include capture success rate (percentage of virtual visits where vitals were successfully obtained), capture failure reasons (categorized by lighting, camera quality, patient movement, technical error), average measurement duration, and system availability and latency.

Clinical Quality Dashboard. Track the clinical impact of vital sign capture. Metrics include vital sign documentation rate for virtual visits (before and after implementation), percentage of virtual visits with complete vital sign documentation, abnormal value detection rate, alert-to-action conversion rate (how often abnormal value alerts lead to clinical action), and impact on follow-up scheduling patterns.

Population Health Analytics. Aggregate televisit vital sign data enables population-level insights that were previously unavailable. Analytics capabilities to develop include population-level vital sign distributions across virtual care patient panels, identification of patients with deteriorating vital sign trends across multiple virtual visits, correlation analysis between televisit vital sign patterns and clinical outcomes, and cohort comparisons (e.g., vital sign profiles of patients who required hospitalization versus those who did not).

These dashboards should be built using the health system's existing analytics infrastructure (Epic Caboodle/Cogito, Oracle Health HealtheAnalytics, or enterprise data warehouse platforms). Televisit vital sign data stored in standard EHR flowsheet fields is accessible through standard reporting pathways without requiring custom data extraction.

Interoperability With Existing RPM Platforms

Many health systems operate RPM programs alongside their virtual care programs. Camera-based televisit vitals and RPM device data should be managed as complementary data sources, not competing ones.

Data Harmonization. When a patient enrolled in an RPM program also has virtual visits with camera-based vitals, the EHR should present a unified vital sign view that includes data from both sources. This requires consistent LOINC coding across RPM devices and camera-based measurements, clear source labeling in the vital sign display (device type, measurement modality), and unified trending that includes data from all sources with appropriate visual differentiation.

Clinical Workflow Alignment. Providers reviewing a patient with both RPM data and televisit vitals should see a coherent clinical picture. Clinical informatics teams should design the provider view to show the most recent vital signs regardless of source, trend data from all sources on a single timeline, and source-specific filtering when the provider needs to isolate data from a specific measurement modality.

Data Quality Validation Framework

Maintaining data quality for camera-based vital signs requires ongoing validation.

Automated Quality Checks. Implement automated validation rules that flag physiologically implausible values (heart rate of 0 or 300, SpO2 of 50%), values that are statistically outliers relative to the patient's historical data, measurements with low confidence scores from the rPPG system, and duplicate measurements from the same encounter timestamp.

Periodic Clinical Validation. Establish a periodic review process where clinical informatics and clinical leadership review a sample of camera-based vital sign measurements against available clinical context. This is not a comparison to a reference device (which is not present during virtual visits) but a clinical plausibility review that assesses whether the captured values are consistent with the clinical picture.

Algorithm Performance Monitoring. Track aggregate accuracy metrics over time, including distribution of vital sign values across the patient population (should approximate expected population distributions), comparison of camera-based vitals to in-person vitals for patients who have both within a close time window, and monitoring for systematic bias across demographic subgroups (age, skin tone, sex).

Feedback Loop. Establish a process for providers to flag vital sign readings they believe are inaccurate. This feedback, while anecdotal, provides valuable signal for identifying measurement quality issues and driving algorithm improvement. Categorize provider feedback by issue type (implausible value, inconsistent with clinical presentation, discrepant from device measurement) and share aggregated feedback with the technology vendor.

Implementation Roadmap for Clinical Informatics

A structured implementation approach for clinical informatics teams includes the following phases.

Phase 1 (Weeks 1-4): Standards and Architecture. Define LOINC coding and data standards for each vital sign parameter. Select the EHR integration pattern and design the message or API specification. Define the data governance framework (consent, quality tiers, retention, access). Configure EHR flowsheet rows or vital sign definitions for camera-based measurements.

Phase 2 (Weeks 5-8): Integration Build and Test. Build the integration interface (HL7v2, FHIR, or direct API). Configure EHR display of camera-based vitals (flowsheets, Storyboard, note templates). Implement quality validation rules. Conduct end-to-end testing with synthetic data and then with live test encounters.

Phase 3 (Weeks 9-12): Pilot and Validation. Deploy to pilot departments with clinical informatics support. Monitor data quality, integration reliability, and clinical workflow fit. Iterate on display, alerting, and documentation workflows based on pilot feedback. Validate data quality against clinical plausibility standards.

Phase 4 (Weeks 13+): Scale and Optimize. Expand to additional departments following the organizational rollout plan. Build reporting and analytics dashboards. Implement clinical decision support rules. Establish ongoing data quality monitoring and governance processes.

Clinical informatics teams that approach televisit vital signs with the same rigor they apply to any clinical data integration project -- clear standards, validated interfaces, defined governance, and continuous quality monitoring -- will deliver a capability that providers trust and patients benefit from.