US20220398667A1

US20220398667A1 - Process and system for the management, storage and automation of health care information and application program interface therefor

Info

Publication number: US20220398667A1
Application number: US17/399,178
Authority: US
Inventors: Stephen Barrett CICHY; Markus Daniel BOCKLE; Courtney Brooke JACKSON
Original assignee: Monarch Specialty Group Inc
Current assignee: Monarch Specialty Group Inc
Priority date: 2021-06-09
Filing date: 2021-08-11
Publication date: 2022-12-15

Abstract

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.

Description

RELATED APPLICATIONS

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 TECHNOLOGY

The 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.

BACKGROUND

Remuneration 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.
FIG. 1 from this protocol illustrates an example of communications between Providers and Claims Adjudicators on a claims processing network 10 for prescription claims adjudication. Multiple claims processing networks are available (e.g., RelayHealth, Emdeon, and others) and may be used by different actors at different times on the same coverage claims. As shown, some processors can be a Claims Adjudicator, either directly speaking to the Provider, via a “Switch” using an Intermediary before or after the “Switch” or on the right of FIG. 1 using a Facilitator connected to the switch to help manage between a Primary Adjudicator as the Processor and the Secondary Adjudicator as the Processor.
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.
FIG. 2 also from the protocol shows what is called a “Payor-to-Payor” mode between two Adjudicators instead of a communication between an Adjudicator and a Provider. As shown at FIG. 1 , the protocol uses both “Switches” and “Facilitators” in an effort to communicate. For example, when Medicare Crossover communications between Medicare and other Payors happen, this can be done as shown at FIG. 2 . Also, when information is reported for Medicare Part D from Payor to facilitator to Payor, the system can be used as what is called “Medicare Part D Payor-to-Payor facilitation.”
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 FIGS. 1 and 2 . For example, the code includes the following types of responses:


		Segment

Eligibility	Transmission	Response Status Segment
Verification	Accepted/Transaction
Response	Approved
Eligibility	Transmission	Response Status Segment
Verification	Accepted/Transaction
Response	Rejected
Claim Billing or	Transmission	Response Status Segment
Encounter	Accepted/Transaction
	Paid
Claim Billing or	Transmission	Response Status Segment
Encounter	Accepted/Transaction
	Captured
Claim Billing or	Transmission	Response Status Segment
Encounter	Accepted/Transaction
	Rejected

** Other segments similar such as Transmission Rejected/Transaction Rejected, Service Billing/Transmission Accepted-Transaction Paid, etc.

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:


		Mandatory or
Field	Name	Situational

111-AM	Segment Identification	M
112-AN	Transaction Response Status	M
503-F3	Authorization Number	Q
130-UF	Additional Message Information Count	Q
	(Required Once Invention Uses 526-FQ)
132-UH	Additional Message Information Qualifier	Q *R*
	(Required Once Invention Users 526-FQ)
526-FQ	Additional Message Information	Q *R*
	(API Data Response FIG. 11 290)
131-UG	Additional Message Information Continuity	Q *R*
	(Required only if Message 526-FQ is Repeated)
549-7F	Help Desk Phone Number Qualifier	Q
550-8F	Help Desk Phone Number	Q

The Response Status Segment breakdown for a Rejected Transaction reads:


		Mandatory or
Field	Name	Situational

111-AM	Segment Identification	M
112-AN	Transaction Response Status	M
503-F3	Authorization Number	Q
510-FA	Reject Count	R
511-FB	Reject Code	R *R*
546-4F	Reject Field Occurrence Indicator	Q *R*
130-UF	Additional Message Information Count	Q
	(Required Once Invention Uses 526-FQ)
132-UH	Additional Message Information Qualifier	Q *R*
	(Required Once Invention Uses 526-FQ)
526-FQ	Additional Message Information	Q *R*
	(API Data Response FIG. 11 290)
131-UG	Additional Message Information Continuity	Q *R*
	(Required only if Message 526-FQ is Repeated)
549-7F	Help Desk Phone Number Qualifier	Q
550-8F	Help Desk Phone Number	Q
987-MA	URL	I

The protocol also includes a Claim Billing request which also provides a Response Status Segment that is Transaction Accepted/Transaction Paid:


		Mandatory or
Field	Name	Situational

111-AM	Segment Identification	M
112-AN	Transaction Response Status	M
503-F3	Authorization Number	Q
547-5F	Approved Message Code Count	Q
548-6F	Approved Message Code	Q *R*
130-UF	Additional Message Information Count	Q
	(Required Once Invention Uses 526-FQ)
132-UH	Additional Message Information Qualifier	Q *R*
	(Required Once Invention Uses 526-FQ)
526-FQ	Additional Message Information	Q *R*
131-UG	Additional Message Information Continuity	Q *R*
	(Required only if Message 526-FQ is Repeated)
549-7F	Help Desk Phone Number Qualifier	Q
550-8F	Help Desk Phone Number	Q
993-A7	Internal Control Number	Q

The protocol also includes a Claim Billing request which also provides a Response Status Segment that is Transaction Accepted/Transaction Captured:


		Mandatory or
Field	Name	Situational

111-AM	Segment Identification	M
112-AN	Transaction Response Status	M
503-F3	Authorization Number	Q
130-UF	Additional Message Information Count	Q
	(Required Once Invention Uses 526-FQ)
132-UH	Additional Message Information Qualifier	Q *R*
	(Required Once Invention Uses 526-FQ)
526-FQ	Additional Message Information	Q *R*
131-UG	Additional Message Information Continuity	Q *R*
	(Required only if Message 526-FQ is Repeated)
549-7F	Help Desk Phone Number Qualifier	Q
550-8F	Help Desk Phone Number	Q
993-A7	Internal Control Number	Q

The protocol also includes a Claim Billing request which also provides a Response Status Segment that is Transaction Accepted/Transaction Rejected:


		Mandatory or
Field	Name	Situational

111-AM	Segment Identification	M
112-AN	Transaction Response Status	M
503-F3	Authorization Number	Q
510-FA	Reject Count	R
511-FB	Reject Code	R *R*
546-4F	Reject Field Occurrence Indicator	Q *R*
130-UF	Additional Message Information Count	Q
	(Required Once Invention Uses 526-FQ)
132-UH	Additional Message Information Qualifier	Q *R*
	(Required Once Invention Uses 526-FQ)
526-FQ	Additional Message Information	Q *R*
131-UG	Additional Message Information Continuity	Q *R*
	(Required only if Message 526-FQ is Repeated)
549-7F	Help Desk Phone Number Qualifier	Q
550-8F	Help Desk Phone Number	Q
987-MA	URL	I

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.

SUMMARY

The 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.

DRAWINGS

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.

FIG. 1 is an illustration from the prior art illustrating the Processor to Provider communication between actors of the health care industry under the NCPDP Telecommunication Standard v. D.0.

FIG. 2 is an illustration from the prior art illustrating the Processor to Processor communication between actors of the health care industry under the NCPDP Telecommunication Standard v. D.0.

FIG. 3 is an illustration of a possible hardware architecture in which the process and system for the automation of health care information and application program interface therefor described here below can be implemented according to an embodiment of the present disclosure.

FIG. 4 is an illustration of the different software solutions to be implemented in the different computers shown at FIG. 3 and associated structuring of user-interface implementation for the implementation and operation of the process and system for the automation of health care information and application program interface therefor according to an embodiment of the present disclosure.

FIG. 5 is a functional and representative diagram of the different actors and Processors to Providers to be connected using a hardware solution as shown at FIG. 3 and operating a group of software solutions as shown generally at FIG. 4 which operate under a protocol for the process and system for the automation of health care information and application program interface therefor according to an embodiment of the present disclosure.

FIGS. 6 and 7 illustrate several possible pages and operating windows of the software interface of a possible pharmacist for entry of the primary coverage request for use under the process and system for the automation of health care information and application program interface therefor according to an embodiment of the present disclosure.

FIG. 8 is a diagram which represents the different functional and software steps which describe a service for the calculation and generation of a coupon of secondary benefits linked with additional coverage for any primary claim for use in a software operated by the pharmacists according to an embodiment of the present disclosure.

FIGS. 9 and 10 illustrate several possible pages and operating windows of the software interface of the service for the calculation and generation of a coupon code for secondary benefits linked with additional coverage for any primary claim for use in a software solution as shown at FIG. 8 .

FIG. 11 shows a diagram representing the different steps and process for the system for the automation of health care information and application program interface therefor according to an embodiment of the present invention.

FIG. 12A is a diagram illustrating a first example of the function and transfer of API information between the different terminals or software for the process and system for the automation of health care information and application program interface therefor according to an embodiment of the present disclosure.

FIG. 12B is a diagram illustrating a second example of the function and transfer of API information between the different terminals or software for the process and system for the automation of health care information and application program interface therefor according to an embodiment of the present disclosure.

FIG. 13 is a revised version of FIG. 8 adding multiple secondary features to the primary invention in accordance to an embodiment of the present disclosure.

FIG. 14 is a diagram illustrating the different steps of the primary process linked with the process for the management, storage and automation of health care information and application program interface therefor according to an embodiment of the present disclosure.

FIG. 15 is a revised version of FIG. 14 adding multiple secondary features to the primary invention in accordance to an embodiment of the present disclosure.

Corresponding reference numerals indicate corresponding parts throughout the several views of the drawings.

DETAILED DESCRIPTION

Numerous 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.
FIG. 3 shows generally a computer network arrangement 1 where a user (for example, a pharmacist) uses either a computing device 58 or other device such as a smart phone, a web enabled phone, a tablet, or any other type of computer device to access network 51 to submit claims using the NCPDP protocols. Several other computer devices 53 are shown in addition to 58 to help understand the diversity of use and configuration. Computing device 58 is operatively connected 59 to the network 51. Server 50 is also connected to network 51. For example, a user may log into a server 50 via a network 51 such as the internet or a LAN. What is also contemplated is the use of partial internal networks operating remote or in tandem with the internet. For example, a hospital may have a LAN-based internal system and network which could be connected externally.
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 FIG. 4 , having shown above how multiple types of hardware configurations now can exist, this diagram illustrates the different software solutions to be implemented as interface 57 for access to a platform 52 from FIG. 3 and associated structuring of user-interface implementation for the implementation and operation of the process and system for the automation of health care information and method thereof. As shown, software solutions 62 (later shown as Software A and Software B), that are protocol compliant engines for operating different object can be programmed with either a URL interface 61 that is accessed via a HTML format web browser 60. Alternatively, in most industry and highly secure software solutions, a portal 71 is created with a software interface 70. The system 1 as in FIG. 3 has software locally at 58 or 53 and locally at a central location 50 for processing of data. Using device 58 shown at FIG. 3 , a person can, for example download an App from an App store or a software from the internet. Referring to FIG. 4 , using an HTML browser 60, a Software Interface 70 such as a dedicated application, or other suitable software, may connected to the website 62 via a URL 61, API or other connection specific to the data is connected. The system 62 described above as hosted on server is made available as a website or web portal with a main page 63 and subpages 64 such as for example tabs with patient or prescription-specific tabs to offer structured information 65 or non-structured information 66. Users navigate the website 62 via these pages 63, 64 to enter and deliver structure and non-structure data. HTML links may be used in place of tabs.
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 FIG. 4 suggests that the Protocol Compliant Engine 62 is located remotely via a portal 71 or a URL connection 61, one of ordinary skill in the art will understand that such solutions can be, if needed localized in a single computer and the connections 61, 71 can be internal to a LAN, another network or even a single machine.
Turning to FIG. 5 , what is shown is a functional and representative diagram of the different actors, often called under the protocol Processors to Providers to be connected using a hardware solution as shown at FIG. 3 and operating a group of software solutions as shown generally at FIG. 4 which operate under a protocol for the process and system for the automation of health care information and method thereof according to an embodiment of the present disclosure.
Shown as 100 is the representation of the different actors according to one embodiment which play roles of the hardware of FIG. 3 . To help numbering, some of the computers have been renumbered to coordinate the set to 100-117 to better guide the reader. While renumbering has been offered, one of ordinary skill will understand that such have no effect on what is shown or described. As shown at the bottom row of FIG. 1 from the prior art, a Provider shown is a hospital 102 which offers healthcare services. In some cases, the hospital 102 is the party which will dispense and deliver drugs or other services using a station 101 of some type connected 103 to the network 51.
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 FIG. 1 .
Also illustrated is one of a numerous number of Payors, for example, insurance 110 a which has a computing device 109 for connected 111 to the network as part of the system. Shown as 110 b 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 FIG. 4 . Systems can include two windows but will run different demands differently.
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 110 a. 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 110 a. 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.
FIG. 6 shows one window of a possible configuration and embodiment of Software A 105 which relates to any number of commercially available software solutions designed to generate, send, receive, and process requests for insurance coverage using the NCPDP protocols. For example, as shown at 130, a patient's information typically includes name and contact information, such as an address and telephone number(s). Other parameters such as gender, social security number, and language, may be included 131, 132. On each of these software solutions, a script/prescription is received under the NCPDP protocol which will match the identity of the patient. If the patient is not in the system, a protocol is set up to help pharmacists and doctors create a patient's identity and profile.
FIG. 7 shows how the primary insurance is connected to the patient 133 and in some cases several options can be given. Here, using button 134, the primary insurance is selected. The primary insurer typically has associated claim routing information, such as one or more of BIN, PCN and Group ID entered into Software A. This information is typically found on insurance cards provided by an insurer and carried by the insured to access healthcare. Similar information for a secondary insurer/Payor may also be entered into Software A. The Software A 105, having the identity of the client and the received prescription from the service provider, will be able to generate a NCPDP compliant request with routing information to the appropriate Adjudicator (Processor) as shown at FIG. 1 . This may be considered a claim for insurance coverage for the prescription. For example, if the prescription requests 400 capsules of drug X, the primary insurance may be queried on an upload message which is then returned down to the Provider in the bilateral communication under the protocol.
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 110 b.
FIGS. 9 and 10 shown specific illustrations of images from a Software B 107 which is designed to optimize the participation of secondary Payors such as pharmaceutical manufacturers. FIG. 8 illustrates a diagram which represents the different functional and software steps which describe a service for the calculation and generation of a coupon of secondary benefits linked with additional coverage for any primary claim for use in a software operated by the pharmacists according to an embodiment of the present disclosure.
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 FIG. 4 at either 61 or 71. But one of ordinary skill in the art will recognize that as fingerprint, facial recognition features and other biometrics arrive on the market, they may be used along with other access processes known in the art.
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 FIG. 9 , for each selected Provider 203 is uploaded and displayed a list of all co-pays available. The database access 205 which has each pharmacy or Provider 206 accessed one of many co-pay programs includes multiple key metrics for use and indexing 202. For example, if a small California-based corporation wants to offer a rebate certain limited coverage for one specific drug when purchased in 400 capsule format, the database 205 can be programmed to include the promotion 205. It may be assigned only to pharmacies 206 in a certain area and could also include a specific address of residence. Entry of this promotion and co-pay program 202 is time consuming and as shown requires the entry of a product name, a supplier type, the NDC, the sponsor, the program name and the date/status. The NDC number is the National Drug Code which serves as an identifier for products. As shown at FIG. 9 , offered back from the database is a product name 150, the type of supply and format (e.g. 60 mg), the National Drug Code (NDC) 152 which connects the product and avoid errors by creating a redundancy in the descriptive and the corporation/name of the program sponsor. Here, it may be the drug manufacturer 153, a third-party, or any other party. The name is also entered to help the Provider understand if he has the proper program in mind 154 and finally a status/order selection 155. Some offerings could be seasonal or temporary or even limited to a certain budget.
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 FIG. 9 . In some cases, one of ordinary skill in the art can understand that several co-pays could be offered and offer different non-additive benefits. To select, the person adds the number, the name and nature of the benefits. The patient is then qualified 208 in a first step of qualification. In a positive and negative option (Y/N) the selected patient may be found not to be eligible for the co-pay. For example, if the person is insured by Medicare, payment from pharmaceutical manufacturers is not permitted. In that case, the secondary co-pay benefit will be immediately denied 209. The qualification process can be complex and multi-stage 210, and various business rules may be applied to evaluate the claim. Several questions and conditions may be imposed by the co-pay secondary insurance. For example, in the case of an HIV drug, the person may be required to demonstrate if he or she is not eligible to other preferential benefits which would be able to pay for the medication. Also, the co-pay benefit may not be available to those who have a certain medical conditions.
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 FIG. 10 and shown as 212 as a portion of the diagram, the information on the primary insurance is entered such as the Bank Identification Number (BIN), the Process Control Number (PCN) and the Primary Group ID. This information allows the system to know who is the primary claim Payor. Then a claim result is requested 213 which is then analyzed at 214 and 215 for a determination if the claim has been paid and therefore there is no need for co-pay or the claim has been denied in whole, in portion or in part. In that case, rejection codes must be entered 215. The system then at 216 will generate a coupon/dispense code which will be unique to the claim and secondary insurance coverage. The coupon issued includes a BIN #, the PCN #, the GROUP ID which was entered along with the MEMBER ID and text such as instruction and conditions. Each MEMBER ID # is individual and customized to the transaction. The Provider then returns to Software A 105 and enters the coupon information into Software A 105 systems under the tab “secondary coverage” or alternate coverage to reduce the price. The Provider then re-submits the claim. This two-step is not unlike the entry of a coupon reduction in websites.
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 FIG. 12A and FIG. 12B, API 240 receives a NCPDP request generated by Software A, parses the message and makes certain information from the NCPDP request available to Software B.
In one embodiment as shown in FIG. 12A, the claims processing network 10 is conventional. A Payor 110 b connected to the claims processing network 10 provides API 240 with access to received NCPDP request messages for processing by Software B. In some embodiments, the Payor develops an API and parses NCPDP messages to extract prescription information and passes the extracted prescription information to Software B via the API. In some embodiments, a Payor passes NCPDP messages to Software B through an API.
In the example of FIG. 12B, the API 240 is part of the claims processing network 10 a and directly receives NCPDP messages from the claims processing network. NCPDP routing information is generated for the Program Administrator, including one or more of a BIN, a PCN, and a Group ID, as would be used by an insurer or other Payor. The Program Administrator routing information is entered into Software A, for example, by the Provider as if it were a secondary Payor. In another example, primary and secondary Payors are entered in the primary and secondary positions, respectively, and the BIN, PCN, and/or Group ID of the Program Administrator is entered into a tertiary position. The Switches route NCPDP messages including the API's routing information to API 240. Advantageously in this example, a Payor does not have to be involved in each NCPDP transaction.
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 (FIG. 12B) and APIs associated with and operated by Payor (FIG. 12A). In either example, Software B 107 may access information from Payor 110 b concerning eligibility requirements and other business rules for administration of a payment assistance program. Advantageously, a Provider does not have to alter its Software A workflow, and appropriate data is automatically made available to 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 FIG. 8 . A patient/consumer 116 may access Software B to check on claims status or obtain information about the prescription medication.
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.
FIG. 11 as shown describes generally and functionally how in a series of six steps of a first process, a claim request is launched in Software A 250. The claim request is generated as set forth above with respect to FIGS. 6 and 7 , except that the Program Administrator is provided with information from the NCPDP request from Software A. In one example (FIG. 12A), API 240 is provided with access to NCPDP messages via a Payor 110 b that is part of the claims processing network 10. In another example (FIG. 12B), the API 240 associated with the Program Administrator is added as a secondary Payor (or tertiary Payor), and the corresponding BIN, PCN and Group ID information is added to the NCPDP message. This may be done in series with a claim request for primary insurance or in parallel. For example, after the primary insurance claim is adjudicated, the Provider may add the Program Administrator as a secondary Payor an resubmit the claim. Alternatively, the Provider may include the primary insurance Payor and Program Administrator on the initial claim request. Once submitted, the Switches will route any NCPDP message having the Program Administrator's routing information to the Program Administrator.
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 FIG. 8 but without manual input from the Provider. Software B generates response message and updates the machine-readable object 280. The API 240 generates a NCPDP-compliant message in step 290. In step 292, a switch routes the response to the requesting Provider. In step 300, Software A processes the NCPDP response.
FIG. 13 offers greater detail on how the process generally and broadly 400 described at FIG. 11 , FIG. 12A and FIG. 12B can be articulated in conjunction with a plurality of different responses. For example, at 401 the Provider such as a doctor or pharmacist accesses Software A and enters much of the data relating to the patient and the prescription (some of which may have been received automatically in Software A from a prescriber). The Provider may then request primary coverage 402, for example a coverage of 20%, 95% or even 100% from the source shown at FIG. 5 as 110 a. As shown above, at multiple portion of Software A, can a message be sent of relevance, here the Eligibility Verification Request under the NCPDP code 403. The primary coverage provider (i.e. the Payor) 404 responds to the eligibility verification by sending data which indicates, for example, if the primary covers all, a portion or none of the request. Codes are also sent under the format NCPDP as the EV Response 405. This response can be either automatically used to upload the information as described below or the request can be made as shown as part of a subsequent activation from the Provider.
Returning to FIG. 13 , at 406, the database of Software A is now updated with the EVR data as shown at FIG. 7 133. It has now response parameters and, for example, reject codes if in fact those were generated by the Primary Insurance Provider. At this step, the database is updated with this information at Software A.
Once the Provider, as shown at FIG. 7 has the primary result 133 displayed and for use in any way described above, she can make a request for a secondary coverage by clicking, for example on the button ADD 134 in Software A. The NCPDP EV Request made 407, for example via FIG. 7 element 133 is routed to the API (either associated with Software B or a Payor 110 b) 409 which passes the EV Request as described above 408, will exchange and upload information it needs to run as shown at 410 and fully described at FIG. 8 . Advantageously, Software B now has access to information contained in the initial EV Request to the primary insurer 110 a and the primary insurer's response, without the Provider having to log into Software B or interrupt the Provider's conventional workflow in Software A. The system then creates a formatted response under the NCPDP protocol 411 as the EV Response.
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 412 a 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 418 a or deny the response 418 b.
The third case 417 is when the case for secondary coverage is denied 415. The Software A will then display 412 c this response. The intermediate response is indicated at 412 b on FIG. 13 .
Turning to FIG. 14 , as shown with detail at FIGS. 3-13 is a new process, system and method for multiple steps in optimization, database enhancement, storage, and automation of use of health care information by a health care provider and it manages multiple Payor services linked with a patient or a prescription. This represents a modification to FIG. 8 to reflect the new processes described above. What is described are additional pieces which should be seen as additive to FIG. 8 and not replacing these above described inventive concepts.
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:


Code	Place of
	Service Name	Place of Service Description

01	Pharmacy	A facility or location where drugs and
		other medically related items and
		services are sold, dispensed, or
		otherwise provided directly to patients.
02	Telehealth	The location where health services and
		health related services are provided or
		received, through a telecommunication
		system.
03	School	A facility whose primary purpose is
		education.
04	Homeless	A facility or location whose primary
	Shelter	purpose is to provide temporary
		housing to homeless individuals.
05	Indian	A facility or location, owned and
	Health Service	operated by the Indian Health Service
. . . to 99

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 FIG. 15 , the added elements 600 which add to the related FIG. 13 diagram show how Case 1 which is returned as a coupon response as described above may 601 also include place of service training content. Also, as shown at 603, additional guided conveyance forms may be sent back to the Software A 107 to help the Provider. Automated real time EV requests can also be used 602 instead of the selection of a button such as 133 to upload secondary services and coverage. The protocol can be designed to immediately and automatically be queried when the EV Request 403 is sent for primary coverage. Options can then be displayed.
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.


JSON Field	Reference Field	Required	Dats Type	Description

npi	pharmacy_info	true	string	Valid 10-digit NPI number of the
				pharmacy
bin	insurance_info	true	string	Valid 6 digit BIN
pcn	insurance_info	false	string	Valid PCN
group	insurance_info	false	string	Valid group
member_id	insurance_info	false	string	Valid member id
patient_copay	bv_info	false	number	The patient copay amount from
				the primary insurance
				adjudication
reject_codes	bv_info	false	object	For each reject code, there is a
				separate key value pair,
				consisting of reject code index,
				and the actual reject code: For
				example, the first reject code
				would be “1”:“70”. The third
				reject code would be “3”:“80”.
				The object can contain as few or
				as many elements as required by
				the claim (i.e. as many reject
				codes as are actually present).
first_name	patient_info	true	string	First name of the patient. Can
				only contain alphanumeric
				characters along with period and
				comma.
last_name	patient_info	true	string	Last name of the patient. Can
				only contain alphanumeric
				characters along with period and
				comma.
dob	patient_info	true	string	Date of birth of the patient.
				Format: YYYY-MM-DD
gender	patient_info	true	string	M—male, F—female
state	patient_info	true	string	Valid US state code
address1	prescriber_info	false	string	The prescriber's address
city	prescriber_info	false	string	The prescriber's city
firstname	prescnber_info	false	string	The prescriber's first name.
				Required if NPI is not provided.
				Can only contain alphanumeric
				characters along with period and
				comma.
lastname	prescriber_info	false	string	The prescriber's last name.
				Required if NPI is not provided.
				Can only contain alphanumeric
				characters along with period and
				comma.
npi	prescriber_info	true	string	Valid 10-digit NPI number of the
				prescriber
state	prescriber_info	false	string	Valid US state code
zip	prescriber_info	false	string	Valid US zip code
ndc	product_info	true	string	Valid 11-digit NDC code (without
				hyphens)
days_supply	product_info	true	string	Valid positive integer
number_of_refills	product_info	false	string	Valid positive integer
quantity	product_info	true	string	Valid positive integer
written_date	rx_info	false	string	Date the prescription was
				written. Format: YYYY-MM-DD

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 FIGS. 11-15 .
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.


		Data
JSON Field	Required	Type	Description

status_code	true	number	These are standard HTTP response
			codes.
success	true	boolean	Did the request pass the program
			rules' criteria?
message	true	string	This is the response message that
			will need to be returned in the
			NCPDP response, it will be no
			more than 1,000 characters long
			and should be transmitted
			using field 526-FQ (“Additional
			Message Information”)

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 110 b 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

What is claimed is:

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:

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.

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:

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 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.