PROCESS AND SYSTEM FOR THE MANAGEMENT, STORAGE AND AUTOMATION OF HEALTH CARE INFORMATION AND APPLICATION PROGRAM INTERFACE THEREFOR
A process for generating a response message to an eligibility verification request transmitted over a healthcare claims network having at least one health care protocol of communication comprises the steps of: executing business rules on a rules engine for a program sponsor on information in the eligibility verification request to determine an individual's eligibility for benefits; generating a protocol-compliant response message including information not specified in the health care protocol of communication; and providing the protocol-compliant response message to the claims network; wherein the at least one health care protocol of communication comprises the NCPDP Telecommunication Standard.
This application claims priority to, and the benefit of, U.S. Provisional Patent Application No. 63/208,861, filed Jun. 9, 2021, the entirety of which is incorporated by reference.
FIELD OF TECHNOLOGYThe field of invention relates to information messaging concerning adjudication of health benefit claims, such as prescription pharmacy claims, and other messaging in support of healthcare services.
BACKGROUNDRemuneration for pharmaceutical goods in the United States can be broken into three very broad groups: insurance (both private and public), third-party copay assistance programs, and cash. As a result, individuals use multiple resources to help pay for their healthcare services including paying for prescribed medications at pharmacies and hospitals, and pharmacies need to be able to accommodate these multiple resources and payors. For example, individuals may have employer-sponsored primary coverage with one set of prescription medication benefits, secondary coverage, for certain benefits, or a combination of primary and secondary insurances. In other examples, individuals may have primary and secondary coverage in federally sponsored programs, such as Medicare and Medicaid.
Primary coverage, or primary insurance, is insurance coverage that pays out before any other benefits are applied, regardless of whether there are other insurance policies covering the same condition. Secondary coverage, or secondary insurance, pays some or all of the costs left after the primary insurance has paid (e.g. deductibles, copayments, coinsurances). For example, primary coverage may reimburse only a portion of the cost of a medication prescribed to treat a medical condition such as cancer, and secondary coverage may be available to pay additional amounts after primary insurance coverage is applied.
In addition to primary or secondary insurance coverage, there are various health care services offered by insurance providers and non-insurance entities, such as pharmaceutical manufacturers. These services often go beyond simply paying for the cost of the prescribed medication, and could include, for example, patient support services designed to assist the patient in taking their medication, prior authorization services designed to assist the patient, prescriber in working with the insurance provider to obtain permission for prescription coverage, or care management programs designed to help treat the underlying condition for which the prescription medication has been prescribed. Where these services and programs exist, they are non-interoperable to the prescription claim for insurance benefits that is adjudicated by the pharmacist at the pharmacy counter.
When a pharmacy adjudicates a claim for insurance benefits at the point of care, the pharmacy's prescription dispensing software interfaces with a tool created by the National Council for Prescription Drug Programs (NCPDP®). NCPDP was founded in 1977 to create standards used to allow pharmacy prescription dispensing software to communicate with insurers and other third party payors of prescription drugs. represent NCPDP is referenced in the Health Insurance Portability and Accountability Act (HIPAA) and the Medicare Prescription Drug, Improvement, and Modernization Act as a key player in the field of claims adjudication. NCPDP has created standards such as the Telecommunication Standard and Batch Standard, the SCRIPT Standard for Electronic Prescribing, and the Manufacturers Rebate Standard. These standards facilitate communication between the pharmacy and the insurer/payor to provide a means for submitting and processing claims for payment.
While the present invention is not limited to a single protocol or standard and describes generally a process, method and system which can be implemented on any software system or protocol, including new protocols to be implemented upon need, the present invention uses the NCPDP Telecommunication Standard, widely in use today to help pharmacies access and use the invention. While the present invention uses this standard, it will be understood that the invention may also be applied to other communications standards and protocols. One of ordinary skill in the art will understand how the below-described embodiments should be read in context of the evolving field in this art.
The NCPDP Telecommunication Standard indicates that the term “Provider” may include entities such as a retail pharmacy, mail order pharmacy, doctor's office, clinic, hospital, long-term care facility, or any other entity, which dispenses prescription drugs and submits those prescriptions electronically under a patient's pharmacy benefit to a Payor for reimbursement. The term “Adjudicator” also known as “Processor” is often a third-party administrator of prescription drug programs on behalf of insurers. The Adjudicator may also be an insurer, a governmental program or any other entity, which receives prescription drug claims, makes a decision regarding the level of reimbursement to the provider, and transmits a response to the provider. The, “Intermediary” is a party that receives a claim from switches or Providers, perform editing/messaging and then either pass the claims to the appropriate switch or adjudicator or return (reject) claims to the Providers. The reply from the Adjudicator may also pass to an Intermediary for editing and messaging on its return to the Provider.
Some Processors may not support “Dial-Up” communication, centralized claims processing, or reliability in communication and may use a “Switch” which receives transactions from Providers and Intermediaries as claims pass from Providers to Adjudicators. Switches accept claims, optionally perform format conversions, may perform pre-editing, and then pass the claims to the appropriate Processor. As part of most protocols of communication, the goal is to structure the data to be sent into a stream which allows for a target and a recipient to talk.
To make a claim for prescription coverage, a Provider enters prescription information into commercially available software on a computer. The prescription information includes the medication being prescribed, the insured person and identifiers and routing information for at least a primary insurer. The software generates a NCPDP-compliant message and transmits it to the claims processing network 10, where Switches route the claim request message to the Payor or an appropriate Adjudicator.
If the claim is not fully paid, the Provider may re-submit the claims to all non-primary claims to the Switch, which routes them to both the Secondary, Tertiary Payors, etc., or associated Adjudicator or Facilitator. The Facilitator may create and send reporting transactions containing Secondary, Tertiary, etc. The Telecommunication Standard, Version D.0 is incorporated by reference, and the above is described in greater detail, for example, at Section 3.2.2
The protocol includes Mandatory (M) segments to a transaction, Situational segments (R, RM, Q, or QM) which are respectively Required, Required for Medicaid Subrogation only, Qualified Requirement or Qualified Requirement for Medicaid Subrogation. Next values of segments can be Informational Only (I), Optional (O), Not Used (N), or finally Repeating (***R***). Generally speaking, while strings of values and code are sent of a fixed type, each field is described as a field (e.g. 503-F3), a field name, a segment description above (M, R, RM, Q, QM, I, O, N, or ***R***) and a “situation” or portion that describes and puts context.
Generally speaking, the Protocol defines: (a) Eligibility Verification, (b) Eligibility Verification Request Segments, (c) Eligibility Verification Response, (d) Transmission Accepted/Transmission Approved, (e) Transmission Accepted/Transmission Rejected/Transmission Rejected/Transaction Rejected. Next the protocol includes (i) Claim billing or Encounter Request, (ii) Claim Billing or Encounter Response as part of Transmission Accepted/Transaction Paid, Transmission Accepted/Transaction Capture, or Transmission Accepted/Transaction Rejected. Finally, there is a final Transmission Rejected/Transaction Rejected claim communication.
The NCPDP Telecommunication Standard Implementation Guide Version D.0 for example describes the different protocol-based communications to travel and be exchanged over the systems as described at
As shown above, two messages (Approved and Rejected) have been noted as point of entry linked with the Eligibility Verification Response (e.g. a message asking if a person is eligible for primary coverage). The Response Status Segment breakdown for an Approved Transaction reads:
The Response Status Segment breakdown for a Rejected Transaction reads:
The protocol also includes a Claim Billing request which also provides a Response Status Segment that is Transaction Accepted/Transaction Paid:
The protocol also includes a Claim Billing request which also provides a Response Status Segment that is Transaction Accepted/Transaction Captured:
The protocol also includes a Claim Billing request which also provides a Response Status Segment that is Transaction Accepted/Transaction Rejected:
As shown above the protocol has similar structure and functions when used in most of the return confirmations. Each time, the Response Message Segment is used in similar ways for Service Billing, Claim Reversal, Service Reversal, Claim Rebill, etc.
As can be appreciated, the process for determining eligibility for benefits in a medication prescribing and dispensing environment is currently widely computerized to facilitate the communication of claim, for coverage, responses to claims for coverage, and provisions of benefits to individuals. However, due in part to the scope of participants, including virtually all prescribers, providers, and insurers, the protocols are rigid and slow to add new features, while information required to issue manufacturer coupons may change rapidly and vary depending on context.
In addition to payment of deductibles, copayments, or coinsurance, in the United States multiple third parties play a role to help make their drugs and services more affordable and more available to users. For example, some drug manufacturers sponsor such payment assistance programs such as “if you cannot afford [drug X], then [manufacturer X] can help.” Pharmaceutical manufacturers may offer coupons for payment assistance for their prescription medicines. As used herein, “coupon” means a coupon, voucher or other type of communication directing the user to a copayment “offset” pertaining to a pharmaceutical benefit or other form of such information. These coupons may be redeemed through the NCPDP protocol as described above by entering, for example, Payor routing information for the coupon. However, the Provider has to obtain approval to apply to coupon and obtain the proper routing information for the coupon claim.
The payment assistance may be optimized when a drug is not sufficiently covered by a primary or secondary insurance so that it is affordable to a patient or when certain other conditions exist. As a consequence, the process and system of placing payment assistance aka ‘coupons’ for certain drugs is highly complex. Each time, a service provider must run complex algorithms to make sure the benefits are appropriate.
For example, Hoffman et al. secured in 2011 U.S. Pat. No. 7,957,983 directed to a new method for using an “administrator” to help manage medication therapy management, adherence to programs, and the implementation of pharmacosurveillance programs. Using a central pivot third party, multiple issues unique with the world of prescription drugs can be managed such as the control of addictive drugs, medicine interference, over-prescriptions, or the use of multiple third-party programs. In the above, this technology attempts to solve problems that are the purview of a Payor and not a user. What is needed is a new system which helps coordinate and manage optimization of costs for a patient and to offer those in the process, such as pharmacists guidance and simplified user interfaces.
Service providers exist to assist with administration of payment assistance programs as described above. However, implementing payment assistance from such manufacturers typically require a Provider log into a web portal or otherwise to manually provide information relating to a given pharmaceutical manufacturer's programs. Due to hundreds, if not thousands, of prescriptions being processed daily, this process can easily overwhelm a Provider such as a pharmacy.
SUMMARYThe present disclosure relates to a new system, and process for the optimization of workflows and computer systems where the generation and transfer of digital information between a plurality of software, stored in a plurality of databases must be coordinated.
In some embodiments, a process for generating a response message to an eligibility verification request transmitted over a healthcare claims network having at least one health care protocol of communication comprises the steps of: executing business rules on a rules engine for a program sponsor on information in the eligibility verification request to determine an individual's eligibility for benefits; generating a protocol-compliant response message including information not specified in the health care protocol of communication; and providing the protocol-compliant response message to the claims network; wherein the at least one health care protocol of communication comprises the NCPDP Telecommunication Standard. The information not specified in the health care protocol of communication may comprise a coupon for pharmaceutical manufacturer benefits in a pre-defined field of the NCPDP Telecommunication Standard. The coupon may comprise at least a member ID personalized number for entry into a subsequent request for payment.
The protocol-compliant eligibility verification request message may be generated on a first software solution and the protocol-compliant response message may be generated by a second software solution. The second software solution further may comprise a remote web portal.
In some embodiments, the information not specified in the health care protocol of communication comprises a tokenized Uniform Resource Locator (URL) in the 526-FQ field of the NCPDP Telecommunication Standard which provides access to the remote web portal. The rules engine may determine that additional information is required to process the eligibility verification request. The web portal may be pre-populated with information from the eligibility verification request from the rules engine, and wherein the tokenized URL includes information to authenticate a recipient of the URL and provide access to the web portal for a limited period of time.
The tokenized URL may provide access to request-specific forms, including ability to pre-fill the forms based on claims data from the eligibility verification request, facilitate the transmission of the forms to stakeholders for review, and track the completion of various forms. The tokenized URL may enable collection and management of legal documents pertaining to a pharmaceutical manufacturer benefit program, place of service, or per-patient prescription transactions. The tokenized URL may enable place of service identity and licensure profiling.
In some examples, the tokenized URL provides access to place of service training related to the eligibility verification request, inclusive of the provision of messaging, digital files, video and audio content pertaining to a payor-sponsored service.
The tokenized URL may also enable intake of data files comprising information not captured via a standard NCPPD eligibility verification request. For example, the tokenized URL may enable guided conveyance of forms for the processing and electronic filing of prior authorization forms by pharmacies for patients in connection with manufacturer-sponsored service programs
The first software solution may comprise a healthcare services Provider's claim processing system, and the method may further comprise the step of displaying at the first software solution to the Provider a response.
In some examples, a benefit program administrator operates the second software solution, and the benefit program administrator receives and parses the protocol compliant eligibility verification request message. For example, the benefit program administrator may be assigned routing information comprising at least one of the group comprising a Bank Identification Number (BIN), a Process Control Number (PCN) and a Primary Group ID; and the protocol-compliant eligibility verification request message includes the assigned routing information and a benefit verification request is routed to the benefit program administrator.
The second software solution may comprise an API, and the method may further comprise the steps of: the API parsing the protocol-compliant eligibility verification request message into a machine-readable object; the business rules engine executing the business rules on the machine readable object; the business rules engine updating the machine-readable object with response information; and the API generating the protocol-compliant response message based on the updated machine-readable object.
The process may further comprising the step of parsing the protocol-compliant eligibility verification request message to extract information relevant to a program sponsor's benefit program, wherein step of parsing the protocol-compliant eligibility verification request message is performed by a program sponsor and the step of executing business rules by is performed by a program administrator.
The process may further comprise the step of receiving the protocol-compliant eligibility verification request message from the claims network. In some examples, the program sponsor is a pharmaceutical manufacturer. In some examples, the program sponsor is an insurer.
In another example, a process for generating a response message to an eligibility verification request transmitted over a healthcare claims network having at least one health care protocol of communication comprises the steps of: executing business rules on a rules engine for a program sponsor on information extracted from the eligibility verification request to determine an individual's eligibility for benefits; populating a web portal with information extracted from the eligibility verification request; and providing a response to the eligibility verification request via the web portal and over a network other than the healthcare claims network; wherein the at least one health care protocol of communication comprises the NCPDP Telecommunication Standard.
The protocol-compliant eligibility verification request message may be generated on a first software solution and the business rules engine and web portal may comprise a second software solution.
The business rules engine may determine that additional information is required to process the eligibility verification request. The web portal is populated with information from the eligibility verification request from the rules engine, and web portal communicates a request for additional information to an individual without using the healthcare claims network.
The first software solution may comprise a healthcare services Provider's claim processing system.
A benefit program administrator may operates the second software solution, and the benefit program administrator may receive and parse the protocol compliant eligibility verification request message. The benefit program administrator may be assigned routing information comprising at least one of the group comprising a Bank Identification Number (BIN), a Process Control Number (PCN) and a Primary Group ID; and the protocol-compliant eligibility verification request message includes the assigned routing information.
The second software solution may comprise an API, and the method further comprises the steps of: the API parsing the protocol-compliant eligibility verification request message into a machine-readable object; the business rules engine executing the business rules on the machine readable object; the business rules engine updating the machine-readable object with response information; and the business rules engine populating the web portal with information based on the updated machine-readable object.
The response may be received on a mobile device, and the mobile device may be associated with a person selected from the group consisting of a prescribing physician, a pharmacist, and a patient.
The drawings described herein are for illustrative purposes only of selected embodiments and not all possible implementations, and are not intended to limit the scope of the present disclosure.
Corresponding reference numerals indicate corresponding parts throughout the several views of the drawings.
DETAILED DESCRIPTIONNumerous specific details are set forth such as examples of specific components, devices, and methods, to provide a thorough understanding of embodiments of the present disclosure. However, the invention is not limited to any specific embodiment except as recited in the claims. It will be apparent to those skilled in the art that specific details need not be employed, that example embodiments may be embodied in many different forms and that neither should be construed to limit the scope of the disclosure. In some example embodiments, well-known processes, well-known device structures, and well-known technologies are not described in detail.
The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms “a,” “an,” and “the” may be intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms “comprises,” “comprising,” “including,” and “having,” are inclusive and therefore specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is also to be understood that additional or alternative steps may be employed.
When an element or layer is referred to as being “on,” “engaged to,” “connected to,” or “coupled to” another element or layer, it may be directly on, engaged, connected or coupled to the other element or layer, or intervening elements or layers may be present. In contrast, when an element is referred to as being “directly on,” “directly engaged to,” “directly connected to,” or “directly coupled to” another element or layer, there may be no intervening elements or layers present. Other words used to describe the relationship between elements should be interpreted in a like fashion (e.g., “between” versus “directly between,” “adjacent” versus “directly adjacent,” etc.). As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.
Although the terms first, second, third, etc. may be used herein to describe various elements, components, regions, layers and/or sections, these elements, components, regions, layers and/or sections should not be limited by these terms. These terms may be only used to distinguish one element, component, region, layer or section from another region, layer or section. Terms such as “first,” “second,” and other numerical terms when used herein do not imply a sequence or order unless clearly indicated by the context. Thus, a first element, component, region, layer or section discussed below could be termed a second element, component, region, layer or section without departing from the teachings of the example embodiments.
The connection will be done, for example, over the network 51 such as the Internet, a LAN either cloud-based or other related technologies. As shown, several computers 50, and 53 (and also 58), are designed with a processor 54 for calculating and running software, a memory 55 connected to the processor 54 for use of a display 56 over some type of interface 57. A server 50 is configured with a software platform 52. Platform 52 is capable of operating centrally or in a cloud as a software as a service (SaaS) application. Also, not shown is the process of uploading from a server, either locally or remotely the software for installation locally and for operation with a website or software located on the server 50 for the processing of data. Most systems are now designed for use by thousands of users and the database is either localized in the memory or used in a centralized platform 52 in one remote computer or cloud-based memory for operation.
The structure of computer network arrangement 1 is provided as one example but, as one of ordinary skill will understand, these systems are highly modular and differ from one location to the next and various configurations may be used to implement the invention. Pharmacists or other users will be able to access the system 1 using an iPad or from a remote location while still connected with their own computer 50 for operating this invention. Also, portable, compact and discrete solutions of hardware are being implemented that will not alter the fundamental way the invention operates. For example, the current solution can operate in tandem with automated display dispensers, live pharmacists on automated remote systems, and integrate with other healthcare delivery systems.
Moving to
What is described generally is the use of multiple layers of software, such a basic operating system (e.g. 10S, Windows, etc.) designed to serve as base on which a Software Interface 70 or HTML Browser 60 can be operated. Once again, while the illustration of
Turning to
Shown as 100 is the representation of the different actors according to one embodiment which play roles of the hardware of
Another possible Provider is shown as 113 as a pharmacy also with a computing device 114 also equally connected 112 to the network 51. In the case of the pharmacy 113, it could be in reception of an order from the hospital 102 over the system under the protocol. Doctors could issue scripts or prescriptions and enter them into the system 100. Illustrated is a patient or consumer 116 who is in need of medication 117. This consumer is the one who has an identity, a medical history, a prescription to be filled and has a unique insurance and Payor (Adjudicator/Processor) set as described in
Also illustrated is one of a numerous number of Payors, for example, insurance 110a which has a computing device 109 for connected 111 to the network as part of the system. Shown as 110b is a secondary coverage promise, rebate, insurance contract. While in some case these secondary Payors are Insurers themselves, they also can be a prescription drug manufacturer which sponsor programs to reimburse one drug under precise conditions such as a co-pay promise.
The present invention is not limited to examples where the primary Payor is an insurer. For example, in some embodiments the present invention is employed when the primary Payor is a prescription drug manufacturer for direct access to a drug reimbursement program. In other embodiments, the present invention is employed when the primary Payor is a service that provides provide drug coupons for discounts on medications, such as GoodRx, Inc. and the patient pays with cash or credit.
Shown as 104 and 106 are two computers each having a different software solution 105 and 107 running in the system. Each is connected to the network 103, 108. As described herein, to help understand how two solutions can co-exist on different or similar computers, computing devices 104, 106 are illustrated as two standalone systems. One of ordinary skill in the art will recognize that the computers of the Provider 101, 114 such as a hospital or a pharmacy are designed to have one or both of these applications A, B (e.g. Software A, Software B), locally or remotely via a portal as described at
In some embodiments, Software A at 105 is optimized for generating NCPDP-compliant claims requests and receiving and processing NCPDP-compliant response messages. Software A at 105 is operatively connected to network 51 and communicates with Adjudicators and/or Payors 110a. In this configuration, the Provider must open Software A 105, run a request for primary coverage and reimbursement (e.g. 50%) from a source such as 110a. Software A generates a NCPDP compliant claim request message identifying a primary insurance Payor, including routing information such as one or more of BIN, PCN and Group ID. Optionally, secondary insurance Payor routing information may also be included in the request.
As set forth above, one or more switches, intermediaries, or facilitators will route the NCPDP compliant request for verification of benefits to the Adjudicator (Processor) associated with the primary insurer. Again, as set forth above, the Adjudicator will respond with another NCPDP-compliant message confirming or denying eligibility for the claimed benefits. For example, the response may include a full payment, a partial payment, or a denial of payment for a prescribed drug.
If the claim is not fully covered by primary insurance, the Provider may seek additional claim coverage from secondary insurers in the same way.
If insurance payors do not provide sufficient coverage for a prescription, additional payment assistance may be sought from pharmaceutical manufacturers. Manufacturer's payment assistance programs may have eligibility requirements that are not supported by NCPDP messaging protocols. In such cases, Software B may be provided to administer the payment assistance programs sponsored by a Program Sponsor. Software B may be hosted and/or made available to Providers by a Program Administrator. A Program Administrator may administer payment assistance programs for multiple Payors of other entities, such as pharmaceutical manufactures or other providers of prescription medications. It should be noted, however, that a Program Administrator is typically not an actual Payor, and for such Program Administrators, a response to a EV Request will in most, if not all cases, be a denial. However, even though the Program Administrator is not a Payor or other Program Sponsor, the invention advantageously engages in bi-directional communications with a Provider using one or more claims processing networks and related communications protocols. Program Sponsors may include Insurers, Pharmaceutical Manufacturers, Group Policy Owners, Employers, pharmacy networks, Nursing Homes, and others.
To use Software B in a conventional workflow, the Provider must access Software B 107 and open this application. Software B may be accessed through a web portal or other application. Because Software B is not connected to Software A, the Provider will then have to re-enter data already found on the request for primary coverage and try to secure data and information from Software B about the payment assistance programs available from manufacturers or others such as 110b.
In current practice, the process 200 for generating a coupon or denial thereof begins at 201 with a simple access to the Software B 107 using in one embodiment a conventional User ID and password. While this represents one possible mode of access as shown at
As part of this Software B 107, the Provider 112 or 102 (as shown by 106) will select a provider such as itself (e.g. a pharmacy) 203. Software B 107 is connected to a database 205 and has for best purpose to manage the secondary coverage. Next, as shown with greater detail at
Next at 207 the system and process will select one co-pay available from the given list from the database 205 and as shown at
In the event the patient entered is qualified for the benefits, data 211 is then entered of the prescriber along with the National Provider Identifier (NPI). In an important step of the process illustrated by
While the above process is beneficial, it does require a departure from the conventional insurance claim coverage workflow and extra steps performed by a Provider, including re-entering data already found in the Provider's claims processing software. It also requires logging in to Software B for every prescription where payment assistance from a pharmaceutical manufacturer is sought.
Rather than interrupting the Software A workflow and logging in to Software B for every prescription where payment assistance is sought, the present invention provides embodiments where claim information is entered into Software B without manual input through the portal. As shown in
In one embodiment as shown in
In the example of
A NCPDP request has a field for a patient's primary Payor BIN in NCPDP requests/claims that are routed to secondary Payors, or in the case of some embodiments of the present invention, the Program Administrator. However, no fields are provided in messages routed to secondary or tertiary Payors for the primary Payor's PCN or Group ID. This information may be necessary for the Program Administrator to evaluate a patient's eligibility for certain programs. Accordingly, in some embodiments of the invention, the Provider enters the PCN and/or Group ID of primary and/or secondary Payors into unused fields in the NCPDP request. In one example, the NCPDP standard includes a cardholder first name field, but it is unused. The Provider enters the patient's PCN and/or Group ID, and the Program Administrator is configured to retrieve this information from the cardholder first name field and enter it into the system. Other unused fields may also be used. The field may also be configured on a pharmacy-by-pharmacy basis, with different pharmacies (or pharmacy chains) using different fields.
The above embodiments can be implemented independently or concurrently in the same system. For example, a system may include both APIs associated with Software B (
In the above embodiments, the web portal 71 is provided to enable access to information determined by or extracted by Software B, and to receive additional related information from additional sources. In some embodiments, Software B populates the web portal 71 with information extracted from eligibility verification requests or other messages carried on the healthcare network. In some embodiments, Software B populates the web portal 71 with determinations made by the business rules engine based on information extracted from eligibility verification requests or other messages carried on the healthcare network. In one example, a Provider such as a pharmacy 113 may access Software B as described above with respect to
Advantageously, the web portal can message various participants for additional information or to communicate status, including the prescribing physician 102. For example, the prescribing physician 102, the patient 116 and/or the pharmacy 113 may install mobile applications on their respective mobile devices. The applications may be secured with account credentials, such as user name and password. In another example, the mobile devices may be identified by an identifier unique to the device. The web portal 71 can then send secure messages and alerts to the mobile application and/or by text/sms message for display to their recipient without using the NCPDP network. The recipients may also respond to messages and alerts using the mobile application. Software B can also send reminders for refills to any or all of the above.
In step 252, a Switch routes the NCPDP request to the primary insurer and, in some cases, to the API 240. In Step 260, an API associated with Software B parses the NCPDP message into a machine-readable format, such as a JSON object. An example of a suitable API and JSON object is discussed in more detail below. The machine-readable object captures any information in the primary insurance request which is necessary to evaluate eligibility for a prescription drug payment assistance program. The machine-readable object is made available to Software B. Software B processes the request using the machine-readable object 270 as generally shown at
Returning to
Once the Provider, as shown at
As shown, at least three cases are possible and illustrated by arrows. At Case 1, the data secured by Software B is sufficient and a full response 414 is sent for display 412a in Software A. In such a case, Software B generates a message for the supplemental message field, which may include a BIN, PCN and Group ID corresponding to a coupon offered by a pharmaceutical manufacturer with instructions to the Provider concerning coupon redemption. In some embodiments, the API message includes the coupon message in the 526-FQ field of the NCPDP-compliant message. The Provider then enters the coupon information into Software A, re-submits the claim, and obtains the benefit of the coupon, all without having to leave the workflow of Software A or re-entering claim information.
In case 2, additional information is required by Software B to evaluate eligibility for a manufacturer's coupon or the value of a coupon according to the relevant payment assistance program. In this case, Software B and the API 240 include a request for additional information in the NCPDP response message. In one example, if an appropriate NCPDP field exists for required information, a message to the Provider is sent back in the 526-FQ field requesting that the Provider add the information and resubmit the claim. For example, a coupon or rebate program may depend on a geographical location of an insured, and the Provider may have left the address fields blank. The supplemental message may request the Provider to enter the data and resubmit the claim using Software A. This has the advantage of having bi-directional communications with the Provider to enter information for Software B without the Provider having to depart from the workflow of Software A.
In another example, a URL is returned in the 526-FQ field and presented to the Provider by Software A to click and access Software B to complete some level of verification. For example, in these cases 413 there could be a Provider obligation to validate one parameter as the visual contact with the person, provide PCN and/or Group ID information for a primary Payor, provide an attestation that the primary insurer is not a government program, or other information that is desirable to enter directly into Software B. Advantageously, in some examples, the URL comprises a tokenized URL as a one-time use link to an entry form for the specific information needed that is active for a limited period of time. Tokenization provides access credentials along with the URL. Each unique token corresponds to an individual claim in the web portal 71. When a user accesses a claim using the tokenized URL, the user does not have access to any other claims. Thus, the Provider does not have to log in to Software B with his or her credentials and find the related claim, and may go directly to the point of entry of the requested information or verification. Once the claim is completed, the token no longer provides access to the claim. In another example, a URL to educational/training information or instructions may be sent to the Provider in the NCPDP. This pretraining may be required prior to dispensation of the prescribed medication.
One final step is shown as 416 where the Provider after being confronted with Case 2 where it shown in one embodiment where he must log in, clicks on the link 419 and enters the portal 416 with the API data and associated queries already loaded. The Provider will answer one or two questions, then the system will either issue the response 418a or deny the response 418b.
The third case 417 is when the case for secondary coverage is denied 415. The Software A will then display 412c this response. The intermediate response is indicated at 412b on
Turning to
For example, the improved process, system and method of use thereof 500 first results in enhancing database accesses 501 and the amount of information which is stored therein. At 502, what is shown is the enhancement of the database 501 for each of the numerous co-pay programs, for example, adding legal documents linked with the programs, geographical service maps and other related information linked with where the services are offered, patient specific transactions such as agreements, consents, attestations, etc.
At 503, the inventor has found that place-of-service identity and licensure profiling, that offers information on where the service relates to the setting in which prescriptions pertaining to a manufacturer-sponsored service are received. For example, the Center for Medicare & Medicaid Services created a set of service codes for professional claims that includes:
By way of incorporation therein, the entire table from the CMS (updated October 2019) is added hereto. As illustrated such a code may be placed between element 206 and 501 or can be inserted as part of any upload and structure of information. One of ordinary skill in the art will understand that if Software A already is programmed to include this additional information, such can be uploaded as part of 202. At element 504, the code that was entered 503 can then be selected once the co-pay or the pharmacy has been entered into the system at step 509 or 207.
Next, the inventor has added step 505 which allows for the system, process and method of use thereof to enter co-pay program additional comments that may be generated or provided by any party. For example, electronic messaging, digital files, video or audio content relating to the program. The content may comprise training content for dispensing or use of the prescribed medication. This will help a user who secures information to get additional information on the programs.
Step 506 illustrates where a pharmacy or any other user of the system can be asked to file and seek preapproval requests linked with the co-pay program. The Software B 105 can, as shown, request at 507 for validation from Co-Pay service providers of these requests 506 in a subsequent step.
At 508, the inventor has added the additional capacity for data files of multiple format type to be loaded and added to the enhance database 501 to further help with information collection, processing and storage for future use. At 509, the upload and display for selected pharmacies from the enhanced database 501 also can include notifications of outstanding actions, for example the request for validation 506, 507 uploaded from the pharmacy.
Referring to
In the illustrated examples, the API 240 processes NCPDP messages from Software A into machine-readable objects, such as JavaScript Object Notation (JSON) objects. A JSON object generally comprises a set of defined tags and corresponding values. One example of a set of JSON tags/fields and related descriptions is provided in the table below.
The JSON field/tag names are in the left column of the table and a description of each field is in the right column. These field names generally correspond to NCPDP message fields. Each JSON field is assigned a data type (string, number, Boolean, etc.). Each field is also designated as either required or not required. The values for the fields for each JSON object are populated from NCPDP messages by the parser. The invention is not limited to these fields and fewer or greater fields may be employed. Software B accesses populated JSON objects via the API and processes the data as is described with respect to
After processing the data and evaluating the claim against the pharmaceutical manufacturer's eligibility requirements, Software B updates the JSON object with response information. One example of response information comprises the following table.
In particular, the response information includes a “success” field (Boolean) and a “message” field (string). The message field comprises a string of text to be displayed on Software A to the requesting Provider. This may comprise any of the examples set forth above, such as instructions to re-submit with additional information, a time-limited hyperlink to enter an attestation, etc.
Using the response information from Software B, the API 240 executes a script and generates a NCPDP-compliant response message with routing information back to the requesting Provider. In the example of 12A, the response is provided to Payor 110b to forward to the claims processing network 10. In the example of 12B, the API 240 directly sends the response to the claims processing network 10.
In each example, the NCPDP response message also includes the content for the 526-FQ field, where required. The API transmits the NCPDP response message to the network and the one or more Switches routes the message to the to the Software A of the requesting Provider. Thus, Software A does not have to be modified to communicate information bi-directionally with Software B. Also, enhanced messaging between Software B and Software A is achieved without modifying existing NCPDP protocols.
In another example, Software B populates the web portal with information regarding a response to a request made using the NCPDP network. The web portal may then send a response to a recipient via the mobile application as described above. For example, if the response information is unsuitable for inclusion in a NCPDP-compliant message, such as graphics or images, the web portal may communicate the response information to a recipient via the secure mobile application. Also, this example may be used to communicate with individuals that do not have regular access to the NCPDP network. For example, a request for verification of information could be made directly to a patient/consumer 116. Also, if there is an ambiguity or error in a prescription, the web portal may contact the prescribing physician directly, rather than communicating through the Provider.
In the above and on the associated figures, what is shown is a process for the management, storage, and automated generation over a system comprising a plurality of user personal computers or servers, each with at least a computer processor with a computer memory for executing software in the computer memory by the computer processor, a computer display and interface connected to the computer processor for use of at least a software solution by the processor in the memory, and wherein each of the plurality of user personal computers is connected to a network for the transfer of information in at least one protocol of communication between said user personal computers, wherein the system includes at least a first of the plurality of user personal computers includes a first software solution for determination of primary coverage by a Payor in the health care space, and includes a second solution either on the same or a different user personal computer for determination of secondary coverage by a different Payor in the health care space, the process comprising the steps of connecting, using a health-care related protocol of communication, over a network to the first software solution operable by a provider of health care services in a health care space to a third party Payor for sending an eligibility verification request of primary coverage for an individual and securing a response of eligibility verification, updating a database of the first software solution with the response for primary coverage received at the first software solution, connecting, using the health care related protocol of communication, over the network to the second software solution operable by the provider of health care services in the health care space, launching the second software solution and using an API data exchange tool, populating the second software solution with a selected set of data from the database updated in one of the preceding steps, allowing the second software solution to generate a formatted response in the health care protocol of communication with data regarding a response as to secondary coverage based upon the populated selected set of data from the database and transferred over the a software application programming interface (API) data exchange, and displaying at the first software solution to the provider of health care services the response as to secondary coverage.
In other embodiments, the health care protocol of communication is the NCPDP Telecommunication Standard, the formatted response in NCPDP protocol of communication with data regarding the response to secondary coverage is sent using a Response Status Segment including the message 526-FQ field, and the response as to secondary coverage is sent along one of three possible formatting from a group including: a full response with personalized code, a Uniform Resource Locator (URL) for logging back into the second software solution, or a denial of secondary coverage.
Also, the process further comprises the step of allowing access from the first software solution to the second software solution via the provider URL for generating over a response of opened queries either a full response with personalized code or a denial of coverage, the selected set of data from the database includes at least one of: a Bank Identification Number (BIN), a Process Control Number (PCN), a Primary Group ID, a National Provider Identifier (NPI), a selected co-pay, a patient contact information, an identification of a selected pharmacy, and using the selected set of data, the step of allowing the second software solution to generate the formatted response in NCPDP protocol of communication with data regarding the response as to secondary coverage comprises the sub-steps of selecting a health care provider, selecting a co-pay as secondary insurance, passing a patient qualification step, entry of prescriber information; population of the Bank Identification Number (BIN), the Process Control Number (PCN) and the Primary Group ID, entering a primary claim result; and generating the response as to secondary coverage.
Also, the response is a coupon with at least a member ID personalized number for entry into the first software solution, the process of entering the primary claim results includes entry of rejection codes also part of the selected set of data, the provider of health care services is a pharmacy, the primary coverage and the secondary coverage is for the repayment of costs of drugs, and the API is of the JSON type with JSON fields and wherein the API is programmed to both capture and transfer data from the first software solution to the second software solution but also to transfer a response from the second software solution to the first software solution.
Also described is a system for the management, storage, and automated generation of primary and secondary health care coverage, comprising: a plurality of user personal computers or servers, each with at least a computer processor with a computer memory for executing software in the computer memory by the computer processor, a computer display and interface connected to the computer processor for use of at least a software solution by the processor in the memory, and wherein each of the plurality of user personal computers is connected to a network for the transfer of information in at least one health care protocol of communication between said user personal computers, wherein the system further comprises: at least a first of the plurality of user personal computers with a first software solution for determination of primary coverage by a Payor in the health care space, and at least a second of the plurality of user personal computers with a second solution either on the same or a different user personal computer for determination of secondary coverage by a different Payor in the health care space, and wherein, the first software solution for sending an eligibility verification request of primary coverage for an individual to the second software solution and securing a response of eligibility verification in a health care protocol; a database in the first software solution for storage of the response for primary coverage received at the first software from the second software solution; an API data exchange tool, for taking a selected set of data from the database of the first software solution and populating the second software solution; and the second software solution to generate a formatted response in the health care protocol of communication with data regarding a response as to secondary coverage based upon the populated selected set of data from the database and transferred over the API data exchange.
Finally also disclosed is an Application Program Interface (API) to help coordinate the transfer of information in a system for the management, storage, and automated generation of primary and secondary health care coverage, the system comprising a plurality of user personal computers or servers, each with at least a computer processor with a computer memory for executing software in the computer memory by the computer processor, a computer display and interface connected to the computer processor for use of at least a software solution by the processor in the memory, and wherein each of the plurality of user personal computers is connected to a network for the transfer of information in at least one health care protocol of communication between said user personal computers, wherein the system further comprises at least a first of the plurality of user personal computers with a first software solution for determination of primary coverage by a Payor in the health care space, and at least a second of the plurality of user personal computers with a second solution either on the same or a different user personal computer for determination of secondary coverage by a different Payor in the health care space, and wherein the first software solution for sending an eligibility verification request of primary coverage for an individual to the second software solution and securing a response of eligibility verification in a health care protocol, the API comprising, a data exchange tool, for taking a selected set of data from a database of the first software solution and populating the second software solution, and the second software solution to generate a formatted response in the health care protocol of communication with data regarding a response as to secondary coverage based upon the populated selected set of data from the database and a tool to transfer back to the first software solution a response data.
Claims
1. A process for generating a response message to an eligibility verification request transmitted over a healthcare claims network having at least one health care protocol of communication, the process comprising the steps of: wherein the at least one health care protocol of communication comprises the NCPDP Telecommunication Standard.
- executing business rules on a rules engine for a program sponsor on information in the eligibility verification request to determine an individual's eligibility for benefits;
- generating a protocol-compliant response message including information not specified in the health care protocol of communication; and
- providing the protocol-compliant response message to the claims network;
2. The process of claim 1, wherein the information not specified in the health care protocol of communication comprises a coupon for pharmaceutical manufacturer benefits in a pre-defined field of the NCPDP Telecommunication Standard.
3. The process of claim 2, wherein the coupon comprises at least a member ID personalized number for entry into a subsequent request for payment.
4. The process of claim 1, wherein the protocol-compliant eligibility verification request message is generated on a first software solution and the protocol-compliant response message is generated by a second software solution; and wherein the second software solution further comprises a remote web portal.
5. The process of claim 4, wherein the information not specified in the health care protocol of communication comprises a tokenized Uniform Resource Locator (URL) in the 526-FQ field of the NCPDP Telecommunication Standard which provides access to the remote web portal.
6. The process of claim 5, wherein the rules engine determines that additional information is required to process the eligibility verification request, the web portal is pre-populated with information from the eligibility verification request from the rules engine, and wherein the tokenized URL includes information to authenticate a recipient of the URL and provide access to the web portal for a limited period of time.
7. The process of claim 5, wherein the tokenized URL provides access to request-specific forms, including ability to pre-fill the forms based on claims data from the eligibility verification request, facilitate the transmission of the forms to stakeholders for review, and track the completion of various forms.
8. The process of claim 5, wherein the tokenized URL enables collection and management of legal documents pertaining to a pharmaceutical manufacturer benefit program, place of service, or per-patient prescription transactions.
9. The process of claim 5, wherein the tokenized URL enables place of service identity and licensure profiling.
10. The process of claim 5, wherein the tokenized URL provides access to place of service training related to the eligibility verification request, inclusive of the provision of messaging, digital files, video and audio content pertaining to a payor-sponsored service.
11. The process of claim 5, wherein the tokenized URL enables intake of data files comprising information not captured via a standard NCPPD eligibility verification request.
12. The process of claim 5, wherein the tokenized URL enables guided conveyance of forms for the processing and electronic filing of prior authorization forms by pharmacies for patients in connection with manufacturer-sponsored service programs
13. The process of claim 4, wherein the first software solution is a healthcare services Provider's claim processing system, and further comprising the step of displaying at the first software solution to the Provider a response.
14. The process of claim 4, wherein a benefit program administrator operates the second software solution, and the benefit program administrator receives and parses the protocol compliant eligibility verification request message.
15. The process of claim 14, wherein benefit program administrator is assigned routing information comprising at least one of the group comprising a Bank Identification Number (BIN), a Process Control Number (PCN) and a Primary Group ID; and the protocol-compliant eligibility verification request message includes the assigned routing information.
16. The process of claim 4, wherein the second software solution comprises an API, and the method further comprising the steps of:
- the API parsing the protocol-compliant eligibility verification request message into a machine-readable object,
- the business rules engine executing the business rules on the machine readable object;
- the business rules engine updating the machine-readable object with response information; and
- the API generating the protocol-compliant response message based on the updated machine-readable object.
17. The process of claim 1 further comprising the step of parsing the protocol-compliant eligibility verification request message to extract information relevant to a pharmaceutical manufacturer benefit program, wherein step of parsing the protocol-compliant eligibility verification request message is performed by a program sponsor and the step of executing business rules by is performed by a program administrator.
18. The process of claim 1 further comprising the step of receiving the protocol-compliant eligibility verification request message from the claims network.
19. The process of claim 1, wherein the program sponsor is a pharmaceutical manufacturer.
20. The process of claim 1, wherein the program sponsor is an insurer.
21. A process for generating a response message to an eligibility verification request transmitted over a healthcare claims network having at least one health care protocol of communication, the process comprising the steps of: wherein the at least one health care protocol of communication comprises the NCPDP Telecommunication Standard.
- executing business rules on a rules engine for a program sponsor on information extracted from the eligibility verification request to determine an individual's eligibility for benefits;
- populating a web portal with information extracted from the eligibility verification request; and
- providing a response to the eligibility verification request via the web portal and over a network other than the healthcare claims network;
22. The process of claim 21, wherein the protocol-compliant eligibility verification request message is generated on a first software solution and the business rules engine and web portal comprise a second software solution.
23. The process of claim 21, wherein the business rules engine determines that additional information is required to process the eligibility verification request, the web portal is pre-populated with information from the eligibility verification request from the rules engine, and wherein web portal communicates a request for additional information to an individual without using the healthcare claims network.
24. The process of claim 23, wherein the first software solution is a healthcare services Provider's claim processing system.
25. The process of claim 23, wherein a benefit program administrator operates the second software solution, and the benefit program administrator receives and parses the protocol compliant eligibility verification request message.
26. The process of claim 25, wherein benefit program administrator is assigned routing information comprising at least one of the group comprising a Bank Identification Number (BIN), a Process Control Number (PCN) and a Primary Group ID; and the protocol-compliant eligibility verification request message includes the assigned routing information.
27. The process of claim 23, wherein the second software solution comprises an API, and the method further comprising the steps of:
- the API parsing the protocol-compliant eligibility verification request message into a machine-readable object,
- the business rules engine executing the business rules on the machine readable object;
- the business rules engine updating the machine-readable object with response information; and
- the business rules engine populating the web portal with information based on the updated machine-readable object.
28. The process of claim 21 further comprising the step of receiving the protocol-compliant eligibility verification request message from the healthcare claims network.
29. The process of claim 21, wherein the program sponsor is a pharmaceutical manufacturer.
30. The process of claim 21, wherein the program sponsor is an insurer.
31. The process of claim 21, further comprising the step of receiving the response on a mobile device.
32. The process of claim 21, further comprising the step of receiving the response on a mobile device, wherein the mobile device is associated with a person selected from the group consisting of a prescribing physician, a pharmacist, and a patient related to the eligibility verification request.
33. The process of claim 1 further comprising the step of parsing the protocol-compliant eligibility verification request message to extract information relevant to a wellness program sponsored by a third party payor, pharmaceutical manufacturer benefit program, or other third party, wherein step of parsing the protocol-compliant eligibility verification request message is performed by a program sponsor and the step of executing business rules by is performed by a program administrator.
Type: Application
Filed: Aug 11, 2021
Publication Date: Dec 15, 2022
Inventors: Stephen Barrett CICHY (Chicago, IL), Markus Daniel BOCKLE (Pickens, SC), Courtney Brooke JACKSON (Hendersonville, NC)
Application Number: 17/399,178
