WO2021231377A1

WO2021231377A1 - Systems and methods for implementing occupational health testing protocol

Info

Publication number: WO2021231377A1
Application number: PCT/US2021/031708
Authority: WO
Inventors: Sanjay Basu; Rajaie BATNIJI; Le CHANG
Original assignee: CollectiveHealth, Inc.
Priority date: 2020-05-12
Filing date: 2021-05-11
Publication date: 2021-11-18

Abstract

Techniques for implementing occupational health testing protocols of a workplace are described. A worker can interact with a service provider from their computing device via a user interface that enables the worker to register and provide symptom information associated with a health condition. The service provider can receive worker data associated with the worker and process the worker data to determine a level of risk for the worker. Based partly on the level of risk and symptom data, a testing frequency for the worker can be determined. The testing frequency can be used to determine a status of the worker and a status indicator indicative of the status of the worker can be presented via the user interface. The status indicator can control access to one or more occupational operations.

Description

SYSTEMS AND METHODS FOR IMPLEMENTING OCCUPATIONAL HEALTH TESTING PROTOCOL

PRIORITY

[0001] This application claims priority to U.S. Provisional Application No. 63/023,248, filed on May 12, 2020, and U.S. Provisional Application No. 63/052,424, filed on July 15, 2020, the entire contents of both of which are incorporated by reference herein.

BACKGROUND

[0002] Implementing health safety protocols in a workplace enables workers to continue to work without disruptions caused by illness, for example that can result from contact in or at the workplace. Traditionally, workers report when they are ill and refrain from entering the workplace for work. Workers self-monitor at home and return when they feel healthy. Traditionally, instances of sickness-related absences are reported and tracked on a one-by-one basis, without much follow-up or monitoring by workplaces. More recently, however, with an increasing number of severe health risks in the community at-large — due in part to highly contagious diseases (e.g., the novel coronavirus (“COVID-19”)) — workplaces are facing delays and hardships in their operations. Workplaces are struggling to meet their duty to guard their workers’ personal privacy, maintain account of health events at an organization-wide level, comply with government and community safety mandates, all while trying to meet the demands of conducting their day-to-day businesses. Current techniques for maintaining safe workplaces are inadequate.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The detailed description is set forth with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items or features.

[0004] FIG. 1 A illustrates an example environment for performing techniques described herein.

[0005] FIG. IB illustrates an example of a portion of a datastore associated with the example environment of FIG. lA.

[0006] FIG. 2 illustrates an example user interface configured to facilitate registration with a workplace safety product, as described herein.

[0007] FIG. 3 illustrates another example of the user interface configured to obtain registration data from a worker, as described herein.

[0008] FIG. 4 illustrates another example of the user interface configured to obtain symptom data from a worker, as described herein.

[0009] FIG. 5 illustrates another example of the user interface configured to facilitate test scheduling for a worker, as described herein.

[0010] FIG. 6 illustrates another example of the user interface configured to communicate to a worker that testing results are pending, as described herein. [0011] FIG. 7 illustrates another example of the user interface configured to communicate to a worker that a positive testing result has been received, as described herein.

[0012] FIG. 8 illustrates another example of the user interface configured to communicate to a worker that a negative testing result has been received and to enable the worker to access workplace operations, as described herein.

[0013] FIG. 9 illustrates another example of the user interface configured to facilitate additional test scheduling for a worker, as described herein.

[0014] FIG. 10 illustrates another example of the user interface configured to communicate a status of a worker to the worker, as described herein.

[0015] FIG. 11 illustrates an example process for determining a level of risk associated with a worker, as described herein.

[0016] FIG. 12 illustrates an example process for receiving at least one of registration data and/or symptom data associated with a worker, as described herein.

[0017] FIG. 13 illustrates an example process for determining an optimal testing frequency for a worker, as described herein.

[0018] FIG. 14 illustrates an example process for utilizing testing for certification, as described herein.

[0019] FIG. 15 illustrates an example process for maintaining certification (e.g., maintaining an “active” status associated with a “certificate”) of a worker, as described herein.

[0020] FIG. 16 illustrates an example process for implementing occupational health testing protocol, as described herein.

[0021] FIG. 17 illustrates an example process for controlling access to an operation based at least in part on compliance with the occupational health testing protocol, as described herein.

[0022] FIG. 18 illustrates an example of various surfaces associated with a workplace safety product, as described herein.

DETAILED DESCRIPTION

[0023] Techniques for implementing occupational health testing protocol are described herein. That is, techniques described herein relate to a workplace safety product, and related systems and/or processes, that are configured to help workplaces implement a workplace safety program to reduce occupational health risks associated with health conditions, including but not limited to novel coronavirus (“COVID-19”). In an example, a service provider, which can be an administrator of services, can provide softw are hardw are, and/or other computing devices to enable and/or implement the workplace safety product. In such an example, workplaces (e.g., companies, employers, or other organizations) that purchase or otherwise use services of the service provider can utilize the workplace safety product described herein to determine customized and/or personalized testing frequencies for workers. In at least one example, such customized and/or personalized testing frequencies can be determined based on worker function (e.g., role(s) or assignment(s) associated with workers), risk stratification of workers (e.g., based at least in part on occupational health research and protocols), and/or data associated with workers (e.g., personal data, symptom data, etc.). Compliance with testing requirements (e.g., at determined testing frequencies) can be used for controlling access to workplace operations, as described herein. That is, techniques described herein relate to (i) determining conditions for accessing workplace operations (e g., which can include certifications) and/or (ii) enforcing such conditions to control access to such workplace operations. In at least one example, the workplace safety product can be useful for, among other things, limiting the risk of exposure (e.g., of a particular health concern such as COVID- 19) among workers and customers and/or otherwise maintaining safe workplaces.

[0024] That is, in at least one example, the workplace safety product described herein can facilitate (i) ingestion of a list of workforce members (“workers,” or individuals who are asked by their workplace to get tested and certified in order to go to work, perform duties, and/or otherwise perform operations per a contract with their workplace) from workplaces that contract with a service provider (e.g., employers, companies, or other organizations that employ or are otherwise associated with workers whom they want to be tested); (ii) processing and classifying of worker function (e.g., what role or assignment are individual workers associated with); (iii) risk stratification of workers in accordance with occupational health research and protocols; (iv) reporting of population metrics and status of workers, along with positive testing results (if requested by a workplace); and/or (v) worker vaccination and reporting of vaccination metrics to workplaces In some examples, the workplace safety product can be associated with an application (i.e., “app”) that (i) registers workers, (ii) collects personal information and consents, (iii) prompts workers to enter symptom information, (iv) navigates workers to sample collection for testing and/or upload of testing results, and/or (v) based on testing results, provides a status or “pass” to indicate completion of the testing program or that quarantine or furtirer testing is needed.

[0025] In at least one example, a service provider can offer such workplace safety product, and related systems and/or processes, to enable employers to deploy testing for certain health conditions (e.g., COVID-19, etc.), collect testing results, and disseminate testing results to patients, employers, and the government (all with consent of the individual and/or patient) in the form of certification of non-infection and/or immunity. The workplace safety product, and related systems and/or processes, can be helpful in enabling employers to safely have their employees return to work in scenarios where large-scale testing is not available or required by other entities (e.g., local, state, or federal governments).

[0026] As described above, traditionally, workers report when they are ill and refrain from entering the workplace for work. Workers self-monitor at home and return when they are feeling healthy . Traditionally, instances of sickness- related absences are reported and tracked on a one-by-one basis, without much in the form of follow-up or monitoring by workplaces. More recently, however, with an increasing number of severe health risks in the community at-large — due in part to highly contagious diseases (e.g., COVID-19) — one-by-one tracking and/or reliance on selfreporting/monitoring is inadequate. Further, due to the sensitive nature of health-related data and/or the frequency at which testing and/or other symptom reporting is required to maintain safe and healthy workplaces, conventional techniques are inadequate.

[0027] Techniques described herein offer improvements to conventional techniques. That is, techniques described herein offer techniques to reduce occupational health risks to limit exposure among workers and/or customers and/or to otherwise maintain safe workplaces. As described above, a sendee provider can provide a workplace safety product. The workplace safety product can be executed across multiple computing devices associated with the service provider (e.g., service provider computing device(s)) and one or more users (e.g., computing device(s) of workplace(s) and/or worker(s)).

[0028] In at least one example, the service provider can be associated with service provider computing device(s) that receive data from disparate sources, including but not limited to, workplace computing devices, worker computing devices, testing facility computing devices, healthcare computing devices, and/or the like. In some examples, such data can be received via applications provided by the service provider. In some examples, such data can be received via one or more application programming interfaces (API(s)) or other computing components that enable integration between the service provider and one or more other entities. In at least one example, the service provider computing device(s) can utilize received data to classify workers, such as by role or assignment. In at least one example, the service provider computing device(s) can utilize received data to determine risk levels associated with workers, which can be based at least in part on occupational health research and protocols. In at least one example, worker classifications and/or risk levels can be used to determine testing frequencies for individual workers and/or groups of workers. Such testing frequencies can be used to determine when such workers are required to obtain and/or provide testing results. Compliance with such testing frequencies can be used to determine statuses of individual workers, which can be used by the service provider to control access to workplace operations.

[0029] In at least one example, a worker can utilize a user computing device that can have an application associated with the workplace safety product installed thereon. The application can specially configure the user computing device to communicate with service provider computing device(s) to facilitate techniques as described herein. In at least one example, the application can enable a worker to input data via a user interface, such as registration data, symptom data, and/or the like. Further, the application can facilitate test scheduling and access to previous testing results. Further, in some examples, the application can present notifications and/or reminders associated with scheduling additional testing appointments at a frequency personalized and/or customized for the worker. That is, the workplace safety product can navigate workers to testing facilitates (which can provide testing results back to the service provider) and/or can enable workers to upload or otherwise provide testing results procured via other testing facilities, at frequencies personalized and/or customized for individual workers, to ensure compliance with workplace requirements as they relate to health and/or safety.

[0030] In at least one example, workers can be associated with statuses, which can be used for determining certifications. In at least one example, a status associated with the worker can be used to determine whether the worker is permitted to perform operations of a workplace. In at least one example, a worker with an active status can have access to a code (e.g., a passcode, a barcode, a Quick Response (QR) code, etc ), badge, or the like that can be used for granting access to operations of a workplace. That is, a worker with an active status can be “certified” or have a “pass” to access operations of a workplace. In some examples, the application can present the code, badge, etc. The code, badge, etc. can indicate that the worker is associated with an active status and/or that the worker otherwise complies with workplace requirements associated with health and/or safety (e.g., the worker has completed testing requirements, the worker is free of concerning symptoms, etc.). In some examples, the code, badge, etc. can represent a certification or pass, such that certified workers and/or workers with passes are granted permission to perform workplace operations that other workers who are not certified and/or do not have such passes are not, at least temporarily.

[0031] In at least one example, workplaces can utilize instances of an application associated with the workplace safety product to track worker compliance with health and/or safety requirements. In some examples, workplaces can obtain reporting of population metrics associated with their individual workplaces. For instance, a workplace can query records of the service provider to determine the number of active workers, inactive workers, workers who have tested positive, workers who have tested negative, workers experiencing particular symptoms, etc. at a particular time. In some examples, results of such queries can be returned such that individual workers are not identified. In some examples, a workplace can request additional information associated with individual workers which, so long as such workers have consented to sharing such information, the service provider can share. In some examples, workers can provide proof of other health-related events, such as vaccinations. In such examples, workplaces can similarly utilize instances of the application associated with the workplace safety product to track worker vaccination and/or obtain reports associated with vaccination metrics.

[0032] The workplace safety product can utilize risk stratification, symptom evaluation, established testing frequency, etc. to implement protocol to limit the risk of exposure among workers and/or customers and/or to ensure healthy workplaces. The distributed system associated with the workplace safety product can enable workplaces to have more oversight as it pertains to the health of individual workers. That is, instead of relying on self-reporting and selfmonitoring, the workplace safety product enables workplaces to know whether workers are infected and to implement protocol to ensure that infected workers are safe to return to the workplace. Such oversight can be done using the workplace safety product, and in a way that preserves the sensitive nature of the data that is obtained to make health- related decisions in the workplace. By making access to workplace operations conditional on compliance with testing frequency and/or other protocol, techniques described herein can enable workplaces to limit the risk of exposure among workers and/or customers and/or to ensure healthy workplaces.

[0033] While reference is made herein to “testing” and protocol related to COVID-19, techniques can be similarly applicable to any health and/or safety protocol that affects workplaces. For example, the workplace safety product can be used to enforce a workplace policy as it relates to drug use and workplace operations can be conditional based on compliance with a drug testing protocol. Or, as another example, the workplace safety product can be used to enforce a workplace policy as it relates to more common contagious illnesses, such as strep throat. That is, while reference is made herein to COVID-19 testing and protocol, techniques described herein can be applicable in any workplace setting that requires oversight to ensure health and/or safety. Furthermore, while techniques described herein are related to COVID-19 and a product for enabling employees to return to work, techniques described herein can be similarly applicable for any health care condition and/or related protocol and controlling whether individuals are able to enter a public or private space, perform an activity, perform an operation, or the like. For example, techniques described herein can be utilized for, among other things, vaccinations in schools, hospitals, travel, etc. Techniques described herein can further be utilized for, among other things, certifying that individuals are healthy and/or otherwise disease free for travel, public transportation, dating applications, etc. [0034] FIG. 1A depicts an example environment 100 for performing techniques described herein. In at least one example, the example environment 100 can include one or more service provider computing device(s) 102, which can be associated with a service provider providing the product and/or other occupational health testing protocols, as described herein. The service provider computing device(s) 102 can include one or more servers or other types of computing devices that can be embodied in any number of ways. In an example of a server, the functional components and data can be implemented on a single server, a cluster of servers, a server farm or data center, a cloud-hosted computing service, a cloud-hosted storage service, and so forth, although other computer architectures can additionally or alternatively be used.

[0035] In at least one example, the service provider computing device(s) 102 can communicate with a user computing device 104 via one or more network(s) 106. That is, the service provider computing device(s) 102 and the user computing device 104 can transmit, receive, and/or store data (e.g., registration data, symptom data, indicator(s) for access control, and/or the like) using the network(s) 106, as described herein. The user computing device 104 can be any suitable type of computing device, e.g., portable, semi-portable, semi-stationary, or stationary. Some examples of the user computing device 104 can include a tablet computing device, a smart phone, a mobile communication device, a laptop, a notebook, a desktop computing device, a terminal computing device, a wearable computing device, an augmented reality device, an Internet of Things (IOT) device, or any other computing device capable of sending communications and performing the functions according to the techniques described herein. While a single user computing device 104 is shown, in practice, the example environment 100 can include multiple (e.g., tens of, hundreds of, thousands of, millions of) user computing devices. In at least one example, user computing devices, such as the user computing device 104, can be operable by users to, among other things, utilize a workplace safety product as described herein. In some examples, a user can be a “worker,” which can be associated with a workplace. A worker can be an employee, an independent contractor, an agent, a volunteer, or the like that performs operations for or on behalf of a workplace.

[0036] The network(s) 106 can include, but are not limited to, any type of network known in the art, such as a local area network or a wide area network, the Internet, a wireless network, a cellular network, a local wireless network, Wi-Fi and/or close-range wireless communications, Bluetooth®, Bluetooth Low Energy (BLE), Near Field Communication (NFC), a wired network, or any other such network, or any combination thereof. Components used for such communications can depend at least in part upon the type of network, the environment selected, or both. Protocols for communicating over such network(s) 106 are well known and are not discussed herein in detail.

[0037] In at least one example, the service provider computing device(s) 102 can include one or more processors 108, computer-readable media 110, one or more communication interfaces 112, and input/output devices 114. In at least one example, each processor of the processor(s) 108 can be a single processing unit or multiple processing units, and can include single or multiple computing units or multiple processing cores. The processor(s) 108 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units (CPUs), graphics processing units (GPUs), state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. For example, the processor(s) 108 can be one or more hardware processors and/or logic circuits of any suitable type specifically programmed or configured to execute the algorithms and processes described herein. The processor(s) 108 can be configured to fetch and execute computer-readable instructions stored in the computer-readable media, which can program the processor(s) to perform the functions and techniques described herein. The computer-readable media 110 can include volatile, nonvolatile, removable, and/or nonremovable memory or other media implemented in any type of technology for storage of data, such as computer- readable instructions, data structures, program modules, or other data. Such computer-readable media 110 can include, but is not limited to, RAM, ROM, EEPROM, flash memory' or other memory technology, optical storage, solid state storage, magnetic tape, magnetic disk storage, RAID storage systems, storage arrays, network attached storage, storage area networks, cloud storage, or any other medium that can be used to store the desired data and that can be accessed by a computing device. Depending on the configuration of the server(s) 102, the computer-readable media 110 can be a type of computer-readable storage media and/or can be a tangible non-transitory media to the extent that when mentioned, non-transitory computer-readable media exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.

[0038] The computer-readable media 110 can be used to store any number of functional components that are executable by the processor(s) 108. In many implementations, these functional components comprise instructions or programs that are executable by the processor(s) 108 and that, when executed, specifically configure the processor(s) 108 to perform the actions attributed above to the service provider. Functional components stored in the computer- readable media can optionally include a certification component 115 that can identify and present testing facility options and/or instructions, request tests and/or testing kits for users (and facilitate the provisioning thereof), receive testing results, determine, based on the protocol referenced herein, a testing frequency for users, manage and/or maintain certificates, generate report(s) based on real-time and/or historical data associated with entities and/or users, recommend supplemental service(s), etc. In at least one example, the certification component 115 can include one or more functional components such as a risk determination component 116 (e.g., for determining and/or performing risk stratification of workers or other users in accordance with occupational health research and protocols, as described below), a status determination component 118 (e.g., for determining, based at least in part on testing results, a status to indicate completion of the testing program or that quarantine or further testing is needed, as described below), and an access control component 120 (e.g., for controlling access to workplace operations based on statuses, as described below). While some of the functional components are shown as being associated with the certification component 115, in some examples, each of the functional components can be standalone components. In some examples, the functional components can include additional or alternative components, such as a reporting component 122 (e.g., for determining and/or reporting of population metrics and status of workers or other users, along with positive testing results (if requested by a workplace) and/or reporting of vaccination metrics to workplaces), a payment component (e.g., for processing payment for services rendered herein), and/or one or more other functional components, and/or the like. In some examples, the functional components can additionally include a datastore 124 and an operating system 126.

[0039] In at least one example, the risk determination component 116 can receive data and utilize such data for outputting levels of risk associated with individual workers. In at least one example, the risk determination component 116 can receive workplace data associated with a workplace and/or worker data associated with workers of a workplace and can store the data in the datastore 124. Workplace data can include, but is not limited to, a name, address (including zip code), phone number, email address, and/or the like of the workplace, an expected number of workers to be tested, whether workers are remote, a type of workplace, etc. In some examples, workplace data can indicate whether workers come in close contact with the public in their work, office configurations, HV AC/ventilation systems, working conditions, etc. In some examples, workplace data can include worker data.

[0040] Worker data can include, but is not limited to, names of workers, personal information of workers (e.g., addresses (including zip codes), phone numbers, birthdates, email addresses, etc.), worker identifiers of workers, roles of workers, assignments of workers, type(s) of work done by workers, permissions of workers (e.g., which operations workers are permissioned to perform), schedules of workers, payroll of workers, benefits of workers, dates of workers (e.g., start dates, end dates, etc.), and/or the like. As a non-limiting example, worker data can include a zip code associated with a worker, whether the worker is a healthcare worker, and/or whether the worker is working remotely or has been working from a location associated with the workplace.

[0041] In some examples, such workplace data and/or worker data can be received from a computing device of a workplace (e.g., which can be a third-party computing device of the third-party computing device(s) 127). In some examples, the workplace data and/or worker data can be received in a data file or other object that is associated with data for each worker of the workplace. In some examples, the risk determination component 116 can receive the worker data in a first format and can convert the worker data into a second format, which can be standardized for the service provider.

[0042] In some examples, the risk determination component 116 can determine classes of individual of the workers. In some examples, such classes can be based at least in part on roles and/or assignments received via the worker data. In some examples, such classes can be based at least in part on additional or alternative workplace data, worker data, or other data associated with the worker. In some examples, the risk determination component 116 can use a classifier (e.g., perceptron, Naive Bayes, decision tree, logistic regression, k-nearest neighbor, artificial neural networks/deep learning, support vector machine, random forest, bagging, Adaboost, etc.) and/or a classification model (e.g., a model trained using a classifier) to classify individual of the workers. A classification model can be trained by a classifier on training data to understand how input characteristics (e.g., worker geolocation, birthdate, roles, assignments, permissions, schedules, payroll, benefits, etc.) relate to individual classes. In some examples, a class can represent a group of workers that are associated with a same or similar set of characteristics. For example, users associated with a first role, first age range, and/or first schedule can be associated with a first class and users associated with a second role, a second age range, and/or second schedule can be associated with a second class. In some examples, such classes can be used to determine risk levels associated with individual workers and/or groups of workers.

[0043] In some examples, the risk determination component 116 can analyze workplace data, worker data, and/or the like to determine levels of risk associated with individual of the workers. In some examples, additional or alternative data can be used for determining levels of risk (e.g., registration data, symptom data, determined classes, etc.). Furthermore, in some examples, epidemiological considerations can be utilized to determine levels of risks for particular health-related events. Such considerations include transmission rates, routes of transmission (e.g., of a disease), forms (e.g., droplet, aerosol and/or formite) of transmission, viral shedding and symptoms, incubation period, basic reproduction number (e.g., measure of transmissibility), case fatality rate, reinfection and immunity, etc. In some examples, such data can be obtained from third-party- sources, such as the U.S. Department of Health or the like. In some examples, such data can include new case counts and/or otherwise indicate current rates of transmission. In some examples, epidemiological considerations can be based on geographic area(s) associated with worker(s) (e.g., based on zip code or other indicators) such that levels of risk can be based at least in part on changes in local areas. [0044] In at least one example, classes, as determined as described above, can be used by the risk determination component 116 to determine levels of risk associated with individual of the workers. In some examples, the risk determination component 116 can analyze workplace data, worker data, classes, and/or any other data as described above using one or more rules to determine levels of risk associated with individual of the workers. In some examples, the risk determination component 116 can analyze workplace data, worker data, classes, and/or any other data as described above using an algorithm and/or machine-trained model (e.g., a model trained using a machine-learning mechanism) to determine levels of risk associated with individual of the workers.

[0045] In at least one example, a machine-trained model can be trained based at least in part on training data, which can include workplace data, worker data, classes, health history data, epidemiological considerations, and/or levels of risk associated with individual workers. In at least one example, such training can be supervised (e.g., using nearest neighbor, Naive Bayes, regression (linear or logistic), decision trees, random forests, support vector machines, neural networks, etc.), unsupervised (e.g., using Apriori, k-means, etc.), semi-supervised, reinforcement, and/or the like. In some examples, deep learning mechanisms can be used for training model(s). In at least one example, the machine- trained model can be trained to output a score or other indicator indicative of a level of risk associated with individual workers (e.g., based at least in part on received worker data and/or classes). As such, in some examples, the risk determination component 116 can output a score or other indicator indicative of a level of risk associated with individual workers. In some examples, levels of risk can be associated with a score or metric (e.g., 100 indicating high risk, 0 indicating low risk), a range of scores or metrics (e.g., 100-75 indicating high risk, 74-120 indicating medium risk, 120-0 indicating low risk), or the like.

[0046] In some examples, workers can be associated with one or more levels of risk, which can be tied to different roles/assignments, workplaces, geographical locations, etc.

[0047] In at least one example, the status determination component 118 can receive registration data associated with workers. For example, a worker can register to use the workplace safety product by providing registration data. Registration data can include, but is not limited to, personal information (e.g., name, address (e.g., including zip code), phone number, birthdate, email, etc.) and/or account information (e.g., a user identifier, password, etc.). In at least one example, a worker can be associated with a workplace-defined code or other identifier provided by their workplace to associate their account with the workplace (e.g., so the service provider knows to map the worker account of the worker with the correct workplace). In at least one example, the registration data can be provided at registration or onboarding, which can correspond to creation of a worker account. Worker account data can be stored in a worker profile associated with the datastore 124. Worker account data can be updated overtime.

[0048] In some examples, workers can be prompted to input additional or alternative data that can be associated with “registration data.” Such data can correspond to health history data, travel data, and/or the like. In at least one example, the health history data can comprise health care data, which can be associated with health care records of the worker or provided based on worker input. In at least one example, health history- data can include indications of prior illnesses, prior surgeries, familial health history, and/or the like. In some examples, the health history data can include vaccine history. Further, in some examples, the health history data can include, but is not limited to, prior symptom data, prior testing appointments, prior testing results, etc. In at least one example, the health history data can be used to determine a vulnerability of the worker. For instance, if the worker (i) has a health condition (e.g., high blood pressure, diabetes, heart disease, lung disease, liver disease, kidney disease, is immunocompromised, is pregnant, has recently had a baby, etc.), (ii) takes public transportation to work and/or uses public transportation for regular activities, and/or (iii) lives in a congregate housing facility (e.g., nursing home, group home, dorm rooms, etc.), the worker may be considered to have an increased vulnerability. In at least one example, health history data can also include information associated with the worker’s immunity. For instance, immunity' can be determined based on whether the worker has previously had a confirmed infection and/or disease.

[0049] In at least one example, travel history data can indicate which prior travel destinations, travel dates, airline tickets previously purchased, rental cars previously purchased, train tickets previously purchased, event tickets previously purchased, previous reservations, etc. Additional or alternative data can be obtained for insight into health and/or exposure, which in some examples, can be received by an input by the w orker and/or from third-party sources, as described herein.

[0050] In some examples, registration data can be received by the status determination component 118 via input to a user interface displayed on the user computing device 104 of a worker. That is, as illustrated in FIGS. 2 and 3, an application (or web browser) on the user computing device 104 can display a user interface that includes user interface element(s) to guide the worker to input particular registration data. In some examples, the status determination component 118 can receive registration data via such an input mechanism. In some examples, the status determination component 118 can obtain registration data from one or more third-party sources, such as testing facilities, healthcare providers, travel service providers, social media service providers, etc. In such examples, a worker can provide credentials or other data to facilitate such. In at least one example, such registration data can be obtained via one or more API calls or other integrations (e.g., with the third-party computing device(s) 127).

[0051] In at least one example, the status determination component 118 can receive symptom data. In at least one example, such symptom data can indicate one or more symptoms, including, but not limited to a cough, a headache, body aches, digestive issues, loss of taste/smell, fatigue, confusion, upper respiratory symptoms, etc. In some examples, the status determination component 118 can receive symptom data via input to a user interface displayed by the user computing device 104 of a worker. For example, a prompt can be presented via a user interface. That is, as illustrated in FIG. 4, an application (or web browser) on the user computing device 104 can display a user interface that includes user interface element(s) to guide the worker to provide one or more indications of current and/or recent symptoms. In some examples, a worker can interact with the user interface to indicate which symptoms, if any, they are currently experiencing or have experienced within a designated period of time (e.g., the last 24 hours, the last seven days, etc.). In some examples, a worker can be prompted to provide a reading from a sensor on the user computing device 104. For example, the user computing device 104 can be associated with a thermometer, which can be initialized to obtain a temperature reading of a worker. As another example, the user computing device 104 can be associated with a blood oxygen sensor that can be initialized to obtain a blood oxygen saturation reading of a worker. Such readings (e.g., temperature, blood oxygen, etc.) can be used to determine symptoms of the worker (e.g., fever, shortness of breath/diffrculty breathing, etc.). In at least one example, symptom data can be requested at a particular frequency, which, in some examples, can be particular to individual workers.

[0052] In at least one example, the status determination component 118 can determine testing frequencies for the workers. For instance, the status determination component 118 can receive a level of risk associated with a worker, registration data associated with the worker, and/or symptom data associated with the worker and can determine a testing frequency for the worker. In some examples, such a testing frequency can be determined based at least in part one or more rules. In some examples, such a testing frequency can be determined based at least in part on an algorithm or a machine-trained model. In at least one example, the machine -trained model can be trained based at least in part on training data, which can include levels of risk, registration data, symptom data, and/or testing frequencies associated with individual workers. In at least one example, such training can be supervised (e.g., using nearest neighbor, Naive Bayes, regression (linear or logistic), decision trees, random forests, support vector machines, neural networks, etc.), unsupervised (e.g., using Apriori, k-means, etc.), semi-supervised, reinforcement, and/or the like. In some examples, deep learning mechanisms can be used for training model(s). In at least one example, the machine- trained model can be trained to output an indication of a frequency at which a particular worker should be tested (e.g., for a particular health condition). In at least one example, the status determination component 118 can output testing frequencies that are particular to individual workers — that is, such testing frequencies can be personalized and/or customized for individual workers.

[0053] As described above, the status determination component 118 can determine a testing frequency, which can be an “optimal testing frequency,” for a worker (e.g., recommendation(s) on how often to test a worker under different risk scenarios and type(s) of testing modalities (e.g., saliva, seralogic, PCR, etc.)). Air “optimal testing frequency” seeks to minimize false positives caused by too frequent of testing and works to ensure that effective reproductive number (e.g., the number of secondary cases caused by a primary case) is less than one to prevent an outbreak. In at least one example, the status determination component 118 can receive, as input, at least (i) the level of risk and the (ii) transmission rate data into a model, and can output the optimal testing frequency that (i) minimizes the number of false positives and (ii) preserves the effective reproductive number to be less than one. In at least one example, the optimal testing frequency can be customized for the worker and can be based at least in part on data associated with the worker (e.g., workplace data, worker data, registration data, third-party data, etc.). In other examples, the optimal testing frequency can be customized for a cohort of workers (e.g., work site, a group of similar workers, etc.), a general population, or the like. In at least one example, the optimal testing frequency can be used to determine a frequency (e.g., daily, weekly, biweekly, monthly, etc.) that the worker is required to provide testing results for a particular disease or infection (i.e., to maintain a certification or otherwise be permitted to engage in an activity or perform an operation). Details associated with a model for determining an optimal testing frequency are described below.

[0054] In at least one example, a Susceptible-Exposed-Infections-Removed (SEIR)-like model, in which workers interact with an age -structured community population (representing patients, customers, etc.) as well as among themselves, can be used for determining optimal testing frequency. In at least one example, PCR-based testing for each individual in a workforce can be simulated, and time intervals for testing from daily to monthly can be varied to generate the model as described herein. In some examples, one or more assumptions can be used in generating the model: (i) infectiousness begins in the last two days of the incubation period and workers self-quarantine when receiving a positive test or when symptoms occur, so that transmission between workers occurs only from asymptomatically or pre -symptomatically infectious workers and (ii) workers take one day to receive results after testing. In at least one example, one or more parameters, such as incubation time, infectious period, test sensitivity, and test specificity can be probabilistically varied (e.g., over basic reproduction number (R₀) and proportion of infections that were asymptomatic).

[0055] In at least one example, the model can be configured to track one or more features of each simulated person, including but not limited to: (i) the person’s true state of infection (susceptible, exposed, infected, or recovered); (ii) the observed state of infection based on test results (uninfected, currently infected based on positive PCR, or immune based on observed PCR infection followed by completion of a 14 day self-quarantine period); and (iii) whether the person was at work. Each individual person believed to be uninfected in the population can be tested at varying intervals (e.g., simulations). For each simulation, workplace transmission can be varied (e.g., reduced by dividing the number of infectious worker-days by the number of potential infectious worker-days, etc.). At each time point, the effective reproduction number (R_t) can be determined, for example, by multiplying Ro by the reduction in transmission at that time period.

[0056] To validate the model, a mathematical formula with an analytical solution can be derived based on a geometric distribution, which can follow the same assumptions and parameters as the microsimulations (described above). An example of the mathematical formula, which can be used by the status determination component 118 to determine an optimal testing frequency, is provided below in Equation 1.

Equation 1

[0057] In Equation 1, E(lnf ectious Work Days) is the expected number of days that a person who is infected will work, F is the testing frequency in days, and n is the number of infectious days. For symptomatic individuals, n = 3 which is approximately the number of pre symptomatic days. For asymptomatic individuals, n = 9 which is the infectious period length. 1 (. ) is an indicator function which determines if an infectious work day occurs on a testing day. To estimate R_e in a susceptible workforce, the daily R_e can be calculated and the mean can be determined for the first 10 days of the simulation after R_e has stabilized (confidence interval sizes < +/- 0.05). Equation 1 assumes a constant worker population and that workers gain immunity in the short-term after recover) . [0058] In at least one example, the status determination component 118 can determine a status of a worker based at least in part on compliance with testing at the testing frequency determined for the worker. In some examples, the worker can visit a testing facility to obtain a test. In some examples, the worker can receive a testing result (e.g., a physical document) from the testing facility and can provide the testing result to the status determination component 118 via the user computing device 104. In at least one example, the status determination component 118 can prompt a worker to submit a testing result, for example via a user interface displayed by the user computing device 104 of the worker. In some examples, the worker can manually enter information associated with a test and/or testing result the worker has received. In some examples, the user computing device 104 can be associated with a camera or other scanner that can capture an image of a testing result. In some examples, the worker can use another functionality of the user computing device 104 to submit a testing result electronically. The status determination component 118 can receive an electronic version of a testing result and, if necessary, can perform natural language processing, image processing, and/or the like to extract testing results and/or other relevant information.

[0059] In some examples, the testing facility, which can be associated with one of the third-party computing device(s) 127, can provide a testing result (e.g., an electronic document or other object) to the service provider computing device(s) 102, for example via an email, secure portal, integration, and/or the like.

[0060] In at least one example, based at least in part on receiving a testing result (e.g., via upload or electronic transmission), the status determination component 118 can determine the status of the worker. In at least one example, if the testing result is associated with a first result (e.g., positive, inclusive, etc ), the status determination component 118 can determine that the worker is associated with an inactive status. In at least one example, if the testing result is associated with a second result (e.g., negative), the status determination component 118 can determine that the worker is associated with an active status. In some examples, an active status can require additional or alternative conditions to be satisfied (e.g., symptom-free, etc.). In some examples, a testing result associated with the second result may not be the only way to achieve an active status. For example, if a worker tests positive and a recommended quarantine period lapses from the date of the positive test, the status determination component 118 can determine that the worker is associated with an active status. Or, if a worker has been vaccinated, the status determination component 118 can determine that the worker is associated with an active status. In at least one example, the status detennination component 118 can associate a flag or other indicator indicating a status of a worker (e.g., active, inactive, etc.) with a worker profile of the worker. In at least one example, workers associated with an active status can be '‘certified” and/or have a “pass” to enable them to perform workplace operations, at least temporarily.

[0061] In at least one example, a worker can be associated with a status for a period of time. In some examples, the period of time can be determined based at least in part on the testing frequency determined for the worker. In at least one example, the worker can be associated with an active status until a period of time, determined based on the testing frequency, has lapsed. In at least one example, at a time prior to the end of the period of time, the status determination component 118 can cause a notification to be sent to the user computing device 104 to notify the worker that another testing result needs to be submitted to maintain the active status. In at least one example, if the period of time has lapsed and another (negative) testing result has not yet been received, the status determination component 118 can modify' the active status of the worker to an inactive status. In at least one example, the period of time can be determined based at least in part on the first testing result. For example, if the first testing result is associated with a first result (e.g., positive, inconclusive, etc.), the period of time can be a shorter or longer period of time than if the first testing result was associated with a second result (e.g., negative). In some examples, a worker can be required to complete additional or alternative check-ins or testing, for example, at a same or different frequency than the testing frequency. For instance, in at least one example, a worker can be required to submit an indication of symptoms daily, weekly, or the like, to maintain an active status (e.g., even with anegative testing result). Additional details associated with determining status(es), utilizing testing for certification, and/or maintaining certification are described below with reference to FIGS. 14-16.

[0062] In at least one example, the access control component 120 can control access to workplace operations as described herein. In an example, access to workplace operations can be conditioned based at least in part on compliance with testing requirements or other occupational health testing protocol. In at least one example, the access control component 120 can provide indicators to workers that are associated with an active status. That is, the access control component 120 can provide indicators to workers that are certified. An indicator can comprise a certification or a pass for an associated worker. In some examples, such an indicator can comprise a passcode, a barcode, a Quick Response (QR) code, a badge, and/or the like.

[0063] In some examples, the indicator can be presented via a user interface displayed by a user computing device 104 of the worker to enable the worker to access one or more workplace operations. For example, the access control component 120 can receive a request for a worker to perform an operation. In some examples, the access control component 120 can cause a prompt to be presented to cause the worker to provide an indicator indicating their active status (i.e., that they are certified). In at least one example, the worker can present the user computing device 104, which can display the indicator, to a reader device. The reader device can read the indicator and send an indication of the indicator to the access control component 120. In at least one example, the access control component 120 can receive the indication of the indicator and can enable the worker to perform the operation. In some examples, the worker can provide the indicator via another mechanism, such as by inputting a passcode provided to the worker, or the like. In at least one example, based at least in part on determining that a worker is associated with an active status, the access control component 120 can send a notification to a workplace of the worker to notify the workplace that the worker is associated with an active status. In some examples, such a notification can be associated with an email, a text message, an in-app notification, and/or the like.

[0064] In some examples, a request (e.g., to verify status of a worker) can be sent from a computing device associated with a workplace (e.g., which can be a third-party computing device of the third-party computing device(s) 127). An example of such a workplace computing device can be a computing device controlling access to a workplace facility, a room or area in the workplace facility, and/or the like. In some examples, an example of such a workplace computing device can be a computing device that controls machinery or other equipment within a workplace. In some examples, an example of such a workplace computing device can be a computing device associated with a software application or other program that enables the worker to perform operations for the workplace.

[0065] In at least one example, the reporting component 122 can generate and/or output reports based at least in part on data stored in association with the service provider computing device(s) 102 (e.g., in the datastore 124). In at least one example, the reporting component 122 can receive a query or other request for data associated with a particular characteristic (e.g., active workers, inactive workers, vaccinated workers, etc.). In at least one example, the reporting component 122 can generate and/or output a response and/or report to the query and/or other request for data. In at least one example, the reporting component 122 can provide reports to workplaces to enable workplaces to obtain a macro-level view of such workplaces.

[0066] In at least one example, the datastore 124 can be configured to store data that is accessible, manageable, and updatable. In some examples, the datastore 124 can be integrated with the service provider computing device(s) 102, as shown in FIG. 1A. In other examples, the datastore 124 can be located remotely from the service provider computing device (s) 102 and can be accessible to the service provider computing device (s) 102 and/or user device(s), such as the user device 104. The datastore 124 can comprise one or multiple databases, which can include, but are not limited to, worker profiles 128, testing data 129, and rule(s)/model(s) 130, which can be associated with the protocol described herein. Additional or alternative data may be stored in the datastore and/or one or more other datastores. [0067] In at least one example, the worker profiles 128 can store data associated with workers. In at least one example, a worker profile can store data including, but not limited to, worker data associated with the worker, registration data associated with the worker, symptom data associated with the worker, testing data associated with the worker, and/or the like. In at least one example, a worker profile of the worker profiles 128 can be associated with a flag or other indicator indicating the status of the worker. As described above, the flag or other indicator can indicate whether the worker is associated with an active status or inactive status. In some examples, such “passes” or “certificates” (i.e., indicating an active status) can be stored in a separate database in addition to, or as an alternative of, being stored with the worker profiles 128.

[0068] In at least one example, the testing data 129 can store data associated with pending tests and testing results history of individual workers. In some examples, testing results associated with an individual worker can be mapped to, or otherwise associated with, a worker profile associated within the worker profiles 129.

[0069] In at least one example, the rule(s)/model(s) 130 can be associated with the protocol as described herein. [0070] A non-limiting example of a configuration of the datastore 124, storing at least some of the data described herein, is illustrated in FIG. IB. For example, as illustrated in FIG. IB, the datastore 124 can include testing results, certifications, worker profiles, and/or the like.

[0071] In at least one example, the operating system 126 can manage the processor(s) 108, computer-readable media 110, hardware, software, etc. of the service provider computing device(s) 102.

[0072] The communication interface(s) 112 can include one or more interfaces and hardware components for enabling communication with various other devices (e.g., the user computing device 104), such as over the network(s) 106 or directly. In some examples, the communication interface(s) 112 can facilitate communication via Application Programming Interfaces (APIs) (e.g., using API calls), HyperText Transfer Protocols (HTTPs), etc.

[0073] The service provider computing device(s) 102 can further be equipped with various input/output devices 114 (e.g., I/O devices). Such I/O devices 114 can include a display, various user interface controls (e.g., buttons, keyboard, mouse, touch screen, etc.), audio speakers, connection ports and so forth. [0074] In at least one example, the user computing device 104 can include one or more processors 132, computer- readable media 134, one or more communication interfaces 136, and input/output devices 138.

[0075] In at least one example, each processor of the processor(s) 132 can be a single processing unit or multiple processing units, and can include single or multiple computing units or multiple processing cores. The processor(s) 132 can comprise any of the types of processors described above with reference to the processor(s) 108 and may be the same as or different than the processor(s) 108.

[0076] The computer-readable media 134 can comprise any of the types of computer-readable media 134 described above with reference to the computer-readable media 110 and may be the same as or different than the computer- readable media 110. Functional components stored in the computer-readable media can optionally include at least one application 140 and an operating system 142.

[0077] In at least one example, the application 140 can be a mobile application, a web application, or a desktop application, which can be provided by the service provider or which can be an otherwise dedicated application. In some examples, the application 140 can be associated with a workplace safety product provided by the service provider. In at least one example, the application 140 can be a native application associated with the service provider. In some examples, individual user computing devices associated with the environment 100 can have an instance or versioned instance of the application 140, which can be downloaded from an application store, accessible via the Internet, or otherwise executable by the processor(s) 132 to perform operations as described herein. That is, the application 140 can be an access point, enabling the user computing device 104 to interact with the service provider computing device(s) 102 to access and/or use services available via the service provider. In at least one example, the application 140 can present user interfaces, as described herein. In at least one example, a user can interact with the user interfaces via touch input, keyboard input, mouse input, spoken input, or any other type of input. Additional or alternative access points, such as a web browser, can be used to enable the user computing device 104 to interact with the service provider computing device(s) 102 as described herein. That is, in examples where the application 140 is described as performing an operation below, in an additional or alternative example, such an operation can be performed by another access point, such as a web browser or the like.

[0078] As described above, the application 140, which can be associated with the user computing device 104, can present one or more user interfaces. In at least one example, the application 140 can present one or more onboarding user interfaces that can enable a user to register with the service provider. Example(s) of onboarding user interface(s) are provided below, for example, with respect to FIGS. 2 and 3. In at least one example, a worker can receive a communication (e.g., an email, text message, etc.) from a workplace (e.g., via the user computing device 104), instructing the worker to download the application 140. In some examples, the workplace can send the communication directly. In other examples, a workplace registered with the sendee provider can request the service provider to send such a communication to workers associated with the workplace. As an example, an employer registered with the service provider can request the service provider to send such a communication to its employees. In some examples, the service provider computing device(s) 102 can utilize worker data to determine where to send such communication(s). In at least one example, the communication can include an activation code and/or a unique, workplace-assigned ID (e.g., worker ID, student ID, username, etc.). Once downloaded, a registration user interface can be displayed on the user computing device 104 and the worker can interact with the user computing device 104 to input a username, password, etc. In some examples, the application 140 can subsequently display an activation user interface, where the worker can enter the activation code, at which point the user can be prompted to enter their unique, workplace-assigned ID. In at least one example, the application 140 can send the data entered (e.g., the activation code, unique, worker-assigned ID, etc.) to the service provider computing device(s) 102. The service provider computing device(s) 102 can then access data records provided by the workplace (e.g., business and/or employer) with which the worker is associated (e.g., stored in the data store 124) to determine if data entered by the worker matches worker data records. For instance, if the service provider computing device(s) 102 determine that the user’s date of birth, activation code, and unique, workplace-assigned ID match the workplace’s data records, the service provider computing device(s) 102 can create an account for the worker. If one or more of the entered user data does not match the workplace’s data record, the user may not be able to proceed past the activation screen. [0079] In at least one example, a worker who successfully creates an account can proceed one or more additional onboarding user interfaces, to input registration data, as described above. Such initial registration data can include, but is not limited to, (i) the worker’s workplace zip code, (ii) the worker’s home zip code, (iii) whether the worker is a healthcare worker or first responder, (iv) whether the worker works remotely, (v) personal information, etc. In some examples, this data can be supplementary to data provided by the workplace of the worker. In some examples, such data can include information that can be used to access information associated with the worker from third-party entities. For instance, the user can provide bus pass information so that the ridership of the worker can be provided to the service provider computing device(s) 102. In another example, the worker can provide account information associated with a third-party service provider (e.g., gym, credit card, bank, healthcare provider, etc.) for the service provider computing device(s) 102 to access an account of the worker (e.g., with consent of the user, of course). While onboarding processes are described above in relation to the application 140, in additional or alternative examples, onboarding processes can be facilitated via a web browser or the like.

[0080] As described above, in at least one example, worker data, registration data, and/or third-party data associated with the worker can be used to determine (i) an initial risk level of the worker, (ii) vulnerability of the worker, and/or (iii) immunity of the worker. In at least one example, the service provider computing device(s) 102 can utilize the data received from worker data, registration data, and/or third-party data associated with the worker to generate a level of risk that is unique to the worker, workplace location, local population, or the like. Determining the level of risk is described above and also below. In at least one example, the level of risk for a worker can be used, in combination with a set of processes, rules, or policies (e.g., protocol) to determine an optimal testing frequency that can be used to determine whether the worker is certified to return to work. That is, the level of risk can be used to determine when a worker is required to provide results of a test, such as a COVID-19 test, to signal positive or negative infection. The worker can be required to provide evidence of a negative test and certify answers to one or more relevant questions related to risk of transmission of a disease prior to a certification being issued for the worker. Such certification can be obtained via an active status determination as described above. If a worker is certified, the worker can have access to a certificate (e.g., a QR code, barcode, badge, etc.) that can be valid for a designated period of time. In some examples, the certificate can be presented via a user interface of the user computing device 104. A non-limiting example of such a user interface 144 is shown in FIG. 1A. As illustrated in FIG. 1A, the user interface 144 can present data associated with a worker. In some examples, the user interface 144 can present a QR code 146 (or passcode, barcode, badge, etc.). In at least one example, the user interface 144 can include user interface element(s) 148 indicating a status of the worker (i.e., Active), a prompt on how to use the QR code 146, an expiration date of the “pass,” etc. In some examples, the user interface 144 can include user interface element(s) associated with actuation mechanism(s) 150 that, when actuated, enable the worker to schedule another test or test(s), view policies, and/or the like. Additional or alternative data can be presented via the user interface 144, as shown and described below.

[0081] While it should be noted that testing results are part of determining the risk of a worker’s infectiousness and ability to return to work, one or more other factors can contribute to such a determination, which can include an initial risk level (e.g., which can be based at least in part on a geographic location and/or class associated with the worker), changes in risk level (e.g., changes in health conditions, changes to infection rate of a disease in an area close to the worker), symptoms (e.g., if the worker develops symptoms), exposure (e.g., if the worker was exposed to someone with the disease or has been to high-risk public spaces), prior infection (e.g., if the worker was previously infected with the disease), etc.

[0082] In at least one example, the operating system 142 can manage the processor(s) 132, computer-readable media 134, hardware, software, etc. of the user computing device 104.

[0083] The communication interface(s) 136 can include one or more interfaces and hardware components for enabling communication with various other devices (e.g., the service provider computing device(s) 102), such as over the network(s) 106 or directly. In some examples, the communication interface(s) 136 can facilitate communication via Application Programming Interfaces (APIs) (e.g., using API calls), HyperText Transfer Protocols (HTTPs), etc. [0084] The user computing device 104 can further be equipped with various input/output devices 138 (e.g., I/O devices). Such I/O devices 138 can include a display, various user interface controls (e.g., buttons, keyboard, mouse, touch screen, etc.), audio speakers, sensors (e.g., thermometers, blood oxygen sensors, heartrate monitors, etc.), cameras or other scanners, connection ports, and so forth.

[0085] The environment 100 includes third-party computing device(s) 127. In some examples, individual of the third- party computing device(s) 127 can be associated with an entity, including, but not limited to a workplace (e.g., a business, an employer, and/or an organization), a government entity, a testing facility, a third-party service provider, or the like. In at least one example, the service provider can enable individual of the third-party computing device(s) 127 to access functionality associated with the service provider via one or more interfaces, such as APIs. That is, in some examples, individual of the entities can utilize such APIs to integrate functionality associated with the service provider into their own device(s) to facilitate techniques described herein.

[0086] In at least one example, the service provider computing device(s) 102 can cause a user interface to be displayed via a third-party computing device of the third-party computing device(s) 127 (e.g., via an API) to enable respective workplaces to provide workplace data associated with workplaces and/or worker data. Workplace data and/or worker data is described above.

[0087] FIGS. 2-10 depict examples of a user interface 200, that can be presented via the application 140 or other component of a user computing device, such as the user computing device 104. The user interface 200 can be an instance of the user interface 144 described above with reference to FIG. 1 A. While the user interface 200 is illustrated as a graphical user interface displayed via a user interface of the user computing device 104, in additional or alternative examples, the user interface can comprise a voice user interface (e.g., data described as being presented via the user interface can be output via spoken commands or other speech) or the like.

[0088] FIG. 2 depicts the user interface 200 configured for receiving registration data, for example, as part of an onboarding process as described herein. In at least one example, the user interface 200 can include user interface element(s) 202 for receiving data input from a worker. In at least one example, the user interface 200 can prompt the worker to input registration data, as described above. In one example, the worker can be guided to enter personal information (e.g., name, address (e.g., including zip code), phone number, birthdate, email address, etc.), workplace information (e.g., workplace, an activation code and/or identification code associated with the workplace, a role or assignment at the workplace, etc.), access information (e.g., an email address, phone number, or the like and/or a password), etc. In at least one example, the user interface element(s) 202 can represent input labels (e.g., name, DOB, address, email, and a password) that visually differentiate the data requested from the worker.

[0089] Data collected and/or exchanged via techniques described herein can be highly sensitive and personal to workers and/or other users. As such, various measures can be taken to ensure that such data is securely stored and only used for purposes as disclosed to the workers and/or other users (and consented to by the relevant user(s)). In at least one example, the user interface 200 can include a user interface element 204 that can be associated with an actuation mechanism to enable a worker to provide explicit consent for their data to be shared for the intended purposes (e.g., with their workplace, with testing facilities, with healthcare professionals, etc.). In at least one example, the worker can be required to actuate the actuation mechanism associated with the user interface element 204 to continue with registration. As illustrated in the user interface 200, the user interface 200 can display a message that explains a privacy policy and the user interface element 204 can be associated with the message to enable the worker to acknowledge they have read and understand data collection and privacy protection measures. The worker can revoke consent or request that data stored in association with the worker profde be erased at any time.

[0090] In at least one example, the user interface 200 can include a user interface element 206 that is associated with an actuation mechanism. The actuation mechanism 206 can enable the worker to provide an input to save registration data input via the user interface 200. In at least one example, based at least in part on detecting actuation of the actuation mechanism 206, the application 140 can send the registration data input via the user interface 200 to the service provider computing device(s) 102. Such registration data can be used to generate a worker profde for the worker, which can be stored in the worker profiles 128. In at least one example, based at least in part on detecting actuation of the actuation mechanism 206, the application 140 can update the user interface 200.

[0091] In at least one example, as illustrated in FIG. 3, the user interface 200 can be updated to provide additional or alternative mechanisms for uploading or otherwise providing registration data associated with the worker. In at least one example, after creating a worker profde, the user can be prompted, via one or more user interface elements 300 associated with the user interface 200, to input additional or alternative data. For example, in FIG. 3, the user interface 200 includes user interface element(s) 300 prompting the worker to provide health history data and travel history data. Such data can be associated with “registration data” and can be stored in association with a worker profde, as described above. In some examples, the health history data and/or travel history data can be manually input via the user interface 200. That is, by actuating an actuation mechanism associated with the user interface element(s) 300, an input user interface can be presented to enable the worker to input health history data and/or travel history data. In some examples, health history data and/or travel history data can be provided from a third-party service provider (e.g., via one or more API calls and/or the like). For instance, a healthcare provider can send health history data to the service provider, which can be associated with a worker profile. As another example, an airline can provide data associated with previously purchased airline tickets, which can be associated with a worker profile. In some examples, by actuating an actuation mechanism associated with the user interface element(s) 300, the worker can provide credentials to enable access to such third-party data.

[0092] In at least one example, the worker can interact with the user interface 200, for example to actuate the user interface element 206. In at least one example, based at least in part on detecting such an actuation, the application 140 can send the data input via the user interface 200 to the service provider computing device(s) 102, wherein the data can be associated with a worker profile in the datastore 124.

[0093] FIG. 4 illustrates another example of the user interface 200, wherein the user interface includes one or more user interface elements 400 associated with one or more symptoms. That is, in some examples, the user interface 200 can be associated with an input mechanism through which a worker can indicate which, if any symptoms, the worker has had in a designated period of time. In some examples, the worker can select individual of the user interface element(s) 400 to indicate which symptom(s), if any, the worker has had in the designated period of time. While shown as radio buttons to enable options to be selected, in some examples, a worker can select from a drop down, enter text via a free form text box, toggle a switch, etc. That is, the worker can interact with the user interface 200 via various mechanisms to provide an input associated with symptom data.

[0094] In some examples, the user computing device 104 can receive symptom data from one or more input/output devices 138. For example, the user computing device 104 can obtain a reading from a sensor associated therewith, as described above. In at least one example, by actuating an actuation mechanism associated with user interface element 402, a thermometer can be initialized to obtain a temperature reading. The application 140 can display the temperature reading via the user interface 200 and/or can send an indication of the temperature reading to the service provider computing device(s) 102. As another example, by actuating an actuation mechanism associated with the user interface element 404, a blood oxygen sensor can be initialized to obtain a blood oxygen reading. The application 140 can display the blood oxygen reading via the user interface 200 and/or can send an indication of the blood ox gen reading to the service provider computing device(s) 102. In at least one example, data input via the user interface 200, as represented in FIG. 4, can be referred to herein as “symptom data.”

[0095] In at least one example, the worker can interact with the user interface 200, for example to actuate the user interface element 206. In at least one example, based at least in part on detecting such an actuation, the application 140 can send the data input via the user interface 200 to the service provider computing device(s) 102, wherein the data can be associated with a worker profile in the datastore 124.

[0096] In some examples, the user interface 200 can be configured to facilitate scheduling a test, as illustrated in FIG. 5. For instance, the user interface 200 can include one or more user interface elements 500 that enable a worker to select a location, date, time, etc. for a test. In some examples, appointment details can be selected from a drop-down menu, as illustrated in FIG. 5. In some examples, the worker can select the location, date, time, etc. from other interactive components, such as an interactive map, a calendar, and/or the like. In at least one example, the user interface 200 can include a user interface element 502 that can be associated with an actuation mechanism. In at least one example, based at least in part on detecting an actuation of the actuation mechanism associated with the user interface element 502, the application 140 can utilize the data input via the user interface 200 to schedule the appointment to enable the worker to get the test.

[0097] In at least one example, after a worker has completed the test, the user interface 200 can be updated to include one or more user interface elements 600, which can notify the worker that the testing results have not yet been received, as illustrated in FIG. 6. That is, FIG. 6 is a non-limiting example wherein the user interface 200 indicates that testing results are pending.

[0098] In at least one example, when a testing result is received by the service provider (e.g., from a third-party computing device of the third-party computing device(s) 127), the status determination component 118 can receive the testing result, as described above. In at least one example, based at least in part on determining that the testing result is associated with a first result (e.g., positive or inconclusive), the status determination component 118 can determine that the worker is associated with an inactive status. As described above, the access control component 120 can cause the user interface 200 to be updated to include user interface element(s) 700 indicating that the testing result was positive (or inconclusive), as illustrated in FIG. 7. In at least one example, the user interface 200 can include a user interface element 702 that can be associated with an actuation mechanism that, when actuated, can cause the user interface 200 to be updated to enable the worker to schedule another test (e.g., as illustrated in FIG. 5). [0099] In at least one example, based at least in part on determining that the testing result is associated with a second result (e.g., negative), the status determination component 118 can determine that the worker is associated with an active status. Further, the access control component 120 can cause the user interface 200 to be updated to include user interface element(s) 800 indicating that the worker is associated with an active status, as illustrated in FIG. 8. In at least one example, one of the user interface element(s) 800 can comprise a QR code 802 or other indication indicating that the worker is associated with an active status. As described above, in at least one example, the QR code 802 can be used to access operational operations. In at least one example, the user interface element(s) 800 can include an indication of when the active status of the worker expires (and thus, the “pass” or “certificate” expires). In at least one example, the user interface 200 can include additional or alternative user interface element(s) 804 that can be associated with actuation mechanisms that enable the worker to schedule a new test, access policies, etc.

[0100] In some examples, the service provider can send reminders to workers (e.g., user computing devices associated therewith) prior to expiration of active statuses, as illustrated in FIG. 9. That is, prior to the end of a period of time, determined based on a particular testing frequency for a worker, the status determination component 118 can cause the user interface 200 to be updated to include a reminder for the worker to schedule a new test. In some examples, the user interface 200 can include one or more user interface elements 900 to facilitate such scheduling, as described above with reference to FIG. 4. In at least one example, the user interface 200 can include a user interface element 902 that can be associated with an actuation mechanism. In at least one example, based at least in part on detecting an actuation of the actuation mechanism associated with the user interface element 902, the application 140 can utilize the data input via the user interface 200 to schedule the appointment to enable the worker to get the test.

[0101] In at least one example, if the worker fails to procure a negative test prior to expiration of the active status (e .g. , at the testing frequency associated with the worker) and/or otherwise fails to comply with requirements of having an active status (e.g., does not submit updated symptom data as required and/or indicates they have a symptom) the status determination component 118 can modify the status of the worker to inactive and can cause the user interface 200 to be updated, as illustrated in FIG. 10. As illustrated in FIG. 10, the user interface 200 no longer displays the QR Code 802 and, instead, includes one or more user interface elements 1000 notifying the worker that they’ve lost their active status. In at least one example, the user interface 200 can include a user interface element 1002 that can be associated with an actuation mechanism that, when actuated, can cause the user interface 200 to be updated to enable the worker to schedule another test (e.g., as illustrated in FIG. 5). In some examples, the user interface 200 can be updated to include user interface elements indicating one or more operations that the worker can perform to (again) obtain an active status.

[0102] FIGS. 2-10 illustrate examples of configurations of die user interface 200. FIGS. 2-10 make reference to “user interface elements.” A user interface element can be any element of the user interface. A user interface element can be a text element, a graphical element, a picture, a logo, a symbol, and/or the like. In some examples, a user interface element can be presented as a pop-up, overlay, new sections of the user interface 200, a new user interface, part of another user interface element, and/or the like. In at least one example, individual of the user interface elements can be associated with actuation mechanisms. Such actuation mechanisms can make the corresponding user interface elements selectable. That is, actuation of an actuation mechanism as described herein can, in some examples, indicate a selection of a corresponding user interface element. In at least one example, the application 140 can receive an indication of an interaction with a user interface element (e.g., indication of a selection and/or actuation of an actuation mechanism) and can send an indication of such to the service provider computing device(s) 102. In some examples, the service provider computing device (s) 102 can send data and/or instructions to the application 140 to generate new user interfaces and/or update the user interface 200, as described herein.

[0103] The example user interfaces and user interface elements described above are provided for illustrative purposes. In some examples, such user interfaces and user interface elements can include additional or alternative data, which can be presented in additional or alternative configurations. That is, the user interfaces and user interface elements should not be construed as limiting.

[0104] FIGS. 11-17 are flowcharts showing example processes involving techniques as described herein. The processes illustrated in FIGS. 11-17 are described with reference to components of the environment 100 shown in FIG. 1 A for convenience and ease of understanding. However, the processes illustrated in FIGS. 11-17 are not limited to being performed using the components described above with reference to the environment 100. Moreover, the components described above with reference to the environment 100 are not limited to performing the processes illustrated in FIGS. 11-17.

[0105] The processes in FIGS. 11-17 are illustrated as collections of blocks in logical flow graphs, which represent sequences of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by processor(s), perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described blocks can be combined in any order and/or in parallel to implement the processes. In some embodiments, one or more blocks of the process can be omitted entirely. Moreover, the processes in FIGS. 11-17 can be combined in whole or in part with each other or with other processes. [0106] FIG. 11 illustrates an example process 1100 for determining a level of risk associated with a worker, as described herein.

[0107] At operation 1102, the service provider computing device(s) 102 can receive data associated with a worker of a workplace. This data can be received or ingested via one or more input mechanisms. As discussed above, in some examples, such data can be received from a user computing device 104 of a worker or of a workplace (e.g., which can be a third-party computing device of the third-party computing device(s) 127). That is, in some examples, data associated with a worker can comprise worker data or workplace data, as described above. In some examples, the data can be received in a data fde or other object that is associated with data for each worker of the workplace. In some examples, the service provider computing device(s) 102 can receive workplace data or worker data in a first format and can convert the worker data into a second format, which can be standardized for the service provider. [0108] At operation 1104, the service provider computing device(s) 102 can store the data in a datastore of a service provider. As discussed above, the service provider computing device(s) 102 can store such data in the datastore 124, for example, in a worker profile of the worker profiles 128.

[0109] At operation 1106, which can be optional, the service provider computing device(s) 102 can process the data to classify the worker. For example, the service provider computing device(s) 102 can determine classes of individual of the workers, based at least in part on roles and/or assignments received via the data associated with the worker. In some examples, such classes can be based at least in part on additional or alternative workplace data, worker data, or other data associated with the worker. In some examples, the service provider computing device(s) 102 can use a classifier and/or a classification model to classify individual of the workers, as described above. In some examples, such classes can be used to determine risk levels associated with individual workers and/or groups of workers.

[0110] At operation 1108, the service provider computing device(s) 102 can determine a level of risk associated with the worker. The service provider computing device(s) 102, for example, can analyze workplace data, worker data, and/or the like to determine levels of risk associated with individual of the workers. In some examples, additional or alternative data can be used for detennining levels of risk. Furthermore, in some examples, epidemiological considerations can be utilized to determine levels of risks for particular health-related events. Such considerations include transmission rates, routes of transmission, forms of transmission, viral shedding and symptoms, incubation period, basic reproduction number (e.g., measure of transmissibilify), case fatality rate, reinfection and immunity, etc. In some examples, such data can be obtained from third-part sources, such as the U.S. Department of Health or the like. In some examples, such data can include new case counts and/or otherwise indicate current rates of transmission. In some examples, epidemiological considerations can be based on geographic area(s) associated with worker(s) (e.g., based on zip code or other indicators) such that levels of risk can be based at least in part on changes in local areas. [0111] As discussed above, in some examples, classes, as determined above, can be used by the service provider computing device(s) 102 to determine levels of risk associated with individual of the workers. In some examples, the service provider computing device(s) 102 can analyze workplace data, worker data, classes, and/or any other data as described above using one or more rules to determine levels of risk associated with individual of the workers. In some examples, the service provider computing device(s) 102 can analyze workplace data, worker data, classes, and/or any other data as described above using an algorithm and/or machine-trained model (e.g., a model trained using a machine -learning mechanism) to determine levels of risk associated with individual of the workers), as described above. In at least one example, as indicated above, a machine-trained model can be trained to output a score or other indicator indicative of a level of risk associated with individual workers (e.g., based at least in part on received worker data and/or classes). Thus, in some examples, the service provider computing device(s) 102 can output a score or other indicator indicative of a level of risk associated with individual workers. In some examples, a level of risk can be associated with a score or metric (e.g., 100 indicating high risk, 0 indicating low risk), a range of scores or metrics (e.g., 100-75 indicating high risk, 74-120 indicating medium risk, 120-0 indicating low risk), or the like. In at least one example, workers can be associated with one or more levels of risk, which can be tied to different roles/assignments, workplaces, geographical locations, etc.

[0112] Thus, in at least one example, the service provider computing device(s) 102 can determine a level of risk associated with the worker based at least in part on the data received at operation 1102 and, in some examples, epidemiological considerations. In some examples, the level of risk can be tied to a class of the worker (as determined at operation 1106), a role/assignment of the worker, and/or a geographical location of the worker. In some examples, the process 1100 can proceed from operation 1104 to operation 1108 without first processing the data to classify the worker. That is, the service provider computing device(s) 102 can receive the data associated with the worker, store the data, and determine a level of risk associated with the worker without having first classified the worker. In at least one example, the level of risk determined for the worker can be used to determine a testing frequency for the worker, as described below with reference to FIG. 13.

[0113] FIG. 12 illustrates an example process 1200 for receiving at least one of registration data and/or symptom data associated with a worker, as described herein. In some examples, one or more operations associated with the process 1200 can be performed during onboarding (e.g., onboarding the worker with the workplace safety product).

[0114] At operation 1202, the service provider computing device(s) 102 can cause a user interface to be presented via computing device of the worker. The service provider can be associated with service provider computing device(s) 102 that receive(s) data from disparate sources, including but not limited to, workplace computing devices, worker computing devices, testing facility computing devices, healthcare computing devices, and/or the like. In some examples, such data can be received via applications provided by the service provider. In some examples, such data can be received via one or more APIs or other computing components that enable integration between the service provider and one or more other entities. In at least one example, the service provider computing device(s) 102 can exchange data with the application 140 to cause a user interface to be presented via a user computing device 104 of the worker. A non-limiting example of such a user interface is described above with reference to FIGS. 2 and 3. [0115] At operation 1204 the service provider computing device(s) 102 can receive via the user interface, registration data associated with a worker of a workplace. As described above, in at least one example, the worker can input registration data via the user interface. In some examples, registration data can be received from third-party sources. Examples of registration data are described above.

[0116] At operation 1206, the service provider computing device(s) 102, can store the registration data in a datastore of a service provider. For example, worker account data can be stored in a worker profile associated with the worker profiles 128 of the datastore 124.

[0117] At operation 1208, the service provider computing device(s) 102 can receive, via the user interface, symptom data associated with the worker. In at least one example, the user interface can be updated to prompt the worker to input symptom data. An example of such a user interface is described above with reference to FIG. 4. Examples of symptom data are provided above. In some examples, symptom data can be received by the service provider computing device(s) 102 (e.g., via the application 140). In some examples, the worker can be required to provide symptom data at a particular frequency, which may or may not be determined using the protocol described herein. In some examples, a worker can be required to provide symptom data hourly, daily, weekly, etc.

[0118] In at least one example, worker data, workplace data, class(es), level(s) of risk, registration data, and/or symptom data can be used by the service provider computing device(s) 102 to determine a testing frequency for a worker. Additional details associated with determining a testing frequency are described below with reference to FIG. 13.

[0119] FIG. 13 illustrates an example process 1300 for determining an optimal testing frequency for a worker, as described herein.

[0120] At operation 1302, the service provider computing device(s) 102 can receive data associated with a worker, as described above with reference to operation 1102 of FIG. 11, operation 1204 of FIG. 12, and operation 1208 of FIG. 12.

[0121] At operation 1304, the service provider computing device(s) 102 can determine worker information associated with the worker. In at least one example, the sendee provider computing device(s) 102 can determine the worker information based on the data associated with the worker. In some examples, such worker information can comprise a class associated with the worker, as described above with reference to operation 1106 of FIG. 11.

[0122] At operation 1306, the service provider computing device(s) 102 can access transmission rate data for the particular disease or infection. In at least one example, the transmission rate data can be accessed via outside third- party data sources, such as the U.S. Department of Health or the like. This can provide new case counts or otherwise indicate current rates of transmission. In at least one example, the service provider computing device(s) 102 can determine a transmission rate for the worker’s home zip code and/or the worker’s workplace zip code. In this way, the service provider computing device(s) 102 can modify worker risk levels based on changes in local areas.

[0123] At operation 1308, the service provider computing device(s) 102 can determine a level of risk for the worker (e.g., a risk level indicating the worker’s risk of being infected and/or infectious to others). In at least one example, the level of risk can be based on the data associated with the worker, the worker information, and/or the transmission rate data.

[0124] In at least one example, the service provider computing device(s) 102 can utilize the worker data to generate a level of risk that is unique to the worker, workplace location, and local population. As an example, the service provider computing device(s) 102 can determine a level of risk of the worker based on one or more factors, including demographic information of the worker (e.g., age, gender, race, ethnicity, etc.), zip code(s) of the worker (e.g., where they live, where they work), work site information (e.g., contact, ventilation, interaction with public, etc.), health condition/wellness, job type/role, whether the worker is a healthcare worker, whether the worker uses public transportation, whether the worker lives with others, and the like. In at least one example, the service provider computing device(s) 102 can determine the level of risk by utilizing one or more of statistical analysis, machine learning techniques, and/or other data analysis techniques, as described above.

[0125] In at least one example, worker data associated with a worker can be received from multiple workplaces, indicating that the worker has multiple jobs (e.g., is employed by one or more employers in one or more roles). In such an example, the service provider computing device(s) 102 can determine levels of risk associated with each of the worker’s jobs and can prioritize the level of risk based at least in part on raking levels of risk associated with different jobs, etc.

[0126] At operation 1310 the service provider computing device(s) 102 can determine an optimal testing frequency (e.g., recommendation(s) on how often to test a worker under different risk scenarios and type(s) of testing modalities (e.g., saliva, serologic, PCR, etc.)). An “optimal testing frequency” seeks to minimize false positives caused by too frequent of testing and works to ensure that effective reproductive number (e.g., the number of secondary cases caused by a primary case) is less than one to prevent an outbreak hi at least one example, the service provider computing device(s) 102 can utilize a model to determine the optimal testing frequency.

[0127] In at least one example, the service provider computing device(s) 102 can input (i) the level of risk (e.g., as described above with reference to operation 1104) and the (ii) transmission rate data (e.g., as described above with reference to operation 1106) into the model and the model can output the optimal testing frequency that (i) minimizes the number of false positives and (ii) preserves the effective reproductive number to be less than one. In at least one example, the optimal testing frequency can be customized for the worker and can be based at least in part on data associated with the worker (e.g., workplace data, worker data, registration data, third-party data, etc.). In other examples, the optimal testing frequency can be customized for a cohort of workers (e.g., work site, a group of similar workers, etc.), a general population, or the like. In at least one example, the optimal testing frequency can be used to determine a frequency (e.g., daily, weekly, biweekly, monthly, etc.) that the worker is required to provide testing results for a particular disease or infection (i.e., to maintain a certification or otherwise be permitted to engage in an activity or perform an operation).

[0128] In at least one example, the techniques described herein can request an indication of testing (i.e., a testing result) from the worker (e.g., an indication of whether the worker has been tested for a particular infection or disease and/or a request for testing results from the worker). In some examples, the timing for determining when to send the request can be determined based at least in part on the optimal testing frequency determined for the worker. In some examples, the request can be sent via an email, text message, push notification, an in-app notification, etc. In at least one example, if the worker has been tested, the worker can upload testing results via the application 140. In some examples, the service provider computing device(s) 102 can receive testing results from partners providing testing and with whom the worker has granted permission to share the testing results (e.g., from third-party computing device(s) 127 associated therewith). Examples of user interfaces to facilitate scheduling a test, uploading a testing result, viewing testing results, and/or receiving reminders for rescheduling tests are described above with reference to FIGS. 5-9.

[0129] In some examples, the service provider computing device(s) 102 can determine a symptom checking frequency for the worker. For instance, the service provider computing device(s) 102 can require the worker to provide symptom data to determine if the worker is exhibiting symptoms consistent with a particular disease or infection, and/or has been exposed to someone with the particular disease or infection. In at least one example, the service provider computing device(s) 102 can display questions associated with exposure and symptoms to the worker via the user computing device 104. In at least one example, the questions can be customized for the particular disease or infection. In at least one example, techniques described here can be integrated with wearable technology, such that worker symptoms can be based on and/or confirmed by real time data.

[0130] In at least one example, the service provider computing device(s) 102 can determine if the worker is certified (i.e., to show up to work, participate in an activity, perform an operation, or the like), based at least in part on testing results and an indication that the worker is not and/or has not experienced a designated set of symptoms in a designated period of time. In some examples, the symptom(s) and/or period of time can be particular to the worker (e.g., based on worker data, worker information, level of risk, etc.). If a worker is associated with a negative test and has not experienced the designated set of symptoms during the designated period of time, the service provider computing device(s) 102 can determine that the worker is associated with an active status and thus is certified. In such an example, the service provider computing device(s) 102 can provide the worker with a notification that the worker is certified, as described above. In some examples, the notification can include a code (e.g., QR code, barcode, etc.), badge, or some other indicator indicating that the worker is certified. In at least one example, the certification can be valid for a period of time, that can be determined based on the optimal testing frequency, after which the worker may be required to submit to another test and re-certify.

[0131] FIG. 14 illustrates an example process 1400 for utilizing testing for certification, as described herein.

[0132] At operation 1402, the service provider computing device(s) 102 can receive testing results of a worker. In some examples, workers can visit testing facilities to obtain a test. In some examples, such testing facilities can provide a testing result to the worker. In at least one example, the worker can manually provide a testing result (e.g., manually input a testing result) and/or can submit an image of the testing result, as described above. For instance, the worker can submit a picture of a testing result and the service provider computing device(s) 102 can use optical character recognition (OCR) techniques to identify and extract values. Such extracted information can be compared to the submitted testing results to verify the submitted testing results. In at least one example, the testing results received from the worker can be manually verified by a service agent of the service provider. In some examples, the service provider can partner with one or more testing facilities that, with consent of the worker, can provide the testing results to the service provider. In at least one example, the service provider computing device(s) 102 can receive multiple types of testing results from one or more workers.

[0133] At operation 1404, the service provider computing device(s) 102 can determine if the result of the test is positive. In at least one example, if the testing result is determined to not be positive (e.g., the test is negative) (i.e., “no” at operation 1404), an indication of a negative result can be stored in association with an account of the worker (e.g., a worker profile), as shown in operation 1406. At operation 1410, in response to determining that a testing result is negative (i.e., “no” at operation 1404), the service provider computing device(s) 102 can generate a certificate, store the certificate, as shown in operation 1414, and cause the certificate to be presented to the worker via a user computing device 104. That is, the service provider computing device(s) 102 can determine that a worker is associated with an active status and generate the certificate based on such a determination. In some examples, the worker may be required to provide additional or alternative information (e.g., that the worker has not experienced designated symptoms during a period of time) prior to the service provider computing device(s) 102 determining that the worker is associated with an active status and generating, storing, and/or presenting the certificate to the worker. In at least one example, the certificate can be presented to the worker via the application 140. An example certificate, which can be an indication presented via a user interface, is illustrated above in FIG. 8. In at least one example, the certificate can be associated with an expiration date. In at least one example, the certificate can be used to verify that the worker has not been exposed and/or does not currently have symptoms of a particular disease and/or infection. For instance, the worker can present the certificate in order to gain access to particular public or private areas (e.g., entry to a restaurant, enter a workplace building, go to school, etc.), perform an activity, perform an operation, etc.

[0134] In at least one example, if the testing result is determined to be positive (i.e., “yes” at operation 1404), the service provider computing device(s) 102 can cause a notification to be sent to at least one entity (e.g., an employer, the service provider, the government, another third-party entity, etc.), as shown in operation 1408, and an indication of a positive result can be stored in associated an account of the worker (e.g., worker profile), as shown in operation 1412. The service provider computing device(s) 102 can also generate and display a directive for the worker, as shown in operation 1416. In at least one example, such a directive can include an instruction to stay home, obtain treatment, obtain another test, reach out to a workplace for more instruction, etc. That is, the directive can comprise one or more operations that the worker is to perform to obtain a certificate and/or active status.

[0135] In at least one example the techniques described herein can be utilized for contact tracing (e.g., identifying and notifying one or more person(s) potentially exposed to a known carrier of a particular disease or infection) and/or exposure control, as described in the protocol. For instance, the techniques described herein can be integrated with third-party data sources of a worker (e.g., calendar application(s), email application(s), transportation pass(es), transportation application(s), fitness tracking application(s) and/or device(s), etc.), which can be utilized, in conjunction with the data, worker information, health care data, described herein to aid in contact tracing. In at least one example, the integrated worker information can be presented to one or more of the worker, workplace(s) of the worker, or another entity.

[0136] FIG. 15 illustrates an example process 1500 for maintaining certification of a worker, as described herein. [0137] At operation 1502, the sendee provider computing device(s) 102 can receive data from a worker based on an optimal testing frequency. For instance, the optimal testing frequency for the worker can require the worker to enter responses to questions every 24 hours, three days, one week, or the like. As such, the worker can be required to provide testing results at the determined testing frequency for the worker. In at least one example, the worker can also be required to answer one or more questions at the particular testing frequency. Such question(s) can relate to exposure of the worker (e.g., has the worker been exposed to a person diagnosed with a particular disease or infection; has the worker traveled by plane as a passenger, etc.) and/or symptoms of the worker (e.g., has the worker experienced one or more new symptoms associated with the particular disease or infection). In at least one example, the service provider computing device(s) 102 can receive the data via the application 140, wearable devices, data from third- party" data sources, etc.

[0138] At operation 1504, the service provider computing device(s) 102 can determine if the worker has responded during a predetermined period of time (e.g., 24 horns, three days, one week, etc.). In at least one example, the service provider computing device(s) 102 can require the worker to provide worker data every 24 hours, three days, one week, etc. In at least one example, if the service provider computing device(s) 102 determine the worker has not responded for the predetermined period of time associated with the testing frequency for the worker, the service provider computing device(s) 102 can invalidate an active certificate, as shown in 1506. In at least one example, the worker can reactivate the certificate (e.g., for the remaining life of the certificate), by providing worker data, such as responses to the one or more questions (e.g., indicating symptom and/or exposure risk). In such an example, the process can return to operation 1502.

[0139] In at least one example, the service provider computing device(s) 102 can determine that the worker has responded during the predetermined period of time. At operation 1508, the service provider computing device(s) 102 can cause one or more questions to be presented to the worker via the user computing device 122. In at least one example, the one or more questions can be associated with new worker exposure and new worker symptoms, as described above. The service provider computing device(s) 102 can determine if the worker has answered “YES” to any of the one or more questions, which indicates the worker has new symptoms and/or new exposure to the particular disease or infection. In at least one example, the service provider computing device(s) 102 determine the worker has not answered “YES” to any of the one or more questions. In this example, an active certificate of the worker can be maintained, as illustrated at operation 1510, and the worker can be instructed to report again according to the optimal testing frequency.

[0140] In at least one example, the service provider computing device(s) 102 can determine that the worker has answered “YES” to at least one of the one or more questions. In this example, the worker’s active certificate, if any, can be invalidated, as shown in operation 1512, and the service provider computing device(s) 102 can require the worker to continue to report symptoms according to the optimal testing frequency. In at least one example, the worker’s optimal testing frequency can be updated based on the indication of positive symptom(s) and/or positive exposure of the worker. In at least one example, the service provider computing device(s) 102 can instruct the worker to submit a new test. In at least one example, the service provider computing device(s) 102 can cause a new testing kit to be sent to the worker in response to the indication of a positive symptom and/or positive exposure. [0141] In at least one example, the service provider computing device(s) 102 can cause the worker’s certificate to be reactivated at a later time. In at least one example, the worker certificate can be reactivated if the sendee provider computing device(s) 102 receive a new, negative testing result from the worker via the user computing device 122. Additionally, or alternatively, the worker’s certificate can be reactivated if the sendee provider computing device(s) 102 determines that the worker does not answer “YES” (e.g., the worker answers “NO” to the one or more questions), on or after a predetermined amount of time (e.g., 7 days, 10 days, etc.) after the initial date of symptom reporting. If the service provider computing device(s) 102 determines that the worker takes another action (e.g., answers “YES” or “NO” to the one or more questions within the predetermined amount of time, does nothing, etc., the worker’s certificate can remain invalidated.

[0142] In some examples, reminders for testing and/or symptom submissions can be sent to the worker via messages, emails, texts, push notifications, in-app notifications, or the like.

[0143] In at least one example, the techniques described herein can be utilized for integrated health care billing and/or payment.

[0144] FIG. 16 illustrates an example process 1600 for implementing occupational health testing protocol, as described herein.

[0145] At operation 1602, the service provider computing device(s) 102 can determine, based at least in part on a level of risk and/or symptom data, a testing frequency for a worker, wherein the worker is associated with an inactive status. For instance, the service provider computing device(s) 102 can determine a level of risk associated with a worker (e.g., as described above with reference to FIG. 11), registration data associated with the worker, and/or symptom data associated with the worker (e.g., as described above with reference to FIG. 12) and can determine a testing frequency for the worker. In some examples, such a testing frequency can be determined based at least in part one or more rules. In some examples, such a testing frequency can be determined based at least in part on an algorithm or a machine-trained model. As described above, the service provider computing device(s) 102 can determine a testing frequency, which can be an “optimal testing frequency,” for a worker. An “optimal testing frequency” seeks to minimize false positives caused by too frequent of testing and works to ensure that effective reproductive number is less than one to prevent an outbreak. In at least one example, the optimal testing frequency can be customized for the worker and can be based at least in part on data associated with the worker. In some examples, the optimal testing frequency can be customized for a cohort of workers, a general population, or the like. In at least one example, the optimal testing frequency can be used to determine a frequency (e.g., daily, weekly, biweekly, monthly, etc.) that the worker is required to provide testing results for a particular disease or infection (i.e., to maintain a certification or otherwise be permitted to engage in an activity or perform an operation).

[0146] In at least one example, the sendee provider computing device(s) 102 can determine a status of a worker based at least in part on compliance with testing at the testing frequency determined for the worker. At operation 1604, the service provider computing device(s) 102 can determine if a testing result has been received from a worker. In at least one example, if a testing result has been received (i.e., “yes” at operation 1604), the process 1600 can continue to operation 1606, wherein the service provider computing device(s) 102 can determine whether the testing result is negative. Based at least in part on a determination that the testing result is negative (i.e., “yes” at operation 1606), the service provider computing device(s) 102 can update the inactive status to an active status, as illustrated at operation 1608. In such an example, the sendee provider computing device(s) 102 can modify a flag associated with a worker profile of the worker. In some examples, the service provider computing device(s) 102 can cause an active status indicator to be presented via a user computing device 104 of the worker, as illustrated at operation 1612. In some examples, such an indicator can be a certificate or pass. An example of such is illustrated in FIG. 8, above. In at least one example, such an active status indicator can be used by a worker to access workplace operations.

[0147] At operation 1614, the service provider computing device(s) can determine a period of time based on the testing frequency and, as illustrated at operation 1616, can determine whether the period of time has lapsed. In at least one example, based at least in part on a determination that the period of time has not lapsed, the worker can maintain the active status. Based at least in part on a determination that the period of time has lapsed (i.e., “yes” at operation 1616), the service provider computing device(s) 102 can update the active status to an inactive status, as illustrated at operation 1618. That is, the service provider computing device(s) 102 can modify the flag associated with the worker profile of the w orker from an active status flag to an inactive status flag, or otherwise cause the worker profile to be updated to indicate that the worker is no longer associated with an active status. In at least one example, the service provider computing device(s) 102 can modify the active status indicator to an inactive status indicator. That is, in some examples, the service provider computing device(s) 102 can cause the user interface to be updated to indicate that the worker is not associated with an active status (e.g., does not have a pass, is not certified, etc.). In at least one example, the service provider computing device(s) 102 can prompt the worker to schedule a test. In at least one example, the service provider computing device(s) 102 can send a notification to the user computing device 104 of the worker, which can be presented via a user interface of the user computing device. In some examples, the user interface can enable the worker to schedule a test appointment. An example of such a user interface is illustrated in FIGS. 5 and 9, above.

[0148] In at least one example, if the service provider computing device(s) 102 determine that no testing result has been received (i.e., “no” at operation 1604), the service provider computing device(s) 102 can prompt the worker to schedule a test, as illustrated at operation 1622.

[0149] FIG. 17 illustrates an example process 1700 for controlling access to an operation based at least in part on compliance with the occupational health testing protocol, as described herein.

[0150] At operation 1702, the service provider computing device(s) 102 can receive a request for a worker to perform an operation. In at least one example, a status associated with the worker can be used to determine whether the worker is permitted to perform operations of a workplace. In at least one example, the service provider computing device(s) 102 can cause a prompt to be presented to cause the worker to provide an indicator indicating their active status (i.e., that they are certified).

[0151] At operation 1704, the service provider computing device(s) 102 can determine if the worker is associated with an active status. In at least one example, the worker can present the user computing device 104, which can display the indicator, to a reader device. The reader device can read the indicator and send an indication of the indicator to the service provider computing device(s) 102. In at least one example, based at least in part on receiving the indication of the indicator (i.e., an active status indicator), the service provider computing device(s) 102 can determine that the worker is associated with an active status. In some examples, the worker can provide an indication via an alternative mechanism, such as by providing a code (e.g., via a user interface, to another worker, etc.), presenting a badge, and/or the like.

[0152] In an example where the service provider computing device(s) 102 determine that a worker is associated with an active status (i.e., “yes” at operation 1704), the service provider computing device(s) 102 can enable the worker to perform the operation, as illustrated at operation 1706. As illustrated in FIG. 8, a worker can be enabled to access operational operations with a QR code presented via a user interface of the user computing device 104 associated with the worker. As described above, a “certificate” or “pass” can comprise a QR code or any other type of indicator indicating active status of the worker. In at least one example, workers associated with an active status can be “certified” and/or have a “pass” to enable them to perform workplace operations, at least temporarily.

[0153] In some examples, the service provider computing device(s) 102 can determine that the worker status is not associated with an active status (i.e., “no” at operation 1704). In such an example, the service provider computing device (s) 102 can cause an instruction to be presented via a user interface of the user computing device 104 of the worker, wherein the instruction is associated with operation(s) to be performed to obtain an active status, as illustrated at operation 1708. That is, in an example where the worker is not associated with an active status (i.e., the worker is associated with an inactive status), the service provider computing device(s) 102 can determine why the worker is not associated with an active status (e.g., the worker has not submitted symptom data, the worker has indicated the worker is experiencing a symptom that is associated with an inactive status, the worker has not submitted a testing result, the worker submitted a positive or inconclusive testing result, etc.). In at least one example, the service provider computing device(s) 102 can cause an instruction to be presented via the user computing device 104 of the worker. In at least one example, the instruction can indicate operation(s) to be performed to obtain an active status. For example, the instruction can instruct the worker to submit symptom data, to quarantine for a designated period of time, submit a negative testing result, etc. The process 1700 can then return to operation 1704.

[0154] While FIGS. 11-17 are described as being performed by the service provider computing device(s) 102, individual operations can be performed by additional or alternative components of the service provider computing device(s) 102, for example, as described above with reference to FIG. 1A.

[0155] FIG. 18 illustrates an example of various surfaces associated with a workplace safety product, as described herein. With respect to FIG. 18, there are three rows and two columns illustrated. The rows, for example, can represent target users (e.g., employer/workplace, worker/user, testing partners). In additional or alternative examples, there could be more than three rows, to include additional or alternative users, such as the government or the like. In at least one example, the two columns can represent examples of different user experiences (e.g., the user experience and customer experience (CX) tooling).

[0156] In at least one example, the “App (1)” can represent the application 140, which can be a mobile application, desktop application, or the like, described above. In an alternative example, the App can represent functionality availed via a web browser or a website user interface. The worker can provide data and otherwise interact with the service provider via the App illustrated in FIG. 18. The worker can register for an account, schedule testing appointments, report testing results, answer questions (e.g., regarding symptoms, etc.), view and/or access certificates, and the like via the App. Further, the App can be a mechanism through which the worker can present an active status indicator, as described above.

[0157] In at least one example, the “Testing Partner API (2)” can represent connections between the service provider computing device(s) 102 and one or more third-party computing devices 127 that are associated with lab partners. In at least one example, the Testing Partner API enables communication between the service provider computing device(s) 102 and the one or more third-party computing devices 127 regarding a worker’s testing information (e.g., testing results, etc.).

[0158] In at least one example, the “Assist Platform (3)” can represent an internal customer relationship management system/platform. In at least one example, the Assist Platform can represent a customer service ticketing system and/or a customer service platform for the service provider computing device(s) 102. In at least one example, Assist Platform enables customer service agents to create and submit customer service requests and/or contact a customer service representative.

[0159] In at least one example, the “Review App (4)” represents a class of service agents of the service provider computing device(s) 102. In at least one example, the class of service agents can review and/or manually verily testing results received from worker(s). In at least one example, testing results can be submitted via a photograph and/or manual entry, as described above.

[0160] In at least one example, the “Activation/ Admin Portal (5)” can represent a user interface (e.g., application, web site, etc.) for clients (e.g., employers) of the service provider computing device(s) 102. In at least one example, the workplaces can utilize the Activation/ Admin Portal to administer workplace information, accounts, etc.

[0161] In at least one example, the “Reporting Portal (6)” can represent external facing portal that can be accessed by an entity (e.g., Human Resource department of the entity, Health and Safety, etc.). In at least one example, a workplace entity can log into the Reporting Portal and identify information associated with one or more workers who are employed by the workplace entity. For instance, the Reporting Portal can identify one or more workers that are and/or are not complying with a protocol implemented by the entity. The Reporting Portal can aggregate and/or present reports.

[0162] In at least one example, “Payments (7)” can represent an integration with a billing department associated with the service provider computing device(s) 102. In at least one example, the Payments can identify a number of workers that have been tested, where the number of workers were tested, how much the number of workers were billed for, and/or what the number of workers were billed for. The Payments can facilitate payment for tests, for example. [0163] In at least one example, the “User Status API (8)” can represent an application that is available to both workers and workplaces associated with the workers. In at least one example, the User Status API can enable workers to access information associated with testing (e.g., access testing results, test status, etc.). In at least one example, User Status API is available to workplaces. In at least one example, the User Status API can enable workplaces to identify a particular worker that has tested positive for a particular disease or infection. For instance, the workplace can submit a query to the User Status API, where the query requests information regarding testing of a particular worker (e.g., has a particular worker tested positive for a particular disease or infection). In response, the User Status API can present an indication regarding the query, such as indicating that the particular worker has tested positive for the particular disease or infection.

Conclusion

[0164] While one or more examples of the techniques described herein have been described, various alterations, additions, permutations and equivalents thereof are included within the scope of the techniques described herein. [0165] In the description of examples, reference is made to the accompanying drawings that form a part hereof, which show by way of illustration specific examples of the claimed subject matter. It is to be understood that other examples can be used and that changes or alterations, such as structural changes, can be made. Such examples, changes or alterations are not necessarily departures from the scope with respect to the intended claimed subject matter. While the steps herein can be presented in a certain order, in some cases the ordering can be changed so that certain inputs are provided at different times or in a different order without changing the function of the systems and methods described. The disclosed procedures could also be executed in different orders. Additionally, various computations that are herein need not be performed in the order disclosed, and other examples using alternative orderings of the computations could be readily implemented. In addition to being reordered, the computations could also be decomposed into sub-computations with the same results.

Example Clauses

[0166] A: A method, implemented at least in part by one or more computing devices of a service provider, comprising: receiving worker data associated with a plurality of workers of a workplace; storing the worker data in a datastore of the service provider; processing the worker data to classify individual workers of the plurality of workers, w herein a worker of the plurality workers is associated with a classification; determining, based at least in part on classifications of the individual workers, levels of risk for the individual workers, wherein the worker is associated with a level of risk; receiving, from a computing device of the worker, registration data for the worker; storing the registration data in the datastore of the service provider; causing a user interface to be presented by the computing device of the w orker, wherein the user interface includes one or more user interface elements that are interactable to enable the worker to provide symptom data associated with an occupational health condition; receiving the symptom data from the computing device of the worker; determining, using a model and based at least in part on at least the level of risk of the worker and the symptom data, a testing frequency for the worker; determining a status of the worker based at least in part on a testing result received from a computing device of a testing facility, wherein the testing frequency for the worker is used to determine timing for a subsequent test of the w orker; and causing a status indicator indicative of the status of the worker to be presented via the user interface of the computing device of the worker, wherein the status indicator controls access to one or more workplace operations.

[0167] B: The method of paragraph A, wherein the classification comprises a role or an assignment.

[0168] C: The method of paragraph A or paragraph B, further comprising: receiving, at a first time and from the computing device of the testing facility, the testing result of the worker; based at least in part on the testing result being associated with a first result, associating an active status with the worker; and based at least in part on the testing result being associated with a second result, associating an inactive status with the worker. [0169] D: The method of paragraph C, further comprising: determining that the worker is associated with the active status, wherein the status indicator comprises an active pass; and sending, to a computing device of the workplace, an indication that the worker is associated with an active status.

[0170] E: The method of any of paragraphs C or paragraph D, wherein the testing result of the worker comprises a first testing result, the method further comprising: determining, based at least in part on the testing frequency, a lapse of a period of time from the first time; causing a retesting instruction to be presented via the user interface of the computing device of the worker, wherein the retesting instruction includes an indication of one or more testing facilities; receiving, at a second time, a second testing result associated with the worker; and determining the status of the worker based at least in part on the second testing result.

[0171] F: The method of paragraph C, further comprising: determining that the worker is associated with the inactive status; and causing an instruction to be presented via the user interface of the computing device of the worker, wherein the instruction is associated with one or more operations to be performed to obtain an active status.

[0172] G: The method of any of paragraphs A-F, wherein the user interface further includes one or more additional user interface elements that are interactable to enable the worker to schedule an additional test at one or more testing facilities or review one or more linked policies or other documents of the workplace.

[0173] H: The method of any of paragraphs A-E, wherein the status indicator, when associated with an active status, comprises a Quick Response (QR) code that is readable to enable access to the one or more workplace operations. [0174] I: A system comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions that, when executed by the one or more processors, cause the system to: receive worker data associated with a plurality of workers of a workplace; store the worker data in a datastore of a service provider; process the worker data to classify individual workers of the plurality of workers, wherein a worker of the plurality workers is associated with a classification; determine, based at least in part on classifications of the individual workers, levels of risk for the individual workers, wherein the worker is associated with a level of risk; receive, from a computing device of the worker, registration data for the worker; store the registration data in the datastore of the service provider; cause a user interface to be presented by the computing device of the worker, wherein the user interface includes one or more user interface elements that are interactable to enable the worker to provide symptom data associated with an occupational health condition; receive the symptom data from the computing device of the worker; determine, using a model and based at least in part on at least the level of risk of the worker and the symptom data, a testing frequency for the worker; determine a status of the worker based at least in part on a testing result received from a computing device of a testing facility, wherein the testing frequency for the worker is used to determine timing for a subsequent test of the worker; and cause a status indicator indicative of the status of the worker to be presented via the user interface of the computing device of the worker, wherein the status indicator controls access to one or more workplace operations.

[0175] J: The system of paragraph I, wherein the instructions, when executed by the one or more processors, cause the system further to: receive, at a first time and from the computing device of the testing facility, the testing result of the worker; based at least in part on the testing result being associated with a first result, associate an active status with the worker; and based at least in part on the testing result being associated with a second result, associate an inactive status with the worker.

[0176] K: The system of paragraph J, wherein the instructions, when executed by the one or more processors, cause the system further to: determine that the worker is associated with the active status, wherein the status indicator comprises an active pass; and send, to a computing device of the workplace, an indication that the worker is associated with an active status.

[0177] L: The system of paragraph J or paragraph K, wherein the testing result of the worker comprises a first testing result, and wherein the instructions, when executed by the one or more processors, cause the system further to: determine, based at least in part on the testing frequency, a lapse of a period of time from the first time; cause a retesting instruction to be presented via the user interface of the computing device of the worker, wherein the retesting instruction includes an indication of one or more testing facilities; receive, at a second time, a second testing result associated with the worker; and determine the status of the worker based at least in part on the second testing result. [0178] M: The system of paragraph J, wherein the instructions, when executed by the one or more processors, cause the system further to: determining that the worker is associated with the inactive status; and causing an instruction to be presented via the user interface of the computing device of the worker, wherein the instruction is associated with one or more operations to be performed to obtain an active status.

[0179] N: The system of any of paragraphs I-M, wherein the user interface further includes one or more additional user interface elements that are interactable to enable the worker to schedule an additional test at one or more testing facilities or review one or more linked policies or other documents of the workplace.

[0180] O: The system of any of paragraphs I-L, wherein the status indicator, when associated with an active status, comprises a Quick Response (QR) code that is readable to enable access to the one or more workplace operations. [0181] P: One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to: receive worker data associated with a plurality of workers of a workplace; store the worker data in a datastore of a service provider; process the worker data to classify individual workers of the plurality of workers, wherein a worker of the plurality workers is associated with a classification; determine, based at least in part on classifications of the individual workers, levels of risk for the individual workers, wherein the worker is associated with a level of risk; receive, from a computing device of the worker, registration data for the worker; store the registration data in the datastore of the service provider; cause a user interface to be presented by the computing device of the worker, wherein the user interface includes one or more user interface elements that are interactable to enable the worker to provide symptom data associated with an occupational health condition; receive the symptom data from the computing device of the worker; determine, using a model and based at least in part on at least the level of risk of the w orker and the symptom data, a testing frequency for the worker; determine a status of the worker based at least in part on a testing result received from a computing device of a testing facility, wherein the testing frequency for the worker is used to determine timing for a subsequent test of the worker; and cause a status indicator indicative of the status of the worker to be presented via the user interface of the computing device of the worker, wherein the status indicator controls access to one or more workplace operations. [0182] Q: The one or more non-transitory computer-readable media of paragraph P, wherein the instructions, when executed by the one or more processors, cause the one or more processors further to: receive, at a first time and from the computing device of the testing facility, the testing result of the worker; based at least in part on the testing result being associated with a first result, associate an active status with the worker; and based at least in part on the testing result being associated with a second result, associate an inactive status with the worker.

[0183] R: The one or more non-transitory computer-readable media of paragraph Q, wherein the instructions, when executed by the one or more processors, cause the one or more processors further to: determine that the worker is associated with the active status, wherein the status indicator comprises an active pass; and send, to a computing device of the workplace, an indication that the worker is associated with an active status. [0184] S: The one or more non-transitory computer-readable media of paragraph R, wherein the status indicator comprises a Quick Response (QR) code that is readable to enable access to the one or more workplace operations. [0185] T: The one or more non-transitory computer-readable media of any of paragraphs Q-S, wherein the testing result of the worker comprises a first testing result, and wherein the instructions, when executed by the one or more processors, cause the one or more processors further to: determine, based at least in part on the testing frequency, a lapse of a period of time from the first time; cause a retesting instruction to be presented via the user interface of the computing device of the worker, wherein the retesting instruction includes an indication of one or more testing facilities; receive, at a second time, a second testing result associated with the worker; and determine the status of the worker based at least in part on the second testing result.

[0186] While the example clauses described above are described with respect to one particular implementation, it should be understood that, in the context of this document, the content of the example clauses can also be implemented via a method, device, system, a computer-readable medium, and/or another implementation. Additionally, any of examples A-T may be implemented alone or in combination with any other one or more of the examples A-T.

Claims

CLAIMS What is claimed is:

1. A method, implemented at least in part by one or more computing devices of a service provider, comprising: receiving worker data associated with a plurality of workers of a workplace; storing the worker data in a datastore of the service provider; processing the worker data to classify individual workers of the plurality of workers, wherein a worker of the plurality workers is associated with a classification; determining, based at least in part on classifications of the individual workers, levels of risk for the individual workers, wherein the worker is associated with a level of risk; receiving, from a computing device of the worker, registration data for the worker; storing the registration data in the datastore of the service provider; causing a user interface to be presented by the computing device of the worker, wherein the user interface includes one or more user interface elements that are interactable to enable the worker to provide symptom data associated with an occupational health condition; receiving the symptom data from the computing device of the worker; determining, using a model and based at least in part on at least the level of risk of the worker and the symptom data, a testing frequency for the worker; determining a status of the worker based at least in part on a testing result received from a computing device of a testing facility, wherein the testing frequency for the worker is used to determine timing for a subsequent test of the worker; and causing a status indicator indicative of the status of the worker to be presented via the user interface of the computing device of the worker, wherein the status indicator controls access to one or more workplace operations.

2. The method of claim 1, wherein the classification comprises a role or an assignment.

3. The method of claim 1, further comprising: receiving, at a first time and from the computing device of the testing facility, the testing result of the worker; based at least in part on the testing result being associated with a first result, associating an active status with the worker; and based at least in part on the testing result being associated with a second result, associating an inactive status with the worker.

4. The method of claim 3, further comprising: determining that the worker is associated with the active status, wherein the status indicator comprises an active pass; and sending, to a computing device of the workplace, an indication that the worker is associated with an active status.

5. The method of claim 3, wherein the testing result of the worker comprises a first testing result, the method further comprising: determining, based at least in part on the testing frequency, a lapse of a period of time from the first time; causing a retesting instruction to be presented via the user interface of the computing device of the worker, wherein the retesting instruction includes an indication of one or more testing facilities; receiving, at a second time, a second testing result associated with the worker; and determining the status of the worker based at least in part on the second testing result.

6. The method of claim 3, further comprising: determining that the worker is associated with the inactive status; and causing an instruction to be presented via the user interface of the computing device of the worker, wherein the instruction is associated with one or more operations to be performed to obtain an active status.

7. The method of claim 1, wherein the user interface further includes one or more additional user interface elements that are interactable to enable the worker to schedule an additional test at one or more testing facilities or review one or more linked policies or other documents of the workplace.

8. The method of claim 1, wherein the status indicator, when associated with an active status, comprises a Quick Response (QR) code that is readable to enable access to the one or more workplace operations.

9. A system comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions that, when executed by the one or more processors, cause the system to: receive worker data associated with a plurality of workers of a workplace; store the worker data in a datastore of a service provider; process the worker data to classify individual workers of the plurality of workers, wherein a worker of the plurality workers is associated with a classification; determine, based at least in part on classifications of the individual workers, levels of risk for the individual workers, wherein the worker is associated with a level of risk; receive, from a computing device of the worker, registration data for the worker; store the re istration data in the datastore of the service provider; cause a user interface to be presented by the computing device of the worker, wherein the user interface includes one or more user interface elements that are interactable to enable the worker to provide symptom data associated with an occupational health condition; receive the symptom data from the computing device of the worker; determine, using a model and based at least in part on at least the level of risk of the worker and the symptom data, a testing frequency for the worker; determine a status of the worker based at least in part on a testing result received from a computing device of a testing facility, wherein the testing frequency for the worker is used to determine timing for a subsequent test of the worker; and cause a status indicator indicative of the status of the worker to be presented via the user interface of the computing device of the worker, wherein the status indicator controls access to one or more workplace operations.

10. The system of claim 9, wherein the instructions, when executed by the one or more processors, cause the system further to: receive, at a first time and from the computing device of the testing facility , the testing result of the worker; based at least in part on the testing result being associated with a first result, associate an active status with the worker; and based at least in part on the testing result being associated with a second result, associate an inactive status with the worker.

11. The system of claim 10, wherein the instructions, when executed by the one or more processors, cause the system further to: determine that the worker is associated with the active status, wherein the status indicator comprises an active pass; and send, to a computing device of the workplace, an indication that the worker is associated with an active status.

12. The system of claim 10, wherein the testing result of the worker comprises a first testing result, and wherein the instructions, when executed by the one or more processors, cause the system further to: determine, based at least in part on the testing frequency, a lapse of a period of time from the first time; cause a retesting instruction to be presented via the user interface of the computing device of the worker, wherein the retesting instruction includes an indication of one or more testing facilities; receive, at a second time, a second testing result associated with the worker; and determine the status of the worker based at least in part on the second testing result.

13. The system of claim 10, wherein the instructions, when executed by the one or more processors, cause the system further to: determining that the worker is associated with the inactive status; and causing an instruction to be presented via the user interface of the computing device of the worker, wherein the instruction is associated with one or more operations to be performed to obtain an active status.

14. The system of claim 9, wherein the user interface further includes one or more additional user interface elements that are interactable to enable the worker to schedule an additional test at one or more testing facilities or review one or more linked policies or other documents of the workplace.

15. The system of claim 9, wherein the status indicator, when associated with an active status, comprises a Quick Response (QR) code that is readable to enable access to the one or more workplace operations.

16. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to: receive worker data associated with a plurality of workers of a workplace; store the worker data in a datastore of a service provider; process the worker data to classify individual workers of the plurality of workers, wherein a worker of the plurality workers is associated with a classification; determine, based at least in part on classifications of the individual workers, levels of risk for the individual workers, wherein the worker is associated with a level of risk; receive, from a computing device of the worker, registration data for the worker; store the registration data in the datastore of the service provider; cause a user interface to be presented by the computing device of the worker, wherein the user interface includes one or more user interface elements that are interactable to enable the worker to provide symptom data associated with an occupational health condition; receive the symptom data from the computing device of the worker; determine, using a model and based at least in part on at least the level of risk of the worker and the symptom data, a testing frequency for the worker; determine a status of the worker based at least in part on a testing result received from a computing device of a testing facility, wherein the testing frequency for the worker is used to determine timing for a subsequent test of the worker; and cause a status indicator indicative of the status of the worker to be presented via the user interface of the computing device of the worker, wherein the status indicator controls access to one or more workplace operations.

17. The one or more non-transitory computer-readable media of claim 16, wherein the instructions, when executed by the one or more processors, cause the one or more processors further to: receive, at a first time and from the computing device of the testing facility , the testing result of the worker; based at least in part on the testing result being associated with a first result, associate an active status with the worker; and based at least in part on the testing result being associated with a second result, associate an inactive status with the worker.

18. The one or more non-transitory computer-readable media of claim 17, wherein the instructions, when executed by the one or more processors, cause the one or more processors further to: determine that the worker is associated with the active status, wherein the status indicator comprises an active pass; and send, to a computing device of the workplace, an indication that the worker is associated with an active status.

19. The one or more non-transitory computer-readable media of claim 18, wherein the status indicator comprises a Quick Response (QR) code that is readable to enable access to the one or more workplace operations.

20. The one or more non-transitory computer-readable media of claim 17, wherein the testing result of the worker comprises a first testing result, and wherein the instructions, when executed by the one or more processors, cause the one or more processors further to: determine, based at least in part on the testing frequency, a lapse of a period of time from the first time; cause a retesting instruction to be presented via the user interface of the computing device of the worker, wherein the retesting instruction includes an indication of one or more testing facilities; receive, at a second time, a second testing result associated with the worker; and determine the status of the worker based at least in part on the second testing result.