WO2017059499A1 - A method and system for claims management - Google Patents

A method and system for claims management Download PDF

Info

Publication number
WO2017059499A1
WO2017059499A1 PCT/AU2016/050947 AU2016050947W WO2017059499A1 WO 2017059499 A1 WO2017059499 A1 WO 2017059499A1 AU 2016050947 W AU2016050947 W AU 2016050947W WO 2017059499 A1 WO2017059499 A1 WO 2017059499A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
work order
service provider
participant
services
Prior art date
Application number
PCT/AU2016/050947
Other languages
French (fr)
Inventor
Stephen James AUSTEN
Christopher Stuart SIMON
Brody Kenrick
Original Assignee
Lantern Claims Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2015904105A external-priority patent/AU2015904105A0/en
Application filed by Lantern Claims Pty Ltd filed Critical Lantern Claims Pty Ltd
Publication of WO2017059499A1 publication Critical patent/WO2017059499A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08Insurance

Definitions

  • the present disclosure relates generally to the field of computer and
  • one or more embodiments of the present disclosure involve the management of services related to claims against a scheme.
  • one or more embodiments of the present disclosure involve the management of the display and purchase or booking of products and services that are claimable under a scheme. Further, one or more embodiments of the present disclosure involve the management of the provisioning of services by a service provider claimable under a scheme. Further, one or more embodiments of the present disclosure involve the automated re-imbursement for claims made by a service provider against the scheme.
  • operator/funder may be, for example, an insurance organisation , government benefits program , private company, or the like.
  • the validity of a claim is determ ined on the basis of the rules of the scheme, the participant's entitlements under the scheme, and the specific data contained in the claim transaction request, such as the participant details and the items requested.
  • Schemes and programs are not restricted to government-based programs and may be established by any organisation to provide allowances/entitlements to users. Schemes and programs may also control the provisioning of services from a set of selected service providers against the allowance rules associated with the particular scheme. Many private companies already have similar scheme/funding structures. Such private companies include, for example, health insurance, property insurance, and accident insurance companies.
  • FI G. 1 is a schematic representation 100 illustrating operation of an existing scheme/program in which a single service provider organisation is approved by the scheme to provide services to participants within the scheme.
  • FI G. 1 shows a participant 105 receiving services from a single service provider organisation 120.
  • the service provider organisation 120 is the only provider approved for the scheme and the service provider organisation 120 receives funding from the scheme/program 1 10 to provide the services.
  • the participant 105 cannot use another service provider 130.
  • FI G. 2 is a schematic representation 200 illustrating operation of an existing scheme/program 210 in which one or more service providers 220, 230 are approved by the scheme to provide services to participants within the scheme/program .
  • the services are delivered to a participant 205 by the respective service providers 220, 230.
  • the service providers 220, 230 then subm it claims to the scheme/program 21 0 in relation to the delivered services.
  • Unfortunately in this case only the first service provider 220 associated with a first claim is reimbursed by the scheme/program 210, as the funds allocated under the scheme have been exhausted.
  • the system 200 does not include any checks to prevent service providers 230 from providing services after funds associated with the scheme have been exhausted.
  • the scheme or program operator authorises the participant (or an authorised carer associated with the participant) to access some goods/ services (an entitlement) ;
  • the participant (or carer) manually searches for a suitable service provider to provide the goods/ services; the participant (or carer) orders the goods or services from a selected service provider;
  • the selected service provider collects relevant entitlement information from the participant (or carer) ;
  • the service provider provides the goods and/or services to the participant ; the service provider submits an invoice to the scheme or program operator using the entitlement information and details about the actual service (such as cost, time, and services rendered) ; and
  • the scheme or program operator pays the service provider.
  • the current claim ing process has at least the following issues:
  • entitlement information must be passed between several entities, often in formats requiring manual entry and checking which can cause errors and is time consuming, causing delays;
  • searching for a suitable service provider that offers the goods and services which are valid for a particular participant under a given scheme or program involves searching one or more information sources and contacting service providers to confirm validity and availability;
  • invoice data requirements of the scheme or program operator are typically more rigorous than standard tax invoices and also commonly vary between schemes, making it difficult for a service provider to comply with the requirements of a nominated scheme and it is particularly onerous when a service provider operates across m ultiple schemes;
  • service provider organisations/ aggregators do not have timely information regarding work undertaken by sub-contractors and often receive invoices from sub-contractors too late to include them in the relevant billing cycle (i.e. , a service provider aggregator often experiences difficulties in invoicing expenses to a scheme operator, as the service provider must not claim costs before the service provider has received invoices from the relevant sub-contractors) ; payment from the scheme operator to the service provider is often delayed due to processing, checking , and correcting of subm itted invoices;
  • the service provider is usually unaware at the time of receiving a booking request from a participant whether the entitlement permits the provision of the goods or services offered by the service provider ( I n some schemes, the service provider is not able to check the validity of the claim until the service has already been rendered - leading to confusion and dissatisfaction) ; and g) the various parties with an interest in a claim (e.g. , broker, aggregator, and carer) are not made aware that a service provider has provided the goods or services to a participant.
  • the various parties with an interest in a claim e.g. , broker, aggregator, and carer
  • Standard claiming systems such as the HI CAPS health claims and payment scheme operated in Australia, provide a point-of-service device for use in processing a claim , whereby the point-of-service device checks some claim data and authorises a payment.
  • this is not integrated with any booking or pre-authorisation process, nor does it allow for entitlements to be "reserved" for future services.
  • it is not possible to control the manner in which the service is provided. That is, existing systems do not control which service providers may be engaged to provide the service or when such a service may be provided.
  • the present disclosure relates to a method and system for the management of claim-related services.
  • the present disclosure provides a method for receiving a booking for a service at an eMarketplace comprising :
  • the method further includes the step of adjusting entitlement information to reflect the work order.
  • the present disclosure provides a claims management system comprising :
  • a centralised server coupled to a com munications network, said server including : a processor; and
  • participant profile information associated with a user said participant profile information referencing a set of entitlements
  • the computer program when executed on the processor, performs the further step of adjusting entitlement information to reflect the work order.
  • the present disclosure provides a method for processing a work order at a claims management server, said method comprising the steps of :
  • the present disclosure provides a method for transmitting a service indication for a work order from a claim processing device, said work order providing pre-authorised approval for a service provider to render a service to a participant registered with a scheme, said method comprising the steps of :
  • the present disclosure provides an apparatus for implementing any one of the aforementioned methods.
  • the present disclosure provides a computer program product including a computer readable medium having recorded thereon a computer program for implementing any one of the methods described above.
  • FI G. 1 is a schematic representation illustrating operation of an existing scheme/fund in which a single service provider is approved by the scheme;
  • FI G. 2 is a schematic representation illustrating operation of an existing scheme/fund in which m ultiple service providers are approved by the scheme;
  • FI G. 3 is a schematic representation of a claim management system in accordance with the present disclosure.
  • FIG. 4 is a schematic block diagram representation of a claims management system of the present disclosure
  • FIG. 5 is a schematic block diagram representation illustrating connectivity of various parties to a claims management platform , according to an embodiment of the present disclosure
  • FI G. 6 is a schematic representation showing a flow of physical and computer data items representing goods or services through a claims platform , according to an embodiment of the present disclosure
  • FI G. 7 is a schematic representation showing invoicing and payment interactions for services rendered under a Service Provisioning Scheme
  • FI G. 8 is a schematic representation showing a functional decomposition of one embodiment of a claims platform , according to an embodiment of the present disclosure
  • FI G. 9 shows a system architecture for an implementation of a claims management system , according to an embodiment of the present disclosure
  • FI G. 1 0 illustrates data relationships in a claims management system , according to an embodiment of the present disclosure
  • FI G. 1 1 illustrates a process for creating a plan, according to an embodiment of the present disclosure
  • FIG. 12 illustrates an eMarketplace for discovering products and services and conducting transactions and having services provided , according to an embodiment of the present disclosure
  • FI G. 13 illustrates an eMarketplace for finding products and services and conducting a claims service transaction, according to an embodiment of the present disclosure
  • FI G. 14 illustrates an eMarketplace and associated connectivity and interactions, according to an embodiment of the present disclosure
  • FI G. 1 5 illustrates a Participant service checkout view, according to an embodiment of the present disclosure
  • FI G. 1 6 illustrates a Participant portal , according to an embodiment of the present disclosure
  • Fl G. 1 7 illustrates filtering goods and/or services for display in an eMarketplace, according to an embodiment of the present disclosure
  • FI G. 1 8 illustrates participant interactions, according to an embodiment of the present disclosure
  • FI G. 1 9 illustrates participant interactions for a payment process, according to an embodiment of the present disclosure
  • FI G. 20 illustrates assigning items to a work order, according to an embodiment of the present disclosure
  • FI G. 21 shows a carer screen view, according to an embodiment of the present disclosure
  • FI G. 22 illustrates a participant's interactions to submit a reimbursement claim , according to an embodiment of the present disclosure
  • FI G. 23 illustrates an example of a participant and service provider interactions, according to an embodiment of the present disclosure
  • FI G. 24 illustrates a flow of actions leading to an authorisation of a claim charge against a purchase, according to an embodiment of the present disclosure
  • FI G. 25 illustrate a flow of ClaimCharging and settlement to a service provider, according to an embodiment of the present disclosure
  • FI G. 26 is a Service Provider Portal view, according to an embodiment of the present disclosure.
  • FI G. 27 illustrates ClaimCharge submission, according to an embodiment of the present disclosure
  • FI G. 28 illustrates settlement of a charge against a work order (claim) , according to an embodiment of the present disclosure
  • FI G. 29 illustrates registration of a user, according to an embodiment of the present disclosure
  • FI G. 30 illustrates registration of a service provider and Service Provider Scheme Participation, according to an embodiment of the present disclosure
  • FI G. 31 illustrates registration of a carer/participant, according to an embodiment of the present disclosure
  • Fig. 32 is a schematic block diagram representation of a system that includes a general purpose computer on which one or more embodiments of the present disclosure may be practised ;
  • Fig. 33 is a schematic block diagram representation of a system that includes a general mobile device on which one or more embodiments of the present disclosure may be practised. Detailed Description
  • the present disclosure provides an electronic marketplace (eMarketplace) server adapted to receive a booking request from a user for a service in relation to a set of available services authorised within the marketplace.
  • the set of available services presented to the user for selection depends on entitlement information associated with that user.
  • the server issues a work order (a support or service assignment or an 'earmark' or, more generally, an 'agreement') that constitutes authorisation for a selected service provider to render one or more specific services based on the booking requests.
  • the server stores a copy of the work order for use in later reconciliation when the selected service provider submits a claim based on the issued work order.
  • a participant is a person who is approved to "participate" in a scheme (or program) and receives a service by a service provider.
  • a participant may be, for example, a person insured by an insurance provider, whereby the scheme relates to terms of a health insurance fund operated by the insurance provider.
  • references throughout this specification to a scheme also encompass a program or other organised activity, and is not to be construed in a limiting sense.
  • a scheme or program is a combination of funder, broker, service provider aggregator, and the holder of the funds account. Examples include, but are not lim ited to, National Disability I nsurance Scheme (NDI S) , Aged Care, Transport Accident Commission (TAC) , and WorkCover NSW.
  • NDI S National Disability I nsurance Scheme
  • TAC Transport Accident Commission
  • WCover NSW WorkCover NSW.
  • a funder is a governmental insurance scheme or other funding program that justifies the need for the program and provides the funding or a private sector company (e.g. , an insurer) .
  • funders examples include NDI S and TAC.
  • a carer is a person who looks after the interests of a participant if a participant is not able to self-manage their own claims, bookings, and/or service provider interactions. Often , a carer is the same person that assists the participant in other matters. For example, a carer may be a husband or wife of a person with disabilities. Professional carers also exist.
  • a broker is an institution or individual that provides consultancy to participants, prospective participants (and , where appropriate, associated carers) to determine product and service solutions across a number of service providers and product providers.
  • An example of a broker is an insurance company or accounting agency, such as Ernst & Young ( EY) .
  • a service is a treatment, procedure, good , or consultation that is provided under a scheme or program to a participant in that scheme or program .
  • a service aims to assist, improve, or rehabilitate the participant .
  • Examples of a service may include, for example, physiotherapy, transport, or dentistry.
  • a service provider is an individual or business that provides a service to a participant .
  • a service provider may include, for example, a physiotherapist, psychologist, a cleaner, or a driver.
  • a service provider aggregator is a larger service provider providing comprehensive service packages operating under a scheme (possibly a one-stop shop) .
  • the service packages may include in-house services and also services performed by external service providers. External providers are generally paid by the service provider aggregator, rather than by a scheme operator. Examples of a service provider aggregator include, for example, Just Better Care and Northcott.
  • an "allowed claim” may be associated with one or more goods and/or services.
  • an "allowed claim” in relation to a participant of a health insurance scheme may relate to a service request by that participant for 1 hour of physiotherapy.
  • a service provider that renders the 1 hour of physiotherapy lodges an invoice, in the form of a ClaimCharge, to the scheme or program for payment of rendered services.
  • a session refers to the total activities of a participant for one service provider on one occasion (usually on one specific day) .
  • a session may include the service provider's journey to the participant and the delivery of several support items.
  • An example of a session may include, for example, a taxi to a medical centre, dentistry procedures, provision of a new toothbrush, and taxi home.
  • Another example may be a physiotherapist driving to a participant's home, providing physiotherapy services, and the physiotherapist driving back to the physiotherapist's office.
  • an entitlement is a granted approval by a scheme operator to a participant of a scheme of a specific service item to a specific quantity delivered by a specific service provider type or a specific service provider. Examples are 5 hours of physiotherapy or $1000 of psychological consultation.
  • a plan includes a set of one or more plan-items.
  • a plan may include a list of allowed/fundable items for a specific participant, such as mobility training, physiotherapy, and/ or hearing- aid.
  • plan-item is a permission (e.g. , authorization and entitlement) pertaining to a specific item-code ( item-codes represent items ⁇ e.g. services and/or goods ⁇ that are available under a scheme) .
  • a booking is an act of ordering services by a participant (or their proxy - e.g. , an associated carer) .
  • a booking may include the type of service to be delivered and/or a time for that service to be rendered. Examples are ordering a physiotherapy session or making a dental appointment .
  • a work order is a sub-set of an entitlement or plan that is a certain set of services with a budget targeted at a particular service provider.
  • Such a work order may include pre-authorisation of a monetary amount for the service(s) to be rendered , an ability to specify the service(s) to be rendered, the quantity of those services, the service provider to render the service(s) and possibly temporal lim itations.
  • the temporal limitations may define a time period after which the work order will expire.
  • the temporal limitations may also specify a particular time period during which the services may be rendered, such as to coincide with an off- peak delivery period for those services.
  • the work order optionally provides for the assignment of one plan item (or a fraction thereof) to a specific service provider or to be charged against by any registered service provider.
  • a ClaimCharge is an act of authorizing and charging a service that has been rendered by a service provider, for example, providing an invoice.
  • a ClaimCharge includes a set of one or more claim- items.
  • An example of a ClaimCharge is when a service provider, who is assigned to deliver a certain service to a participant registered with a scheme, delivers this service and consequently "claims" (or charges) the provision of that service against the scheme operator in order to receive payment.
  • a claim-item is an item that refers to a specific service provider and specifies an item-code.
  • An example is a claim on rendered physiotherapy services.
  • an item-code library is a list of support items, typically covered by a funder under a certain scheme.
  • a service is not lim ited to only health services and may also relate to motor vehicle repair services, home and property insurance, government sponsored buy-back program (guns, sun-tanning equipment) , and the like.
  • the present disclosure provides a claims management system that may be implemented using a cloud-available server.
  • the present disclosure also provides a description of one or more methods by which a claim transaction can be processed by an end-user and a service provider associated with such a claims management system.
  • the present disclosure provides an e-commerce marketplace for claim transactions.
  • the marketplace presents a tailored set of available goods and services to a participant , according to benefits and constraints defined by at least one plan of at least one scheme to which the participant has subscribed.
  • the present disclosure also provides a system which allows participants and service provider aggregators to order services - typically from the marketplace.
  • the present disclosure also provides a system which provides for validation of an order, according to benefits and constraints defined by at least one plan of at least one scheme to which the participant has subscribed.
  • the present disclosure further provides one or more claiming devices that allow service work orders to be claimed against by a service provider as the services are provided to the participant .
  • Such claim ing means include, for example, a software application ("app") executing on a computing device accessed by the service provider, a web-based portal, or a combination thereof.
  • FI G. 3 is a schematic representation of a claim management system 300 in accordance with the present disclosure.
  • the system 300 includes a claims platform 350 that comm unicates with a scheme/program 310 and manages the selection of services by a participant 305, the authorisation of work orders, the rendering of services, and payment upon service delivery by one or more service providers 320, 330.
  • the claims platform 350 is a system for processing claims, comprised of three elements:
  • a claims system (a claim processing engine - incorporating portals for various user groups) ;
  • the claims platform 350 allows for the creation of an authorised work order, which dictates the work a service provider is authorised to perform for a participant under their care. This authorised work order is then able to be claimed upon (charged) by the service provider one or more times using a claim processing device to allow for payment.
  • FIG. 4 is a schematic block diagram representation showing an overview of a system 400 for implementing a claim management system in accordance with the present disclosure.
  • the system 400 shows several devices controlled/owned by various parties and how those parties and devices access and comm unicate with other components of the system 400.
  • the system 400 includes a com munication network 450.
  • the com munication network 450 may be implemented using a dedicated com munications link, a local area network (LAN) , a wide area network (WAN) , the I nternet , a
  • the system 400 also includes a claims system and marketplace 430 that includes an eMarketplace portal 432, and administration portal 434, and a database server 436.
  • the system 400 further includes a set of service providers 41 0, comprising one or more service provider organisations or individuals.
  • the set of service providers 410 use mobile software applications 414 for home services or service provider individuals to communicate with the claims system and marketplace 430 and other entities of the system 400.
  • the set of service providers 410 alternatively, or in combination with the mobile software applications 414, uses patient management systems adapted to com municate with the server 430.
  • the system 400 further includes a set of participants and carers 420, who can use mobile apps and/or browser-based webpages to com municate with the claims system and eMarketplace server 430 and other entities in the system 400.
  • the system of FI G. 4 also includes a set of schemes/programs 440, each of which uses a broker portal or an application programming interface (API ) to brokers' systems or an administration portal for self-managed schemes to comm unicate with other entities in the system 400, including the claims system and eMarketplace 430.
  • API application programming interface
  • Broker Plan Manager Platform A person who establishes participants' plans.
  • a person who updates a plan and manages it A person who updates a plan and manages it.
  • Broker eMarketplace A person who manages a plan and visits the
  • Plan Plan Manager Platform A professional service provider managing a
  • Plan eMarketplace A person who manages a plan and visits the Manager Customer Portal marketplace on the participant's behalf.
  • Carer Plan Manager Platform A private carer managing a participant's plan and authorised to act on their behalf.
  • Carer eMarketplace A person who manages a plan and visits the
  • Participant Plan Manager Platform A person who can view their own plan and
  • Participant eMarketplace A person who self-manages their plan and visits
  • Public user eMarketplace A potential or not signed-in participant.
  • Service Service Provider user A service provider operating as an individual.
  • Admin initially registers a service provider organisation and enables SP deliverer to self-register under their organisation.
  • Service eMarketplace Service An administrator with a service provider who
  • Scheme Admin Ul An external administrator who manages users of a support scheme.
  • FI G. 5 is a schematic block diagram representation showing various actors and how those actors interact with several parts of a claim management platform 500.
  • the claims platform includes a plan manager portal 510 and a service provider portal 520.
  • the plan manager portal 510 provides user and application interfaces to establish plans and allows other involved parties to use these plans to place bookings (and create work orders) and purchases.
  • the service provider portal 520 enables the service providers to validate work orders and charge for provided services (or otherwise indicate status changes or notes on a work order) .
  • An eMarketplace allows a participant or carer (an authorised person who acts on behalf of the participant) to find appropriate services and products and directly order or pay with scheme/program funds.
  • the eMarketplace may also be available to the public in order that the public (i.e. , users who are not yet registered with the scheme) can browse the services.
  • Service providers can also access an eMarketplace adm inistration interface to manage their catalogue and offerings (this can also be entered by other parts of the system, but direct editing by the service provider helps distribute responsibility of ensuring accuracy on the offering can be made by the parties most interested/affected) .
  • the platform allows for administrators (via the Scheme Adm inistration interface and the Participants Overview I nterface) to manage several participants across schemes, manage several plans across schemes per participant, manage personal funds per participant via an electronic wallet to facilitate co-payments across plans, and oversee plans (e.g. , states status) and be notified when action is required.
  • the platform allows participants and carers (via the Customer Portal) to: find services and products in an eMarketplace that is configured with the user's needs, allowances/entitlements and preferences; place orders with plan funds and/or traditional payment methods; request and submit quotes; communicate (bi-directionally) with providers; and display transaction history, rate services and products.
  • FI G. 6 is a schematic representation of a flow 600 showing various actors and their "real world" items/ actions and how they map to their representations in the system .
  • the flow 600 includes an outer cycle and a m iddle cycle. Around the outside of the outer cycle, the actors can be seen as scheme/program, broker, participants and service providers.
  • the m iddle cycle shows an item-code library, a plan, a work order and a ClaimCharge.
  • An item-code library stores a list of items (services and/or goods) that are available under a given scheme.
  • the item-code library is connected to item-codes, shown in the inner cycle.
  • the item-code library functions as a pricelist for the stored list of items, whereby a scheme/program can define limits for the services and goods that are allowed to be funded under that scheme.
  • a plan is based on the available services and the participant's needs and treatment or outcome goals.
  • a broker may establish a plan with a subset of specific items or categories. The participant or carer then books services from the plan-items.
  • plan-items typically via the eMarketplace interactive web pages, but also possible by a web service REST/SOAP or other automated means
  • making of a booking typically by eMarketplace, but also by other automated means
  • the work order represents a "pre-authority" for services and goods to be provided.
  • the work order is available in the system to be assigned to a specific service provider, by for example a plan manager or the participant.
  • the work order may also be made available in the system so that an arbitrary (but authorised) service provider can assign the work order to themselves (typically by use of a service provider interface - app or portal) , however other models are supported by the system for service providers competing for the right to service (be assigned) the work order.
  • One such competition is a reverse auction market place where service providers bid on price and other service dimensions for exclusive assignment .
  • a ClaimCharge is an indication by a service provider that they have partially or completely fulfilled a work order and wish to charge for their services.
  • the services rendered by the service provider are captured as ClaimCharge items which are pre- authorised in the work order, which - subject to the prevailing funding methodology of the scheme/program - allows for close to immediate settlement.
  • a scheme comprises plan categories, SP categories, item-codes (potentially from several libraries from m ultiple sources and even multiple schemes) and also optionally properties of plan items (e.g. , plan categories or item-codes) and/or properties of plan budget (per item or total ; per unit-price or total) .
  • An item-code library (pricelist) links plan categories to SP categories - e.g ., item- code a (plan category x, SP category X) or item-code b (plan category y, SP category Y) .
  • a plan comprises plan items.
  • Plan-items can be a category-individual where plan categories have an individual budget (e.g . , Plan Category x - budget n or Plan Category y - budget m) , item-code specific where item-codes with individual price and quantity or individual budget (e.g. , item-code 1 - budget n and item-code 2 - amount x; price y) or category total where plan categories have total budget only (e.g. , Plan Category x and Plan Category y with Total Budget : budget n) .
  • a ClaimCharge is a group of ClaimCharge items (also referred to as claim items) .
  • ClaimCharge items can be plan categories with price and quantity or item-codes with price and quantity.
  • FI G. 7 is a schematic representation showing flows 700 of invoicing and payment interactions for services rendered under a service provisioning scheme.
  • the claims platform manages services and related activities so that the claims engine can automate resulting payment-related activities.
  • FI G. 8 is a schematic representation showing a functional decomposition of one embodiment of a claims platform 800 in accordance with the present disclosure.
  • FI G. 8 shows connectivity, API s/ services and data sources/sinks for various parts of a claims management system . I n particular, FI G. 8 shows the modularity of services and interactions with external services.
  • the claims platform 800 is compatible with external frontends and can incorporate external procedural services into the claims process or process externally managed data.
  • the claims platform 800 may be implemented using a brokerage module 810, a front end module 820, an authentication and permissions module 830, an ecom merce module 840, a claims module 850, an analytics module 860, and a banking module 870.
  • the platform 800 optionally includes other modules relating to plans, transaction data, participants, work orders, service providers, data import/ export, wallet functionality, schemes, item-code libraries, broker and PMs and Rules. Most modules can connect to an Enterprise Resource Planning (ERP) system for data analytics and business insights.
  • ERP Enterprise Resource Planning
  • a bus/queue/message delivery system is present to allow data and message exchange between the different modules.
  • the brokerage module 81 0 comprises a Plan Broker Portal module 815.
  • the front end module 820 presents various interfaces and portals to the user and has connectivity for various web server technologies.
  • Third party interfaces 880 also exist for various adm inistrative functions
  • the authentication and permissions module 830 provides single sign-on services via user sub-modules and permissions sub-modules.
  • I t contains a database which may be shared with other databases in the system .
  • the ecommerce module 840 services the eMarketplace.
  • the ecommerce module 840 contains submodules for presenting various aspects of the marketplace and for acting upon the booking , fulfilment and payment of services and goods.
  • the ecommerce module 884 also contains a database which may be shared with other databases in the system .
  • the payment sub-module connects to external payments services (e.g. , payment gateways, PayPal) for the payment of self-funded products and services.
  • the Claims (ClaimCharge/l nvoice) module 850 provides functionality for processing state changes on a work order including validation that a ClaimCharge is allowed on a work order.
  • the Claims (ClaimCharge/ l nvoice) module 850 comprises sub- modules for a settlement engine that drives a sub-module for payment and invoicing.
  • the Claims (ClaimCharge/l nvoice) module 850 connects to the Bank module.
  • the bank module 870 includes a payment processing module (or one per supported banking interface) . When a QaimCharge is to be settled, this payment processing module sends commands and ensures correct behaviour of the payment being seen through to completion . [001 12]
  • the analytics module 860 runs various analytical and reporting processes and makes these available via an API and also presents the data to the ERP. The analytics module 860 has connectivity to the database across the entire system .
  • FIG. 9 shows an architecture 900 for an implementation of the claims system depicted in FI G. 8.
  • FI G. 1 0 shows several data entities and their dependencies for an
  • I tems in such an implementation 1 000 may include, for example, but are not limited to, personal supports and training, accommodation/tenancy, assistance access/maintain, assistance prod-personal care/ safety, assistance integrate into school/education, assistive products, household task, assistance life stage, transition, assistance personal activities, assistance travel/transport, behaviour support, comm unity nursing care, daily tasks/shared living, development-life skills, early childhood supports, household tasks, interpret/translate, physical wellbeing, plan management, therapeutic supports, and training-travel independence.
  • Assistive products and equipment in such an implementation 1000 may include, for example, but are not limited to, assistive equip-recreation , communications and information equipment, equipment special assess setup, hearing equipment , home modification, personal mobility equipment, vehicle modifications and vision equipment.
  • Fl G. 1 1 shows a process 1 1 00 to establish a plan via the plan manager portal.
  • a plan represents various aspects of the entitlements of a participant .
  • the claims platform can support different types of plans. According to one embodiment , the following plans are supported :
  • a plan is applied to a participant and given an optional expiry date. Different actions are then taken depending on the service plan .
  • items can be added under a plan- category and then a total for scheme funding is set and a total for self-funding is set.
  • item-code specific plan For an " item-code specific plan" , specific items are added as an item-code and for each item an amount is set for scheme funding and self-funding.
  • the items are typically added to the system in bulk via a database/dataset import and uploaded into the claims system or received via integration between the claims system and a scheme provider or service provider system . Additions and updates can be done on an individual item basis also. Modifications can be made in the admin portal on details of an item manually.
  • FI G. 12 depicts an eMarketplace 1200 that presents participant-specific offerings to participants and allows for the booking, provisioning and settlement of payments for services.
  • the scheme/program provides participant data and plan data (comprising entitlement data) to the claims system .
  • the participant data and plan data may be in addition to existing user data for the participant stored in the system or a related system (for example, from previous use by the user of the system such as a registration process or prior usage on the current scheme or other schemes) .
  • the data specifying the participants and their plan/entitlements can be transm itted to the claims system via a range of means, and may be sent ahead of time and stored in the claims system or requested by the claims system on an as-needed basis.
  • Service providers are varied in their size and complexity, from large organisations employing thousands of people and providing a m ultitude of products and services, down to sole traders offering a specific service.
  • Service providers provide their catalogue data to the service provider e-marketplace, thus specifying the goods and services to be offered in the market (b) .
  • the scheme operator may also provide catalogue data, which may initially be done in bulk with catalogue revisions being done by the service provider.
  • the eMarketplace offers a variety of means to accept a catalogue of products and services from service providers (b) , such as an online data entry mechanism or an API for receiving a direct data feed.
  • the catalogue data includes the descriptive details for the item , reference to "item-codes" of one or more schemes, and may include a wide range of other attributes, such as price, images, service availability, options, meta-data, or extras.
  • the eMarketplace may offer goods and services in different ways and from different sources.
  • the eMarketplace might aggregate offerings from m ultiple vendors and across m ultiple schemes.
  • the eMarketplace might also be a single vendor for a single scheme.
  • the eMarketplace provides potential customers with a searchable listing of catalogue items and a means by which to purchase those items.
  • a standard eMarketplace is deficient because it does not take into account the entitlements that are allocated to a participant when that participant is attempting to find suitable services.
  • the service provider eMarketplace uses the data from the service provider catalogue (b) along with the participant's plan from the scheme operator (c) to determine which products are able to be purchased by (or on behalf of) a participant.
  • the eMarketplace When a participant visits the eMarketplace, the eMarketplace presents the participant with a user-specific view of the market offering (d) , which is modified according to the plan data of the participant (c) .
  • a person authorised to act on a participant's behalf can also visit the eMarketplace and be presented with a user-specific view (an impersonated view) of the market offering (d) , which is modified according to the plan data of the participant with which the authorised person is associated (c) .
  • a customer a participant or person authorised to act on a participant's behalf (e.g. , carer; plan manager; service coordinator; supports coordinator) is able to log into the eMarketplace as a means of identifying themselves to the e-marketplace.
  • the eMarketplace can then present the catalogues in a way which is more convenient to the customer and speed up the service selection process (d) .
  • the customer is able to make a purchase request, which is lodged in the claims system as a work order (e) including data relating to the participant, plan, service provider, and catalogue item and the validity and authorisation for service transactions to be made under the work order.
  • a work order including data relating to the participant, plan, service provider, and catalogue item and the validity and authorisation for service transactions to be made under the work order.
  • the participant selects the appropriate goods or services for booking.
  • the order or purchase is pre-authorised in the claims system (e) .
  • This 'work order' remains in the claims system until the service provider charges the service via the service provider portal or mobile app (f) .
  • the claims engine validates this charge request in real-time with regards to scheme and entitlement specific rules and informs both parties of the transaction result.
  • the validation of a request may be performed independently from displaying of the goods and services and may be present as a payment option (similar to a pay with credit card or PayPal) integrated with an independent marketplace.
  • the service provider is informed regarding the work order via the service provider Portal (including mobile apps) (f) .
  • the service provider can authorise and charge for providing a service (f) .
  • CI aim Charge/ invoice can be settled in real time (g) .
  • the scheme operator receives relevant transaction and settlement data in the form of reporting ( h) .
  • the claims management platform facilitates the settlement of funds between the held funds account and the service provider (g) and can report any transaction data back to the scheme (h) .
  • FIG. 13 shows a further embodiment of the present disclosure in which an eMarketplace 1300 presents participant-specific offerings to a participant to make a booking .
  • the scheme operator provides participant data and plan data (comprising entitlement data) to the claims system .
  • Service providers provide their catalogue data to the eMarketplace, thus specifying the goods and services to be offered in the market (b) .
  • the eMarketplace uses the data from the service provider catalogue (b) along with the participant's plan from the scheme operator (c) to determine which products are able to be purchased by (or on behalf of) a participant.
  • the eMarketplace When a participant visits the eMarketplace, the eMarketplace presents the participant with a user-specific view of the market offering (d) , which is modified according to the plan data of the participant (c) .
  • the customer is able to make a purchase request, or booking, which is converted in the claims system as a work order (e) including data relating to the participant, plan , service provider, and catalogue item .
  • the participant selects the appropriate goods or services for booking.
  • the order or purchase is pre-authorised and remains in the claims system (e) for further processing.
  • FI G. 14 shows a decomposition 1400 of the eMarketplace, actors and external interfaces.
  • the eMarketplace has a Service Provider Ul ( User I nterface) , a Broker Registration and Login Ul and a Participant/Carer Ul .
  • the eMarketplace also includes an interface to each of a Claims engine/System , External Data, a Data Buyer
  • a Web Portal module connects to a database for storing catalogue and other data.
  • the Web Portal comprises a Shopping Cart , Preferences, a social layer (messages and comments along with product and service ratings) and a search module.
  • the search module processes results for both product search and service search.
  • An Order Processing module enables the booking of services or ordering of goods. For an order - consisting of goods and services - to be placed, the Claim authorisation module determines whether the order is allowed. The Claim authorisation module connects to a claims engine or other data source to determine what is allowed to be ordered . The goods and services that are allowed are determined based on the participant's plan. Following, or in a related process to the order, a work order can be made in the claims system .
  • the facility also exists to take direct payment within the marketplace for an order.
  • the claims management system imposes, or facilitates application of, a charge to the participant in relation to a co-payment or in the case of upsold/optional items that are not covered at all by the scheme or the participant's entitlements.
  • Such charges to the participant may also relate to expediting some aspects of the goods and services, such as express delivery or out of hours services.
  • Payment via external payment methods e.g. , credit card, PayPal, etc.
  • FI G. 1 5 shows a screen displayed to a participant on order checkout .
  • the system matches items from the marketplace to available entitlements (plan) and allows the user to select the plan or plan-items in case different options are available (as multiple options from different service providers may be found) .
  • the claims platform may manage multiple sets of funding sources available to a participant .
  • each funding source is represented by at least two accounts: a budget account ( representing the budget available from the funding source) and a cash account (representing im mediately available cash from the funding source) .
  • Claims are authorised against available entitlements in the budget account and authorised claims are settled based on available cash in the cash account.
  • Funding sources may be considered as being either cash-oriented or budget-oriented.
  • An account set up by a participant or carer for co-funding amounts which exceed entitlements under a scheme/program (sometimes referred to as the participant's "wallet") is an example of a cash-oriented funding source.
  • a scheme/program sometimes referred to as the participant's "wallet”
  • the budget account and the cash account are identical and the budget account is only increased when the cash account is increased. I n the example of FI G. 15, the amount of the purchase/order exceeds the plan's allowance and the user is able to pay with 'Wallet' funds or conventional payment methods like credit cards or PayPal to make the order and confirm the booking .
  • FI G. 1 6 is a screen view representing several screens presented in the eMarketplace. Together, the screens are showing several ways in which searches for services, products, organisations and personal assistants can be conducted and refined/filtered.
  • the home page has several facilities on it , including registration, login , help pages and search facilities (such as quick search, find products and services, and events and activities) .
  • a search When a search is executed, for example via the homepage, the system presents a search details page.
  • the page consists of a results pane and several filter and refinement options that may take the form of a free text field, a radio button, a range or slider or other filter mechanisms.
  • Services may be searched for and filtered on dimensions as shown in ( 1 ) .
  • Products may be searched for and filtered on dimensions as shown in (2) .
  • Organisations and Personal Assistants searches provide links to contact details that may be from a separate data source and provided as a directory service. These may be searched for and filtered on dimensions as shown in (3) and (4) .
  • FI G. 1 7 shows the eMarketplace integrating data from the claims platform to display pages to the participant .
  • Service providers upload or manage their catalogues and associate each offered item to item-code libraries or Service Categories as provided by schemes/programs the service providers wish to participate in .
  • the eMarketplace presents available services and goods it does so by filtering the catalogue by scheme (to show only approved or allowed services with a matching item-code) and specific service provider approval . This can then also be further filtered on plan (entitlement) .
  • FI G. 1 8 shows a participant's interactions in the eMarketplace.
  • the participant may arrive via the Plan Manager Portal or directly to the eMarketplace. Participants may self-register or have a log-in already.
  • the eMarketplace can also display services to users that are not logged in (some embodiments restrict this public access) . Following access to the eMarketplace, the customer can discover services and products by searching or browsing over a number of dimensions/hierarchy.
  • the eMarketplace will display a result of a discovered item.
  • the eMarketplace when being accessed via a redirection is capable of having a search or a particular item presented to the participant.
  • FI G. 1 9 shows participant interactions for the payment of an order or a check-out of their cart of selected goods and services.
  • I f a selected item is covered by one of the participant's plans /work orders, then the purchase can be facilitated against scheme funds - depending on the item type.
  • I f an item is not covered by the plan, then the transaction is conducted by a direct payment using an external payment authority or a Wallet kept in the system representing non-plan customer funds (which can be topped up by external payments) .
  • Product orders are typically finalized im mediately.
  • Services orders are typically finalized by the service provider. Depending on service type or other characteristics the system pre-approves a service in the form of a work order. After the service is provisioned, the service provider finalises the work order. Finalising causes a settlement to occur.
  • FI G. 20 shows an example assignment of plan-items to a work order.
  • the work order may stipulate one specific service provider or allow many service providers to render services against that work order.
  • Plan-items can be assigned to a specific service provider, several service providers or to allow several/many service providers to claim against the plan-item (e.g. , all those authorised under the scheme to provide this kind of service) .
  • the assignment itself may dictate a specific item-code or may j ust define a Service Category.
  • the process (executed by automated means or manually depending on available data and permissions) begins by selecting a plan item .
  • a choice/indication of whether the work order is to be specific to a particular service provider is made ( if it is an option/requirement , then a particular service provider is provided) .
  • a choice/indication of whether the work order is to be specific to a particular item-code is made. I f the work order is not specific to a particular item-code, then only a work order Total is provided. I f the work order is specific to a particular item-code, then item-codes are selected/provided as is a quantity and a unit price.
  • FI G. 21 shows a screen 21 00 for a carer managing a participant's plan.
  • a carer authorised to manage a participant's plan logs onto their Plan Manger Portal and selects the participant by entering the participant's identification. Having full access to the plan as displayed by the wire-frame, the carer may navigate to the eMarketplace to find accurate services.
  • the screen shows all participants that are under this carer.
  • the screen also indicates the allowance consumed under a plan, the amount remaining and a transaction history.
  • FI G. 22 is a flow diagram of a method 2200 showing a participant's interactions to submit a reimbursement claim. I n this example, a service was rendered and paid for by the participant that could be covered under the plan associated with the participant, but the service was not captured under a work order. Depending on the scheme/program funding model and item-code associated with a plan-item , participants may lodge claims to reimburse relevant expenditure.
  • the participant selects a plan if appropriate or automatically selects the plan if only one plan exists.
  • the participant selects a plan-item (discovered by search or other mechanisms) .
  • the claims system checks if a reimbursement is allowed for the plan item . I f the plan item is reimbursable, then the system presents an option to "Claim reimbursement" to the participant.
  • the participant clicks "Claim reimbursement” and enters other relevant data, such as quantity, unit price and other data as might be specified in the plan or scheme.
  • the platform then allows for the uploading of a receipt.
  • the receipt may be uploaded by a file access or a camera on a smart phone/ mobile device.
  • FI G. 23 shows an example flow 2300 for a participant's and service provider's interactions of acquiring and fulfilling a service.
  • the participant books a service via the eMarketplace using plan funds (that is the payment of the items is within the plan/scheme and will not require a co-payment) .
  • the service provider delivers the requested service across several sessions until the work order is complete/ exhausted and the service provider finalizes the transaction via the Service Provider App.
  • the participant is logged into a session in the eMarketplace.
  • the system presents a filtered set of offerings to the participant.
  • the participant performs a search for a specific item (in this case, item-code representing "personal domestic activities") .
  • the eMarketplace displays results (in this case, this specific service from several service providers) .
  • the participant selects an item (in this case, the selected item is an item with a covered/ allowed price equal to the item prices) .
  • the participant places this item into their shopping cart ( in this case, indicating that the participant want the maximum quantity of sessions covered by the plan) .
  • the participant selects to pay for the service via claim/scheme funds.
  • the claims system pre-approves the payment (reserving the plan funding) and creates a work order.
  • the claims system sends an indication to the service provider (in this case, an email, but an 'app' notification or other message forms are also supported, including sending a call to an API in a service provider system) of the booking/work order.
  • the service provider is now permitted to work on the work order and has received a notification of the work order (and related booking) .
  • the service provider organises with the participant when to deliver the services.
  • the service provider makes a home visit to the participant.
  • the service provider scans an identity card/item of the participant such as a bar code, Radio Frequency I D ( RFI D) , Near Field Com munications (NFC) or using Bluetooth/LE or app identification using the Service Provider App.
  • the work orders and remaining allowance for this participant are displayed on the Service Provider App.
  • the service provider checks that the work is covered and then performs the work.
  • the service provider indicates the performed work quantity against the work order.
  • the rendering of services in this example finalises the transaction/session and causes a ClaimCharge to be sent indicating the services are complete and can be settled and that the Claims system, because of the pre-authorisation, knows that a payment can be made.
  • the participant receives a receipt/ notice of the services rendered for their records. The information is placed in the stored transaction history associated with the participant.
  • the service provider has more work to do on the work order and schedules another session to render more services.
  • This example also shows a flow where a participant raises a dispute on poorly rendered or not delivered services.
  • the system has dispute resolution capabilities and allows for putting a hold on or the return of funds (to both or either of the scheme and participant, as appropriate) .
  • the system tracks the state of the work order or items as being disputed and is capable of putting a hold on the settlement of the payments for these goods and services.
  • a refund (or removal from payment) for a disputed transaction can be initiated by the service provider or a plan manager.
  • the system also allows for the cancellation of a work order with remaining services/ allowances at the discretion of the participant or the service provider.
  • FI G. 24 shows a flow of actions leading to an authorisation of a claim (charges) against a purchase.
  • the claims platform identifies a set of available valid funding sources.
  • Validity of funding sources is based on the rules of the relevant funding source. Rules may be general to the funding source (for example, dates between which funds may be used) or specific to the items and categories of items that the participant is attempting to fund from the funding source (for example, the maximum amount that will be funded for a particular item) . Funding sources may be considered pre-authorised or may require specific authorisation from the funder or a person to whom the funder has delegated authorisation (including the participant) .
  • a successful purchase (booking) in the eMarketplace (a) occurs and this causes the creation of a work order. Purchases that are made on the eMarketplace are converted into work orders in the claims system (b) .
  • the work order is a pre-authorised allocation of work and specifies the work which can be performed by a service provider (or allow for any registered service provider to claim/charge against) .
  • the claims platform first identifies an available set of funding sources. I f any funding sources are pre-authorised, the claims platform will fund the claim from those funding sources to the maximum extent permitted by the funding source.
  • the pre-authorisation is made by processing the items in the booking under a scheme specific ruleset validating the respective items of the work order against the participant's plan.
  • a work order can comprise an item-code, amount, validity dates, and may contain additional restrictions or rules limiting the finalisation of the transaction (counts, limits, time, valid service providers) .
  • the work order effectively represents a pre-authorisation for a future set of ClaimCharges.
  • the funds are removed from the particular funding source's budget account (effectively being "reserved” for the particular work order) and are represented in a new budget-oriented funding source specifically for that work order.
  • the new funding source becomes a valid funding source for ClaimCharges which match the relevant work order. I f a work order of significant duration (for example, greater than 6 months) is to be authorised against a cash-oriented funding source, there may be insufficient funds in the cash account to fund the entire work order.
  • the authorisation rules require sufficient funding in the cash-oriented funding source to fund the first invoicing cycle of the work order
  • the budget-oriented funding source is established with a budget account and a cash account
  • a new budget and cash receivable account are established and the funds for the first invoicing cycle are transferred from the cash-oriented funding source's accounts (budget and cash accounts) to the work order's funding source's accounts (budget and cash accounts) and a new receivable funding source budget account is created recording the cash receivable amount owed to complete the funding of the cash-oriented funding source.
  • Automatic authorisation rules may be configured to apply for a given maxim um claim value or any claim value. Automatic authorisation rules may also be configured with a delay so that the funding of the claim is automatically authorised some time after the claim is received. As the participant (or the person authorised to act on a participant's behalf) is notified as soon as the claim is received, the participant and/or other person have the opportunity to review and dispute the claim within the time period but with the knowledge that the claim will become authorised without their intervention after the nominated time period.
  • a ClaimCharge is processed/validated against the work order (c) to obtain payment for the services rendered.
  • a ClaimCharge transaction is submitted by the service provider on a claim processing device, the claim data is checked against the work order and other rules for the scheme.
  • a response is provided to the service provider, indicating whether the claim has been successfully lodged and if not , why.
  • the claim processing device in one embodiment is an application running on one or more mobile operating systems (a mobile app) .
  • mobile operating systems may include, for example, iOS App, Android App, and Windows Mobile App.
  • the claim processing device in a further embodiment is a device capable of sending an SMS (Short Messaging System) message (often referred to as a "text message") for which a text message with an identifier for the work order and the work conducted is sent to the claims system .
  • SMS Short Messaging System
  • the claim processing device in a further embodiment is a web-based portal accessible from a browser.
  • An additional embodiment has this portal implemented as a mobile specific site optim ised for mobile devices.
  • a further embodiment has this claim processing device incorporated into a Point-of-sale (POS) terminal (e.g. , EFTPOS, or Credit Card term inal) .
  • the POS terminal indicates the claim request to the claims engine instead of, or in addition to, other systems.
  • Some POS terminals have a physical/soft button to perform the ClaimCharge operation.
  • the POS terminal receives participant or work order identification entered into the device either by reading an identification such as a card/QR code/bar code/NFC or similar, either directly or via a dongle.
  • the claim processing device may be a mobile device, desktop PC, or other hardware, such as a desktop terminal or Point of Sale device.
  • the claim transaction data may vary from scheme to scheme, but generally contains information about the participant , service provider, item-code/s, and service details such as cost, time, and description .
  • Certain embodiments have the service provider using a claim processing device (CPD) to process the charge for a claim (ClaimCharge) after services have been rendered.
  • CPD claim processing device
  • the CPD can also indicate other aspects of a claim/booking , partial rendering, a
  • no-show a cancellation , or other kinds of change in state.
  • the claim transaction data is sent to the scheme operator (d) . This may be for reporting or may also facilitate payment to the service provider (d) . The payment may also be directly settled via the claim engine ( FI G. 25) .
  • the claim transaction data On successful lodgement, the claim transaction data may be transm itted to the scheme operator via an agreed transmission methodology (e.g. file transfer, email, or web API ) .
  • FI G. 25 shows a flow of a service provider initiating a ClaimCharge.
  • the ClaimCharge triggers the fully automated authorisation and settlement process.
  • the scheme/program determ ines the tim ing and nature of the settlement transaction.
  • settlement is to be performed by the claims platform
  • the timing of settlement is contingent on the cash being available for each of the identified funding sources in its associated cash account.
  • the funds are immediately available as the funding source's budget account would only have had sufficient funds to authorise the claim if the cash was immediately available given the budget account reflects the cash account.
  • the cash may or may not be available for settlement at the time that the claim is authorised. I n those circumstances, the claims platform will wait until the cash is available before settling the account .
  • a service provider attempts to charge a service via a claim processing device (e.g. , a Service Provider App) .
  • the service delivered should be covered by the scheme and to initiate the payment procedure ( instead of manual invoicing) the submission is made.
  • the claims engine validates the requests on scheme/plan based rules in real-time and, if allowed, finalises the transaction and triggers the settlement.
  • the settlement of funds between the scheme/program 's held funds account and the service providers is facilitated overnight or as defined by the scheme/program .
  • FIG. 26 shows an example of a Dashboard 2600 of the Service Provider
  • the Service Provider Portal Dashboard 2600 provides an overview of awaiting quotes, open work orders (open orders) , and Statistics (business insights) .
  • the service provider can directly respond to requests, quotes, orders, add com ments, and initiate a ClaimCharge or other state modification.
  • FI G. 27 shows the submission of a ClaimCharge by a service provider.
  • a service provider receives a product order from the eMarketplace, their interaction may be as little as accepting an order for processing/fulfilment.
  • the eMarketplace order contains a service (work order)
  • the service provider finalizes this transaction via a claim submission device as outlined in FI G. 25.
  • plan-items may have been assigned to many service providers, hence the participant retains the choice of which service provider to go to. I n this case, the service provider needs to identify the participant (e.g . , by scanning a card) . I f the provider is authorised to deliver the envisaged service, the transaction is finalized as above.
  • a different operational mode allows the service provider to create the work order via the Service Provider App - I nvoicing mode.
  • this ClaimCharge may correspond to the submission of an electronic invoice or an integrated validation procedure as above.
  • FI G. 28 shows claims/ charges settlement.
  • the claims engine can aggregate successful transactions for each service provider and create payment orders across service providers to be transmitted to a financial institution (e.g. , a payments order file) .
  • the financial institution processes this payment order, releases the transactions for processing (banking) , and sends a status report back to the claims engine.
  • the claims engine updates transactional data and sends out remittance advice to service providers. I f the status report contains errors, the system optionally notifies internal support administration to manually resolve the settlement problems.
  • FI G. 29 shows user self-registration .
  • the user registration process may be generic and independent of the envisaged role ( users may also have several roles in the system administrator of one scheme, participant to another) . I f a person registers with an email address that had been used as in invitation to a specific role, the user will automatically inherit that role, once successfully registered.
  • An unknown person who wants to operate as a carer may select the scheme they want to participate in . Depending on the scheme setting, a scheme admin may then authorise this person to receive the envisaged role.
  • Service provider data is provided either by the scheme/program, or by the service provider when registering onto the platform online.
  • FI G. 30 shows service provider on-boarding.
  • a user may register as a new service provider organisation or individual service provider and select the scheme they wish to participate in.
  • a scheme may be open or closed to new service providers. Open schemes can be joined by any service providers; closed schemes reserve the right to approve the new service provider. This approval can be general or per service item relating to the scheme's service categories as managed within their item-code libraries.
  • a service provider will register their bank account with the eMarketplace.
  • a user who has registered a scheme inherits the role of a service provider adm in for that scheme. This user may invite other persons to register as service provider deliverers and he may make himself a deliverer to use the operational portal.
  • FI G. 31 shows on-boarding of participants and authorisation of carers.
  • Participants are primarily imported from scheme/program's systems - via an automated connection or manually by a bulk upload or import .
  • a broker, scheme admin or service provider may also establish a participant in the system . This may be done via the portal.
  • An operator of a system as described herein may charge fees based on transactions. These fees can be charged to both the service provider and the scheme provider (f under) . The fee reflects the value to each entity.
  • the system can charge the participant and other actors in the system . I n a typical health care scheme implementation , the system does not charge participants, but may do so. I t would be probable to charge in a private market like an insurance claims system .
  • the service provider subscribes to the service to process claims quickly (simplicity, traceability, and overnight settlement) (and they will pay a monthly subscription) .
  • the scheme provider saves on manual invoicing processing (hence typically charged a fixed price per claim or item) and the service provider gets faster access to their funds (hence typically charged a percentage of value) .
  • the system can create revenue in several ways. For example, App Revenue. Monthly subscription sales for the Service Provider App (to individual service providers) begin. I ntegration to online services for claims made via patient management system integration and online sales.
  • the system processes several data streams that can be monetized by providing the information to the scheme provider or other bodies such as governmental oversight , the service providers for analytics/ competitive information or to private advertisers.
  • the key factors dictating value of the data are covered - namely 'Who the customer is', 'Where they are located', 'How old they are', and 'What they Purchase'.
  • An interface is provided by the system to provide this analytics information either as a data source or to an ERP (See FI G. 8 - 860 and 890) .
  • Data for insights and analysis of user behaviour can be made available via an OLAP data cube or via SQL or MDX queries.
  • Embodiments of the present disclosure offer valuable benefits to parties to the system. Embodiments of the present disclosure offer high transparency to all involved parties and discoverability of information and history. [00204] The system can ensure that any service is provided by an authorised provider to an authorised scheme participant and thus financially covered (no questions and no complaints related to these issues) and general confidence in the system the assurance that a claim is valid will bring.
  • Embodiments of the present disclosure offer many benefits to the user
  • the system can be managed easily by a separate user (carer) , and simplify the process to find an appropriate provider for claim services and place orders by providing a smart eMarketplace.
  • This eMarketplace understands a visiting participant's plan and presents the market in a custom ized way.
  • Embodiments of the present disclosure offer many benefits to the service provider.
  • the service provider does not need to manage invoicing and payment, automating the production and transmission of invoices from suppliers, better controls of SPs, a marketable asset of a market place of simple usability, monitoring and involvement in transactions (allowing for com missions) , and allowing overnight settlement to suppliers.
  • Embodiments of the present disclosure offer many benefits to the
  • Embodiments of the present disclosure also offer many benefits to
  • Private schemes such as property insurance are well suited to benefit from the claims management system of the present disclosure.
  • insurance claims for a private scheme across m ultiple insurance types e.g. , NRMA supporting motor vehicle, home and contents, pet insurance
  • Participants can access a white-labelled system (branded for the private scheme) for tracking their claims.
  • Service providers e.g. , smash repairs, body shops, retailers for replacement goods, would be able to access the system to fulfil work orders (and to vie competitively to gain access to the rights to the work order, e.g. , reverse auction) .
  • Point of sale integration for claims processing at a retailer e.g. , Kmart Tyre and Auto or Harvey Norman
  • FIG. 32 is a schematic block diagram of a system 3200 that includes a general purpose computer 3210.
  • the general purpose computer 321 0 includes a plurality of components, including : a processor 3212, a memory 3214, a storage medium 3216, input/output ( I /O) interfaces 3220, and input/output ( I/O) ports 3222.
  • Components of the general purpose computer 321 0 generally comm unicate using one or more buses 3248.
  • the memory 3214 may be implemented using Random Access Memory (RAM) , Read Only Memory (ROM) , or a combination thereof .
  • the storage medium 3216 may be implemented as one or more of a hard disk drive, a solid state "flash" drive, an optical disk drive, or other storage means.
  • the storage medium 3216 may be utilised to store one or more computer programs, including an operating system , software applications, and data. I n one mode of operation , instructions from one or more computer programs stored in the storage medium 321 6 are loaded into the memory 3214 via the bus 3248. I nstructions loaded into the memory 3214 are then made available via the bus 3248 or other means for execution by the processor 3212 to implement a mode of operation in accordance with the executed instructions.
  • One or more peripheral devices may be coupled to the general purpose computer 321 0 via the I/O ports 3222.
  • the general purpose computer 321 0 is coupled to each of a speaker 3224, a camera 3226, a display device 3230, an input device 3232, a printer 3234, and an external storage medium 3236.
  • the speaker 3224 may be implemented using one or more speakers, such as in a stereo or surround sound system .
  • one or more peripheral devices may relate to a keyboard, tablet, mouse, or other input or output device connected to the I/O ports 3222.
  • the camera 3226 may be a webcam , or other still or video digital camera, and may download and upload information to and from the general purpose computer 3210 via the I /O ports 3222, dependent upon the particular implementation .
  • images recorded by the camera 3226 may be uploaded to the storage medium 321 6 of the general purpose computer 321 0.
  • images stored on the storage medium 3216 may be downloaded to a memory or storage medium of the camera 3226.
  • the camera 3226 may include a lens system , a sensor unit , and a recording medium .
  • the display device 3230 may be a computer monitor, such as a cathode ray tube screen, plasma screen, or liquid crystal display ( LCD) screen .
  • the display 3230 may receive information from the computer 3210 in a conventional manner, wherein the information is presented on the display device 3230 for viewing by a user.
  • the display device 3230 may optionally be implemented using a touch screen to enable a user to provide input to the general purpose computer 321 0.
  • the touch screen may be, for example, a capacitive touch screen, a resistive touchscreen , a surface acoustic wave touchscreen, or the like.
  • the input device 3232 may be a keyboard, a mouse, a stylus, drawing tablet, or any combination thereof , for receiving input from a user.
  • the external storage medium 3236 may include an external hard disk drive (HDD) , an optical drive, a floppy disk drive, a flash drive, or any combination thereof and may be implemented as a single instance or multiple instances of any one or more of those devices.
  • the external storage medium 3236 may be implemented as an array of hard disk drives.
  • the I /O interfaces 3220 facilitate the exchange of information between the general purpose computing device 3210 and other computing devices.
  • the I /O interfaces may be implemented using an internal or external modem , an Ethernet connection , or the like, to enable coupling to a transm ission medium.
  • the I /O interfaces 3222 are coupled to a com munications network 3238 and directly to a computing device 3242.
  • the computing device 3242 is shown as a personal computer, but may be equally be practised using a smartphone, laptop, or a tablet device. Direct communication between the general purpose computer 3210 and the computing device 3242 may be implemented using a wireless or wired transmission link.
  • the communications network 3238 may be implemented using one or more wired or wireless transm ission links and may include, for example, a dedicated communications link, a local area network (LAN) , a wide area network (WAN) , the I nternet, a telecommunications network, or any combination thereof.
  • LAN local area network
  • WAN wide area network
  • I nternet I nternet
  • telecommunications network any combination thereof.
  • telecomm unications network may include, but is not limited to, a telephony network, such as a Public Switch Telephony Network ( PSTN) , a mobile telephone cellular network, a short message service (SMS) network, or any combination thereof.
  • PSTN Public Switch Telephony Network
  • SMS short message service
  • the general purpose computer 321 0 is able to comm unicate via the com munications network 3238 to other computing devices connected to the communications network 3238, such as the mobile telephone handset 3244, the touchscreen smartphone 3246, the personal computer 3240, and the computing device 3242.
  • One or more instances of the general purpose computer 3210 may be utilised to implement a server acting as a portal to implement a claims management system in accordance with the present disclosure.
  • the memory 3214 and storage 321 6 are utilised to store data relating to registered participants, plans, and the like.
  • Software for implementing the claims management system is stored in one or both of the memory 3214 and storage 321 6 for execution on the processor 3212.
  • the software includes computer program code for implementing method steps in accordance with the method of claims management described herein .
  • Fig. 3333 is a schematic block diagram of a system 3300 on which one or more aspects of a claims management method and system of the present disclosure may be practised.
  • the system 3300 includes a portable computing device in the form of a smartphone 3310, which may be used by a registered user of a claims management system in accordance with the present disclosure.
  • the smartphone 3310 includes a plurality of components, including: a processor 3312, a memory 3314, a storage medium 3316, a battery 331 8, an antenna 3320, a radio frequency (RF) transmitter and receiver 3322, a subscriber identity module (SI M) card 3324, a speaker 3326, an input device 3328, a camera 3330, a display 3332, and a wireless transmitter and
  • RF radio frequency
  • SI M subscriber identity module
  • the smartphone 3310 also includes a wired connection 3345 for coupling to a power outlet to recharge the battery 3318 or for connection to a computing device, such as the general purpose computer 321 0 of Fig. 32.
  • the wired connection 3345 may include one or more connectors and may be adapted to enable uploading and downloading of content from and to the memory 3314 and SI M card 3324.
  • the smartphone 331 0 may include many other functional components, such as an audio digital-to-analogue and analogue-to-digital converter and an amplifier, but those components are omitted for the purpose of clarity. However, such components would be readily known and understood by a person skilled in the relevant art.
  • the memory 3314 may include Random Access Memory (RAM) , Read Only Memory (ROM) , or a combination thereof .
  • the storage medium 3316 may be
  • the storage medium 3316 may be utilised to store one or more computer programs, including an operating system, software applications, and data. I n one mode of operation, instructions from one or more computer programs stored in the storage medium 331 6 are loaded into the memory 3314 via the bus 3348. I nstructions loaded into the memory 3314 are then made available via the bus 3348 or other means for execution by the processor 3312 to implement a mode of operation in accordance with the executed instructions.
  • the smartphone 331 0 also includes an application programm ing interface (API ) module 3336, which enables programmers to write software applications to execute on the processor 3312.
  • API application programm ing interface
  • Such applications include a plurality of instructions that may be pre-installed in the memory 3314 or downloaded to the memory 3314 from an external source, via the RF transmitter and receiver 3322 operating in association with the antenna 3320 or via the wired connection 3345.
  • the smartphone 331 0 further includes a Global Positioning System (GPS) location module 3338.
  • GPS Global Positioning System
  • the GPS location module 3338 is used to determ ine a geographical position of the smartphone 3310, based on GPS satellites, cellular telephone tower triangulation , or a combination thereof. The determ ined geographical position may then be made available to one or more programs or applications running on the
  • the wireless transmitter and receiver 3334 may be utilised to comm unicate wirelessly with external peripheral devices via Bluetooth, infrared , or other wireless protocol.
  • the smartphone 331 0 is coupled to each of a printer 3340, an external storage medium 3344, and a computing device 3342.
  • the computing device 3342 may be implemented, for example, using the general purpose computer 321 0 of Fig . 32.
  • the camera 3326 may include one or more still or video digital cameras adapted to capture and record to the memory 3314 or the SI M card 3324 still images or video images, or a combination thereof .
  • the camera 3326 may include a lens system , a sensor unit, and a recording medium .
  • a user of the smartphone 331 0 may upload the recorded images to another computer device or peripheral device using the wireless transmitter and receiver 3334, the RF transmitter and receiver 3322, or the wired connection 3345.
  • the display device 3332 is implemented using a liquid crystal display (LCD) screen.
  • the display 3332 is used to display content to a user of the smartphone 3310.
  • the display 3332 may optionally be implemented using a touch screen, such as a capacitive touch screen or resistive touchscreen, to enable a user to provide input to the smartphone 3310.
  • the input device 3328 may be a keyboard, a stylus, or microphone, for example, for receiving input from a user.
  • the keyboard may be implemented as an arrangement of physical keys located on the smartphone 610.
  • the keyboard may be a virtual keyboard displayed on the display device 3332.
  • the SI M card 3324 is utilised to store an I nternational Mobile Subscriber I dentity ( I MSI ) and a related key used to identify and authenticate the user on a cellular network to which the user has subscribed.
  • I MSI I nternational Mobile Subscriber I dentity
  • the SI M card 3324 is generally a removable card that can be used interchangeably on different smartphone or cellular telephone devices.
  • the SI M card 3324 can be used to store contacts associated with the user, including names and telephone numbers.
  • the SI M card 3324 can also provide storage for pictures and videos. Alternatively, contacts can be stored on the memory 3314.
  • the RF transm itter and receiver 3322 in association with the antenna 3320, enable the exchange of information between the smartphone 3310 and other computing devices via a comm unications network 3390.
  • RF transm itter and receiver 3322 enable the smartphone 3310 to comm unicate via the communications network 3390 with a cellular telephone handset 3350, a smartphone or tablet device 3352, a computing device 3354 and the computing device 3342.
  • the computing devices 3354 and 3342 are shown as personal computers, but each may be equally be practised using a smartphone, laptop, or a tablet device.
  • the communications network 3390 may be implemented using one or more wired or wireless transm ission links and may include, for example, a cellular telephony network, a dedicated communications link, a local area network (LAN) , a wide area network (WAN) , the I nternet, a telecommunications network, or any combination thereof.
  • a telecomm unications network may include, but is not limited to, a telephony network, such as a Public Switch Telephony Network ( PSTN) , a cellular ( mobile) telephone cellular network, a short message service (SMS) network, or any combination thereof.
  • PSTN Public Switch Telephony Network
  • SMS short message service

Abstract

Disclosed herein are methods and systems relating to claims management. A method for receiving a booking for a service at an eMarketplace comprises: receiving an access request for a user to an eMarketplace server, said user being associated with participant profile information referencing a set of entitlements; producing a set of available services, wherein the set of available services is produced based on entitlement information derived from said set of entitlements and said access request; receiving a booking request for at least one instance of a selected one of said available services, said instance to be provided by one or more service providers; approving each instance based on entitlement information derived from said set of entitlements; creating a work order that comprises an approval for one or more service providers to render one or more instances of said selected available service; and storing the work order in a database.

Description

A METHOD AND SYSTEM FOR CLAI MS MANAGEMENT
Related Application
[ 0001 ] The present application is related to Australian Provisional Patent Application No. 20159041 05 titled "A method and system for claims management" and filed on 8 October 2015 in the name of Lantern Claims Pty Ltd, the entire content of which is incorporated by reference as if fully set forth herein.
Technical Field
[ 0002] The present disclosure relates generally to the field of computer and
telecom munication systems and more specifically to methods and systems for the management of services. I n particular, one or more embodiments of the present disclosure involve the management of services related to claims against a scheme.
Further, one or more embodiments of the present disclosure involve the management of the display and purchase or booking of products and services that are claimable under a scheme. Further, one or more embodiments of the present disclosure involve the management of the provisioning of services by a service provider claimable under a scheme. Further, one or more embodiments of the present disclosure involve the automated re-imbursement for claims made by a service provider against the scheme.
Background
[ 0003] The term "claiming" refers to the process of a scheme or program participant requesting products or services from a service provider to be paid for, either completely or partially, by a scheme or program operator/funder. A scheme or program
operator/funder may be, for example, an insurance organisation , government benefits program , private company, or the like. The validity of a claim is determ ined on the basis of the rules of the scheme, the participant's entitlements under the scheme, and the specific data contained in the claim transaction request, such as the participant details and the items requested.
[0004] Claim-based schemes and programs are common and occur internationally. I n Australia, examples include the National Disability I nsurance Scheme (NDI S) , home care packages, WorkCover, Public trustees, government welfare programs (e.g. , Medicare) , and employee entitlement programs. [ 0005] Schemes and programs are not restricted to government-based programs and may be established by any organisation to provide allowances/entitlements to users. Schemes and programs may also control the provisioning of services from a set of selected service providers against the allowance rules associated with the particular scheme. Many private companies already have similar scheme/funding structures. Such private companies include, for example, health insurance, property insurance, and accident insurance companies.
[ 0006] FI G. 1 is a schematic representation 100 illustrating operation of an existing scheme/program in which a single service provider organisation is approved by the scheme to provide services to participants within the scheme. FI G. 1 shows a participant 105 receiving services from a single service provider organisation 120. The service provider organisation 120 is the only provider approved for the scheme and the service provider organisation 120 receives funding from the scheme/program 1 10 to provide the services. The participant 105 cannot use another service provider 130.
[ 0007] FI G. 2 is a schematic representation 200 illustrating operation of an existing scheme/program 210 in which one or more service providers 220, 230 are approved by the scheme to provide services to participants within the scheme/program . The services are delivered to a participant 205 by the respective service providers 220, 230. The service providers 220, 230 then subm it claims to the scheme/program 21 0 in relation to the delivered services. Unfortunately, in this case only the first service provider 220 associated with a first claim is reimbursed by the scheme/program 210, as the funds allocated under the scheme have been exhausted. The system 200 does not include any checks to prevent service providers 230 from providing services after funds associated with the scheme have been exhausted.
[ 0008] The current way a participant receives services from a service provider as part of a scheme or program , and the manner in which an operator of the scheme or program compensates the service provider, broadly follows the following steps:
a) the scheme or program operator authorises the participant (or an authorised carer associated with the participant) to access some goods/ services (an entitlement) ;
b) the participant (or carer) manually searches for a suitable service provider to provide the goods/ services; the participant (or carer) orders the goods or services from a selected service provider;
the selected service provider collects relevant entitlement information from the participant (or carer) ;
the service provider provides the goods and/or services to the participant ; the service provider submits an invoice to the scheme or program operator using the entitlement information and details about the actual service (such as cost, time, and services rendered) ; and
the scheme or program operator pays the service provider.
The current claim ing process has at least the following issues:
entitlement information must be passed between several entities, often in formats requiring manual entry and checking which can cause errors and is time consuming, causing delays;
searching for a suitable service provider that offers the goods and services which are valid for a particular participant under a given scheme or program involves searching one or more information sources and contacting service providers to confirm validity and availability;
invoice data requirements of the scheme or program operator are typically more rigorous than standard tax invoices and also commonly vary between schemes, making it difficult for a service provider to comply with the requirements of a nominated scheme and it is particularly onerous when a service provider operates across m ultiple schemes;
service provider organisations/ aggregators do not have timely information regarding work undertaken by sub-contractors and often receive invoices from sub-contractors too late to include them in the relevant billing cycle ( i.e. , a service provider aggregator often experiences difficulties in invoicing expenses to a scheme operator, as the service provider must not claim costs before the service provider has received invoices from the relevant sub-contractors) ; payment from the scheme operator to the service provider is often delayed due to processing, checking , and correcting of subm itted invoices;
the service provider is usually unaware at the time of receiving a booking request from a participant whether the entitlement permits the provision of the goods or services offered by the service provider ( I n some schemes, the service provider is not able to check the validity of the claim until the service has already been rendered - leading to confusion and dissatisfaction) ; and g) the various parties with an interest in a claim (e.g. , broker, aggregator, and carer) are not made aware that a service provider has provided the goods or services to a participant.
[ 0010] Standard claiming systems, such as the HI CAPS health claims and payment scheme operated in Australia, provide a point-of-service device for use in processing a claim , whereby the point-of-service device checks some claim data and authorises a payment. However, this is not integrated with any booking or pre-authorisation process, nor does it allow for entitlements to be "reserved" for future services. Thus, it is not possible to control the manner in which the service is provided. That is, existing systems do not control which service providers may be engaged to provide the service or when such a service may be provided. I n addition , if a participant is entitled to 10 hours of service under a particular scheme, and a "service provider aggregator" associated with that scheme has booked only 1 hour of service relating to the participant , then the chosen service provider can still potentially claim the entire 1 0 hours.
[ 001 1 ] Electronic com merce platforms exist for particular schemes, whereby the platforms provide facilities through which service providers can advertise their services and in some cases even accept orders. However, these systems are not aware of claim entitlements associated with an individual participant. This makes it a difficult manual task to search for specific items which satisfy the rules of a participant's plan under a particular scheme. Also, service providers are at risk of taking bookings or providing goods without assurance that the claim is authorised and will be reimbursed.
[ 0012] Thus, a need exists to provide systems which provide enhanced goods and services search, listing and booking abilities in an electronic marketplace and an ability to simplify and control the pre-authorisation , reservation, validity, claim ing, reimbursement and settlement process for service providers. Summary
[ 0013] The present disclosure relates to a method and system for the management of claim-related services.
[ 0014] I n a first aspect, the present disclosure provides a method for receiving a booking for a service at an eMarketplace comprising :
receiving an access request for a user to an eMarketplace server, said user being associated with participant profile information referencing a set of entitlements;
producing a set of available services, wherein the set of available services is produced based on entitlement information derived from said set of entitlements and said access request ;
receiving a booking request for at least one instance of a selected one of said available services, said instance to be provided by one or more service providers;
approving each instance based on entitlement information derived from said set of entitlements;
creating a work order that comprises an approval for one or more service providers to render one or more instances of said selected available service; and
storing the work order in a database.
[ 0015] I n one arrangement, the method further includes the step of adjusting entitlement information to reflect the work order.
[ 0016] I n a second aspect, the present disclosure provides a claims management system comprising :
a centralised server coupled to a com munications network, said server including : a processor; and
a memory for storing:
participant profile information associated with a user, said participant profile information referencing a set of entitlements; and
a computer program that when executed on said processor performs the steps of :
receiving from a client device, via said communications network, an access request for said user;
producing a set of available services, wherein the set of available services is produced based on entitlement information derived from said set of entitlements and said access request ; receiving a booking request for at least one instance of a selected one of said available services, said instance to be provided by one or more service providers;
approving each instance based on entitlement information derived from said set of entitlements;
creating a work order that comprises an approval for one or more service providers to render one or more instances of said selected available service; and
storing the work order in said memory.
[ 0017] I n one arrangement, the computer program, when executed on the processor, performs the further step of adjusting entitlement information to reflect the work order.
[ 0018] I n a third aspect, the present disclosure provides a method for processing a work order at a claims management server, said method comprising the steps of :
receiving an access request for a service provider, wherein the service provider is associated with service provider profile information ;
receiving from the service provider a service indication associated with a work order, said work order providing pre-authorised approval for said service provider to render a service to a participant registered with a scheme associated with said claims management server;
validating said service indication based on said work order and said service provider profile information ;
sending a response indicating that said service indication is valid; and processing said work order in response to the service indication.
[0019] I n a fourth aspect, the present disclosure provides a method for transmitting a service indication for a work order from a claim processing device, said work order providing pre-authorised approval for a service provider to render a service to a participant registered with a scheme, said method comprising the steps of :
identifying the work order;
sending an access request for said service provider, wherein the service provider is associated with service provider profile information stored in a claims management server; and sending a service indication associated with said identified work order, said service indication corresponding to a service rendered by said service provider to said participant.
[0020] According to another aspect, the present disclosure provides an apparatus for implementing any one of the aforementioned methods.
[ 0021 ] According to another aspect, the present disclosure provides a computer program product including a computer readable medium having recorded thereon a computer program for implementing any one of the methods described above.
[ 0022] Other aspects of the present disclosure are also provided . Brief Description of the Drawings
[ 0023] One or more embodiments of the present disclosure will now be described by way of specific example(s) with reference to the accompanying drawings, in which :
[ 0024] FI G. 1 is a schematic representation illustrating operation of an existing scheme/fund in which a single service provider is approved by the scheme;
[ 0025] FI G. 2 is a schematic representation illustrating operation of an existing scheme/fund in which m ultiple service providers are approved by the scheme;
[ 0026] FI G. 3 is a schematic representation of a claim management system in accordance with the present disclosure;
[ 0027] FI G. 4 is a schematic block diagram representation of a claims management system of the present disclosure;
[ 0028] FI G. 5 is a schematic block diagram representation illustrating connectivity of various parties to a claims management platform , according to an embodiment of the present disclosure;
[ 0029] FI G. 6 is a schematic representation showing a flow of physical and computer data items representing goods or services through a claims platform , according to an embodiment of the present disclosure;
[ 0030] FI G. 7 is a schematic representation showing invoicing and payment interactions for services rendered under a Service Provisioning Scheme;
[ 0031 ] FI G. 8 is a schematic representation showing a functional decomposition of one embodiment of a claims platform , according to an embodiment of the present disclosure; [ 0032] FI G. 9 shows a system architecture for an implementation of a claims management system , according to an embodiment of the present disclosure;
[ 0033] FI G. 1 0 illustrates data relationships in a claims management system , according to an embodiment of the present disclosure;
[ 0034] FI G. 1 1 illustrates a process for creating a plan, according to an embodiment of the present disclosure;
[ 0035] FI G. 12 illustrates an eMarketplace for discovering products and services and conducting transactions and having services provided , according to an embodiment of the present disclosure;
[ 0036] FI G. 13 illustrates an eMarketplace for finding products and services and conducting a claims service transaction, according to an embodiment of the present disclosure;
[0037] FI G. 14 illustrates an eMarketplace and associated connectivity and interactions, according to an embodiment of the present disclosure;
[0038] FI G. 1 5 illustrates a Participant service checkout view, according to an embodiment of the present disclosure;
[0039] FI G. 1 6 illustrates a Participant portal , according to an embodiment of the present disclosure;
[0040] Fl G. 1 7 illustrates filtering goods and/or services for display in an eMarketplace, according to an embodiment of the present disclosure;
[0041 ] FI G. 1 8 illustrates participant interactions, according to an embodiment of the present disclosure;
[0042] FI G. 1 9 illustrates participant interactions for a payment process, according to an embodiment of the present disclosure;
[0043] FI G. 20 illustrates assigning items to a work order, according to an embodiment of the present disclosure;
[ 0044] FI G. 21 shows a carer screen view, according to an embodiment of the present disclosure;
[ 0045] FI G. 22 illustrates a participant's interactions to submit a reimbursement claim , according to an embodiment of the present disclosure; [ 0046] FI G. 23 illustrates an example of a participant and service provider interactions, according to an embodiment of the present disclosure;
[ 0047] FI G. 24 illustrates a flow of actions leading to an authorisation of a claim charge against a purchase, according to an embodiment of the present disclosure;
[ 0048] FI G. 25 illustrate a flow of ClaimCharging and settlement to a service provider, according to an embodiment of the present disclosure;
[ 0049] FI G. 26 is a Service Provider Portal view, according to an embodiment of the present disclosure;
[ 0050] FI G. 27 illustrates ClaimCharge submission, according to an embodiment of the present disclosure;
[0051 ] FI G. 28 illustrates settlement of a charge against a work order (claim) , according to an embodiment of the present disclosure;
[0052] FI G. 29 illustrates registration of a user, according to an embodiment of the present disclosure;
[0053] FI G. 30 illustrates registration of a service provider and Service Provider Scheme Participation, according to an embodiment of the present disclosure;
[0054] FI G. 31 illustrates registration of a carer/participant, according to an embodiment of the present disclosure;
[0055] Fig. 32 is a schematic block diagram representation of a system that includes a general purpose computer on which one or more embodiments of the present disclosure may be practised ; and
[0056] Fig. 33 is a schematic block diagram representation of a system that includes a general mobile device on which one or more embodiments of the present disclosure may be practised. Detailed Description
[0057] Method steps or features in the accompanying drawings that have the same reference numerals are to be considered to have the same function(s) or operation(s) , unless the contrary intention is expressed or implied.
Overview
[ 0058] The present disclosure provides an electronic marketplace (eMarketplace) server adapted to receive a booking request from a user for a service in relation to a set of available services authorised within the marketplace. The set of available services presented to the user for selection depends on entitlement information associated with that user. On receipt of the booking request, the server issues a work order (a support or service assignment or an 'earmark' or, more generally, an 'agreement') that constitutes authorisation for a selected service provider to render one or more specific services based on the booking requests. The server stores a copy of the work order for use in later reconciliation when the selected service provider submits a claim based on the issued work order.
[ 0059] I n this specification, unless the context suggests otherwise, a participant (or client) is a person who is approved to "participate" in a scheme (or program) and receives a service by a service provider. Such a participant may be, for example, a person insured by an insurance provider, whereby the scheme relates to terms of a health insurance fund operated by the insurance provider. I t is to be understood that references throughout this specification to a scheme also encompass a program or other organised activity, and is not to be construed in a limiting sense.
[ 0060] I n this specification, unless the context suggests otherwise, a scheme or program is a combination of funder, broker, service provider aggregator, and the holder of the funds account. Examples include, but are not lim ited to, National Disability I nsurance Scheme (NDI S) , Aged Care, Transport Accident Commission (TAC) , and WorkCover NSW.
[ 0061 ] I n this specification, unless the context suggests otherwise, a funder is a governmental insurance scheme or other funding program that justifies the need for the program and provides the funding or a private sector company (e.g. , an insurer) .
Examples of funders include NDI S and TAC.
[ 0062] I n this specification, unless the context suggests otherwise, a carer is a person who looks after the interests of a participant if a participant is not able to self-manage their own claims, bookings, and/or service provider interactions. Often , a carer is the same person that assists the participant in other matters. For example, a carer may be a husband or wife of a person with disabilities. Professional carers also exist.
[ 0063] I n this specification, unless the context suggests otherwise, a broker is an institution or individual that provides consultancy to participants, prospective participants (and , where appropriate, associated carers) to determine product and service solutions across a number of service providers and product providers. An example of a broker is an insurance company or accounting agency, such as Ernst & Young ( EY) .
[ 0064] I n this specification, unless the context suggests otherwise, a service is a treatment, procedure, good , or consultation that is provided under a scheme or program to a participant in that scheme or program . Typically, such a service aims to assist, improve, or rehabilitate the participant . Examples of a service may include, for example, physiotherapy, transport, or dentistry.
[ 0065] I n this specification, unless the context suggests otherwise, a service provider (SP) is an individual or business that provides a service to a participant . Examples of a service provider may include, for example, a physiotherapist, psychologist, a cleaner, or a driver.
[ 0066] I n this specification, unless the context suggests otherwise, a service provider aggregator is a larger service provider providing comprehensive service packages operating under a scheme (possibly a one-stop shop) . The service packages may include in-house services and also services performed by external service providers. External providers are generally paid by the service provider aggregator, rather than by a scheme operator. Examples of a service provider aggregator include, for example, Just Better Care and Northcott.
[0067] I n this specification, unless the context suggests otherwise, a claim is a case of one specific incident and the total service request of one participant with a
scheme/program relating to the specific incident. Depending on the scheme and the implementation, an "allowed claim" may be associated with one or more goods and/or services. For example, an "allowed claim" in relation to a participant of a health insurance scheme may relate to a service request by that participant for 1 hour of physiotherapy. A service provider that renders the 1 hour of physiotherapy lodges an invoice, in the form of a ClaimCharge, to the scheme or program for payment of rendered services. [0068] I n this specification, unless the context suggests otherwise, a session refers to the total activities of a participant for one service provider on one occasion (usually on one specific day) . A session may include the service provider's journey to the participant and the delivery of several support items. An example of a session may include, for example, a taxi to a medical centre, dentistry procedures, provision of a new toothbrush, and taxi home. Another example may be a physiotherapist driving to a participant's home, providing physiotherapy services, and the physiotherapist driving back to the physiotherapist's office.
[ 0069] I n this specification, unless the context suggests otherwise, an entitlement (plan) is a granted approval by a scheme operator to a participant of a scheme of a specific service item to a specific quantity delivered by a specific service provider type or a specific service provider. Examples are 5 hours of physiotherapy or $1000 of psychological consultation.
[0070] I n this specification, unless the context suggests otherwise, a plan includes a set of one or more plan-items. For example, a plan may include a list of allowed/fundable items for a specific participant, such as mobility training, physiotherapy, and/ or hearing- aid.
[0071 ] I n this specification, unless the context suggests otherwise, a plan-item is a permission (e.g. , authorization and entitlement) pertaining to a specific item-code ( item-codes represent items { e.g. services and/or goods} that are available under a scheme) .
[0072] I n this specification, unless the context suggests otherwise, a booking is an act of ordering services by a participant (or their proxy - e.g. , an associated carer) . A booking may include the type of service to be delivered and/or a time for that service to be rendered. Examples are ordering a physiotherapy session or making a dental appointment .
[ 0073] I n this specification, unless the context suggests otherwise, a work order is a sub-set of an entitlement or plan that is a certain set of services with a budget targeted at a particular service provider. Such a work order may include pre-authorisation of a monetary amount for the service(s) to be rendered , an ability to specify the service(s) to be rendered, the quantity of those services, the service provider to render the service(s) and possibly temporal lim itations. The temporal limitations may define a time period after which the work order will expire. The temporal limitations may also specify a particular time period during which the services may be rendered, such as to coincide with an off- peak delivery period for those services. The work order optionally provides for the assignment of one plan item (or a fraction thereof) to a specific service provider or to be charged against by any registered service provider.
[0074] I n this specification, unless the context suggests otherwise, a ClaimCharge is an act of authorizing and charging a service that has been rendered by a service provider, for example, providing an invoice. A ClaimCharge includes a set of one or more claim- items. An example of a ClaimCharge is when a service provider, who is assigned to deliver a certain service to a participant registered with a scheme, delivers this service and consequently "claims" (or charges) the provision of that service against the scheme operator in order to receive payment.
[ 0075] I n this specification, unless the context suggests otherwise, a claim-item is an item that refers to a specific service provider and specifies an item-code. An example is a claim on rendered physiotherapy services.
[ 0076] I n this specification, unless the context suggests otherwise, an item-code library is a list of support items, typically covered by a funder under a certain scheme.
[ 0077] I t will be appreciated by a person skilled in the art that the above descriptions are indicative and not restrictive and the same or sim ilar functionality offered by aspects, embodiments, and arrangements of the present disclosure may have different natural language meanings in different applications. For example, a participant is not lim ited to a single person, but m ight be any person authorised to act on a policy or even a corporation or body insured as a single entity on behalf of employees or members.
Sim ilarly, a service is not lim ited to only health services and may also relate to motor vehicle repair services, home and property insurance, government sponsored buy-back program (guns, sun-tanning equipment) , and the like.
Description of Embodiments
[ 0078] The present disclosure provides a claims management system that may be implemented using a cloud-available server. The present disclosure also provides a description of one or more methods by which a claim transaction can be processed by an end-user and a service provider associated with such a claims management system. I n particular, the present disclosure provides an e-commerce marketplace for claim transactions. The marketplace presents a tailored set of available goods and services to a participant , according to benefits and constraints defined by at least one plan of at least one scheme to which the participant has subscribed. The present disclosure also provides a system which allows participants and service provider aggregators to order services - typically from the marketplace. The present disclosure also provides a system which provides for validation of an order, according to benefits and constraints defined by at least one plan of at least one scheme to which the participant has subscribed. The present disclosure further provides one or more claiming devices that allow service work orders to be claimed against by a service provider as the services are provided to the participant . Such claim ing means include, for example, a software application ("app") executing on a computing device accessed by the service provider, a web-based portal, or a combination thereof.
[ 0079] FI G. 3 is a schematic representation of a claim management system 300 in accordance with the present disclosure. The system 300 includes a claims platform 350 that comm unicates with a scheme/program 310 and manages the selection of services by a participant 305, the authorisation of work orders, the rendering of services, and payment upon service delivery by one or more service providers 320, 330.
[ 0080] The claims platform 350 is a system for processing claims, comprised of three elements:
a) a claims system (a claim processing engine - incorporating portals for various user groups) ;
b) a services (and goods) eMarketplace; and
c) a claim processing device (service provider app/portal) .
The claims platform 350 allows for the creation of an authorised work order, which dictates the work a service provider is authorised to perform for a participant under their care. This authorised work order is then able to be claimed upon (charged) by the service provider one or more times using a claim processing device to allow for payment.
[ 0081 ] FI G. 4 is a schematic block diagram representation showing an overview of a system 400 for implementing a claim management system in accordance with the present disclosure. The system 400 shows several devices controlled/owned by various parties and how those parties and devices access and comm unicate with other components of the system 400. I n particular, the system 400 includes a com munication network 450. The com munication network 450 may be implemented using a dedicated com munications link, a local area network (LAN) , a wide area network (WAN) , the I nternet , a
telecomm unications network, or any combination thereof. [0082] The system 400 also includes a claims system and marketplace 430 that includes an eMarketplace portal 432, and administration portal 434, and a database server 436.
[0083] The system 400 further includes a set of service providers 41 0, comprising one or more service provider organisations or individuals. I n this example, the set of service providers 410 use mobile software applications 414 for home services or service provider individuals to communicate with the claims system and marketplace 430 and other entities of the system 400. The set of service providers 410 alternatively, or in combination with the mobile software applications 414, uses patient management systems adapted to com municate with the server 430.
[ 0084] The system 400 further includes a set of participants and carers 420, who can use mobile apps and/or browser-based webpages to com municate with the claims system and eMarketplace server 430 and other entities in the system 400.
[ 0085] The system of FI G. 4 also includes a set of schemes/programs 440, each of which uses a broker portal or an application programming interface (API ) to brokers' systems or an administration portal for self-managed schemes to comm unicate with other entities in the system 400, including the claims system and eMarketplace 430.
[ 0086] I n the context of the system 400 of FI G. 4, the respective entities and interfaces through which they communicate in relation to the system 400 are described in Table 1 below.
Actors and the typical interfaces of the claims system
Actor Typical User Interface Description of user
Broker Plan Manager Platform A person who establishes participants' plans.
A person who updates a plan and manages it.
A person who assigns plan managers to manage a plan.
Broker eMarketplace A person who manages a plan and visits the
marketplace on the plan's participant's behalf. Customer Portal
Plan Plan Manager Platform A professional service provider managing a
participant's plan and authorised to act on their
Manager
behalf.
Plan eMarketplace A person who manages a plan and visits the Manager Customer Portal marketplace on the participant's behalf.
Carer Plan Manager Platform A private carer managing a participant's plan and authorised to act on their behalf.
Carer eMarketplace A person who manages a plan and visits the
Customer Portal marketplace on the participant's behalf.
Participant Plan Manager Platform A person who can view their own plan and
transactions.
A person who may self-manage their own plan.
Participant eMarketplace A person who self-manages their plan and visits
Customer Portal the marketplace on their own behalf.
Public user eMarketplace A potential or not signed-in participant.
Customer Portal
Service Service Provider user A service provider operating as an individual.
Provider management An administrator with a service provider who
Admin initially registers a service provider organisation and enables SP deliverer to self-register under their organisation.
Service eMarketplace Service An administrator with a service provider who
Provider Provider Admin Ul uploads/modifies catalogues and service
categories.
Admin
Service Service Provider Ul An employee or assistant of a service provider
Provider (web, mobile) organisation who actually delivers the service to a recipient.
Deliverer
Service Service Provider Ul A service provider individual who delivers the
Provider (web, mobile) service autonomously (w/o a SP organisation).
Individual
Scheme Admin Ul An external administrator who manages users of a support scheme.
Admin
App Admin Admin Ul An internal administrator who manages scheme settings.
Table 1 [0087] FI G. 5 is a schematic block diagram representation showing various actors and how those actors interact with several parts of a claim management platform 500. The claims platform includes a plan manager portal 510 and a service provider portal 520. The plan manager portal 510 provides user and application interfaces to establish plans and allows other involved parties to use these plans to place bookings (and create work orders) and purchases. The service provider portal 520 enables the service providers to validate work orders and charge for provided services (or otherwise indicate status changes or notes on a work order) .
[0088] An eMarketplace allows a participant or carer (an authorised person who acts on behalf of the participant) to find appropriate services and products and directly order or pay with scheme/program funds. The eMarketplace may also be available to the public in order that the public (i.e. , users who are not yet registered with the scheme) can browse the services. Service providers can also access an eMarketplace adm inistration interface to manage their catalogue and offerings (this can also be entered by other parts of the system, but direct editing by the service provider helps distribute responsibility of ensuring accuracy on the offering can be made by the parties most interested/affected) .
[0089] The platform allows for administrators (via the Scheme Adm inistration interface and the Participants Overview I nterface) to manage several participants across schemes, manage several plans across schemes per participant, manage personal funds per participant via an electronic wallet to facilitate co-payments across plans, and oversee plans (e.g. , states status) and be notified when action is required.
[0090] The platform allows participants and carers (via the Customer Portal) to: find services and products in an eMarketplace that is configured with the user's needs, allowances/entitlements and preferences; place orders with plan funds and/or traditional payment methods; request and submit quotes; communicate (bi-directionally) with providers; and display transaction history, rate services and products.
[0091 ] FI G. 6 is a schematic representation of a flow 600 showing various actors and their "real world" items/ actions and how they map to their representations in the system . The flow 600 includes an outer cycle and a m iddle cycle. Around the outside of the outer cycle, the actors can be seen as scheme/program, broker, participants and service providers. The m iddle cycle shows an item-code library, a plan, a work order and a ClaimCharge. [0092] An item-code library stores a list of items (services and/or goods) that are available under a given scheme. The item-code library is connected to item-codes, shown in the inner cycle. The item-code library functions as a pricelist for the stored list of items, whereby a scheme/program can define limits for the services and goods that are allowed to be funded under that scheme.
[ 0093] A plan is based on the available services and the participant's needs and treatment or outcome goals. A broker may establish a plan with a subset of specific items or categories. The participant or carer then books services from the plan-items.
[ 0094] The selection of plan-items (typically via the eMarketplace interactive web pages, but also possible by a web service REST/SOAP or other automated means) and the making of a booking (typically by eMarketplace, but also by other automated means) creates a work order in the system. The work order represents a "pre-authority" for services and goods to be provided. The work order is available in the system to be assigned to a specific service provider, by for example a plan manager or the participant. The work order may also be made available in the system so that an arbitrary (but authorised) service provider can assign the work order to themselves (typically by use of a service provider interface - app or portal) , however other models are supported by the system for service providers competing for the right to service (be assigned) the work order. One such competition is a reverse auction market place where service providers bid on price and other service dimensions for exclusive assignment .
[ 0095] A ClaimCharge is an indication by a service provider that they have partially or completely fulfilled a work order and wish to charge for their services. The services rendered by the service provider are captured as ClaimCharge items which are pre- authorised in the work order, which - subject to the prevailing funding methodology of the scheme/program - allows for close to immediate settlement.
[ 0096] The following aspects have a data representation in the claims system which is used in the delivery and charging of goods and services in the claims management system .
[ 0097] A scheme comprises plan categories, SP categories, item-codes (potentially from several libraries from m ultiple sources and even multiple schemes) and also optionally properties of plan items (e.g. , plan categories or item-codes) and/or properties of plan budget (per item or total ; per unit-price or total) . [0098] An item-code library (pricelist) links plan categories to SP categories - e.g ., item- code a (plan category x, SP category X) or item-code b (plan category y, SP category Y) .
[ 0099] A plan comprises plan items. Plan-items can be a category-individual where plan categories have an individual budget (e.g . , Plan Category x - budget n or Plan Category y - budget m) , item-code specific where item-codes with individual price and quantity or individual budget (e.g. , item-code 1 - budget n and item-code 2 - amount x; price y) or category total where plan categories have total budget only (e.g. , Plan Category x and Plan Category y with Total Budget : budget n) .
[00100] A ClaimCharge (claim) is a group of ClaimCharge items (also referred to as claim items) . ClaimCharge items can be plan categories with price and quantity or item-codes with price and quantity.
[00101 ] FI G. 7 is a schematic representation showing flows 700 of invoicing and payment interactions for services rendered under a service provisioning scheme. The claims platform manages services and related activities so that the claims engine can automate resulting payment-related activities.
[00102] The f under defines services and the rules for authorisations. Plans are then created by brokers or service provider aggregators. Services are rendered by the service providers to the participants. After the services have been delivered, the ClaimCharge (invoicing) is made in order to start the settlement process. This can be made directly by the service provider or in some cases may be aggregated. The payment processing can take place either by the funder's own settlement mechanism or can be performed in the claims platform ( in order to expedite payment) .
[00103] FI G. 8 is a schematic representation showing a functional decomposition of one embodiment of a claims platform 800 in accordance with the present disclosure. FI G. 8 shows connectivity, API s/ services and data sources/sinks for various parts of a claims management system . I n particular, FI G. 8 shows the modularity of services and interactions with external services. The claims platform 800 is compatible with external frontends and can incorporate external procedural services into the claims process or process externally managed data.
[00104] The claims platform 800 may be implemented using a brokerage module 810, a front end module 820, an authentication and permissions module 830, an ecom merce module 840, a claims module 850, an analytics module 860, and a banking module 870. The platform 800 optionally includes other modules relating to plans, transaction data, participants, work orders, service providers, data import/ export, wallet functionality, schemes, item-code libraries, broker and PMs and Rules. Most modules can connect to an Enterprise Resource Planning (ERP) system for data analytics and business insights. A bus/queue/message delivery system is present to allow data and message exchange between the different modules.
[ 00105] The brokerage module 81 0 comprises a Plan Broker Portal module 815.
[ 00106] The front end module 820 presents various interfaces and portals to the user and has connectivity for various web server technologies.
[00107] Third party interfaces 880 also exist for various adm inistrative functions
(participant , plan managers, and service provider) and also to facilitate connectivity to an external patient management system 882, ecom merce platform interface 884, a " Pay Anyone" integration module 886 and additional "Reimbursement Services" integration module 888.
[ 00108] The authentication and permissions module 830 provides single sign-on services via user sub-modules and permissions sub-modules. I t contains a database which may be shared with other databases in the system .
[ 00109] The ecommerce module 840 services the eMarketplace. The ecommerce module 840 contains submodules for presenting various aspects of the marketplace and for acting upon the booking , fulfilment and payment of services and goods. The ecommerce module 884 also contains a database which may be shared with other databases in the system . The payment sub-module connects to external payments services (e.g. , payment gateways, PayPal) for the payment of self-funded products and services.
[ 001 1 0] The Claims (ClaimCharge/l nvoice) module 850 provides functionality for processing state changes on a work order including validation that a ClaimCharge is allowed on a work order. The Claims (ClaimCharge/ l nvoice) module 850 comprises sub- modules for a settlement engine that drives a sub-module for payment and invoicing. The Claims (ClaimCharge/l nvoice) module 850 connects to the Bank module.
[ 001 1 1 ] The bank module 870 includes a payment processing module (or one per supported banking interface) . When a QaimCharge is to be settled, this payment processing module sends commands and ensures correct behaviour of the payment being seen through to completion . [001 12] The analytics module 860 runs various analytical and reporting processes and makes these available via an API and also presents the data to the ERP. The analytics module 860 has connectivity to the database across the entire system .
[ 001 13] FI G. 9 shows an architecture 900 for an implementation of the claims system depicted in FI G. 8.
[ 001 14] FI G. 1 0 shows several data entities and their dependencies for an
implementation 1000 of the claims system depicted in FI G. 8.
[001 1 5] I tems in such an implementation 1 000 may include, for example, but are not limited to, personal supports and training, accommodation/tenancy, assistance access/maintain, assistance prod-personal care/ safety, assistance integrate into school/education, assistive products, household task, assistance life stage, transition, assistance personal activities, assistance travel/transport, behaviour support, comm unity nursing care, daily tasks/shared living, development-life skills, early childhood supports, household tasks, interpret/translate, physical wellbeing, plan management, therapeutic supports, and training-travel independence.
[001 1 6] Assistive products and equipment in such an implementation 1000 may include, for example, but are not limited to, assistive equip-recreation , communications and information equipment, equipment special assess setup, hearing equipment , home modification, personal mobility equipment, vehicle modifications and vision equipment.
[001 1 7] Fl G. 1 1 shows a process 1 1 00 to establish a plan via the plan manager portal. A plan represents various aspects of the entitlements of a participant .
[001 1 8] The claims platform can support different types of plans. According to one embodiment , the following plans are supported :
(i) a "Category specific plan with plan total" plan where the entitled services are only lim ited by service categories and the total funding is not specifically distributed among these plan items;
(ii) a "Category specific plan with item total" plan which defines the distribution of the total funding over the included plan-items; and
(iii) an "item-code specific plan" which specifies the services allowed by defining a specific item-code per plan-item.
[001 1 9] A plan is applied to a participant and given an optional expiry date. Different actions are then taken depending on the service plan . [00120] For a "Category specific plan with plan total" , items can be added under a plan- category and then a total for scheme funding is set and a total for self-funding is set.
[00121 ] For a "Category specific plan with item total" , items are added under a plan- category and for each item an amount is set for scheme funding and self-funding.
[00122] For an " item-code specific plan" , specific items are added as an item-code and for each item an amount is set for scheme funding and self-funding. The items are typically added to the system in bulk via a database/dataset import and uploaded into the claims system or received via integration between the claims system and a scheme provider or service provider system . Additions and updates can be done on an individual item basis also. Modifications can be made in the admin portal on details of an item manually.
Services eMarketplace
[ 00123] FI G. 12 depicts an eMarketplace 1200 that presents participant-specific offerings to participants and allows for the booking, provisioning and settlement of payments for services.
[00124] The scheme/program provides participant data and plan data (comprising entitlement data) to the claims system . The participant data and plan data may be in addition to existing user data for the participant stored in the system or a related system (for example, from previous use by the user of the system such as a registration process or prior usage on the current scheme or other schemes) .
[00125] Systems for implementing different schemes/programs vary depending on the particular application and implementation , but generally the data specifying the participants and their associated entitlements follow a sim ilar format. Participants have personal details and a scheme identifier (a) . Plan data may contain a series of 'item- codes', a value claimable, and validity dates. Depending on the scenario, a participant can be restricted to a single plan or can have multiple plans.
[ 00126] The data specifying the participants and their plan/entitlements can be transm itted to the claims system via a range of means, and may be sent ahead of time and stored in the claims system or requested by the claims system on an as-needed basis.
[ 00127] Service providers are varied in their size and complexity, from large organisations employing thousands of people and providing a m ultitude of products and services, down to sole traders offering a specific service. Service providers provide their catalogue data to the service provider e-marketplace, thus specifying the goods and services to be offered in the market (b) . The scheme operator may also provide catalogue data, which may initially be done in bulk with catalogue revisions being done by the service provider.
[00128] The eMarketplace offers a variety of means to accept a catalogue of products and services from service providers (b) , such as an online data entry mechanism or an API for receiving a direct data feed. The catalogue data includes the descriptive details for the item , reference to "item-codes" of one or more schemes, and may include a wide range of other attributes, such as price, images, service availability, options, meta-data, or extras.
[00129] The eMarketplace may offer goods and services in different ways and from different sources. The eMarketplace might aggregate offerings from m ultiple vendors and across m ultiple schemes. The eMarketplace might also be a single vendor for a single scheme.
[00130] The eMarketplace provides potential customers with a searchable listing of catalogue items and a means by which to purchase those items. However, in relation to making purchases via a claim from a scheme, a standard eMarketplace is deficient because it does not take into account the entitlements that are allocated to a participant when that participant is attempting to find suitable services.
[00131 ] The service provider eMarketplace uses the data from the service provider catalogue (b) along with the participant's plan from the scheme operator (c) to determine which products are able to be purchased by (or on behalf of) a participant.
[00132] When a participant visits the eMarketplace, the eMarketplace presents the participant with a user-specific view of the market offering (d) , which is modified according to the plan data of the participant (c) .
[00133] According to another embodiment, a person authorised to act on a participant's behalf (e.g. , carer; plan manager; service coordinator; supports coordinator or broker) can also visit the eMarketplace and be presented with a user-specific view (an impersonated view) of the market offering (d) , which is modified according to the plan data of the participant with which the authorised person is associated (c) .
[00134] A customer (a participant or person authorised to act on a participant's behalf (e.g. , carer; plan manager; service coordinator; supports coordinator) is able to log into the eMarketplace as a means of identifying themselves to the e-marketplace. The eMarketplace can then present the catalogues in a way which is more convenient to the customer and speed up the service selection process (d) .
[ 00135] The customer is able to make a purchase request, which is lodged in the claims system as a work order (e) including data relating to the participant, plan, service provider, and catalogue item and the validity and authorisation for service transactions to be made under the work order.
[ 00136] Using this specific market view, the participant selects the appropriate goods or services for booking. The order or purchase is pre-authorised in the claims system (e) . This 'work order' remains in the claims system until the service provider charges the service via the service provider portal or mobile app (f) . The claims engine validates this charge request in real-time with regards to scheme and entitlement specific rules and informs both parties of the transaction result. The validation of a request may be performed independently from displaying of the goods and services and may be present as a payment option (similar to a pay with credit card or PayPal) integrated with an independent marketplace.
[ 00137] The service provider is informed regarding the work order via the service provider Portal (including mobile apps) (f) . The service provider can authorise and charge for providing a service (f) .
[ 00138] Depending on the funding model adopted by the scheme/program and whether the scheme/program provides access to a held funds account, a successful transaction (CI aim Charge/ invoice) can be settled in real time (g) .
[ 00139] The scheme operator receives relevant transaction and settlement data in the form of reporting ( h) .
[ 00140] The claims management platform facilitates the settlement of funds between the held funds account and the service provider (g) and can report any transaction data back to the scheme (h) .
[00141] FI G. 13 shows a further embodiment of the present disclosure in which an eMarketplace 1300 presents participant-specific offerings to a participant to make a booking .
[00142] The scheme operator provides participant data and plan data (comprising entitlement data) to the claims system . [00140] Service providers provide their catalogue data to the eMarketplace, thus specifying the goods and services to be offered in the market (b) .
[00141 ] The eMarketplace uses the data from the service provider catalogue (b) along with the participant's plan from the scheme operator (c) to determine which products are able to be purchased by (or on behalf of) a participant.
[00142] When a participant visits the eMarketplace, the eMarketplace presents the participant with a user-specific view of the market offering (d) , which is modified according to the plan data of the participant (c) .
[00143] The customer is able to make a purchase request, or booking, which is converted in the claims system as a work order (e) including data relating to the participant, plan , service provider, and catalogue item . The participant selects the appropriate goods or services for booking. The order or purchase is pre-authorised and remains in the claims system (e) for further processing.
[00143] FI G. 14 shows a decomposition 1400 of the eMarketplace, actors and external interfaces. The eMarketplace has a Service Provider Ul ( User I nterface) , a Broker Registration and Login Ul and a Participant/Carer Ul . The eMarketplace also includes an interface to each of a Claims engine/System , External Data, a Data Buyer
(reports/analytics/insights) system , Broker System and service provider systems.
[00144] A Web Portal module connects to a database for storing catalogue and other data. The Web Portal comprises a Shopping Cart , Preferences, a social layer (messages and comments along with product and service ratings) and a search module. The search module processes results for both product search and service search.
[ 00145] An Order Processing module enables the booking of services or ordering of goods. For an order - consisting of goods and services - to be placed, the Claim authorisation module determines whether the order is allowed. The Claim authorisation module connects to a claims engine or other data source to determine what is allowed to be ordered . The goods and services that are allowed are determined based on the participant's plan. Following, or in a related process to the order, a work order can be made in the claims system .
[ 00146] The facility also exists to take direct payment within the marketplace for an order. I n one arrangement, the claims management system imposes, or facilitates application of, a charge to the participant in relation to a co-payment or in the case of upsold/optional items that are not covered at all by the scheme or the participant's entitlements. Such charges to the participant may also relate to expediting some aspects of the goods and services, such as express delivery or out of hours services. Payment via external payment methods (e.g. , credit card, PayPal, etc.) may be initiated by the front end and essentially by-pass the claims engine, although the claims engine may optionally store records. Note that the settlement of service provider charges with "claim" funds is accomplished/initiated through the claims engine.
[ 00147] FI G. 1 5 shows a screen displayed to a participant on order checkout . When the participant has found products and/or services they wish to order on the eMarketplace and selects to check-out , the system matches items from the marketplace to available entitlements (plan) and allows the user to select the plan or plan-items in case different options are available (as multiple options from different service providers may be found) .
[ 00148] The claims platform may manage multiple sets of funding sources available to a participant . I n one arrangement, each funding source is represented by at least two accounts: a budget account ( representing the budget available from the funding source) and a cash account (representing im mediately available cash from the funding source) . Claims are authorised against available entitlements in the budget account and authorised claims are settled based on available cash in the cash account. Funding sources may be considered as being either cash-oriented or budget-oriented.
[ 00149] While dependent on the funding model adopted by a scheme/program , a participant's entitlement under a scheme/program is often budget-oriented. Budget- oriented funding sources generally have a higher budget account than a cash account. While some scheme/program funding models may provide the full amount of the budget as cash, many either provide only a portion of the cash to support the full budget ( replenishing amounts periodically or as they are spent by way of an acquittal process) or only provide funds as required to meet payments for goods and services which have been provided. Authorised work orders are generally budget-oriented, as they represent a segregation/ reservation of funds from a budget-oriented funding source. An account set up by a participant or carer for co-funding amounts which exceed entitlements under a scheme/program (sometimes referred to as the participant's "wallet") is an example of a cash-oriented funding source. For cash-oriented funding sources, the budget account and the cash account are identical and the budget account is only increased when the cash account is increased. I n the example of FI G. 15, the amount of the purchase/order exceeds the plan's allowance and the user is able to pay with 'Wallet' funds or conventional payment methods like credit cards or PayPal to make the order and confirm the booking .
[00150] FI G. 1 6 is a screen view representing several screens presented in the eMarketplace. Together, the screens are showing several ways in which searches for services, products, organisations and personal assistants can be conducted and refined/filtered.
[00151 ] The home page has several facilities on it , including registration, login , help pages and search facilities (such as quick search, find products and services, and events and activities) .
[00152] When a search is executed, for example via the homepage, the system presents a search details page. The page consists of a results pane and several filter and refinement options that may take the form of a free text field, a radio button, a range or slider or other filter mechanisms. Services may be searched for and filtered on dimensions as shown in ( 1 ) . Products may be searched for and filtered on dimensions as shown in (2) . Organisations and Personal Assistants searches provide links to contact details that may be from a separate data source and provided as a directory service. These may be searched for and filtered on dimensions as shown in (3) and (4) .
[ 00153] FI G. 1 7 shows the eMarketplace integrating data from the claims platform to display pages to the participant .
[ 00154] Service providers upload or manage their catalogues and associate each offered item to item-code libraries or Service Categories as provided by schemes/programs the service providers wish to participate in . When the eMarketplace presents available services and goods it does so by filtering the catalogue by scheme (to show only approved or allowed services with a matching item-code) and specific service provider approval . This can then also be further filtered on plan (entitlement) .
[ 00155] FI G. 1 8 shows a participant's interactions in the eMarketplace. The participant may arrive via the Plan Manager Portal or directly to the eMarketplace. Participants may self-register or have a log-in already. The eMarketplace can also display services to users that are not logged in (some embodiments restrict this public access) . Following access to the eMarketplace, the customer can discover services and products by searching or browsing over a number of dimensions/hierarchy. The eMarketplace will display a result of a discovered item. The eMarketplace when being accessed via a redirection is capable of having a search or a particular item presented to the participant.
[ 00156] The customer/participant now selects an item and the eMarketplace presents a detailed view of the selected service (or product) . At this point, it generally makes sense to ensure a user is logged in as the user/participant information is important for understanding what proportion of a booking/order is covered by the scheme/plan. I f an item requires a quote to be provided, the system takes the requests and tracks the request with the service/products provider and alerts the participant at a later time when the quote is ready. For an item with a price, the customer can place the item in a shopping cart/trolley/order pad and follow the payment process (See FI G. 1 9) . Lastly, the customer is given an option to rate the products or services, wherein any such ratings information is stored and used for customer information or feedback to the service provider or the scheme.
[00157] FI G. 1 9 shows participant interactions for the payment of an order or a check-out of their cart of selected goods and services. I f a selected item is covered by one of the participant's plans /work orders, then the purchase can be facilitated against scheme funds - depending on the item type. I f an item is not covered by the plan, then the transaction is conducted by a direct payment using an external payment authority or a Wallet kept in the system representing non-plan customer funds (which can be topped up by external payments) . Product orders are typically finalized im mediately. Services orders are typically finalized by the service provider. Depending on service type or other characteristics the system pre-approves a service in the form of a work order. After the service is provisioned, the service provider finalises the work order. Finalising causes a settlement to occur.
[ 00158] FI G. 20 shows an example assignment of plan-items to a work order. The work order may stipulate one specific service provider or allow many service providers to render services against that work order. Plan-items can be assigned to a specific service provider, several service providers or to allow several/many service providers to claim against the plan-item (e.g. , all those authorised under the scheme to provide this kind of service) . The assignment itself may dictate a specific item-code or may j ust define a Service Category. The process (executed by automated means or manually depending on available data and permissions) begins by selecting a plan item . A choice/indication of whether the work order is to be specific to a particular service provider is made ( if it is an option/requirement , then a particular service provider is provided) . A choice/indication of whether the work order is to be specific to a particular item-code is made. I f the work order is not specific to a particular item-code, then only a work order Total is provided. I f the work order is specific to a particular item-code, then item-codes are selected/provided as is a quantity and a unit price.
[ 00159] FI G. 21 shows a screen 21 00 for a carer managing a participant's plan. A carer authorised to manage a participant's plan logs onto their Plan Manger Portal and selects the participant by entering the participant's identification. Having full access to the plan as displayed by the wire-frame, the carer may navigate to the eMarketplace to find accurate services. The screen shows all participants that are under this carer. The screen also indicates the allowance consumed under a plan, the amount remaining and a transaction history.
[ 00160] FI G. 22 is a flow diagram of a method 2200 showing a participant's interactions to submit a reimbursement claim. I n this example, a service was rendered and paid for by the participant that could be covered under the plan associated with the participant, but the service was not captured under a work order. Depending on the scheme/program funding model and item-code associated with a plan-item , participants may lodge claims to reimburse relevant expenditure.
[ 00161 ] I n order to lodge this claim , the participant selects a plan if appropriate or automatically selects the plan if only one plan exists. The participant selects a plan-item (discovered by search or other mechanisms) . The claims system then checks if a reimbursement is allowed for the plan item . I f the plan item is reimbursable, then the system presents an option to "Claim reimbursement" to the participant. The participant then clicks "Claim reimbursement" and enters other relevant data, such as quantity, unit price and other data as might be specified in the plan or scheme. The platform then allows for the uploading of a receipt. The receipt may be uploaded by a file access or a camera on a smart phone/ mobile device.
[00162] FI G. 23 shows an example flow 2300 for a participant's and service provider's interactions of acquiring and fulfilling a service. The participant books a service via the eMarketplace using plan funds (that is the payment of the items is within the plan/scheme and will not require a co-payment) . The service provider delivers the requested service across several sessions until the work order is complete/ exhausted and the service provider finalizes the transaction via the Service Provider App. [00163] The participant is logged into a session in the eMarketplace. The system presents a filtered set of offerings to the participant. The participant performs a search for a specific item (in this case, item-code representing "personal domestic activities") . The eMarketplace displays results (in this case, this specific service from several service providers) . The participant selects an item (in this case, the selected item is an item with a covered/ allowed price equal to the item prices) . The participant places this item into their shopping cart ( in this case, indicating that the participant want the maximum quantity of sessions covered by the plan) . The participant selects to pay for the service via claim/scheme funds. The claims system pre-approves the payment (reserving the plan funding) and creates a work order. The claims system sends an indication to the service provider ( in this case, an email, but an 'app' notification or other message forms are also supported, including sending a call to an API in a service provider system) of the booking/work order.
[ 00164] The service provider is now permitted to work on the work order and has received a notification of the work order (and related booking) . The service provider organises with the participant when to deliver the services. I n this example, the service provider makes a home visit to the participant. I n this example, the service provider scans an identity card/item of the participant such as a bar code, Radio Frequency I D ( RFI D) , Near Field Com munications (NFC) or using Bluetooth/LE or app identification using the Service Provider App. The work orders and remaining allowance for this participant are displayed on the Service Provider App. The service provider checks that the work is covered and then performs the work. The service provider then indicates the performed work quantity against the work order. The rendering of services in this example finalises the transaction/session and causes a ClaimCharge to be sent indicating the services are complete and can be settled and that the Claims system, because of the pre-authorisation, knows that a payment can be made. The participant receives a receipt/ notice of the services rendered for their records. The information is placed in the stored transaction history associated with the participant.
[ 00165] Following this in the normal flow, then the work order is completed when the work order is exhausted.
[ 00166] I n this example, the service provider has more work to do on the work order and schedules another session to render more services. [00167] This example also shows a flow where a participant raises a dispute on poorly rendered or not delivered services. The system has dispute resolution capabilities and allows for putting a hold on or the return of funds (to both or either of the scheme and participant, as appropriate) . The system tracks the state of the work order or items as being disputed and is capable of putting a hold on the settlement of the payments for these goods and services. A refund (or removal from payment) for a disputed transaction can be initiated by the service provider or a plan manager.
[ 00168] The system also allows for the cancellation of a work order with remaining services/ allowances at the discretion of the participant or the service provider.
Service Provider Claiming App/ Mobile Site/ Portal
[ 00169] FI G. 24 shows a flow of actions leading to an authorisation of a claim (charges) against a purchase. For each claim , the claims platform identifies a set of available valid funding sources. Validity of funding sources is based on the rules of the relevant funding source. Rules may be general to the funding source (for example, dates between which funds may be used) or specific to the items and categories of items that the participant is attempting to fund from the funding source (for example, the maximum amount that will be funded for a particular item) . Funding sources may be considered pre-authorised or may require specific authorisation from the funder or a person to whom the funder has delegated authorisation (including the participant) . A successful purchase (booking) in the eMarketplace (a) occurs and this causes the creation of a work order. Purchases that are made on the eMarketplace are converted into work orders in the claims system (b) . The work order is a pre-authorised allocation of work and specifies the work which can be performed by a service provider (or allow for any registered service provider to claim/charge against) .
[ 00170] I n order to pre-authorise a claim , the claims platform first identifies an available set of funding sources. I f any funding sources are pre-authorised, the claims platform will fund the claim from those funding sources to the maximum extent permitted by the funding source. The pre-authorisation is made by processing the items in the booking under a scheme specific ruleset validating the respective items of the work order against the participant's plan. A work order can comprise an item-code, amount, validity dates, and may contain additional restrictions or rules limiting the finalisation of the transaction (counts, limits, time, valid service providers) . [00171 ] The work order effectively represents a pre-authorisation for a future set of ClaimCharges. Once the work order has been authorised , the funds are removed from the particular funding source's budget account (effectively being "reserved" for the particular work order) and are represented in a new budget-oriented funding source specifically for that work order. The new funding source becomes a valid funding source for ClaimCharges which match the relevant work order. I f a work order of significant duration (for example, greater than 6 months) is to be authorised against a cash-oriented funding source, there may be insufficient funds in the cash account to fund the entire work order. I n those circumstances, the authorisation rules require sufficient funding in the cash-oriented funding source to fund the first invoicing cycle of the work order, the budget-oriented funding source is established with a budget account and a cash account, a new budget and cash receivable account are established and the funds for the first invoicing cycle are transferred from the cash-oriented funding source's accounts (budget and cash accounts) to the work order's funding source's accounts (budget and cash accounts) and a new receivable funding source budget account is created recording the cash receivable amount owed to complete the funding of the cash-oriented funding source.
[ 00172] On each invoicing cycle, after each invoice is received and settled, if the cash has not been provided to fulfil the receivable, all parties will be notified. The notification will be repeated each week until the nominated invoicing date, in order to perm it the service provider to decline the provision of services until funds are available. Where a participant is required to authorise the funding of a claim, the participant or a person authorised to act on a participant's behalf may manually authorise the funding of the claim using the claims platform user interface or may pre-configure automatic authorisation rules.
Automatic authorisation rules may be configured to apply for a given maxim um claim value or any claim value. Automatic authorisation rules may also be configured with a delay so that the funding of the claim is automatically authorised some time after the claim is received. As the participant (or the person authorised to act on a participant's behalf) is notified as soon as the claim is received, the participant and/or other person have the opportunity to review and dispute the claim within the time period but with the knowledge that the claim will become authorised without their intervention after the nominated time period.
[00173] A ClaimCharge is processed/validated against the work order (c) to obtain payment for the services rendered. When a ClaimCharge transaction is submitted by the service provider on a claim processing device, the claim data is checked against the work order and other rules for the scheme. A response is provided to the service provider, indicating whether the claim has been successfully lodged and if not , why. The claim processing device in one embodiment is an application running on one or more mobile operating systems (a mobile app) . Such mobile operating systems may include, for example, iOS App, Android App, and Windows Mobile App. The claim processing device in a further embodiment is a device capable of sending an SMS (Short Messaging System) message (often referred to as a "text message") for which a text message with an identifier for the work order and the work conducted is sent to the claims system . The claim processing device in a further embodiment is a web-based portal accessible from a browser. An additional embodiment has this portal implemented as a mobile specific site optim ised for mobile devices. A further embodiment has this claim processing device incorporated into a Point-of-sale ( POS) terminal (e.g. , EFTPOS, or Credit Card term inal) . The POS terminal indicates the claim request to the claims engine instead of, or in addition to, other systems. Some POS terminals have a physical/soft button to perform the ClaimCharge operation. The POS terminal receives participant or work order identification entered into the device either by reading an identification such as a card/QR code/bar code/NFC or similar, either directly or via a dongle.
[ 00174] The claim processing device may be a mobile device, desktop PC, or other hardware, such as a desktop terminal or Point of Sale device. The claim transaction data may vary from scheme to scheme, but generally contains information about the participant , service provider, item-code/s, and service details such as cost, time, and description .
[ 00175] Certain embodiments have the service provider using a claim processing device (CPD) to process the charge for a claim (ClaimCharge) after services have been rendered. The CPD can also indicate other aspects of a claim/booking , partial rendering, a
" no-show", a cancellation , or other kinds of change in state.
[ 00176] For a claim made against a work order, the claim transaction data is sent to the scheme operator (d) . This may be for reporting or may also facilitate payment to the service provider (d) . The payment may also be directly settled via the claim engine ( FI G. 25) . [00177] On successful lodgement, the claim transaction data may be transm itted to the scheme operator via an agreed transmission methodology (e.g. file transfer, email, or web API ) .
[00178] FI G. 25 shows a flow of a service provider initiating a ClaimCharge. The ClaimCharge triggers the fully automated authorisation and settlement process. Where the payment processing is to take place by the scheme/program's own settlement mechanism , the scheme/program determ ines the tim ing and nature of the settlement transaction. Where settlement is to be performed by the claims platform , the timing of settlement is contingent on the cash being available for each of the identified funding sources in its associated cash account. For cash-oriented funding sources, the funds are immediately available as the funding source's budget account would only have had sufficient funds to authorise the claim if the cash was immediately available given the budget account reflects the cash account. For budget-oriented funding sources, the cash may or may not be available for settlement at the time that the claim is authorised. I n those circumstances, the claims platform will wait until the cash is available before settling the account .
[ 00179] A service provider attempts to charge a service via a claim processing device (e.g. , a Service Provider App) . The service delivered should be covered by the scheme and to initiate the payment procedure ( instead of manual invoicing) the submission is made. The claims engine validates the requests on scheme/plan based rules in real-time and, if allowed, finalises the transaction and triggers the settlement. The settlement of funds between the scheme/program 's held funds account and the service providers is facilitated overnight or as defined by the scheme/program .
[ 00180] Using the claims management system in accordance with the present disclosure, service providers need only register and maintain bank account details in one place, while still accessing a wide number of programs/ schemes.
[ 00181 ] FI G. 26 shows an example of a Dashboard 2600 of the Service Provider
Portal/App. The Service Provider Portal Dashboard 2600 provides an overview of awaiting quotes, open work orders (open orders) , and Statistics (business insights) . The service provider can directly respond to requests, quotes, orders, add com ments, and initiate a ClaimCharge or other state modification.
[ 00182] FI G. 27 shows the submission of a ClaimCharge by a service provider. [00183] I n this embodiment, there are four different modes by which a ClaimCharge may be subm itted. I f a service provider receives a product order from the eMarketplace, their interaction may be as little as accepting an order for processing/fulfilment. Provided the eMarketplace order contains a service (work order) , the service provider finalizes this transaction via a claim submission device as outlined in FI G. 25.
[00184] Alternatively, plan-items may have been assigned to many service providers, hence the participant retains the choice of which service provider to go to. I n this case, the service provider needs to identify the participant (e.g . , by scanning a card) . I f the provider is authorised to deliver the envisaged service, the transaction is finalized as above.
[00185] A different operational mode allows the service provider to create the work order via the Service Provider App - I nvoicing mode. Depending on the setup of the scheme, this ClaimCharge may correspond to the submission of an electronic invoice or an integrated validation procedure as above.
[00186] FI G. 28 shows claims/ charges settlement. The claims engine can aggregate successful transactions for each service provider and create payment orders across service providers to be transmitted to a financial institution (e.g. , a payments order file) . The financial institution processes this payment order, releases the transactions for processing (banking) , and sends a status report back to the claims engine. Based on this indication of payments being successful, the claims engine updates transactional data and sends out remittance advice to service providers. I f the status report contains errors, the system optionally notifies internal support administration to manually resolve the settlement problems.
[00187] When connecting to a financial institution , an ABA file is created (all SPs) , the financial institution processes ABA file and sends " Exception Report" , the financial institution releases transactions for processing and sends "Disbursement Report" .
Registration
[ 00188] FI G. 29 shows user self-registration . The user registration process may be generic and independent of the envisaged role ( users may also have several roles in the system administrator of one scheme, participant to another) . I f a person registers with an email address that had been used as in invitation to a specific role, the user will automatically inherit that role, once successfully registered. [00189] An unknown person who wants to operate as a carer may select the scheme they want to participate in . Depending on the scheme setting, a scheme admin may then authorise this person to receive the envisaged role.
[00190] On-boarding service providers into the system can be fully automated. This offers the benefit of minim ising customer service requirements. Service provider data is provided either by the scheme/program, or by the service provider when registering onto the platform online.
[00191 ] FI G. 30 shows service provider on-boarding. A user may register as a new service provider organisation or individual service provider and select the scheme they wish to participate in. Depending on scheme settings, a scheme may be open or closed to new service providers. Open schemes can be joined by any service providers; closed schemes reserve the right to approve the new service provider. This approval can be general or per service item relating to the scheme's service categories as managed within their item-code libraries. A service provider will register their bank account with the eMarketplace.
[ 00192] A user who has registered a scheme inherits the role of a service provider adm in for that scheme. This user may invite other persons to register as service provider deliverers and he may make himself a deliverer to use the operational portal.
[00193] FI G. 31 shows on-boarding of participants and authorisation of carers.
[ 00194] Participants are primarily imported from scheme/program's systems - via an automated connection or manually by a bulk upload or import . However, a broker, scheme admin or service provider may also establish a participant in the system . This may be done via the portal.
[ 00195] I f a user is authorised to act on a participant's behalf (plan manager; carer) this person can be invited. This invitation will grant that person the role of a carer (plan manager) and link the participant's plan to that user. That person may already be a registered claims user or register upon this invitation email.
Revenue Models for Health Schemes
[ 00196] An operator of a system as described herein may charge fees based on transactions. These fees can be charged to both the service provider and the scheme provider (f under) . The fee reflects the value to each entity. The system can charge the participant and other actors in the system . I n a typical health care scheme implementation , the system does not charge participants, but may do so. I t would be probable to charge in a private market like an insurance claims system .
[ 00197] Using the Mobile App, the service provider subscribes to the service to process claims quickly (simplicity, traceability, and overnight settlement) (and they will pay a monthly subscription) .
[00198] The scheme provider saves on manual invoicing processing (hence typically charged a fixed price per claim or item) and the service provider gets faster access to their funds (hence typically charged a percentage of value) .
[00199] The system can create revenue in several ways. For example, App Revenue. Monthly subscription sales for the Service Provider App (to individual service providers) begin. I ntegration to online services for claims made via patient management system integration and online sales.
[00200] Another example, I nvoice I ntegration . Charged to scheme
operator/funders/brokers on each invoice sent to them electronically.
[00201 ] And a further example, via Payment processing . Charged to service providers to facilitate im mediate settlement of funds.
Data Monetisation
[ 00202] The system processes several data streams that can be monetized by providing the information to the scheme provider or other bodies such as governmental oversight , the service providers for analytics/ competitive information or to private advertisers. The key factors dictating value of the data are covered - namely 'Who the customer is', 'Where they are located', 'How old they are', and 'What they Purchase'. An interface is provided by the system to provide this analytics information either as a data source or to an ERP (See FI G. 8 - 860 and 890) . Data for insights and analysis of user behaviour (web site and system access, geographic information of transactions, exhaustion of claims, most used and unused aspects of a fund , potential fraud) can be made available via an OLAP data cube or via SQL or MDX queries.
Benefits of the Claims Management System to Health (or similar) Schemes
[ 00203] Embodiments of the present disclosure offer valuable benefits to parties to the system. Embodiments of the present disclosure offer high transparency to all involved parties and discoverability of information and history. [00204] The system can ensure that any service is provided by an authorised provider to an authorised scheme participant and thus financially covered (no questions and no complaints related to these issues) and general confidence in the system the assurance that a claim is valid will bring.
[00205] Embodiments of the present disclosure offer many benefits to the
customer/participant, including not needing to collect or process invoices, not needing to pay service providers, being able to easily view history, being able to see multiple service providers, being able to purchase online, the system can be managed easily by a separate user (carer) , and simplify the process to find an appropriate provider for claim services and place orders by providing a smart eMarketplace. This eMarketplace understands a visiting participant's plan and presents the market in a custom ized way.
[ 00206] Embodiments of the present disclosure offer many benefits to the service provider. The service provider does not need to manage invoicing and payment, automating the production and transmission of invoices from suppliers, better controls of SPs, a marketable asset of a market place of simple usability, monitoring and involvement in transactions (allowing for com missions) , and allowing overnight settlement to suppliers.
[ 00207] Embodiments of the present disclosure offer many benefits to the
funder/scheme. There are fewer payments to service providers (reduced transaction processing costs) , reduced administration effort and cost and it encourages additional service providers into the "market" as claim/re-imbursement is simplified (and happens quickly) .
[ 00208] Embodiments of the present disclosure also offer many benefits to
non-governmental schemes and schemes outside of the health sector. Private schemes such as property insurance are well suited to benefit from the claims management system of the present disclosure. For example, insurance claims for a private scheme across m ultiple insurance types (e.g. , NRMA supporting motor vehicle, home and contents, pet insurance) can all be supported in the one system as to what is claimable and supported. Participants (policy holders) could access a white-labelled system (branded for the private scheme) for tracking their claims. Service providers, e.g. , smash repairs, body shops, retailers for replacement goods, would be able to access the system to fulfil work orders (and to vie competitively to gain access to the rights to the work order, e.g. , reverse auction) . Point of sale integration for claims processing at a retailer (e.g. , Kmart Tyre and Auto or Harvey Norman) would reduce the paperwork and overhead of providing services and replacement goods (as claims/ scheme money could be used as simply as a credit card) .
Computer I mplementation
[ 00209] The system of the present disclosure may be practised using a computing device, such as a general purpose computer or computer server or a virtualised computer or distributed cloud-based computing services. Fig. 32 is a schematic block diagram of a system 3200 that includes a general purpose computer 3210. The general purpose computer 321 0 includes a plurality of components, including : a processor 3212, a memory 3214, a storage medium 3216, input/output ( I /O) interfaces 3220, and input/output ( I/O) ports 3222. Components of the general purpose computer 321 0 generally comm unicate using one or more buses 3248.
[ 0021 0] The memory 3214 may be implemented using Random Access Memory ( RAM) , Read Only Memory ( ROM) , or a combination thereof . The storage medium 3216 may be implemented as one or more of a hard disk drive, a solid state "flash" drive, an optical disk drive, or other storage means. The storage medium 3216 may be utilised to store one or more computer programs, including an operating system , software applications, and data. I n one mode of operation , instructions from one or more computer programs stored in the storage medium 321 6 are loaded into the memory 3214 via the bus 3248. I nstructions loaded into the memory 3214 are then made available via the bus 3248 or other means for execution by the processor 3212 to implement a mode of operation in accordance with the executed instructions.
[ 0021 1 ] One or more peripheral devices may be coupled to the general purpose computer 321 0 via the I/O ports 3222. I n the example of Fig. 32, the general purpose computer 321 0 is coupled to each of a speaker 3224, a camera 3226, a display device 3230, an input device 3232, a printer 3234, and an external storage medium 3236. The speaker 3224 may be implemented using one or more speakers, such as in a stereo or surround sound system . I n the example in which the general purpose computer 321 0 is utilised to implement one or more servers or computing devices relating to a claims management portal, one or more peripheral devices may relate to a keyboard, tablet, mouse, or other input or output device connected to the I/O ports 3222.
[00212] The camera 3226 may be a webcam , or other still or video digital camera, and may download and upload information to and from the general purpose computer 3210 via the I /O ports 3222, dependent upon the particular implementation . For example, images recorded by the camera 3226 may be uploaded to the storage medium 321 6 of the general purpose computer 321 0. Similarly, images stored on the storage medium 3216 may be downloaded to a memory or storage medium of the camera 3226. The camera 3226 may include a lens system , a sensor unit , and a recording medium .
[ 00213] The display device 3230 may be a computer monitor, such as a cathode ray tube screen, plasma screen, or liquid crystal display ( LCD) screen . The display 3230 may receive information from the computer 3210 in a conventional manner, wherein the information is presented on the display device 3230 for viewing by a user. The display device 3230 may optionally be implemented using a touch screen to enable a user to provide input to the general purpose computer 321 0. The touch screen may be, for example, a capacitive touch screen, a resistive touchscreen , a surface acoustic wave touchscreen, or the like.
[ 00214] The input device 3232 may be a keyboard, a mouse, a stylus, drawing tablet, or any combination thereof , for receiving input from a user. The external storage medium 3236 may include an external hard disk drive ( HDD) , an optical drive, a floppy disk drive, a flash drive, or any combination thereof and may be implemented as a single instance or multiple instances of any one or more of those devices. For example, the external storage medium 3236 may be implemented as an array of hard disk drives.
[ 0021 5] The I /O interfaces 3220 facilitate the exchange of information between the general purpose computing device 3210 and other computing devices. The I /O interfaces may be implemented using an internal or external modem , an Ethernet connection , or the like, to enable coupling to a transm ission medium. I n the example of Fig. 32, the I /O interfaces 3222 are coupled to a com munications network 3238 and directly to a computing device 3242. The computing device 3242 is shown as a personal computer, but may be equally be practised using a smartphone, laptop, or a tablet device. Direct communication between the general purpose computer 3210 and the computing device 3242 may be implemented using a wireless or wired transmission link.
[ 0021 6] The communications network 3238 may be implemented using one or more wired or wireless transm ission links and may include, for example, a dedicated communications link, a local area network ( LAN) , a wide area network (WAN) , the I nternet, a telecommunications network, or any combination thereof. A
telecomm unications network may include, but is not limited to, a telephony network, such as a Public Switch Telephony Network ( PSTN) , a mobile telephone cellular network, a short message service (SMS) network, or any combination thereof. The general purpose computer 321 0 is able to comm unicate via the com munications network 3238 to other computing devices connected to the communications network 3238, such as the mobile telephone handset 3244, the touchscreen smartphone 3246, the personal computer 3240, and the computing device 3242.
[ 0021 7] One or more instances of the general purpose computer 3210 may be utilised to implement a server acting as a portal to implement a claims management system in accordance with the present disclosure. I n such an embodiment, the memory 3214 and storage 321 6 are utilised to store data relating to registered participants, plans, and the like. Software for implementing the claims management system is stored in one or both of the memory 3214 and storage 321 6 for execution on the processor 3212. The software includes computer program code for implementing method steps in accordance with the method of claims management described herein .
[ 0021 8] Fig. 3333 is a schematic block diagram of a system 3300 on which one or more aspects of a claims management method and system of the present disclosure may be practised. The system 3300 includes a portable computing device in the form of a smartphone 3310, which may be used by a registered user of a claims management system in accordance with the present disclosure. The smartphone 3310 includes a plurality of components, including: a processor 3312, a memory 3314, a storage medium 3316, a battery 331 8, an antenna 3320, a radio frequency ( RF) transmitter and receiver 3322, a subscriber identity module (SI M) card 3324, a speaker 3326, an input device 3328, a camera 3330, a display 3332, and a wireless transmitter and
receiver 3334. Components of the smartphone 3310 generally communicate using one or more bus connections 3348 or other connections therebetween. The smartphone 3310 also includes a wired connection 3345 for coupling to a power outlet to recharge the battery 3318 or for connection to a computing device, such as the general purpose computer 321 0 of Fig. 32. The wired connection 3345 may include one or more connectors and may be adapted to enable uploading and downloading of content from and to the memory 3314 and SI M card 3324.
[0021 9] The smartphone 331 0 may include many other functional components, such as an audio digital-to-analogue and analogue-to-digital converter and an amplifier, but those components are omitted for the purpose of clarity. However, such components would be readily known and understood by a person skilled in the relevant art. [00220] The memory 3314 may include Random Access Memory (RAM) , Read Only Memory ( ROM) , or a combination thereof . The storage medium 3316 may be
implemented as one or more of a solid state "flash" drive, a removable storage medium , such as a Secure Digital (SD) or m icroSD card, or other storage means. The storage medium 3316 may be utilised to store one or more computer programs, including an operating system, software applications, and data. I n one mode of operation, instructions from one or more computer programs stored in the storage medium 331 6 are loaded into the memory 3314 via the bus 3348. I nstructions loaded into the memory 3314 are then made available via the bus 3348 or other means for execution by the processor 3312 to implement a mode of operation in accordance with the executed instructions.
[00221 ] The smartphone 331 0 also includes an application programm ing interface (API ) module 3336, which enables programmers to write software applications to execute on the processor 3312. Such applications include a plurality of instructions that may be pre-installed in the memory 3314 or downloaded to the memory 3314 from an external source, via the RF transmitter and receiver 3322 operating in association with the antenna 3320 or via the wired connection 3345.
[ 00222] The smartphone 331 0 further includes a Global Positioning System (GPS) location module 3338. The GPS location module 3338 is used to determ ine a geographical position of the smartphone 3310, based on GPS satellites, cellular telephone tower triangulation , or a combination thereof. The determ ined geographical position may then be made available to one or more programs or applications running on the
processor 3312.
[ 00223] The wireless transmitter and receiver 3334 may be utilised to comm unicate wirelessly with external peripheral devices via Bluetooth, infrared , or other wireless protocol. I n the example of Fig . 33, the smartphone 331 0 is coupled to each of a printer 3340, an external storage medium 3344, and a computing device 3342. The computing device 3342 may be implemented, for example, using the general purpose computer 321 0 of Fig . 32.
[ 00224] The camera 3326 may include one or more still or video digital cameras adapted to capture and record to the memory 3314 or the SI M card 3324 still images or video images, or a combination thereof . The camera 3326 may include a lens system , a sensor unit, and a recording medium . A user of the smartphone 331 0 may upload the recorded images to another computer device or peripheral device using the wireless transmitter and receiver 3334, the RF transmitter and receiver 3322, or the wired connection 3345.
[ 00225] I n one example, the display device 3332 is implemented using a liquid crystal display (LCD) screen. The display 3332 is used to display content to a user of the smartphone 3310. The display 3332 may optionally be implemented using a touch screen, such as a capacitive touch screen or resistive touchscreen, to enable a user to provide input to the smartphone 3310.
[ 00226] The input device 3328 may be a keyboard, a stylus, or microphone, for example, for receiving input from a user. I n the case in which the input device 3328 is a keyboard, the keyboard may be implemented as an arrangement of physical keys located on the smartphone 610. Alternatively, the keyboard may be a virtual keyboard displayed on the display device 3332.
[ 00227] The SI M card 3324 is utilised to store an I nternational Mobile Subscriber I dentity ( I MSI ) and a related key used to identify and authenticate the user on a cellular network to which the user has subscribed. The SI M card 3324 is generally a removable card that can be used interchangeably on different smartphone or cellular telephone devices. The SI M card 3324 can be used to store contacts associated with the user, including names and telephone numbers. The SI M card 3324 can also provide storage for pictures and videos. Alternatively, contacts can be stored on the memory 3314.
[ 00228] The RF transm itter and receiver 3322, in association with the antenna 3320, enable the exchange of information between the smartphone 3310 and other computing devices via a comm unications network 3390. I n the example of Fig. 33, RF transm itter and receiver 3322 enable the smartphone 3310 to comm unicate via the communications network 3390 with a cellular telephone handset 3350, a smartphone or tablet device 3352, a computing device 3354 and the computing device 3342. The computing devices 3354 and 3342 are shown as personal computers, but each may be equally be practised using a smartphone, laptop, or a tablet device.
[ 00229] The communications network 3390 may be implemented using one or more wired or wireless transm ission links and may include, for example, a cellular telephony network, a dedicated communications link, a local area network ( LAN) , a wide area network (WAN) , the I nternet, a telecommunications network, or any combination thereof. A telecomm unications network may include, but is not limited to, a telephony network, such as a Public Switch Telephony Network ( PSTN) , a cellular ( mobile) telephone cellular network, a short message service (SMS) network, or any combination thereof.
I ndustrial Applicability
[00230] The arrangements described are applicable to the insurance and health care industries.
[00231 ] The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.
[00232] I n the context of this specification, the word "comprising" and its associated grammatical constructions mean "including principally but not necessarily solely" or "having" or " including" , and not "consisting only of" . Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings.
[00233] As used throughout this specification, unless otherwise specified , the use of ordinal adjectives "first" , "second" , "third" , "fourth" , etc. , to describe common or related objects, indicates that reference is being made to different instances of those common or related objects, and is not intended to imply that the objects so described must be provided or positioned in a given order or sequence, either temporally, spatially, in ranking , or in any other manner.
[00234] Although the invention has been described with reference to specific examples, it will be appreciated by those skilled in the art that the invention may be embodied in many other forms.

Claims

We claim :
1 . A method for receiving a booking for a service at an eMarketplace comprising:
receiving an access request for a user to an eMarketplace server, said user being associated with participant profile information referencing a set of entitlements;
producing a set of available services, wherein the set of available services is produced based on entitlement information derived from said set of entitlements and said access request ;
receiving a booking request for at least one instance of a selected one of said available services, said instance to be provided by one or more service providers;
approving each instance based on entitlement information derived from said set of entitlements;
creating a work order that comprises an approval for one or more service providers to render one or more instances of said selected available service; and
storing the work order in a database.
2. The method according to claim 1 , wherein the eMarketplace is implemented using at least one server coupled to a communications network.
3. The method according to either one of claims 1 or 2, wherein said set of entitlements is associated with a plan defined by a scheme operator.
4. The method according to any one of claims 1 to 3, wherein said user is a web services agent.
5. The method according to any one of claims 1 to 4, wherein set said of entitlements comprises scheme information filtered on one or more pieces of participant data from the participant profile information .
6. The method according to any one of claims 1 to 5, wherein the set of produced available services is filtered based on a set of service providers.
7. The method according to any one of claims 1 to 6, wherein the work order comprises a pre-authorisation for the service.
8. The method according to any one of claims 1 to 7, wherein booking information comprises at least one of a specific service provider, a location and a time for said selected available service.
9. The method according to any one of claims 1 to 8, comprising the further step of: producing a set of promotional services not available to said user under said set of entitlements.
10. The method according to any one of claims 1 to 9, wherein the set of available services is derived from a service catalogue.
1 1 . The method according to any one of claims 1 to 10, wherein the set of available services is filtered using a set of one or more allowed service providers.
12. The method according to any one of claims 1 to 1 1 , wherein the set of available services comprises services allowed under said set of entitlements and promotable services not allowed under said set of entitlements.
13. The method according to any one of claims 1 to 12, comprising the further step of: displaying said produced set of available services on a computing device accessed by said user.
14. The method according to any one of claims 1 to 13, wherein the work order comprises a first portion of scheme-funded service and a second portion of non-scheme-funded service.
15. The method according to any one of claim 14, comprising the further step of :
rendering a payment by said user in relation to said booking, using at least one of an electronic wallet, credit card, non-cash payment method, or escrow device.
16. The method according to claim 15, wherein said payment relates to said second portion of non-scheme-funded service.
17. The method according to any one of claims 1 to 16, comprising the further step of: receiving from a service provider a change to a service indication relating to a work order.
18. The method according to claim 17, wherein said service indication is a payment request based on a rendered instance of a service by said service provider.
19. A claims management system comprising :
a centralised server coupled to a com munications network, said server including : a processor; and
a memory for storing:
participant profile information associated with a user, said participant profile information referencing a set of entitlements; and
a computer program that when executed on said processor performs the steps of :
receiving from a client device, via said communications network, an access request for said user;
producing a set of available services, wherein the set of available services is produced based on entitlement information derived from said set of entitlements and said access request ;
receiving a booking request for at least one instance of a selected one of said available services, said instance to be provided by one or more service providers;
approving each instance based on entitlement information derived from said set of entitlements;
creating a work order that comprises an approval for one or more service providers to render one or more instances of said selected available service; and
storing the work order in said memory.
20. A method for processing a work order at a claims management server, said method comprising the steps of :
receiving an access request for a service provider, wherein the service provider is associated with service provider profile information ;
receiving from the service provider a service indication associated with a work order, said work order providing pre-authorised approval for said service provider to render a service to a participant registered with a scheme associated with said claims management server; validating said service indication based on said work order and said service provider profile information ;
sending a response indicating that said service indication is valid; and
processing said work order in response to the service indication.
21 . The method according to claim 20, wherein the service provider is a person or a computer automated agent.
22. The method according to either one of claims 20 or 21 , wherein the service indication is a service rendered indication.
23. The method according to claim 22, wherein the service rendered indication indicates the rendering of a proper sub-set of services associated with the work order.
24. The method according to claim 22, wherein the service rendered indication indicates the rendering of all services associated with the work order.
25. The method according to either one of claims 20 or 21 , wherein the service indication is a request to process a payment in relation to a service.
26. The method according to either one of claims 20 or 21 , wherein the service indication relates to the participant not presenting to an appointment relating to said work order.
27. The method according to any one of claims 20 to 26, wherein the service is received from one of a software application or a point-of-sale (POS) term inal.
28. The method according to any one of claims 20 to 27, comprising the further step of : determining a settlement amount based on said work order and said service indication.
29. The method according to any one of claims 20 to 28, comprising the further step of : sending payment instructions relating to said work order to a payment interface, the payment instructions indicating a payment to be made to a bank account associated with the profile information .
30. The method according to any one of claims 20 to 28, comprising the further step of : receiving an indication to disable the work order.
31 . The method according to any one of claims 20 to 28, comprising the further step of : determining that the work order has had authorised services exhausted.
32. The method according to either one of claims 30 and 31 , comprising the further steps of :
receiving from the service provider a second service indication request associated with the work order; and
sending a response indicating that said second service indication is not valid.
33. The method according to any one of claims 20 to 32, comprising the further steps of : receiving from a second service provider, different from the first service provider, a second service indication request associated with the work order; and
sending a response indicating that said second service indication is valid.
34. A method for transm itting a service indication for a work order from a claim processing device, said work order providing pre-authorised approval for a service provider to render a service to a participant registered with a scheme, said method comprising the steps of: identifying the work order;
sending an access request for said service provider, wherein the service provider is associated with service provider profile information stored in a claims management server; and
sending a service indication associated with said identified work order, said service indication corresponding to a service rendered by said service provider to said participant.
35. The method according to claim 34, wherein identifying the work order includes the step of processing a card or other identifier issued by said scheme.
36. The method according to claim 35, wherein processing said card includes the step of reading participant information stored on said card or other identifier.
37. The method according to claim 36, wherein said participant information is stored using one of a magnetic strip, a quick response (QR) code, biometric information , or a barcode.
38. The method according to either one of claims 36 and 37, wherein said scanning includes the steps of :
capturing an image of a portion of said card; and
processing said captured image to identify said participant information.
5
39. The method according to any one of claims 34 to 38, comprising the further step of : receiving a response indicating that the service indication is valid .
40. The method according to any one of claims 34 to 39, comprising the further step of : ι α presenting a success indication.
41 . The method according to any one of claims 34 to 40, wherein the claim processing device is a software application or a Point-of-Sale terminal . i s 42. The method according to either one of claims 24 or 41 , wherein the service indication is a request to process a payment in relation to a service.
PCT/AU2016/050947 2015-10-08 2016-10-07 A method and system for claims management WO2017059499A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2015904105A AU2015904105A0 (en) 2015-10-08 A method and system for claims management
AU2015904105 2015-10-08

Publications (1)

Publication Number Publication Date
WO2017059499A1 true WO2017059499A1 (en) 2017-04-13

Family

ID=58487119

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2016/050947 WO2017059499A1 (en) 2015-10-08 2016-10-07 A method and system for claims management

Country Status (1)

Country Link
WO (1) WO2017059499A1 (en)

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5301105A (en) * 1991-04-08 1994-04-05 Desmond D. Cummings All care health management system
US20040254816A1 (en) * 2001-10-30 2004-12-16 Myers Gene E. Network-connected personal medical information and billing system
US20050015277A1 (en) * 2003-07-15 2005-01-20 Andreas Mau Real-time benefits service marketplace
WO2008030850A1 (en) * 2006-09-08 2008-03-13 American Well Inc. Connecting consumers with service providers
US20110029367A1 (en) * 2009-07-29 2011-02-03 Visa U.S.A. Inc. Systems and Methods to Generate Transactions According to Account Features
US20110166872A1 (en) * 2009-08-14 2011-07-07 Cervenka Karen L Auto-substantiation for healthcare upon sponsor account through payment processing system
US20120109679A1 (en) * 2008-09-15 2012-05-03 ZocDoc, Inc. Consumer portal for healthcare appointments across practice groups
AU2013100134A4 (en) * 2013-02-08 2013-03-14 Designed Health Care Solutions Pty Ltd Aged Care Costing System And Method Of Use
US20140222452A1 (en) * 2013-02-05 2014-08-07 Care Builders, Inc. Method and system for compiling and designing care support information
US20140244275A1 (en) * 2013-02-25 2014-08-28 Unitedhealth Group Incorporated Healthcare marketplace
KR101439809B1 (en) * 2014-05-02 2014-09-12 국민건강보험공단 Health insurance web edi system
WO2014188435A1 (en) * 2013-05-23 2014-11-27 Davidshield L.I.A. (2000) Ltd. Automated reimbursement interactions

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5301105A (en) * 1991-04-08 1994-04-05 Desmond D. Cummings All care health management system
US20040254816A1 (en) * 2001-10-30 2004-12-16 Myers Gene E. Network-connected personal medical information and billing system
US20050015277A1 (en) * 2003-07-15 2005-01-20 Andreas Mau Real-time benefits service marketplace
WO2008030850A1 (en) * 2006-09-08 2008-03-13 American Well Inc. Connecting consumers with service providers
US20120109679A1 (en) * 2008-09-15 2012-05-03 ZocDoc, Inc. Consumer portal for healthcare appointments across practice groups
US20110029367A1 (en) * 2009-07-29 2011-02-03 Visa U.S.A. Inc. Systems and Methods to Generate Transactions According to Account Features
US20110166872A1 (en) * 2009-08-14 2011-07-07 Cervenka Karen L Auto-substantiation for healthcare upon sponsor account through payment processing system
US20140222452A1 (en) * 2013-02-05 2014-08-07 Care Builders, Inc. Method and system for compiling and designing care support information
AU2013100134A4 (en) * 2013-02-08 2013-03-14 Designed Health Care Solutions Pty Ltd Aged Care Costing System And Method Of Use
US20140244275A1 (en) * 2013-02-25 2014-08-28 Unitedhealth Group Incorporated Healthcare marketplace
WO2014188435A1 (en) * 2013-05-23 2014-11-27 Davidshield L.I.A. (2000) Ltd. Automated reimbursement interactions
KR101439809B1 (en) * 2014-05-02 2014-09-12 국민건강보험공단 Health insurance web edi system

Similar Documents

Publication Publication Date Title
US11704710B2 (en) Online marketplace with seller financing
US20190318433A1 (en) Real estate marketplace method and system
US11055773B2 (en) Online marketplace with seller financing
US10861105B2 (en) Computer readable medium, system, and method of providing a virtual venue for the transfer of taxpayer-specific information
US7818219B2 (en) Electronic realty and transaction system and method therein
US7689444B2 (en) Electronic insurance application fulfillment system and method
US20150242850A1 (en) Methods and systems for permissions management
US20090012887A1 (en) Method And System For Provision Of Personalized Service
US20130282524A1 (en) Systems and methods for providing real estate services
US20130339189A1 (en) Method and apparatus for facilitating real estate transactions
US20150046349A1 (en) Mobile Platform for Legal Process
US10043206B2 (en) Facilitating transactions in connection with service providers
US20140149160A1 (en) Facilitating personal shopping assistance
US20200012762A9 (en) Price transparency search, bundling, and financing for surgeries, medical procedures, and services
US20220172272A1 (en) Systems and methods for management of automotive services
US20190318367A1 (en) Merchant services contract-analysis and sales-facilitation system, software, components, and methods
US20070288349A1 (en) Method and system for facilitating secured commercial transactions through trusted agents
US20140108184A1 (en) Transaction-driven social network
US20170201781A1 (en) Online media content distribution with associated transactions
US20140214507A1 (en) Referral affiliate buyout system and method
US20060036539A1 (en) System and method for anonymous gifting
WO2017059499A1 (en) A method and system for claims management
US20170076367A1 (en) Systems, Methods, and Software For Lien Payoff and Transfer of Title
US20180075373A1 (en) System and method for a care services marketplace
US20220300908A1 (en) System and method for claim reimbursement

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16852909

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16852909

Country of ref document: EP

Kind code of ref document: A1