Patent Publication Number: US-2022222751-A1

Title: Network-based marketplace service pricing tool for facilitating purchases of bundled services and products

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This is an International Application based on U.S. patent application Ser. No. 16/685,888 filed Nov. 15, 2019, which is a continuation-in-part of U.S. patent application Ser. No. 16/520,906 filed Jul. 24, 2019, which is a Continuation-in-part of U.S. patent application Ser. No. 15/055,076 filed Feb. 26, 2016, which is a continuation-in-part of U.S. Pat. No. 14,874,004 filed Oct. 2, 2015, which is a continuation of U.S. patent application Ser. No. 14/827,026 filed Aug. 14, 2015, which is a continuation-in-part of U.S. application Ser. No. 14/461,209 filed Aug. 15, 2014, issued Sep. 15, 2015, as U.S. Pat. No. 9,123,072, which claims the benefit of Provisional Application No. 61/866,922, filed Aug. 16, 2013. 
    
    
     BACKGROUND OF THE INVENTION 
     Exemplary embodiments of the present invention relate to the marketing and facilitating the sale of services and products. More specifically, exemplary embodiments relate to methods and apparatuses for providing a web-based mechanism allowing prospective patients to search for and compare healthcare services and products offered by local providers, including bundled sets of services, and facilitating prepaid purchases of such healthcare services and products by prospective patients at discounted rates. 
     The price of healthcare services varies depending on specialty, procedure, and physician practice. In the United States, many patients do not have access to a simple way to shop and compare the price of common medical procedures. Due to the current managed care based payor system in the US, the cost of treatment is often determined by managed care organizations. 
     These managed care organizations have specific formularies for drugs and procedures designed specifically to patients&#39; individual health plans, which restrict the drugs and procedures available to patients in their particular plans. Patients have historically had no access to these price lists or formularies and have had very few tools to assist them in finding and comparing health care services or predetermining the cost of a procedure. Currently prospective patients who chose to compare medical costs are forced to conduct extensive, often inefficient, and time consuming research to compare medical procedures prior to treatment. 
     The rising cost of healthcare is having a dramatic effect on the U.S. healthcare system. Healthcare costs continue to outpace pace inflationary growth, provider reimbursement rates continue to fall, and the cost of patient insurance premiums are increasing. To lower monthly premium costs, many patients are choosing to purchase (and employers are choosing to offer) high deductible health plans as an alternative to traditional higher premium PPO health plans. 
     These high deductible plans require patients to pay cash payments for medical services until the high deductible is satisfied, and once this deductible has been met, the insurance carrier begins to cover medical costs. As a result, many patients are seeing exponential increases in out-of-pocket expenses for medical procedures and services. In addition to more patients selecting high deductible plans, many patients cannot afford increased payments and are becoming uninsured or underinsured. As the number of patients who are uninsured, underinsured, or on high deductible plans grows, the need for a mechanism that allows patients to find discounted medical services increases and an efficient payment system. 
     SUMMARY OF THE INVENTION 
     Exemplary embodiments of the present invention are related to an apparatus for facilitating purchases of services offered by service providers. The apparatus includes an application server providing a network service that is accessible to a plurality of users through a plurality of client systems communicatively coupled to the application server via a network and a data storage system storing a service offer database that is maintained by the application server. 
     The service offer database comprises a plurality of service offer information records respectively associated with a plurality of service offers. The plurality of service offers includes at least one service offer for a bundled set of services. Each service offer information record comprises an indication of a primary service of the associated service offer, a purchase price for the associated service offer, a payment amount for the primary service, and compensation information for the primary service. Upon receiving purchase information for the user for purchasing the selected service offer from the client system, the network service is operable to issue a request to the funding source for funds corresponding to the purchase price included in the service offer information record associated with the selected service offer to process a purchase of the selected service offer by the user. 
     In exemplary embodiments, each service offer for a bundled set of services comprises a bundled set of healthcare services provided by corresponding healthcare service providers. 
     In exemplary embodiments, at least one service offer information record associated with a service offer for a bundled set of services further comprises an indication of a facility for performing the primary service, a facility fee for the facility, and compensation information for the facility fee. 
     In exemplary embodiments, at least one service offer information record associated with a service offer for a bundled set of services further comprises an indication that at least one of the secondary services associated with the primary service is an optional secondary service. 
     In exemplary embodiments, the data storage system stores a profile database that is maintained by the application server. The profile database comprises a respective account information record for each of a plurality of user accounts registered with the application server. The plurality of user accounts includes a plurality of customer accounts and a plurality of provider accounts. The account information record for each user account comprising information for authorizing a user accessing the network service from one of the client systems to access the network service in association with the user account. 
     In exemplary embodiments, the plurality of provider accounts includes a plurality of physician accounts and a plurality of practice group accounts, the account information record for each practice group account comprises an indication of one or more of the physician accounts being affiliated with the practice group account. 
     In exemplary embodiments, the data storage system stores a transaction information database that is maintained by the application server. The transaction information database comprises a respective purchase information record for each processed purchase, by a user accessing the network service from one of the client systems in association with a customer account, of a service offer that has been created by a user accessing the network service from one of the client systems in association with a provider account, the respective purchase information record for each processed purchase comprising an indication of the service offer information record associated with the purchased service offer and, for each of the primary service and any secondary service of the service offer, and an indication of whether the purchase has been redeemed with respect to the service. 
     In exemplary embodiments, the network service, upon being accessed by a user of one of the client systems to process a purchase of a service offer, generates a voucher for the user that specifies a unique confirmation number for the purchase and the corresponding service provider for each of the primary service and any secondary service of the purchased service offer, and, for each of the primary service and any secondary service of the purchased service offer, sets the purchase information record for the processed purchase to indicate that the purchase has not been redeemed with respect to the service. 
     Exemplary embodiments of the present invention that are related to computer-implemented processes and computer systems corresponding to the above-summarized exemplary embodiments directed to an apparatus are also described and claimed herein. 
     The above-described and other features and advantages realized through the techniques of the present disclosure will be better appreciated and understood with reference to the following detailed description, drawings, and appended claims. Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The subject matter that is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description of exemplary embodiments of the present invention taken in conjunction with the accompanying drawings in which: 
         FIG. 1  is a schematic diagram illustrating an example network architecture for a healthcare marketplace system that can be configured to implement exemplary embodiments of the present invention. 
         FIG. 2  is a block diagram illustrating a server system in accordance with an exemplary embodiment of the present invention. 
         FIGS. 3A-3D  are a number of screen shots illustrating examples of a graphical user interfaces that may be implemented by services provided within a customer portal in accordance with exemplary embodiments of the present invention. 
         FIG. 4A  is an illustration of an example voucher that may be generated within a user interface by functions provided within a customer portal for a purchased service in accordance with exemplary embodiments of the present invention. 
         FIG. 4B  is an illustration of an example voucher that may be generated within a user interface by functions provided within a customer portal for a purchased service that is offered as a bundled set of services in accordance with exemplary embodiments of the present invention. 
         FIG. 5  is a block diagram of an exemplary computer system that can be used for implementing exemplary embodiments of the present invention. 
         FIG. 6  is a schematic diagram illustrating a second example network architecture for a healthcare marketplace system that can be configured to implement exemplary embodiments of the present invention; and 
         FIGS. 7A-7C  are a number of screen shots illustrating examples of a graphical user interfaces that may be implemented by services provided within a provider portal in accordance with exemplary embodiments of the present invention. 
         FIG. 8  illustrates a flow chart of an insurance policy stored in the insurance database executed by the application server in accordance with exemplary embodiments of the present invention. 
         FIG. 9  illustrates a block diagram of a virtual payment system manager communicating with client system in a healthcare marketplace system. 
         FIG. 10  illustrates a block diagram of the application server showing deductible checker, shopping cart, and drug discounted card in accordance with another embodiment of the present invention. 
     
    
    
     The detailed description explains exemplary embodiments of the present invention, together with advantages and features, by way of example with reference to the drawings, in which similar numbers refer to similar parts throughout the drawings. The flow diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted, or modified. All of these variations are considered to be within the scope of the claimed invention. 
     DETAILED DESCRIPTION 
     While the specification concludes with claims defining the features of the invention that are regarded as novel, it is believed that the invention will be better understood from a consideration of the description of exemplary embodiments in conjunction with drawings. It is of course to be understood that the embodiments described herein are merely exemplary of the invention, which can be embodied in various forms. Therefore, specific structural and functional details disclosed in relation to the exemplary embodiments described herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention in virtually any appropriate form, and it will be apparent to those skilled in the art that the present invention may be practiced without these specific details. Further, the terms and phrases used herein are not intended to be limiting but rather to provide an understandable description of the invention. 
     Exemplary embodiments of a transactional marketplace system in accordance with the present invention will now be described with reference to the drawings. Exemplary embodiments of the present invention may be implemented to provide healthcare service providers and pharmacies with a mechanism to remotely offer healthcare services and products to prospective patients at discounted rates in exchange for prepayment of the costs for the services and products via a network-based application (for example, a web-based application). 
     In this regard, exemplary embodiments may further be implemented to provide prospective patients with a mechanism to remotely search, compare, and make pre-paid purchases of such healthcare services and products offered by local medical service providers and pharmacies via a network-connected device configured to access the network-based application. Exemplary embodiments may be further implemented to provide healthcare service providers with the ability to remotely offer a bundled set of healthcare services that are performed separately by multiple providers to prospective patients through such a network-based mechanism in which the patient is provided the opportunity to make a prepaid purchase of such a bundled set of services in a single transaction via the network-connected device, whereby the network-based application facilitates a disbursed distribution of the payment among the multiple healthcare service providers that perform services included in the bundled set of services. 
     Exemplary embodiments may also be further implemented to provide a virtual payment system for facilitating and accounting for the exchange of payment for services and products purchased by (or otherwise on behalf of) patients and offered by healthcare providers via the transactional marketplace system in which a respective virtual money account is established and utilized for each participant in transactions conducted within the marketplace system to manage and track the process of exchanging actual currency and/or credits used to pay for the transactions through the use of corresponding virtual funds created within the virtual payment system. 
     In such exemplary embodiments, the virtual funds may be allocated and distributed to, exchanged among, and redeemed for corresponding amounts of actual currency by various participants to each transaction for which payment is facilitated through the virtual payment system, and the participants to transactions within the virtual payment system for which respective virtual money accounts are established and utilized may include, in addition to patients, healthcare providers, or other entities specified for receiving payments for services or products offered through the marketplace system, third party payers, and an entity that provides the transactional marketplace system. 
     Exemplary embodiments may be further implemented to provide various types of healthcare service providers, which may include individual physicians, practice groups, and hospital systems, with the ability to establish affiliations with one another through such a network-based mechanism and provide various options allowing the service providers to remotely offer healthcare services in association with these affiliations. 
     It should further be noted that various aspects of exemplary embodiments of the present invention described herein are not limited to healthcare services (also referred to herein as procedures) and products but, rather, may be implemented with respect to any suitable classes and types of services and products that may be offered by any suitable classes and types of service providers and retailers. 
     Referring now to  FIG. 1 , a schematic diagram illustrating an example network architecture for a healthcare marketplace system  100  that can be configured to implement exemplary embodiments of the present invention is provided. It should of course be understood that  FIG. 1  is intended as an example, not as an architectural limitation for different embodiments of the present invention, and therefore, the particular elements depicted in  FIG. 1  should not be considered limiting with regard to the environments within which exemplary embodiments of the present invention may be implemented. 
     In the example illustrated in  FIG. 1 , healthcare marketplace system  100  is implemented as a client/server system that includes a central server system  110  that is commonly accessed by each user of the system through operation of any of a plurality of client systems  140  that are operatively coupled to the central server system via a communication network  150 . Central server system  110  further includes a database server  112  that is coupled to a data store  114  and an application server  116 , and each client system  140  is a user terminal or other client device implementing software for and running a respective client application  142  for accessing services provided via a network-based application (also referred to herein as a network service) implemented by application server  116 . 
     As further illustrated, exemplary marketplace system  100  may also include at least one third-party server system  160  to enable other functionality that may be accessed and utilized by server system  110  to provide and/or enhance the network service discussed herein. In exemplary embodiments, marketplace system  100  can include additional servers, clients, and other devices not shown in  FIG. 1 . The particular architecture depicted in  FIG. 1  is provided as an example for illustrative purposes and, in exemplary embodiments, any number of client systems  140  may be connected to server system  110  at any given time via network  150 , and server system  110  can comprise multiple server components and databases located within a single server system or within multiple server systems, where the multiple server systems are integrated with or accessible by users of client systems  140  as a distributed server system via network  150 . 
     In exemplary embodiments, network  150  can be configured to facilitate communications between server system  110  and client systems  140 , as well as communications with and between other devices and computers connected together within marketplace system  100 , by any suitable wired (including optical fiber), wireless technology, or any suitable combination thereof, including, but not limited to, personal area networks (PANs), local area networks (LANs), wireless networks, wide-area networks (WAN), the Internet (a network of heterogeneous networks using the Internet Protocol, IP), and virtual private networks, and the network may also utilize any suitable hardware, software, and firmware technology to connect devices such as, for example, optical fiber, Ethernet, ISDN (Integrated Services Digital Network), T-1 or T-3 link, FDDI (Fiber Distributed Data Network), cable or wireless LMDS network, Wireless LAN, Wireless PAN (for example, IrDA, Bluetooth, Wireless USB, Z-Wave and ZigBee), HomePNA, Power line communication, or telephone line network. Such a network connection can include intranets, extranets, and the Internet, may contain any number of network infrastructure elements including routers, switches, gateways, etc., can comprise a circuit switched network, such as the Public Service Telephone Network (PSTN), a packet switched network, such as the global Internet, a private WAN or LAN, a telecommunications network, a broadcast network, or a point-to-point network, and may utilize a variety of networking protocols now available or later developed including, but not limited to the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols for communication. 
     In exemplary embodiments, application server  116 , database server  112 , and any other servers employed within server system  110  and third-party servers utilized within marketplace system  100  can be implemented within any suitable computing system or systems such as a workstation computer, a mainframe computer, a server system (for example, SUN ULTRA workstations running the SUN operating system, IBM RS/6000 workstations and servers running the AIX operating system, or an IBM zSeries eServer running z/OS, zNM, or LINUX OS), a server cluster, a distributed computing system, a cloud based computing system, or the like, as well as any of the various types of computing systems and devices described below with reference to the client systems  140 . Server system  110  may be implemented using any of a variety of architectures. For example, application server  116  and database server  112  may also be implemented independently or as a single, integrated device. While the exemplary embodiment illustrated in  FIG. 1  depicts application server  116  and database server  112  as individual components, the applications provided by these servers, or various combinations of these applications, may actually be server applications running on separate physical devices. In this regard, server system  110  may comprise a number of computers connected together via a network and, therefore, may exist as multiple separate logical and/or physical units, and/or as multiple servers acting in concert or independently, wherein each server may be comprised of multiple separate logical and/or physical units. In exemplary embodiments, server system  110  can be connected to network  150  through a collection of suitable security appliances, which may be implemented in hardware, software, or a combination of hardware and software. 
     As illustrated in  FIG. 1 , application server  116  is communicatively coupled to database server  112 . Database server  112  is connected to data store  114 , which comprises a plurality of databases that are maintained by database server  112 , accessed by application server  116  via database services provided at a front end by database server  112 , and store information on a variety of matters that is utilized in providing the services offered via the network service provided by the application server, as described below in greater detail. 
     The machine learning algorithm  15  instructs the service offer database  114   h  to store each healthcare service provider service corresponding to the user selection and displays the bundled set of service offers via the graphical user interface/provider portal  130  that matches the users&#39; selection. 
     Any machine-learning algorithm  15  can be employed, such as neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines and the like. The system may also employ combinations of various artificial intelligence techniques to the service offer database  114   h.    
     The machine learning algorithm  15  takes into account of each and every parameter of user inputs such as type of disease, location, expertise, procedures, hospitals, pricing etc. Thus, the machine learning algorithm  15  displays the best results/hits based on the inputs and preferences of the user. 
     As used herein, the term “data store,” “data storage unit,” storage device”, and the like can to any suitable memory device that may be used for storing data, including manual files, machine-readable files, and databases. In exemplary embodiments, application server  116 , database server  112 , and data store  114  may have implemented together a single computing device, implemented within a plurality of computing devices locally coupled to each other via a suitable communication medium, such as a serial port cable, telephone line or wireless frequency transceiver, implemented within a plurality of computing devices remotely coupled to each other via network  150 , or any suitable combination thereof. 
     Client systems  140  are computer devices to which one or more users, which may be healthcare providers offering services or products or patients seeking to purchase healthcare services or products, or their human agents (for example, personal representatives or assistants), have access. It should be noted that the term “user” is used herein to refer to one who uses a computer system, such as one of client systems  140 . As described in greater detail below, client systems  140  are each operable by such users to access server system  110  via network  150  and act as clients to access services offered by the network service provided by the server system within exemplary marketplace system  100 . For this purpose, each client system includes a respective client application  142  that executes on the client system and allows a user to interact with server system  110  via application server  116 . 
     In exemplary embodiments, the computer systems of client systems  140  can be any of a wide range of suitable computing devices such as one or more workstations, desktop computers, laptops, or other personal computers (PCs) (for example, IBM or compatible PC workstations running the MICROSOFT WINDOWS operating system or LINUX OS, MACINTOSH computers running the MAC OSX operating system, or equivalent), non-traditional-computer digital devices such as Personal Digital Assistants (PDAs) and other handheld or portable electronic devices, smart phones and other mobile handsets, tablet computers, netbook computers, game consoles, home theater PCs, desktop replacement computers, and the like, or any other suitable information processing devices. An exemplary computer system for client systems  140  is described in greater detail below with reference to  FIG. 5 . 
     In general, during operation of exemplary marketplace system  100 , a client system  140  first establishes a connection to server system  110  via network  150 . Once the connection has been established, the connected client system may directly or indirectly transmit data to and access content from the application server  116 . A user accessing application server  116  through the connected client system can thereby to use a client application  142  to access services provided by the application server, which are described in greater detail below, via a user interface implemented by the client application within which the client application renders the information served by the application server. 
     In exemplary embodiments, application server  116  can implement network service as a non-web client application (such as a mobile application), a web client application, or both to provide the services accessed by client systems  140  within server system  110 , and client applications  142  can correspondingly be implemented as non-web client applications, web client applications, or both for operation by users of the client systems to interact with application server  116  and access the services provided thereby. For example, application server  116  can comprise a web server configured to provide a web application for the respective client applications implemented on client systems  140  that are configured to provide web-based user interfaces for utilizing the services provided by the web server. For instance, the user interfaces of client applications implemented on client systems  140  can be configured to provide various options corresponding to the functionality offered in exemplary embodiments described herein through suitable user interface controls (for example, by way of menu selection, point-and-click, dialog box, or keyboard command). In one general example, the user interfaces may provide “send” or “submit” buttons that allow users of client applications to transmit requested information to application server  116 . The user interfaces can be implemented, for example, as a graphical user interface (GUI) that renders a common display structure to represent the network service provided by application server  116  for a user of a client platform. 
     More specifically, in such an example, application server  116  can, for example, be configured to provide services via a web-based software application hosting a corresponding website that includes a number of web pages (e.g., screens), and client applications  142  can comprise a web browser executing on client systems  140 , such that the services provided by application server  116  are accessible to client systems  114  using the Internet or an intranet. Users of client systems  140  may thereby access the website provided by application server  116  by, for example, inputting or following a link to the uniform resource locator (URL) for the website in the web browser, which then enable users to display and interact with information, media, and other content embedded within the web pages of the website provided by application server  116 . The web-based software application can transmit information that can be processed by the web browsers to render a user interface using, for example, a browser-supported programming languages such as JavaScript, HTML, HTML5, and CSS, or the like, and can communicate with the web browsers using, for example, HTTPS. POST and/or GET requests. Client applications  142  and application server  116  may be configured so that information transmitted between client systems  140  and server system  110  can be encrypted and sent over a secure network connection to protect, for example, patient privacy. 
     Referring now to  FIG. 2 , a block diagram illustrating an exemplary embodiment of server system  110  is provided. As illustrated in  FIG. 2 , application server  116  is implemented to provide a plurality of services via a customer portal  120  and a plurality of services via a provider portal  130 . As described herein, application server  116  can be implemented to provide a respective set services for each of various types of users (for example, unregistered guests, customers, individual physicians, nurses, office staff, practice group administrators, hospital system administrators, pharmacy administrators, and the like), and some of the services offered by application server  116  can be commonly applicable to and accessible by all types of users, while other services can be applicable to and accessible only by specific types of users. 
     For purposes of description, the terms “providers” and “provider users” are used herein to refer to the general class of users that register with the system offer healthcare services or products for purchase by customer users registered with the system, which can include individual physician users, practice group administrators, hospital system administrators, pharmacy administrators, and the like. In addition, a user account for a particular provider can have any number of authorized users. As an example, an account established for a physician can have the physician as one of its users. It can also have nurses or office staff working for the physician as other authorized users. The other authorized users can log into the account and perform various actions with the permission and under the supervision of the physician. 
     A single hospital system account may be established and shared by multiple staff member&#39;s hospital system. For purpose of illustration, there can be a designated user (for example, an account administrator) who is responsible for managing the account. The administrator can be provided with greater access rights within server system  110  with respect to the account. In exemplary embodiments, the particular client applications  142  or the particular client systems  140  that are utilized for accessing application server  116  can be respective to and customized for each type of user account. For example, the particular client application that is utilized for each type of account can be implemented to a provide virtual computing platform that is specific to the services offered for that type of account. 
     As further illustrated in exemplary embodiment of  FIG. 2 , and as will also be described in greater detail below, data store  114  comprises a plurality of databases that are maintained and accessible by application server  116  via database server  112 , including a customer profile database  114   a , a physician profile database  114   b , a practice group profile database  114   c , a hospital system profile database  114   d , a pharmacy profile database  114   e , a condition information database  114   f , an available services database  114   g , a service offer database  114   h , an available products database  114   i , a product offer database  114   j , a transaction information database  114   k , and one or more additional databases  1141  that may be used for storing any other suitable information that may be utilized by server system  110  (for example, system usage data, audit trail data, data used internally within the system by application server  116 , and the like). 
     The customer profile database  114   a  is configured to register users thereby providing user&#39;s personal information for purchasing healthcare services. The physician profile database  114   b  is configured to register and maintain records of individual physician offering healthcare services. The condition information database  114   f  is configured to register and maintain information records for various health conditions and diseases for which corresponding healthcare services are offered. 
     The hospital system profile database  114   d  is configured to register and maintain account information records for hospital system administrators providing pre-paid healthcare services. The available service database  114   g  is configured to register and maintain records of various healthcare services offered by at least one of: a physician; and a hospital. The transaction information database  114   k  is configured to maintain records of purchases made by registered users. 
       FIG. 3A  is a screen shot illustrating an example of a graphical user interface provided by such a home page  300  for customer portal  120 . In the illustrated example, the search interface provided at home page  300  can include a drop-down menu  302 , a search entry field  304 , a location entry field  306 , and a search button  308 . Drop-down menu  302  provides a set of selectable options that allow the user to search for particular procedures offered by provider users registered with the system, particular products offered by pharmacy users registered with the system, information on providers registered with the system, and information on health conditions that is maintained within system. In exemplary embodiments, navigation and search service  124  can be configured to use location information that may be gathered by any suitable location determining functionality implemented on the client system to provide a default location entry (for instance, city name and/or zip code) within location entry field  306 . In such embodiments, navigation and search service  124  may be further configured to request permission from the user via the user interface to be able to access and utilize such location information for this purpose. 
     In one example, when the user selects the option within drop-down menu  302  to search for a particular service offered by provider users registered with the system, the user can then proceed to enter the name of the service within search entry field  304 . In conjunction with selecting the particular service, the user can also enter a city name and/or zip code or opt to utilize a default location entry within location entry field  306  to localize a search radius for providers offering the selected service for purchase via marketplace system  100 . 
     Once the appropriate search information is entered, the user can then select the search button to direct navigation and search service  124  to conduct a search of local providers registered with server system  110  and offering the inputted healthcare service for purchase via marketplace system  100 . Navigation and search service  124  can conduct such a location-based search by accessing, for example, service offer database  114   h  in conjunction with physician profile database  114   b , practice group profile database  114   c , hospital system profile database  114   d , and/or any other suitable information and databases to which the application server has access to filter the information records included within available services database  114   g  for healthcare services that match the specified search criteria, and then present the results of the search to user within a search result listing page. 
     In exemplary embodiments, whenever navigation and search service  124  is directed to conduct a location-based search by a user (for example, for local providers offering the inputted healthcare service or, as discussed below, for local providers generally or for local pharmacy providers offering healthcare products), the navigation and search service can be configured to maintain the location specified within location entry field  306  for search within a data object for a session with application server  116  that is maintained for the user. 
       FIG. 3B  is a screen shot illustrating an example of a GUT provided by a search result listing page  310  for customer portal  120  that presents a list of providers offering the service specified within search entry field  304  within a default search radius (for example, 50 miles) of the location specified within location entry field  306  returned in the search conducted by navigation and search service  124 . In the illustrated example, search result listing page  310  includes a result listing section  311 , a result filtering section  316 , and a result sorting section  318 . Result filtering section  316  provides various user interface controls for refining the results of the search presented within result listing section  311  by modifying the search criteria or inputting additional search criteria. In the illustrated example, result filtering section 
     In the example screen shot depicted in  FIG. 3B , each entry for an offered service listed in result listing section  311  includes a first portion  312  presenting information from the account information record within physician profile database  114   b  of the physician that will perform the service as specified in the information record for the offered service within service offer database  114   h  (for example, the physician&#39;s name, specialty, and profile picture), a second portion  313  presenting information from the account information record of the provider that is offering the service through the system (for example, provider name) and the location at which the offered service will be performed (for example, address and telephone number), and a third portion  314  presenting cost information for purchasing the offered service through application server  116  (for example, the discounted price for the service that is specified in the information record for the offered service within service offer database  114   h  and a cost savings difference between the discounted price and the regular price for the service when the service is purchased outside of the system from the provider as specified in the information record for the offered service within service offer database  114   h ), and an option to select to purchase the offered service listed in the entry (for example, via an “Add to Cart” button included within third portion  314 ). 
     Referring now to  FIG. 3C , a screen shot illustrating an example of a GUI provided by a healthcare service information page  320  implemented by navigation and search service  124  for a particular healthcare service is provided. In the illustrated example, healthcare service information page  320  includes a procedure overview section  322 , a cost comparison graphic  324 , and a provider listing section  326 . 
     In exemplary embodiments, as further illustrated in  FIG. 3D , physician information section  332  can further include additional user interface elements such as a “Leave a review” button  333 , a “Request an appointment” button  334 , and a map element  335  depicting a mapped location of an office location included within respective account information record that is maintained for the particular physician user in physician profile database  114   b  (which navigation and search service  124  may be configured to generate by remotely accessing a third-party mapping service). In response to a user selecting “Leave a review” button  333 , navigation and search service  124  can be configured to implement suitable user interface controls for allowing the user to post or submit a review of the particular physician to server system  110 . In response to receiving such a review, navigation and search service  124  can be configured to, for example, include information pertaining to the review within the respective account information record that is maintained for the particular physician user in physician profile database  114   b  or send an electronic message to the physician user pertaining to the review, for example, by way of email utilizing the contact information specified in the respective account information record for the physician. 
     In response to a user selecting “Request an appointment” button  334 , navigation and search service  124  can be configured to implement suitable user interface controls for allowing the user to submit a request for scheduling an appointment to the particular physician user (for example, by sending a notification to the physician user by utilizing the contact information specified in the respective account information record for the physician that includes contact information for the user). Navigation and search service  124  may also be configured to implement suitable user interface controls for allowing the user to schedule an appointment with the particular physician user. Navigation and search service  124  may provide this functionality by, for example, accessing a service with which the particular physician user is associated, which may be a service offered by application server  116  or offered by a third-party service provider. 
     In the present example, as illustrated in  FIG. 3D , the information presented in offered procedures section  336  of physician profile page  330  can include a listing of healthcare services offered by the particular physician for purchase through marketplace system  100 . 
     In exemplary embodiments, the user interface implemented by account management service  122  may be further configured to provide user interface controls for requesting authorization for payment of a predetermined fee to gain access to the ability to make prepaid purchases of healthcare services and products offered within marketplace system  100 . The payment information input by the user may be an instruction to use the billing information included within the respective account information record established for the user within customer profile database  114   a  or submission of alternative payment information such as, for example, bank account information, credit or debit card information, or other electronic payment information (such as information for utilizing an account the user has with PayPal or any another entity facilitating payments and money transfers to be made through the Internet), which may be for an account maintained for the user or an account maintained for another person or entity that the user is authorized to utilize for this purpose. 
     Account management service  122  can be configured to, upon the authorization and appropriate payment information being provided by the user, access a corresponding third-party payment servicing system and utilize the payment information to direct the payment servicing system to transfer the amount for the payment authorized by the user from the account servicer of the user to a financial account maintained by the providers of marketplace system  100 . In this regard, the respective account information record established for the user within customer profile database  114   a  can further include an account status that is managed by account management service  122  for the user indicating whether the user is presently provided with the ability to make prepaid purchases of healthcare services and products offered within marketplace system  100 . 
     Upon a user registering a customer account with server system  110  to establish an account information record within customer profile database  114   a  and logging into his or her customer account (for example, by accessing a login user interface element or a login screen within the user interface implemented by customer portal  120  to provide the user name and password associated with the account), the user then proceeds with purchasing any offered service or product for which the session data object for the session with application server  116  that is being maintained for the user includes an indication that the user has selected for purchasing. For example, upon the user selecting an option within the user interface implemented by navigation and search services  124  to navigate to a customer purchase page and initiate a purchasing session with purchasing service  126  to purchase one or more of the offered items indicated as having been selected by the user in the session data object in association with the registered customer account for the user. 
     The purchase information section included within the user interface implemented for the payment page may further include a total price for the purchase that is equal to a sum of the respective price for purchasing the corresponding offered item included for each entry included in the purchasing information section. In exemplary embodiments, purchasing service  126  may be configured to adjust the total price based on any applicable state taxes or any discount codes submitted by the user. In this regard, purchasing service  126  may be further implemented to provide a user interface element allowing a user to submit any application discount codes to application server  116 . 
     For this purpose, the user interface controls implemented within a payment section may include a button that is accessible by the user to provide authorization for the request to be issued to the specified funding source (for example, a “Submit” or “Purchase” button) along suitable user interface elements accessible by the user to input the purchase information specifying the funding source to use for the purchase. The purchase information input by the user may be an instruction to use the billing information included within the respective account information record for the customer account of the user within customer profile database  114   a  or submission of alternative purchase information such as, for example, bank account information, credit or debit card information, or other electronic payment information (such as information for utilizing an account the user has with PayPal or any another entity facilitating payments and money transfers to be made through the Internet). The purchase information may, for example, specify an account maintained for the user, an account maintained for another person or entity that the user is authorized to utilize for this purpose, or an entity that has arranged to be invoiced and provide reimbursement for purchases of healthcare services and products made by the user within marketplace system  100 . 
     Purchasing server  126  can also be configured to, upon processing the payment for the purchase of the offered service, generate a voucher for the customer user within the user interface for the purchased service that can be utilized by the customer user to redeem the purchase and receive the service from the physician specified for the offered service (the providers of marketplace system  100  can have pre-arranged agreements with providers registered with the system that the providers will agree to honor such vouchers generated by purchasing server  126  for purchased services). An example of such a voucher is illustrated in  FIG. 4A . As depicted in the example, example voucher  400  can be generated to include identifying information for the customer user  402 , identifying and contact information for the physician specified for the offered service  404 , a description of the purchased service  406 , a confirmation number  408  for the purchase, which may be generated by purchasing server  126  based on the unique transaction identifier that is included in the respective information record for the purchase that is maintained within transaction information database  114   k , and instructions for redeeming the voucher  410 . The confirmation number may also be provided in the electronic confirmation message to the customer user and electronic notifications to the physician user that will be performing the service and the provider user for the offered service sent by purchasing system  126  to the customer user. The voucher can be presented to the user within the user interface, for example, as printable and/or machine readable form. 
     Purchasing server  126  can be configured to, upon processing the payment for the purchase of the offered service that is being offered as a primary service in conjunction with a bundled set of services, navigate the user interface to a purchase confirmation page and send an electronic confirmation message to the customer user and electronic notifications to each physician that will perform a service of the bundled set of services and the provider user for the offered service (as specified according to the information record for the offered service within service offer database  114   h ), for example, by way of email utilizing the contact information specified in the respective account information records for the customer, the physicians, and the provider for the offered service. Purchasing server  126  can be also be configured to generate a respective information record for the completed purchase with corresponding information within transaction information database  114   k , which initially indicates that the purchase has not yet been redeemed with respect to the primary service, each secondary service, and any facility specified for the purchased offered service. 
     Purchasing server  126  can also be configured to, upon processing the payment for the purchase of the offered service that is being offered as a primary service in conjunction with a bundled set of services, generate a voucher for the customer user within the user interface for the purchased service that can be utilized by the customer user to redeem the purchase and receive the service from the corresponding physician specified for each of the services of the bundled set of services (the providers of marketplace system  100  can have pre-arranged agreements with providers registered with the system that the providers will agree to honor such vouchers generated by purchasing server  126  for purchased services). An example of such a voucher for a bundled set of services is illustrated in  FIG. 4B . As depicted in the example, example voucher  400  can be generated to include identifying information for the customer user  402 , identifying and contact information for each physician specified for a service and any facility included in the offered service  404 , a description of each service of the purchased service  406 , a confirmation number  408  for the purchase, which may be generated by purchasing server  126  based on the unique transaction identifier that is included in the respective information record for the purchase that is maintained within transaction information database  114   k , and instructions for redeeming the voucher  410 . The confirmation number (or any other suitable redemption information such as a one or two dimensional bar code, a QR code, or any other form of machine readable information) may also be provided in the electronic confirmation message to the customer user and electronic notifications to the physician user that will be performing the service and the provider user for the offered service sent by purchasing system  126  to the customer user. The voucher can be presented to the user within the user interface, for example, as printable and/or machine readable form. 
     Upon the user indicating an intention to register as a physician user, the user will be able to initiate a registration session with account management service  131  to register a physician account with server system  110 . Account management service  131  may be configured, for example, to implement a user interface that includes a series of pages with user interface controls accessible by the user to guide the user through the account registration process and prompt the user to input various types of information or media to be maintained by database server  112  within a respective account information record that is established for the user within physician profile database  114   b  such as, for example, name, practice specialty, office location(s) and hours, a profile picture, contact information (such as an email address and/or a telephone number), biographical information (such as awards, honors, publications, patient testimonials, and other information that can be helpful for marketing the physician to customers accessing the system), URLs or references to websites and social media profiles, compensation information (indicating a financial account for receiving payment for purchases of services offered by the physician via the system), information pertaining to outside facilities that are used for particular services performed by the physician (for example, information pertaining to particular hospitals or clinics such as name, address, contact information, facility fee, and compensation information indicating a financial account that is used by the facility for receiving a facility fee), and any other suitable identifying or descriptive information. The user interface may also be implemented by account management service  131  to prompt the user for any group affiliation codes or hospital affiliation codes. 
     Procedure management service  133  may be configured, for example, to implement a user interface that includes a series of pages with user interface controls accessible by the user to guide the user through the service offering process and prompt the user to input various types of information to be maintained by database server  112  within a respective information record that is established in association with the unique physician account identifier for the physician within service offer database  114   h . For example, the user may be provided with a drop-down menu providing a list of selectable medical specialties and, upon selecting a particular medical specialty, the user can be presented with a list of selectable healthcare services for which an information record for the service is maintained within available services database  114   g  in association with the specialty. 
     Upon the user indicating an intention to request payment for a purchased service that have been performed (for example, by selecting a “Voucher Processing” tab within the physician account page implemented by provider portal  130 ), the user will be able to initiate a voucher processing session with transaction processing service  136 . In particular, transaction processing service  136  may be configured, for example, to implement a voucher history page within the user interface that presents information relevant to the physician user for a list of purchases for which the respective information record for the purchase that is maintained within transaction information database  114   k  includes the unique physician account identifier for the physician user within physician profile database  114   b  as the physician user that is designated as performing a service included the purchase (for example, a primary or secondary service for a bundled set of services). The relevant information for each listed purchase may include, for example, the voucher confirmation number or redemption code, name and contact information for the customer user, a description of the service the physician user is designated as performing for the purchase, a purchase date, and a voucher redemption status. Such a voucher history page may also be accessed in association with the user account for the physician user to verify vouchers presented customers requesting to have a service performed in association with a voucher. 
     The voucher history page can also provide a user interface element in association with each of the listed purchases for which the voucher redemption status for the service the physician user is designated as performing indicates the service has not been performed that is accessible by the physician user to submit a verification to application server  116  that the physician user has performed the service for the customer user in accordance with the purchase. 
     Referring again to  FIG. 2 , in exemplary embodiments, when a user operating a client system to access application server  116  via a corresponding client application executing on the client system initiates a registration with server system  110  and specifies an intention to register as a practice group administrator (for example, via a user interface element on any page implemented by navigation and search service  124 ), the user will be able to initiate a registration session with account management service  131  to register a practice group account with server system  110 . Account management service  131  may be configured, for example, to implement a user interface that includes a series of pages with user interface controls accessible by the user to guide the user through the account registration process and prompt the user to input various types of information or media to be maintained by database server  112  within a respective account information record that is established for the user within practice group profile database  114   c  such as, for example, practice group name, location and hours, contact information (such as an email address and/or a telephone number), URLs or references to websites and social media profiles for the practice group, information pertaining to outside facilities that are used for particular procedures by physicians affiliated with the practice group, (for example, information pertaining to particular hospitals or clinics such as name, address, contact information, facility fee, and compensation information indicating a financial account that is used by the facility for receiving a facility fee), compensation information (indicating a financial account for receiving payment for purchases of services that are performed by affiliated physicians via the system), and any other suitable identifying or descriptive information. 
     The voucher history page can also provide a user interface element in association with each of the listed purchases for which the voucher redemption status for the service indicates the service has not been performed that is accessible by the practice group user to submit a verification to application server  116  that the affiliated physician user specified as performing the service has performed the service for the customer user in accordance with the purchase. 
     In exemplary embodiments, when a user operating a client system to access application server  116  via a corresponding client application executing on the client system initiates a registration with server system  110  and specifies an intention to register as a hospital system administrator (for example, via a user interface element on any page implemented by navigation and search service  124 ), the user will be able to initiate a registration session with account management service  131  to register a hospital system account with server system  110 . Account management service  131  may be configured, for example, to implement a user interface that includes a series of pages with user interface controls accessible by the user to guide the user through the account registration process and prompt the user to input various types of information or media to be maintained by database server  112  within a respective account information record that is established for the user within hospital system profile database  114   d  such as, for example, contact information (such as an email address and/or a telephone number), information pertaining to outside facilities that can be used for particular procedures by physicians affiliated with the hospital system (for example, information pertaining to particular hospitals or clinics such as name, address, contact information, facility fee, and compensation information indicating a financial account for that is used by the facility for receiving a facility fee), compensation information (indicating a financial account for receiving payment for purchases of services performed by affiliated physicians via the system), and any other suitable identifying or descriptive information. 
     In exemplary embodiments, the functionality that is provided within provider portal  130  for users of hospital system accounts can vary in certain respects from the functionality that may be provided within provider portal  130  for users of practice group accounts. For example, with respect to physicians that are affiliated with the hospital system account, users of hospital system accounts may only be provided with access rights (for example, to view, modify, and specify in a service being offered by the hospital system for purchase) to services offered for purchase by affiliated physician users that have been specified by the physician users as being hospital procedures with respect to the physician accounts. Hospital system users may also be provided with functionality to, as an alternative to selecting a service by accessing a list of selectable medical specialties when initiating a service offering with procedure management service  133  to offer a service performed by affiliated physicians for purchase via server system  110 , submit a search query for a service by inputting descriptive terms or a medical code number that is used to identify the service (for example, according to the CPT code set) or access a list of affiliated physicians and, upon selecting a particular affiliated physician from the list, be presented with a list of selectable healthcare services for which an information record for the service is maintained within service offer database  114   h  that indicates the selected physician as the physician that will perform the service. 
     In addition, because a hospital system may be more likely to offer a higher quantity of services for purchase as a bundled set of services within marketplace system  100  than other types of provider users, the functionality implemented by provider portal  130  within the user interface for allowing a user of a hospital system account to manage information pertaining to services offered by the hospital system for purchase and to view a history of transactions performed for services offered for purchase by the hospital system within server system  110  may include an additional user interface element that is accessible by a user for the hospital system account manage and view information pertaining to only services that are offered by the hospital system as a bundled set of services 
       FIG. 5  is a block diagram of an exemplary computer system  600  that can be used for implementing exemplary embodiments of the present invention. Computer system  600  includes one or more processors, such as processor  604 . Processor  604  is connected to a communication infrastructure  602  (for example, a communications bus, cross-over bar, or network). Various software embodiments are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person of ordinary skill in the relevant art(s) how to implement the invention using other computer systems and/or computer architectures. 
     Exemplary computer system  600  can include a display interface  608  that forwards graphics, text, and other data from the communication infrastructure  602  (or from a frame buffer not shown) for display on a display unit  610 . Computer system  600  also includes a main memory  606 , which can be random access memory (RAM), and may also include a secondary memory  612 . Secondary memory  612  may include, for example, a hard disk drive  614  and/or a removable storage drive  616 , representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. Removable storage drive  616  reads from and/or writes to a removable storage unit  618  in a manner well known to those having ordinary skill in the art. Removable storage unit  618 , represents, for example, a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive  616 . As will be appreciated, removable storage unit  618  includes a computer usable storage medium having stored therein computer software and/or data. 
     In exemplary embodiments, secondary memory  612  may include other similar means for allowing computer programs or other instructions to be loaded into the computer system. Such means may include, for example, a removable storage unit  622  and an interface  620 . Examples of such may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units  622  and interfaces  620  which allow software and data to be transferred from the removable storage unit  622  to computer system  600 . 
     Computer system  600  may also include a communications interface  624 . Communications interface  624  allows software and data to be transferred between the computer system and external devices. Examples of communications interface  624  may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card etc. Software and data transferred via communications interface  624  are in the form of signals which may be, for example, electronic, electromagnetic, optical, or other signals capable of being received by communications interface  624 . These signals are provided to communications interface  624  via a communications path (that is, channel)  626 . Channel  626  carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link, and/or other communications channels. 
     In this document, the terms “computer program medium,” “computer usable medium,” and “computer readable medium” are used to generally refer to media such as main memory  606  and secondary memory  612 , removable storage drive  616 , a hard disk installed in hard disk drive  614 , and signals. These computer program products are means for providing software to the computer system. The computer readable medium allows the computer system to read data, instructions, messages or message packets, and other computer readable information from the computer readable medium. The computer readable medium, for example, may include non-volatile memory, such as Floppy, ROM, Flash memory, Disk drive memory, CD-ROM, and other permanent storage. It can be used, for example, to transport information, such as data and computer instructions, between computer systems. Furthermore, the computer readable medium may comprise computer readable information in a transitory state medium such as a network link and/or a network interface including a wired network or a wireless network that allow a computer to read such computer readable information. 
     Computer programs (also called computer control logic) are stored in main memory  606  and/or secondary memory  612 . Computer programs may also be received via communications interface  624 . Such computer programs, when executed, can enable the computer system to perform the features of exemplary embodiments of the present invention as discussed herein. In particular, the computer programs, when executed, enable processor  604  to perform the features of computer system  600 . Accordingly, such computer programs represent controllers of the computer system. 
     Referring now to  FIG. 6 , a schematic diagram illustrating an example network architecture for healthcare marketplace system  100  within which an exemplary embodiment of a provider pricing tool in accordance with the present invention is implemented. It should of course be understood that  FIG. 6  is intended as an example, not as an architectural limitation for different embodiments of the present invention, and therefore, the particular elements depicted in  FIG. 6  should not be considered limiting with regard to the environments within which exemplary embodiments of the present invention may be implemented. 
     In the example illustrated in  FIG. 6 , the particular components that are utilized for providing the provider pricing tool are integrated within system  100  in conjunction with the components of the system as described above with reference to the exemplary embodiments illustrated  FIGS. 1 and 2 . More specifically, the pricing tool  137  is shown in  FIG. 6  as being implemented within procedure management service  133  included within provider portal  130 , and data store  114  further comprises a service pricing information database  114   m  and a cost adjustment information database  114   n  that are maintained by database server  112 , are accessed by application server  116  via database services provided at a front end by database server  112 , and retain information collected from a variety of data sources that is utilized in providing the services offered via the provider pricing tool within the network service provided by the application server, as described below in greater detail. 
     In the present exemplary embodiments, for use in conjunction with the physician service pricing information within service pricing information database  114   m , a corresponding set of cost adjustment data can be compiled and maintained within cost adjustment information database  114   n  that can be applied to account for geographical variances in physician costs. The cost adjustment data can, for instance, be compiled from and/or determined based upon the Geographic Practice Cost Indices (GPCis), which is used along with RVUs in Medicare Physician Fee Schedule (PFS) provided by CMS to determine allowable payment amounts for medical procedures in a manner that reflects geographical variations in practice cost. GPCis are used to help standardize the differences in resource costs incurred in operating a private medical practice across geographic areas when those costs are compared with the national average costs for the physician work, practice expense, and malpractice insurance components of the fee schedule. 
     More specifically, the CMS has established a GPCI for every Medicare payment locality for each of the three relative value unit components for a procedure (that is, the RVUs for work, practice expense, and malpractice), and the GPCis are applied in the calculation of a fee schedule payment amount by multiplying the RVU for each component times the GPCI for that component. A listing of the current GPCI locality structure, including state, locality area (and when applicable, counties assigned to each locality area), and the corresponding GPCis for each locality, can be obtained from the CMS website, and this information can be compiled and maintained within cost adjustment information database  114   n  by a back-end administrator of server system  110 . In exemplary embodiments, a specific cost adjustment factor can be determined based on the GPCI information for each designated locality area and maintained within cost adjustment information database  114   n . For example, a standard rate adjustment factor for each designated locality area can be determined by calculating an average (or any other suitable aggregate or composite-based) factor by which the corresponding GPCis for the locality impact the standard national rate derived for each service. As another example, such a standard rate adjustment factor for each designated locality area can be derived directly from the Geographic Adjustment Factor (GAF) that is determined for the locality by CMS. The GAF for each designated locality area is calculated as the weighted average of the three GPCis, where the weights are the percentage of RVUs nationally made up by the PW, PE, and MP RVUs. 
     In another example, for each service for which the information record within service pricing information database  114   m  includes an indication that the service is offered as a primary service of a bundled set of services along with an indication that the primary service is required to be performed at an outside facility, the respective pricing information that is included in the information record for the use of the outside facility can be determined by whether the use of the outside facility is classified as a facility outpatient service or a facility inpatient service. For instance, for each facility outpatient service, the respective pricing information that is included in the information record for the use of the outside facility can be obtained from the APC price data that is maintained in association with CPT or HCPCS procedure codes by CMS. CMS assigns individual services classified according to HCPCS codes to APCs based on similar clinical characteristics and similar costs. Thus, APCs are essentially line-level fee schedules in which each HCPCS code for a service is assigned to one of hundreds of individual APCs, and for almost every APC, the fee is determined by multiplying a prospectively established scaled relative weight for the service&#39;s clinical APC by a conversion factor (CF) to arrive at a national unadjusted payment rate for the APC. 
     Accordingly, in exemplary embodiments, for each service for which a respective information record is maintained within service pricing information database  114   m  and a corresponding APC is provided by CMS, the corresponding national unadjusted payment rate for the facility outpatient service can be included in the set of pricing information of the respective information record for the service within service pricing information database  114   m.    
     In the present exemplary embodiment, for use in conjunction with the facility outpatient service pricing information within service pricing information database  114   m  discussed above, a corresponding set of cost adjustment data can be compiled and maintained within cost adjustment information database  114   n  that can be applied to account for geographic differences. The cost adjustment data for the facility outpatient service pricing information can, for instance, be compiled from and/or determined based upon the facility wage index that is maintained by the CMS. 
     In the present exemplary embodiment, for use in conjunction with the facility inpatient service pricing information within service pricing information database  114   m  discussed above, a corresponding set of cost adjustment data can be compiled and maintained within cost adjustment information database  114   n  that can be applied to account for geographic differences. 
     Similar to the example discussed above with regard to the cost adjustment data for the facility outpatient service pricing information, the cost adjustment data for the facility inpatient service pricing information can, for instance, be compiled from and/or determined based upon the facility wage index that is maintained by the CMS. As noted above, in exemplary embodiments, the facility wage index information can be obtained from CMS and maintained within cost adjustment information database  114   n.    
     In this regard, it should be noted that certain services for which the respective information record within service pricing information database  114   m  includes an indication that the service is offered as a primary service of a bundled set of services along with an indication that the primary service is required to be performed at an outside facility may facilitate a mapping of the use of the outside facility to both facility outpatient service price data and facility inpatient service price data. In exemplary embodiments, for such services, a back-end administrator of server system  110  can make a determination of which set of facility price data is more suitable to include in the set of pricing information of the information record. For example, such a determination may be based upon whether the particular service is more typically performed as a facility outpatient service or a facility inpatient service. In alternative exemplary embodiments, for each service for which the respective information record within service pricing information database  114   m  includes an indication that the service is offered as a primary service of a bundled set of services along with an indication that the primary service is required to be performed at an outside facility for which the use of the outside facility can be mapped to both facility outpatient service price data and facility inpatient service price data, respective information records can be maintained for the service as an outpatient facility service and for the service as an inpatient facility service within service pricing information database  114   m.    
     In this regard, anesthesia time is a continuous time period from the start of anesthesia to the end of an anesthesia service, and one-time unit corresponds to a 15-minute interval, or fraction thereof, starting from the time the physician begins to prepare the patient for induction and ending when the patient may safely be placed under post-operative supervision and the physician is no longer in personal attendance. The conversion factors are listed by the CMS according to locality. Thus, the conversion factor in the formula listed above will correspond to the locality of the performing provider. 
     In exemplary embodiments, to access the functionality provided by pricing tool  137 , a provider user, upon registering a provider account with server system  110  (for example, a physician, practice group, or hospital system account) to establish an account information record within the corresponding profile database maintained within data store  114  and logging into his or her physician account, the user may be directed to a provider account page implemented by provider portal  130  that provides a set of user interface controls that can be accessed by the user to access functionality provided by procedure management service  133  to offer healthcare services for purchase by customer users registered with the system. As noted above, in the present exemplary embodiment, the accessible functionality provided by procedure management service  133  in this regard includes the functionality provided by pricing tool  137 . 
     In particular, upon the provider user indicating an intention to utilize pricing tool in conjunction with offering healthcare services for purchase via server system  110  (for example, by selecting a “Service Pricing Tool” tab within the provider account page implemented by provider portal  130 ), the user will be directed to an interactive service pricing page with information that is generated based on the information maintained in the respective information record for the provider within the corresponding profile database maintained within data store  114  and the respective information records for healthcare services that are maintained in service pricing information database  114   m . Price setting tool  137  may be configured, for example, to implement the interactive service pricing page to provide the provider user with detailed pricing information and recommended rates for services that may be offered by the provider for purchase via server system  110 , as well as various user interface controls accessible by the user to perform adjustments to the recommended rates as desired. 
       FIG. 7A  is a screen shot illustrating a first example of a graphical user interface provided by such a service pricing page  700  for a user accessing provider portal  130  in association with a registered hospital system account. In the example illustrated in  FIG. 7A , the user interface provided at service pricing page  700  includes a medical specialty drop-down menu  702 , a locality adjustment section  704 , a recommended rate adjustment section  706 , a detailed pricing information section  708 , and a set of selectable buttons  710   a  (“Email Prices”),  710   b  (“Save Changes”), and  710   c  (“Take Live”), the use of which will be described in greater detail below. Drop-down menu  702  provides a list of selectable medical specialties (for example, orthopedics, general surgery, cardiac imaging, etc.), and pricing tool is implemented to, in response to the user selecting a particular medical specialty using drop-down menu  702 , configure the user interface options and populate the information displayed within locality adjustment section  704 , recommended rate adjustment section  706 , and detailed pricing information section  708  in accordance with the selected medical specialty and further based on information maintained in the respective information record for the provider that is maintained within hospital system profile database  114   d , information that is maintained in the respective information records for each service indicated as being commonly associated with the selected medical specialty within service pricing information database  114   m , and information maintained within cost adjustment information database  114   n , which, as discussed above, can be accessed by pricing tool  137  via database services provided at a front end by database server  112 . 
     For instance, in the example screen shot illustrated in  FIG. 7A , the user has selected “Radiology” from medical specialty drop-down menu  702 , and pricing tool  137  has, in response to this selection, configured the user interface options and populated the information displayed within locality adjustment section  704 , recommended rate adjustment section  706 , and detailed pricing information section  708  in accordance with the selection of “Radiology” from drop-down menu  702 . More specifically, as shown in  FIG. 7A , locality adjustment section  704  has been configured to include a physician locality section and a facility section in response to the selection of “Radiology” from drop-down menu  702 . The physician locality section is provided for making pricing adjustments based on the locality of a physician that is affiliated with the hospital system and would be performing the radiology services being priced. The facility section is included within locality adjustment section  704  in response to pricing tool  137  recognizing that the respective information records for services indicated as being commonly associated with the selected medical specialty of radiology within service pricing information database  114   m  include information records having an indication that the service is a primary service of a bundled set of services that is required to be performed at an outside facility and is provided for making pricing adjustments based on the facility that is affiliated with the hospital system at which the radiology services being priced would be performed. 
     In the present example, the physician locality section includes a physician location field  704   a  and a physician location rate field  704   b , and the facility section includes a facility field  704   c  and a facility rate field  704   d . The physician location field  704   a  is for receiving and displaying an entry specifying the location of a physician that would be performing the services indicated as being commonly associated with the selected medical specialty of radiology within service pricing information database  114   m , and the physician location rate field  704   b  is configured to provide a rate adjustment factor for the pricing information included in detailed pricing information section  708  for the services indicated as being commonly associated with radiology. In exemplary embodiments, pricing tool  137  can be configured to derive an initial physician location entry based on the location associated with physician affiliation(s) included in hospital system profile database  114   d  and include this derived physician location entry as a default value within physician location field  704   a . Physician location rate field  704   b  is provided for receiving and displaying a geographic adjustment rate for physician services that, by default, is derived based on information maintained in cost adjustment information database  114   n  and provided by pricing tool  137  in correspondence with the physician location entry that is currently specified within physician location field  704   a . More particularly, in exemplary embodiments, pricing tool  137  can be configured to access the physician rate cost adjustment data in cost adjustment information database  114   n  that corresponds to the physician location entry that is currently specified within physician location field  704   a  (for example, a standard rate adjustment factor determined for a designated locality area that encompasses the specified physician location entry) and derive a corresponding geographic adjustment rate that is displayed as a default value within physician location rate field  704   b.    
     In the present example, pricing tool  137  is further configured to allow the provider user accessing service pricing page  700  to proceed to enter text corresponding to a desired location of the physician that would perform the services associated with the selected medical specialty within physician location field  704   a . In this regard, pricing tool  137  may be configured to require that the text entered by the user in physician location field  704   a  correspond to a particular locality area for which corresponding physician rate adjustments are maintained in cost adjustment information database  114   n.    
     The list of suggested physician locations provided by pricing tool  137  can further include an option for the user to select a standard, national physician rate rather than a particular geographic location. In response to a specification of a new physician location within physician location field  704   a , pricing tool  137  can be configured to dynamically access the physician rate cost adjustment data in cost adjustment information database  114   n  that corresponds to the newly-specified physician location entry that is currently specified within physician location field  704   a  and derive a corresponding geographic adjustment rate that is displayed as the current value within physician location rate field  704   b.    
     In exemplary embodiments, pricing tool  137  can be configured to derive an initial outside facility entry based on the facility affiliation(s) included the respective information record for the hospital system account in hospital system profile database  114   d  being used to access the pricing tool  137  functionality via provider portal  130  and include this derived facility entry as a default value within facility field  704   c . Facility rate field  704   d  is provided for receiving and displaying an adjustment rate for facility services that, by default, is derived and provided by pricing tool  137  in correspondence with the characteristics of the facility that is currently specified as the entry within facility field  704   c.    
     In the present example, pricing tool  137  is further configured to allow the provider user accessing service pricing page  700  to proceed to enter text corresponding to a name of a desired outside facility at which the services associated with the selected medical specialty would be performed within facility field  704   c . In this regard, pricing tool  137  may be configured to require that the text entered by the user in facility field  704   c  correspond to the name of a particular facility specified in the facility affiliations included the respective information record for the hospital system account in hospital system profile database  114   d  being used to access the pricing tool  137  functionality via provider portal  130 . 
     With continued reference to the example screen shot illustrated in  FIG. 7A , pricing tool  137  has, in response to the user selection “Radiology” from medical specialty drop-down menu  702 , configured the user interface options and populated the information displayed within rate adjustment section  706 . More specifically, as shown in  FIG. 7A , rate adjustment section  706  has been configured to include a physician rate adjustment field  706   a  and a facility rate adjustment field  706   b  in response to the selection of “Radiology” from drop-down menu  702 . Physician rate adjustment field  706   a  is provided for making a general pricing adjustment to the pricing information included in detailed pricing information section  708  for physician fees for the services indicated as being commonly associated with radiology as desired by the provider user that may be based on any budgetary considerations specific to the provider and/or physician. 
     With continued reference to the example screen shot illustrated in  FIG. 7A , as noted above, pricing tool  137  has, in response to the user selection “Radiology” from medical specialty drop-down menu  702 , configured the user interface options and populated the information displayed within detailed pricing information section  708 . In general, as shown in  FIG. 7A , detailed pricing information section  708  is generated by pricing tool  137  as a table with various interactive user interface controls that includes a procedure column  711 , a facility price column  712 , a physician price column  713 , an additional fee column  714 , and a total amount column  715 . 
     The information in procedure column  711  is generated by pricing tool  137  to include a row entry for each procedure category listed in the respective information records for services that are maintained in service pricing information database  114   m  and include an indication that the service is commonly associated with the medical specialty selected via drop-down menu  702 , which is “Radiology” for the example screen shot depicted in  FIG. 7A . For instance, the procedure categories listed in procedure column  711  in the present example include “Bone Density DXA Extremity” radiology procedures, “Bone Density DXA Scan” radiology procedures, and “Videofluoroscopic Swallowing Study” radiology procedures. As further illustrated in  FIG. 7A  for the example of the “Bone Density DXA Extremity” radiology procedures listing in in procedure column  711 , detailed pricing information section  708  is implemented to include user interface elements that are accessible by the user. 
     In the present example, the expanded information for the “Bone Density DXA Extremity” radiology procedures listing includes row entries for a “Dxa bone density/peripheral” service and a “Fracture assessment via dxa” service. As further illustrated in  FIG. 7A , the expanded information for a particular procedure category further includes, for each service categorized as a sub-procedure of the procedure category, a medical code number used to identify the service (for example, a CPT code), a base facility rate, a base physician rate, an adjusted facility rate, and an adjusted physician rate. The base physician rate for each service listed in the expanded display is obtained by pricing tool  137  from standard national physician rate derived for the service and the adjusted physician rate for each service listed in the expanded display is calculated by pricing tool  137  for display within detailed pricing information section  708  by multiplying the corresponding base physician rate by both the current value that is specified in physician location rate field  704   b  of locality adjustment section  704  and the current percentage value that is specified in physician rate adjustment field  706   a  of recommended rate adjustment section  706 . 
     In the present example, as further illustrated in  FIG. 7A , the expanded information for a particular procedure category further includes a physician price field  711   a  that specifies a price that will be set by the provider user for each of the services that have been categorized under the expanded procedure category and a facility price field  711   b  that specifies a price that will be applied by the provider user for the use of an outside facility for each of the services that have been categorized under the expanded procedure category. 
     In exemplary embodiments, pricing tool  137  can be configured to derive and include initial, default price values within physician price field  711   a  and physician price field  711   a . As further indicated in the example screen shot illustrated in  FIG. 7A , the row entry for a particular procedure category will include a pricing value under physician price column  713  that corresponds to the pricing value that is specified within physician price field  711   a  in the expanded display for the procedure category, and, likewise, the row entry for a particular procedure category will include a pricing value under facility price column  712  that corresponds to the pricing value that is specified within facility price field  711   b  in the expanded display for the procedure category. In this regard, pricing tool  137  can be configured to dynamically update the pricing values provided under physician price column  713  and facility price column  712  in response to changes to the price values within physician price field  711   a  and facility price field  711   b  respectively. As further illustrated in  FIG. 7A , the row entry for a particular procedure category can include a pricing value under total amount column  715  that is provided as a sum of the price values listed under facility price column  712 , physician price column  713 , and, if included, additional fee column  714  in the row entry for a particular procedure category. This represents the actual price at which each service listed in the expanded display for a procedure category would be offered for purchase via marketplace system  100  as a bundled set of services from the provider user accessing service pricing page  700  via provider portal  130 . 
     As noted above and further illustrated in  FIG. 7A , the user interface provided at service pricing page  700  in the present example also includes a set of accessible user interface controls  710   a  (“Email Prices”),  710   b  (“Save Changes”), and  710   c  (“Take Live”). For purposes of the present example, these user interface controls are provided within service pricing page  700  as selectable buttons. In the present exemplary embodiment, pricing tool  137  can be configured to, in response to a provider user selecting “Save Changes” button  710   b , generate an information record that includes indications of all of the information. 
     In the present exemplary embodiment, pricing tool  137  can be configured to, in response to a provider user selecting “Email Prices” button  710   s , provide user interface controls for allowing the user to specify an email address and send an electronic document that includes indications of the pricing information. 
     Finally, with reference to the present example, pricing tool  137  can be configured to, in response to a provider user selecting “Take Live” button  710   c , automatically initiate, on behalf of the provider user, a service offering with procedure management service  133  to offer each of the services currently included within detailed pricing information section  708  of service pricing page  700  for the particular medical specialty presented selected by the user from drop-down menu  702  for purchase via server system  110 . In this manner, pricing tool  137  can provide a mechanism for a provider to offer a large number of services for purchase via marketplace system  100  by customer users registered with the system without having to perform full set of operations described above for accessing functionality provided by procedure management service  133  to offer each of the services individually. 
       FIG. 7B  is a screen shot illustrating a second example of a graphical user interface provided by service pricing page  700  for a user accessing provider portal  130  in association with a registered hospital system account. In the example illustrated in  FIG. 7B , the user has selected “General Surgery” from medical specialty drop-down menu  702 , and pricing tool  137  has, in response to this selection, configured the user interface options and populated the information displayed within locality adjustment section  704 , rate adjustment section  706 , and detailed pricing information section  708  in accordance with the selection of “General Surgery” from drop-down menu  702 . More specifically, as shown in  FIG. 7B , locality adjustment section  704  has been configured to include, in addition to the physician locality section and the facility section described above with reference to the example illustrated in  FIG. 7C , an anesthesia locality section in response to the selection of “General Surgery” from drop-down menu  702 . The anesthesia locality section is included within locality adjustment section  704  in response to pricing tool  137  recognizing that the respective information records for services. 
     In the present example, the anesthesia locality section includes an anesthesia location field  704   e  and an anesthesia location rate field  704   f . The anesthesia location field  704   e  is for receiving and displaying an entry specifying the location at which the services indicated as being commonly associated with the selected medical specialty of general surgery within service pricing information database  114   m  would be performed, and the anesthesia location rate field  704   f  is configured to provide a rate adjustment factor for the pricing information included in detailed pricing information section  708  for the services indicated as being commonly associated with radiology. 
     Anesthesia location rate field  704   f  is provided for receiving and displaying a geographic adjustment rate for physician services that, by default, is derived and provided by pricing tool  137  in correspondence with the anesthesia location entry that is currently specified within anesthesia location field  704   e . More particularly, in exemplary embodiments, pricing tool  137  can be configured to access the information pertaining to anesthesia rate adjustments in service pricing information database  114   n  corresponding to the anesthesia location entry that is currently specified within anesthesia location field  704   e  and derive a corresponding geographic adjustment rate that is displayed as a default value within anesthesia location rate field  704   e . The corresponding geographic adjustment rate can be derived, for example, based on a ratio of the CMS anesthesia conversion factor to a standard, national anesthesia conversion factor. 
     Specification of a new location within anesthesia location field  704   e , pricing tool  137  can be configured to dynamically access the information pertaining to physician rate adjustments in geographic factors database  114   n  corresponding to the newly-specified physician location entry within anesthesia location field  704   e  and derive a corresponding geographic adjustment rate that is displayed as the current value within anesthesia location rate field  704   f . In the present example, pricing tool  137  is also configured to allow the provider user to directly access anesthesia location rate field  704   f  and specify a desired value for the geographic adjustment rate that will override the particular geographic adjustment rate that is derived by pricing tool  137  based on the location entry within anesthesia location field  704   e  and displayed as the current value within anesthesia location rate field  704   f . The effect of such an entry being submitted within anesthesia rate field  704   f  will be described below with reference to detailed pricing information section  708 . 
     With continued reference to the example screen shot illustrated in  FIG. 7B , as noted above, pricing tool  137  has, in response to the user selection “General Surgery” from medical specialty drop-down menu  702 , configured the user interface options and populated the information displayed within rate adjustment section  706 . 
     With continued reference to the example screen shot illustrated in  FIG. 7B , as noted above, pricing tool  137  has, in response to the user selection “General Surgery” from medical specialty drop-down menu  702 , configured the user interface options and populated the information displayed within detailed pricing information section  708 . In general, as shown in  FIG. 71 , detailed pricing information section  708  is generated by pricing tool  137  as a table with various interactive user interface controls that includes, in addition to procedure column  711 , facility price column  712 , physician price column  713 , additional fee column  714 , and total amount column  715 , an anesthesia price column  716 . As illustrated in  FIG. 7B , the expanded information for a particular procedure category further includes, for each service categorized as a sub-procedure of the procedure category, in addition to a medical code number used to identify the service, a base facility rate, a base physician rate, an adjusted facility rate, and an adjusted physician rate as described above with reference to  FIG. 7A , a base anesthesia rate and an adjusted anesthesia rate. 
     In the present example, as further illustrated in  FIG. 7B , the expanded information for a particular procedure category further includes, in addition to physician price field  711   a  and facility price field  711   b , an anesthesia price field  711   c  that specifies a price that will be applied by the provider user for each anesthesia service performed in association with the services that have been categorized under the expanded procedure category. 
     For example, pricing tool  137  can be configured to enable the user select between using the average of the corresponding adjusted anesthesia rates for all services listed in the expanded display for a procedure category for the price values within anesthesia price field  711   c  or the highest of the corresponding adjusted anesthesia rates for all services listed in the expanded display for a procedure category for the price values within anesthesia price field  711   c . In exemplary embodiments, pricing tool  137  can be further configured to allow the provider user accessing service pricing page  700  to access anesthesia price field  711   c  to input a particular price value within this field. 
     As further indicated in the example screen shot illustrated in  FIG. 7B , the row entry for a particular procedure category will include a pricing value under anesthesia price column  716  that corresponds to the pricing value that is specified within anesthesia price field  711   c  in the expanded display for the procedure category. In this regard, pricing tool  137  can be configured to dynamically update the pricing value provided under anesthesia price column  716  in response to changes to the price value within anesthesia price field  711   c . As discussed above, in exemplary configurations of pricing tool  137 , such changes to the price value within anesthesia price field  711   c  in the expanded display for a particular procedure category may occur in response to changes to any of the current value that is specified in anesthesia location rate field  704   f  of locality adjustment section  704 , the current percentage value that is specified in anesthesia rate adjustment field  706   c  of recommended rate adjustment section  706 , changes in the particular method employed by pricing tool  137  to derive and set the price value within anesthesia price field  711   c , and direct entries of a particular price value by a provider user within anesthesia price field  711   c.    
     As further illustrated in  FIG. 7B , the row entry for a particular procedure category can include a pricing value under total amount column  715  that is provided as a sum of the price values listed under facility price column  712 , physician price column  713 , anesthesia price column  716 , and, if included, additional fee column  714  in the row entry for a particular procedure category. This represents the actual price at which each service listed in the expanded display for a procedure category would be offered for purchase via marketplace system  100  as a bundled set of services from the provider user accessing service pricing page  700  via provider portal  130 . In exemplary embodiments, pricing tool  137  can be further configured to provide an option via user interface controls implemented within service pricing page  700  for a provider user that is accessing the service pricing page  700  and has selected a medical specialty from drop-down menu  702  for which pricing tool  137  recognizes that the respective information records for services indicated as being commonly associated with the selected medical specialty within service pricing information database  114   m  include information records having an indication that the service is a primary service of a bundled set of services that a secondary service associated with the primary service in the bundled set is an anesthesia procedure to not include information and options pertaining to the associated anesthesia procedures and anesthesia pricing information within the service pricing page for the selected medical specialty. 
       FIG. 7C  is a screen shot illustrating a third example of a graphical user interface provided by service pricing page  700  for a user accessing provider portal  130  in association with a registered hospital system account. In the example illustrated in  FIG. 7C , the user has selected “GI” (gastroenterology) from medical specialty drop-down menu  702 , and pricing tool  137  has, in response to this selection, configured the user interface options and populated the information displayed within locality adjustment section  704 , rate adjustment section  706 , and detailed pricing information section  708  in accordance with the selection of “GI” from drop-down menu  702 . 
     In general, as shown in  FIG. 7C , detailed pricing information section  708  is generated by pricing tool  137  as a table with various interactive user interface controls that includes, in addition to procedure column  711 , facility price column  712 , physician price column  713 , additional fee column  714 , and total amount column  715 , a pathology price column  717 . 
     As illustrated in  FIG. 7C , the expanded information for a particular procedure category further includes, for each service categorized as a sub-procedure of the procedure category, in addition to a medical code number used to identify the service, a base facility rate, a base physician rate, an adjusted facility rate, and an adjusted physician rate as described above with reference to  FIG. 7A , a base pathology rate. The base pathology rate for each service listed in the expanded display is obtained by pricing tool  137  from the pathology rate for the service that is stored within the respective information record maintained for the service within service pricing information database  114   m  for display within detailed pricing information section  708 . 
     In the present example, as further illustrated in  FIG. 7C , the expanded information for a particular procedure category further includes, in addition to physician price field  711   a  and facility price field  711   b , a pathology price field  711   d  that specifies a price that will be applied by the provider user for each pathology service performed in association with the services that have been categorized under the expanded procedure category. In exemplary embodiments, pricing tool  137  can be configured to derive and include an initial, default price value within pathology price field  711   d . For example, pricing tool  137  can derive and set the default price value within pathology price field  711   d  as the average of the base pathology rates for all services listed in the expanded display for a procedure category. In exemplary embodiments, pricing tool  137  can be further configured to allow the provider user accessing service pricing page  700  to access pathology price field  711   d  to input a particular price value within this field. 
     As further indicated in the example screen shot illustrated in  FIG. 7C , the row entry for a particular procedure category will include a pricing value under pathology price column  717  that corresponds to the pricing value that is specified within pathology price field  711   d  in the expanded display for the procedure category. In this regard, pricing tool  137  can be configured to dynamically update the pricing value provided under pathology price column  717  in response to changes to the price value within pathology price field  711   d . As further illustrated in  FIG. 7B , the row entry for a particular procedure category can include a pricing value under total amount column  715  that is provided as a sum of the price values listed under facility price column  712 , physician price column  713 , pathology price column  717 , and, if included, additional fee column  714  and anesthesia price column  716  in the row entry for a particular procedure category. This represents the actual price at which each service listed in the expanded display for a procedure category would be offered for purchase as a bundled set of services via marketplace system  100  from the provider user accessing service pricing page  700  via provider portal  130 . 
     In exemplary embodiments, the functionality that is provided within provider portal  130  for users of hospital system accounts can further include a set of user interface controls implemented by service selling service  135  that can be accessed by a user of a hospital system account to sell prepaid purchases of services to a customer in-person by operating a client system located at, for example, a medical clinic being visited by the customer to access application server  116 . In this regard, service selling service  135  may provide functionality allowing a user of a hospital system account to sell, in addition to services that are offered for purchase by the hospital within server system  100 , services that are constructed by a user of a hospital system account, including bundled sets of services. 
     In exemplary embodiments, the user interface implemented by account management service  131  may be further configured to provide user interface controls for requesting authorization for payment of a predetermined fee to gain access to the ability to offer healthcare products for purchase within marketplace system  100 . Such a fee may be, for example, a one-time charge or a periodic charge (such as a monthly, biannual, or annual fee). 
     Upon the user indicating an intention to offer a healthcare product for purchase (for example, by selecting a “Offer Service” tab within the pharmacy account page implemented by provider portal  130 ), the user will be able to initiate a product offering with product management service  134  to offer a healthcare product for purchase via server system  110 . 
     Upon the user indicating an intention within the pharmacy account page implemented by provider portal  130  to access various account management functions, the pharmacy administrator can access various user interface elements provided by account management service  131  to, for example, manage pharmacy and payment or compensation information, manage information pertaining to products offered for purchase by the pharmacy, and view a history of transactions performed for products offered for purchase by the pharmacy within server system  110 . 
     In exemplary embodiments disclosed herein, because certain healthcare information may be considered highly confidential, marketplace system  100  can be implemented to provide for a high-level of security for information transferred between client applications executing on client systems  142  and application server  116 . For illustration, whenever applicable, marketplace system  100  (for example, for operations and functionalities) may be implemented to comply with requirements under the Health Insurance Portability and Accountability Act (HIPAA). For example, if certain type of information should not be accessible to a specific party (for example, a prescription product manufacturer or service provider) according to HIPAA requirements or other confidentiality concerns, system  100  can implement information-control or information-protection measures that ensure the specific party cannot access that type of information. As another example, to protect patient privacy, information transmitted over a computer or communication network, such as information transmitted between application server  116  and any client system  140  and electronic messages transmitted by server system  110 , can be encrypted. In exemplary embodiments, system  100  can be HIPAA-validated to ensure privacy and comply with all requirements. 
       FIG. 8  illustrates a flow chart of an insurance policy stored in the insurance database ( 114   o , shown in  FIG. 2 ) executed by the application server ( 116 , shown in  FIG. 2 ). The insurance database is programmed to provide an optimized bundled price  802  for healthcare services. For exemplary purposes, the system maximizes collections at each phase in the user&#39;s care cycle. For various phases there is an option for paying the payment  804 . The patient is referred or scheduled for a procedure, where the patient may receive a push notification to pay prospectively. Alternatively, the patient checks-in at a provider&#39;s location and the patient pays at the point of service such as by cash, card, digital wallet, etc. Alternatively, the patient is made to pay after services are provided and/or at discharge wherein, the patient receives a push notification to pay retrospectively. 
     Further, each of the patient&#39;s information is monitored such as but not limited to a doctor&#39;s order/schedule (for example, CHC Redox), propensity to pay data (CHC-Vendor), benefit status (CHC-ribbon health) and CareCredit pre-approval. Based on the patient information, a doctor&#39;s order is matched. Further, the price is set based on the patient&#39;s capacity and/or willingness to pay for the service and/or product. Further, each payment is monitored to check if a patient is paying out-of-pocket. The system compares the bundled price to the remaining patient deductible to determine the patient&#39;s capacity to pay for the services and/or product. Furthermore, patients are allowed to pay either in full or through CareCredit. 
     The system is configured to pay the optimal price in full every time to the hospital/physician/pharmacy and any associated service provider. The procedure is transparent and acceptable to both patients and the provider. The service providers collect the maximum data on the patients who are willing to pay. Further, the hospital may leave revenue on the table by charging less than what patients are willing to pay. 
     The application server ( 116 , shown in  FIG. 2 ) processes the data stored in the insurance database  114   o  and allows the user to access the insurance information via an insurance management service ( 14 , shown in  FIG. 2 ). The hospital sends an electronic claim to the system after care is delivered to the patient. The system then distributes payment and sends an electronic remittance file based on the information stored in the insurance database  114   o . The system passes the electronic claim to the insurance company  806  to update the patient&#39;s accumulator (not for reimbursement). The insurance  806  then notifies the system of accumulator status. The system then sends an update to the patients. 
       FIG. 9  illustrates a block diagram of a virtual payment system manager  170  communicating with a client system in a healthcare marketplace system in accordance with another exemplary embodiment of the present invention. As noted above, exemplary embodiments of the present invention may be implemented to provide a virtual payment system for facilitating and accounting for the exchange of payment for services and products purchased by (or otherwise purchased on behalf of) patients and offered by healthcare providers via the creation, transfer, and redemption of virtual funds within a central server system  110 . 
     In some exemplary embodiments, the virtual payment system manager  170  is configured to facilitate the tracking and management of promotional credits that may be offered by the providers of a healthcare marketplace system  100  to registered users of the server system  110  for taking certain actions within the system in association with their registered accounts. 
     For example, the providers of a marketplace system  100  may offer a promotion to potential customer users in which each user, upon completing registration of a respective customer account with server system  110 , will receive a credit of a specified amount of funds (for instance, a credit of $25) that the customer user may use to purchase services and/or products offered within marketplace system  100  by provider users that are registered with server system  110 . 
     In one embodiment, the virtual payment system manager  170  is configured to, access the database server  112  to create the respective account information record for the virtual money account for the customer within the virtual money account database  114   o , and access database server  112  to create a new virtual fund corresponding to a specified amount for a promotional credit within the database of virtual fund objects included in the respective account information record. 
     In this regard, the virtual payment system manager  170  generates a unique identifier for the new virtual fund object being created and defines the attributes of the object to include an indication of the value of the corresponding virtual funds, the unique identifier generated for the object, an indication that the original funding source is a credit that was conveyed by the providers of marketplace system  100 , a creation timestamp for the object, an indication that the corresponding virtual funds for the object are not presently allocated to use as payment for an offered service or product purchased within the marketplace system, and, optionally, an indication of an expiration date for the promotional credit by which the customer user must use the credited funds to purchase the services and/or products offered within marketplace system  100 . 
     In such an example, the virtual payment system manager  170  is configured to further access database server  112  to also create a corresponding new virtual fund object for the promotional credit within the container of virtual fund objects included in the respective account information record for a respective virtual money account that is being maintained within virtual money account database  114   o  for an entity that provides the marketplace system (which may have already been established, for example, by a backend administrator of server system  110 ). More specifically, virtual payment system manager  170  generates a unique identifier for the new virtual fund object being created and define the attributes of the object to include an indication of the value of the corresponding virtual funds as a negative value, the unique identifier generated for the object, an indication that the original funding source is a corresponding amount of real currency held within an external financial account maintained by the providers of marketplace system  100  (and thereby owed to the virtual payment system by the marketplace system providers), and a creation timestamp for the object. 
     In one embodiment the virtual payment system manager  170  is also configured to, upon creating the corresponding virtual fund objects for the promotional credit within the respective account information records for the virtual money accounts for the customer user and the entity that provides the marketplace system within virtual money account database  114   o , updates the total balance values and available balance values included in the sets of general information within the respective account information records for the respective virtual money accounts appropriately to reflect the newly-created virtual fund objects. 
     In the example illustrated in  FIG. 9 , the particular components that are utilized for providing the virtual payment system are integrated within system  100  in conjunction with the components of the system as described above and herein below with reference to the exemplary embodiments illustrated  FIGS. 1 and 2 . In particular, as depicted in  FIG. 9 , application server  116  is further implemented to include virtual payment system manager  170 . As also depicted in  FIG. 9 , data store  114  further comprises virtual money account database  114   p , which is maintained by database server  112 , is accessed by application server  116 . 
     In the present exemplary embodiment, virtual payment system manager  170  is shown in  FIG. 9  as including a virtual account management module  171 , a transaction tracking module  172 , a communication module  173 , a virtual fund creation and disbursement module  174 , a virtual payment processing module  175 , and an adjustment processing module  176 . In general, the various modules implemented within virtual payment system manager  170  in the present exemplary embodiments are configured to interact with one another, customer portal  120 , provider portal  130 , and data store  114  via database server  112  to perform the various operations described in the examples provided above pertaining to exemplary embodiments in which a virtual payment system is implemented within server system  110 . 
     The virtual account management module  171  is configured to access virtual money account database  114   p  to create respective account information records for respective virtual money accounts of participants to transactions conducted within marketplace system  100 . The virtual account management module  171  retrieves, maintains, performs modifications to respective information account records as necessary in response to participants that are logged-in to server system  110  accessing the account management functions provided by account management service  122  or account management service  131  to manage and view information pertaining to the respective virtual money accounts for the participants within the virtual payment system. 
     Transaction tracking module  172  can, for example, be configured to dynamically perform updates to the accounting details pertaining to transactions conducted within the virtual payment system. The modue  172  dynamically calculates and performs updates to the balance values that are included within the general information in the respective account information records for the respective virtual money accounts in response to transactions conducted within the virtual payment system. 
     Further, module  172  dynamically performs processing for handling virtual fund objects that have been created within the virtual money account based on promotional credits that have expired in response to such expirations occurring, and dynamically perform processing for reversing payment processing operations performed within the virtual payment system for purchases of offered services and products that have not been redeemed within expiration periods specified for such purchases in response to the end of such expiration periods being reached 
     Communication module  173  can, for example, be configured to generate notifications and reports with respect to virtual money accounts managed and transactions conducted within the virtual payment system, transmit generated notifications and reports to corresponding components of customer portal  120  and provider portal  130 , receive notifications and information from corresponding components of customer portal  120  and provider portal  130 , and process such received notifications and information. 
     Virtual fund creation and disbursement module  174  can, for example, be configured to implement functionality for creating or instantiating new virtual fund objects within respective account information records for virtual money accounts as needed for transactions conducted within the virtual payment system, processing disbursal requests within the virtual payment system (including functionality for deleting virtual fund objects), and performing automatic periodic disbursals for virtual money accounts within the virtual payment system. 
     Virtual payment processing module  175  can, for example, be configured to implement functionality for performing operations for facilitating payment processing within the virtual payment system for purchases of offered services and products by customers users registered with server system  110 , as well as to perform corresponding updates to the attributes defining the virtual fund objects within the respective account information records in response to performing such operations for facilitating payment processing within the virtual payment system. Adjustment processing module  176  can, for example, be configured to implement functionality for performing operations for processing cancellation requests, refund requests, and other modifications to purchases of offered services and products for which payment processing is handled within the virtual payment system, as well as to perform corresponding updates to the attributes defining the virtual fund objects within the respective account information records in response to performing such operations for processing cancellation requests, refund requests, and other modifications to purchases within the virtual payment system. 
     In exemplary embodiments disclosed herein, because certain healthcare information may be considered highly confidential, marketplace system  100  can be implemented to provide for a high-level of security for information transferred between client applications executing on client systems  142  and application server  116 . For illustration, whenever applicable, marketplace system  100  (for example, for operations and functionalities) may be implemented to comply with requirements under the Health Insurance Portability and Accountability Act (HIPAA). As another example, to protect patient privacy, information transmitted over a computer or communication network, such as information transmitted between application server  116  and any client system  140  and electronic messages transmitted by server system  110 , can be encrypted. In exemplary embodiments, system  100  can be HIPAA-validated to ensure privacy and comply with all requirements. 
       FIG. 10  illustrates a block diagram of the application server showing a deductible checker, shopping cart and drug discount card in accordance with another embodiment of the present invention. The application server  116  may further include a deductible checker  1002  to look up the patient&#39;s deductible, a shopping cart  1004  for providing details of pricing to the user, and a drug discount card  1006  for the user for subscription of healthcare services. 
     The deductible checker  1002  allows patient&#39;s/user&#39;s to look up their deductible and to let the user know whether the healthcare service offered is at better and/or competitive prices. The shopping cart  1004  is automatically communicated to the registered users with the pricing details of the healthcare services with which they intend to proceed. The shopping cart  1004  is automatically communicated such as but not limited to email, SMS, flashing on the graphical user interface, and any other similar communication networks etc. The shopping cart  1004  automatically checks for any deductibles, insurance and accordingly generates the pricing for the user. 
     In another embodiment, the shopping cart  1004  is verified by an analyst to confirm the pricing. Thus, the shopping cart is sent to the analyst system and then to the user. This allows the user to pre-pay for the healthcare services. Further, the shopping cart  1004  is generated with the right bundled prices (e.g. accounting for discounts when certain procedures are purchased together etc.). The drug discount card  1006  is provided to the users who subscribe to the healthcare services. 
     Aspects of exemplary embodiments of the present invention described herein can be implemented using one or more program modules and data storage units. As used herein, the term “modules”, “program modules”, “components” “systems”, “tools”, “utilities”, and the like include routines, programs, objects, components, data structures, and instructions, or instructions sets, and so forth that perform particular tasks or implement particular abstract data types. As can be appreciated, the modules refer to computer-related entities that can be implemented as software, hardware, firmware and/or other suitable components that provide the described functionality, and which may be loaded into memory of a machine embodying an exemplary embodiment of the present invention. Aspects of the modules may be written in a variety of programming languages, such as C, C++, Java, etc. The functionality provided by modules used for aspects of exemplary embodiments described herein can be combined and/or further partitioned. 
     As used herein, the terms “data storage unit,” “data store”, “storage unit”, and the like can refer to any suitable memory device that may be used for storing data, including manual files, machine readable files, and databases. The modules and/or storage units can all be implemented and run on the same computing system (for example, the exemplary computer system illustrated in  FIG. 5  and described below) or they can be implemented and run on different computing systems. For example, one or modules can be implemented on a personal computer operated by a user while other modules can be implemented on a remote server and accessed via a network. 
     While the invention has been described in detail with reference to exemplary embodiments, it will be understood by those skilled in the art that various changes and alternations may be made and equivalents may be substituted for elements thereof without departing from the scope of the invention as defined by the appended claims. In addition, many modifications may be made to adapt a particular application or material to the teachings of the invention without departing from the essential scope thereof. 
     Variations described for exemplary embodiments of the present invention can be realized in any combination desirable for each particular application. Thus particular limitations, and/or embodiment enhancements described herein, which may have particular limitations need be implemented in methods, systems, and/or apparatuses including one or more concepts describe with relation to exemplary embodiments of the present invention. 
     Therefore, it is intended that the invention not be limited to the particular embodiments disclosed as the best mode contemplated for carrying out this invention, but that the invention will include all embodiments falling within the scope of the present application as set forth in the following claims, wherein reference to an element in the singular, such as by use of the article “a” or “an” is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Moreover, no claim element is to be construed under the provisions of 35 U.S.C. § 112, sixth paragraph, unless the element is expressly recited using the phrase “means for” or “step for.” These following claims should be construed to maintain the proper protection for the present invention.