System Requirements

Technology platform
Our technology platform features 256-bit AES-encrypted signaling and media stream 
Connections to web app and API through HTTPS only, using TSL 1.3 or 1.2 encryption for in- transit encryption, and TSL 1.0 encryption for older browsers that do not support TLS 1.3 or 1.2. 128-bit AES-encrypted full database encryption using BitLocker , PHI encrypted at rest using AES-256. 
Each session participant has his/her own individual session access code, which provides granular access and auditability 
No passwords stored on our system; we store salted one-way password hashes only.
Notifications sent from our system, such as invites, notifications, and reminders, never include any PHI.
For additional PCI compliance, no credit cards are stored on our system, nor does any credit card information pass through our system in unencrypted form; all credit card information is vaulted at our PCI-compliant merchant gateway 
Pan-Tilt-Zoom (PTZ)
Our system has a pan, zoom and focus capability with a smart-phone, tablet, or webcam. 
Pan-Tilt-Zoom (PTZ) cameras are cameras which are capable of being controlled remotely to pan (rotate) or tilt, or zoom in or out. This can be particularly useful in teledentistry applications, if the patient is unable to adjust the camera themselves, or if the clinician wants to examine the patient directly without making the patient stop and adjust the camera for them each time they need a different view. 

Zoom allows screen sharing on a computer, tablet, and mobile devices running Zoom, though options are limited on tablets and mobile devices. Chromebook participants can receive screenshares, but cannot annotate (i.e. draw) on them. 
The host does not need to make someone else a presenter in order to share screen, but only one person may share a screen at a time. 
Our system has a strong track record for high-reliability (99.9% uptime) and high-quality connectivity (minimum of 480p). 
Our system has both software and hardware components allowing for instrumented visits if needed with the ability to push over 41 devices. 
Our system is compatible with intra-oral cameras and other instruments. 
We accomplish through the use of API’s. Based on the data you want to have 
interface with the given EHR we can provide you with the API. 
Functional Capabilities and Features
Our system:

  1. Allows for both patient-initiated encounters, as well as, clinic and/or hospital-initiated encounters. A request consultation button can be created by which a patient can request a session. 
  2. Allows for both patient facing and provider facing schedulers and appointment creation. Both on demand queued and scheduled. 
  3. Is robust enough to allow Up to 99 participants can be scheduled and engaged in a single session at a time.
  4. Has a recording feature in which the recordings can be stored in the providers cloud or stored on a providers local device. Allowing the recordings to be accessed on demand as deemed necessary 
  5. Has an built-in e-document feature which offers a highly customizable electronic intake system. 
  6. Capable of handling a wide variety of use cases. These can be explored in much greater detail on our website. 
  7. Has use cases range from Individual providers, hospitals, Urgent Care, Nursing facilities, behavioral health facilities, emergency rooms and first responder integrations. 
  8. Provides HIPAA compliant virtual visits to monitor stable chronic conditions for patients located in rural areas with limited access to healthcare. 
  9. Is fully HIPAA compliant and meets all HIPAA compliance protocols and is backed with our Business Associates Agreement (BAA). We can provide this capability to assist patients in rural areas and run on networks as low as 3G. 
  10. Has the capability of adding multiple participants to the same session, so a single patient can have a conversation with different providers all in different locations at the same time for a collaborative healthcare experience. 
    1. When multiple users are in a session, the camera switches to and displays to other participants the person who is speaking. This enables a smooth recording viewing experience so only one audio source (the speaker) is being played on audio. The recording itself will however display all participants in the video session. 
  11. Connects to primary care provider at hospital discharge for smooth transition of care experience for all patients.
  12. Is unbiased and will operate and any and all operating systems, browsers and equipment. All that is required is for the patient and provider to have a device with a camera and microphone. The system can run on as little as a 3g cellular signal. Support for patients and providers for help, if needed, to connect is offered free of charge and is available 24/7/365 from our US based support centers. 
  13. Since we are cloud based, all of our upgrades patches and maintenance are done at the cloud level so no inconvenience to UMC. If there is a patch or upgrade that will require the system to be down for a short period of time, we will alert UMC of this scheduled maintenance and is usually done during low utility time frames. 

Data Center
We have a dedicated data center cage with biometric security, with no reliance on third parties for any routine network maintenance or management. One of our nodes is located here in Las Vegas with tours available on an as needed basis.The system is a cloud based platform. 
Disaster Recovery Process
Our Disaster Recovery Process is designed to recover from a long-term, catastrophic outage at the our Data Center at The Disaster Recovery Process includes real-time and near-real-time offsite data replication of all data elements to a warm standby environment at an Amazon Web Services (AWS) Data Center, which is 500+ miles from our Data Center, is kept at proper scale and can be used for an indefinite period of time. With the design goal to use a completely parallel infrastructure, scenarios from which we can quickly and successfully recover include systems outage, denial of service attack, compromised network, or equipment downtime at our primary data center. Our Recovery Time Objective (RTO) is 10 minutes. The Recovery Point Objective (RPO) is 1 minute. 
Fully Redundant Video Network with Automatic Failover Our platform uses the Zoom and Vsee video engine for videoconferencing. Non-recordable sessions are routed with end-to-end encryption through the Zoom Cloud, and recordable sessions are routed with end-to-end encryption through our Cloud. Both the Zoom Cloud and Our Cloud contain n+1 MCU configurations with automatic failover between geographic zones. When connecting to a session, the Zoom client of the session host sends connection requests to every known MCU; the first MCU to respond handles the session. In the event that an MCU fails, the Zoom clients will automatically seek the next closest MCU (in terms of response). 
Disaster Recovery Setup – Data Elements Three data elements are replicated from the Primary Data Center to the Secondary AWS Instance in real time or near real time. 
1) Transactional database containing encrypted clinical, user, session, and customer information: replicated every 60 seconds; 2) Usage database containing historical usage information: replicated in real-time; and, 3) Encrypted file system objects containing all other data: replicated every 60 seconds via encrypted file system object copy. By replicating all data elements in real-time or near-real-time, we are able to conform to a Recovery Point Objective (RPO) of only 1 minute, targeting extremely minimal data loss, even in the most catastrophic disaster scenario. 
Data Replication Monitoring Every 5 minutes, a web monitor checks the data replication process of these three data elements to ensure consistency with the primary data sources. In the event that any of the elements are not consistent with the primary data sources, the engineering and operations teams receive alerts via e-mail and text message. Those alerts are not closed until the problem is resolved through the evidence of the reestablishment of data consistency between the primary and secondary. 
Disaster Response – Cutover from Primary to Secondary Transition from Primary to Secondary (“Cutover”) is a manual process, to be undertaken only at the direction of certain authorized staff. The objective for completion of this cutover is 10 minutes, which includes time for disaster notification, evaluation, decision making, and technical execution. In the event of a disaster, cutover from Primary to Secondary has three steps, which can be expected to complete quickly and reliably, as they have been scripted and are tested monthly: 
1) Technologic Diagnosis. We maintain a diagnostic checklist that our Operations staff can use to quickly determine whether a cutover should be undertaken. This checklist is expected to address over 90% of the likely root causes requiring a cutover, including networking or power failure in our data center outside of our network edge, various types of hardware failure in our server racks at or behind our network edge, virtualization server software failure, server host OS failure, web or application server software failure, intra-LAN networking issues, excessive unhandled exception rate, data corruption, intrusion, DDoS, and many others. Engineering is notified at the moment Operations begins working the diagnostic checklist. If diagnosis cannot be quickly made by the Operations team using the diagnostic checklist, then the Engineering team will make the final decision, and will have already started its own diagnostic process. 
2) Secondary Data Activation. The transactional database, usage database, and encrypted file system objects are replicated locally from read-only replica sets to live instances, a process which takes less than two minutes. Note that because the replication to the live instance is manually triggered, even if the Data Center instance came back online during the cutover process, it would not be possible to conflate any Data Center data modifications with those from the AWS infrastructure. 
3) DNS cutover. Because we use Cloudflare’s reverse proxy for all web transactions, our DNS cutover occurs globally within moments. Our secondary infrastructure will observe the DNS change within one minute, and at that time mark itself as the new primary. At this point, the cutover is complete and all web traffic is served from the AWS infrastructure. 
Disaster Response Recovery – Cutback from Secondary to Primary Once the issue—whatever caused the cutover in the first place—is completely resolved, we will announce a 2 hour maintenance window to re-establish the Data Center as the Primary and AWS as the Secondary, scheduled when a low number of users are expected on to be on the system. During the scheduled maintenance, the following steps will be taken: A) DNS redirect. We point our DNS to a “catchall” server, which will show that our website is temporarily down. Within 60 seconds, our primary and secondary will both stop accepting web requests, and our background tasks will stop executing on both infrastructures. B) Data replication. The transactional, usage, and filesystem data are replicated back to the Primary. The databases are appropriately set to their original replication/replica set roles. This process takes approximately 20-30 minutes. C) DNS cutback. Our DNS records are set back to the original data center references. Within 60 seconds, the Data Center infrastructure will query DNS, observe that it is now the primary, and will take over data consumption. The primary infrastructure at our Data Center will begin accepting web requests, and background tasks will run on that.