Collateralization of Medical Claims

The embodiments of the present disclosure generally relate to the field of healthcare system management. More particularly, the present disclosure relates to collateralization of medical claims for resource exchange.

The subject matter disclosed in the background section should not be assumed or construed to be prior art merely due to its mention in the background section. Similarly, any problem statement mentioned in the background section or its association with the subject matter of the background section should not be assumed or construed to have been previously recognized in the prior art.

In recent years, healthcare sector has been under tremendous financial pressure due to the increase of costs accompanied by the unpredictable cash flow. Majority of the revenue of a healthcare facility comes from reimbursement of medical claims submitted by the payers for the services they have been rendered. However, processing of these medical claims can be challenging and may take several months, causing a financial crunch for the medical facility due to which they struggle in managing their finances.

To tackle this issue, majority of the healthcare facilities (such as hospitals) rely on raising capital from financial providers (such as banks) which provide loans at high interest rates. Moreover, the loan interest rate varies for each healthcare facility based on their credit ratings dependent on various factors corresponding to their line of credit such as worth of assets, revenue generated, services offered, and the cash in hand. Another way to raise capital is through Muni Bonds or issue debt, which again depends on hospitals credit rating, market they operate in, and their balance sheet.

Contemporary approaches used by the healthcare systems to raise capital are also very cumbersome and expensive, due to high interest rates, high number of agreements, and plethora of rules and regulations, which adds to the challenges of the healthcare systems. In view of the above-mentioned challenges, there is a requirement of a technical solution to address the broader problem.

The following embodiments present a simplified summary in order to provide a basic understanding of some aspects of the disclosed invention. This summary is not an extensive overview, and it is not intended to identify key/critical elements or to delineate the scope thereof. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

According to an embodiment, a method for collateralizing medical claims is presented. The method includes receiving, from a medical facility, a request to collateralize a medical claim corresponding to at least one medical service rendered by the medical facility. The request to collateralize the medical claim comprises details of the medical claim and details of at least one preferred primary client to collateralize the medical claim. The method further includes retrieving, from the request to collateralize the medical claim, a set of input parameters for the medical claim. The set of input parameters includes a claim identifier, a claim amount, a claim date, and details of the at least one preferred primary client, for the medical claim. Furthermore, the method includes retrieving, from a database, a historical claim data corresponding to a plurality of claim settlements. Furthermore, the method includes determining, through a first Machine Learning (ML) model using the set of input parameters and the historical claim data, a set of output parameters for the medical claim. The set of output parameters includes a risk score for the medical claim, an expected claim settlement date, and a collateral value for the medical claim. The risk score and the collateral value for each medical claim dynamically change based on a variation in a claim age value of the medical claim, a days to pay (DTP) value for the medical claim, and/or a new claim settlement entry in the historical claim data for training the first ML model, or a combination of the aforementioned. Furthermore, the method includes generating a first request for the at least one preferred primary client using the set of input parameters and the set of output parameters. Furthermore, the method includes determining, whether a first acknowledgement is received from the at least one preferred primary client in response to the first request. Furthermore, in response to the reception of the first acknowledgement, the method includes generating a dashboard entry for the medical claim using the set of input parameters and the set of output parameters. Moreover, the method includes adding the dashboard entry to the database.

In some aspects of the present disclosure, prior to the addition of the dashboard entry in the database, the method further includes associating a medical facility identifier and at least one preferred primary client identifier with the dashboard entry.

In some aspects of the present disclosure, the claim age value corresponds to a duration between a present temporal value and the claim date. The days to pay value corresponds to a duration between the present temporal value and the expected claim settlement date.

In some aspects of the present disclosure, the method further includes determining, for the medical claim, a risk category from a plurality of risk categories based on the risk score associated with the medical claim. Furthermore, the method includes updating the set of output parameters by associating the determined risk category to the medical claim.

In some aspects of the present disclosure, the method further includes receiving a second request from the medical facility, where the second request includes a net collateral value, details of a secondary client, and a concentration limit corresponding to a maximum percentage of the net collateral value associated with each of the at least one primary client. Furthermore, the method includes determining, through a second ML model, a first set of medical claims from the plurality of medical claims based on the second request. Furthermore, the method includes retrieving, from the database, a first set of dashboard entries corresponding to the first set of medical claims. Furthermore, the method includes determining, through the second ML model, a first monitory value corresponding to the first set of medical claims, using the first set of dashboard entries. Furthermore, the method includes generating a third request for the secondary client using the first set of dashboard entries and the first monitory value. Furthermore, the method includes determining, whether a third acknowledgement is received from the secondary client in response to the third request. Furthermore, the method includes generating a resource exchange entry in response to the reception of the third acknowledgement and storing the resource exchange entry into the database.

In some aspects of the present disclosure, prior to the storage of the resource exchange entry in the database, the method further includes associating the medical facility identifier and a secondary client identifier with the resource exchange entry.

In some aspects of the present disclosure, the method further includes receiving a dashboard request from a user device associated with at least one of, the medical facility, the secondary client, or the at least one preferred primary client. The dashboard request comprises user defined input corresponding to at least of the medical facility identifier, the secondary client identifier, or the at least one preferred primary client identifier. Furthermore, the method includes determining, using a third ML model, one or more entries stored in the database based on the dashboard request and rendering the entries on the user device. The one or more entries includes at least one of, one or more dashboard entries, one or more resource exchange entries, or a combination thereof, corresponding to the user defined input.

In some aspects of the present disclosure, the new claim settlement entry in the historical claim data corresponds to a change in at least one of, a ranking of each of the at least one primary client, a rating of each of the at least one primary client, and a status of each of the at least one primary client.

According to another embodiment, a system to collateralize medical claims is presented. The system includes a database and a data processing circuitry communicatively coupled to the database. The data processing circuitry is configured to receive, from a medical facility, a request to collateralize a medical claim corresponding to at least one medical service rendered by the medical facility. The request to collateralize the medical claim comprises details of the medical claim and details of at least one preferred primary client to collateralize the medical claim. The data processing circuitry is further configured to retrieve, from the request to collateralize the medical claim, a set of input parameters for the medical claim. The set of input parameters comprises a claim identifier, a claim amount, a claim date, and details of the at least one preferred primary client, for the medical claim. Furthermore, the data processing circuitry is configured to retrieve, from the database, a historical claim data corresponding to a plurality of claim settlements. Furthermore, the data processing circuitry is configured to determine, through a first Machine Learning (ML) model using the set of input parameters and the historical claim data, a set of output parameters for the medical claim. The set of output parameters comprises a risk score for the medical claim, an expected claim settlement date, and a collateral value for the medical claim. The risk score and the collateral value for each medical claim dynamically change based on at least one of a variation in a claim age value of the medical claim, a days to pay (DTP) value for the medical claim, and a new claim settlement entry in the historical claim data for training the first ML model. Furthermore, the data processing circuitry is configured to generate a first request for the at least one preferred primary client using the set of input parameters and the set of output parameters. Furthermore, the data processing circuitry is configured to determine, whether a first acknowledgement is received from the at least one preferred primary client in response to the first request. Furthermore, the data processing circuitry is configured to generate, in response to the reception of the first acknowledgement, a dashboard entry for the medical claim using the set of input parameters and the set of output parameters. Moreover, the data processing circuitry is configured to add the dashboard entry to the database.

According to yet another embodiment, a computer-program product for collateralizing a plurality of medical claims is presented. The computer program product comprises computer-executable instructions that are stored on a non-transitory computer-readable medium and that, when executed by a data processing circuitry performs operations. The operations include receiving, from a medical facility, a request to collateralize a medical claim corresponding to at least one medical service rendered by the medical facility. The request to collateralize the medical claim comprises details of the medical claim and details of at least one preferred primary client to collateralize the medical claim. The operations further include retrieving, from the request to collateralize the medical claim, a set of input parameters for the medical claim. The set of input parameters includes a claim identifier, a claim amount, a claim date, and details of the at least one preferred primary client, for the medical claim. The risk score and the collateral value for each medical claim dynamically change based on at least one of a variation in a claim age value of the medical claim, a days to pay (DTP) value for the medical claim, and a new claim settlement entry in the historical claim data for training the first ML model. Furthermore, the operations include retrieving, from a database, a historical claim data corresponding to a plurality of claim settlements. Furthermore, the operations include determining, through a first Machine Learning (ML) model using the set of input parameters and the historical claim data, a set of output parameters for the medical claim. The set of output parameters includes a risk score for the medical claim, an expected claim settlement date, and a collateral value for the medical claim. Furthermore, the operations include generating a first request for the at least one preferred primary client using the set of input parameters and the set of output parameters. Furthermore, the operations include determining, whether a first acknowledgement is received from the at least one preferred primary client in response to the first request. Furthermore, in response to the reception of the first acknowledgement, the operations include generating a dashboard entry for the medical claim using the set of input parameters and the set of output parameters. Furthermore, the operations include adding the dashboard entry to the database.

Inventive concepts of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of one or more embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Further, the one or more embodiments disclosed herein are provided to describe the inventive concept thoroughly and completely, and to fully convey the scope of each of the present inventive concepts to those skilled in the art. Furthermore, it should be noted that the embodiments disclosed herein are not mutually exclusive concepts. Accordingly, one or more components from one embodiment may be tacitly assumed to be present or used in any other embodiment.

The following description presents various embodiments of the present disclosure. The embodiments disclosed herein are presented as teaching examples and are not to be construed as limiting the scope of the present disclosure. The present disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary design and implementation illustrated and described herein, but may be modified, omitted, or expanded upon without departing from the scope of the present disclosure.

The following description contains specific information pertaining to embodiments in the present disclosure. The detailed description uses the phrases “in some embodiments” which may each refer to one or more or all of the same or different embodiments. The term “some” as used herein is defined as “one, or more than one, or all.” Accordingly, the terms “one,” “more than one,” “more than one, but not all” or “all” would all fall under the definition of “some.” In view of the same, the terms, for example, “in an embodiment” refers to one embodiment and the term, for example, “in one or more embodiments” refers to “at least one embodiment, or more than one embodiment, or all embodiments.”

The term “comprising,” when utilized, means “including, but not necessarily limited to;” it specifically indicates open-ended inclusion in the so-described one or more listed features, elements in a combination, unless otherwise stated with limiting language. Furthermore, to the extent that the terms “includes,” “has,” “have,” “contains,” and other similar words are used in either the detailed description, such terms are intended to be inclusive in a manner similar to the term “comprising.”

In the following description, for the purposes of explanation, various specific details are set forth to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features.

The description provided herein discloses exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the foregoing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing any of the exemplary embodiments. Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it may be understood by one of the ordinary skilled in the art that the embodiments disclosed herein may be practiced without these specific details.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein the description, the singular forms “a”, “an”, and “the” include plural forms unless the context of the invention indicates otherwise.

The terminology and structure employed herein are for describing, teaching, and illuminating some embodiments and their specific features and elements and do not limit, restrict, or reduce the scope of the present disclosure. Accordingly, unless otherwise defined, all terms, and especially any technical and/or scientific terms, used herein may be taken to have the same meaning as commonly understood by one having ordinary skill in the art.

The present disclosure relates to a system and a method for collateralizing medical claims. In some aspects of the present disclosure, the method includes a number of processes that may be utilized to provide a technical solution to the existing healthcare problems related to unpredictable cash flow. Particularly, the method includes a process to generate a dashboard entry corresponding to a medical claim. The dashboard entry includes various information fields corresponding to the medical claim related to a monitory value (i.e., a dynamic collateral value) determined for the medical claim, status of risk associated with the medical claim, information of preferred primary client(s) for resource exchange in lieu of the medical claim as collateral, and the like. The status of risk as well as the monitory value of the medical claim is dependent on a time duration that has passed since the medical claim has been generated. For example, the monitory value of the medical claim decreases as the time passes, whereas the risk associated with the medical claim increases with time.

The method further includes a process for exchanging resources in lieu of the collateralized claims. Furthermore, the method includes a process for managing the resource exchange as the monitory amount of the collateralized claims is dynamic. Moreover, the method includes presenting dashboard(s) including information about collateralization of medical claims, resource exchange, as well as details of various entities involved in the system such as collaterals, risk associated with the collaterals, and the like.

Some embodiments of the present disclosure relate to use of Machine Learning (ML) models to determine a dynamic risk score and a dynamic collateral value associated with a medical claim for collateralization. The ML models are trained using historical claim settlement data as well as various details of a payer of the medical claim, based on which the ML models are trained to determine a dynamic risk score as well as a monitory value for the medical claim as collateral. The ML models are further utilized to determine an amount that can be requested as a loan from a financial partner, when the medical claim is submitted as collateral. Moreover, the ML models are trained to generate a dynamic dashboard for a user of the system based on a set of inputs received from the user.

Some embodiments of the present disclosure relate to providing risk profile(s) of the collaterals along with analysis & trends of data for secondary client(s), based on which the secondary client(s) can make a decision for collateralization of the medical claim(s). In some aspects of the present disclosure, the secondary client may further be enabled to track the collaterals through a life cycle of the medical claims and make informed decision.

Some other embodiments of the present disclosure relate to designing a set of protocols for the exchange of monitory resources (such as a loan from a bank) in lieu of the medical claims as collaterals. In simpler words, the set of protocols relate to generating and managing claims portfolio in terms of a monitory value as well as a risk associated with using these medical claims as collaterals. Some embodiments of the present disclosure support access to alternate capital raised through “asset backed lending program” for collateralized claims funding facility. Some other embodiments of the present disclosure relate to managing resource exchange for the collateralized claims.

The following description provides specific details of certain aspects of the disclosure illustrated in the drawings to provide a thorough understanding of those aspects. It should be recognized, however, that the present disclosure can be reflected in additional aspects and the disclosure may be practiced without some of the details in the following description.

1 FIG. 11 FIG. Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings.through, discussed below, and the embodiments used to describe the principles of the present disclosure are by way of illustration only and should not be construed in any way to limit the scope of the present disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged system or device.

Various aspects including the example aspects are now described more fully with reference to the accompanying drawings, in which the various aspects of the disclosure are shown. The disclosure may, however, be embodied in different forms and should not be construed as limited to the aspects set forth herein. Rather, these aspects are provided so that this disclosure is thorough and complete, and fully conveys the scope of the disclosure to those skilled in the art. In the drawings, the sizes of components may be exaggerated for clarity.

1 FIG. 1 FIG. 100 100 102 104 106 108 110 100 112 102 114 102 104 116 104 104 116 116 116 100 106 118 118 100 a c a c presents a block diagram of a systemto collateralize medical claims, in accordance with an exemplary aspect of the present disclosure. The systemmay include an end user device, primary client device(s), a secondary client device, and a data processing serversupported by ML model(s). Various entities of the systemmay be communicatively coupled to each other by a network. The end user devicemay be associated with the medical facility rendering medical services to patient(s) and may be operated by an end user(e.g., hospital staff operating the end user deviceon behalf of the medical facility). Each primary client devicemay be operated by a primary client. For illustration,presents first through third primary client devices-operated by first through third clients-, respectively. Specifically, the primary clientsmay be financial payers, that are registered with the systemand may be capable of providing their resources (monetarily) in exchange of medical claim(s) as collateral. The secondary client devicemay be operated by the secondary client. Specifically, the secondary clientmay be a financial partner (such as a bank) registered with the systemthat may provide monitory resources (i.e., by way of a loan) to the medical facility in exchange of the collateralized medical claim(s).

102 114 102 114 116 118 102 114 108 114 116 118 In some aspects of the present disclosure, the end user devicemay enable the end userto provide input(s) for collateralization of medical claim(s) rendered by the medical facility. The end user devicemay enable the end userto provide multiple selection inputs corresponding to a request to collateralize the medical claim(s). Specifically, the selection inputs may correspond to a selection of the medical claim(s) to be collateralize, a selection of preferred primary client(s), a request for exchange of collateralized medical claim with resources of the secondary client, and the like. In some other aspects of the present disclosure, the end user devicemay further facilitate the end userto view a claim portfolio for the collateralized medical claim. Specifically, the claim portfolio may be generated by the data processing serverbased on transaction(s) between the end userand the clients (cumulatively referring to the primary clientsand the secondary client).

104 116 102 104 116 102 116 108 108 104 116 116 104 116 In some aspects of the present disclosure, the primary client devicemay enable a corresponding primary clientto receive request(s) from the end user device. The request(s) may correspond to collateralizing medical claim(s) for medical service(s) rendered by the medical facility. The primary client devicemay further enable the primary clientto provide selection input(s) to accept or reject request(s) from the end user device. Furthermore, based on the selection input(s) by the primary client, the data processing servermay be configured to collateralize the medical claim(s) or discard the request to collateralize the medical claim(s). Moreover, when the medical claim(s) are collateralized, the data processing servermay generate dashboard entries corresponding to each medical claim. The primary client devicemay further enable the primary clientto provide display selection input(s), based on which a dashboard may be rendered (e.g., displayed or presented) to the primary clientthrough the primary client device. The dashboard facilitates the primary clientto manage collateralized transactions with the medical facility.

104 104 104 116 116 104 104 104 104 a c, a c, a c, The presented embodiment shows three primary client devices(i.e., the first through third primary client devices-operated by the first through third primary clients-respectively), however the scope of the present disclosure is not limited to it. In other embodiments, the primary client devicesmay have any number of primary client devices, without deviating from the scope of the present disclosure. All the primary client devicesmay be structurally and functionally similar to the first through third primary client devices-as presented herein.

106 118 102 118 114 118 106 118 102 118 108 118 106 118 118 106 118 In some aspects of the present disclosure, the secondary client devicemay enable the secondary clientto receive resource exchange request(s) from the end user device. The resource exchange request(s) may enable the secondary clientto be informed of the collateralized medical claim(s) extended by the end userin exchange of monitory resources (e.g., a loan) from the secondary client. The secondary client devicemay further enable the secondary clientto accept or reject the resource exchange request(s) from the end user device. Moreover, when the secondary clientaccepts the resource exchange request(s), the data processing servermay generate resource exchange entries corresponding to the resource exchange between the medical facility and the secondary client. The secondary client devicemay further facilitate the secondary clientto provide selection input(s) to select data fields corresponding to instances of the resource exchange(s) between the secondary clientand the medical facility. Based on the selection input(s), the secondary client devicemay further render information of resource exchange to the secondary client.

102 104 106 400 108 112 108 108 116 118 400 4 FIG. The end user device, the primary client device(s), and the secondary client device(presented later inas ‘user device’ and cumulatively referred to as ‘user devices’) may be capable of communicating with the data processing serverthrough the network. Each of the user devices may have an electronic application installed, that enables them to interact with the data processing server. The electronic application may be hosted by the data processing serversuch that an application interface of the electronic application may enable the users to provide input(s) and receive output(s) corresponding to collateralization of medical claim(s) and managing resource exchange between the medical facility and the clients (hereinafter referring cumulatively to the primary clientsand the secondary client). Examples of the user devices may include, but are not limited to portable handheld electronic devices such as a mobile phone, a tablet, a laptop, a smart watch etc., or fixed electronic devices such as a desktop computer, computing devices, etc. Aspects of the present disclosure are intended to include or otherwise cover any type of user device as the user device, without deviating from the scope of the present disclosure.

108 108 108 116 118 108 100 108 108 114 116 118 The data processing servermay be configured to perform data processing and/or data storage operations to collateralize the medical claim(s). More particularly, the data processing servermay be configured to create dashboard entries corresponding to acknowledged request(s) for collateralization of the medical claim(s). The data processing servermay further be configured to create resource exchange entries corresponding to acknowledged request(s) for resource exchange between the medical facility and the client(s) (cumulatively referring to the primary clientand the secondary client). Furthermore, the data processing servermay be configured to create dashboard entries for onboarding of client(s) to use the system. Furthermore, the data processing servermay be configured to manage the resource exchange(s) between the medical facility and the client(s). In some aspects of the present disclosure, based on the selection input(s), the data processing servermay be configured to generate dashboard(s) to be presented to the user (cumulatively referring to the end user, the primary client, and the secondary client).

108 108 108 108 The data processing servermay be a network of computers, a software framework, or a combination thereof, that may provide a generalized approach to create a server implementation. Examples of the data processing servermay include, but are not limited to, personal computers, laptops, mini-computers, mainframe computers, any non-transient and tangible machine that can execute a machine-readable code, cloud-based servers, distributed server networks, or a network of computer systems. The data processing servermay be realized through various web-based technologies such as, but not limited to, a Java web-framework, a .NET framework, a personal home page (PHP) framework, or any web-application framework. In various aspects of the present disclosure, the data processing servermay be configured to perform data processing and/or storage operations to enable collateralization of the medical claims.

108 120 122 120 108 120 The data processing servermay include data processing circuitryand a server memory. The data processing circuitrymay include processor(s) configured with suitable logic, instructions, circuitry, interfaces, and/or codes for executing operations of various operations performed by the data processing serverfor computations and data processing related to collateralization of the medical claims. Examples of the data processing circuitrymay include, but are not limited to, an Application Specific Integrated Chip (ASIC) processor, a RISC processor, a CISC processor, a Field Programmable Gate Array (FPGA), and the like.

122 120 100 108 122 The server memorymay be configured to store the logic, instructions, circuitry, interfaces, and/or codes of the data processing circuitryfor executing various operations of the system. Aspects of the present disclosure are intended to include and/or otherwise cover any type of the data associated with the data processing server, without deviating from the scope of the present disclosure. Examples of the server memorymay include but are not limited to, a ROM, a RAM, a flash memory, a removable storage drive, a HDD, a solid-state memory, a magnetic storage drive, a PROM, an EPROM, and/or an EEPROM.

108 124 124 108 100 112 124 124 108 100 Moreover, the data processing servermay also include a network interface. The network interfacemay be configured to enable the data processing serverto communicate with various other entities of the systemvia the network. Examples of the network interfacemay include, but are not limited to, a MODEM, a network interface such as an Ethernet card, a communication port, and/or a Personal Computer Memory Card International Association (PCMCIA) slot and card, an antenna, a radio frequency (RF) transceiver, amplifier(s), a tuner, oscillator(s), a digital signal processor, a coder-decoder (CODEC) chipset, a Subscriber Identity Module (SIM) card, and a local buffer circuit. It will be apparent to a person of ordinary skill in the art that the network interfacemay include any device and/or apparatus capable of providing wireless or wired communications between the data processing apparatusand various other entities of the system.

108 110 100 110 110 110 110 108 The data processing servermay be supported by ML modelsto perform data processing task(s) associated with the operations of the system. The ML modelsmay be trained to determine a dynamic risk value and an associated dynamic collateral value for a medical claim (i.e., a monitory equivalent value for the medical claim collateralized as asset). The ML modelsmay further be configured to determine medical claim(s) from a number of medical claims associated with the medical facility to be collateralized for resource exchange with the clients based on selection inputs from the clients (such as a net collateral value, a collateral exchange value, and the like). Furthermore, the ML modelsmay be trained to generate dashboard entries for the clients reflecting resource exchange transaction(s) between the clients based on a user selection. In some aspects of the present disclosure, the ML modelsmay be hosted by external datacenter(s). The external datacenter(s) may include suitable logic, circuitry, and/or code(s) to store data and perform computational tasks to support the data processing server. Examples of the external data center(s) may include, but are not limited to Oracle Database, Amazon Web Services (AWS) Database, and the like.

112 100 112 100 112 The networkmay include suitable logic, circuitry, and interfaces that may be configured to provide several network ports and several communication channels for transmission and reception of data related to operations of various entities of the system. Each network port may correspond to a virtual address (or a physical machine address) for transmission and reception of the communication data. For example, the virtual address may be an Internet Protocol Version 4 (IPV4 ) (or an IPV6 address) and the physical address may be a Media Access Control (MAC) address. The networkmay be associated with an application layer for implementation of communication protocols based on communication requests from the various entities of the system. The communication data may be transmitted or received via the communication protocols. Examples of the communication protocols may include, but are not limited to, Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), Domain Network System (DNS) protocol, Common Management Interface Protocol (CMIP), Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), Long Term Evolution (LTE) communication protocols, or any combination thereof. In some aspects of the present disclosure, the communication data may be transmitted or received via at least one communication channel of several communication channels in the network. The communication channels may include, but are not limited to, a wireless channel, a wired channel, a combination of wireless and wired channel thereof. The wireless or wired channel may be associated with a data standard which may be defined by one of a Local Area Network (LAN), a Personal Area Network (PAN), a Wireless Local Area Network (WLAN), a Wireless Sensor Network (WSN), Wireless Area Network (WAN), Wireless Wide Area Network (WWAN), a metropolitan area network (MAN), a satellite network, the Internet, an optical fiber network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, and a combination thereof. Aspects of the present disclosure are intended to include or otherwise cover any type of communication channel, including known, related art, and/or later developed technologies.

2 FIG. 2 FIG. 108 108 108 120 122 124 200 201 202 illustrates a block diagram depicting the data processing server, in accordance with an exemplary embodiment of the present disclosure. The data processing servermay be configured to perform data processing task(s) and data storage task(s) for collateralization of the medical claims. According to the exemplary embodiment as presented through, the data processing servermay include the data processing circuitry, the server memory, the network interface, an input-output (I/O) interface, and a console hostcoupled to each other by way of a first communication bus.

200 108 108 108 The I/O interfacemay include suitable logic, circuitry, interfaces, and/or codes that may be configured to receive input(s) and render output(s) by or from the data processing server, respectively. The input(s) may correspond to operation(s) and configuration(s) of various components of the data processing server. The output(s) may correspond to an operational status of various components of the data processing server.

201 108 201 108 The console hostmay include suitable logic, circuitry, interfaces, and/or codes that may be configured for executing various operations of the electronic application on the user devices, by way of which a user can trigger the data processing serverto collateralize the medical claims. In some other aspects of the present disclosure, the console hostmay further provide Graphical User Interfaces (GUIs) for the data processing serverfor user interaction.

2 FIG. 120 203 204 206 208 210 212 214 120 216 In the exemplary embodiment as presented through, the data processing circuitrymay include a profile generator, a data exchanger, a trade analyzer, a data estimator, a trade generator, a portfolio constructor, and an internal clock. Various components of the data processing circuitrymay be communicatively coupled to each other by way of a second communication bus.

203 102 104 106 The profile generatormay be configured to receive user registration data from the user devices (cumulatively referring to the end user device, the primary client devices, and the secondary client device). The user registration data may include personal identifier containing identity information of the user of the user device. In some aspects of the present disclosure, the user registration data may also include biometric data of the user such as, but not limited to, fingerprints, iris scans, images, voice samples, and the like associated with the user. Aspects of the present disclosure are intended to include or otherwise cover any type of biometric data of the plurality of users without deviating from the spirit and scope of the present disclosure.

203 203 203 203 203 100 203 100 203 100 203 The profile generatormay further be configured to authenticate the user registration data. In some aspects of the present disclosure, the profile generatormay be configured to fetch an identity data of the user from external sources. Furthermore, the profile generatormay fetch identity information from the identity data and may compare the identity information fetched from the user registration data with the identity information derived from the identity data. In a scenario, when both the information data match with each other, the profile generatormay authenticate the identity of the user and may proceed to generate a user profile for the user based on the identity information derived from the user registration data. In some aspects of the present disclosure, the profile generatormay enable the user to set the password protection for logging-in to the system. In such a scenario, the profile generatormay be configured to verify a password entered by the user for logging-in to the systemby comparing the password entered by the user with the set password protection. In a scenario, when the password entered by the user is verified, the profile generatormay enable the user to log-in to the system. In a scenario, when the password entered by the user is not verified, the profile generatormay generate a login error signal to enable a login error to be displayed on the user device.

203 203 102 116 118 8 FIG.(A) 8 FIG.(I) In some other aspects of the present disclosure, the profile generatormay further be configured to generate dashboard elements (e.g., data input elements and/or data display elements) to facilitate the user to provide input(s) and receive output(s) related to user details. For example, the profile generatormay generate dashboard elements to add, edit, and/or display details corresponding to the medical facility (i.e., corresponding to the end user device), the primary client, and the secondary client(presented later fromthrough.

204 122 104 106 102 120 204 102 116 204 122 204 116 116 116 The data exchangermay be configured to enable exchange of data and/or instruction(s) between the server memory, the primary client devices, the secondary client device, the end user device, and various other entities of the data processing circuitry. Particularly, the data exchangermay be configured to receive request(s) to collateralize the medical claim corresponding to medical service(s) rendered by the medical facility, from the end user device. The request to collateralize the medical claim may include details of the medical claim and details of preferred primary client(s)to collateralize the medical claim. The data exchangermay further be configured to retrieve a historical claim data corresponding to past claim settlements, from the server memory. In some aspects of the present disclosure, the historical claim data may be stored in an external database (not shown). In such a scenario, the data exchangermay be configured to generate a data fetch signal for the external database to retrieve the historical claim data from the external database. In some aspects of the present disclosure, the request to collateralize the medical claim(s) may correspond to resource exchange between the medical facility and the primary clients. Specifically, the request may be associated with generation of a trade between the medical facility and the primary client(s), which enables collateralized medical claims belonging to the medical facility to be exchanged for monitory resources of the primary client(s)(that may be referred to as payers of the collateralized claims).

204 102 118 118 118 118 The data exchangermay further be configured to receive a second request from the end user device. The second request may include a net collateral value, details of the secondary client, and a preferred risk category for the medical claim(s) to be exchanged for resources. In some aspects of the present disclosure, the second request may correspond to resource exchange between the medical facility and the secondary client. Specifically, the second request may be associated with generation of a trade between the medical facility and the secondary client, which enables collateralized medical claims belonging to the medical facility to be exchanged for monitory resources of the secondary client(to provide a loan to the medical facility in exchange of the collateralized medical claims).

204 110 Furthermore, the data exchangermay be configured to exchange data and/or instructions with the ML modelswhich may provide Artificial intelligence (AI) support for collateralization of the medical claim(s).

208 116 116 116 116 116 The data estimatormay be configured to retrieve, from the request to collateralize the medical claim, a set of input parameters for the medical claim. The set of input parameters for a medical claim may include, but are not limited to, a claim identifier, a claim amount, a claim date, details of the preferred primary client(s), and a department listed on the medical claim. In some aspects of the present disclosure, the details of the preferred primary client(s)may include data corresponding to a ranking of each of the preferred primary client(s), a rating of each of the preferred primary client(s), and a claim payment status of each of the preferred primary client(s). Aspects of the present disclosure are intended to include or otherwise cover any type of healthcare parameters that may be directly observed from a medical claim as the set of input parameters, without deviating from the scope of the present disclosure.

208 110 110 110 The data estimatormay further be configured to determine, through a first Machine Learning (ML) modelfrom the ML models, a set of output parameters for the medical claim using the set of input parameters and the historical claim data. The set of output parameters for the medical claim may include, but are not limited to, a risk score for the medical claim, an expected claim settlement date, and a collateral value for the medical claim. Aspects of the present disclosure are intended to include or otherwise cover any type of output parameters in the set of output parameters for the medical claim, as may be determined by the first ML modelto collateralize the medical claim, without deviating from the scope of the present disclosure.

208 214 208 110 208 208 110 208 110 110 The data estimatormay further be configured to determine a set of derived output parameters for the medical claim. In some aspects of the present disclosure, the set of derived output parameters for the medical claims may include a claim age value and a days to pay (DTP) value for the medical claim. The claim age value corresponds to a duration between a present temporal value and the claim date, and the days to pay value corresponds to a duration between the present temporal value and the expected claim settlement date. The present temporal value may be determined by the internal clock, that is configured to keep track of time and calendar date. In some aspects of the present disclosure, the data estimatormay be configured to determine the DTP value using the first ML model. The data estimatormay further determine the expected claim settlement date based on the DTP value. In some aspects of the present disclosure, the data estimatormay be configured to determine an estimated date of payment for the medical claim using the first ML model, based on the set of input parameters of the medical claim. The data estimatormay further determine the DTP value based on a difference between the estimated date of payment value and the present temporal value (i.e., present calendar date). Particularly, the risk score and the collateral value for each medical claim dynamically change based on variation(s) in the claim age value of the medical claim, the days to pay (DTP) value for the medical claim, and/or a new claim settlement entry in the historical claim data for training the first ML model. Therefore, the dashboard entries may change periodically, continuously, dynamically, or based on a user's intervention, as may be determined through the first ML model.

208 110 208 In some aspects of the present disclosure, the risk score for the medical claim may dynamically change with time. Specifically, the data estimator, by use of the first ML modelmay dynamically alter (i.e., increase) the risk score for the medical claim with increase in the claim age value and decrease in the DTP value. Moreover, the data estimatormay decrease the collateral value of the medical claim with an increase in the risk score.

208 208 208 208 208 208 Based on the risk score value, the data estimatormay further assign a risk status to the medical claim. For example, when the dynamic risk score value is between a range of 0 to 5, the data estimatormay assign ‘low risk’ status to the medical claim. When the dynamic risk score value is between a range of 6-10, the data estimatormay assign a ‘medium risk’ status to the medical claim. Moreover, when the dynamic risk score value’ is between a range of 11-15, the data estimatormay assign a ‘high risk’ status to the medical claim. Furthermore, when the dynamic risk score value is between a range of 16-20, the data estimatormay assign a ‘very high risk’ status with the medical claim. Based on the dynamic risk score and the changing days to pay value, the data estimatormay further be configured to update the collateral value for the medical claim.

In some aspects of the present disclosure, the risk status may be reflected on a dashboard to the user, which enables the user to make informed decision to collateralize the medical claim and/or exchange the collateralized medical claim for resources.

116 208 208 In some aspects of the present disclosure, the set of derived output parameters may further include a value of estimated days remaining till payment, a payer ranking for each primary client, a DTP group, a claim age group, a value of collateral claim ratio (CCR), and a CCR group. The data estimatormay determine the value of estimated days remaining till payment based on a difference between the estimated date of payment value and the present temporal value. Based on the DTP value, the data estimatormay be configured to assign the DTP group from a number of DTP groups to the medical claim.

208 208 In some aspects of the present disclosure, the data estimatormay determine the CCR value by dividing the collateral value of the medical claim with the claim value of the medical claim. As the risk associated with a medical claim is dependent on time, the CCR value also changes with time. Based on the CCR value of the medical claim, the data estimatormay be configured to assign a CCR group to the medical claim.

208 208 208 208 208 In an exemplary scenario, when the DTP value for the medical claim is between a range of 0-30 days, the data estimatormay assign the medical claim to ‘DTP group 1’. Similarly, when the DTP value for the medical claim is between a range of 31-45 days, the data estimatormay assign the medical claim to ‘DTP group 2’. Moreover, when the DTP value for the medical claim is between a range of 46-90 days, the data estimatormay assign the medical claim to ‘DTP group 3’. Furthermore, when the DTP value for the medical claim is between a range of 91-150 days, the data estimatormay assign the medical claim to ‘DTP group 4’. Furthermore, when the DTP value for the medical claim is above 151 days, the data estimatormay assign the medical claim to ‘DTP group 5’.

208 208 208 208 208 208 208 208 208 208 In another exemplary scenario, when the CCR value is between a range of 0-10, the data estimatormay assign the medical claim to ‘CCR group 1’. When the CCR value is between a range of 11-20, the data estimatormay assign the medical claim to ‘CCR group 2’. When the CCR value is between a range of 21-30, the data estimatormay assign the medical claim to ‘CCR group 3’. When the CCR value is between a range of 31-40, the data estimatormay assign the medical claim to ‘CCR group 4’. When the CCR value is between a range of 41-50, the data estimatormay assign the medical claim to ‘CCR group 5’. When the CCR value is between a range of 51-60, the data estimatormay assign the medical claim to ‘CCR group 6’. When the CCR value is between a range of 61-70, the data estimatormay assign the medical claim to ‘CCR group 7’. When the CCR value is between a range of 71-80, the data estimatormay assign the medical claim to ‘CCR group 8’. When the CCR value is between a range of 81-90, the data estimatormay assign the medical claim to ‘CCR group 9’. When the CCR value is between a range of 91-100, the data estimatormay assign the medical claim to ‘CCR group 10’.

208 208 208 208 208 208 The data estimatormay further be configured to assign a claim age group to the medical claim based on the claim age of the medical claim. In an exemplary scenario, when the claim age value of the medical claim is between a range of 0-30 days, the data estimatormay assign the medical claim to ‘claim group 1’. When the claim age value of the medical claim is between a range of 31-45 days, the data estimatormay assign the medical claim to ‘claim group 2’. When the claim age value of the medical claim is between a range of 46-90 days, the data estimatormay assign the medical claim to ‘claim group 3’. When the claim age value of the medical claim is between a range of 91-150 days, the data estimatormay assign the medical claim to ‘claim group 4’. When the claim age value of the medical claim is above 151 days, the data estimatormay assign the medical claim to ‘claim group 5’.

208 116 208 116 116 210 116 208 122 122 208 The data estimatormay further be configured to generate a first request for the preferred primary client(s)using the set of input parameters and the set of output parameters of the medical claim. Furthermore, the data estimatormay determine, whether a first acknowledgement is received from any of the preferred primary client(s)in response to the first request. The first acknowledgement may refer to an acceptance towards the first request (i.e., for collateralization of the medical claim and resource exchange between the medical facility associated with the medical claim and the preferred primary client). In an exemplary scenario, when the trade generatordetermines a reception of the first acknowledgement from the primary client, the data estimatormay generate a dashboard entry for the medical claim and may store the dashboard entry in the server memory. In some aspects of the present disclosure, prior to the addition of the dashboard entry in the server memory, the data estimatormay associate a medical facility identifier and a preferred primary client identifier(s) with the dashboard entry corresponding to the collateralized medical claim.

210 110 110 122 118 116 116 The trade generatormay be configured to determine, through a second ML modelfrom the ML models, a first set of medical claims from a number of medical claims stored in the server memorybased on the second request. The second request may include a net collateral value, details of the secondary client, a concentration limit for each of the preferred primary client(s). The concentration limit may correspond to a maximum percentage of the net collateral value associated with each of the preferred primary client(s)that can be collateralized for resource exchange. In some aspects of the present disclosure, the second request may further include a preferred risk category (i.e., associated with the risk status), and a department of interest. The department of interest may refer to a department of treatment associated with the collateralized medical claim.

102 118 210 122 Specifically, the second request may be generated by the end user deviceto exchange the collateralized medical claim for monitory resources (such as a loan) from the secondary client. Based on the contents of the second request, the trade generatormay retrieve a first set of dashboard entries corresponding to the first set of medical claims, from the server memory. In some aspects of the present disclosure, the first set of dashboard entries may include the set of input parameters and the set of output parameters, as well as the set of derived output parameters of medical claim(s) matching with the contents (or user requirements) of the second request.

210 110 110 210 110 122 116 210 118 118 118 210 210 118 210 118 210 122 122 The trade generatormay further be configured to determine, through a second ML modelfrom the ML models, a first monitory value corresponding to the first set of medical claims, using the first set of dashboard entries. In some aspects of the present disclosure, the trade generator, using the second ML modelmay select dashboard entries from the ones stored in the server memory, that correspond to collateralized medical claims by the primary client(s). Based on the selected dashboard entries, the trade generatormay generate data display elements, that can be displayed to the secondary client. In some aspects of the present disclosure, the data display items may be presented to the secondary clientin the form of a bucket of collateralized claims. Content(s) of the bucket may be customized based on selection(s) made by the secondary client. Moreover, the trade generatormay be configured to generate a third request for the secondary client using the first set of dashboard entries and the first monitory value. Furthermore, the trade generatormay determine whether a third acknowledgement is received from the secondary client in response to the third request. The third acknowledgement may refer to acceptance of the third request (i.e., for resource exchange between the medical facility and the secondary client). In an exemplary scenario, when the trade generatordetermines acknowledgement of medical claim(s) for resource exchange from the secondary client, the trade generatormay generate a resource exchange entry and may store the resource exchange entry in the server memory. In some aspects of the present disclosure, prior to the storage of the resource exchange entry in the server memory, the medical facility identifier and a secondary client identifier with the resource exchange entry.

206 206 206 206 212 206 110 206 122 206 110 206 118 206 118 118 206 122 118 206 The trade analyzermay be configured to analyze changes in various resource exchange entries with time. Specifically, the trade analyzermay determine a difference between the net collateral value and the first monitory value for the first set of medical claims. At an instance of time, when the trade analyzerdetermines that the difference between the net collateral value and the first monitory value is less than a margin exposure value, the trade analyzermay generate a resource exchange upgrade trigger. Moreover, the trade analyzermay be configured to identify a need to update the medical claim(s) for resource exchange. The trade analyzer, through the second ML model, may determine a second set of medical claims from the plurality of medical claims, in response to the resource exchange upgrade trigger, based on the updated monitory value. In response, the trade analyzermay also retrieve a second set of dashboard entries corresponding to the second set of medical claims, from the server memory. Further, the trade analyzermay determine, through the second ML model, a second monitory value corresponding to the second set of medical claims, using the second set of dashboard entries. Furthermore, the trade analyzermay be configured to generate a fourth request for the secondary clientusing the second set of dashboard entries and the second monitory value. The fourth request may correspond to exchange of the resources of the secondary client at the second monitory value. Furthermore, the trade analyzermay determine whether a fourth acknowledgement is received from the secondary clientin response to the fourth request. In a scenario, when the fourth acknowledgement is received from the secondary client device, the trade analyzermay generate an updated resource exchange entry and may store it into the server memory. In another scenario, when the fourth acknowledgement is not received from the secondary client device, the trade analyzermay discard the fourth request.

212 102 104 106 212 110 110 112 212 The portfolio constructormay be configured to generate a dashboard portfolio of medical claim(s) to be presented to a user of the user device (cumulatively referring to the end user deviceassociated with the medical facility, the primary client device, and the secondary client device). Particularly, the portfolio constructor may receive a dashboard request from the user device. The dashboard request may include user defined input corresponding to the medical facility identifier, the secondary client identifier, or the at least one preferred primary client identifier. The portfolio constructormay further be configured to determine, using a third ML modelfrom the ML models, entries stored in the server memorybased on the dashboard request. The entries may include one or more dashboard entries, one or more resource exchange entries, or a combination of them, corresponding to the user defined input. Furthermore, the portfolio constructormay generate a portfolio generation trigger that enables the entries to be rendered (displayed or presented) on the user device.

120 108 120 Various components of the data processing circuitryare presented to illustrate the functionality driven by the data processing server. It will be apparent to a person having ordinary skill in the art that various components in the data processing circuitryare for illustrative purposes and not limited to any specific combination of hardware circuitry and/or software.

122 100 122 122 216 218 220 222 224 226 2 FIG. The server memorymay be configured to store data corresponding to system. In some aspects of the present disclosure, server memorymay be segregated into multiple repositories that may be configured to store a specific type of data. In the exemplary embodiment as presented through, the server memorymay include an instructions repository, a claim data repository, a dashboard repository, a resource-exchange repository, a user data repository, and a ML data repository.

216 108 218 100 220 220 120 222 114 116 118 224 100 226 110 120 The instructions repositorymay be configured to store instructions for various components of the data processing server. The claim data repositorymay be configured to store data associated with the collateralized medical claims of the system. The dashboard data repositorymay be configured to store data corresponding to dashboard request(s) from the users. Moreover, the dashboard data repositorymay store dashboard element(s) generated by the data processing circuitry. The resource-exchange repositorymay be configured to store data associated with resource exchange between the end userand the clients (cumulatively referring to the primary client(s)and the secondary client). The user data repositorymay be configured to store data associated with registration and/or authentication of users of the system. The ML data repositorymay be configured to retrieve data and/or instruction(s) from the ML modelsthat may be utilized by various components of the data processing circuitryfor collateralization of medical claim(s) or resource exchange in lieu of the collateralized medical claim(s).

122 108 120 122 2 FIG. Various components of the server memoryare presented for illustration as per the functionality of the data processing server. It will be apparent to a person having ordinary skill in the art that various components in the server memoryare for illustrative purposes and the scope of the present disclosure is not limited by the specific repositories as presented herein through. The server memorymay include any count and/or type of data storage repositories, without deviating from the scope of the present disclosure.

3 FIG. 2 FIG. 110 110 302 304 306 308 310 110 110 is a block diagram that depicts a machine learning (ML) modelto collateralize the medical claims, according to an exemplary embodiment. The ML modelmay include a model interface, a model database, a model updater, a model executor, and an algorithm store. In the exemplary embodiment, the first through third ML models(as discussed in) may be designed in accordance with the ML modelas presented herein.

302 120 302 108 302 108 304 306 308 302 108 108 The model interfacemay receive training data based on the functionality of various components of data processing circuitry. The model interfacemay further send model-generated output(s) to the data processing server. Furthermore, the model interfacemay receive feedback data from the data processing serverand may transmit the feedback data to model database. The model updatermay access the feedback data to update parameter(s) (such as weights, bias, number of layers, filters, pooling type etc.) of the model executorfor training specific collateralization of the medical claims or exchange in resources in lieu of the collateralized medical claims. Additionally, the model interfacemay receive instruction data from the data processing serverand may transmit classified information to the data processing server.

304 304 306 304 306 306 108 The model databasemay store neural networks, weights of neurons for the neural networks, input data for the neural networks, output data from the neural networks, and the like. Additionally, the model databasemay transmit a neural network from the stored neural networks to the model updater. The model databasefurther sends the feedback data to model updater. Based on the feedback data, the model updatermay update the parameters of ML model for customized training specific to each functionality of the data processing server.

308 306 306 308 310 108 308 302 108 308 308 110 The model executormay receive data from the model updaterthat includes a customized training regimen specific to each object and the feedback data. Based on the data received from the model updater, the model executormay retrieve ML algorithms from the algorithm storeto perform operation(s) for the data processing server. Particularly, the model executormay include an input neurons layer configured to receive data from the model interface, hidden neuron layer(s) configured to propagate the received data for classification, and an output neuron layer configured to depict an output in accordance with the functionality of a component of the data processing server. Moreover, the model executoris trained for specific task(s) to classify the input data to generate the output. Each neuron of the model executormay be attached with a weight and a bias, that is determined via training of the ML model.

308 108 110 110 108 2 FIG. In some aspects of the present disclosure, the model executormay be designed using field programmable gate array (FPGA) and/or application specific integrated chip (ASIC) programmed for a specific ML functionality to support the data processing server. In some aspects of the present disclosure, each of the first through third ML modelsmay be designed using Gradient-Boosting (GB) ML models. It will be apparent to a person of ordinary skill in the art that the scope of the ML modelsis not limited only to use of the GB models. Rather, the scope of the present disclosure is limited to the functionality of the data processing serveras presented in, that may be supported by any utilize any ML model existing, or designed later in advancement of the technology, without deviating from the scope of the present disclosure.

308 310 310 310 308 116 118 In some aspects of the present disclosure, the model executormay transmit indication of a ML algorithm to algorithm store. The algorithm storemay store multiple ML algorithms. Based on the indication, the algorithm storemay transmit the corresponding ML algorithm from the multiple machine learning algorithms to be used by the model executorfor collateralization of the medical claims, preparation of dashboard(s), and/or resource exchange between the medical facility and the clients (cumulatively referring to the primary clientsand/or the secondary client).

4 FIG. 4 FIG. 400 400 102 104 106 400 402 404 406 408 410 412 414 presents a block diagram of the user device, in accordance with an exemplary embodiment. The user devicemay represent any of the end user device, the primary client device, and the secondary client device, in accordance with an exemplary aspect of the present disclosure. According to the exemplary embodiment as presented through, the user devicemay include a user interface, an application console, a device processor, a device memory, a communication interface, access point(s), and a communication interface, communicatively coupled to each other.

402 416 416 416 402 418 418 418 The user interfacemay include an input interfacefor receiving input(s) from the user. Examples of the input interfacemay include, but are not limited to, a touch interface, a mouse, a keyboard, a motion recognition unit, a gesture recognition unit, a voice recognition unit, or the like. Aspects of the present disclosure are intended to include or otherwise cover any type of the input interfaceincluding known, related art, and/or later developed technologies without deviating from the scope of the present disclosure. The user interfacemay further include an output interfacefor rendering output(s) to the user. Examples of the output interfacemay include, but are not limited to, a digital display, an analog display, a touch screen display, a graphical user interface, a website, a webpage, a keyboard, a mouse, a light pen, an appearance of a desktop, and/or illuminated characters. Aspects of the present disclosure are intended to include or otherwise cover any type of the output interfaceincluding known, related art, and/or later developed technologies without deviating from the scope of the present disclosure.

404 400 404 100 108 408 404 420 418 406 418 The application consolemay be configured as a computer-executable application, to be executed by the user device. The application consolemay include suitable logic, instructions, and/or codes for executing multiple operations of the systemand may be controlled (or hosted) by the data processing server. The computer executable application(s) may be stored in the device memory. In some aspects of the present disclosure, the application consolemay include an application logic, that may include logic, codes, and/or circuitry to control the display through the output interface. More particularly, the application logic may be shared with the device processorthat controls output(s) rendered through the output interface.

406 400 406 406 400 402 406 406 The device processormay include suitable logic, instructions, circuitry, interfaces, and/or codes for executing various operations associated with the user device. In some aspects of the present disclosure, the device processormay utilize processor(s) such as Arduino or raspberry pi and/or the like. Further, the device processormay be configured to control operation(s) executed by the user devicein response to the input received at the user interfacefrom the user. Examples of the device processormay include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a field-programmable gate array (FPGA), a Programmable Logic Control unit (PLC), and the like. Aspects of the present disclosure are intended to include or otherwise cover any type of the device processorincluding known, related art, and/or later developed processing units, without deviating from the scope of the present disclosure.

408 406 410 400 100 408 408 408 422 404 408 400 The device memorymay be configured to store logic, instructions, circuitry, interfaces, and/or codes of the device processor, data associated with the communication controller, data associated with the user device, and data associated with the system. Examples of the device memorymay include, but are not limited to, a Read-Only Memory (ROM), a Random-Access Memory (RAM), a flash memory, a removable storage drive, a hard disk drive (HDD), a solid-state memory, a magnetic storage drive, a Programmable Read Only Memory (PROM), an Erasable PROM (EPROM), and/or an Electrically EPROM (EEPROM). Aspects of the present disclosure are intended to include or otherwise cover any type of the device memoryincluding known, related art, and/or later developed memories, without deviating from the scope of the present disclosure. In some aspects of the present disclosure, the device memorymay store application objectsspecific to the computer-executable application running through the application console. The device memorymay further store instruction objects for operations of various components of the user device.

410 410 410 414 112 Communication controllermay include processing circuitry to enable and/or control the access point(s). The access point(s)generate wireless communication signals that facilitate the communication interfaceto communicatively couple with network.

414 400 100 112 414 414 400 100 The communication interfacemay be configured to enable the user deviceto communicate with various components of the systemover the network. Examples of the communication interfacemay include, but are not limited to, a modem, a network interface such as an Ethernet card, a communication port, and/or a Personal Computer Memory Card International Association (PCMCIA) slot and card, an antenna, a radio frequency (RF) transceiver, amplifier(s), a tuner, oscillator(s), a digital signal processor, a coder-decoder (CODEC) chipset, a Subscriber Identity Module (SIM) card, and a local buffer circuit. It will be apparent to a person of ordinary skill in the art that the communication interfacemay include any device and/or apparatus capable of providing wireless or wired communication between the user deviceand the other components of the system.

5 5 FIGS.(A)-(C) 500 1 500 3 100 400 illustrate Graphical User interfaces (GUIs)-through-generated by the systemand presented through the user devicecorresponding to generation of claim portfolio corresponding to selected medical claims, in accordance with an exemplary aspect of the present disclosure.

5 FIG.(A) 5 FIG.(B) 500 1 500 2 100 418 102 114 114 404 108 418 500 1 502 1 502 2 502 3 504 1 More particularly,andillustrate example embodiments of application interfaces (i.e., the GUI-and GUI-) generated by the system. The Application interfaces display dashboards presented through the output interfaceof the end user deviceto the end userof the medical facility, in accordance with option(s) selected by the end user. The application is operated through the application console, controlled by the data processing server, and is displayed through the output interface. The GUI-may include elements-,-,-, and-.

502 1 100 502 1 The element-may include selectable option(s) to facilitate the user for selecting an operation to be performed by the system. Preferably, the element-may include a dashboard selection option, a claims portfolio selection option, a trading selection option, and a trade management selection option.

502 2 502 2 100 502 2 502 2 100 502 2 100 The element-may include selectable options for the user. Preferably, the element-may include a notification option that enables the user to view notification(s) for the user generated by the system. The element-may further include a help option that enables the user to input a query for operations of the application interface. Furthermore, the element-includes a user account option that enables the user to view and/or update user-account information provided by the user while registering with the system. Moreover, the element-includes a logout option that enables the user to log-out the user-account from the application. Logging-out may enable the user to log-in to the system using log-in details corresponding to another user-account registered with the system.

502 1 502 3 502 3 418 504 1 502 3 502 3 100 504 1 In the presented aspect of the present disclosure, when the claim portfolio option is selected by the user using the element-, the element-is presented on the application interface. The element-may include selectable option(s) to facilitate the user to select option(s) to be displayed through the output interfacevia the element-. In some aspects of the present disclosure, the options of element-may include the claim identifier (presented as claim no.) of a medical claim, the set of input parameters of the medical claim, the set of output parameters of the medical claim, and the set of derived output parameters of the medical claim. Based on the user selection through the element-, the systemgenerates display fields for the element-.

504 1 504 2 504 1 504 2 504 1 504 2 In the presented aspect, the element-is presented to display the risk status, the risk score, the claim identifier (i.e., presented as the claim no.), the claim date, the department, and the DTP value. Moreover, the element-is presented to display the claim age, the primary client (i.e., presented as payer), the claim amount, status of the claim, the collateral value, a funding amount, and a funding status. It will be apparent to a person skilled in the art that the fields presented through the elements-and-are for illustration only, and the scope of the present disclosure is not limited to the. Rather, the elements-and/or-may include data fields corresponding to the claim identifier of a medical claim, the set of input parameters of the medical claim, the set of output parameters of the medical claim, and the set of derived output parameters of the medical claim, based on the user selection.

100 500 3 100 500 3 504 3 504 3 504 3 5 FIG.(C) In some aspects of the present disclosure, the systemfurther facilitates the user to view medical descriptive details of various services rendered by the medical facility, presented through a medical claim. The application interface enables the user to click on a medical claim to present the medical descriptive details of the services.presents an application interface (i.e., presented through the GUI-) generated by the system, in response to selection of a medical claim for medical descriptive information by the user. The GUI-includes an element-that includes medical descriptive details of various services rendered by the medical facility presented in the selected claim. In the presented embodiment, the element-may include a Current Procedural Terminology (CPT), Healthcare Common Procedure Coding Systems (HCPCS) number, details of healthcare provider, department details, claim amount, claim status, collateral amount, and DTP details, for each service of the medical claim. It will be apparent to a person of ordinary skill in the art that the fields for medical descriptive information of the medical claim are for illustration only, and the scope of the present disclosure is not limited to it. Rather, the element-may include any type of medical descriptive information of services as may be derived from the medical claim generated by the healthcare facility, without deviating from the scope of the present disclosure.

6 6 FIGS.(A)-(E) 600 1 600 5 100 400 illustrate application interfaces (presented through GUIs-through-) generated by the systemand presented through the user devicecorresponding to resource exchange, in accordance with an exemplary aspect of the present disclosure.

6 FIG.(A) 600 1 100 600 1 100 502 1 600 1 502 1 502 2 502 3 600 1 602 1 504 4 Particularly,illustrates example embodiment of an application interface (i.e., the GUI-) generated by the system. The GUI-is generated by the systemin response to a selection of the trading option from the element-by the user. The GUI-may include elements-,-, and-. The GUI-may further include elements-and-.

602 2 602 1 118 504 4 100 600 1 504 4 100 504 4 502 3 504 4 118 The element-may include selectable option(s) to facilitate the user to provide input(s) for resource exchange. Specifically, the element-may include an option to select the secondary client(i.e., presented as financial partner), an option to select the target collateral value, an option to select the concentration limit, an option to select the risk status of medical claim(s), an option to select the primary client(s) (presented as payers), and an option to select the department. In accordance with the selection(s) of the user, the element-is generated by the systemand presented through the GUI-of the application interface. In the presented embodiment, the element-is presented to include the risk status, the risk score, a trade identifier (trade ID), the claim identifier (Claim ID), the claim date, the department details, and the DTP value of the medical claims determined by the systembased on the selection(s) by the user. It will be apparent to a person skilled in the art that the data fields included in the element-are based on the selection of the data fields by the user through the element-as presented above, and thus the scope of the present disclosure is not limited to it. Rather, the element-may include any data fields that may correspond to resource exchange between the medical facility and the secondary client, without deviating from the scope of the present disclosure.

602 1 602 1 504 4 600 2 The element-may further include an option to create basket of the medical claims as determined by the system based on the selections by the user from the various options of the element-and presented through the element-. In an exemplary scenario, when the option to create basket is selected by the user, the application renders another application interface presented through GUI-.

6 FIG.(B) 6 FIG.(C) 600 2 600 3 100 600 2 504 5 603 604 1 603 604 1 604 1 606 1 600 2 606 1 606 1 600 3 andillustrate example embodiments of application interfaces (i.e., the GUI-and GUI-) generated by the system. The GUI-includes an element-that includes sub-elementand sub-element-. The sub-elementenables the user to select options for selecting entities participating in the resource exchange. The sub-element-enables the user to select trade-details input as an option. In an exemplary scenario, when the user selects (or clicks on) the sub-element-, a new sub-element-is generated by the system that is presented by the GUI-. The sub-element-enables the user to select (or provide) input(s) for resource exchange. Moreover, when the user selects (or provides) inputs for resource exchange to the options of the sub-element-, application renders another application interface presented through GUI-.

600 3 504 6 604 2 604 2 604 2 606 2 602 2 608 1 606 2 608 1 504 5 504 6 600 4 The GUI-includes an element-that further includes a sub-element-. In some aspects of the present disclosure, the sub-element-enables the user to view the risk details corresponding to the resource exchange. In an exemplary scenario, when the user selects (or clicks on) the sub-element-, a new sub-element-is presented on the application interface. The sub-element-may include selectable option-that enables selection of risk parameter(s) associated with the resource exchange. Moreover, the sub-element-may also present the data of the selection through the selectable option-using various graphical options such as but not limited to graphs, bar graph, pie chart, etc. the element-and-further includes an option for request authorization of the resource exchange, that enables the user to generate a request for resource exchange based on the selected (or provided) input(s). In an exemplary scenario, when the user selects the option for request authorization, the application renders to GUI-.

6 FIG.(D) 6 FIG.(E) 600 4 600 5 100 600 4 504 7 502 3 600 5 504 8 502 3 504 7 504 8 504 7 504 8 502 3 andillustrate example embodiments of application interfaces (i.e., the GUI-and GUI-) generated by the system. The GUI-includes an element-that presents resource exchange details based on a selection of option(s) from the element-by the user. Similarly, the GUI-includes an element-that presents resource exchange details based on another selection of option(s) from the element-by the user. It will be apparent to a person of ordinary skill in the art that the data fields presented through the elements-and-are for illustration only, and the scope of the present disclosure is not limited to it. Rather, the elements-and-may include any data field related to the resource exchange, as may be selected by the user using the element-.

7 FIG. 7 FIG. 700 100 700 502 1 700 504 9 118 504 118 504 9 100 502 2 504 9 700 illustrates an application interface (i.e., presented through GUI) generated by the system. The GUIis presented on the application interface by a selection of the trade management option from the element-. The GUImay include an element-that presents information related to various resource exchanges of a secondary client. In the exemplary embodiment presented through, the elementincludes a list of resource exchanges (presented as trade list) comprising selectable options for each resource exchange associated with the secondary client. Upon selection of a resource exchange option by the user, the application interface provides details of the selected resource exchange. The element-may further include a summary of the selected resource exchange (presented as trade summary) that may include details of the medical claim(s) corresponding to the selected resource exchange. In an exemplary scenario, when the difference between the net collateral value and the first monitory value for the first set of medical claims for a resource exchange is less than the margin exposure value, the systemmay generate a notification for the user, that may be presented to the user by selecting the notification option in the element-. Moreover, the second monitory value, the second set of medical claims and their associated details may be rendered to the user through the element-of the GUI.

8 8 FIG.(A)-(I) 800 1 800 9 100 400 116 118 100 800 1 502 1 502 2 802 1 802 1 502 2 100 504 10 800 1 504 10 100 116 118 504 10 illustrate GUIs-through-generated by the systemand presented through the user devicecorresponding to onboarding and managing accounts of different entities (i.e., the medical facility, the primary clients, and the secondary clients) of the system, in accordance with an exemplary aspect of the present disclosure. The GUI-is rendered by the application interface when the user selects the dashboard option from the element-. In such a scenario, the element-may indicate a settings option-. In an exemplary scenario, when the user selects (or clicks on) the settings option-from the element-, the systemmay generate an element-on the GUI-. The element-includes options to select and add details corresponding to various entities of the system(e.g., the medical facility, the primary clients, and the secondary clients). Based on the selection(s) of the entity from the options in the element-, the application renders to another application interface.

800 2 800 2 504 11 100 504 11 504 11 504 11 800 3 800 3 504 12 100 504 12 100 504 12 100 800 2 Specifically, when the user selects to add details of the medical facility, the application renders to the application interface presented through the GUI-. The GUI-includes an element-comprising several selectable options (e.g., data fields) that enables the user to provide details of the medical facility to the system. The element-further includes an option to add a medical facility that may be submitted upon submitting input(s) for required data fields of the element-. When the user provides the input(s) for the required data fields of the element-and submits the addition of the medical facility, the application may render to another application interface presented through GUI-. The GUI-includes an element-that renders details of the medical facility added to the system. The element-further includes an option to search medical facilities added to the system. Furthermore, the element-may also include an option to add details of a new medical facility to the system, which when clicked by the user renders the application to the application interface presented through GUI-.

118 800 4 800 4 504 14 118 100 504 14 118 504 14 504 14 118 800 5 800 5 504 15 100 504 15 118 100 504 15 118 100 800 4 In an exemplary scenario, when the user selects to add details of a secondary client(presented as financial partner) to the system, the application renders to GUI-. The GUI-may include an element-that includes a number of selectable options to enable the user for providing details of the secondary clientto be added to the system. The element-further includes an option to add a secondary clientto the system that may be submitted upon submitting input(s) for required data fields of the element-. When the user provides the input(s) for the required data fields of the element-and submits the addition of the new secondary client, the application may render to another application interface presented through GUI-. The GUI-includes an element-that renders details of the new secondary client added to the system. The element-further includes an option to search secondary clientadded to the system. Furthermore, the element-may also include an option to add details of a new secondary clientto the system, which when clicked by the user renders the application to the application interface presented through GUI-.

116 100 800 6 800 6 504 16 116 100 504 16 116 504 16 116 100 116 100 In an exemplary scenario, when the user selects to add details of a primary client(presented as financial partner) to the system, the application renders to GUI-. The GUI-may include an element-that includes a number of selectable options to enable the user for providing details of the primary clientto be added to the system. The element-further includes an option to add the primary clientto the system that may be submitted upon submitting input(s) for required data fields of the element-. Once the details of the newly added primary clientare submitted, the systemmay generate an account for the newly added primary clientto access the service(s) of the system.

114 100 800 7 800 7 504 17 114 100 504 17 114 504 17 114 100 114 100 In an exemplary scenario, when the user selects to add details of an end user(presented as financial partner) to the system, the application renders to GUI-. The GUI-may include an element-that includes a number of selectable options to enable the user for providing details of the end userto be added to the system. The element-further includes an option to add the end userto the system that may be submitted upon submitting input(s) for required data fields of the element-. Once the details of the newly added end userare submitted, the systemmay generate an account for the newly added end userto access the service(s) of the system.

116 800 8 800 8 504 18 116 504 18 504 18 In an exemplary scenario, when the user selects to add department details of medical facility associated with a medical claim and/or details of the preferred primary clientfor the medical claim, the application renders to GUI-. The GUI-may include an element-that includes a number of selectable options to enable the user for providing details of the department for the medical claim and select a preferred primary client. The element-further includes an option to add the department to the system that may be submitted upon submitting input(s) for required data fields of the element-.

100 800 9 800 9 504 19 504 19 122 In an exemplary scenario, when the user selects to edit details medical facility to the system, the application renders to GUI-. The GUI-may include an element-that includes a number of selectable options to enable the user for editing (or updating) details of the selected medical facility. The element-further includes an option to update the details of the medical facility into the server memory.

5 FIG.(A) 8 FIG.(I) 100 100 100 100 As will be apparent to a person of ordinary skill in the art, the GUIs presented bythroughare for illustration of some of the functions performed by the system, according to some exemplary aspects of the present disclosure. It must be noted that the GUIs (as presented) does not signify a specific form of data presentation or providing information to or by the systemthat may limit the scope of the present disclosure. Rather, the systemmay generate any type of GUIs as may be suitable to render the various operations of the systempresented above.

9 FIG. 900 is a flow chart that depicts a processfor generating and storing a dashboard entry corresponding to a collateralized medical claim, in accordance with an exemplary aspect of the present disclosure.

902 108 102 116 At block, the data processing servermay receive the request to collateralize a medical claim corresponding to medical service(s) rendered by the medical facility, from the end user device. The request to collateralize the medical claim may include details of the medical claim and details of the preferred primary client(s)to collateralize the medical claim.

904 108 116 At block, the data processing servermay retrieve the set of input parameters for the medical claim from the request to collateralize the medical claim. The set of input parameters includes the claim identifier, the claim amount, the claim date, and details of the preferred primary client(s), for the medical claim.

906 108 122 At block, the data processing servermay retrieve the historical claim data corresponding to past claim settlements from the server memory.

908 108 110 108 108 108 110 110 108 108 At block, the data processing servermay determine, through the first Machine Learning (ML) modelusing the set of input parameters and the historical claim data, the set of output parameters for the medical claim. The set of output parameters includes the risk score for the medical claim, the expected claim settlement date, and the collateral value for the medical claim. In some aspects of the present disclosure, the data processing servermay further be configured to determine the set of derived output parameters using the set of output parameters. Specifically, the data processing servermay determine the claim age value and the DTP value for the medical claim. The claim age value corresponds to the duration between the present temporal value and the claim date. The DTP value corresponds to the duration between the present temporal value and the expected claim settlement date. In some aspects of the present disclosure, the data processing servermay further dynamically change the risk score in accordance with variation in the claim age value and the days to pay value for the medical claim. Particularly, the risk score and the collateral value for each medical claim dynamically change based on variation(s) in the claim age value of the medical claim, the days to pay (DTP) value for the medical claim, and/or a new claim settlement entry in the historical claim data for training the first ML model. Therefore, the dashboard entries may change periodically, continuously, dynamically, or based on a user's intervention, as may be determined through the first ML model. Moreover, the data processing servermay determine, for the medical claim, a risk category from a plurality of risk categories based on the risk score associated with the medical claim. Furthermore, the data processing servermay update the set of output parameters by associating the determined risk category to the medical claim.

910 108 116 108 104 116 At block, the data processing servermay generate the first request for the preferred primary client(s)using the set of input parameters and the set of output parameters. The data processing servermay further transmit the first request to the preferred primary client device(s)corresponding to the preferred primary client(s).

912 108 104 108 900 916 108 900 914 At block, the data processing servermay determine, whether the first acknowledgement is received from one preferred primary client device(s)in response to the first request. When the first acknowledgement is received by the data processing server, the processproceeds to block. Else when the first acknowledgement is not received by the data processing server, the processproceeds to block.

914 108 At block, the data processing servermay discard the first request.

916 108 At block, the data processing servermay generate a dashboard entry for the medical claim using the set of input parameters and the set of output parameters.

918 108 122 122 112 108 At block, the data processing servermay add the dashboard entry to the server memory. The entry may be iteratively updated by the data processing serverbased on the changes to the set of output parameters and the set of derived output parameters due to lapse of time. In some aspects of the present disclosure, prior to the addition of the dashboard entry in the server memory, the data processing servermay further associate the medical facility identifier and the preferred primary client identifier with the dashboard entry.

10 FIG. 1000 is a flow chart that depicts a processfor exchanging resources between the medical facility and the clients in exchange of the collateralized claims, in accordance with an exemplary aspect of the present disclosure.

1002 108 102 116 116 At block, the data processing servermay receive the second request from the end user deviceassociated with the medical facility. The second request includes the net collateral value, details of the secondary client, and the concentration limit for each preferred primary client.

1004 108 110 122 At block, the data processing servermay determine, through the second ML model, the first set of medical claims from of medical claims stored in the server memory, based on the second request.

1006 108 122 At block, the data processing servermay retrieve the first set of dashboard entries corresponding to the first set of medical claims from the server memory.

1008 108 110 At block, the data processing servermay determine, through the second ML model, the first monitory value corresponding to the first set of medical claims, using the first set of dashboard entries.

1010 108 118 108 106 118 At block, the data processing servermay generate the third request for the secondary clientusing the first set of dashboard entries and the first monitory value. The data processing servermay further transmit the third request to the secondary client deviceassociated with the secondary client.

1012 108 106 108 1000 1016 108 1000 1014 At block, the data processing servermay determine whether the third acknowledgement is received from the secondary client devicein response to the third request. When the third acknowledgement is received by the data processing server, the processproceeds to block. Else when the third acknowledgement is not received by the data processing server, the processproceeds to block.

1014 108 At block, the data processing servermay discard the third request.

1016 108 At block, the data processing servermay generate the resource exchange entry in response to the reception of the third acknowledgement.

1018 108 122 108 122 108 At block, the data processing servermay store the resource exchange entry into the server memory. Moreover, the data processing servermay update the resource exchange entry iteratively with lapse of time. In some aspects of the present disclosure, prior to the storage of the resource exchange entry in the server memory, the data processing servermay associate the medical facility identifier and the secondary client identifier with the resource exchange entry.

11 FIG. 1100 400 114 102 116 104 118 106 is a flow chart that depicts a processfor presenting information to a user of the user device, in accordance with an exemplary aspect of the present disclosure. The user may be an end userassociated with the end user devicecorresponding to the medical facility. The user may also be the primary clientassociated with the primary client device. Moreover, the user may be the secondary clientassociated with the secondary client device. The information rendered to the user may correspond to transactions associated with the user.

1102 108 400 102 104 106 At block, the data processing servermay receive the dashboard request from the user device. The dashboard request may be associated with at least one of, the medical facility associated with the end user device, the secondary client, or the preferred primary client. The dashboard request may include user defined input corresponding to at least of the medical facility identifier, the secondary client identifier, or the preferred primary client identifier.

1104 108 110 110 At block, the data processing servermay determine, using the third ML model, entries stored in the server memorybased on the dashboard request. The entries may include at least one of, dashboard entries, resource exchange entries, or a combination thereof, corresponding to the user defined input.

1106 108 400 At block, the data processing servermay render the entries on the user device.

Now, referring to the technical abilities and advantageous effect of the present disclosure, the disclosure presents a platform that allows access to alternate financing by leveraging medical claims (i.e., receivables) as collateral. Given the challenges (quality, time delays upwards of 45 days, risk of payment, etc.) with medical claims processing, the platform takes a unique approach to validating the claims, identifying the risk associated with the claims & providing insights for both medical facilities and the clients to make educated decision on using the medical claim as collateral. Moreover, the platform is backed by an “Asset backed commercial paper” program from the clients that allows for them to provide funding to the customers for their operational needs, without having the customer go through regular channels (e.g., line of credit, revolver credit etc.) from their banking partners. In addition, the platform also assures medical facilities to keep track of their receivables and solve their monitory problems.

Those skilled in the art will appreciate that the methodology described herein in the present disclosure may be carried out in other specific ways than those set forth herein in the above disclosed embodiments without departing from essential characteristics and features of the present invention. The above-described embodiments are therefore to be construed in all aspects as illustrative and not restrictive.

The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein. Any combination of the above features and functionalities may be used in accordance with one or more embodiments.

In the present disclosure, each of the embodiments has been described with reference to numerous specific details which may vary from embodiment to embodiment. The foregoing description of the specific embodiments disclosed herein may reveal the general nature of the embodiments herein that others may, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications are intended to be comprehended within the meaning of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and is not limited in scope.