Integrated Hosted Solutions

This application claims priority to and the benefit of U.S. Provisional Application No. 63/575,337, filed Apr. 5, 2024, titled “INTEGRATED HOSTED SOLUTIONS,” the disclosure of which is hereby incorporated by reference in its entirety.

This disclosure relates generally to data transmission, and more particularly to facilitating and optimizing transmission of requests from a user device using an integrated service associated with a provider management software.

Healthcare providers, clinicians, health clinics, hospitals, specialty practices, dental offices, or any other related healthcare-associated provider may utilize a practice management software to facilitate transactions between the healthcare provider and a patient, organize patient data, schedule appointments, and/or any other administrative task necessary to conduct business as a healthcare provider. The practice management software may be operated by a third-party entity, but customized for the healthcare provider. In some examples, the practice management software is not conducive to managing complicated transactions (e.g., payment with credit, payment by an individual other than the patient, etc.) and requires additional effort by the healthcare provider to complete the complicated transaction. Additionally, in some examples, the practice management software may not include a method of managing transactions at all, requiring the healthcare provider to identify a secondary software that must be cooperative with the practice management software.

Methods are described herein for facilitating and optimizing transmission of one or more requests from a user device using an integrated service associated with an independent software vendor (ISV). In some examples, the method may include receiving a request to initiate a secured transaction associated with a patient account, where the request is received by a server associated with an integrated service, and where a plurality of instances of the request are performed by the server simultaneously. The method may also include generating one or more inquiries pertaining to the secured transaction, where the one or more inquiries are generated using the request, and where the one or more inquiries are requests for information used to process the secured transaction. The method may also include transmitting, using a first custom application programming interface (API) a data request to a secured database for patient data associated with the secured transaction and the patient account. The method may also include receiving, from the secured database using the first custom API, the patient data. The patient data may include secure private data associated with the secured transaction. The method may also include populating a portion of the one or more inquiries by generating a comparison of the one or more inquiries to the patient data and by identifying at least one matching inquiry based on the comparison. The at least one matching inquiry may indicate that an element of patient data corresponds to an inquiry from the one or more inquiries. The method may also include facilitating presentation of the one or more inquiries on a user interface of a display device, wherein the portion of the one or more inquiries are distinguished upon presentation by populating the portion of the one or more inquiries with respective elements of patient data.

Systems are described herein for facilitating and optimizing transmission of one or more requests from a user device using an integrated service. The systems may comprise one or more processors and a memory storing instructions that, as a result of being executed by the one or more processors, cause the system to perform any of the aforementioned methods.

Non-transitory computer-readable storage media are described herein that store instructions therein that, as a result of being executed by one or more processors, cause the one or more processors to perform the any of the aforementioned methods.

Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations can be used without parting from the spirit and scope of the disclosure. Thus, the following description and drawings are illustrative and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding of the disclosure. However, in certain instances, well-known or conventional details are not described in order to avoid obscuring the description. References to one or an embodiment in the present disclosure can be references to the same embodiment or any embodiment; and such references mean at least one of the embodiments.

Reference to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which can be exhibited by some embodiments and not by others.

The terms used in this specification generally have their ordinary meanings in the art, within the context of the disclosure, and in the specific context where each term is used. Alternative language and synonyms can be used for any one or more of the terms discussed herein, and no special significance should be placed upon whether or not a term is elaborated or discussed herein. In some cases, synonyms for certain terms are provided. A recital of one or more synonyms does not exclude the use of other synonyms. The use of examples anywhere in this specification including examples of any terms discussed herein is illustrative only and is not intended to further limit the scope and meaning of the disclosure or of any example term. Likewise, the disclosure is not limited to various embodiments given in this specification.

Without intent to limit the scope of the disclosure, examples of instruments, apparatus, methods, and their related results according to the embodiments of the present disclosure are given below. Note that titles or subtitles can be used in the examples for convenience of a reader, which in no way should limit the scope of the disclosure. Unless otherwise defined, technical and scientific terms used herein have the meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. In the case of conflict, the present document, including definitions will control.

Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims or can be learned by the practice of the principles set forth herein.

In the appended figures, similar components and/or features can have the same reference label. Further, various components of the same type can be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.

In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of certain inventive embodiments. However, it will be apparent that various embodiments may be practiced without these specific details. The figures and description are not intended to be restrictive. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or designs.

Disclosed embodiments may provide a framework through which one or more machine learning algorithms and programmatic logic are implemented to dynamically, and in real-time, process incoming invoices and corresponding claims as these invoices are received to identify one or more conditions for which treatment was provided. Based on these identified one or more conditions, as well as any known historical data corresponding to the claimant, adjudication of the invoices and corresponding claims may be performed.

The present disclosure includes a system and method for facilitating transactions with an integrated service associated with an independent software vendor (ISV), such as a third-party practice management software. An ISV may be a software, either installed on a local server, accessed via the Internet, accessible via cloud storage, any combination thereof, or the like, that a software user (e.g., a healthcare provider and/or healthcare office) may access to manage operations. For example, the ISV may be used to manage patient data, schedule and track appointments, communicate with patients, update medical records of patients, facilitate transactions, any combination thereof, or the like. In some examples, the ISV may be hosted on a central server and/or cloud server and one or more devices, offices, departments, or the like, may access instances of the ISV accordingly. The integrated service may be incorporated into the ISV but may be managed by a central controller not associated with the ISV. For example, to conduct updates on the integrated service, the central controller may initiate the updates, and the updates may be automatically implemented in the integrated service without involvement from the ISV or an affiliate third-party.

An indication of the integrated service may appear on a user interface (e.g., a graphical user interface (GUI), a web page, an application, etc.) associated with the ISV. The indication may be in the form of a button, a link, a menu option, an icon, a title, any combination thereof, or the like. An administrator associated with the healthcare provider may select, “click,” touch (on a touchscreen interface), or the like, the indication to access the integrated service. Once the integrated service has been selected by the administrator on a device, the device may be redirected to a second GUI, webpage, application, or the like, associated with the integrated service. On the integrated service GUI, the administrator may navigate to achieve one or more goals, including facilitating a transaction, conducting a return, applying for a loan, communicating with a patient, any combination thereof, or the like. The administrator, depending on the goal, may be prompted to fill in information corresponding to the patient, healthcare provider, service, transaction, any combination thereof, or the like. For example, if the patient wishes to apply for a loan to pay for medical services, the administrator may be prompted to input the patient's name, contact information, social security number, income information (e.g., paystubs), data necessary to perform a credit check, any combination thereof, or the like.

The integrated service and the ISV may be incorporated such that the integrated service may access one or more secured databases associated with the ISV. For example, the ISV may manage a database (stored locally, on a cloud-based storage platform, any combination thereof, or the like) that may contain privileged health-related information associated with one or more patients. This may include medical history, demographic information, appointment history, social security numbers, contact information, payment information, and the like. The integrated service, through an encrypted and/or secured connection, may retrieve data from the one or more secured databases. Thus, when an administrator is attempting to facilitate a transaction on the integrated service, the integrated service may pre-populate one or more necessary fields with data from the one or more secured databases (e.g., name of patient, address of patient, social security number of patient, etc.), resulting in a more streamlined process for the patient, healthcare provider, and administrator.

The integrated service, once appropriate information has been received, may transmit a request to a transaction manager associated with the integrated service. The request may include a request to submit a payment, a request for a loan, a request to distribute a refund, any combination thereof, or the like. In response to the request, the transaction manager may process the request and transmit a response. For example, the transaction manager may notify the integrated service that the payment method was declined, the loan was approved, the refund has been initiated, any combination thereof, or the like. Subsequently, the integrated service may notify the ISV and/or the user device to “pull back” the data associated with the transaction (i.e., request data associated with the transaction, the request, the response from the transaction manager, etc.). The ISV may pull back the data and may update the one or more secured databases accordingly (e.g., add a transaction associated with a patient, add new billing information associated with a patient, update the appointment and payment history for a patient, etc.). The ISV may notify the administrator and/or the patient according to the response from the transaction manager. In some examples, the integrated service may notify the administrator and/or the patient.

illustrates an example block diagram for implementing an integrated serviceaccording to some aspects of the present disclosure. The integrated servicemay be a service implemented as a plug-in to a pre-existing third-party practice management software (ISV). The integrated servicemay assist healthcare providers in facilitating transactions, reviewing patient files, viewing a transaction status, any combination thereof, or the like. System, as shown in, may represent one or more components necessary to implement integrated servicewithin an ISV. The ISV may be associated with user device, which may access the ISV by downloading software, via the Internet on a subscription or otherwise, at an instance provided by a cloud provider, any combination thereof, or the like. User devicemay be a computing device associated with a healthcare provider and/or healthcare office. For example, user devicemay be a laptop, desktop computer, smartphone, tablet, or the like. Integrated servicemay be installed and/or linked within the ISV as an “add-in,” such that user devicemay access integrated servicethrough the ISV. For example, integrated servicemay appear as a “button,” link, tool, icon, or the like on a GUI associated with the ISV. Using the integrated servicebutton, a user associated with user devicemay initiate integrated serviceand begin operating integrated serviceto streamline one or more otherwise tedious services, such as facilitating payments, applying for loans, granting refunds, etc.

User devicemay request to launch integrated serviceby touching, clicking, or otherwise selecting the integrated servicebutton associated with the ISV. In some examples, the integrated servicebutton may be in different locations or represented in a different manner depending on the variety of ISV and/or GUI associated with the ISV. For example, a first third-party entity operating a first ISV may incorporate integrated servicethrough the addition of a “button” at the top of a GUI, while a second third-party entity operating a second ISV may incorporate integrated servicethrough the addition of a banner on the right-hand side of a GUI. The presentation of the integrated servicebutton on the ISV may not impact the functionality of integrated service. After user devicerequests to launch integrated service, integrated servicemay redirect user deviceto a website, GUI, application, or the like configured to present integrated serviceon user device. In some examples, the integrated serviceGUI may be included within the ISV program, hosted on an Internet site, in a separate application, hosted on a cloud provider, any combination thereof, or the like. The integrated serviceGUI may present one or more options to user device, such as “apply,” “purchase,” “refund,” “lookup,” or any other options that may be related to healthcare-related transactions. By clicking, touching, or otherwise selecting an option of the one or more options, user devicemay be additionally redirected to alternative locations within the integrated serviceGUI specially configured to process a type of request from user device.

Integrated servicemay include one or more components, including user inquiry system, transaction system, management system, and historical transaction data. Each component may be implemented individually or in combination to operate integrated service. Integrated servicemay communicate and transmit data with user deviceusing the components described herein, or other components associated with integrated service. Integrated servicemay be hosted on a remote server, a cloud provider, on a local device, any combination thereof, or the like.

A receptionist, doctor, hygienist, nurse, office administrator, or any other individual associated with a healthcare practice may access integrated serviceon user deviceto conduct some sort of action on behalf of a patient. For example, a patient may wish to make a payment for a healthcare service provided by the healthcare practice. When user deviceindicates a request to complete an action using integrated service(e.g., apply for a loan, make a purchase, refund a customer, etc.), the request may prompt user inquiry systemto generate one or more user inquiries necessary to complete the action. The one or more user inquiries may be based on prior transactions, requirements by transaction manager(e.g., a bank facilitating a loan may require particular information from the loan applicant, a payment processing entity may require particular information from a payor to complete a payment, etc.), generated by the healthcare practice (e.g., generated by an accounting department of a hospital, etc.), any combination thereof, or the like.

In some examples, the one or more user inquiries may be generated by a machine-learning algorithm trained to predict information necessary to complete a particular action. The machine-learning algorithm may receive the request to complete the action and may be trained to generate one or more user inquiries that may be related to the requested action. Examples of machine-learning algorithms include algorithms such as k-means clustering algorithms, fuzzy c-means (FCM) algorithms, expectation-maximization (EM) algorithms, hierarchical clustering algorithms, density-based spatial clustering of applications with noise (DBSCAN) algorithms, and the like. Other examples of machine learning or artificial intelligence algorithms include, but are not limited to, genetic algorithms, backpropagation, reinforcement learning, decision trees, linear classification, artificial neural networks, anomaly detection, and such. More generally, machine learning or artificial intelligence methods may include regression analysis, dimensionality reduction, meta-learning, reinforcement learning, deep learning, and other such algorithms and/or methods. In some instances, the machine-learning algorithm may be trained using training data received and/or derived from one or more actions and respective user inquiries associated with the one or more actions. In some examples, the first machine-learning model may be trained using training data received and/or derived from historical data (e.g., historical transaction data) associated with prior transactions associated with integrated service. In some instances, the first machine-learning model may be trained using data associated with other implementations of integrated service(e.g., an instance of integrated serviceassociated with another office, enterprise, or organization). The machine-learning algorithm can be trained using supervised training, supervised training, semi-supervised training, reinforcement training, combinations thereof, or the like.

For example, the machine-learning algorithm may be trained using transfer learning. Transfer learning is a technique in machine learning where a machine-learning algorithm initially trained to solve a particular task is used as the starting point for a different task. Transfer learning can be useful when the second task is somewhat similar to the first task, or when there is limited training data available for the second task. For example, a machine-learning algorithm initially trained to generate one or more user inquiries may be further trained to generate one or more user inquiries associated with a particular action (e.g., “make a payment”). In some instances, integrated servicemay access a pre-trained model and “fine-tune” the pre-trained model by training the pre-trained model on a second training dataset. The second training dataset can include training data that includes user inquiries that are labeled with one or more possible actions. To further fine-tune the machine-learning algorithm, integrated servicereconfigures the machine-learning algorithm to include additional hidden and/or output layers to recognize information necessary to complete a particular action. In some instances, fine-tuning the pre-trained model includes unfreezing some of the layers of the pre-trained model and training them on the new training dataset. The number of layers that are unfrozen can depend on the size of the new dataset and how similar it is to the original dataset. For example, the fine-tuning of the first machine-learning model can include freezing the weights of the first machine-learning model, to train the first machine-learning model to predict user inquiries necessary to complete a particular action. Then, the weights can be unfrozen such that the first machine-learning model can be trained to improve accuracy of the user inquiries. By improving accuracy of the machine-learning algorithm, this reduces the processing load on computers associated with integrated serviceby reducing the number of iterations necessary to gather information necessary to complete an action. Further, this reduces the likelihood that irrelevant information is gathered and processed, thereby reducing a processing load on the system.

The one or more user inquiries may include prompts requesting information to be input by user device. User devicemay input data through one or more input devices, including, but not limited to, a keyboard, a mouse, a microphone, and/or a touchscreen interface. For example, the individual associated with the healthcare practice may type in responses to the one or more user inquiries on the keyboard of a desktop computer. The prompts may include requests for patient data, transaction data, healthcare provider data, appointment data, payment method data, record locators, any combination thereof, or the like. For example, to complete payment for a healthcare appointment, integrated servicemay request a patient name or identification number, payment method, appointment type, a billing address, and an email to send a receipt. The individual associated with the healthcare practice may relay the one or more user inquiries to the patient and input responses on behalf of the patient. For example, a receptionist may ask for the patient's credit card information and may input the credit card information into integrated serviceusing user deviceon behalf of the patient.

In some examples, integrated servicemay determine to transmit the one or more user inquiries to patient device. The determination to transmit the one or more user inquiries may be performed by the machine-learning algorithm. The machine-learning algorithm may be further trained to determine whether or not to immediately transmit the one or more user inquiries to patient device(e.g., without presenting the user inquiries to user device). A third training dataset may include historical data associated with historical user inquiries associated with one or more user accounts. For example, the machine-learning algorithm may determine that historically, a first user calls to pay bills associated with a user account of the first user. Therefore, the machine-learning algorithm may automatically transmit the one or more user inquiries to patient devicebased on historical data associated with the first user. In some other examples, the machine-learning algorithm may automatically transmit the one or more user inquiries to patient devicebased on historical data associated with users similarly situated to the first user. For example, if the first user is a minor and is unlikely to pay a medical bill personally, the machine-learning algorithm may automatically transmit the one or more user inquiries to patient devicebased on historical data associated with other users that are also minors. In some examples, the one or more user inquiries may be transmitted to patient deviceafter receiving user input from user device(e.g., at a touchscreen, at a keyboard, with a mouse click, any combination thereof, or the like.) In some other examples, the one or more user inquiries may be transmitted to patient deviceafter a duration of time (e.g., 30 seconds pass without input from user device).

For example, if the patient wishes to fill out the one or more user inquiries discreetly (e.g., without relaying answers to a receptionist, etc.), the patient may request the one or more user inquiries be sent to her cell phone so the patient can input responses privately. In some other examples, this enables a parent of a minor to input payment information, confidential identification information, or otherwise as a response to one or more user inquiries without entrusting this information and/or data to a minor child attending a healthcare appointment without the parent (e.g., a 17-year-old child attending a dental cleaning without an accompanying parent, a parent is waiting in the car, etc.). The transmitted inquiries may include all of the one or more user inquiries or a select few of the one or more user inquiries. For example, user devicemay complete requests associated with the appointment and/or the healthcare provider and may transmit requests associated with payment information to patient device. All or some of the one or more user inquiries may be transmitted to patient devicevia email, text message, web link, any combination thereof, or the like. For example, user devicemay send an email containing an embedded link to patient device, where the embedded link redirects patient deviceto a website containing the one or more user inquiries transmitted to patient deviceby user device. In some other examples, patient devicemay receive SMS/text message/mobile message prompts containing a request. For example, patient devicemay receive a text message containing the question “What is the patient's date of birth?” Patient devicemay input a response to the question (e.g., “Apr. 10, 2001”) using one or more input methods, including a touchscreen interface, a microphone, etc.

In some examples, to expedite responding to requests of the one or more user inquiries, secured databasemay be accessed to generate responses to some, none, or all of the one or more user inquiries generated by user inquiry system. The one or more user inquiries generated by user inquiry systemmay be automatically populated with data stored within secured databasewithout input required from user deviceor patient device. For example, after user devicetransmits the request to complete an action and user inquiry systemgenerates one or more user inquiries necessary to complete the action, secured databasemay be queried to identify data pertinent to the one or more user inquiries. In some examples, a minimal amount of input may be required from user devicein order to identify pertinent information (e.g., integrated servicemay prompt user devicefor a patient name or birthday). In some other examples, using cached data, cookies, machine-learning, any combination thereof, or the like, integrated servicemay identify contextually relevant data in order to identify pertinent information within secured database. For example, the machine-learning algorithm may be further trained to identify contextually relevant data using a fourth training dataset that includes historical data (e.g., historical transaction data) that identifies contextually relevant data associated with an action a customer identifier. For example, the machine-learning algorithm may automatically identify contextually relevant data within secured databasebased on a customer name and an action.

As another example, if the ISV software had navigated to a particular patient profile, appointment, medical history, or otherwise, shortly before initiating integrated service, integrated servicemay identify data related to the particular patient profile, appointment, or medical history and use that data to identify pertinent information with secured database. The pre-population of responses to one or more user inquiries may assist the individual associated with the healthcare practice and/or the patient with responding to the one or more user inquiries. For example, upon presentation of the one or more user inquiries via user deviceto the individual associated with the healthcare practice, the individual may observe that some inquiries have already been “filled in” or “answered” by the data gathered from secured database. In some other examples, the “filled in” or “answered” inquiries may be omitted from the presentation of the one or more user inquiries via user device(e.g., the “filled in” inquiries are not presented on a user interface associated with user device) and/or transmission of the one or more user inquiries to patient device(e.g., the “filled in” inquiries are not transmitted to patient device). As a result, this reduces processing required to obtain data associated with the one or more user inquiries. Further, this procedure saves individuals associated with the transaction (e.g., the healthcare provider, the patient, the office administrator facilitating the transaction at user device, etc.) valuable time and increases office efficiency. Additionally, this procedure may increase accuracy of data by avoiding user input mistakes.

Secured databasemay store data related to patients, appointments, payment information, healthcare providers, medical history, any combination thereof, or the like. In some examples, secured databasemay be implemented by integrated service. The data may be stored according to a custom data structure and/or storage mechanism. The custom data structure and/or storage mechanism may be dependent on a search algorithm utilized by integrated serviceto identify pertinent information within secured database(e.g., linear search, binary search, hashing, sequential search, index-based search, graph search algorithms, distributed search algorithms, etc.). For example, secured databasemay utilize arrays, linked lists, stacks, queues, trees, graphs, hash tables, heaps, skip lists, any combination thereof, or the like, to store data within secured database. The custom data structure may be implemented in a relational database, NoSQL database, in-memory database, graph database, object-oriented database, cloud-based database, any combination thereof, or the like. For examples, secured databasemay store a patient's name, medical history, most recent appointment information, account balance, and/or any other relevant data in association with a patient ID number (e.g., a social security number, an ID number assigned by the healthcare provider or the ISV, etc.). Secured databasemay be secured using one or more mechanisms of security, including, but not limited to, encryption (e.g., SSL/TLS, RSA, hash, etc.), authentication, access control, inference control, flow control, etc. Secured databasemay receive the data from the ISV, the integrated service, user device, an external data source (e.g., a secondary cloud database source, local memory, another database, etc.), any combination thereof, or the like. Data stored within secured databasemay be “tagged” or given an alternative form of identifier to provide ease of search. For example, payment information associated with a particular patient may be stored with the tag “payment,” “credit card,” “payment method,” along with the name or reference ID of the particular patient, to quickly identify and satisfy a request of the one or more user inquiries for payment information.

User inquiry system, prior to transmitting the one or more user inquiries to user deviceand/or patient devicecontaining requests for data, may access secured databaseto determine which, if any, of the one or more user inquiries may be satisfied using data stored in secured database. For example, user inquiry system, using an identifier associated with the request to complete an action (e.g., a patient ID number, an appointment date and time, a patient name, a patient birth date, etc.) may query secured databasefor relevant data using one or more search algorithms (e.g., linear search, binary search, hashing, sequential search, index-based search, graph search algorithms, distributed search algorithms, etc.). The query and subsequent communications may be encrypted, protected, and/or secured through one or more means to preserve the sensitive information stored within secured database. For example, user inquiry systemmay query secured databasefor data matching a specific patient ID number provided by user deviceand/or the ISV, which may include a name, payment information, demographic information, income information, etc.

In some examples, user inquiry systemmay also receive data from user deviceand/or the ISV to satisfy one or more of the one or more user inquiries. The data may be transmitted through a secured communication channel (e.g., encryption, authentication, error detection, shielding, directional transmission, etc.). For example, the ISV may transmit data pertaining to a particular appointment (e.g., scheduled time, duration, procedures performed, etc.), a patient (e.g., name, age, etc.), healthcare provider (e.g., name, charge rate, etc.), etc. This data, in lieu of or in addition to data gathered from other sources (e.g., secured database, user device, patient device, etc.), may be gathered to satisfy requests of the one or more user inquiries.

User inquiry systemmay attempt to satisfy as many of the one or more user inquiries as possible using alternative sources (e.g., secured database, the ISV, etc.) prior to transmitting the remaining requests of the one or more user inquiries to user devicefor manual entry or transmission to patient devicefor manual entry. In some examples, the requests satisfied by the alternative sources may still be transmitted to user deviceand/or patient device, but may show as “complete” or may display the data provided by the alternative source and provide an opportunity for user deviceand/or patient deviceto manually modify the pre-populated data. For example, one or more user inquiries requesting a patient name, birthday, and Social Security number may be prepopulated and “filled out” using data from secured databaseand may be displayed as “filled out” when displayed via user deviceand/or patient device. However, user deviceand/or patient devicemay include capabilities to modify the prepopulated data if the patient's name, birthday, and/or Social Security number are incorrect. In some examples, if the prepopulated data is modified by user deviceand/or patient device, the modified data may be transmitted to secured databaseand the data stored within secured databasemay be updated (e.g., updating expired credit card information with new credit card information).

User deviceand/or patient devicemay submit responses to the one or more user inquiries to user inquiry system. User inquiry systemmay further transmit the responses to transaction system, which may cross-reference the responses with historical transaction datato determine the accuracy of the data provided. For example, transaction systemmay detect a disparity between an income provided in a prior transaction and an income provided in a current transaction. This disparity may be associated with a name, an income, an identifier (e.g., Social Security Number, customer identifier, invoice number, etc.), a medical diagnosis, a date of a recent appointment, a birth date, an age, a weight, a height, a credit card number, a bank account and/or routing number, a debit card number, an email, a phone number, medical history information, any combination thereof, or the like. In some examples, transaction systemmay determine whether to notify user deviceand/or patient deviceof the disparity. For example, the disparity may not materially impact the treatment and payment processing of a patient associated with the one or more user inquiries (e.g., weight, date of recent appointment). Thus, in some examples, transaction systemmay flag the disparity for future identification (e.g., using a tag and/or metadata) and may not notify user deviceand/or patient deviceof the disparity. However, in some other examples, transaction systemmay notify user deviceof the disparity. In some examples, depending on the disparity detected by transaction system, transaction systemmay reject the responses to the one or more user inquiries and return the one or more user inquiries to the user inquiry systemto be inspected and/or edited by user deviceand/or patient device. For example, if a credit card number, phone number, address, or any other response is found to be invalid by transaction system(e.g., by cross-referencing with an external third-party database, identifying a phone number response has an incorrect amount of digits, etc.), transaction systemmay reject the responses to the one or more user inquiries and may notify user deviceof the rejection and display at least the incorrect response via user devicefor correction. In some examples, the rejection of the responses may be used to further train the machine-learning algorithm.

Transaction systemmay store the responses to the one or more user inquiries in association with the current transaction in historical transaction data. Historical transaction datamay be accessed by integrated serviceand/or other associated components (e.g., user inquiry system, transaction system, management system, user device) to access data related to prior transactions conducted by integrated service. In some examples, historical transaction datamay periodically purge data according to criteria specified by integrated service, user device, the ISV, any combination thereof, or the like. The data may be purged according to transaction date (e.g., transactions older than five years), storage capacity (e.g., oldest transactions are purged first when historical transaction datareaches a certain size), transaction type (e.g., cash transactions are purged, while credit card transactions are kept), status (e.g., approved transactions are purged, while pending transactions are kept), any combination thereof, or the like.

Transaction system, once the data provided in response to the one or more user inquiries has been confirmed and approved by transaction system, may transmit the request and the corresponding responses to the one or more user inquiries to transaction manager. Transaction managermay be located on a remote server and may be associated with a third party. For example, transaction managermay be affiliated with a bank, loan manager, a point-of-sale service, integrated service manager, or the like. In some examples, integrated service managermay be included within the functionality described in system. Integrated service managermay be associated with integrated serviceand may contribute to the functionality of integrated serviceby providing updates, managing configurations, installing software, providing IT support, enforcing changes throughout a network of user devices (e.g., user deviceand secondary user device(s)), any combination thereof. Integrated service managermay be hosted in a location that may be the same or different as integrated service, user device, etc. For example, integrated service managermay be hosted on a remote server that may be able to connect to integrated service.

In some examples, transaction managermay identify one or more issues associated with the request and the corresponding responses. While transaction systemlocally verifies that the provided data is accurate, transaction managerverifies that the provided data is usable and sufficient to perform the desired action. For example, transaction managermay identify missing data (e.g., phone number, date of birth, email address, etc.), incorrect data (e.g., invalid or declined credit card number, invalid Social Security number, invalid banking information, etc.), unnecessary data (e.g., appointment information, entity-specific identifier, healthcare provider information, etc.), any combination thereof, or the like, may be identified by transaction manager. In response to identifying the one or more issues, transaction managermay transmit a notification to integrated serviceassociated with the one or more issues. The notification may include a request for more data, a request for revised data, a notification that excessive data was received, any combination thereof, or the like. Based on the notification, integrated servicemay perform one or more actions to remedy the one or more issues indicated in the notification. For example, integrated servicemay notify user device, may notify patient device, may generate additional user requests and transmit the additional user requests to patient deviceand/or user device(e.g., notify patient devicethat a credit card number was invalid and request updated credit card information), any combination thereof, or the like. In some examples, the one or more issues may be used to update and/or further train the machine-learning algorithm. The one or more issues may be included in a training dataset that is used to refine the generation of the one or more user inquiries.

In addition to being comprised of transaction manager, integrated service managermay also be comprised of central manager. Central managermay be a central controller responsible for implementing software updates, notifications indicating hardware updates, assisting with the implementation of integrated serviceinto the ISV software, any combination thereof, or the like. Central managermay be connected to multiple instances of integrated servicethat may be associated with a different ISV and/or a different user device. For example, software changes to integrated servicemay be implemented via central managerat Hospital and Dentist Office simultaneously, even if Hospital and Dentist Office are two distinct, unaffiliated users of integrated service.

If an update is received from central managerat integrated service, it may be processed through management system. Management systemmay facilitate the synchronization of integrated servicebetween central manager, user device, and secondary user device(s). For example, any settings associated with integrated servicethat are implemented by user devicemay be further implemented at secondary user device(s)via management system. Additionally, notifications, updates, changes, or any other transmission received from central managermay be implemented on integrated servicevia management system. For example, if central managertransmits an update to integrated servicethat alters the color of the “button” displayed on the GUI of the ISV, management systemmay implement that change on user device.

In some examples, a healthcare provider office may be associated with one or more “satellite” offices (i.e., affiliated offices or practices in another area of healthcare, another location, etc.). For example, user devicemay be associated with a “home” office of Dental Practice, and secondary user device(s)may be associated with one or more secondary locations of Dental Practice (e.g., Dental Practice #2 located in another town, Dental Practice #3 specializing in pediatric dental care, etc.). In some other examples, user deviceand secondary user device(s)may be associated with the same practice/location/office (e.g., user deviceis the “primary” while secondary user device(s)may be associated with individual rooms, stations, and/or offices within the location). In either scenario, changes implemented at the “home” or “primary” office on user devicepertaining to integrated servicemay be implemented on local sessions of integrated servicehosted at secondary user device(s). Secondary user device(s)may have complete access to integrated service, secured database, and any other components described herein that are also accessible to user device. However, secondary user device(s)may merely lack administrative authority and/or authentication to complete certain actions associated with integrated service, including, but not limited to, adding/removing data from secured databaseand/or historical transaction data, initiate a particular type of transaction (e.g., a loan), make setting changes associated with integrated service(e.g., notification preferences, time/location preferences, implementing recommended software updates, etc.), creating or altering patient profiles, any combination thereof, or the like.

Integrated servicemay be utilized by more than one healthcare provider office at one time. The different healthcare provider offices may access distinct instances of integrated servicethat may be customized to each individual healthcare provider office (e.g., historical transaction datamay be distinct for each individual healthcare provider office). However, integrated servicemay be hosting many requests for actions at one time from user deviceand/or other user devices with access to integrated service(e.g., secondary user device(s), user devices associated with other instances of integrated service, etc.). A server associated with integrated servicemay be capable of managing multiple requests simultaneously and may process data in real-time.

illustrates an example process for data transmission between one or more components associated with the integrated service according to some aspects of the present disclosure. The process demonstrated inis a mere example of how the components described inand throughout the specification may transmit data. In some examples, the steps described herein may happen in a different order than described, the steps may occur simultaneously, some steps may be omitted or combined with another step, multiple instances of the same step may be occurring simultaneously, etc.

The user devicemay be a user device similar to user device, as described in. It may be a personal computer, a tablet, a laptop, a desktop computer, a mobile phone, or the like. User devicemay be associated with a particular healthcare provider, practice, office, location, any combination thereof, or the like. On user device, a practice management software (ISV) may be installed. The ISV is a third-party software or resource that a healthcare practice may utilize to manage appointments, billings, patient files, or other administrative aspects of the healthcare practice. In some examples, the ISV may be downloaded to user device, a website accessed on the Internet, hosted by a cloud provider, hosted at a remote server, any combination thereof, or the like. An individual associated with the healthcare practice, such as an administrator, may access user deviceand the ISV.

Within the ISV may be a representation of integrated service. The representation may be demonstrated on a GUI associated with the ISV and integrated servicemay be represented by a “button,” a menu option, a link, a symbol, any combination thereof, or the like. To initiate integrated service, user device, using an input device (e.g., a keyboard, a mouse, a touch screen, a voice command, etc.) may select the representation of integrated serviceto launch integrated service. Upon the launch of integrated service, user devicemay be redirected to a custom GUI associated with integrated service, which may be hosted within the ISV software, at a website, at a cloud provider, at a remote server, any combination thereof, or the like.

At step, the user devicemay transmit a first request to integrated service. The first requested may be transmitted at the custom GUI associated with integrated servicevia the input device of user device. The first request may include a request to complete a particular action, such as completing a transaction, apply for credit, process a refund, lookup the status of a particular transaction, any combination thereof, or the like.

At step, integrated servicemay generate one or more user inquiries based on the first request. The one or more user inquiries may include requests for information and/or data required to complete the first request, such as patient information, appointment information, payment information, any combination thereof, or the like. The one or more user inquiries may be dependent on the action associated with the first request. For example, the one or more user inquiries may differ between a request to apply for credit (e.g., financial information of the patient, patient Social Security number, etc.) and a request to lookup the status of a particular transaction (e.g., transaction date, transaction ID number, patient ID number, etc.).

At step, integrated servicemay request patient data from secured databasethat correspond to the one or more user inquiries. Secured databasemay be queried for responses to the one or more user inquiries. For example, integrated servicemay query secured databasefor a patient's name, address, and phone number that have been requested as an inquiry of the one or more user inquiries. In some examples, integrated servicemay provide some initial identifying data to identify pertinent information within secured database. For example, integrated servicemay provide a patient ID number, a patient name, an appointment date and time, a type of service provided, any combination thereof, or the like. The initial identifying data may be used by a search algorithm (e.g., linear search, binary search, hashing, sequential search, index-based search, graph search algorithms, distributed search algorithms, etc.) to identify pertinent data within secured database(e.g., a name associated with a patient ID number, payment information associated with a patient ID number, etc.).

Secured databasemay be configured according to a custom data structure and/or storage mechanism. The custom data structure and/or storage mechanism may be dependent on the search algorithm used by integrated service. For example, secured databasemay utilize arrays, linked lists, stacks, queues, trees, graphs, hash tables, heaps, skip lists, any combination thereof, or the like, to store data within secured database. The custom data structure may be implemented in a relational database, NoSQL database, in-memory database, graph database, object-oriented database, cloud-based database, any combination thereof, or the like. For examples, secured databasemay store a patient's name, medical history, most recent appointment information, account balance, and/or any other relevant data in association with a patient ID number (e.g., a social security number, an ID number assigned by the healthcare provider or the ISV, etc.). Secured databasemay be secured using one or more mechanisms of security, including, but not limited to, encryption (e.g., SSL/TLS, RSA, hash, etc.), authentication, access control, inference control, flow control, etc.

At step, secured databasemay transmit the pertinent data identified by the search algorithm to integrated service. In some examples, the pertinent data may be presented as raw data to integrated service. Using an integrated logic mechanism, identifiers within the pertinent data (e.g., tags, labels, etc.), machine-learning, natural language processing, any combination thereof, or the like, integrated servicemay match the pertinent data to the one or more user inquiries. For example, integrated servicemay identify a string of digits and recognize that string of digits to be a credit card number, thereby matching an inquiry for “credit card number” with the string of digits.

At step, user devicemay present the one or more user inquiries via user device. The one or more user inquiries may be displayed via the ISV system, a GUI associated with integrated service, a website, any combination thereof, or the like. The one or more user inquiries may be displayed as a series of requests for information that a user of user devicemay “fill out” or “complete” using one or more input devices. In some examples, the presented one or more user inquiries may include inquiries that were matched with data obtained from secured database. In these examples, the matched inquiries may be presented via user devicebut may be displayed as already “filled out” or “completed.” In some examples, the user may manually modify the data supplied to the matched inquiries (e.g., if there is a mistake in the stored data, if the data needs to be updated, etc.). For example, if secured databasetransmits data associated with an expired credit card as a response to a user inquiry, the user of user devicemay modify the response with updated credit card information.