WO2021155127A1

WO2021155127A1 - Automated data record classification and methods of use thereof

Info

Publication number: WO2021155127A1
Application number: PCT/US2021/015682
Authority: WO
Inventors: Henry LEGERE; Nicholas Solter; Jason Moore; Camille BERRY
Original assignee: Reliant Immune Diagnostics, Inc.
Priority date: 2020-01-31
Filing date: 2021-01-29
Publication date: 2021-08-05

Abstract

Systems and methods for automated rapid medical triage include processing systems (100) to receive a per-visit intake record comprising data representative of a chief complaint and a history of a present illness (HPI) associated with a user visit. The per-visit intake record is matched to a visit type record of a visit template library including a plurality of visit type records based on a matching set of visit type attributes to data representative of the chief complaint and the history of the HPI. A test attribute of the visit type record indicative of an applicable diagnostic test is identified. An emergency attribute of the visit type record indicating that the chief complaint and the HPI form an emergency is identified, and the per-visit intake record is updated by appending a visit type identify identifying the visit type record.

Description

AUTOMATED DATA RECORD CLASSIFICATION AND METHODS OF USE THEREOF

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to United States Provisional Patent Application number 62/968,450 filed on 1/31/2020, which is herein incorporated by reference in its entirety.

COPYRIGHT NOTICE

[0002] A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in drawings that form a part of this document: Copyright, Reliant Immune Diagnostics, All Rights

Reserved.

FIELD OF TECHNOLOGY

[0003] The present disclosure generally relates to computer-based platforms and systems configured for one or more novel technological applications of automated data record classification and methods of use thereof.

BACKGROUND OF TECHNOLOGY

[0004] A computer network platform or system may include a group of computers (e.g., clients, servers, smart routers) and other computing hardware devices that are linked together through one or more communication channels to facilitate communication and resource-sharing, via one or more specifically programmed graphical user interfaces (GUIs), among a wide range of users.

[0005] The creation of an electronic record or profile may include the need to augment the record or profile for more efficient queuing and matching with respect to other records and profiles. However, typically, systems for the creation, queuing, filtering and matching of electronic records and profiles are cumbersome and inefficient.

SUMMARY OF THE DESCRIBED SUBJECT MATTER [0006] In some embodiments, the present disclosure provides a computer-based method that includes at least the following steps of: receiving, by at least one processor, a per-visit intake record including data representative of a chief complaint and a history of a present illness (HP I) associated with a user visit; matching, by the at least one processor, the per-visit intake record to a visit type record of a visit template library including a plurality of per-visit intake records based on a matching set of visit type attributes to data representative of the chief complaint and the HPI; identifying, by the at least one processor, a test attribute of the visit type record indicative of an applicable diagnostic test; identifying, by the at least one processor, an emergency attribute of the visit type record indicating that the chief complaint and the HPI form an emergency; updating, by the at least one processor, the per-visit intake record by appending a visit type identify identifying the visit type record; and causing to display, by the at least one processor, a visit type interface representative of the visit type record on a screen of at least one computing device associated with at least one user of the user visit, including an indication of the emergency attribute and the test attribute.

[0007] In some embodiments, the present disclosure provides a computer-based system that includes at least the following components of at least one data storage system configured to store a visit template library having a plurality of visit templates representing visit type attributes for each of a plurality of visit types, and at least one processing device configured to perform instructions stored in a memory causing the system to perform steps. The steps include: receive a per-visit intake record including data representative of a chief complaint and a history of a present illness (HPI) associated with a user visit; match the per-visit intake record to a visit type record of the plurality of visit type records in the visit template library based on a matching set of visit type attributes to data representative of the chief complaint and the HPI; identify a test attribute of the visit type record indicative of an applicable diagnostic test; identify an emergency attribute of the visit type record indicating that the chief complaint and the HPI form an emergency; update the per-visit intake record by appending a visit type identify identifying the visit type record; and cause to display a visit type interface representative of the visit type record on a screen of at least one computing device associated with at least one user of the user visit, including an indication of the emergency attribute and the test attribute. [0008] In some embodiments, the present disclosure provides a computer-based product having a non-transitory computer readable medium having stored thereon computer readable instructions configured to cause a processor to perform a computer-implemented method that includes at least the following steps of: receiving a per-visit intake record including data representative of a chief complaint and a history of a present illness (HPI) associated with a user visit; matching the per-visit intake record to a visit type record of a visit template library including a plurality of per-visit intake records based on a matching set of visit type attributes to data representative of the chief complaint and the HPI; identifying a test attribute of the visit type record indicative of an applicable diagnostic test; identifying an emergency attribute of the visit type record indicating that the chief complaint and the HPI form an emergency; updating the per-visit intake record by appending a visit type identify identifying the visit type record; and causing to display a visit type interface representative of the visit type record on a screen of at least one computing device associated with at least one user of the user visit, including an indication of the emergency attribute and the test attribute.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Various embodiments of the present disclosure can be further explained with reference to the attached drawings, wherein like structures are referred to by like numerals throughout the several views. The drawings shown are not necessarily to scale, with emphasis instead generally being placed upon illustrating the principles of the present disclosure. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ one or more illustrative embodiments.

[0010] FIGS. 1-39 show one or more schematic flow diagrams, certain computer-based architectures, and screenshots of various specialized graphical user interfaces which are illustrative of some exemplary aspects of at least some embodiments of the present disclosure.

DETAILED DESCRIPTION

[0011] Various detailed embodiments of the present disclosure, taken in conjunction with the accompanying figures, are disclosed herein; however, it is to be understood that the disclosed embodiments are merely illustrative. In addition, each of the examples given in connection with the various embodiments of the present disclosure is intended to be illustrative, and not restrictive.

[0012] Throughout the specification, the following terms take the meanings explicitly associated herein, unless the context clearly dictates otherwise. The phrases “in one embodiment” and “in some embodiments” as used herein do not necessarily refer to the same embodiment(s), though it may. Furthermore, the phrases “in another embodiment” and “in some other embodiments” as used herein do not necessarily refer to a different embodiment, although it may. Thus, as described below, various embodiments may be readily combined, without departing from the scope or spirit of the present disclosure.

[0013] In addition, the term "based on" is not exclusive and allows for being based on additional factors not described, unless the context clearly dictates otherwise. In addition, throughout the specification, the meaning of "a," "an," and "the" include plural references. The meaning of "in" includes "in" and "on." [0014] It is understood that at least one aspect/functionality of various embodiments described herein can be performed in real-time and/or dynamically. As used herein, the term “real-time” is directed to an event/action that can occur instantaneously or almost instantaneously in time when another event/action has occurred. For example, the “real-time processing,” “real-time computation,” and “real-time execution” all pertain to the performance of a computation during the actual time that the related physical process (e.g., a user interacting with an application on a mobile device) occurs, in order that results of the computation can be used in guiding the physical process.

[0015] As used herein, the term “dynamically” and term “automatically,” and their logical and/or linguistic relatives and/or derivatives, mean that certain events and/or actions can be triggered and/or occur without any human intervention. In some embodiments, events and/or actions in accordance with the present disclosure can be in real-time and/or based on a predetermined periodicity of at least one of: nanosecond, several nanoseconds, millisecond, several milliseconds, second, several seconds, minute, several minutes, hourly, several hours, daily, several days, weekly, monthly, etc.

[0016] As used herein, the term “runtime” corresponds to any behavior that is dynamically determined during an execution of a software application or at least a portion of software application.

[0017] In some embodiments, exemplary inventive, specially programmed computing systems and platforms with associated devices are configured to operate in the distributed network environment, communicating with one another over one or more suitable data communication networks (e.g., the Internet, satellite, etc.) and utilizing one or more suitable data communication protocols/modes such as, without limitation, IPX/SPX, X.25, AX.25, AppleTalk(TM), TCP/IP (e.g., HTTP), near-field wireless communication (NFC), RFID, Narrow Band Internet of Things (NBIOT), 3G, 4G, 5G, GSM, GPRS, WiFi, WiMax, CDMA, satellite, ZigBee, and other suitable communication modes. In some embodiments, the NFC can represent a short-range wireless communications technology in which NFC-enabled devices are “swiped,” “bumped,” “tap” or otherwise moved in close proximity to communicate. In some embodiments, the NFC could include a set of short-range wireless technologies, typically requiring a distance of 10 cm or less. In some embodiments, the NFC may operate at 13.56 MHz on ISO/IEC 18000-3 air interface and at rates ranging from 106 kbit/s to 424 kbit/s. In some embodiments, the NFC can involve an initiator and a target; the initiator actively generates an RF field that can power a passive target. In some embodiment, this can enable NFC targets to take very simple form factors such as tags, stickers, key fobs, or cards that do not require batteries. In some embodiments, the NFC’s peer-to-peer communication can be conducted when a plurality of NFC-enable devices (e.g., smartphones) within close proximity of each other.

[0018] The material disclosed herein may be implemented in software or firmware or a combination of them or as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any medium and/or mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), and others.

[0019] As used herein, the terms “computer engine” and “engine” identify at least one software component and/or a combination of at least one software component and at least one hardware component which are designed/programmed/configured to manage/control other software and/or hardware components (such as the libraries, software development kits (SDKs), obj ects, etc.). [0020] Examples of hardware elements may include processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, application specific integrated circuits (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate array (FPGA), logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. In some embodiments, the one or more processors may be implemented as a Complex Instruction Set Computer (CISC) or Reduced Instruction Set Computer (RISC) processors; x86 instruction set compatible processors, multi-core, or any other microprocessor or central processing unit (CPU). In various implementations, the one or more processors may be dual -core processor(s), dual-core mobile processor(s), and so forth.

[0021] Computer-related systems, computer systems, and systems, as used herein, include any combination of hardware and software. Examples of software may include software components, programs, applications, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computer code, computer code segments, words, values, symbols, or any combination thereof. Determining whether an embodiment is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints.

[0022] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium which represents various logic within the processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. Such representations, known as “IP cores” may be stored on a tangible, machine readable medium and supplied to various customers or manufacturing facilities to load into the fabrication machines that make the logic or processor. Of note, various embodiments described herein may, of course, be implemented using any appropriate hardware and/or computing software languages (e.g., C++, Objective-C, Swift, Java, JavaScript, Python, Perl, QT, etc ).

[0023] In some embodiments, one or more of illustrative computer-based systems or platforms of the present disclosure may include or be incorporated, partially or entirely into at least one personal computer (PC), laptop computer, ultra-laptop computer, tablet, touch pad, portable computer, handheld computer, palmtop computer, personal digital assistant (PDA), cellular telephone, combination cellular telephone/PDA, television, smart device (e.g., smart phone, smart tablet or smart television), mobile internet device (MID), messaging device, data communication device, and so forth.

[0024] As used herein, term “server” should be understood to refer to a service point which provides processing, database, and communication facilities. By way of example, and not limitation, the term “server” can refer to a single, physical processor with associated communications and data storage and database facilities, or it can refer to a networked or clustered complex of processors and associated network and storage devices, as well as operating software and one or more database systems and application software that support the services provided by the server. Cloud servers are examples.

[0025] In some embodiments, as detailed herein, one or more of the computer-based systems of the present disclosure may obtain, manipulate, transfer, store, transform, generate, and/or output any digital object and/or data unit (e.g., from inside and/or outside of a particular application) that can be in any suitable form such as, without limitation, a file, a contact, a task, an email, a message, a map, an entire application (e.g., a calculator), data points, and other suitable data. In some embodiments, as detailed herein, one or more of the computer-based systems of the present disclosure may be implemented across one or more of various computer platforms such as, but not limited to: (1) Linux, (2) Microsoft Windows, (3) OS X (Mac OS), (4) Solaris, (5) UNIX (6) VMWare, (7) Android, (8) Java Platforms, (9) Open Web Platform, (10) Kubemetes or other suitable computer platforms.

[0026] In some embodiments, illustrative computer-based systems or platforms of the present disclosure may be configured to utilize hardwired circuitry that may be used in place of or in combination with software instructions to implement features consistent with principles of the disclosure. Thus, implementations consistent with principles of the disclosure are not limited to any specific combination of hardware circuitry and software. For example, various embodiments may be embodied in many different ways as a software component such as, without limitation, a stand-alone software package, a combination of software packages, or it may be a software package incorporated as a “tool” in a larger software product.

[0027] For example, exemplary software specifically programmed in accordance with one or more principles of the present disclosure may be downloadable from a network, for example, a website, as a stand-alone product or as an add-in package for installation in an existing software application. For example, exemplary software specifically programmed in accordance with one or more principles of the present disclosure may also be available as a client-server software application, or as a web-enabled software application. For example, exemplary software specifically programmed in accordance with one or more principles of the present disclosure may also be embodied as a software package installed on a hardware device.

[0028] In some embodiments, illustrative computer-based systems or platforms of the present disclosure may be configured to handle numerous concurrent users that may be, but is not limited to, at least 100 (e.g., but not limited to, 100-999), at least 1,000 (e.g., but not limited to, 1,000-9,999 ), at least 10,000 (e.g., but not limited to, 10,000-99,999 ), at least 100,000 (e.g., but not limited to, 100,000-999,999), at least 1,000,000 (e.g., but not limited to, 1,000,000- 9,999,999), at least 10,000,000 (e.g., but not limited to, 10,000,000-99,999,999), at least 100,000,000 (e.g., but not limited to, 100,000,000-999,999,999), at least 1,000,000,000 (e.g., but not limited to, 1,000,000,000-999,999,999,999), and so on.

[0029] In some embodiments, illustrative computer-based systems or platforms of the present disclosure may be configured to output to distinct, specifically programmed graphical user interface implementations of the present disclosure (e.g., a desktop, a web app., etc.). In various implementations of the present disclosure, a final output may be displayed on a displaying screen which may be, without limitation, a screen of a computer, a screen of a mobile device, or the like. In various implementations, the display may be a holographic display. In various implementations, the display may be a transparent surface that may receive a visual projection. Such projections may convey various forms of information, images, or objects. For example, such projections may be a visual overlay for a mobile augmented reality (MAR) application. [0030] In some embodiments, illustrative computer-based systems or platforms of the present disclosure may be configured to be utilized in various applications which may include, but not limited to, gaming, mobile-device games, video chats, video conferences, live video streaming, video streaming and/or augmented reality applications, mobile-device messenger applications, and others similarly suitable computer- device applications.

[0031] As used herein, the term “mobile electronic device,” or the like, may refer to any portable electronic device that may or may not be enabled with location tracking functionality (e.g., MAC address, Internet Protocol (IP) address, or the like). For example, a mobile electronic device can include, but is not limited to, a mobile phone, Personal Digital Assistant (PDA), Blackberry ™, Pager, Smartphone, or any other reasonable mobile electronic device. [0032] As used herein, terms “proximity detection,” “locating,” “location data,” “location information,” and “location tracking” refer to any form of location tracking technology or locating method that can be used to provide a location of, for example, a particular computing device, system or platform of the present disclosure and any associated computing devices, based at least in part on one or more of the following techniques and devices, without limitation: accelerometer(s), gyroscope(s), Global Positioning Systems (GPS); GPS accessed using Bluetooth™; GPS accessed using any reasonable form of wireless and non-wireless communication; WiFi™ server location data; Bluetooth ™ based location data; triangulation such as, but not limited to, network based triangulation, WiFi™ server information based tri angulation, Bluetooth™ server information based triangulation; Cell Identification based tri angulation, Enhanced Cell Identification based triangulation, Uplink-Time difference of arrival (U-TDOA) based triangulation, Time of arrival (TOA) based tri angulation, Angle of arrival (AOA) based triangulation; techniques and systems using a geographic coordinate system such as, but not limited to, longitudinal and latitudinal based, geodesic height based, Cartesian coordinates based; Radio Frequency Identification such as, but not limited to, Long range RFID, Short range RFID; using any form of RFID tag such as, but not limited to active RFID tags, passive RFID tags, battery assisted passive RFID tags; or any other reasonable way to determine location. For ease, at times the above variations are not listed or are only partially listed; this is in no way meant to be a limitation.

[0033] As used herein, terms “cloud,” “Internet cloud,” “cloud computing,” “cloud architecture,” and similar terms correspond to at least one of the following: (1) a large number of computers connected through a real-time communication network (e.g., Internet); (2) providing the ability to run a program or application on many connected computers (e.g., physical machines, virtual machines (VMs)) at the same time; (3) network-based services, which appear to be provided by real server hardware, and are in fact served up by virtual hardware (e.g., virtual servers), simulated by software running on one or more real machines (e.g., allowing to be moved around and scaled up (or down) on the fly without affecting the end user). [0034] In some embodiments, the illustrative computer-based systems or platforms of the present disclosure may be configured to securely store and/or transmit data by utilizing one or more of encryption techniques (e.g., private/public key pair, Triple Data Encryption Standard (3DES), block cipher algorithms (e.g., IDEA, RC2, RC5, CAST and Skipjack), cryptographic hash algorithms (e.g., MD5, RIPEMD-160, RTRO, SHA-1, SHA-2, Tiger (TTH), WHIRLPOOL, RNGs).

[0035] The aforementioned examples are, of course, illustrative and not restrictive.

[0036] As used herein, the term “user” shall have a meaning of at least one user. In some embodiments, the terms “user”, “subscriber” “consumer” or “customer” should be understood to refer to a user of an application or applications as described herein and/or a consumer of data supplied by a data provider. By way of example, and not limitation, the terms “user” or “subscriber” can refer to a person who receives data provided by the data or service provider over the Internet in a browser session, or can refer to an automated software application which receives the data and stores or processes the data.

[0037] As used herein, the terms “and” and “or” may be used interchangeably to refer to a set of items in both the conjunctive and disjunctive in order to encompass the full description of combinations and alternatives of the items. By way of example, a set of items may be listed with the disjunctive “or”, or with the conjunction “and.” In either case, the set is to be interpreted as meaning each of the items singularly as alternatives, as well as any combination of the listed items.

[0038] Figures 1 through 39 illustrate systems and methods of the creation of electronic records and associated profiles, and filtering, matching and queuing these records and profiles. The following embodiments provide technical solutions and technical improvements that overcome technical problems, drawbacks and deficiencies in the technical fields involving the matching and analysis of electronic records and profiles. As explained in more detail, below, technical solutions and technical improvements herein include aspects of improved intelligent algorithm creation of electronic records with content-based tracking and analysis for more efficient matching and queuing of the electronic records with automated recommendations based on the electronic records. Based on such technical features, further technical benefits become available to users and operators of these systems and methods. Moreover, various practical applications of the disclosed technology are also described, which provide further practical benefits to users and operators that are also new and useful improvements in the art.

[0039] FIG. 1 is a block diagram of another exemplary computer-based system and platform automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0040] In some embodiments, user profiles may be matched to each other to put two or more users in communication with each other. However, in some embodiments, the matching may depend on one or more user’s needs. Such needs-based matching is a difficult and complex process due to a potentially large set of factors that may characterize the needs. Similarly, the needs may be associated with corresponding capabilities of another user being matched, which may also be complex. Moreover, the needs and capabilities may be dynamic or temporary. For example, a patient user may be matched to a healthcare provider user based on electronic records associated with the patient and a history of a present illness (HPI). In some embodiments, a telemedicine platform 100 is architected to efficiently record users’ needs and capabilities, and match electronic records and associated user profiles in a dynamic and efficient manner that prevents resource overhead and long matching periods, thus improving the matching and queuing of electronic records and profiles for more efficient profile routing. [0041] In some embodiments, the telemedicine platform 100 may automatically generate electronic records associated with users at, e.g., a user computing device 102. In some embodiments, users may access the telemedicine platform 100 using the user computing device 102 including, e.g., a mobile computing device such as a smartphone, tablet, PDA or other mobile device, or any other suitable computing device including a laptop, desktop computer, virtual machine, or other device. In some embodiments, the user computing device 102 communicates with the telemedicine platform 100 to generate electronic records, such as, e.g., electronic visit records associated with patient profiles, using a dynamic and algorithm generation process for more efficient and more accurate electronic record generation and queuing.

[0042] In some embodiments, a cloud platform 110 may be utilized to receive application programming interface (API) requests from the user computing device 102 via a cloud API 121. In some embodiments, the cloud API 121 may be one or more APIs or an API gateway, such as, e.g., the Amazon API Gateway™, however, other API collections are contemplated for interfacing with the cloud platform 110.

[0043] In some embodiments, the cloud platform 110 may include a system for instantiating one or more services related to the generation and routing of electronic records and profiles. For example, the cloud platform 110 may include a service for each distinct type of task or process associated with the generation and routing of electronic records and profiles. For example, the cloud platform 110 may include services associated with, e.g., dynamic algorithmic survey generation, automated record categorization, predictive recommendations related to the electronic records, automated and self-organizing queuing, among other services. In some embodiments, the cloud platform 110 utilizes services based on, e.g., a community cloud, a distributed cloud, a multicloud, a poly cloud, a big data cloud, a high-performance computing (HPC) cloud, or other cloud structure implemented as, e.g., a public cloud, private cloud or hybrid cloud. In some embodiments, the cloud platform 110 includes a serverless computing model where services are instantiated in, e.g., virtual machines to perform tasks for, e.g., software-as-a-service (SaaS), function-as-a-service (FaaS), or other operating model and combinations thereof. In some embodiments, cloud platform 110 is a serverless cloud computing platform, such as, e.g., Amazon Lambda™ or other suitable serverless cloud platform.

[0044] In some embodiments, the cloud platform 110 may instantiate services in containers that run as independent virtual machines. In some embodiments, the cloud platform 110 includes an image analysis container 111 that receives an image, e.g., form a lab test taken by a user at the user computing device 102, and automatically recognize the results using, e.g., image recognition models. In some embodiments, the lab results may be tracked and analyzed by a lab analysis container 112 instantiated by the cloud platform 110. In some embodiments the lab analysis container 112 determines and records, e.g., a medical condition associated with the recognized image. In some embodiments, the cloud platform 110 may instantiate additional containers. Each container may include, e.g., a container management service for manage and run, e.g., distributed applications in one or more containers, such as, e.g., Docker™ containers or other suitable containers. In some embodiments, each container may further include a worker instance for each task being performed by the associated service or application.

[0045] In some embodiments, the cloud platform 110 may be in communication with one or more storage devices for, e.g., persistent storage, database storage, task and process queuing, caching, buffering, among other storage services. For example, in some embodiments, the cloud platform 110 is in communication with a database 115 for maintaining, e.g., user profile data, electronic record data, lab test data, among other data. In some embodiments, the database 115 may include any suitable database system, such as, e.g., one or more storage devices (e.g., solid state drives, hard drives, magnetoresistive drives, flash storage, etc.), a server or server system, a distributed database, a centralized database, among other configurations and architectures, including, e.g., Amazon DynamoDB™ and other solutions. [0046] In some embodiments, the cloud platform 110 may be in communication with a persistent storage for access to data objects for use with tasks and processes instantiated by the cloud platform 110. Thus, the cloud platform 110 may be in communication with, e.g., an object storage system 116, such as, e.g., Amazon S3™ or other similar solution.

[0047] In some embodiments, to facilitate surfacing data for tasks and processes run by services in the cloud platform 110, an elastic search service 117 may be provided. In some embodiments, the elastic search service 117 is a service instantiated by the cloud platform 110, however in some embodiments, the elastic search service 117 is separate service in communication with the cloud platform 110 with access to the database 115 and the object storage 116. In some embodiments, services instantiated by the cloud platform 110 may utilize the elastic search service 117, such as, e.g., an Amazon ElasticSearch Service™, using, e.g., an appropriate API request to cause the elastic search service 117 to perform a search of the database 115 or object storage 116 or both to identify and return matching data, such as, e.g., records, profiles, lab data, data objects, state information, among others.

[0048] In some embodiments, services of the cloud platform 110 may utilize resources, such as the database 115, object storage 116 and elastic search service 117 concurrently with each other. Thus, sometimes the resources may be fully utilized by a subset of existing tasks. The remainder of the tasks may be queued for each respective resource by a queue service 118, such as, e.g., an Amazon Simple Queue Service™ or other suitable queue service to facilitate scheduling tasks on limited resources. For example, in some embodiments, data may be shared across containers and services instantiated by the cloud platform 110 by queuing the data for access to each other container or service to implement message queuing to eliminate the traditional overhead associated with operating in-house messaging infrastructures. These operating overheads include: unused capacity installed to meet peak demands, human resources that are necessary to maintain messaging infrastructure, projects idle time waiting for resource provisioning, and a need to isolate messaging resources. Besides reducing cost, the queue service 118 may simplify access to messaging resources and therefore facilitate integration efforts within organizations and between them. Thus, data may be shared amongst users via the queue service 118.

[0049] In some embodiments, containers instantiated by the cloud platform 110 may utilize medical information associated with the user at the user computing device 102 by accessing electronic medical records (EMR) at an EMR system 104. Accordingly, a user may interact with the telemedicine platform 100 using the user computing device 102 while leveraging EMR provided by the EMR system 104. For example, a user may utilize the cloud API 121 to call functionality from a container by the cloud platform 110. Details, such as data, user selections, responses to questions, among other details, may be communicated to the container, such as the lab analysis container 112 by a routing system 124. In some embodiments, the routing system 124 may communicated uploaded data to the lab analysis container 112, including user data, such as the aforementioned details, and the EMR from the EMR system 104 associated with the user.

[0050] In some embodiments, the routing system 124 may route data to containers instantiated byte cloud platform 110 over, e.g., the internet. Therefore, in some embodiments, the routing system 124 may utilize a domain name system (DNS) service and gateway to identifying internet protocol (IP) addresses associated with the target container or instance and route data to the target container or instance.

[0051] In some embodiments, the data from computing devices, such as the user computing device 102 or EMR system 104, may include messages routed by the routing system 124. In some embodiments, each message may include requests, such as, e.g., cloud API 121 requests, or instruction to applications instantiated in containers. Thus, the messages may utilize processor, storage and memory resources in the cloud platform 110 to respond to the requests or instructions. Accordingly, in some embodiments, based on the message received from the user computing device 102 and EMR system 104, the telemedicine platform 100 may provision resources to one or more containers of the cloud platform 110, such as the lab analysis container 112, using a load balancer 125.

[0052] Moreover, in some embodiments, the user computing device 102 and EMR system 104 may be provided with content to facilitate user interaction with the cloud platform 110. For example, graphical user interfaces (GUIs), images, videos, policies, among other static content stored in, e.g., a content storage 123. In some embodiments, each GUI screen is stored in the content storage 123 for quick and efficient access by applications access the telemedicine platform 100, such as, e.g., a web browser, a smartphone or tablet application, a desktop or personal computer application, or other software program.

[0053] Similarly, in some embodiments, an administrative computing device 106 may access the telemedicine platform 100 to administer configurations, security policies, among other administrative functions. The administrative computing device 106 may interface with the content storage 123 and the load balancer 125 to, e.g., receive content and interact with applications instantiated in containers as described above, as well as administer the content storage 123 and the load balancer 125. For example, the administrative computing device 106 may add, remove and modify content in the content storage 123, such as, e.g., to update the GUI displayed on a user computing device 102, modify alerts, notices and policies displayed to a user, among other changes to content. Similarly, the administrative computing device 106 may configure the load balancer 125 to adjust, e.g., resource and container priorities, including how tasks and processes are prioritized, among other load balancer 125 configuration settings. [0054] FIG. 2 illustrates a flowchart of an illustrative methodology of automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure. [0055] In some embodiments, a telemedicine platform, such as the telemedicine platform 100 described above, may include a cloud platform 110 as described above, having multiple services for automated user characteristic recognition and matching. In some embodiments, to efficiently receive user data for automated profile generation, characterization and matching, the cloud platform 110 may utilize an intake service 220 with automated triage service 230, a test analysis service 260, a recommendation service 240 and a self-organized queue service 250. Each service may store and retrieve data from a data storage system 270 including, e.g., the database 115 and the object storage 116 described above. In some embodiments, the data storage system 270 maintains data regarding, e.g., template libraries, user records, user data, medical condition information, among other data and data objects.

[0056] In some embodiments, the intake service 220 generates a comprehensive, algorithmic and dynamic graphical user interface (GUI) that presents an algorithm questionnaire tailored to a user’s input. Based on an initial selection by a user, the intake service 220 may generate a series of follow-up questions, e.g., in the form of additional or dynamically modified GUI screens. Furthermore, as the intake service 220 receives user selections in response to the follow-up questions, the intake service 220 may generate additional, modified, or different follow-up questions, dynamically according to attributes and characteristics associated with the user.

[0057] In some embodiments, the intake service 220 implements a catalog-based approach to dynamic GUI generation. For example, a server, such as, e.g., the database 115 or the object storage 116 of the data storage system 270, or the static content storage 123 described above, may maintain the algorithms and a catalog of GUI sets for dynamic delivery to a user device, such as the user computing device 102 described above. For example, in some embodiments, the GUI sets include a screen or sequence of screens to display, e.g., via a mobile application, personal computer application, web browser, or other delivery mechanism, with medical history and history of present illness questions for a user. As the user selects or enters responses to questions of the dynamic GUI, subsequent questions may be determined based on the responses to intelligently determine and surface pertinent questions to the user’s state. Thus, irrelevant questions can be avoided, reducing communication bandwidth and computational resources while also reducing time and effort on the part of the user.

[0058] In some embodiments, the intake service 220 may store the user selections and/or response in the data storage system 270 to update the user’s profile by adding the selections and responses to the user’s medical history and to the user’s history of the present illness associated with the present intake process. In some embodiments, each user response is stored in the user’s profile in the data storage system 270 concurrently with the user selecting the response. However, in some embodiments, the user selections and responses are cached, e.g., in a cache of the cloud platform 110, and uploaded as a batch at the end of an intake session to update the user’s profile. An intake session may commence upon the intake service 220 being called, and may end upon the user completing the GUI sets or the user exiting the intake session.

[0059] In some embodiments, the intake service 220 includes an automated triage service 230 to automatically predict resources needed to address the user’s responses to questions. For example, in some embodiments, based on the user responses to the dynamic GUI of the intake service 220, the automated triage service 230 may determine a type of visit for which the user is engaging the cloud platform 110. In some embodiments, the automated triage service 230 may take into account user responses to the algorithmically generated dynamic GUI, as well as a user profile (e.g., medical history), a user location, and contextual information such as epidemiological information (e.g., the presence of epidemics, increased rates of contagious diseases, among other epidemiological information), among other data. In some embodiments, the information is compared to, e.g., visit type entries in, e.g., an index, look-up-table, catalog, or other data structure to determine a match and identify a visit type for the user.

[0060] In some embodiments, some visit types may include a data item indicating a diagnostic test appropriate for the visit type. For example, in some embodiments, a “flu” visit type may include a flu test strip, a “strep throat” visit type may include a strep test, among other visit types and associated tests. In some embodiments, where the automated triage service 230 identifies a visit type having an associated test, the automated triage service 230 may call, e.g., via an appropriate API, a test analysis service 260. In some embodiments, the automated triage service 230 may initially present a GUI to the user via the user computing device with an option to select whether the user has a test ready to upload. Where the user does have such a test, the automated triage service 230 may call the test analysis service 260. Where the user does not have such a test, the automated triage service 230 may skip the test analysis service 260 and call the recommendation service 240, or recommend via a GUI that the user take such a test and save the user’s progress (e.g., the answers provided by the user to the intake service 220) in the data storage system 270 so that the user may return and continue the visit with the diagnostic test at a later time.

[0061] In some embodiments, the test analysis service 260 may receive an image for the diagnostic test and automatically identify test results based on the received image. For example, a user may be prompted by a GUI of the test analysis service 260 to either capture or upload an image of the test device. In some embodiments, the test analysis service 260 may utilize an image recognition algorithm, such as, e.g., a machine learning algorithm with feature extraction, including, e.g., a neural network (e.g., a convolutional neural network (CNN), a recurrent neural network (RNN), or other neural network), or other classifier algorithm, to classify the results of the test based on the image (e.g., positive or negative). In some embodiments, upon classifying the test results, the test analysis service 260 may store the test results and the associated image in the data storage system 270 to update the user’s profile by adding the test results and image to the user’s medical history and/or history of the present illness.

[0062] In some embodiments, where the test analysis service 260 is called by the automated triage service 230, the test analysis service 260 may call the recommendation service 240 upon classification of the test results. However, in some embodiments, where the visit type determined by the automated triage service 230 does not include a diagnostic test, the test analysis service 260 may be skipped, and the automated triage service 230 or the intake service 220 may call the recommendation service 240.

[0063] In some embodiments, the recommendation service 240 utilizes the user profile stored in the data storage system 270, including the history of present illness (HPI) generated according to user selections in response to the dynamic GUI of the intake service and the visit type determined by the automated triage service 230, including any applicable tests classified by the test analysis service 260, to predict recommended treatment options. In some embodiments, the recommendation service 240 may recognize, e.g., via tags or metadata, types of HPI information, such as, e.g., chief complaint, symptoms, symptom details (e.g., duration, severity, etc.), medical history, medications, among other HPI information and medical history information. In some embodiments, the recommendation service 240 may automatically determine the different types of HPI information. For example, the intake service 220 may label, e.g., via metadata including embedded flags or tags, to signify a type of HPI information assigned to responses associated with each question during intake. In some embodiments, however, the recommendation service 240 may automatically classify each type of HPI information using, e.g., a recognition algorithm, such as, e.g., a text parsing algorithm, a machine learning classification algorithm, an index or look-up table, or other recognition technique and combinations thereof. [0064] In some embodiments, based on the HPI received from the intake service 220 and test analysis service 260, as well as the recommended visit type from the automated triage service 230, the recommendation service 240 may predict a most likely condition or set of conditions along with associated recommended treatments. In some embodiments, the recommendation service 240 may compare the HPI to, e.g., an index or look-up table of having diseases and conditions classified by HPI, such as, e.g., signs and symptoms, complaints, social circumstances, abnormal findings, external causes of injury or diseases, among other factors and combinations thereof. In some embodiments, the recommendation service 240 may access the index in the data storage system 270, or the recommendation service 240 may maintain a cache of the index in a local storage or memory.

[0065] In some embodiments, the index or look-up table may include structured data to facilitate comparing received HPI with the disease and condition classifications, such as, e.g., medical classification codes including, e.g., the International Statistical Classification of Diseases and Related Health Problems (ICD), the Diagnostics and Statistical Manual of Mental Disorders (DSM), international Classification of Sleep Disorders (ICSD), Online Mendelian Inheritance in Man, among other health-related classification codes. In some embodiments, the classification code or codes may be extracted from an external source (e.g., the ICD-10), and formatted into the structured data of the index for use by the recommendation service 240. In some embodiments, the classification code or codes may be automatically parsed into structured data form using, e.g., a text parsing algorithm to automatically identify a disease entry, and associated, e.g., signs and symptoms, complaints, social circumstances, abnormal findings, external causes of injury or diseases, among other factors and combinations thereof as set forth in the classification code or codes.

[0066] In some embodiments, using the index, the recommendation service 240 may compare the received HPI with each disease entry in the index to match, e.g., signs and symptoms, complaints, social circumstances, abnormal findings, external causes of injury or diseases, among other factors and combinations thereof. In some embodiments, exact matches may not be available. Thus, in some embodiments, the recommendation service 240 may score each partial match according to, e.g., a sum or weighted sum of a number of HPI factors (e.g., signs and symptoms, complaints, social circumstances, abnormal findings, external causes of injury or diseases, among other factors and combinations thereof) that match a given disease entry of the index. In some embodiments, the recommendation service 240 may produce a recommendation including the matching disease entry or the most likely to match disease entry or entries based on the score. In some embodiments, the recommendation may include, e.g., an ordered list of the top matching disease entries, such as the top 2, top 3, top 5, top 10 or other number of highest scoring disease entries.

[0067] In some embodiments, the recommendation service 240 adds the recommendation to the user’ s profile and updates the user account in the data storage system 270 with the updated user’s profile. The user’s profile is then passed to the self-organized queue service 250 to matching the user with an appropriate provider. In some embodiments, the self-organized queue service 250 enters a user into a virtual waiting room, e.g., hosted in the cloud platform 110. In some embodiments, the virtual waiting room includes a pool of user profiles for all users engaging with the cloud platform 110 to match with providers. In some embodiments, provider profiles associated with each provider engaging with the cloud platform 110 are also assigned to the virtual waiting room. Each provider profile may include, e.g., provider characteristics such as medical capabilities (e.g., area of specialty, years of experience, age levels each provider is qualitied to treat, languages, active licenses) as well as location and other characteristics. Thus, in some embodiments, a provider may sign in to an account on the cloud platform 110 and receive patients assigned by the self-organized queue service 250. [0068] In some embodiments, the user profile is assigned or entered into the virtual waiting room upon initiation of the intake service 220. For example, upon creation of a per-visit profile including the user responses to the intake service 220, the visit type assigned by the automated triage service 230, the test results from the test analysis service 260 and the recommended conditions from the recommendation service 240, the per-visit profile may appended with a time-stamp interpretable by the self-organized queue service 250 as the time of entry into the virtual waiting room. In some embodiments, user profiles in the virtual waiting room are ordered according to time of entry, where an earlier time of entry results in a higher priority or earlier position in a queue before user profiles with a later time of entry.

[0069] In some embodiments, the virtual waiting room queues user profiles according to available providers. In some embodiments, the self-organized queue service 250 matches each user profile with a matching provider profile. Based on, e.g., the chief complaint of the user profile as determined by the intake service 220, the visit type as determined by the automated triage service 230, the recommended condition and treatment determined by the recommendation service 240, or a combination thereof, the self-organized queue service 250 determines a set of capabilities matching the user profile. Using the matching capabilities, the self-organized queue services 250 identifies provider profiles having the matching capabilities. Therefore, the self-organized queue service 250 may then place the user profile in a queue associated with each provider profile having the matching capabilities, ordered according to time of entry. In some embodiments, to enter a user profile into a given queue, a link to the user profile may be generated and added to, e.g., an ordered list of links for user profiles for each provider profile having the matching capabilities. As a result, in some embodiments, each provider may be presented, e.g., at a user computing device 102, with a user interface showing a provider-specific queue of patients ordered according to time of entry. [0070] In some embodiments, a provider may selected next patient in the queue according to a next most recent time of entry. Upon selection, the self-organized queue service 250 may automatically call a teleconference service 280 to initiate a teleconference session between the provider and a user associated with the selected user profile using, e.g., text chat, video chat, voice chat, email, or other communication mechanism. In some embodiments, upon the selection, the self-organized queue service 250 may clear the user profile from queues in other provider-specific queues that match the user profile, thus moving up the following user profiles in the order of the other provider-specific queues.

[0071] In some embodiments, the teleconference service 280 may record data related to the teleconference session, such as, e.g., chat logs, time stamps, notes entered by the provider, tests and treatments prescribed and taken, among other information produced during the teleconference session. In some embodiments, the data may be appended to the user profile and stored in the account of the associated user in the data storage system 270. In some embodiments, the data is appended to the visit specific profile, which may be stored in the user’s account as a stand-alone record, however, the data of the visit specific profile may be added to an omnibus user profile having data from all visit specific profiles recorded therein. Thus, a user’s account in the data storage system 270 may maintain a record of visits, including illnesses with associated HPI information, tests and test results, medical histories, among other data.

[0072] Accordingly, the cloud platform 110 for an efficient system for filtering user profiles to match with provider profiles. Using the dynamically and algorithmically generated GUIs by the intake service 220, extraneous and irrelevant data may be reduced to reduce bandwidth, data processing and memory usage, while the automated triage service 230 and recommendation service 240 provide for intelligent classification and characterization of visit specific user profiles for more accurate more efficient filtering and queuing. Moreover, the self-organized queue service 250 enables efficient, centralized matching of profiles for automatic connection via the teleconference service 280 that facilitates user profile entry into multiple parallel queues across a diverse range of providers with diverse capabilities for flexible and consistent matching such that each provider profile may have a unique set of user profiles matched therewith based on the unique capabilities associated with each provider profile.

[0073] FIG. 3 illustrates a flowchart of an illustrative methodology of algorithm record generation for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0074] In some embodiments, an intake service 220, such as the intake service 220 of the cloud platform 110 described above, may efficiently and accurate identify relevant visit-specific data associated with a user visit with a healthcare provider via the cloud platform 110. In some embodiments, the intake service 220 may, therefore, receive a visit request 321 to create an intake record 329 based on per-visit intake responses and a user profile 328 during active encounter.

[0075] In some embodiments, the intake service interacts with a user computing device (e.g., the user computing device 102 described above), via, e.g., a web browser or native application to remotely serve content to the user computing device upon API requests. Therefore, in some embodiments, a GUI may be generated at the user computing device via, e.g., a GUI delivery mechanism such as the web browser, native application, progressive web application (PWA), or other form of application stored and installed on the user computing device. In some embodiments, a cloud platform (e.g., the cloud platform 110 described above) may maintain the code and data for generating the GUI at the user computing device, such as, e.g., user interface elements, including virtual buttons, toggles, menus, icons, etc., as well as data including selection options, links, actions, etc. rather than at the user computing device for easier, more efficient updating and modifying of the GUI. However, maintaining the GUI within an application on the user computing device is also contemplated, e.g., using a native application, a progressive web application (PWA), or other form of application stored and installed on the user computing device.

[0076] In some embodiments, the intake service 220 receives the visit request 321 from a user computing device (e.g., the user computing device 102 described above). In some embodiments, receiving the visit request 321 triggers the intake service 220 to prompt the user for a chief complaint selection. The prompt may include generating at the user computing device, e.g., the GUI including suitable elements for facilitating selection from one of a variety of possible chief complaints at block 322. In some embodiments, the GUI may include a multiple choice selection of, e.g., virtual buttons, or other virtual interface element for selecting an option. In some embodiments, the user may select a checkbox associated with a chief complaint option and then press a “Submit” virtual button. Other methods of selecting a chief complaint option are contemplated.

[0077] In some embodiments, the user selection of the chief complaint at the chief complaint selection 322 may trigger the intake service 220 to create an active encounter at block 323, e.g., via an active encounter API request to the cloud platform. In some embodiments, the intake service 220 instantiates an active encounter to dynamically prompt the user via the GUI with requests for selections related to a history of a present illness by first checking whether a user profile is available at a condition check 324. In some embodiments, information represented by data stored in a user profile may be used during the active session as a basis for dynamic prompts via the GUI. For example, medical history, demographics, height, weight, among other data may be used to identify a next prompt in a series of dynamically generated prompts. Thus, in some embodiments, the intake service 220 may generate, e.g., a profile API request associated with the user to search an account database, e.g., maintained the data storage system 270 described above, for an associated user profile in connection with the user’s account. [0078] In some embodiments, the intake service 220 identifies, via a return from the account database, that a user profile does not exist or is otherwise incomplete. Thus, in some embodiments, the intake service 220 may present to the user, e.g., via the GUI on the display of the user computing device, a user profile template. In some embodiments, the template may include a series of prompts in separate screens of the GUI for information related to the user and the user’s medical history, however, in some embodiments, the template is a scrolling page of fields for user input.

[0079] In some embodiments, upon response to the template by, e.g., selecting or inputting information into the template, a user’s profile responses are received by the intake service 220. In some embodiments, upon each selection or input via the GUI as the user computing device, the user computing device may transmit data representing the user responses to the intake service 220. In some embodiments, the data is transmitted upon a user selecting a submit button, thus causing a profile response API to communicate the input response to the intake service. In some embodiments, some or all of the responses may be a selection from options. Upon selection of one of the options, the profile response API may return the selection. Other techniques for uploading the data representing the user responses to the profile prompts are contemplated, and combinations thereof.

[0080] In some embodiments, the responses to the profile prompts causes the generation of a user profile 328. In some embodiments, the intake service 220 uses the user profile 328 in the active session in generating intake prompts to the user. For example, in some embodiments, the active session may dynamically surface a series of prompts for input at the user computing device, where each prompt includes interface elements for selecting one or more items of a list of characteristics related to the chief complaint selected at block 322. As a response to each prompt is received, the intake service 220 may direct the active session to determine a next prompt or set of prompts based on the previously received responses, the chief complaint, the user profile or a combination thereof.

[0081] In some embodiments, upon selection by a user of an option in a prompt served by the intake service 220, the response by may be communicated back to the intake service 220. In some embodiments, when the intake service 220 receives the per-visit intake responses at block 325, the responses may be provided back to the active session instantiated at block 323. As a result, the intake service 220 can utilize the active session to generate a next prompt or next set of prompts for user selection.

[0082] In some embodiments, the intake service 220 may aggregate the per-visit intake responses to create a per-visit intake record 329, at block 326, storing data representative of the per-visit intake responses. In some embodiments, a first per-visit intake response is converted into a data format structured to represent the first per-visit intake response in a machine-readable fashion, e.g., in a table, encoded according to a suitable encoding technique, or other method and combinations thereof. In some embodiments, each subsequent per-visit intake response after the first per-visit intake response may be appended to the per-visit intake record 329 to form a complete record of the intake process, including user selections of, e.g., the chief complaint, signs and symptoms, descriptors of the condition (e.g., severity), duration of the condition, medications, among others, to form a history of the present illness. However, in some embodiments, each response is cached, either at the user computing device or by the intake service 220 of the cloud platform, or both, and then aggregated into the per-visit intake record 329 upon completion of the per-visit intake responses.

[0083] In some embodiments, the intake record 329 may be stored with the user profile 328 in the account associated with the user. Accordingly, a user’s account may include profile information, as well as a history of per-visit intake records 329 for each visit to the cloud platform.

[0084] FIG. 4 illustrates a flowchart of an illustrative methodology of algorithmic record filtering for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0085] In some embodiments, an intake service (e.g., the intake service 220 described above) utilizes an active encounter 323 to dynamically surface GUIs to a user a user computing device via a display. Static intake formats results in intake prompts that are predetermined and used for most or all scenarios. However, such intake formats may include intake prompts that are not pertinent to a given user at a particular time or not specific enough to provide predictive or actionable data. Thus, surfacing the non-pertinent intake prompts and processing the user responses or selections wastes processing resources, including, e.g., processor cycles, processor time-share, memory consumption and bandwidth, and communication bandwidth. Moreover, the static intake formats occupies more time of the user to fill out every intake prompt, thus extending user intake and bottlenecking matching with a provider. Using more general intake prompts reduce the quantity of intake prompts results in user intake with less predictive power and less actionable data. Instead, in some embodiments, the active encounter 323 analyzes a user’s chief complaint, as well as any prior intake responses and selections during the active encounter 323 to determine a next intake prompt to surface to the GUI at the user computing device. In some embodiment, the active encounter 323 leverages an intake template library 436 maintained in the data storage system 270 to facilitate this dynamic intake prompt generation.

[0086] In some embodiments, the active encounter 323 presents a prompt at the user computing device including a chief complaint inquiry at block 421. In some embodiments, the chief complain inquiry includes selectable user interface elements representing a variety of illness symptoms, such as, e.g., runny nose, nausea, headache, cold symptoms, flu symptoms, pink eye symptoms, sore throat, rash and allergy symptoms, urinary symptoms, ear aches, dental symptoms, among other chief complaints.

[0087] In some embodiments, the selectable user interface elements may include a virtual button, that upon selection by a user, communicate data associated with the selection to, e.g., the intake service 220 of the cloud platform 110. In some embodiments, the selectable user interface elements may include checkboxes associated with each chief complaint option, which may be selected and communicated to the, e.g., intake service 220 of the cloud platform 110 upon user selection of a submit button or other virtual button in the GUI. In some embodiments, the data associated with the selected chief complaint may be communicated to the intake service 220 via an API or other data communication technique across a network to server or a cloud platform instantiating the intake service 220.

[0088] In some embodiments, the active encounter 323 receives the chief complaint selection at block 422. In some embodiments, the chief complaint selection includes a data object, such as, e.g., a variable, a programming object in, e.g., JSON or other database language, or other data obj ect to indicate that the data obj ect is a chief complaint and includes a particular selection of the chief complaint options. Thus, the active encounter 323 may receive the data object associated with the chief complaint selected by the user.

[0089] In some embodiments, using the user selection represented by the data object, the active encounter 323 may generate a next question set at block 423. In some embodiments, the next question set may include one or more user selectable prompts to elicit information regarding characteristics of the chief complaint. Thus, the user may be guided through a history of a present illness without irrelevant questions that may otherwise occupy computational resources and communication bandwidth. [0090] In some embodiments, the next set question or set of questions is determined based on previous responses, including the selected chief complaint. For example, in some embodiments, a catalog-based approach is used to dynamically surface questions via GUI prompts to a user computing device. In such an example, the previous responses are compared to an intake algorithm and an intake template library 426 stored in the data storage system 270. For each set of questions surfaced, the intake template library 426 has a set of possible follow up questions or question sets according to the intake algorithm. Thus, for example, upon selecting a chief complaint, the active encounter 323 employs the intake algorithm to select one of a group of chief complaint follow-up question sets. Based on the chief complaint follow up question set determined, and the user responses to the chief complaint follow-up question set, the active encounter 323 may employ the intake algorithm to select form the intake template library 426 a subsequent question set. The next question set may be generated with the intake algorithm at block 423 each time the active encounter 323 receives user input responding to the generated question set at block 424. Thus, the intake questions presented to the user may be iteratively determined at each set of questions selected from the intake template library 426 based on user selections to previous question sets and the chief complaint.

[0091] Accordingly, in some embodiments, the active encounter 323 employs the intake algorithm in conjunction with the intake template library 426. In some embodiments, the intake template library 426 includes template question sets, e.g., labeled with a respective question set identifier for each question set. In some embodiments, the intake algorithm may automatically receive as input the question set identifiers already presented to the user, as well as the user selections in response to the already presented question sets, and determine a next question set identifier. For example, a table or index may associated question set identifier-user selection combinations with a respective next question set. However, in some embodiments, each question set may include, e.g., metadata setting forth conditions for selection including previously presented question set identifier-user selection combinations. Alternatively, the algorithm may be coded as conditionals in a software program code using explicitly coded logic. The intake algorithm may therefore match the next question set identifier to a question set identifier in the intake template library 426 to identify the next question set for presentation to the user.

[0092] In some embodiments, the intake template library 426 includes a full set of questions for each possible chief complaint selection, thus forming an intake template for chief complaint follow-up. However, in some embodiments, the intake template library 426 may include multiple intake template portions for each chief complaint selection such that multiple successive intake question sets from the intake template portions may be generated based on user selections to previous intake template portions.

[0093] In some embodiments, the intake algorithm includes hard coded rules for matching previous question sets and associated responses with a predetermined next question set. Thus, the intake algorithm may have a predefined sequence of questions for all possible combinations of question sets and responses. However, in some embodiments, the intake algorithm may include a machine learning algorithm to correlate chief complaint and question set responses to a predicted next question or question set of the questions in the intake template library 426. Such an intake machine learning algorithm may include, e.g., a classifier including, e.g., a convolutional neural network, artificial neural network, deep neural network, support vector machine, random forest, decision trees, multilayer perceptron, or other machine learning classifier algorithm.

[0094] In some embodiments, the active encounter 323 may aggregate the user responses for intake at block 425 to create the per-visit intake record 329. In some embodiments, the active encounter may store data representative of the intake responses in, e.g., a data log associated with the user. In some embodiments, each intake response is converted into a data format structured to represent the intake responses in a machine-readable fashion, e.g., in a table, encoded according to a suitable encoding technique, or other method and combinations thereof. In some embodiments, each subsequent per-visit intake response after a first per-visit intake response may be appended to the per-visit intake record 329 to form a complete record of the intake process, including user selections of, e.g., the chief complaint, signs and symptoms, descriptors of the condition (e.g., severity), duration of the condition, medications, among others, to form a history of the present illness. However, in some embodiments, the active encounter 323 caches each response, either at the user computing device or by the intake service 220 of the cloud platform, or both, and then aggregates the cached responses into the intake record 329 upon completion of the per-visit intake responses.

[0095] In some embodiments, the intake record 329 may be stored with the user profile in the account associated with the user, e.g., in the data storage system 270 Accordingly, a user’s account may include profile information, as well as a history of intake records 329 for each visit to the cloud platform.

[0096] FIG. 5 illustrates a flowchart of an illustrative methodology of algorithmic record generation for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0097] In some embodiments, matching user profiles can be a difficult and inefficient process due to potentially large numbers of users. The more potential matches that there are, the more duplication of tasks is needed by queuing users more times and generating more notifications, alerts, prompts, and other communications. Moreover, greater potential matches may increase the likelihood of false positive matches that may need to be mitigated, further increasing computation resource consumption. However, in some embodiments, potential matches between users may be filtered through predictive categorization of users. For example, for patient users, predictively identifying a type of medical visit for which the patient users are engaging with the cloud platform (e.g., cloud platform 110 described above), may facilitate more quickly and accurately matching the patient users with provider users based on provider users similarity to the categorization (e.g., medical certifications for types of medical visits, etc.). Thus, time and resources can be reduced through intelligent, predictive categorization of user visit types.

[0098] In some embodiments, an automated triage service 230 predicts the recommended visit type according to user intake responses, e.g., received from the intake service 220 described above. In some embodiments, the automated triage service 230 receives the user intake responses at block 531, e.g., via a suitable triage service API call with the intake response data as recorded in the intake record 329. In some embodiments, the automated triage service 230 may utilize the intake responses to identify a most likely visit type, a matching clinical test, an emergency medicine recommendation, among other visit characteristics for the user based on the user’s responses to intake questions.

[0099] In some embodiments, the automated triage service 230, upon reception of the intake responses, implements a matching algorithm to match intake response to visit types at block 532. The intake response may form a history of a present illness (HPI). In some embodiments, the matching algorithm may include a set of, e.g., logical rules for associated combinations of the chief complaint and HPI to a set of visit types set forth in the visit template library 537. In some embodiments, however, the matching algorithm may utilize, e.g., a machine learning classifier, such as those described above, to classify a visit as a visit type of the visit template library 537 based on the chief complaint and user responses.

[0100] In some embodiments, the visit type may have an associated visit template in the visit template library 537 stored in the data storage system 270. The visit template may identify features of each visit type, such as, e.g., appropriate clinical tests, conditions for identifying an emergency, medical expertise related to the visit, among other characteristics. Thus, in some embodiments, the automated triage service 230 may use the visit template associated with the identified matching visit type to determine whether the matching visit type includes a test at block 533. Where the matching visit type does include a test, the automated triage service 230 may automatically call, e.g., via an API, the test analysis service 260.

[0101] However, where the matching visit type does not include a test, the automated triage service 230 may then determine whether the intake responses for the matching visit type indicate an emergency at block 534. For example, the automated triage service 230 may analyze, e.g., listed characteristics in the visit template, where if a threshold number of the characteristics are met by the intake responses, an emergency is determined. In some embodiments, the threshold number may be about, e.g., 70%, 75%, 80%, 85%, or 90% of the characteristics, or other suitable percentage. In some embodiments, where an emergency is determined, the automated triage service 230 may surface a recommendation to receive emergency care at block 536. For example, the automated triage service 230 may cause the GUI at the user computing device to display a warning message with the recommendation and, e.g., best contact information for emergency care or other suggestions (e.g., nearest hospital, ambulance contact information, etc.).

[0102] However, where an emergency is not indicated, the automated triage service 230 may report the visit type at block 535 by, e.g., recording the matching visit type in the intake record 329 associated with the intake responses. For example, the automated triage service 230 may append a record or log entry to the intake record 329 including the visit type. In some embodiments, the automated triage service 230 modifies the metadata of the intake record 329 to include a tag identifying the visit type. Other techniques for reporting and recording the visit type are contemplated. The intake record 329 with the record of the visit type may then be stored in the data storage system 270 to update the user’s intake record. [0103] FIG. 6 illustrates a flowchart of an illustrative methodology of lab-test record generation for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0104] In some embodiments, a user visit with the cloud platform (e.g., cloud platform 110 described above), may include a recommended clinical test related to the visit type. However, analysis of test results may depend on a variety of factors that not easily perceivable or distinguishable. For example, simply uploading an image of test results may cause artifacts, such as resolution and color artifacts that make interpretation of the test result difficult. Thus, in some embodiments, the cloud platform includes the test analysis service 260 to automatically receive and compensate for coloring, scaling, resolution, and other variations in images of the test results, such as, e.g., images of color test strips for positive/negative testing of conditions. [0105] Accordingly, in some embodiments, the test analysis service 260 may receiving an image of, e.g., a rapid test strip at block 661. In some embodiments, the rapid test strip is marked with a visit code, or the user may input into a test analysis GUI at the user computing device the visit code. As such, upon reception of the image and the visit code, the test analysis service 260 may link the image to the visit record (e.g., intake record 329 described above). [0106] In some embodiments, the test analysis service 260 may first validate the visit code at block 662 to ensure an open visit exists associated with the test. In some embodiments, the visit code is compared to intake records that are open (e.g., submitted to a virtual waiting room, as described above, but not yet selected by a provider). For example, in some embodiments an intake record may include a waiting room indicator that indicates that the intake record is submitted to the virtual waiting room. The waiting room indicator may be present where the intake record has been submitted by the intake service (e.g., intake service 220 described above) and removed upon, e.g., a user cancellation of a visit, a period of inactivity has elapsed where the user has failed to complete any remaining intake steps, or a visit has completed (e.g., by meeting with a provider), among other possible actions and combinations thereof.

[0107] In some embodiments, once validated, the test analysis service 260 may perform test recognition at block 663 on the rapid test associated with the visit code. In some embodiments, the rapid test can include, e.g., a test strip with a color-varying patch to indicate a presence of an analyte, such as with a test line, and, optionally, a control line to indicate the presence of a particular antigen of interest based on the visit type. In some embodiments, the biologic analyte 106 may be any biologic needed for use in the immunoassay, such as urine, blood, saliva, stool, sweat, or other biologies to be used as an analyte. Various methods may be used to acquire the needed biologic, and such may be provided to the user packaged with the test, such as swabs, vials, containers, dilutants and other solutions, or any other equipment required. In the case of a blood analyte, a few drops of blood may be obtained from a finger stick using a finger prick device. Such a blood analyte may be blood mixed with an adequate amount of buffered solution to create the sample analyte or a blood sample that is not diluted or otherwise manipulated, in which case the blood only is the analyte.

[0108] In some embodiments, the rapid test may include a conjugate pad with various reagents associated with a particular antigen associated with the visit type and the condition being tested for, such as a virus, allergen, or bacteria, the reagents being items such antibodies, enzymes, or other reagents needed to diagnose the particular condition. The reagent in the conjugate pad may be conjugated with particles of materials such as colloid gold or colored latex beads. As the analyte migrates through the conjugate pad, antibodies present in the sample analyte complex with the reagents in the conjugate pad, thereby creating an immune complex that will migrate to the test zone or test line.

[0109] In some embodiments, the test line may be precoated with the relevant antigen in question, i.e., a virus, allergen, or bacteria, for the detection of antibodies associated with the particular antigen. The immune complex created when the analyte passes through the conjugate pad is captured onto the antigen contained on the test line. This may create a qualitative response on the strip where the test line is located, such as a colored response. In some embodiments, the test line may not be a line, but may be other shapes or symbols, such as a plus sign. If no antigen -anti -antigen complexes are present in the analyte, no reaction occurs in the test line and a qualitative response will not occur.

[0110] In some embodiments, after passing through the test line, the analyte may migrate further along the strip to reach a control line, where excess anti-antibody-colloidal gold or latex conjugates get bound. A qualitative response may be shown at the control line, indicating that the sample has adequately migrated across the testing membrane or substrate as intended. It will be understood that the control line is not necessarily needed to perform the test, and may be eliminated entirely, but the control line does provide a comparative example. For example, the control line 112, in embodiments where a colored qualitative response is provided, may appear as an overly saturated color, such as a dark or bright saturated red, once the sample reaches the control line. This saturated color may be used as a comparison against the qualitative response shown on the test line. For example, if the qualitative response shown on the test line is a much lighter red than that on the test line, it may be that very little reaction occurred at the test line. Of course, if no response is shown at all at the test line, no reaction has occurred. If the qualitative response at the test line is of a similar saturation to the control line, a strong reaction is indicated.

[0111] In some embodiments, the test recognition at block 663 includes an image recognition algorithm to identify the results of the test based on the presence and color of the test line and/or control line. In particular, in some embodiments, the test analysis service 260 identifies the test strip, including, e.g., the test line and/or control line, using a suitable feature detection mechanism. For example, the test analysis service 260 may perform edge detection to detect the presence of particular shapes and arrangements of shapes, such as, e.g., shapes associated with the test line, control line, test strip, and testing device, including arrangements of each of the aforementioned shapes relative to each other. Accordingly, the test analysis service 260 may identify the test line and/or control line within the image of the rapid test.

[0112] In some embodiments, the test analysis service 260 may analyze the image of the test line and/or control line to determine test results at block 664. In some embodiments, the test analysis service 260 may utilize an image recognition algorithm to interpret, e.g., the detected shapes and colors of formed by pixels in the image of the rapid test. For example, the image may be processed to determine a result based on the severity of the reaction occurring on the test strip test analysis service 260 performs an analysis of the test line captured in the image, including, e.g., counting the number of colored pixels, determining the color, determining the intensity of the color, among other possible analyses. For example, the test analysis service 260 may determine, for each pixel, an intensity across each channel of a suitable color space (e.g., red-green-blue (RGB), cyan-magenta-yellow- black (CMYK), among others). In some embodiments, the test analysis service 260 may determine, for each pixel, a luminance value and one or more chrominance values, e.g., as defined according to YUV color encoding, or other suitable color encoding. The mobile device may then compare this number and color intensity to that in the control line, providing a mathematical evaluation of the test line. Utilizing unique wavelengths of light for illumination in conjunction with either CMOS or CCD detection technology, a signal rich image is produced of the test lines to detect the colloid gold or latex particles. This provides an advantage because a user simply looking at the two lines may not know what the test line indicates, such as when the colored line does appear on the strip, but it is a faded line, rather than a dark line. Based on this analysis, the test analysis service 260 may provide a test results 665 indicator, e.g., on the GUI displayed on the user computing device. [0113] In some embodiments, the test results 665 may be communicated to, e.g., the data storage system 270 or other storage or cache system. In some embodiments, the test results 665 may be appended to the intake record, or associated with the intake record using, e.g., a link based on the visit code as described above.

[0114] FIG. 7 illustrates a flowchart of an illustrative methodology of predictive recommendations based on automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0115] In some embodiments, intake queues and wait times can be lengthened as a result of providers collecting and analyzing information in each visit with users to determine conditions and treatment plans, thus increasing computational resources due to lengthened user engagement. Moreover, without sophisticated and expensive algorithm training or other expensive and inefficient techniques, predicting such conditions and treatment plans to reduce intake times may be often inaccurate. However, in some embodiments, a recommendation service 240 employs a diagnostic code library 745 stored in the data storage system 270 to analyze and interpret, e.g., the test results 665, intake record 329 and medical history 701 for a user to predict a recommend treatment plan. Such use of the diagnostic code library 745 facilitates quick, accurate and efficient prediction of treatment plans and condition diagnoses without resource intensive and complex algorithms and machine learning models, thus reducing computational resources, intake wait times, and teleconference durations between users and providers. Accordingly, the intake and visit process is more efficient.

[0116] In some embodiments, to facilitate these improvements, the recommendation service 240 receives the intake record 329, medical history 801, and, if applicable, test results 665 for each user engaged in a visit with the cloud platform 110. For example, the recommendation service may receive, e.g., a visit code or user identifier associated with each user for each visit. Upon being called via, e.g., a recommendation API as described above, the recommendation service 240 may utilize the visit code or user identifier or both in a request, e.g., API request, to the data storage system 270 for medical data associated with the user for the visit. The data storage system 270 may be configured to respond to the request by returning the test results 665, intake record 329 and medical history 701 associated with a user profile identified by the visit code, the user identifier or both. In some embodiments, a heuristic search or elastic search may be used with the visit code or user identifier as a query to find and retrieve the medical data. However, in some embodiments, user profiles are indexed according to visit codes and user identifiers, with all medical data associated with a user linked to the user’ s user profile. [0117] In some embodiments, the recommendation service 240 may receive the medical data (e.g., test results 665, intake record 329 and medical history 701) from the data storage system 270 and compile, at block 741, an electronic health record (EHR) for the user for the visit. In some embodiments, the EHR includes, e.g., a table, array, or other structured data format, to organize attributes of the medical data according to a pre-defmed structure. For example, attributes associated with the test results 665 may be represented in respective predetermined fields of the EHR data format. Similarly, attributes of the intake record 329 and medical history 701 may also be assigned to respective predetermined fields. For example, the EHR may include a field for each response in the intake record 329, a field for visit type, a field for chief complaint, a field for each item of the medical history 701, including user physical measurements (e.g., height, weight, etc.) and medical history. Thus, in some embodiments, an attribute of the EHR refers to each item of medical data determined for the user.

[0118] In some embodiments, the recommendation service 240 may then use the EHR to re characterize the attributes as a predictive score at block 742. In some embodiments, the EHR may represent attributes as, e.g., strings, numbers, Booleans, or other data types based on the data. For example, test results 665 may be characterized as a Boolean (e.g., true or false) to represent whether a test is positive or negative for a given condition. However, intake responses in the intake record 329 may characterized as a string representing the user responses to each intake question. In some embodiments, some or all of the intake responses in the intake record 329 may be represented as numbers, where each number signifies an option or user selection in the intake question. Thus, each attribute of the intake record 329 may represent a given intake response (e.g., according to a question identifier), with a numerical representation indicating the intake response selected by the user. Similarly, the medical history 701 attributes may be represented using, e.g., strings or numbers associated with attribute identifiers to indicate a user’s selection for the attribute.

[0119] In some embodiments, the recommendation service 240 may use the chief complaint attribute and visit type attribute from the intake record 329 to determine an associated predictive score calculation method based on the attribute value associated with each of the chief complaint and visit type. For example, the EHR may include an attribute identify that identifies the chief complaint attribute with an associated chief complaint value associated therewith. In some embodiments, the recommendation service 240 may match the attribute values for chief complaint or visit type or both to diagnostic scoring identifiers in, e.g., an index or look-up table. The index or look-up table may include a diagnostic scoring method for each chief complaint value, visit type value, or combination thereof for a diagnostic scoring method tailored for each chief complaint and/or visit type. For example, the chief complaint may be “sore throat” and the visit type may be “streptococcal infection”. The recommendation service 240 may utilize the chief complaint value associated with “sore throat” and/or the visit type value associated with “streptococcal infection” to cross-reference the index or look-up table of diagnostic scoring methods and identify the centor score as the appropriate diagnostic scoring method.

[0120] In some embodiments, each diagnostic scoring method may include, e.g., a data entry, a file, a data record, or other data format that includes logic for scoring that is designed to extract attribute values from the EHR according to, e.g., variables specified in the logic of the diagnostic scoring method. Thus, the EHR attributes can be utilized by the selected diagnostic scoring method to calculate a predictive score that represents an aggregate of signs and symptoms as related to the chief complaint and visit type.

[0121] In some embodiments, the recommendation service 240 utilizes the predictive score to match the medical data to a diagnostic index at block 743. In some embodiments, the recommendation service 240 cross references the predictive score with an entry in a diagnostic code library 745 in the data storage system 270 to determine recommended treatment plan. In some embodiments, the diagnostic code library 745 includes, e.g., a diagnostic code such as, e.g., medical classification codes including, e.g., the International Statistical Classification of Diseases and Related Health Problems (ICD), the Diagnostics and Statistical Manual of Mental Disorders (DSM), international Classification of Sleep Disorders (ICSD), Online Mendelian Inheritance in Man, among other health-related classification codes. In some embodiments, the classification code or codes may be extracted from an external source (e.g., the ICD-10), and formatted into the structured data of the index for use by the recommendation service 240. In some embodiments, the diagnostic code library 745 includes medical classification codes having indexed diagnostic records associated with each condition, e.g., an illness, disorder, disease or other medical issue. In some embodiments, each diagnostic record includes, e.g., a diagnostic score based on the signs and symptoms set forth in the medical classification code. In some embodiments, the diagnostic code library 745 establishes diagnostic criteria according to the diagnostic score. However, in other embodiments, the diagnostic score includes multiple scores, where each score is associated with an individual sign or symptom. Thus, the diagnostic criteria may be based on combinations of individual sign or symptom scores.

[0122] In some embodiments, the diagnostic criteria establish a likelihood of the presence of a particular condition, along with a recommended treatment plan given the likelihood of the presence. Thus, the recommendation service 240, based on a match between the predictive score or attribute values of the EHR and the diagnostic score(s) of one or more conditions of the diagnostic code library 745, may generate a predictive recommendation for a user’s visit at block 744. In some embodiments, the predictive recommendation includes a recommendation for a diagnosis with the matching condition or conditions, along with the recommended likelihood of presence based on the diagnostic criteria. Moreover, the recommendation service 240 may extract the recommended treatment plans associated with matching condition of the diagnostic code library 745 as part of the predictive recommendation for the visit.

[0123] Thus, in some embodiments, the recommendation service 240 may provide to a user, a provider, or both, a recommendation for a possible diagnosis of a condition associated with the user’s visit, and a recommended treatment plan. While such a recommendation is not a diagnosis, the recommendation provides an expedient to identifying potential diagnoses based on a referencing of the medical classification codes represented by the diagnostic code library 745. In some embodiments, the predictive recommendation may be appended to the associated user profile or intake record 329 for the user visit for later access.

[0124] FIG. 8 illustrates a flowchart of an illustrative methodology automated electronic record tracking for automated matching to profiles for automated record queuing in accordance with one or more embodiments of the present disclosure.

[0125] In some embodiments, a self-organizing queue service 250 receives each intake record 329 from all users visiting the cloud platform 110 for a visit with a provider. However, to fulfill a visit, a user needs to be matched with a provider. Some providers have different capabilities and qualifications for addressing conditions than others. Thus, organization of users and associated intake records 329 for matching to appropriate providers may facilitate more efficient organization of queues of users to fulfill visits. [0126] In some embodiments, the self-organized queue service 250 automatically matches and organizes queues of intake records 329 according to provider profiles 830 for efficient matching and reduced duplication of processing. To do so, in some embodiments, the self- organized queue service 250 orders each user, at block 851, according to an entry time specified in the user’s associated intake record 329. As described above, each user’s intake record 329 may include a field or metadata tag identifying a time as which the intake records 329 was created for a given user visit on the cloud platform 110, such as, e.g., upon engaging with the intake service 220. The entry time represents a user priority based on a first-come-first-served basis.

[0127] In some embodiments, the order of users according to entry can be used to form a queue of all intake records 329, e.g., in a file queue in a cache or buffer, where each intake record 329 is a file queued in the cache or buffer according to the entry time. Alternatively, the queue may be a link to the intake record 329 rather than the intake record 329 itself to further reduce a memory footprint of the queue. However, a single queue for all intake records 329 ignores provider capabilities, such as, e.g., practice area, license locations (e.g., state, region, country, etc.), ages that the provider is license to treat, among other capabilities. This can lead to incorrectly allowing a user to visit with a provider having non-matching capabilities, which may lead to re-entering the user into the queue, thus duplicating processing and memory resources, as well as providing a time-consuming process for both user and provider. Thus, the self-organized queue service 250 may automatically organize a queue for each provider having only intake records 329 associated matching the capabilities of each respective provider. [0128] In some embodiments, therefore, the self-organized queue service 250 may determine, at block 852, the provider capabilities matching each intake record 329. In some embodiments, the self-organized queue service 250 may utilize the visit type and the user profile associated with each intake records 329 to determine, e.g., the practice area, the location and the age of each user visit associated with teach intake record 329. Thus, the provider capabilities can be determined as the practice area associated with the visit type of the intake record 329, a provider license location based on the location of the intake record 329 or user profile, and a provider age license based on the age identified in the user profile. However, other provider capabilities are also contemplated.

[0129] In some embodiments, the self-organized queue service 250 may utilize the provider capabilities to identify physicians having the provider capabilities for each intake record 329 at block 853. In some embodiments, each provider may log in to the cloud platform 110 with an associated provider profile 830, maintained in the data storage system 270. The provider profile 830 may include data representing the capabilities of the provider, such as, e.g., a practice area associated with the provider, the age range that the provider is qualified to treat (e.g., pediatrics, geriatrics, etc.), regions in which the provider is licensed to provide medical services, among other qualifications.

[0130] In some embodiments, the provider capabilities may be encoded in the provider profile 830 as data indicating each capability. For example, the provider profiles 830 may each include fields associated with each type of capability, and having, e.g., a Boolean, a value, a string, or other data type indicating applicability or degree of applicability of a given capability.

[0131] In some embodiments, the provider capabilities determined by the self-organized queue service 250 associated with the intake records 329 can be compared to each provider profile 830 to identify matching provider profiles to each intake record 329. Each provider capability of the intake records 329 can include an identifier of capability type that can be matched with each capability type of the provider profiles 830. The capability fields associated with each capability type can then be compared between each intake record 329 and each provider profile 830. Where the capability fields of each capability type match between the intake record 329 and the provider profile 830, a matching provider is identified for a given user. [0132] In some embodiments, for each intake record 329, the associated user is added to a provider-specific queue at block 854 for each provider profile that matches the provider capabilities. In some embodiments, a cache or buffer maintains a queue of a link to the matched intake records 329 for each provider profile 830. Thus, provider-specific queues are formed that identify users and associated intake profiles 329 that are lined up for visitation with each provider.

[0133] In some embodiments, the intake records of the provider-specific queues are broadcast to each respective provider GUI associated with each provider profile 830. In some embodiments, upon adding each successive intake record 329 to a provider-specific queue, an update to the provider specific queue at, e.g., a provider GUI, may be pushed from the cloud platform 110 to a provider associated user computing device. For example, a provider may engage with the cloud platform 110 via a user computing device by logging in to an associate provider profile 830. A provider may view, via a provider GUI, the intake records 329 matched to the associated provider profile 830, which may be updated with additional intake records 329 as users complete the intake process by engaging with, e.g., the intake service 220, automated triage service 230, test analysis service 260, and recommendation service 240. Accordingly, a queue is maintained for each provider profiles 830 that is specific to the provider profile 830 based on the matching capabilities between the determined provider capabilities from block 852 and the provider capabilities of each provider profile 830. As a result, each provider is presented, via a display at an associated user computing device, a queue of matching intake records 329 to the associated provider profiles 830.

[0134] In some embodiments, via the provider GUI, the providers may select an intake profile 329 for a visit with the associated user. In some embodiments, the self-organized queue service 250 may only allow a provider to select, via the provider GUI, a first user in the queue. Therefore, each provider-specific queue may be ordered chronologically according to time of entry into the intake process, as described above, such that the self-organized queue service 250 may receive provider acceptance for the first user in the respective provider-specific queue at block 856.

[0135] Once the provider accepts a visit with a given user, the provider may access the user’s user profile to view, e.g., the test results 665 associated with the visit, the intake record 329 including any recommended condition diagnosis and treatment plan (as described above), and the medical history 701. The provider and the user may then be automatically put into a telemedicine visit session, such as, e.g., a video conference, voice conference, text conference, or other form of communication.

[0136] Thus, the self-organized queue service 250 enforce chronological priority while also matching users to providers having the requisite capabilities for the visit type and chief complaint associated with each user. As a result, users can be accurately and efficiently directed to appropriate providers, and providers may be accurately and efficiently provided with electronic health records, including intake records 329, test results 665, medical histories 701, among other pertinent data to expedite telemedicine visits over the cloud platform 110.

[0137] FIG. 9 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0138] In some embodiments, a series of GUI screens can be used to generate a medical history for a user profile. For example, each screen of the GUI can include, e.g., a virtual button for progressing to a “Next” screen, or regressing “Back” to a previous screen. Moreover, each GUI screen can include, e.g., a text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements for specifying aspects of medical history. [0139] FIG. 10 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0140] In some embodiments, a series of GUI screens can be used to prompt a user at a user computing device to select a chief complaint, including, e.g., selectable virtual GUI elements associated with different signs and/or symptoms of illness, including, e.g., graphics for depicting types of signs and/or symptoms and effected body parts.

[0141] FIG. 11 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0142] In some embodiments, upon selecting a chief complaint, a user may be presented with intake initiation GUI screen to inform the user that intake may be initiated. For example, the intake initiate GUI screen may include a description of the intake process and a selected virtual button to, e.g., progress to intake, cancel the intake initiation, or other suitable selection.

[0143] FIG. 12 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0144] In some embodiments, upon entering into the intake process, a user may be presented with a chief complaint clarification GUI screen sequence allowing the user to select symptoms related to the selected chief complaint as well as any exposures for chief complaints that are contagious. In some embodiments, the chief complaint clarification GUI screen sequence is generated for the user based on the selected chief complaint. In some embodiments, the chief complaint and chief complaint clarification may be used to identify or generate a visit type, which may result in one of multiple possible intake question sets according to an intake template library having templates of sequences of GUI screens for prompting the user for visit type-specific prompts for additional information.

[0145] FIG. 13 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0146] In some embodiments, a visit type may be recommended that includes a diagnostic test kit and the recommendation may be presented to the user via a visit type GUI screen. For example, FIG. 13 depicts a Cold & Flu visit type recommendation, with a selectable virtual button for continuing to get a diagnostic test kit associated with Cold & Flu visits. In some embodiments, the visit type GUI screen can include a selectable virtual button for declining to get a diagnostic testing kit.

[0147] FIG. 14 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0148] In some embodiments, a visit type may be recommended that includes a diagnostic test kit and the recommendation may be presented to the user via a visit type GUI screen. For example, FIG. 14 depicts a Sore Throat visit type recommendation, with a selectable virtual button for continuing to get a diagnostic test kit associated with Sore Throat visits. In some embodiments, the visit type GUI screen can include a selectable virtual button for declining to get a diagnostic testing kit.

[0149] FIG. 15 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0150] In some embodiments, a visit type may be recommended that includes a diagnostic test kit and the recommendation may be presented to the user via a visit type GUI screen. For example, FIG. 15 depicts a Urinary Symptoms visit type recommendation, with a selectable virtual button for continuing to get a diagnostic test kit associated with Urinary Symptoms visits. In some embodiments, the visit type GUI screen can include a selectable virtual button for declining to get a diagnostic testing kit.

[0151] FIG. 16A and 16B illustrate a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0152] In some embodiments, where a user selects to proceed with getting a diagnostic testing kit, the user may be prompted with a pharmacy discovery GUI screen sequence where, if a user is in range of a pharmacy, the pharmacy discovery GUI screen sequence provides the user with a selectable map of nearby pharmacies carrying the diagnostic testing kit, as in FIG. 16 A. However, where the pharmacy discovery GUI screen sequence determines that a pharmacy is not in range of the user, the user may be informed that no pharmacies carrying the particular diagnostic testing kit are nearby, as in FIG. 16B. The user may then be presented with the option to continue without a kit.

[0153] FIG. 17 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0154] In some embodiments, a visit type may be recommended that does not include a diagnostic test kit and the recommendation may be presented to the user via a visit type GUI screen. For example, FIG. 17 depicts a Pink Eye visit type recommendation, with a selectable virtual button for continuing to a provider visit. In some embodiments, a visit type warning GUI screen may be displayed upon selecting to continue, where the visit type warning GUI screen provides a prompt for emergency care and how to reach emergency care for the visit type. [0155] FIG. 18 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0156] In some embodiments, a visit type may be recommended that does not include a diagnostic test kit and the recommendation may be presented to the user via a visit type GUI screen. For example, FIG. 18 depicts a Sinus Pain & Pressure visit type recommendation, with a selectable virtual button for continuing to a provider visit. In some embodiments, a visit type warning GUI screen may be displayed upon selecting to continue, where the visit type warning GUI screen provides a prompt for emergency care and how to reach emergency care for the visit type.

[0157] FIG. 19 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0158] In some embodiments, a visit type may be recommended that does not include a diagnostic test kit and the recommendation may be presented to the user via a visit type GUI screen. For example, FIG. 19 depicts a Vomiting & Diarrhea visit type recommendation, with a selectable virtual button for continuing to a provider visit. In some embodiments, a visit type warning GUI screen may be displayed upon selecting to continue, where the visit type warning GUI screen provides a prompt for emergency care and how to reach emergency care for the visit type.

[0159] FIG. 20 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0160] In some embodiments, a visit type may be recommended that recommends immediate emergency care. The recommendation may be presented to the user via an emergency care GUI screen. For example, FIG. 20 depicts the emergency room recommendation, with a selectable virtual button for exiting to visit urgency care or an emergency as soon as possible. However, the emergency care GUI screen may also include an option to select a virtual button for continuing to a provider visit. In some embodiments, the emergency care GUI screen may then surface, upon selection to continue, a warning screen and waiver check box for proceeding without seeking emergency care.

[0161] FIG. 21 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0162] In some embodiments, a visit type may be recommended that does not include a particular type from a set of possible visit types. Thus, the display may be provided with a General Visit recommendation GUI for non-specific visits, with a selectable virtual button for proceeding to a general visit.

[0163] FIG. 22A and 22B illustrate a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0164] In some embodiments, the cloud platform 110 may include a function for payments by, e.g., purchasing visit credits that allow a user profile to be submitted for a visit to a provider. The cloud platform 110 may then perform a check for visit credit in a user account. Where a user does have a visit credit, as in FIG. 22A, the user computing device may be served a visit credit GUI screen with a virtual element for selecting to use the visit credit or a visit code that has already been paid for. However, where a user does not have a visit credit, as in FIG. 22B, a visit credit GUI screen with a virtual element for selecting to use a visit code that has already been paid for, or an option to buy a visit credit followed to buy a series of visit credit purchase GUI screens, including input fields for payment information. [0165] FIG. 23 A and 23B illustrate a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0166] In some embodiments, prior to entering a virtual waiting and after having completed intake response of, e.g., an active encounter, the user may be presented with a profile update GUI screen. The profile update GUI screen may include selectable virtual elements to select whether there are updates to the user profile, including medical history and medications, among other updates, as shows in FIG. 23A. Upon selecting a “Yes” virtual element to update the profile, the user may be presented with a profile update GUI sequence, the start of which is depicted in FIG. 23B. Upon selecting “Continue”, the user may be provided with the series of GUI screens can be used to generate the medical history for the user profile of, e.g., FIG. 9 above.

[0167] FIG. 24A through 24K illustrate a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0168] In some embodiments, the cloud platform 110 may detect that a user is a new patient (e.g., has no account or profile with the cloud platform 110). In some embodiments, the new user may be provided with a new user GUI sequence, which may start with a prompt, as depicted in FIG. 24A, to select to continue with a profile creation process. In some embodiments, upon selecting to continue, the user may be presented with a series of GUI screens that can be used to generate a medical history for a new user profile.

[0169] For example, the new user GUI sequence can include a past medical history GUI screen that may include, e.g., a selection of past medical events with associated selectable interface elements, as depicted in FIG. 24B. By selecting the selectable interface elements, the user may return to the cloud platform 110 data representing a medical history of the user. [0170] Similarly, the new user GUI sequence can include a past surgical history GUI screen that may include, e.g., a selection of past surgical events with associated selectable interface elements, as depicted in FIG. 24C. By selecting the selectable interface elements, the user may return to the cloud platform 110 data representing a surgical history of the user.

[0171] Additionally, the new user GUI sequence can include a medications GUI screen that may include, e.g., a text input interface element, as depicted in FIG. 24D. The user may, therefore, enter the names or descriptions of medications that the user is prescribed in order to return to the cloud platform 110 data representing medications of the user.

[0172] Similarly, the new user GUI sequence can include an allergy GUI screen that may include, e.g., a text input interface element, as depicted in FIG. 24E. The user may, therefore, enter the names or descriptions of allergies with which the user is diagnosed in order to return to the cloud platform 110 data representing associated allergies of the user.

[0173] In some embodiments, a social history GUI screen can also presented to the user. The social history GUI screen can include, e.g., a text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for social history, such as, e.g., marital status, smoking or drinking habits, language preferences, location, age, among others, as depicted in FIG. 24F. The user may, therefore, enter pertinent social history in order to return to the cloud platform 110 data representing a social history of the user.

[0174] Similarly, a family history GUI screen can also presented to the user. The family history GUI screen can include, e.g., a text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for family history, such as, e.g., whether the user’s parents are alive, the age of parents, family histories of brain or heart conditions, cancer or other conditions, among other family history information, as depicted in FIG. 24G. The user may, therefore, enter pertinent family history in order to return to the cloud platform 110 data representing a family medical history of the user.

[0175] In some embodiments, where the user is a woman, the user may be presented with a women’s health GUI screen. The women’s health GUI screen can include, e.g., a text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for women’ s health information, such as, e.g., whether the user has been pregnant and how many times, history of contraception, how many deliveries and types of deliveries, among other women’s health information, as depicted in FIG. 24H. The user may, therefore, enter pertinent women’ s health information in order to return to the cloud platform 110 data representing a women’s health information of the user.

[0176] In some embodiments, the user may be presented with an emergency contact GUI having, e.g., a text entry for user input to specify an emergency contact, as depicted in FIG. 241.

[0177] In some embodiments, the user may be presented with primary care physician GUI having, e.g., a text entry for user input to specify a primary care physician, as depicted in FIG. 24J.

[0178] In some embodiments, the user may be presented with preferred pharmacy GUI having, e.g., a set of selectable pharmacies (e.g., based on nearby pharmacies according to the user’s location) for user selection to specify a preferred pharmacy, as depicted in FIG. 24K.

[0179] FIG. 25 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0180] In some embodiments, the intake service 220 of the cloud platform 110 can include a variety of visit types for which the intake can be customized. Based on the visit type (e.g., acne, cold sore, hair loss, acute illness, herpes, birth control, rash and allergy, etc.), the intake service 220 can progress to distinct intake templates of an intake template library for a customized sequence of intake prompts.

[0181] FIG. 26 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0182] In some embodiments, in response to an acne visit type, an acne questionnaire GUI sequence can be presented to the user. The acne questionnaire GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying acne symptoms, history, triggers, evaluation history, etc.. The user may, therefore, enter pertinent acne information in order to return to the cloud platform 110 data representing a history of a present illness including acne.

[0183] FIG. 27 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0184] In some embodiments, in response to a cold sore visit type, a cold sore questionnaire GUI sequence can be presented to the user. The cold sore questionnaire GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying cold sore symptoms, history, triggers, evaluation history, treatment, etc.. The user may, therefore, enter pertinent cold sore information in order to return to the cloud platform 110 data representing a history of a present illness including cold sore. [0185] FIG. 28 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0186] In some embodiments, in response to a hair loss visit type, a hair loss questionnaire GUI sequence can be presented to the user. The hair loss questionnaire GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying hair type, history, triggers, evaluation history, treatment, etc.. The user may, therefore, enter pertinent hair loss information in order to return to the cloud platform 110 data representing a history of a present illness including hair loss.

[0187] FIG. 29A and 29B illustrate a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0188] In some embodiments, in response to a hair loss visit type for a man, a men’s hair loss questionnaire GUI sequence can be presented to the user in addition to or instead of the hair loss questionnaire GUI sequence of FIG. 28. The men’s hair loss questionnaire GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying men’s hair loss pattern, scalp symptoms, history, triggers, evaluation history, treatment, etc.. The user may, therefore, enter pertinent men’s hair loss information in order to return to the cloud platform 110 data representing a history of a present illness including men’s hair loss.

[0189] In some embodiments, in response to a hair loss visit type for a woman, a women’s hair loss questionnaire GUI sequence can be presented to the user in addition to or instead of the hair loss questionnaire GUI sequence of FIG. 28. The women’s hair loss questionnaire GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying women’s hair loss pattern, scalp symptoms, history, triggers, evaluation history, treatment, etc.. The user may, therefore, enter pertinent women’s hair loss information in order to return to the cloud platform 110 data representing a history of a present illness including women’s hair loss.

[0190] FIGS. 30A through 30E illustrate a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0191] In some embodiments, in response to an acute illness visit type, an acute illness questionnaire GUI sequence can be presented to the user as depicted in FIG. 30 A. The acute illness questionnaire GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying current symptoms, history, triggers, fever details (if applicable), contact with other ill people, medications, evaluation history, treatment, etc.. The user may, therefore, enter pertinent acute illness information in order to return to the cloud platform 110 data representing a history of a present illness including an acute illness. Upon completing the acute illness questionnaire GUI sequence, a customized follow-up sequence of GUI screens can be presented for additional information based on chief complaint.

[0192] In some embodiments, in response to a flu chief complaint, a flu follow-up GUI sequence can be presented to the user as depicted in FIG. 30B. The flu follow-up GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying flu symptoms, immunizations, history, triggers, evaluation history, treatment, etc.. The user may, therefore, enter pertinent flu information in order to return to the cloud platform 110 data representing a history of a present illness including a flu.

[0193] In some embodiments, in response to a pink eye chief complaint, a pink eye follow-up GUI sequence can be presented to the user as depicted in FIG. 30C. The pink eye follow-up GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying an ocular medical history, whether the user uses corrective lenses and what type, pink eye symptoms, history, triggers, evaluation history, treatment, etc.. The user may, therefore, enter pertinent pink eye information in order to return to the cloud platform 110 data representing a history of a present illness including pink eye.

[0194] In some embodiments, in response to a vomiting and diarrhea chief complaint, a vomiting and diarrhea follow-up GUI sequence can be presented to the user as depicted in FIG. 30D. The vomiting and diarrhea follow-up GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying symptoms, history, triggers, evaluation history, treatment, eating history, etc.. The user may, therefore, enter pertinent vomiting and diarrhea information in order to return to the cloud platform 110 data representing a history of a present illness including vomiting and diarrhea. [0195] In some embodiments, for all chief complaints, another follow-up can be presented including health state follow-up GUI sequence as depicted in FIG. 30E. For example, the health state follow-up GUI sequence can include e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for, e.g., women’s health information, specifying vitals measurements (e.g., blood pressure, pulse, respiration rate, height, weight, etc.), and any results from a primary care visit, etc.. The user may, therefore, enter pertinent vomiting and diarrhea information in order to return to the cloud platform 110 data representing a history of a present illness including vomiting and diarrhea.

[0196] FIG. 31 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0197] In some embodiments, in response to a herpes visit type, a herpes questionnaire GUI sequence can be presented to the user. The herpes questionnaire GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying current symptoms, diagnostic history, symptom history, triggers, medications, evaluation history, treatment, etc.. The user may, therefore, enter pertinent herpes information in order to return to the cloud platform 110 data representing a history of a present illness including herpes.

[0198] FIG. 32 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0199] In some embodiments, in response to a birth control visit type, a birth control questionnaire GUI sequence can be presented to the user. The birth control questionnaire GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying reproductive history, reproductive symptoms, medical history, female medical history, evaluation history, treatment, etc.. The user may, therefore, enter pertinent birth control information in order to return to the cloud platform 110 data representing a history of reproductive health.

[0200] FIGS. 33A through 33F illustrate a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0201] In some embodiments, in response to rash and allergy visit type, a rash and allergy questionnaire GUI screen can be presented to the user as depicted in FIG. 33 A. The rash and allergy questionnaire GUI screen can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying, e.g., affected body parts, medications, evaluation history, treatment, etc.. The user may, therefore, enter pertinent rash and allergy information in order to return to the cloud platform 110 data representing a history of a present illness including a rash or allergy. Upon completing the rash and allergy questionnaire GUI screen, a customized follow-up sequence of GUI screens can be presented for additional information based on the affected body parts.

[0202] In some embodiments, in response to an affected eye, an affected eye follow-up GUI sequence can be presented to the user as depicted in FIG. 33B. The affected eye follow-up GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying eye symptoms, immunizations, history, triggers, evaluation history, treatment, etc.. The user may, therefore, enter pertinent flu information in order to return to the cloud platform 110 data representing a history of a present illness including a rash or allergy related to eyes.

[0203] In some embodiments, in response to an affected nose, an affected nose follow-up GUI sequence can be presented to the user as depicted in FIG. 33C. The affected nose follow-up GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying nose symptoms, immunizations, history, triggers, evaluation history, treatment, etc.. The user may, therefore, enter pertinent flu information in order to return to the cloud platform 110 data representing a history of a present illness including a rash or allergy related to noses.

[0204] In some embodiments, in response to an affected lung, an affected lung follow-up GUI sequence can be presented to the user as depicted in FIG. 33D. The affected lung follow-up GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying lung symptoms, immunizations, history, triggers, evaluation history, treatment, etc.. The user may, therefore, enter pertinent flu information in order to return to the cloud platform 110 data representing a history of a present illness including a rash or allergy related to lungs.

[0205] In some embodiments, in response to an affected skin, an affected skin follow-up GUI sequence can be presented to the user as depicted in FIG. 33E. The affected skin follow-up GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying skin symptoms, immunizations, history, triggers, evaluation history, treatment, etc.. The user may, therefore, enter pertinent flu information in order to return to the cloud platform 110 data representing a history of a present illness including a rash or allergy related to skin.

[0206] In some embodiments, regardless of affected body part, the user may be presented with a general rash and allergy follow-up GUI sequence can be presented to the user as depicted in FIG. 33F. The general rash and allergy follow-up GUI sequence can include, e.g., text entry for user input, multiple choice selections with selectable checkboxes, selection toggles, Boolean selections, among other virtual GUI elements associated with series of prompts for specifying rash and allergy information including, e.g., symptoms, environment, environmental effects, allergy history, women’s health information, vitals information, whether a primary care physician has been consulted and what the primary care physician determined, evaluation history, treatment, etc.. The user may, therefore, enter pertinent general rash and allergy information in order to return to the cloud platform 110 data representing a history of a present illness including a rash or allergy.

[0207] FIG. 34A through 34E illustrate a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0208] In some embodiments, before, after, or during the intake process of the intake service 220, including the various questionnaires and follow-ups described above, a visit type may be determined to be associated with a diagnostic test kit. Thus, in some embodiments, a user may be presented at a user computing device with a test kit analysis GUI sequence.

[0209] In some embodiments, the test kit analysis GUI sequence can include an initial test kit screen with a prompt for whether the user has the test kit and/or has taken the test kit. The initial test kit screen can include two or more selectable user interface elements to, e.g., verify that the user has the test kit, verify that the user does not have the test kit, skip the test, or other suitable option, as depicted in FIG. 34A.

[0210] Upon selection that the user has the test kit, the intake service 220 and/or user computing device may initiate a test kit imaging process including a camera interface to acquire a digital image of the test kit, as depicted in FIG. 34B. In some embodiments, the camera interface can include instructions for imaging the test kit. In some embodiments, the test does not include a test, but rather an image of a body part, such as an eye in the case of a pink eye visit type, or rash in the case of a rash and allergy visit type, among other possibilities. The user may point the camera at the test kit or body part to take an image, which may then be uploaded to the cloud platform 110 for analysis the test analysis service 260 as described above. [0211] In some embodiments, to associate with the test with an intake record (e.g., intake record 329), the camera interface may be configured to acquire an image of a visit code provided to the user in relation to the intake record for the visit. In some embodiments, the visit code may be encoded in a barcode that the camera interface may automatically decode. The camera interface may then automatically upload the visit code with the test image for association with the intake record, as depicted in FIG. 34C. In some embodiments, the camera interface may include an option to input the visit code manually. Upon selection of the option to input the visit code manually, the camera interface may change to a visit code interface having a text input field for inputting a visit code provided to the user in relation to the intake record for the visit.

[0212] In some embodiments, a user may provide an incorrect visit code. The camera interface and/or visit code interface may display an alert, as depicted in FIG. 34D, describing the invalid code and providing an option to retry or exit.

[0213] In some embodiments, upon successfully uploading a visit code, the user may be presented with a confirmation GUI as depicted in FIG. 34E. The confirmation GUI may include an alert that the visit code was successfully entered and redeemed, thus linking the test image to an appropriate visit and intake record.

[0214] FIG. 35 illustrates a graphical user interface presented to a user for automated electronic record creation and queuing in accordance with one or more embodiments of the present disclosure.

[0215] In some embodiments, upon completion of an intake process, such as the questionnaires, screens, sequences and follow-ups described above, a user profile or intake record may be placed into a virtual waiting, e.g., in the data storage system 270 and queued for a visit with a matching provider. In some embodiments, the intake service 220 may determine, based on a number of people in the virtual waiting room and a number of providers logged in, an estimate wait time. In some embodiments, a waiting room interface may be presented to the user on the user computer device depicting the estimated wait time and, e.g., an option to cancel the visit via a suitable selectable user interface element, such as a cancel button. The estimated wait may be dynamic, with updates based on the number of remaining users in the virtual waiting room and the number of providers logged in. In some embodiments, the estimated wait time updates in real-time, however in some embodiments, the estimated wait time updates periodically (e.g., every 15 seconds, every 30 seconds, every minute, etc.). The updated estimated wait time may be then be displayed on the waiting room interface.

[0216] FIG. 36 depicts a block diagram of an exemplary computer-based system and platform 900 in accordance with one or more embodiments of the present disclosure. However, not all of these components may be required to practice one or more embodiments, and variations in the arrangement and type of the components may be made without departing from the spirit or scope of various embodiments of the present disclosure. In some embodiments, the illustrative computing devices and the illustrative computing components of the exemplary computer- based system and platform 900 may be configured to manage a large number of members and concurrent transactions, as detailed herein. In some embodiments, the exemplary computer- based system and platform 900 may be based on a scalable computer and network architecture that incorporates varies strategies for assessing the data, caching, searching, and/or database connection pooling. An example of the scalable architecture is an architecture that is capable of operating multiple servers.

[0217] In some embodiments, referring to FIG. 44, members 902-904 (e.g., clients) of the exemplary computer-based system and platform 900 may include virtually any computing device capable of receiving and sending a message over a network (e.g., cloud network), such as network 905, to and from another computing device, such as servers 906 and 907, each other, and the like. In some embodiments, the member devices 902-904 may be personal computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, and the like. In some embodiments, one or more member devices within member devices 902-904 may include computing devices that typically connect using a wireless communications medium such as cell phones, smart phones, pagers, walkie talkies, radio frequency (RF) devices, infrared (IR) devices, CBs, integrated devices combining one or more of the preceding devices, or virtually any mobile computing device, and the like. In some embodiments, one or more member devices within member devices 902-904 may be devices that are capable of connecting using a wired or wireless communication medium such as a PDA, POCKET PC, wearable computer, a laptop, tablet, desktop computer, a netbook, a video game device, a pager, a smart phone, an ultra-mobile personal computer (UMPC), and/or any other device that is equipped to communicate over a wired and/or wireless communication medium (e g., NFC, RFID, NBIOT, 3G, 4G, 5G, GSM, GPRS, WiFi, WiMax, CDMA, satellite, ZigBee, etc.). In some embodiments, one or more member devices within member devices 902- 904 may include may run one or more applications, such as Internet browsers, mobile applications, voice calls, video games, videoconferencing, and email, among others. In some embodiments, one or more member devices within member devices 902-904 may be configured to receive and to send web pages, and the like. In some embodiments, an exemplary specifically programmed browser application of the present disclosure may be configured to receive and display graphics, text, multimedia, and the like, employing virtually any web based language, including, but not limited to Standard Generalized Markup Language (SMGL), such as HyperText Markup Language (HTML), a wireless application protocol (WAP), a Handheld Device Markup Language (HDML), such as Wireless Markup Language (WML), WMLScript, XML, JavaScript, and the like. In some embodiments, a member device within member devices 902-904 may be specifically programmed by either Java, .Net, QT, C, C++ and/or other suitable programming language. In some embodiments, one or more member devices within member devices 902-904 may be specifically programmed include or execute an application to perform a variety of possible tasks, such as, without limitation, messaging functionality, browsing, searching, playing, streaming or displaying various forms of content, including locally stored or uploaded messages, images and/or video, and/or games.

[0218] In some embodiments, the exemplary network 905 may provide network access, data transport and/or other services to any computing device coupled to it. In some embodiments, the exemplary network 905 may include and implement at least one specialized network architecture that may be based at least in part on one or more standards set by, for example, without limitation, Global System for Mobile communication (GSM) Association, the Internet Engineering Task Force (IETF), and the Worldwide Interoperability for Microwave Access (WiMAX) forum. In some embodiments, the exemplary network 905 may implement one or more of a GSM architecture, a General Packet Radio Service (GPRS) architecture, a Universal Mobile Telecommunications System (UMTS) architecture, and an evolution of UMTS referred to as Long Term Evolution (LTE). In some embodiments, the exemplary network 905 may include and implement, as an alternative or in conjunction with one or more of the above, a WiMAX architecture defined by the WiMAX forum. In some embodiments and, optionally, in combination of any embodiment described above or below, the exemplary network 905 may also include, for instance, at least one of a local area network (LAN), a wide area network (WAN), the Internet, a virtual LAN (VLAN), an enterprise LAN, a layer 3 virtual private network (VPN), an enterprise IP network, or any combination thereof. In some embodiments and, optionally, in combination of any embodiment described above or below, at least one computer network communication over the exemplary network 905 may be transmitted based at least in part on one of more communication modes such as but not limited to: NFC, RFID, Narrow Band Internet of Things (NBIOT), ZigBee, 3G, 4G, 5G, GSM, GPRS, WiFi, WiMax, CDMA, satellite and any combination thereof. In some embodiments, the exemplary network 905 may also include mass storage, such as network attached storage (NAS), a storage area network (SAN), a content delivery network (CDN) or other forms of computer or machine readable media.

[0219] In some embodiments, the exemplary server 906 or the exemplary server 907 may be a web server (or a series of servers) running a network operating system, examples of which may include but are not limited to Microsoft Windows Server, Novell NetWare, or Linux. In some embodiments, the exemplary server 906 or the exemplary server 907 may be used for and/or provide cloud and/or network computing. Although not shown in FIG. 44, in some embodiments, the exemplary server 906 or the exemplary server 907 may have connections to external systems like email, SMS messaging, text messaging, ad content providers, etc. Any of the features of the exemplary server 906 may be also implemented in the exemplary server 907 and vice versa.

[0220] In some embodiments, one or more of the exemplary servers 906 and 907 may be specifically programmed to perform, in non-limiting example, as authentication servers, search servers, email servers, social networking services servers, SMS servers, IM servers, MMS servers, exchange servers, photo-sharing services servers, advertisement providing servers, fmancial/banking-related services servers, travel services servers, or any similarly suitable service-base servers for users of the member computing devices 901-904.

[0221] In some embodiments and, optionally, in combination of any embodiment described above or below, for example, one or more exemplary computing member devices 902-904, the exemplary server 906, and/or the exemplary server 907 may include a specifically programmed software module that may be configured to send, process, and receive information using a scripting language, a remote procedure call, an email, a tweet, Short Message Service (SMS), Multimedia Message Service (MMS), instant messaging (IM), internet relay chat (IRC), mIRC, Jabber, an application programming interface, Simple Object Access Protocol (SOAP) methods, Common Object Request Broker Architecture (CORBA), HTTP (Hypertext Transfer Protocol), REST (Representational State Transfer), or any combination thereof.

[0222] FIG. 37 depicts a block diagram of another exemplary computer-based system and platform 1000 in accordance with one or more embodiments of the present disclosure. However, not all of these components may be required to practice one or more embodiments, and variations in the arrangement and type of the components may be made without departing from the spirit or scope of various embodiments of the present disclosure. In some embodiments, the member computing devices 1002a, 1002b thru 1002n shown each at least includes a computer-readable medium, such as a random-access memory (RAM) 1008 coupled to a processor 1010 or FLASH memory. In some embodiments, the processor 1010 may execute computer-executable program instructions stored in memory 1008. In some embodiments, the processor 1010 may include a microprocessor, an ASIC, and/or a state machine. In some embodiments, the processor 1010 may include, or may be in communication with, media, for example computer-readable media, which stores instructions that, when executed by the processor 1010, may cause the processor 1010 to perform one or more steps described herein. In some embodiments, examples of computer-readable media may include, but are not limited to, an electronic, optical, magnetic, or other storage or transmission device capable of providing a processor, such as the processor 1010 of client 1002a, with computer- readable instructions. In some embodiments, other examples of suitable media may include, but are not limited to, a floppy disk, CD-ROM, DVD, magnetic disk, memory chip, ROM, RAM, an ASIC, a configured processor, all optical media, all magnetic tape or other magnetic media, or any other medium from which a computer processor can read instructions. Also, various other forms of computer-readable media may transmit or carry instructions to a computer, including a router, private or public network, or other transmission device or channel, both wired and wireless. In some embodiments, the instructions may comprise code from any computer-programming language, including, for example, C, C++, Visual Basic, Java, Python, Perl, JavaScript, and etc.

[0223] In some embodiments, member computing devices 1002a through 1002n may also comprise a number of external or internal devices such as a mouse, a CD-ROM, DVD, a physical or virtual keyboard, a display, or other input or output devices. In some embodiments, examples of member computing devices 1002a through 1002n (e.g., clients) may be any type of processor-based platforms that are connected to a network 1006 such as, without limitation, personal computers, digital assistants, personal digital assistants, smart phones, pagers, digital tablets, laptop computers, Internet appliances, and other processor-based devices. In some embodiments, member computing devices 1002a through 1002n may be specifically programmed with one or more application programs in accordance with one or more principles/methodologies detailed herein. In some embodiments, member computing devices 1002a through 1002n may operate on any operating system capable of supporting a browser or browser-enabled application, such as Microsoft™, Windows™, and/or Linux. In some embodiments, member computing devices 1002a through 1002n shown may include, for example, personal computers executing a browser application program such as Microsoft Corporation's Internet Explorer™, Apple Computer, Inc.'s Safari™, Mozilla Firefox, and/or Opera. In some embodiments, through the member computing client devices 1002a through 1002n, users, 1012a through 1002n, may communicate over the exemplary network 1006 with each other and/or with other systems and/or devices coupled to the network 1006. As shown in FIG. 45, exemplary server devices 1004 and 1013 may be also coupled to the network 1006. In some embodiments, one or more member computing devices 1002a through 1002n may be mobile clients.

[0224] In some embodiments, at least one database of exemplary databases 1007 and 1015 may be any type of database, including a database managed by a database management system (DBMS). In some embodiments, an exemplary DBMS-managed database may be specifically programmed as an engine that controls organization, storage, management, and/or retrieval of data in the respective database. In some embodiments, the exemplary DBMS-managed database may be specifically programmed to provide the ability to query, backup and replicate, enforce rules, provide security, compute, perform change and access logging, and/or automate optimization. In some embodiments, the exemplary DBMS-managed database may be chosen from Oracle database, IBM DB2, Adaptive Server Enterprise, FileMaker, Microsoft Access, Microsoft SQL Server, MySQL, PostgreSQL, and a NoSQL implementation. In some embodiments, the exemplary DBMS-managed database may be specifically programmed to define each respective schema of each database in the exemplary DBMS, according to a particular database model of the present disclosure which may include a hierarchical model, network model, relational model, object model, or some other suitable organization that may result in one or more applicable data structures that may include fields, records, files, and objects. In some embodiments, the exemplary DBMS-managed database may be specifically programmed to include metadata about the data that is stored.

[0225] In some embodiments, the illustrative computer-based systems or platforms of the present disclosure may be specifically configured to operate in a cloud computing or cloud architecture such as, but not limiting to: infrastructure a service (IaaS), platform as a service (PaaS), and/or software as a service (SaaS). Figures 38 and 39 illustrate schematics of exemplary implementations of the cloud computing/architecture(s) in which the illustrative computer-based systems or platforms of the present disclosure may be specifically configured to operate.

[0226] While one or more embodiments of the present disclosure have been described, it is understood that these embodiments are illustrative only, and not restrictive, and that many modifications may become apparent to those of ordinary skill in the art, including that various embodiments of the inventive methodologies, the illustrative systems and platforms, and the illustrative devices described herein can be utilized in any combination with each other. Further still, the various steps may be carried out in any desired order (and any desired steps may be added and/or any desired steps may be eliminated).

Claims

1. A method comprising: receiving, by at least one processor, a per-visit intake record comprising data representative of a chief complaint and a history of a present illness (HPI) associated with a user visit; matching, by the at least one processor, the per-visit intake record to a visit type record of a visit template library including a plurality of visit type records based on a matching set of visit type attributes to data representative of the chief complaint and the history of the HPI; identifying, by the at least one processor, a test attribute of the visit type record indicative of an applicable diagnostic test; identifying, by the at least one processor, an emergency attribute of the visit type record indicating that the chief complaint and the HPI form an emergency; updating, by the at least one processor, the per-visit intake record by appending a visit type identify identifying the visit type record; and causing to display, by the at least one processor, a visit type interface representative of the visit type record on a screen of at least one computing device associated with at least one user of the user visit, including an indication of the emergency attribute and the test attribute.

2. The method as recited in claim 1, wherein the HPI comprises at least one user intake response resulting from at least one user selection of intake question prompts in an intake GUI sequence.

3. The method as recited in claim 1, further comprising: generating, by the at least one processor, an intake response identifier for each of the at least one user intake response; and determining, by the at least one processor, a chief complaint identifier identifying the chief complain.

4. The method as recited in claim 3, identifying, by the at least one processor, the visit type identifier associated with the visit type record based on each intake response identifier paired with the chief complaint identifier.

5. The method as recited in claim 1, further comprising generating, by the at least one processor, a test analysis GUI sequence comprising a sequence of prompts permitting a user to upload diagnostic test results.

6. The method as recited in claim 1, further comprising generating, by the at least one processor, an emergency recommendation GUI prompt comprising a recommendation for an emergency room visit based on the emergency attribute.

7. The method as recited in claim 1, further comprising instantiating, by the at least one processor, a triage service in a cloud computing container upon receiving the per-visit intake record.

8. The method as recited in claim 1, further comprising storing, by the at least one processor, the per-visit intake record in a persistent object storage system.

9. The method as recited in claim 1, wherein the per-visit intake record is received via an application programming interface (API) request.

10. A system comprising: at least one data storage system configured to store a visit template library having a plurality of visit templates representing visit type attributes for each of a plurality of visit types; and at least one processing device configured to perform instructions stored in a memory causing the system to perform steps to: receive a per-visit intake record comprising data representative of a chief complaint and a history of a present illness (HP I) associated with a user visit; match the per-visit intake record to a visit type record of the plurality of visit type records in the visit template library based on a matching set of visit type attributes to data representative of the chief complaint and the HP I; identify a test attribute of the visit type record indicative of an applicable diagnostic test; identify an emergency attribute of the visit type record indicating that the chief complaint and the HPI form an emergency; update the per-visit intake record by appending a visit type identify identifying the visit type record; and cause to display a visit type interface representative of the visit type record on a screen of at least one computing device associated with at least one user of the user visit, including an indication of the emergency attribute and the test attribute.

11. The system as recited in claim 10, wherein the HPI comprises at least one user intake response resulting from at least one user selection of intake question prompts in an intake GUI sequence.

12. The system as recited in claim 10, wherein the at least one processor is further configured to: generate an intake response identifier for each of the at least one user intake response; and determine a chief complaint identifier identifying the chief complain.

13. The system as recited in claim 12, wherein the at least one processor is further configured to identify the visit type identifier associated with the visit type record based on each intake response identifier paired with the chief complaint identifier.

14. The system as recited in claim 10, wherein the at least one processor is further configured to generate a test analysis GUI sequence comprising a sequence of prompts permitting a user to upload diagnostic test results.

15. The system as recited in claim 10, wherein the at least one processor is further configured to generate an emergency recommendation GUI prompt comprising a recommendation for an emergency room visit based on the emergency attribute.

16. The system as recited in claim 10, wherein the at least one processor is further configured to instantiate a triage service in a cloud computing container upon receiving the per-visit intake record.

17. The system as recited in claim 10, wherein the at least one processor is further configured to store the per-visit intake record in a persistent object storage system.

18. The system as recited in claim 10, wherein the per-visit intake record is received via an application programming interface (API) request.

19. The system as recited in claim 10, further comprising a cloud platform configured to perform the steps in at least one virtual machine.

20. A non-transitory computer readable medium having stored thereon computer readable instructions configured to cause at least one processor to perform a computer-implemented method comprising: receiving a per-visit intake record comprising data representative of a chief complaint and a history of a present illness (HP I) associated with a user visit; matching the per-visit intake record to a visit type record of a visit template library including a plurality of per-visit intake records based on a matching set of visit type attributes to data representative of the chief complaint and the HP I; identifying a test attribute of the visit type record indicative of an applicable diagnostic test; identifying an emergency attribute of the visit type record indicating that the chief complaint and the HPI form an emergency; updating the per-visit intake record by appending a visit type identify identifying the visit type record; and causing to display a visit type interface representative of the visit type record on a screen of at least one computing device associated with at least one user of the user visit, including an indication of the emergency attribute and the test attribute.