DETAILED ACTION
Status of the Claims
1. This action is in reply to the application filed on May 23, 2025.
2. Claims 1-20 are currently pending and have been examined.
Notice of Pre-AIA or AIA Status
3. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Interpretation – Broadest Reasonable Interpretation
4. In determining patentability of an invention over the prior art, all claim limitations have been considered and interpreted using the “broadest reasonable interpretation consistent with the specification during the examination of a patent application since the applicant may then amend his claims.” See In re Prater and Wei, 162 USPQ 541, 550 (CCPA 1969); MPEP § 2111. Applicant always has the opportunity to amend the claims during prosecution, and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. See In re Prater, 162 USPQ 541, 550-51 (CCPA 1969); MPEP § 2111. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 26 USPQ2d 1057 (Fed. Cir. 1993). See also MPEP 2173.05(q) All claim limitations have been considered. Additionally, all words in the claims have been considered in judging the patentability of the claims against the prior art. See MPEP 2143.03.
Language in a method or system claim that states only the intended use or intended result, but does not result in a manipulative difference in the steps of the method claim nor a structural difference between the system claim and the prior art, fails to distinguish the claims from the prior art. In other words, if the prior art structure is capable of performing the intended use, then it meets the claim.
Claim limitations that contain statement(s) such as “if, may, might, can, could”, are treated as containing optional language. As matter of linguistic precision, optional claim elements do not narrow claim limitations, since they can always be omitted.
Claim limitations that contain statement(s) such as “wherein, whereby”, that fail to further define the steps or acts to be performed in method claims or the discrete physical structure required of system claims.
The subject matter of a properly construed claim is defined by the terms that limit its scope. It is this subject matter that must be examined. As a general matter, the grammar and intended meaning of terms used in a claim will dictate whether the language limits the claim scope.
Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation. Claim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed, or by claim language that does not limit a claim to a particular structure. In addition, when a claim requires selection of an element from a list of alternatives, the prior art teaches the element if one of the alternatives is taught by the prior art. See, e.g., Fresenius USA, Inc. v. Baxter Int’l, Inc., 582 F.3d 1288, 1298 (Fed. Cir. 2009). See MPEP 2111.04, 2143.03. The following types of claim language may raise a question as to its limiting effect (this list is not exhaustive):
Preamble (MPEP 2111.02);
Clauses such as “adapted to”, “adapted for”, “wherein”, and “whereby” (MPEP 2111.04)
Contingent limitations (MPEP 2111.04)
Printed matter (MPEP 2111.05) and
Functional language associated with a claim term (MPEP 2181)
Examiner notes that during examination, “claims … are to be given their broadest reasonable interpretation consistent with the specification, and … claim language should be read in light of the specification as it would be interpreted by one of ordinary skill in the art.” See In re Bond, 15 USPQ 1566, 1568 (Fed. Cir. 1990), citing In re Sneed, 218 USPQ 385, 388 (Fed. Cir. 1983). However, "in examining the specification for proper context, [the examiner] will not at any time import limitations from the specification into the claims". See CollegeNet, Inc. v. ApplyYourself, Inc., 75 USPQ2d 1733, 1738 (Fed. Cir. 2005). Construing claims broadly during prosecution is not unfair to the applicant, because the applicant has the opportunity to amend the claims to obtain more precise claim coverage. See In re Yamamoto, 222 USPQ 934, 936 (Fed. Cir. 1984), citing In re Prater, 162 USPQ 541, 550 (CCPA 1969).
As such, while all claim limitations have been considered and all words in the claims have been considered in judging the patentability of the claimed invention, the following language is interpreted as not further limiting the scope of the claimed invention.
The preamble of the instant claim 1 recites "[a] computing system for iteratively querying a plurality of payor computing systems to verify payment coverage for a recipient”
The preamble of the instant claim 9 recites “[a] computer-implemented method for iteratively querying a plurality of payor computing systems to verify payment coverage for a recipient of a service of a service provider, the computer-implemented method comprising:”
The preamble of the instant claim 15 recites “[a] non-transitory computer-readable medium storing instructions for iteratively querying a plurality of payor computing systems to verify payment coverage for a recipient of a service of a service provider, wherein the instructions, when executed by the one or more processors of a computing system, cause the computing system to:”
In general, a preamble limits the invention if it recites essential structure or steps, or if it is "necessary to give life, meaning, and vitality" to the claims. Pitney Bowes, Inc. v. Hewlett-Packard Co. 51 USPQ2d 1161 (Fed. Cir. 1999), Catalina Marketing International Inc. v. Coolsavings.com Inc., 62 USPQ2d 1781 (Fed. Cir. 2002). Conversely, where a patentee defines a structurally complete invention in the claim body and uses the preamble only to state a purpose or an intended use for the invention, the preamble is not a claim limitation given patentable weight. Rowe v. Dror, 42 USPQ2d 1550 (Fed. Cir. 1997); Catalina Marketing International Inc. v. Coolsavings.com Inc., 62 USPQ2d 1781 (Fed. Cir. 2002); Bell Communications Research, Inc. v. Vitalink Communications Corp., 34 USPQ2d 1816 (Fed. Cir. 1995) If a prior art structure is capable of performing the intended use as recited in the preamble, then it meets the claim. See, e.g., In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed. Cir. 1997) See MPEP 2111.02
In the instant case, “for iteratively querying a plurality of payor computing systems to verify payment coverage for a recipient of a service of a service provider” as recited in the preambles of each of the independent claims only states a purpose and/or the intended use of the invention and accordingly is not being assigned any patentable weight.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
5. Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
ANALYSIS:
STEP 1:
Does the claimed invention fall within one of the four statutory categories of invention (process, machine, manufacture or composition matter?
Claim 1 recites a system claim. Claim 9 recites a method claim. Claim 15 recites a non-transitory computer-readable medium claim.
STEP 2A:
Prong One: Does the Claim Recite A Judicial Exception (An Abstract Idea, Law of Nature or Natural Phenomenon)? (If Yes, Proceed to Prong Two, If No, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material)
Claim 1 recites the abstract idea of iteratively querying a plurality of payor computing systems to verify payment coverage for a recipient of a service provider. The idea is described by the following limitations:
receive, from a service provider, a request to verify payment coverage for the recipient of the service;
iterate to verify payment coverage for the recipient at least by, at each iteration:
retrieving a specification for a payor of the plurality of payor systems;
constructing a verification request based on the retrieved specification;
establishing a connection with the payor system based on the retrieved specification;
submitting the verification request to the payor system based on the retrieved specification; and
receiving in response to the submitted verification request, a verification response from the payor system indicating whether a payor associated with the payor system provides payment coverage for the recipient;
based on at least one verification response indicating a payor that provides payment coverage for the recipient, sending to the service provider an indication of an identity of the payor that provides payment coverage for the recipient; and
based on no verification response indicating a payor that provides payment coverage for the recipient, sending to the service provider an indication that payment coverage for the recipient could not be verified.
Claim 9 recites the abstract idea of iteratively querying a plurality of payor computing systems to verify payment coverage for a recipient of a service of a service provider. The idea is described by the following limitations:
storing a plurality of specifications of a respective one of the payor systems;
receiving, from a service provider a request to verify payment coverage for the recipient of the service;
iterating over the plurality of specifications to verify payment coverage for the recipient, wherein each iteration comprises:
retrieving a specification for a payor system of the plurality of payor systems;
constructing a verification request based on the retrieved specification;
establishing a connection with the payor system based on the retrieved specification;
submitting the verification request to the payor system based on the retrieved specification; and
receiving, via the connection and in response to the submitted verification request, a verification response from the payor system indicating whether a payor provides payment coverage for the recipient; and
sending, to the service provider and based on at least one received verification response, either an indication of an identity of the payor that provides payment coverage for the recipient or an indication that payment coverage for the recipient could not be verified.
Claim 15 recites the abstract idea of iteratively querying a plurality of payor computing systems to verify payment coverage for a recipient of a service of a service provider. The idea is described by the following limitations:
store a plurality of specifications, of a respective one of the payor systems;
receive, from a service provider, a request to verify payment coverage for the recipient of the service;
iterate over the plurality of specifications to verify payment coverage for the recipient, wherein each iteration comprises:
retrieving a specification for a payor system of the plurality of payor systems;
constructing a verification request based on the retrieved specification;
establishing a connection with the payor system based on the retrieved specification;
submitting the verification request to the payor system based on the retrieved specification; and
receiving, via the connection and in response to the submitted verification request, a verification response from the payor system indicating whether a payor associated with the payor system provides payment coverage for the recipient; and
send, to the service provider and based on at least one received verification response, either an indication of an identity of the payor that provides payment coverage for the recipient or an indication that payment coverage for the recipient could not be verified.
Applicant’s specification indicates that the disclosure relates to insurance verification systems and methods. (See Applicant Spec para 2)
Notably, the specification discloses that the insurance verification system may be in signal communication with multiple payor systems, multiple provider systems and multiple EHR/EMR systems and that the networks may include the Internet. (See Applicant Spec para 16) The insurance verification system may communicate with a given payor system using an API exposed by that payor system and may be configured to invoke the APIs of multiple payor systems and can query advantageously query multiple payor systems include APIs unique to individual payor systems and APIs common to multiple payor systems. (See Applicant Spec para 16)
The specification therefore makes clear that the insurance verification system is using APIs that are generated by the various payor systems to gather information, and that these APIs are not generated by the Applicant’s system.
Under a BRI, the claims reflect no more than querying a plurality of payor computing systems to verify payment coverage for a recipient using a saved API stored in a database that is from a one of a number of payor computing systems to construct and submit the verification request and either receiving or not receiving a verification response from a respective payor computing system to determine if there is or is not payment coverage for a recipient.
As a result, the abstract ideas describe certain methods of organizing human activity. The steps describe certain fundamental economic practices (including insurance); commercial or legal interactions (including agreements in the form of contracts, legal obligations, business relations) and/or managing personal behavior or relationships or interactions between people (following rules or instructions). The steps (noted above) are describing making requests for information using a format specified by a payor and receiving responses to verification requests using generic computer-implemented steps. (Step 2A, Prong 1: Yes, the claims are abstract)
Prong Two: Does the Claim Recite Additional Elements That Integrate The Judicial Exception Into A Practical Application of the Exception? (If Yes, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material. If No, Proceed to Step 2B)
The claims do not include additional elements that integrate the judicial exception into a practical application of the exception because the claims do not provide improvements to another technology or technical field, improvements to the functioning of the computer itself, are not applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, are not applying the judicial exception with, or by use of a particular machine, are not effecting a transformation or reduction of a particular article to a different state or thing, and are not applying the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Claim 1 recites a plurality of payor computing systems, a computing system comprising one or more processors, a database, a plurality of API specifications, memory, instructions, a service provider system, an electronic connection and one or more computing networks.
Claim 9 recites a plurality of payor computing systems, a database, a plurality of API specifications, a service provider system, an electronic connection, and one or more computing networks.
Claim 15 recites a non-transitory computer-readable medium, instructions, a plurality of payor computing systems, one or more processors of a computing system, a database, a plurality of API specifications, a service provider system, an electronic connection and one or more computing networks.
In particular, the claims only recite a plurality of payor computing systems, a computing system comprising one or more processors, a database, a plurality of API specifications, memory, instructions, a service provider system, an electronic connection, one or more computing networks, and a non-transitory computer-readable medium which are recited at a high level of generality (i.e., as a generic processor performing generic computer functions) such that it amounts to no more than mere instructions to apply the exception using a generic computer component.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, Claims 1, 9 and 15 are directed to an abstract idea without a practical application. (Step 2A – Prong 2: No, the additional claimed elements are not integrated into a practical application)
STEP 2B: If there is an exception, determine if the claim as a whole recites significantly more than the judicial exception itself.
The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: i) receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)); ii) performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims."); iii) electronic recordkeeping, Alice Corp., 134 S. Ct. at 2359, 110 USPQ2d at 1984 (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv) storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; v) electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014) (optical character recognition); and vi) a web browser’s back and forward button functionality, Internet Patent Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1418 (Fed. Cir. 2015). (MPEP §2106.05(d)(II))
This listing is not meant to imply that all computer functions are well‐understood, routine, conventional activities, or that a claim reciting a generic computer component performing a generic computer function is necessarily ineligible. Courts have held computer‐implemented processes not to be significantly more than an abstract idea (and thus ineligible) where the claim as a whole amounts to nothing more than generic computer functions merely used to implement an abstract idea, such as an idea that could be done by a human analog (i.e., by hand or by merely thinking). On the other hand, courts have held computer-implemented processes to be significantly more than an abstract idea (and thus eligible), where generic computer components are able in combination to perform functions that are not merely generic. (MPEP §2106.05(d)(II) – emphasis added)
Below are examples of other types of activity that the courts have found to be well-understood, routine, conventional activity when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: recording a customer’s order, Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1244, 120 USPQ2d 1844, 1856 (Fed. Cir. 2016); shuffling and dealing a standard deck of cards, In re Smith, 815 F.3d 816, 819, 118 USPQ2d 1245, 1247 (Fed. Cir. 2016); restricting public access to media by requiring a consumer to view an advertisement, Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716-17, 112 USPQ2d 1750, 1755-56 (Fed. Cir. 2014); identifying undeliverable mail items, decoding data on those mail items, and creating output data, Return Mail, Inc. v. U.S. Postal Service, -- F.3d --, -- USPQ2d --, slip op. at 32 (Fed. Cir. August 28, 2017); presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; determining an estimated outcome and setting a price, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; and arranging a hierarchy of groups, sorting information, eliminating less restrictive pricing information and determining the price, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1331, 115 USPQ2d 1681, 1699 (Fed. Cir. 2015) (MPEP 2106.05(d))
Here, the steps are receiving or transmitting data over a network; storing and retrieving information in memory and electronically scanning or extracting data - all of which have been recognized by the courts as well-understood, routine and conventional functions.
The claims are directed to an abstract idea with additional generic computer elements that do not add meaningful limitations to the abstract idea because they require no more than a generic computer to perform generic computer functions that are well-understood, routine, and conventional activities previously known in the industry.
For the next step of the analysis, it must be determined whether the limitations present in the claims represent a patent-eligible application of the abstract idea. A claim directed to a judicial exception must be analyzed to determine whether the elements of the claim, considered both individually and as an ordered combination are sufficient to ensure that the claim as a whole amounts to significantly more than the exception itself.
For the role of a computer in a computer implemented invention to be deemed meaningful in the context of this analysis, it must involve more than performance of “well-understood, routine, [and] conventional activities previously known to the industry.” Further, “the mere recitation of a generic computer cannot transform a patent ineligible abstract idea into a patent-eligible invention.”
Applicant’s specification discloses the following:
“As described further herein, the engines of the insurance verification system 102, in this example, are configured to verify insurance coverage for a patient. To that end, the engines, in this example, include an ingestion engine 128, an optical character recognition (OCR) engine 130, an EHR/EMR engine 132, a data transfer engine 134, a validation engine 136, an error handling engine 138, a payor iteration engine 140, and a conversion engine 142. The respective engines may be implemented as a set of executable instructions organized as one or more statements, functions, routines, sub-routines, modules, scripts, and the like that are configured to, when executed, perform the intended functionality of the engine. The respective collections of executable instructions, therefore, are referred to for expedience as “engines” herein to convey the respective functional aspects of the insurance verification system 102, which may be implemented using one or more computing devices configured (e.g., programmed) with the collections of executable instructions stored as firmware and/or software by the one or more computing devices in non-volatile (e.g., read-only) memory and/or volatile (e.g., random access) memory.” (See Applicant Spec para 20)
“It will be appreciated that certain terminology used herein has been selected for convenience and without limitation. For example, the various engines discussed herein may also be referred to as respective modules of the insurance verification system and may be implemented as one or more corresponding functions, routines, sub-routines, and instruction sets as needed to provide the described functionality. As such, the insurance verification system 102 may be implemented using computer-readable and computer-executable instructions, stored on non-transitory computer readable media that, when executed by one or more processors of the insurance verification system, cause and configure the insurance verification system to perform the functionality described with respect to the various engines discussed above. Furthermore, the insurance verification system 102 may be implemented as a single computing device (e.g., a combined web and application server) or as a collection of distributed and interconnected (e.g., networked) computing devices each being configured to perform respective aspects of the insurance verification process.” (See Applicant Spec para 34)
“The disclosure is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the disclosed embodiments include, but are not limited to, personal computers (PCs), server computers, hand-held or laptop devices, smart phones, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.” (See Applicant Spec para 48)
“In Figure 6, an example of a computing device 600 that may be used in implementing one or more aspects described herein is shown. For example, a computing device 600 may, in some examples, implement one or more aspects of the disclosure by reading and/or executing instructions and performing one or more actions based on the instructions. The computing device 600 may represent, be incorporated in, and/or include various devices such as a desktop computer, a computer server, a mobile device (e.g., a laptop computer, a tablet computer, a smart phone, any other types of mobile computing devices, and the like), and/or any other type of data processing device.” (See Applicant Spec para 49)
Generic computer components recited as performing generic computer functions that are well-understood, routine and conventional activities amount to no more than implementing the abstract idea with a computerized system.
Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. The collective functions appear to be implemented using conventional computer systemization.
The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Upon reconsideration of the indicia noted under Step 2A in concert with the Step 2B considerations, the additional claim element(s) amounts to no more than mere instructions to apply the exception using generic computer components. The same analysis applies in Step 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The claim does not provide an inventive concept significantly more than the abstract idea.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The independent claims 1, 9 and 15 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent Claims 2-8, 10-14 and 16-20 further define the abstract idea that is presented in the respective independent Claims 1, 9 and 15 and are further grouped as certain methods of organizing human activity and are abstract for the same reasons and basis as presented above.
Dependent claim 2 provides further details regarding an image classification model trained to indicate an identity of a payor; a plurality of image segmentation models; and optical character recognition. As to the image classification model and image segmentation models, it appears that they are trained outside of the process disclosed as relayed by the specification and then are used by the OCR engine, which has been disclosed at a high level of generality as using the models as a generic tool. (See Applicant Specification para 24) The claim is still describing certain methods of organizing human activity.
Dependent Claims 3 and 11 provide further details as to iterating the plurality of API specifications based on population size. This still describes certain methods of organizing human activities.
Dependent Claims 4 and 12 provide further details as to iterating the plurality of API specifications based on geographic location. This still describes certain methods of organizing human activities.
Dependent Claims 5, 13 and 18 further detail that the first API is a default API and a second API is designated as a backup API for the payor to attempt to verify payment coverage if the primary API is not available. This still describes certain methods of organizing human activities.
Dependent Claims 6, 14, and 19 further detail instructions provided to convert data into a format based on a first API for a first payor and a second format based on a second API for a second payor. This still describes certain methods of organizing human activities.
Dependent Claim 7 further details that the request to verify payment coverage for the recipient is a batch request and that the system can iterate over the plurality of recipients indicated in the batch request for respectively verifying payment coverage. This still describes certain methods of organizing human activities.
Dependent Claim 8 further details converting a format of information included in the received response into a standardized format using a standardized response data model. This is being described at a high level of generality as a tool. The claim is still describing certain methods of organizing human activity.
Dependent Claims 10 and 16 provide further details regarding training an image classification model to indicate an identity of a payor of a plurality of payors associated with an insurance card image input into the image classification model by providing the plurality of first insurance card images and training a plurality of image segmentation models to segment an insurance card into a plurality of segments to indicate information used to verify payment coverage. As to the image classification model and the image segmentation models, it again appears that they are trained outside of the process as relayed by the specification and then used by the OCR engine, which has been disclosed at a high level of generality as using the models as a generic tool. (See Applicant Spec para 24) These claims are still describing certain methods of organizing human activity.
Dependent Claim 17 provides further details as to the iterating the plurality of API specifications based on population size or geographic location. This still describes certain methods of organizing human activities.
Dependent Claim 20 provides further details that the request to verify payment coverage is a request to verify insurance coverage by an insurance provider which is one of a medical, automobile or home insurance provider. This still describes certain methods of organizing human activities.
No further additional hardware components or systemization other than those found in the respective independent claims is recited, thus it is presumed that the claim is further utilizing the same generic systemization as presented above. The dependent claims do not include any additional elements that integrate the abstract idea into a practical application of the exception or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
Therefore, the dependent claims are also directed to an abstract idea.
Thus, Claims 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
6. Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Velaga (US PG Pub. 2022/0277167) in view of Zahora et al. (US PG Pub. 2022/0309592) (“Zahora”) and Hansen et al. (US PG Pub. 2020/0160955) (“Hansen”)
Regarding Claim 1, Velaga discloses the following:
A computing system for iteratively querying a plurality of payor computing systems to verify payment coverage for a recipient of a service of a service provider, the computer system comprising: (See Velaga para 60, Fig. 1A-B)
one or more processors; (See Velaga para 60, Figs. 1A-B)
a database storing a plurality of Application Programming Interface (API) specifications, wherein each API specification defines an API exposed by a respective one of the payor computing systems; and (See Velaga para 60
memory storing instructions that, when executed by the one or more processors, configure the computing system to: (See Velaga paras 60, 117, 126-131
receive, from a service provider system of the service provider, a request to verify payment coverage for the recipient of the service; (See Velaga paras 58-66, 73-78, 84
iterate over the plurality of API specifications to verify payment coverage for the recipient at least by, at each iteration: (See Velaga paras 112-113)
retrieving, from the database, an API specification for a payor computing system of the plurality of payor computing systems; (See Velaga paras 112-113)
constructing a verification request based on the retrieved API specification; (See Velaga paras 58-66, 73-78, 84, 98-102, 112-113
establishing an electronic connection, via one or more computing networks, with the payor computing system based on the retrieved API specification; (See Velaga paras 58-66, 73-78, 83-84, 98-102, 112-113
submitting, via the electronic connection, the verification request to the payor computing system based on the retrieved API specification; and (See Velaga paras 58-64, 73-78, 83-84, 98-102, 112-113
receiving, via the electronic connection and in response to the submitted verification request, a verification response from the payor computing system indicating whether a payor associated with the payor computing system provides payment coverage for the recipient; (See Velaga paras 78-79, 83-85, 97, 98-102,
based on at least one verification response indicating a payor that provides payment coverage for the recipient, sending to the service provider system an indication of an identity of the payor that provides payment coverage for the recipient; and (See Velaga paras 78-79, 83-85, 97)
based on no verification response indicating a payor that provides payment coverage for the recipient, sending to the service provider system an indication that payment coverage for the recipient could not be verified.
Velaga discloses her invention as to a system to verify documentation in real-time. (See Velaga para 59) The system includes a computing device, a verification system, and a repository/database. (See Velaga para 60) The computing device may be a computer, a laptop computer, a smartphone, and/or a tablet, among other examples. (See Velaga para 60) The computing device includes at least a processor, a memory, a graphical user interface (GUI) and a provider application where the provider application may be an engine, software program, service, or a software platform configured to be executable on the computing device. (See Velaga para 60) The database may include a third-party insurer database and/or a healthcare provider database. (See Velaga para 60)
The verification system may include numerous applications, components, and/or engines that are configured to receive and validate or verify information from documentation in real-time. (See Velaga para 61) The verification system includes a validation mechanism, an optical character recognition (OCR) mechanism, storage, and/or an image processing mechanism, among others. (See Velaga para 61)
Velaga also notes that API consumers (e.g., healthcare providers) may utilize the application gateway to utilize the serverless environment which may include numerous modules or engines, such as storage engine, an API management engine, a functions engine, a queue engine and/or a web jobs engine, among others. (See Velaga para 112) The serverless environment may also include a cosmos database and/or a cache. (See Velaga para 113) The SQL database and/or payers (e.g., insurance providers) may interact with one or more engines of the serverless environment. (See Velaga para 113)
While Velaga discloses verifying payment coverage for recipients of a service provider, constructing verification requests and discloses requests to verify payment coverage being submitted and receiving responses to those verification requests and notes that healthcare providers may use the application gateway to verify coverage, Velaga does not fully disclose a plurality of API specifications exposed by payor computing systems, iterating over the plurality of API specifications or additional details of constructing and submitting the verification requests based on the retrieved API specification or if there is no indication of verification of coverage for a recipient.
Zahora discloses systems and methods for calculating medical claims payment estimates that may receive a medical claim for a first patient including billing code(s) and demographic data, apply the demographic data to identify payer(s) for the first patient, access a data universe including patient data collection(s) of patient data records for a second group of patients, payer data collection(s) of data records for payers, and a financial history data collection include financial data records(s) for the first patient, identify for each billing code, a payer payment pattern based on a combination of patient data records and payer data record(s) corresponding to the payer for the first patient, identify a patient payment pattern based on the financial data record(s) and apply the payer payment pattern and the patient payment pattern to the medical claim for the first patient to calculate a payment estimation for the medical claim. (See Zahora Abstract)
In particular, Zahora discloses that the predictive analytics platform may receive all or a portion of input through an application programming interface (API) accessed by and/or batch files provided by the source of the input data (e.g., provider or billing service for the provider). (See Zahora para 97 – API specification)
In some embodiments, accessing includes accessing a set of records maintained by or provided by a third party, such as patient financial data and/or payer data. (See Zahora para 103) The payer data, in some implementations includes coverage details for insurance plans for each of a collection of payers and may include health insurance payers, medical insurance payers, dental insurance payers, vision insurance payers, and/or indemnity insurance payers. (See Zahora para 103 – payer data for a collection of payers)
In some implementations, the predictive analytics platform includes a coverage verification engine configured to automatically submit patient information to a payer system to confirm active coverage of the patient by the payer. (See Zahora para 122) To verify coverage, in some embodiments, the coverage verification engine automatically submits identifying demographic information through an API or other automated communication means to confirm status of coverage, the goal being to receive a response from at least one payer system confirming active coverage and thus, positively identifying the payer as a potential medical claim recipient for the service. (See Zahora para 122 – API specifications to confirm coverage)
In some implementations, the predictive analytics platform includes a payer pre-approval request engine for automatically submitting a pre-authorization request in relation to a scheduled service or recommended product. (See Zahora para 131) The payer pre-approval request engine, for example, may receive indication of a payer, a billing code, and a patient, for example, a payer identifier and a patient identifier. (See Zahora para 131) The payer pre-approval request engine may prepare a pre-authorization request based on this information, and, using the payer identification, determine automated contact information, such as an API, for submitting the pre-approval request. (See Zahora para 131)
The payer pre-approval request engine may also receive indication of a requestor such that, after receiving a response from the payer system, the payer pre-approval request engine may automatically alert the requestor of the outcome of the request (e.g., approved, denied). (See Zahora para 131 – indication of coverage for the recipient or coverage could not be verified) In various implementations, the platform may automatically issue a request for authorization from the payer, may automatically notify a third party to request authorization from the payer, or provide a notice to the user of the platform that the prior authorization is required. (See Zahora para 131)
In some implementations, the predictive analytics platform includes a liability applicability analysis engine configured to analyze information related to a medical claim to identify whether liability insurance is likely to apply. (See Zahora para 132) In some embodiments, the applicability analysis engine, performs natural language processing (NLP) portion of the claims data, service request data, and/or service provider data to identify terms and/or phrases indicative of a claim qualifying for liability coverage. (See Zahora para 132)
The predictive analytics platform, in some implementations, includes a patient information updating engine for expanding upon patient demographic data that may be insufficient for uniquely identifying the patient and/or that contains ambiguous or contradictory information on comparison to another trustworthy source of patient information. (See Zahora para 133) The patient information updating engine, for example, may receive patient information obtained from an intake process, such as a manual data entry process by service provider personnel into the predictive analytics platform or electronic chart data automatically transferred into the predictive analytics platform by one of the service providers. (See Zahora para 133 – provided by the service providers)
In some embodiments, the patient information updating engine analyzes the patient information in view of identification criteria to determine whether the supplied information is sufficient for positive identification of the patient. (See Zahora para 133) For example, a relatively common name and a significant geographic region (e.g., Paul Jacobs of New York) may be insufficient for positive identification of an individual, while a full name plus social security number may be adequate. (See Zahora para 133)
The rules in determining sufficient information, for example, may analyze the patient information in view of the key demographic information identified in the rules as being sufficient for matching purposes has been supplied. (See Zahora para 133) The predictive analytics platform, in some implementations, includes a payment trends analysis engine configured to analyze remittance received from payers and/or patients to identify patterns within the payments. (See Zahora para 135) Further, the patterns may be broken down into subsets, such as billing code categories, payer types (e.g., liability, primary insurance, federal medical coverage programs, etc.) and/or locations (e.g., for a service provider with multiple physical locations). (See Zahora para 135) In some embodiments, the payment trends analysis engine applies machine learning analysis, cluster analysis, and/or statistical data analysis to the remittance data to identify data patterns within the accessed records. (See Zahora para 135) For example, the payment trends analysis engine may include different machine learning classifiers trained to identify patterns related to the various sets and subsets of payment types. (See Zahora para 135, 137)
Further, in some implementations, the predictive analytics platform includes a coverage coordination analysis engine for coordinating benefits coverage between multiple payers available to the patient where the coverage coordination analysis engine, for example, may coordinate benefits based on a legal or administrative hierarchy, such as coordination of benefits (COB) responsibilities and may apply rules to determine an order of benefits application where the coverage coordination analysis engine, based upon the rules, in some embodiments, provides a percentage of each service covered by each of the available payers, an estimated amount to invoice to each of the available payers. and/or a hierarchical order in which to approach the available payers for reimbursement. (See Zahora para 140)
Zahora also discloses example methods and submethods for calculating a combined payment estimate by applying historical patient payment patterns and historical payer payment patterns. (See Zahora para 141)
In some implementations, the method begins with obtaining patient information and service information and if no payer has been identified within the incoming information, known information is used to search for one or more payers within the payer records. (See Zahora paras 142-143) For example, the patient information may be applied to looking up patient records maintained by the service provider to identify previously applied coverage. (See Zahora para 143) If a payer is not found within the patient information or the medical provider system, in some implementations, a payer identification process is conducted to identify one or more payers providing active coverage to the patient. (See Zahora para 144)
In some implementations, for each of the most likely payers, patient status is confirmed through connecting with the payer system where the coverage verification engine may perform confirmations for each of the most likely payers. (See Zahora para 148) If active coverage is confirmed for a payer, in some implementations, patient record information requested from the payer, for example, the coverage verification engine requests patient record information from the payer or receives patient record information automatically with the affirmative response from the payer system. (See Zahora para 149) In some implementations, while additional payer candidates have not yet been confirmed, the operations 336 to 342 are repeated. (See Zahora para 151 – iterated)
In some implementations, if no payer has been located, a lack of insurance status is returned. (See Zahora para 152 – no indication of verification of coverage for a recipient) If multiple payers are available, in some implementations, the payers are ranked in an order of preference which may be based at least in part on the service information and/or the coordination of benefits rules discussed above. (See Zahora para 153)
In some implementations, a submethod for determining authorization status of a patient based on active payer coverage is disclosed. (See Zahora para 182) In some implementations, the authorization status is returned, the authorization status may be returned to the method. (See Zahora para 186 – iterative process) If instead, coverage is not active, in some implementations, one or more payers is identified and if a payer is identified, the method proceeds with issuing a request to the payer system to determine authorization status of the services and returning authorization status; however, if no payer is identified, in some implementations, a status of a patient lacking payer coverage is returned and the status may be returned to the method. (See Zahora paras 186-189, 207-208 – iterative querying)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the methods of verifying payment coverage for recipients of a service provider of Velaga with the use of iterating use of APIs and submitting verification requests to determine coverage for a recipient as taught by Zahora in order to streamline verification processes.
While Velaga in view of Zahora discloses the invention as noted above, they do not squarely disclose that one or more APIs may be exposed by the payor systems.
Hansen discloses a central computing entity receives an encrypted request for performance of a back-end function, the encrypted request associated with a provider and a corresponding practice management system; generates a trigger indication that comprises patient identifying information based on the encrypted request processes the trigger indication using a program code module corresponding to the back-end function and operating on the central computing entity to generate a response; converts the response into a notification in a format corresponding to the practice management system; and encrypts and providers the notification such that a user computing entity receives the notification. (See Hansen Abstract)
In particular, the central computing entity (e.g., mediator module operating on the central computing entity) may issue one or more API calls to one or more APIs exposed by the EMR and/or practice management system and/or access information/data stored in memory media. (See Hansen para 66) In various embodiments, the communications between user computing entities (e.g., provider computing entities and/or patient/member computing entities and/or EMR and/or practice management systems operating thereon and a central computing entity mediator module, eligibility module, care estimate module, and/or the like operating on the central computing entity uses Fast Healthcare Interoperability Resources (FHIR) communication protocols. (See Hansen para 66) The mediator module may issue one or more FHIR API calls to access information/data corresponding to a patient/member and/or to provide a notification to a provider computing entity.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have further modified the methods of verifying payment coverage for recipients of a service provider of Velaga with the use of iterating use of APIs and submitting verification requests to determine coverage for a recipient as taught by Zahora and the issuance of one or more calls to one or more APIs exposed by the EMR or payor systems in order to more quickly provide verification processes.
Regarding Claim 9, this claim recites substantially similar limitations as those seen in Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above and/or is otherwise taught by the prior art. Further, Velaga discloses the following:
A computer-implemented method for iteratively querying a plurality of payor computing systems to verify payment coverage for a recipient of a service of a service provider, the computer-implemented method comprising: (See Velaga para 60, 68-80, 84-86, 126-131, Fig. 1A-B)
Regarding Claim 15, this claim recites substantially similar limitations as those seen in Claims 1 and 9 and as to those limitations is rejected for the same basis and reasons as disclosed above and/or is otherwise taught by the prior art. Further, Velaga discloses the following:
A non-transitory computer-readable medium storing instructions for iteratively querying a plurality of payor computing systems to verify payment coverage for a recipient of a service of a service provider, wherein the instructions, when executed by one or more processors of a computing system, cause the computing system to: (See Velaga para 60, 68-80, 84-86, 126-131, Fig. 1A-B)
Regarding Claim 2, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Velaga discloses the following:
further comprising:
an image classification model trained to indicate an identity of a payor, of a plurality of payors, associated with an insurance card image input into the image classification model; (See Velaga paras 63-64, 68-74, 76-78, 91-94, 106-108, Fig. 2 – extract patient identifier; recognize health insurance document; relate to third-party insurer or healthcare provider database; engage in image classification via an AI or machine learning layer; capture a user image of a healthcare insurance card)
a plurality of image segmentation models, wherein each image segmentation model is trained to segment an insurance card image for a respective one of the plurality of payors into a plurality of segments that each respectively indicate information used to verify payment coverage; (See Velaga paras 68-76, 91-94, 106-108, Fig. 2 – image segmentation)
wherein the instructions, when executed by the one or more processors, further configure the computing system to: (See Velaga paras 126-131
receive, from a service provider system of the service provider, an insurance card image associated with the recipient; (See Velaga paras 106-108, Fig. 2)
identify, by providing the received insurance card image to the image classification model, a payor indicated by the received insurance card image; (See Velaga paras 68-76, 91-94, 106-113, Fig. 2)
segment, by providing the received insurance card image to an image segmentation model associated with the identified payor, the received insurance card image into a plurality of segments; and (See Velaga paras 91-94, 106-113, Fig. 2)
obtain, from one or more segments of the plurality of segments using optical character recognition, information used to verify payment coverage for the recipient; and (See Velaga paras 68-76, 91-94, 106-113, Fig. 2)
wherein the instructions, when executed by the one or more processors, configure the computing system to construct the verification request further based on the information obtained from the one or more segments. (See Velaga paras 68-80, 84-86, 91-94, 106-113, Fig. 2)
Regarding Claims 3 and 11, these substantially similar claims recite the limitations of Claims 1 and 9 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Velaga in view of Zahora and Hansen discloses the following:
wherein the instructions, when executed by the one or more processors, configure the computing system to iterate over the plurality of API specifications at least by iterating over the plurality of API specifications based on insured population size, wherein the computing system is configured to perform a first iteration for a first payor determined to have a first insured population size before a second iteration for a second payor determined to have a second insured population size that is smaller than the first insured population size.
Velaga discloses her invention as to a system to verify documentation in real-time. (See Velaga para 59) The system includes a computing device, a verification system, and a repository/database. (See Velaga para 60) The computing device may be a computer, a laptop computer, a smartphone, and/or a tablet, among other examples. (See Velaga para 60) The computing device includes at least a processor, a memory, a graphical user interface (GUI) and a provider application where the provider application may be an engine, software program, service, or a software platform configured to be executable on the computing device. (See Velaga para 60) The database may include a third-party insurer database and/or a healthcare provider database. (See Velaga para 60)
The verification system may include numerous applications, components, and/or engines that are configured to receive and validate or verify information from documentation in real-time. (See Velaga para 61) The verification system includes a validation mechanism, an optical character recognition (OCR) mechanism, storage, and/or an image processing mechanism, among others. (See Velaga para 61)
Velaga also notes that API consumers (e.g., healthcare providers) may utilize the application gateway to utilize the serverless environment which may include numerous modules or engines, such as storage engine, an API management engine, a functions engine, a queue engine and/or a web jobs engine, among others. (See Velaga para 112) The serverless environment may also include a cosmos database and/or a cache. (See Velaga para 113) The SQL database and/or payers (e.g., insurance providers) may interact with one or more engines of the serverless environment. (See Velaga para 113)
While Velaga discloses verifying payment coverage for recipients of a service provider, constructing verification requests and discloses requests to verify payment coverage being submitted and receiving responses to those verification requests and notes that healthcare providers may use the application gateway to verify coverage, Velaga does not fully disclose a plurality of API specifications exposed by payor computing systems, iterating over the plurality of API specifications or additional details of constructing and submitting the verification requests based on the retrieved API specification or if there is no indication of verification of coverage for a recipient or iterating based on population size.
Zahora discloses systems and methods for calculating medical claims payment estimates that may receive a medical claim for a first patient including billing code(s) and demographic data, apply the demographic data to identify payer(s) for the first patient, access a data universe including patient data collection(s) of patient data records for a second group of patients, payer data collection(s) of data records for payers, and a financial history data collection include financial data records(s) for the first patient, identify for each billing code, a payer payment pattern based on a combination of patient data records and payer data record(s) corresponding to the payer for the first patient, identify a patient payment pattern based on the financial data record(s) and apply the payer payment pattern and the patient payment pattern to the medical claim for the first patient to calculate a payment estimation for the medical claim. (See Zahora Abstract)
In particular, Zahora discloses that the predictive analytics platform may receive all or a portion of input through an application programming interface (API) accessed by and/or batch files provided by the source of the input data (e.g., provider or billing service for the provider). (See Zahora para 97 – API specification)
In some embodiments, accessing includes accessing a set of records maintained by or provided by a third party, such as patient financial data and/or payer data. (See Zahora para 103) The payer data, in some implementations includes coverage details for insurance plans for each of a collection of payers and may include health insurance payers, medical insurance payers, dental insurance payers, vision insurance payers, and/or indemnity insurance payers. (See Zahora para 103 – payer data for a collection of payers)
In some implementations, the predictive analytics platform includes a coverage verification engine configured to automatically submit patient information to a payer system to confirm active coverage of the patient by the payer. (See Zahora para 122) To verify coverage, in some embodiments, the coverage verification engine automatically submits identifying demographic information through an API or other automated communication means to confirm status of coverage, the goal being to receive a response from at least one payer system confirming active coverage and thus, positively identifying the payer as a potential medical claim recipient for the service. (See Zahora para 122 – API specifications to confirm coverage)
In some implementations, the predictive analytics platform includes a payer pre-approval request engine for automatically submitting a pre-authorization request in relation to a scheduled service or recommended product. (See Zahora para 131) The payer pre-approval request engine, for example, may receive indication of a payer, a billing code, and a patient, for example, a payer identifier and a patient identifier. (See Zahora para 131) The payer pre-approval request engine may prepare a pre-authorization request based on this information, and, using the payer identification, determine automated contact information, such as an API, for submitting the pre-approval request. (See Zahora para 131)
The payer pre-approval request engine may also receive indication of a requestor such that, after receiving a response from the payer system, the payer pre-approval request engine may automatically alert the requestor of the outcome of the request (e.g., approved, denied). (See Zahora para 131 – indication of coverage for the recipient or coverage could not be verified) In various implementations, the platform may automatically issue a request for authorization from the payer, may automatically notify a third party to request authorization from the payer, or provide a notice to the user of the platform that the prior authorization is required. (See Zahora para 131)
In some implementations, the predictive analytics platform includes a liability applicability analysis engine configured to analyze information related to a medical claim to identify whether liability insurance is likely to apply. (See Zahora para 132) In some embodiments, the applicability analysis engine, performs natural language processing (NLP) portion of the claims data, service request data, and/or service provider data to identify terms and/or phrases indicative of a claim qualifying for liability coverage. (See Zahora para 132)
The predictive analytics platform, in some implementations, includes a patient information updating engine for expanding upon patient demographic data that may be insufficient for uniquely identifying the patient and/or that contains ambiguous or contradictory information on comparison to another trustworthy source of patient information. (See Zahora para 133) The patient information updating engine, for example, may receive patient information obtained from an intake process, such as a manual data entry process by service provider personnel into the predictive analytics platform or electronic chart data automatically transferred into the predictive analytics platform by one of the service providers. (See Zahora para 133 – provided by the service providers)
In some embodiments, the patient information updating engine analyzes the patient information in view of identification criteria to determine whether the supplied information is sufficient for positive identification of the patient. (See Zahora para 133 – population size) For example, a relatively common name and a significant geographic region (e.g., Paul Jacobs of New York) may be insufficient for positive identification of an individual, while a full name plus social security number may be adequate. (See Zahora para 133 – smaller population size)
The rules in determining sufficient information, for example, may analyze the patient information in view of the key demographic information identified in the rules as being sufficient for matching purposes has been supplied. (See Zahora para 133) The predictive analytics platform, in some implementations, includes a payment trends analysis engine configured to analyze remittance received from payers and/or patients to identify patterns within the payments. (See Zahora para 135) Further, the patterns may be broken down into subsets, such as billing code categories, payer types (e.g., liability, primary insurance, federal medical coverage programs, etc.) and/or locations (e.g., for a service provider with multiple physical locations). (See Zahora para 135) In some embodiments, the payment trends analysis engine applies machine learning analysis, cluster analysis, and/or statistical data analysis to the remittance data to identify data patterns within the accessed records. (See Zahora para 135) For example, the payment trends analysis engine may include different machine learning classifiers trained to identify patterns related to the various sets and subsets of payment types. (See Zahora para 135, 137)
Further, in some implementations, the predictive analytics platform includes a coverage coordination analysis engine for coordinating benefits coverage between multiple payers available to the patient where the coverage coordination analysis engine, for example, may coordinate benefits based on a legal or administrative hierarchy, such as coordination of benefits (COB) responsibilities and may apply rules to determine an order of benefits application where the coverage coordination analysis engine, based upon the rules, in some embodiments, provides a percentage of each service covered by each of the available payers, an estimated amount to invoice to each of the available payers. and/or a hierarchical order in which to approach the available payers for reimbursement. (See Zahora para 140)
Zahora also discloses example methods and submethods for calculating a combined payment estimate by applying historical patient payment patterns and historical payer payment patterns. (See Zahora para 141)
In some implementations, the method begins with obtaining patient information and service information and if no payer has been identified within the incoming information, known information is used to search for one or more payers within the payer records. (See Zahora paras 142-143) For example, the patient information may be applied to looking up patient records maintained by the service provider to identify previously applied coverage. (See Zahora para 143) If a payer is not found within the patient information or the medical provider system, in some implementations, a payer identification process is conducted to identify one or more payers providing active coverage to the patient. (See Zahora para 144)
In some implementations, for each of the most likely payers, patient status is confirmed through connecting with the payer system where the coverage verification engine may perform confirmations for each of the most likely payers. (See Zahora para 148) If active coverage is confirmed for a payer, in some implementations, patient record information requested from the payer, for example, the coverage verification engine requests patient record information from the payer or receives patient record information automatically with the affirmative response from the payer system. (See Zahora para 149) In some implementations, while additional payer candidates have not yet been confirmed, the operations 336 to 342 are repeated. (See Zahora para 151 – iterated)
In some implementations, if no payer has been located, a lack of insurance status is returned. (See Zahora para 152 – no indication of verification of coverage for a recipient) If multiple payers are available, in some implementations, the payers are ranked in an order of preference which may be based at least in part on the service information and/or the coordination of benefits rules discussed above. (See Zahora para 153)
In some implementations, a submethod for determining authorization status of a patient based on active payer coverage is disclosed. (See Zahora para 182) In some implementations, the authorization status is returned, the authorization status may be returned to the method. (See Zahora para 186 – iterative process) If instead, coverage is not active, in some implementations, one or more payers is identified and if a payer is identified, the method proceeds with issuing a request to the payer system to determine authorization status of the services and returning authorization status; however, if no payer is identified, in some implementations, a status of a patient lacking payer coverage is returned and the status may be returned to the method. (See Zahora paras 186-189, 207-208 – iterative querying)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the methods of verifying payment coverage for recipients of a service provider of Velaga with the use of iterating use of APIs and submitting verification requests to determine coverage for a recipient as taught by Zahora in order to streamline verification processes.
While Velaga in view of Zahora discloses the invention as noted above, they do not squarely disclose that one or more APIs may be exposed by the payor systems.
Hansen discloses a central computing entity receives an encrypted request for performance of a back-end function, the encrypted request associated with a provider and a corresponding practice management system; generates a trigger indication that comprises patient identifying information based on the encrypted request processes the trigger indication using a program code module corresponding to the back-end function and operating on the central computing entity to generate a response; converts the response into a notification in a format corresponding to the practice management system; and encrypts and providers the notification such that a user computing entity receives the notification. (See Hansen Abstract)
In particular, the central computing entity (e.g., mediator module operating on the central computing entity) may issue one or more API calls to one or more APIs exposed by the EMR and/or practice management system and/or access information/data stored in memory media. (See Hansen para 66) In various embodiments, the communications between user computing entities (e.g., provider computing entities and/or patient/member computing entities and/or EMR and/or practice management systems operating thereon and a central computing entity mediator module, eligibility module, care estimate module, and/or the like operating on the central computing entity uses Fast Healthcare Interoperability Resources (FHIR) communication protocols. (See Hansen para 66) The mediator module may issue one or more FHIR API calls to access information/data corresponding to a patient/member and/or to provide a notification to a provider computing entity.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have further modified the methods of verifying payment coverage for recipients of a service provider of Velaga with the use of iterating use of APIs and submitting verification requests to determine coverage for a recipient as taught by Zahora and the issuance of one or more calls to one or more APIs exposed by the EMR or payor systems in order to more quickly provide verification processes.
Regarding Claims 4 and 12, these substantially similar claims recite the limitations of Claims 1 and 9 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Velaga in view of Zahora and Hansen discloses the following:
wherein the instructions, when executed by the one or more processors, configure the computing system to iterate over the plurality of API specifications at least by iterating over the plurality of API specifications based on a geographic location of the recipient, wherein the computing system is configured to perform a first iteration for a first payor that is located in the same geographic location as the recipient before a second iteration for a second payor that is not located in the same geographic location as the recipient.
Velaga discloses her invention as to a system to verify documentation in real-time. (See Velaga para 59) The system includes a computing device, a verification system, and a repository/database. (See Velaga para 60) The computing device may be a computer, a laptop computer, a smartphone, and/or a tablet, among other examples. (See Velaga para 60) The computing device includes at least a processor, a memory, a graphical user interface (GUI) and a provider application where the provider application may be an engine, software program, service, or a software platform configured to be executable on the computing device. (See Velaga para 60) The database may include a third-party insurer database and/or a healthcare provider database. (See Velaga para 60)
The verification system may include numerous applications, components, and/or engines that are configured to receive and validate or verify information from documentation in real-time. (See Velaga para 61) The verification system includes a validation mechanism, an optical character recognition (OCR) mechanism, storage, and/or an image processing mechanism, among others. (See Velaga para 61)
Velaga also notes that API consumers (e.g., healthcare providers) may utilize the application gateway to utilize the serverless environment which may include numerous modules or engines, such as storage engine, an API management engine, a functions engine, a queue engine and/or a web jobs engine, among others. (See Velaga para 112) The serverless environment may also include a cosmos database and/or a cache. (See Velaga para 113) The SQL database and/or payers (e.g., insurance providers) may interact with one or more engines of the serverless environment. (See Velaga para 113)
While Velaga discloses verifying payment coverage for recipients of a service provider, constructing verification requests and discloses requests to verify payment coverage being submitted and receiving responses to those verification requests and notes that healthcare providers may use the application gateway to verify coverage, Velaga does not fully disclose a plurality of API specifications exposed by payor computing systems, iterating over the plurality of API specifications or additional details of constructing and submitting the verification requests based on the retrieved API specification or if there is no indication of verification of coverage for a recipient or iterating based on geographic size.
Zahora discloses systems and methods for calculating medical claims payment estimates that may receive a medical claim for a first patient including billing code(s) and demographic data, apply the demographic data to identify payer(s) for the first patient, access a data universe including patient data collection(s) of patient data records for a second group of patients, payer data collection(s) of data records for payers, and a financial history data collection include financial data records(s) for the first patient, identify for each billing code, a payer payment pattern based on a combination of patient data records and payer data record(s) corresponding to the payer for the first patient, identify a patient payment pattern based on the financial data record(s) and apply the payer payment pattern and the patient payment pattern to the medical claim for the first patient to calculate a payment estimation for the medical claim. (See Zahora Abstract)
In particular, Zahora discloses that the predictive analytics platform may receive all or a portion of input through an application programming interface (API) accessed by and/or batch files provided by the source of the input data (e.g., provider or billing service for the provider). (See Zahora para 97 – API specification)
In some embodiments, accessing includes accessing a set of records maintained by or provided by a third party, such as patient financial data and/or payer data. (See Zahora para 103) The payer data, in some implementations includes coverage details for insurance plans for each of a collection of payers and may include health insurance payers, medical insurance payers, dental insurance payers, vision insurance payers, and/or indemnity insurance payers. (See Zahora para 103 – payer data for a collection of payers)
In some implementations, the predictive analytics platform includes a coverage verification engine configured to automatically submit patient information to a payer system to confirm active coverage of the patient by the payer. (See Zahora para 122) To verify coverage, in some embodiments, the coverage verification engine automatically submits identifying demographic information through an API or other automated communication means to confirm status of coverage, the goal being to receive a response from at least one payer system confirming active coverage and thus, positively identifying the payer as a potential medical claim recipient for the service. (See Zahora para 122 – API specifications to confirm coverage)
In some implementations, the predictive analytics platform includes a payer pre-approval request engine for automatically submitting a pre-authorization request in relation to a scheduled service or recommended product. (See Zahora para 131) The payer pre-approval request engine, for example, may receive indication of a payer, a billing code, and a patient, for example, a payer identifier and a patient identifier. (See Zahora para 131) The payer pre-approval request engine may prepare a pre-authorization request based on this information, and, using the payer identification, determine automated contact information, such as an API, for submitting the pre-approval request. (See Zahora para 131)
The payer pre-approval request engine may also receive indication of a requestor such that, after receiving a response from the payer system, the payer pre-approval request engine may automatically alert the requestor of the outcome of the request (e.g., approved, denied). (See Zahora para 131 – indication of coverage for the recipient or coverage could not be verified) In various implementations, the platform may automatically issue a request for authorization from the payer, may automatically notify a third party to request authorization from the payer, or provide a notice to the user of the platform that the prior authorization is required. (See Zahora para 131)
In some implementations, the predictive analytics platform includes a liability applicability analysis engine configured to analyze information related to a medical claim to identify whether liability insurance is likely to apply. (See Zahora para 132) In some embodiments, the applicability analysis engine, performs natural language processing (NLP) portion of the claims data, service request data, and/or service provider data to identify terms and/or phrases indicative of a claim qualifying for liability coverage. (See Zahora para 132)
The predictive analytics platform, in some implementations, includes a patient information updating engine for expanding upon patient demographic data that may be insufficient for uniquely identifying the patient and/or that contains ambiguous or contradictory information on comparison to another trustworthy source of patient information. (See Zahora para 133) The patient information updating engine, for example, may receive patient information obtained from an intake process, such as a manual data entry process by service provider personnel into the predictive analytics platform or electronic chart data automatically transferred into the predictive analytics platform by one of the service providers. (See Zahora para 133 – provided by the service providers)
In some embodiments, the patient information updating engine analyzes the patient information in view of identification criteria to determine whether the supplied information is sufficient for positive identification of the patient. (See Zahora para 133) For example, a relatively common name and a significant geographic region (e.g., Paul Jacobs of New York) may be insufficient for positive identification of an individual, while a full name plus social security number may be adequate. (See Zahora para 133 – based on geographic size )
The rules in determining sufficient information, for example, may analyze the patient information in view of the key demographic information identified in the rules as being sufficient for matching purposes has been supplied. (See Zahora para 133) The predictive analytics platform, in some implementations, includes a payment trends analysis engine configured to analyze remittance received from payers and/or patients to identify patterns within the payments. (See Zahora para 135) Further, the patterns may be broken down into subsets, such as billing code categories, payer types (e.g., liability, primary insurance, federal medical coverage programs, etc.) and/or locations (e.g., for a service provider with multiple physical locations). (See Zahora para 135) In some embodiments, the payment trends analysis engine applies machine learning analysis, cluster analysis, and/or statistical data analysis to the remittance data to identify data patterns within the accessed records. (See Zahora para 135) For example, the payment trends analysis engine may include different machine learning classifiers trained to identify patterns related to the various sets and subsets of payment types. (See Zahora para 135, 137)
Further, in some implementations, the predictive analytics platform includes a coverage coordination analysis engine for coordinating benefits coverage between multiple payers available to the patient where the coverage coordination analysis engine, for example, may coordinate benefits based on a legal or administrative hierarchy, such as coordination of benefits (COB) responsibilities and may apply rules to determine an order of benefits application where the coverage coordination analysis engine, based upon the rules, in some embodiments, provides a percentage of each service covered by each of the available payers, an estimated amount to invoice to each of the available payers. and/or a hierarchical order in which to approach the available payers for reimbursement. (See Zahora para 140)
Zahora also discloses example methods and submethods for calculating a combined payment estimate by applying historical patient payment patterns and historical payer payment patterns. (See Zahora para 141)
In some implementations, the method begins with obtaining patient information and service information and if no payer has been identified within the incoming information, known information is used to search for one or more payers within the payer records. (See Zahora paras 142-143) For example, the patient information may be applied to looking up patient records maintained by the service provider to identify previously applied coverage. (See Zahora para 143) If a payer is not found within the patient information or the medical provider system, in some implementations, a payer identification process is conducted to identify one or more payers providing active coverage to the patient. (See Zahora para 144)
In some implementations, for each of the most likely payers, patient status is confirmed through connecting with the payer system where the coverage verification engine may perform confirmations for each of the most likely payers. (See Zahora para 148) If active coverage is confirmed for a payer, in some implementations, patient record information requested from the payer, for example, the coverage verification engine requests patient record information from the payer or receives patient record information automatically with the affirmative response from the payer system. (See Zahora para 149) In some implementations, while additional payer candidates have not yet been confirmed, the operations 336 to 342 are repeated. (See Zahora para 151 – iterated)
In some implementations, if no payer has been located, a lack of insurance status is returned. (See Zahora para 152 – no indication of verification of coverage for a recipient) If multiple payers are available, in some implementations, the payers are ranked in an order of preference which may be based at least in part on the service information and/or the coordination of benefits rules discussed above. (See Zahora para 153)
In some implementations, a submethod for determining authorization status of a patient based on active payer coverage is disclosed. (See Zahora para 182) In some implementations, the authorization status is returned, the authorization status may be returned to the method. (See Zahora para 186 – iterative process) If instead, coverage is not active, in some implementations, one or more payers is identified and if a payer is identified, the method proceeds with issuing a request to the payer system to determine authorization status of the services and returning authorization status; however, if no payer is identified, in some implementations, a status of a patient lacking payer coverage is returned and the status may be returned to the method. (See Zahora paras 186-189, 207-208 – iterative querying)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the methods of verifying payment coverage for recipients of a service provider of Velaga with the use of iterating use of APIs and submitting verification requests to determine coverage for a recipient as taught by Zahora in order to streamline verification processes.
While Velaga in view of Zahora discloses the invention as noted above, they do not squarely disclose that one or more APIs may be exposed by the payor systems.
Hansen discloses a central computing entity receives an encrypted request for performance of a back-end function, the encrypted request associated with a provider and a corresponding practice management system; generates a trigger indication that comprises patient identifying information based on the encrypted request processes the trigger indication using a program code module corresponding to the back-end function and operating on the central computing entity to generate a response; converts the response into a notification in a format corresponding to the practice management system; and encrypts and providers the notification such that a user computing entity receives the notification. (See Hansen Abstract)
In particular, the central computing entity (e.g., mediator module operating on the central computing entity) may issue one or more API calls to one or more APIs exposed by the EMR and/or practice management system and/or access information/data stored in memory media. (See Hansen para 66) In various embodiments, the communications between user computing entities (e.g., provider computing entities and/or patient/member computing entities and/or EMR and/or practice management systems operating thereon and a central computing entity mediator module, eligibility module, care estimate module, and/or the like operating on the central computing entity uses Fast Healthcare Interoperability Resources (FHIR) communication protocols. (See Hansen para 66) The mediator module may issue one or more FHIR API calls to access information/data corresponding to a patient/member and/or to provide a notification to a provider computing entity.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have further modified the methods of verifying payment coverage for recipients of a service provider of Velaga with the use of iterating use of APIs and submitting verification requests to determine coverage for a recipient as taught by Zahora and the issuance of one or more calls to one or more APIs exposed by the EMR or payor systems in order to more quickly provide verification processes.
Regarding Claims 5, 13 and 18, these substantially similar claims recite the limitations of Claims 1, 9 and 15 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Velaga in view of Zahora and Hansen discloses the following:
wherein:
the plurality of APIs comprise a first API designated as a default API for a payor and a second API designated as a backup API for the payor; and
the instructions, when executed by the one or more processors, configure the computing system to, based on determining that the default API is not available to verify payment coverage by the payor for the recipient, attempt to verify payment coverage by the payor for the recipient using the backup API.
Velaga discloses her invention as to a system to verify documentation in real-time. (See Velaga para 59) The system includes a computing device, a verification system, and a repository/database. (See Velaga para 60) The computing device may be a computer, a laptop computer, a smartphone, and/or a tablet, among other examples. (See Velaga para 60) The computing device includes at least a processor, a memory, a graphical user interface (GUI) and a provider application where the provider application may be an engine, software program, service, or a software platform configured to be executable on the computing device. (See Velaga para 60) The database may include a third-party insurer database and/or a healthcare provider database. (See Velaga para 60)
The verification system may include numerous applications, components, and/or engines that are configured to receive and validate or verify information from documentation in real-time. (See Velaga para 61) The verification system includes a validation mechanism, an optical character recognition (OCR) mechanism, storage, and/or an image processing mechanism, among others. (See Velaga para 61)
Velaga also notes that API consumers (e.g., healthcare providers) may utilize the application gateway to utilize the serverless environment which may include numerous modules or engines, such as storage engine, an API management engine, a functions engine, a queue engine and/or a web jobs engine, among others. (See Velaga para 112) The serverless environment may also include a cosmos database and/or a cache. (See Velaga para 113) The SQL database and/or payers (e.g., insurance providers) may interact with one or more engines of the serverless environment. (See Velaga para 113)
While Velaga discloses verifying payment coverage for recipients of a service provider, constructing verification requests and discloses requests to verify payment coverage being submitted and receiving responses to those verification requests and notes that healthcare providers may use the application gateway to verify coverage, Velaga does not fully disclose a plurality of API specifications exposed by payor computing systems, iterating over the plurality of API specifications or additional details of constructing and submitting the verification requests based on the retrieved API specification or if there is no indication of verification of coverage for a recipient or that there is a default and backup API to verify payment coverage.
Zahora discloses systems and methods for calculating medical claims payment estimates that may receive a medical claim for a first patient including billing code(s) and demographic data, apply the demographic data to identify payer(s) for the first patient, access a data universe including patient data collection(s) of patient data records for a second group of patients, payer data collection(s) of data records for payers, and a financial history data collection include financial data records(s) for the first patient, identify for each billing code, a payer payment pattern based on a combination of patient data records and payer data record(s) corresponding to the payer for the first patient, identify a patient payment pattern based on the financial data record(s) and apply the payer payment pattern and the patient payment pattern to the medical claim for the first patient to calculate a payment estimation for the medical claim. (See Zahora Abstract)
In particular, Zahora discloses that the predictive analytics platform may receive all or a portion of input through an application programming interface (API) accessed by and/or batch files provided by the source of the input data (e.g., provider or billing service for the provider). (See Zahora para 97 – API specification)
In some embodiments, accessing includes accessing a set of records maintained by or provided by a third party, such as patient financial data and/or payer data. (See Zahora para 103) The payer data, in some implementations includes coverage details for insurance plans for each of a collection of payers and may include health insurance payers, medical insurance payers, dental insurance payers, vision insurance payers, and/or indemnity insurance payers. (See Zahora para 103 – payer data for a collection of payers)
In some implementations, the predictive analytics platform includes a coverage verification engine configured to automatically submit patient information to a payer system to confirm active coverage of the patient by the payer. (See Zahora para 122) To verify coverage, in some embodiments, the coverage verification engine automatically submits identifying demographic information through an API or other automated communication means to confirm status of coverage, the goal being to receive a response from at least one payer system confirming active coverage and thus, positively identifying the payer as a potential medical claim recipient for the service. (See Zahora para 122 – API specifications to confirm coverage)
In some implementations, the predictive analytics platform includes a payer pre-approval request engine for automatically submitting a pre-authorization request in relation to a scheduled service or recommended product. (See Zahora para 131) The payer pre-approval request engine, for example, may receive indication of a payer, a billing code, and a patient, for example, a payer identifier and a patient identifier. (See Zahora para 131) The payer pre-approval request engine may prepare a pre-authorization request based on this information, and, using the payer identification, determine automated contact information, such as an API, for submitting the pre-approval request. (See Zahora para 131)
The payer pre-approval request engine may also receive indication of a requestor such that, after receiving a response from the payer system, the payer pre-approval request engine may automatically alert the requestor of the outcome of the request (e.g., approved, denied). (See Zahora para 131 – indication of coverage for the recipient or coverage could not be verified) In various implementations, the platform may automatically issue a request for authorization from the payer, may automatically notify a third party to request authorization from the payer, or provide a notice to the user of the platform that the prior authorization is required. (See Zahora para 131)
In some implementations, the predictive analytics platform includes a liability applicability analysis engine configured to analyze information related to a medical claim to identify whether liability insurance is likely to apply. (See Zahora para 132) In some embodiments, the applicability analysis engine, performs natural language processing (NLP) portion of the claims data, service request data, and/or service provider data to identify terms and/or phrases indicative of a claim qualifying for liability coverage. (See Zahora para 132)
The predictive analytics platform, in some implementations, includes a patient information updating engine for expanding upon patient demographic data that may be insufficient for uniquely identifying the patient and/or that contains ambiguous or contradictory information on comparison to another trustworthy source of patient information. (See Zahora para 133) The patient information updating engine, for example, may receive patient information obtained from an intake process, such as a manual data entry process by service provider personnel into the predictive analytics platform or electronic chart data automatically transferred into the predictive analytics platform by one of the service providers. (See Zahora para 133 – provided by the service providers)
In some embodiments, the patient information updating engine analyzes the patient information in view of identification criteria to determine whether the supplied information is sufficient for positive identification of the patient. (See Zahora para 133) For example, a relatively common name and a significant geographic region (e.g., Paul Jacobs of New York) may be insufficient for positive identification of an individual, while a full name plus social security number may be adequate. (See Zahora para 133)
The rules in determining sufficient information, for example, may analyze the patient information in view of the key demographic information identified in the rules as being sufficient for matching purposes has been supplied. (See Zahora para 133) The predictive analytics platform, in some implementations, includes a payment trends analysis engine configured to analyze remittance received from payers and/or patients to identify patterns within the payments. (See Zahora para 135) Further, the patterns may be broken down into subsets, such as billing code categories, payer types (e.g., liability, primary insurance, federal medical coverage programs, etc.) and/or locations (e.g., for a service provider with multiple physical locations). (See Zahora para 135) In some embodiments, the payment trends analysis engine applies machine learning analysis, cluster analysis, and/or statistical data analysis to the remittance data to identify data patterns within the accessed records. (See Zahora para 135) For example, the payment trends analysis engine may include different machine learning classifiers trained to identify patterns related to the various sets and subsets of payment types. (See Zahora para 135, 137)
Further, in some implementations, the predictive analytics platform includes a coverage coordination analysis engine for coordinating benefits coverage between multiple payers available to the patient where the coverage coordination analysis engine, for example, may coordinate benefits based on a legal or administrative hierarchy, such as coordination of benefits (COB) responsibilities and may apply rules to determine an order of benefits application where the coverage coordination analysis engine, based upon the rules, in some embodiments, provides a percentage of each service covered by each of the available payers, an estimated amount to invoice to each of the available payers. and/or a hierarchical order in which to approach the available payers for reimbursement. (See Zahora para 140 – coordination of benefits in hierarchical order would use a default payer followed by a backup payer)
Zahora also discloses example methods and submethods for calculating a combined payment estimate by applying historical patient payment patterns and historical payer payment patterns. (See Zahora para 141)
In some implementations, the method begins with obtaining patient information and service information and if no payer has been identified within the incoming information, known information is used to search for one or more payers within the payer records. (See Zahora paras 142-143) For example, the patient information may be applied to looking up patient records maintained by the service provider to identify previously applied coverage. (See Zahora para 143) If a payer is not found within the patient information or the medical provider system, in some implementations, a payer identification process is conducted to identify one or more payers providing active coverage to the patient. (See Zahora para 144 – if a first payer is not identified, a backup payer is looked up)
In some implementations, for each of the most likely payers, patient status is confirmed through connecting with the payer system where the coverage verification engine may perform confirmations for each of the most likely payers. (See Zahora para 148) If active coverage is confirmed for a payer, in some implementations, patient record information requested from the payer, for example, the coverage verification engine requests patient record information from the payer or receives patient record information automatically with the affirmative response from the payer system. (See Zahora para 149) In some implementations, while additional payer candidates have not yet been confirmed, the operations 336 to 342 are repeated. (See Zahora para 151 – iterated)
In some implementations, if no payer has been located, a lack of insurance status is returned. (See Zahora para 152 – no indication of verification of coverage for a recipient) If multiple payers are available, in some implementations, the payers are ranked in an order of preference which may be based at least in part on the service information and/or the coordination of benefits rules discussed above. (See Zahora para 153)
In some implementations, a submethod for determining authorization status of a patient based on active payer coverage is disclosed. (See Zahora para 182) In some implementations, the authorization status is returned, the authorization status may be returned to the method. (See Zahora para 186 – iterative process) If instead, coverage is not active, in some implementations, one or more payers is identified and if a payer is identified, the method proceeds with issuing a request to the payer system to determine authorization status of the services and returning authorization status; however, if no payer is identified, in some implementations, a status of a patient lacking payer coverage is returned and the status may be returned to the method. (See Zahora paras 186-189, 207-208 – iterative querying)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the methods of verifying payment coverage for recipients of a service provider of Velaga with the use of iterating use of APIs and submitting verification requests to determine coverage for a recipient as taught by Zahora in order to streamline verification processes.
While Velaga in view of Zahora discloses the invention as noted above, they do not squarely disclose that one or more APIs may be exposed by the payor systems.
Hansen discloses a central computing entity receives an encrypted request for performance of a back-end function, the encrypted request associated with a provider and a corresponding practice management system; generates a trigger indication that comprises patient identifying information based on the encrypted request processes the trigger indication using a program code module corresponding to the back-end function and operating on the central computing entity to generate a response; converts the response into a notification in a format corresponding to the practice management system; and encrypts and providers the notification such that a user computing entity receives the notification. (See Hansen Abstract)
In particular, the central computing entity (e.g., mediator module operating on the central computing entity) may issue one or more API calls to one or more APIs exposed by the EMR and/or practice management system and/or access information/data stored in memory media. (See Hansen para 66) In various embodiments, the communications between user computing entities (e.g., provider computing entities and/or patient/member computing entities and/or EMR and/or practice management systems operating thereon and a central computing entity mediator module, eligibility module, care estimate module, and/or the like operating on the central computing entity uses Fast Healthcare Interoperability Resources (FHIR) communication protocols. (See Hansen para 66) The mediator module may issue one or more FHIR API calls to access information/data corresponding to a patient/member and/or to provide a notification to a provider computing entity.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have further modified the methods of verifying payment coverage for recipients of a service provider of Velaga with the use of iterating use of APIs and submitting verification requests to determine coverage for a recipient as taught by Zahora and the issuance of one or more calls to one or more APIs exposed by the EMR or payor systems in order to more quickly provide verification processes.
Regarding Claims 6, 14, and 19, these substantially similar claims recite the limitations of Claims 1, 9 and 15 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Velaga in view of Zahora and Hansen discloses the following:
convert a format of information included in the received verification request into a standardized format using one or more data model standards;
convert, for a first iteration, information used to verify payment coverage from the standardized format to a first format based on a first API for a first payor; and
convert, for a second iteration, information used to verify payment coverage from the standardized format to a second format based on a second API for a second payor.
In addition to the rejections above as if set forth herein in full, Hansen further discloses that the various EMR and/or practice management systems may generate and provide eligibility requests having a variety of formats and the mediator module may be configured and/or programmed to convert and/or translate the eligibility request into a standardized eligibility inquiry format. (See Hansen paras 91-93 – can be for each payer)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have further modified the methods of verifying payment coverage for recipients of a service provider of Velaga with the use of iterating use of APIs and submitting verification requests to determine coverage for a recipient as taught by Zahora and the issuance of one or more calls to one or more APIs exposed by the EMR or payor systems in order to more quickly provide verification processes.
Regarding Claim 7, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Velaga in view of Zahora and Hansen discloses the following:
wherein:
the request to verify the payment coverage for the recipient is a batch request to verify payment coverage for a plurality of recipients; and
the instructions, when executed by the one or more processors, further configure the computing system to iterate over the plurality of recipients indicated in the batch request to respectively verify payment coverage for the plurality of recipients.
Velaga discloses her invention as to a system to verify documentation in real-time. (See Velaga para 59) The system includes a computing device, a verification system, and a repository/database. (See Velaga para 60) The computing device may be a computer, a laptop computer, a smartphone, and/or a tablet, among other examples. (See Velaga para 60) The computing device includes at least a processor, a memory, a graphical user interface (GUI) and a provider application where the provider application may be an engine, software program, service, or a software platform configured to be executable on the computing device. (See Velaga para 60) The database may include a third-party insurer database and/or a healthcare provider database. (See Velaga para 60)
The verification system may include numerous applications, components, and/or engines that are configured to receive and validate or verify information from documentation in real-time. (See Velaga para 61) The verification system includes a validation mechanism, an optical character recognition (OCR) mechanism, storage, and/or an image processing mechanism, among others. (See Velaga para 61)
Velaga also notes that API consumers (e.g., healthcare providers) may utilize the application gateway to utilize the serverless environment which may include numerous modules or engines, such as storage engine, an API management engine, a functions engine, a queue engine and/or a web jobs engine, among others. (See Velaga para 112) The serverless environment may also include a cosmos database and/or a cache. (See Velaga para 113) The SQL database and/or payers (e.g., insurance providers) may interact with one or more engines of the serverless environment. (See Velaga para 113)
While Velaga discloses verifying payment coverage for recipients of a service provider, constructing verification requests and discloses requests to verify payment coverage being submitted and receiving responses to those verification requests and notes that healthcare providers may use the application gateway to verify coverage, Velaga does not fully disclose a plurality of API specifications exposed by payor computing systems, iterating over the plurality of API specifications or additional details of constructing and submitting the verification requests based on the retrieved API specification or if there is no indication of verification of coverage for a recipient or that the request are batch requests.
Zahora discloses systems and methods for calculating medical claims payment estimates that may receive a medical claim for a first patient including billing code(s) and demographic data, apply the demographic data to identify payer(s) for the first patient, access a data universe including patient data collection(s) of patient data records for a second group of patients, payer data collection(s) of data records for payers, and a financial history data collection include financial data records(s) for the first patient, identify for each billing code, a payer payment pattern based on a combination of patient data records and payer data record(s) corresponding to the payer for the first patient, identify a patient payment pattern based on the financial data record(s) and apply the payer payment pattern and the patient payment pattern to the medical claim for the first patient to calculate a payment estimation for the medical claim. (See Zahora Abstract)
In particular, Zahora discloses that the predictive analytics platform may receive all or a portion of input through an application programming interface (API) accessed by and/or batch files provided by the source of the input data (e.g., provider or billing service for the provider). (See Zahora para 97 – API specification; batch requests)
In some embodiments, accessing includes accessing a set of records maintained by or provided by a third party, such as patient financial data and/or payer data. (See Zahora para 103) The payer data, in some implementations includes coverage details for insurance plans for each of a collection of payers and may include health insurance payers, medical insurance payers, dental insurance payers, vision insurance payers, and/or indemnity insurance payers. (See Zahora para 103 – payer data for a collection of payers)
In some implementations, the predictive analytics platform includes a coverage verification engine configured to automatically submit patient information to a payer system to confirm active coverage of the patient by the payer. (See Zahora para 122) To verify coverage, in some embodiments, the coverage verification engine automatically submits identifying demographic information through an API or other automated communication means to confirm status of coverage, the goal being to receive a response from at least one payer system confirming active coverage and thus, positively identifying the payer as a potential medical claim recipient for the service. (See Zahora para 122 – API specifications to confirm coverage)
In some implementations, the predictive analytics platform includes a payer pre-approval request engine for automatically submitting a pre-authorization request in relation to a scheduled service or recommended product. (See Zahora para 131) The payer pre-approval request engine, for example, may receive indication of a payer, a billing code, and a patient, for example, a payer identifier and a patient identifier. (See Zahora para 131) The payer pre-approval request engine may prepare a pre-authorization request based on this information, and, using the payer identification, determine automated contact information, such as an API, for submitting the pre-approval request. (See Zahora para 131)
The payer pre-approval request engine may also receive indication of a requestor such that, after receiving a response from the payer system, the payer pre-approval request engine may automatically alert the requestor of the outcome of the request (e.g., approved, denied). (See Zahora para 131 – indication of coverage for the recipient or coverage could not be verified) In various implementations, the platform may automatically issue a request for authorization from the payer, may automatically notify a third party to request authorization from the payer, or provide a notice to the user of the platform that the prior authorization is required. (See Zahora para 131)
In some implementations, the predictive analytics platform includes a liability applicability analysis engine configured to analyze information related to a medical claim to identify whether liability insurance is likely to apply. (See Zahora para 132) In some embodiments, the applicability analysis engine, performs natural language processing (NLP) portion of the claims data, service request data, and/or service provider data to identify terms and/or phrases indicative of a claim qualifying for liability coverage. (See Zahora para 132)
The predictive analytics platform, in some implementations, includes a patient information updating engine for expanding upon patient demographic data that may be insufficient for uniquely identifying the patient and/or that contains ambiguous or contradictory information on comparison to another trustworthy source of patient information. (See Zahora para 133) The patient information updating engine, for example, may receive patient information obtained from an intake process, such as a manual data entry process by service provider personnel into the predictive analytics platform or electronic chart data automatically transferred into the predictive analytics platform by one of the service providers. (See Zahora para 133 – provided by the service providers)
In some embodiments, the patient information updating engine analyzes the patient information in view of identification criteria to determine whether the supplied information is sufficient for positive identification of the patient. (See Zahora para 133) For example, a relatively common name and a significant geographic region (e.g., Paul Jacobs of New York) may be insufficient for positive identification of an individual, while a full name plus social security number may be adequate. (See Zahora para 133)
The rules in determining sufficient information, for example, may analyze the patient information in view of the key demographic information identified in the rules as being sufficient for matching purposes has been supplied. (See Zahora para 133) The predictive analytics platform, in some implementations, includes a payment trends analysis engine configured to analyze remittance received from payers and/or patients to identify patterns within the payments. (See Zahora para 135) Further, the patterns may be broken down into subsets, such as billing code categories, payer types (e.g., liability, primary insurance, federal medical coverage programs, etc.) and/or locations (e.g., for a service provider with multiple physical locations). (See Zahora para 135) In some embodiments, the payment trends analysis engine applies machine learning analysis, cluster analysis, and/or statistical data analysis to the remittance data to identify data patterns within the accessed records. (See Zahora para 135) For example, the payment trends analysis engine may include different machine learning classifiers trained to identify patterns related to the various sets and subsets of payment types. (See Zahora para 135, 137)
Further, in some implementations, the predictive analytics platform includes a coverage coordination analysis engine for coordinating benefits coverage between multiple payers available to the patient where the coverage coordination analysis engine, for example, may coordinate benefits based on a legal or administrative hierarchy, such as coordination of benefits (COB) responsibilities and may apply rules to determine an order of benefits application where the coverage coordination analysis engine, based upon the rules, in some embodiments, provides a percentage of each service covered by each of the available payers, an estimated amount to invoice to each of the available payers. and/or a hierarchical order in which to approach the available payers for reimbursement. (See Zahora para 140)
Zahora also discloses example methods and submethods for calculating a combined payment estimate by applying historical patient payment patterns and historical payer payment patterns. (See Zahora para 141)
In some implementations, the method begins with obtaining patient information and service information and if no payer has been identified within the incoming information, known information is used to search for one or more payers within the payer records. (See Zahora paras 142-143) For example, the patient information may be applied to looking up patient records maintained by the service provider to identify previously applied coverage. (See Zahora para 143) If a payer is not found within the patient information or the medical provider system, in some implementations, a payer identification process is conducted to identify one or more payers providing active coverage to the patient. (See Zahora para 144)
In some implementations, for each of the most likely payers, patient status is confirmed through connecting with the payer system where the coverage verification engine may perform confirmations for each of the most likely payers. (See Zahora para 148) If active coverage is confirmed for a payer, in some implementations, patient record information requested from the payer, for example, the coverage verification engine requests patient record information from the payer or receives patient record information automatically with the affirmative response from the payer system. (See Zahora para 149) In some implementations, while additional payer candidates have not yet been confirmed, the operations 336 to 342 are repeated. (See Zahora para 151 – iterated)
In some implementations, if no payer has been located, a lack of insurance status is returned. (See Zahora para 152 – no indication of verification of coverage for a recipient) If multiple payers are available, in some implementations, the payers are ranked in an order of preference which may be based at least in part on the service information and/or the coordination of benefits rules discussed above. (See Zahora para 153)
In some implementations, a submethod for determining authorization status of a patient based on active payer coverage is disclosed. (See Zahora para 182) In some implementations, the authorization status is returned, the authorization status may be returned to the method. (See Zahora para 186 – iterative process) If instead, coverage is not active, in some implementations, one or more payers is identified and if a payer is identified, the method proceeds with issuing a request to the payer system to determine authorization status of the services and returning authorization status; however, if no payer is identified, in some implementations, a status of a patient lacking payer coverage is returned and the status may be returned to the method. (See Zahora paras 186-189, 207-208 – iterative querying)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the methods of verifying payment coverage for recipients of a service provider of Velaga with the use of iterating use of APIs and submitting verification requests to determine coverage for a recipient as taught by Zahora in order to streamline verification processes.
While Velaga in view of Zahora discloses the invention as noted above, they do not squarely disclose that one or more APIs may be exposed by the payor systems.
Hansen discloses a central computing entity receives an encrypted request for performance of a back-end function, the encrypted request associated with a provider and a corresponding practice management system; generates a trigger indication that comprises patient identifying information based on the encrypted request processes the trigger indication using a program code module corresponding to the back-end function and operating on the central computing entity to generate a response; converts the response into a notification in a format corresponding to the practice management system; and encrypts and providers the notification such that a user computing entity receives the notification. (See Hansen Abstract)
In particular, the central computing entity (e.g., mediator module operating on the central computing entity) may issue one or more API calls to one or more APIs exposed by the EMR and/or practice management system and/or access information/data stored in memory media. (See Hansen para 66) In various embodiments, the communications between user computing entities (e.g., provider computing entities and/or patient/member computing entities and/or EMR and/or practice management systems operating thereon and a central computing entity mediator module, eligibility module, care estimate module, and/or the like operating on the central computing entity uses Fast Healthcare Interoperability Resources (FHIR) communication protocols. (See Hansen para 66) The mediator module may issue one or more FHIR API calls to access information/data corresponding to a patient/member and/or to provide a notification to a provider computing entity.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have further modified the methods of verifying payment coverage for recipients of a service provider of Velaga with the use of iterating use of APIs and submitting verification requests to determine coverage for a recipient as taught by Zahora and the issuance of one or more calls to one or more APIs exposed by the EMR or payor systems in order to more quickly provide verification processes.
Regarding Claim 8, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Further, Velaga in view of Zahora and Hansen discloses the following:
wherein the instructions, when executed by the one or more processors, further configure the computing system to convert a format of information included in the received verification response into a standardized format using a standardized response data model.
In addition to the rejections above as if set forth herein in full, Hansen further discloses that the various EMR and/or practice management systems may generate and provide eligibility requests having a variety of formats and the mediator module may be configured and/or programmed to convert and/or translate the eligibility request into a standardized eligibility inquiry format. (See Hansen paras 91-93)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have further modified the methods of verifying payment coverage for recipients of a service provider of Velaga with the use of iterating use of APIs and submitting verification requests to determine coverage for a recipient as taught by Zahora and the issuance of one or more calls to one or more APIs exposed by the EMR or payor systems in order to more quickly provide verification processes.
Regarding Claims 10 and 16, these substantially similar claims recite the limitations of Claims 9 and 15 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Velaga discloses the following:
training an image classification model to indicate an identity of a payor, of a plurality of payors, associated with an insurance card image input into the image classification model at least by providing, to the image classification model, a plurality of first insurance card images, wherein each first insurance card image is labeled with an indication of an identity of a payor of the plurality of payors; (See Velaga paras 63-64, 68-74, 76-78, 91-94, 106-108, Fig. 2 – extract patient identifier; recognize health insurance document; relate to third-party insurer or healthcare provider database; engage in image classification via an AI or machine learning layer; capture a user image of a healthcare insurance card)
training a plurality of image segmentation models to segment an insurance card image into a plurality of segments that each indicate respective information used to verify payment coverage at least by providing, to each image segmentation model, a plurality of second insurance card images, wherein each second insurance card image is labeled with at least one indication of a type of information used to verify payment insurance coverage depicted in a segment of the second insurance card image; (See Velaga paras 68-76, 91-94, 106-108, Fig. 2 – image segmentation)
receiving, from the service provider system of the service provider, an insurance card image associated with the recipient; (See Velaga paras 106-108, Fig. 2)
identifying, by providing the received insurance card image to the trained image classification model, a payor indicated by the received insurance card image; (See Velaga paras 68-76, 91-94, 106-113, Fig. 2)
segmenting, by providing the received insurance card image to an image segmentation model associated with the identifier payor, the received insurance card image into a plurality of segments; (See Velaga paras 91-94, 106-113, Fig. 2)
obtaining, from the one or more segments of the plurality of segments using optical character recognition, information used to verify payment coverage for the recipient; and (See Velaga paras 68-76, 91-94, 106-113, Fig. 2)
constructing the verification request further based on the information obtained from the one or more segments. (See Velaga paras 68-80, 84-86, 91-94, 106-113, Fig. 2)
Regarding Claim 17, this claim recites the limitations of Claim 15 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Velaga in view of Zahora and Hansen discloses the following:
wherein the instructions, when executed by the one or more processors, further cause the computing system to iterate over the plurality of API specifications is based on one of:
insured population size wherein a first iteration for a first payor determined to have a first insured population size is performed before a second iteration for a second payor determined to have a second insured population size that is smaller than the first insured population size; or
a geographic location of the recipient wherein a first iteration for a first payor that is located in the same geographic location as the recipient is performed before a second iteration for a second payor that is not located in the same geographic location as the recipient.
Velaga discloses her invention as to a system to verify documentation in real-time. (See Velaga para 59) The system includes a computing device, a verification system, and a repository/database. (See Velaga para 60) The computing device may be a computer, a laptop computer, a smartphone, and/or a tablet, among other examples. (See Velaga para 60) The computing device includes at least a processor, a memory, a graphical user interface (GUI) and a provider application where the provider application may be an engine, software program, service, or a software platform configured to be executable on the computing device. (See Velaga para 60) The database may include a third-party insurer database and/or a healthcare provider database. (See Velaga para 60)
The verification system may include numerous applications, components, and/or engines that are configured to receive and validate or verify information from documentation in real-time. (See Velaga para 61) The verification system includes a validation mechanism, an optical character recognition (OCR) mechanism, storage, and/or an image processing mechanism, among others. (See Velaga para 61)
Velaga also notes that API consumers (e.g., healthcare providers) may utilize the application gateway to utilize the serverless environment which may include numerous modules or engines, such as storage engine, an API management engine, a functions engine, a queue engine and/or a web jobs engine, among others. (See Velaga para 112) The serverless environment may also include a cosmos database and/or a cache. (See Velaga para 113) The SQL database and/or payers (e.g., insurance providers) may interact with one or more engines of the serverless environment. (See Velaga para 113)
While Velaga discloses verifying payment coverage for recipients of a service provider, constructing verification requests and discloses requests to verify payment coverage being submitted and receiving responses to those verification requests and notes that healthcare providers may use the application gateway to verify coverage, Velaga does not fully disclose a plurality of API specifications exposed by payor computing systems, iterating over the plurality of API specifications or additional details of constructing and submitting the verification requests based on the retrieved API specification or if there is no indication of verification of coverage for a recipient or iterating based on population size or geographic size.
Zahora discloses systems and methods for calculating medical claims payment estimates that may receive a medical claim for a first patient including billing code(s) and demographic data, apply the demographic data to identify payer(s) for the first patient, access a data universe including patient data collection(s) of patient data records for a second group of patients, payer data collection(s) of data records for payers, and a financial history data collection include financial data records(s) for the first patient, identify for each billing code, a payer payment pattern based on a combination of patient data records and payer data record(s) corresponding to the payer for the first patient, identify a patient payment pattern based on the financial data record(s) and apply the payer payment pattern and the patient payment pattern to the medical claim for the first patient to calculate a payment estimation for the medical claim. (See Zahora Abstract)
In particular, Zahora discloses that the predictive analytics platform may receive all or a portion of input through an application programming interface (API) accessed by and/or batch files provided by the source of the input data (e.g., provider or billing service for the provider). (See Zahora para 97 – API specification)
In some embodiments, accessing includes accessing a set of records maintained by or provided by a third party, such as patient financial data and/or payer data. (See Zahora para 103) The payer data, in some implementations includes coverage details for insurance plans for each of a collection of payers and may include health insurance payers, medical insurance payers, dental insurance payers, vision insurance payers, and/or indemnity insurance payers. (See Zahora para 103 – payer data for a collection of payers)
In some implementations, the predictive analytics platform includes a coverage verification engine configured to automatically submit patient information to a payer system to confirm active coverage of the patient by the payer. (See Zahora para 122) To verify coverage, in some embodiments, the coverage verification engine automatically submits identifying demographic information through an API or other automated communication means to confirm status of coverage, the goal being to receive a response from at least one payer system confirming active coverage and thus, positively identifying the payer as a potential medical claim recipient for the service. (See Zahora para 122 – API specifications to confirm coverage)
In some implementations, the predictive analytics platform includes a payer pre-approval request engine for automatically submitting a pre-authorization request in relation to a scheduled service or recommended product. (See Zahora para 131) The payer pre-approval request engine, for example, may receive indication of a payer, a billing code, and a patient, for example, a payer identifier and a patient identifier. (See Zahora para 131) The payer pre-approval request engine may prepare a pre-authorization request based on this information, and, using the payer identification, determine automated contact information, such as an API, for submitting the pre-approval request. (See Zahora para 131)
The payer pre-approval request engine may also receive indication of a requestor such that, after receiving a response from the payer system, the payer pre-approval request engine may automatically alert the requestor of the outcome of the request (e.g., approved, denied). (See Zahora para 131 – indication of coverage for the recipient or coverage could not be verified) In various implementations, the platform may automatically issue a request for authorization from the payer, may automatically notify a third party to request authorization from the payer, or provide a notice to the user of the platform that the prior authorization is required. (See Zahora para 131)
In some implementations, the predictive analytics platform includes a liability applicability analysis engine configured to analyze information related to a medical claim to identify whether liability insurance is likely to apply. (See Zahora para 132) In some embodiments, the applicability analysis engine, performs natural language processing (NLP) portion of the claims data, service request data, and/or service provider data to identify terms and/or phrases indicative of a claim qualifying for liability coverage. (See Zahora para 132)
The predictive analytics platform, in some implementations, includes a patient information updating engine for expanding upon patient demographic data that may be insufficient for uniquely identifying the patient and/or that contains ambiguous or contradictory information on comparison to another trustworthy source of patient information. (See Zahora para 133) The patient information updating engine, for example, may receive patient information obtained from an intake process, such as a manual data entry process by service provider personnel into the predictive analytics platform or electronic chart data automatically transferred into the predictive analytics platform by one of the service providers. (See Zahora para 133 – provided by the service providers)
In some embodiments, the patient information updating engine analyzes the patient information in view of identification criteria to determine whether the supplied information is sufficient for positive identification of the patient. (See Zahora para 133 – population size) For example, a relatively common name and a significant geographic region (e.g., Paul Jacobs of New York) may be insufficient for positive identification of an individual, while a full name plus social security number may be adequate. (See Zahora para 133 – smaller population size; geographic size)
The rules in determining sufficient information, for example, may analyze the patient information in view of the key demographic information identified in the rules as being sufficient for matching purposes has been supplied. (See Zahora para 133) The predictive analytics platform, in some implementations, includes a payment trends analysis engine configured to analyze remittance received from payers and/or patients to identify patterns within the payments. (See Zahora para 135) Further, the patterns may be broken down into subsets, such as billing code categories, payer types (e.g., liability, primary insurance, federal medical coverage programs, etc.) and/or locations (e.g., for a service provider with multiple physical locations). (See Zahora para 135) In some embodiments, the payment trends analysis engine applies machine learning analysis, cluster analysis, and/or statistical data analysis to the remittance data to identify data patterns within the accessed records. (See Zahora para 135) For example, the payment trends analysis engine may include different machine learning classifiers trained to identify patterns related to the various sets and subsets of payment types. (See Zahora para 135, 137)
Further, in some implementations, the predictive analytics platform includes a coverage coordination analysis engine for coordinating benefits coverage between multiple payers available to the patient where the coverage coordination analysis engine, for example, may coordinate benefits based on a legal or administrative hierarchy, such as coordination of benefits (COB) responsibilities and may apply rules to determine an order of benefits application where the coverage coordination analysis engine, based upon the rules, in some embodiments, provides a percentage of each service covered by each of the available payers, an estimated amount to invoice to each of the available payers. and/or a hierarchical order in which to approach the available payers for reimbursement. (See Zahora para 140)
Zahora also discloses example methods and submethods for calculating a combined payment estimate by applying historical patient payment patterns and historical payer payment patterns. (See Zahora para 141)
In some implementations, the method begins with obtaining patient information and service information and if no payer has been identified within the incoming information, known information is used to search for one or more payers within the payer records. (See Zahora paras 142-143) For example, the patient information may be applied to looking up patient records maintained by the service provider to identify previously applied coverage. (See Zahora para 143) If a payer is not found within the patient information or the medical provider system, in some implementations, a payer identification process is conducted to identify one or more payers providing active coverage to the patient. (See Zahora para 144)
In some implementations, for each of the most likely payers, patient status is confirmed through connecting with the payer system where the coverage verification engine may perform confirmations for each of the most likely payers. (See Zahora para 148) If active coverage is confirmed for a payer, in some implementations, patient record information requested from the payer, for example, the coverage verification engine requests patient record information from the payer or receives patient record information automatically with the affirmative response from the payer system. (See Zahora para 149) In some implementations, while additional payer candidates have not yet been confirmed, the operations 336 to 342 are repeated. (See Zahora para 151 – iterated)
In some implementations, if no payer has been located, a lack of insurance status is returned. (See Zahora para 152 – no indication of verification of coverage for a recipient) If multiple payers are available, in some implementations, the payers are ranked in an order of preference which may be based at least in part on the service information and/or the coordination of benefits rules discussed above. (See Zahora para 153)
In some implementations, a submethod for determining authorization status of a patient based on active payer coverage is disclosed. (See Zahora para 182) In some implementations, the authorization status is returned, the authorization status may be returned to the method. (See Zahora para 186 – iterative process) If instead, coverage is not active, in some implementations, one or more payers is identified and if a payer is identified, the method proceeds with issuing a request to the payer system to determine authorization status of the services and returning authorization status; however, if no payer is identified, in some implementations, a status of a patient lacking payer coverage is returned and the status may be returned to the method. (See Zahora paras 186-189, 207-208 – iterative querying)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the methods of verifying payment coverage for recipients of a service provider of Velaga with the use of iterating use of APIs and submitting verification requests to determine coverage for a recipient as taught by Zahora in order to streamline verification processes.
While Velaga in view of Zahora discloses the invention as noted above, they do not squarely disclose that one or more APIs may be exposed by the payor systems.
Hansen discloses a central computing entity receives an encrypted request for performance of a back-end function, the encrypted request associated with a provider and a corresponding practice management system; generates a trigger indication that comprises patient identifying information based on the encrypted request processes the trigger indication using a program code module corresponding to the back-end function and operating on the central computing entity to generate a response; converts the response into a notification in a format corresponding to the practice management system; and encrypts and providers the notification such that a user computing entity receives the notification. (See Hansen Abstract)
In particular, the central computing entity (e.g., mediator module operating on the central computing entity) may issue one or more API calls to one or more APIs exposed by the EMR and/or practice management system and/or access information/data stored in memory media. (See Hansen para 66) In various embodiments, the communications between user computing entities (e.g., provider computing entities and/or patient/member computing entities and/or EMR and/or practice management systems operating thereon and a central computing entity mediator module, eligibility module, care estimate module, and/or the like operating on the central computing entity uses Fast Healthcare Interoperability Resources (FHIR) communication protocols. (See Hansen para 66) The mediator module may issue one or more FHIR API calls to access information/data corresponding to a patient/member and/or to provide a notification to a provider computing entity.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have further modified the methods of verifying payment coverage for recipients of a service provider of Velaga with the use of iterating use of APIs and submitting verification requests to determine coverage for a recipient as taught by Zahora and the issuance of one or more calls to one or more APIs exposed by the EMR or payor systems in order to more quickly provide verification processes.
Regarding Claim 20, this claim recites the limitations of Claim 15 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Velaga discloses the following:
wherein: the request to verify payment coverage is a request to verify insurance coverage by an insurance provider; and the insurance provider is one of a medical insurance provider, an automobile insurance provider, or a home insurance provider. (See Velaga paras 95, 109-115)
Additional Relevant Prior Art of Record Not Currently Being Applied
Hallemeier et al. (US PG Pub. 2021/0391045) (“Hallemeier”) – discloses systems, methods and devices for providing healthcare coverage matching and verification. (See Hallemeier Abstract) In some aspects, the method includes receiving, from a frontend GUI a healthcare coverage application comprising client demographics that include at least two of the following: a last name, a first name, a birthdate, an identification number, an address and a request type associated with a client, using a parallel matching and verification architecture to determine, based on a first set of criteria, a matching database record from an eligibility database that corresponds to the healthcare coverage application, and communicate with a healthcare provider using electronic data interchange transactions, identify based on a second set of criteria, a medical policy that corresponds to the matching database record and verify the medical policy, and transmitting, to the frontend GUI, the medical policy to allow reception of the medical policy by the client. (See Hallemeier Abstract)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMBREEN A. ALLADIN whose telephone number is (571)270-3533. The examiner can normally be reached Monday - Friday 9-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abhishek Vyas can be reached at 571-270-1836. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AMBREEN A. ALLADIN/Primary Examiner, Art Unit 3691 June 27, 2026
Prosecution Insights