WO2002019179A1 - Quotation data exchange - Google Patents

Quotation data exchange Download PDF

Info

Publication number
WO2002019179A1
WO2002019179A1 PCT/AU2001/001078 AU0101078W WO0219179A1 WO 2002019179 A1 WO2002019179 A1 WO 2002019179A1 AU 0101078 W AU0101078 W AU 0101078W WO 0219179 A1 WO0219179 A1 WO 0219179A1
Authority
WO
WIPO (PCT)
Prior art keywords
quotation
insurer
message
repairer
request
Prior art date
Application number
PCT/AU2001/001078
Other languages
French (fr)
Inventor
John Uren
Brett Lyons
Original Assignee
Nrma Insurance Limited
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 AUPQ9750A external-priority patent/AUPQ975000A0/en
Priority claimed from AUPR3297A external-priority patent/AUPR329701A0/en
Application filed by Nrma Insurance Limited filed Critical Nrma Insurance Limited
Priority to AU2001281606A priority Critical patent/AU2001281606B2/en
Priority to AU8160601A priority patent/AU8160601A/en
Priority to NZ524397A priority patent/NZ524397A/en
Publication of WO2002019179A1 publication Critical patent/WO2002019179A1/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
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management

Definitions

  • This invention concerns the control of an insurance repair process.
  • it is a quotation data exchange for the control of an insurance repair process, and in another aspect it is a protocol for the control of an insurance repair process.
  • the repair is typically not a simple transaction between the vehicle owner and a repairer, but will often involve a vehicle insurer.
  • the insurer will generally wish to exercise some control over the repair, for instance in selection of the repairer and authorisation of repair items and their cost.
  • a quotation data exchange for the control of an insurance repair process including:
  • a host computer operating to enable communications between an insurer and a repairer where the communications are selected from a set of electronic messages having predetermined content fields in which data is entered, the message set including: A request for quotation in response to a claim, from insurer to repairer in respect of specified damage;
  • a tax invoice (request for payment) from repairer to insurer in respect of an authorised repair
  • a payment authority from insurer to repairer in response to a request for payment.
  • the set of messages may also include: A request for an inspection from the repairer to the insurer to cause the insurer to inspect the damage.
  • the repairer may send a message declining a repair.
  • the insurer may send a message to the repairer declining payment.
  • Other notifications and error messages may also be exchanged.
  • the host computer may reside at the insurer's premises, and the system will typically involve a communications network, such as the Internet, and remote computers at the repairers.
  • the host and remote computers may have relational databases in which the quotation data is stored. When a message is sent from one party to the other this data is gathered together and used to populate the messages before transmission.
  • the electronic messages enable a vehicle re-instatement lifecycle to be communicated between the repairer and insurer in a common format. There is no specific processing dependent on a repairer.
  • the messages are sufficiently flexible that they can drive different repair models.
  • the data requirements may be expressed in a specific implementation of extensible Markup Language. This is a self-describing data protocol with syntactical facilities for mandatory fields, field grouping and allowable values.
  • Each message is described in a Document Type Definition (dtd) which describes each element and its attributes plus the tags required to identify the element.
  • dtd Document Type Definition
  • allowable values may be defined in the dtd. This allows the sending and receiving applications to cross-reference to their proprietary reference sets.
  • the dtd is a de-normalised data definition that contains syntax and nesting of elements such that complex relationships and data categorisation of the target relational database are implied in the message.
  • the system aims to streamline current paper and fax-based processes, thus increasing efficiency and accuracy of data transfer. Enforcement of data integrity is achieved by use of an electronic record. Efficiency is achieved through easier storage of the quotation data for statutory requirements and also electronic records will allow robotic checking for Parts and Hours submissions. The system also offers an opportunity for expansion to support richer and more powerful forms of communication. In particular, more detailed information may be passed between the two parties, allowing better informed decisions to be made.
  • a process enhancement is the support for digital photos. By building an infrastructure for the communication of digital images, sufficient information can be gained by assessors while reducing the need for on-site visits.
  • the invention is a protocol for the control of an insurance repair process, involving the steps of exchanging communications between an insurer and a repairer from the message set described above.
  • Fig. 1 is a schematic diagram showing the architecture of a data quotation exchange.
  • Fig. 2 is a block diagram of the operation of the exchange.
  • Fig. 3 is a flowchart of the workflow.
  • Fig. 4 is all elevations of a vehicle with the sections identified by numbers.
  • the quotation data exchange (QDE) 1 facilitates communications between an insurer 2 and a number of repairers 3.
  • the insurer has a software solution that integrates with its overall claims process, while the repairers are using software packages developed by third-party vendors.
  • the two parties communicate via the Internet 4, using a protocol, with the content of the communications encapsulated in messages 5.
  • the exchange consists of the following key components: • Messaging architecture
  • the Messages The system provides an "interface" between the insurer's and repairers' systems. It allows either party to implement their internal systems to meet their internal business needs, while retaining the confidence that other parties can be communicated with, in a standard way.
  • Both the insurer and repairer systems store the quotation information in a database. When a message needs to be sent to the other party, this information is gathered together, and used to populate a message for transmission.
  • the Request for Quote message is sent from the insurer to the repairer, and contains: • Details on the incident such as an accident, vandalism, hail etc.
  • Vehicle details such as: make, model, and engine number.
  • the message also specifies whether: • The partnered model should be used for this job.
  • the repairer sends this message to the insurer, indicating that they have declined the job, and provides a reason.
  • the Quote message is the primary mechanism for communicating details between the two parties, and is used in the following cases:
  • This message type contains:
  • the flags are used in the following manner: • When a new quote is generated, all the items are marked as 'added'.
  • the 'added' flag is also used if a new item is added as part of a variation or adjustment.
  • This message is used by either the repairer or insurer. If used by the repairer it acts as a request which the insurer may accept by returning the message or decline by asking the repairer to submit a quotation.
  • This message is sent if the insurer does not wish to proceed with his original request. This may be because of a variety of reasons from the insured wishing to have another repairer allocated to the submission of a totally unacceptable quotation.
  • a payment request message is sent from the repairer to the insurer to indicate that the job has been completed, and to request payment.
  • a payment request may be a Tax Invoice, an Adjustment Note or a Re-activate Invoice depending on previous workflow.
  • the insurer uses this message to notify that payment has been made, and includes payment details such as invoice number, and actual payment date.
  • Payment Declined The insurer uses this message to notify the repairer that a requested payment will not be made and provides a reason.
  • Parts Reference This message is used by the part reference data supplier and is sent to the insurer to communicate the detailed information on car parts.
  • This message is used by the parts reference supplier and is sent to the insurer to communicate the detailed information of a car.
  • This message is used by either party to signal any errors encountered in incoming messages.
  • An error message will have 1 of 4 severities:
  • QML Quotation Markup Language
  • Quotation Markup Language defines a specification for all messages passed between the insurer and repairers. This specification is defined using the extensible Markup Language (XML), an open standard for the development of industry-specific data formats.
  • XML extensible Markup Language
  • XML is self-explanatory, when read in conjunction with the following basic design principles: • XML consists of tags, which are surrounded by angle brackets. An example of a tag: ⁇ QuoteDetails > .
  • an element consists of a start and end tag. The content of the element is then located between these tags, and can consist of either text, or more elements. For example: ⁇ RegistrationNo>UAA 169 ⁇ /RegistrationNo> or:
  • DTD Document Type Definition
  • Model must contain a Make, ModellD, optionally a Description, and optionally a DataManufactureStart.
  • the DTDs specify the structure of QML, but they do not detail the meaning of the elements, nor the format of the element content. For example, a DTD can only specify that an element contains text, not that it must contain a five digit number.
  • Lvl (Level) the hierarchical level at which the element exists. This is used to specify the parent child relationships between fields and which elements are grouped together.
  • Content type “Group” for an element that only contains other elements; "Char” for character data (text); “Flag” for an empty element; "Attr” for a character attribute assigned to another element; "List” for a list of valid values; and "Numeric” for a decimal or floating point number.
  • character number 151 would be written as "—”.
  • "escaped" form should be used, as follows:
  • This message is sent by the insurer to the repairer once only. Any information sent that requires updating will be contained in another message.
  • This message is sent by the repairer to the insurer once only and is an end state for the referenced Request for Quote.
  • This message may be sent by the repairer to the insurer and vice versa multiple times.
  • This message is sent by the insurer to the repairer and may occur at any time when the quotation has already been authorised.
  • This message is sent by the insurer to the repairer and is an end state. Note that it may be sent prior to the receipt of a quotation.
  • This message may be sent by the repairer to the insurer and vice versa. It may occur prior to or subsequent to a quotation.
  • This message is sent by the repairer to the insurer to request payment on the authorised quotation.
  • This message is sent by the repairer to the insurer to adjust a previously submitted Tax Invoice.
  • This message is an increment or decrement to what has been sent previously. It contains a full version of the quotation with only the summary or those items that are added / changed / deleted since the tax invoice flagged.
  • This message is sent by the repairer to the insurer to re-activate a previously submitted Tax Invoice. This implies that the amounts requested are as originally submitted and some variation has been made to the quotation to make the payment requested balance with the authorised quotation.
  • This message is sent by the insurer to the repairer once only and serves to confirm that payment will be made as requested.
  • This message is sent by the insurer to the repairer and serves to inform him that the requested payment will not be made for the given reason.
  • This message is sent by the Parts Reference data supplier to the insurer.
  • This message is sent by the Parts Reference data supplier to the insurer.
  • This message is sent by the insurer to the repairer for the purpose of reporting an error with a previous message. There may be multiple error messages generated for the same original message. Upon receiving one of these error messages, the repairer's system should report the error to the user and if the message has a severity of "Critical" then it should update their system to reflect that the insurer has not accepted their original message.
  • Fig. 3 the workflow can be seen to begin after a vehicle has been damaged and when the claim 31 is lodged.
  • a repairer is allocated 32 and a request for quote 33 is sent to the repairer 34.
  • the repairer has a number of choices. First the repairer may decline the job 35. Second the repairer may quote 36 to repair the vehicle. In this case an on-site inspection may be requested 37 and this on-site inspection may subsequently take place 38. A quotation assessment 39 then takes place.
  • the repairer may request total loss 40. This may be refused 41 and the request for quote 33 may then be repeated. If it is accepted 42 then a total loss advice 43 is made.
  • the quotation assessment 39 will result in either: the return of a Quote message 44 with possible adjustments, the settlement method (Repair or Cash Settlement) 59 and optional authority to proceed with the repair or; a total loss message 43.
  • the quote authority will then enable the repairer to perform the repairs 45.
  • additional repairs may become evident, in which case a variation quote 46 may be prepared and assessed 47 before authority is granted 48 for the additional repairs to take place.
  • the repairer After the repairs have taken place, or after the total loss advice has been made, the repairer generates a tax invoice (payment request) 49 which is received by the insurer and assessed for payment 50. Payment may be authorised 51 and made to the repairer 52. Alternatively payment may be declined 53 in which case the repairer has three options.
  • the first a variation quote 54 which is assessed at 55 and a quote authority given at 56.
  • An adjustment note may be generated at 57 or an invoice may be reactivated at 58 in which case the process continues at the payment assessment 50.
  • a Job Cancelled message may be initiated by the assessor at any time and has been omitted firn the graphic to aid clarity of the remaining flow.
  • Authority may be withdrawn at any time between authority being given and the completion of repairs.

Abstract

This invention concerns a quotation data exchange for the control of a insurance repair process utilising a host computer to create a communication path between an insurer's computer system and multiple repairer's computer systems. The communications are selected from a set of predefined messages having predefined possible order of communication and predefined content fields in which data is entered into. Each computer system may have a relational database in which the relevant quotation data is stored. This data is used to automatically populate the messages content fields before transmission. In another aspect the invention concerns a method of controlling an insurance repair process using the quotation data exchange message set. In further aspect, the invention concerns a protocol for a standard procedure of regulating the data transmission between insurer and repairer computer systems during the insurance repair process.

Description

Title
Quotation Data Exchange
Technical Field This invention concerns the control of an insurance repair process. In one aspect it is a quotation data exchange for the control of an insurance repair process, and in another aspect it is a protocol for the control of an insurance repair process.
Background Art
Motor vehicles need to be repaired after they are damaged for example, as a result of traffic accidents, malicious acts or hailstorms. The repair is typically not a simple transaction between the vehicle owner and a repairer, but will often involve a vehicle insurer. The insurer will generally wish to exercise some control over the repair, for instance in selection of the repairer and authorisation of repair items and their cost.
Summary ofthe Invention
In a first aspect the invention, is a quotation data exchange for the control of an insurance repair process, including:
A host computer operating to enable communications between an insurer and a repairer where the communications are selected from a set of electronic messages having predetermined content fields in which data is entered, the message set including: A request for quotation in response to a claim, from insurer to repairer in respect of specified damage;
A quotation between repairer and insurer for repair of the damage specified in a request for quotation;
An assessed quotation that may or may not contain an authority to proceed with the repair;
A tax invoice (request for payment) from repairer to insurer in respect of an authorised repair;
A payment authority from insurer to repairer in response to a request for payment.
The set of messages may also include: A request for an inspection from the repairer to the insurer to cause the insurer to inspect the damage.
Rather than quote the repairer may send a message declining a repair. The insurer may send a message to the repairer declining payment. Other notifications and error messages may also be exchanged.
The host computer may reside at the insurer's premises, and the system will typically involve a communications network, such as the Internet, and remote computers at the repairers. The host and remote computers may have relational databases in which the quotation data is stored. When a message is sent from one party to the other this data is gathered together and used to populate the messages before transmission.
The electronic messages enable a vehicle re-instatement lifecycle to be communicated between the repairer and insurer in a common format. There is no specific processing dependent on a repairer. The messages are sufficiently flexible that they can drive different repair models.
The data requirements may be expressed in a specific implementation of extensible Markup Language. This is a self-describing data protocol with syntactical facilities for mandatory fields, field grouping and allowable values. Each message is described in a Document Type Definition (dtd) which describes each element and its attributes plus the tags required to identify the element. For a specific occurrence of a message, each data element value is enclosed in the defined tags. Where data occurrences belong to limited data reference sets, allowable values may be defined in the dtd. This allows the sending and receiving applications to cross-reference to their proprietary reference sets.
The dtd is a de-normalised data definition that contains syntax and nesting of elements such that complex relationships and data categorisation of the target relational database are implied in the message.
It should be noted that although the result has an appearance of being simple because of its flat structure, there may be equivalent intelligence embedded in the message definition than the databases, and their complex relationships, where the messages originate and terminate. The system aims to streamline current paper and fax-based processes, thus increasing efficiency and accuracy of data transfer. Enforcement of data integrity is achieved by use of an electronic record. Efficiency is achieved through easier storage of the quotation data for statutory requirements and also electronic records will allow robotic checking for Parts and Hours submissions. The system also offers an opportunity for expansion to support richer and more powerful forms of communication. In particular, more detailed information may be passed between the two parties, allowing better informed decisions to be made. One example of a process enhancement is the support for digital photos. By building an infrastructure for the communication of digital images, sufficient information can be gained by assessors while reducing the need for on-site visits.
In another aspect, the invention is a protocol for the control of an insurance repair process, involving the steps of exchanging communications between an insurer and a repairer from the message set described above.
Brief Description of the Drawings
An example of the invention will now be described with reference to the accompanying drawings, in which:
Fig. 1 is a schematic diagram showing the architecture of a data quotation exchange. Fig. 2 is a block diagram of the operation of the exchange.
Fig. 3 is a flowchart of the workflow.
Fig. 4 is all elevations of a vehicle with the sections identified by numbers.
Best Modes ofthe Invention
The quotation data exchange (QDE) 1 facilitates communications between an insurer 2 and a number of repairers 3.
The insurer has a software solution that integrates with its overall claims process, while the repairers are using software packages developed by third-party vendors.
The two parties communicate via the Internet 4, using a protocol, with the content of the communications encapsulated in messages 5.
This is summarised in Fig. 1.
Quotation Data Exchange Architecture
The exchange consists of the following key components: • Messaging architecture
• Quotation Markup Language (QML)
The Messages The system provides an "interface" between the insurer's and repairers' systems. It allows either party to implement their internal systems to meet their internal business needs, while retaining the confidence that other parties can be communicated with, in a standard way.
Both the insurer and repairer systems store the quotation information in a database. When a message needs to be sent to the other party, this information is gathered together, and used to populate a message for transmission.
When a message is received, another process of conversion will occur, to map the data into the internal database model of the software system. As can be seen, the messages only used during the communication of quotation information, and therefore only have to capture the information needed for this process. The storage oi quotation information is the responsibility of the systems designers, and can be done using any method that meets the overall functional requirements. This model of operation can be seen in Fig. 2.
Request for Quote
The Request for Quote message is sent from the insurer to the repairer, and contains: • Details on the incident such as an accident, vandalism, hail etc.
• Insurance information such as: sum insured, etc.
• Vehicle details, such as: make, model, and engine number.
• Customer contact name and address.
The message also specifies whether: • The partnered model should be used for this job.
• The assessed model should be used.
• The request is for comparison quotation purposes only, and no repairs will be conducted by the repairer.
Once a request has been received by the repairer, a quotation is made and is sent to the insurer. Alternatively, the repairer may decline the job. Job Declined
The repairer sends this message to the insurer, indicating that they have declined the job, and provides a reason.
Quote
The Quote message is the primary mechanism for communicating details between the two parties, and is used in the following cases:
• the initial quote.
• an adjustment made by the insurer. • and a variation made by the repairer.
This message type contains:
• General details on the repair, including: repair dates, updated incident reports, etc.
• Extensive vehicle details, including: make, model, paint colour, options, etc.
• Global hourly rates for categories of repair, such as: paint, repair, mechanical, etc.
• Quote items: providing details on the actual work to be completed.
• An indication that the most recent quotation from the repairer has been accepted.
• An indication that an assessor will need to make an on-site examination of the vehicle to be repaired with reasons.
For each quote item, there are four status flags used to manage the flow of changes between the insurer and the repairer: • added
• changed
• deleted
• acknowledged delete
The flags are used in the following manner: • When a new quote is generated, all the items are marked as 'added'.
• The 'added' flag is also used if a new item is added as part of a variation or adjustment.
• If an adjustment or variation needs to be made, the quote items details are changed to the new values, and each modified quote item is marked as 'changed'. The updated Quote is then sent to the other party. • If an item is to be removed from the quote, it is marked as 'deleted'. It is not, however, omitted from the Quote message, such that an audit trail is maintained. Such an item should be shipped as 'acknowledged delete' in subsequent quote messages. • The absence of all 4 flags means the item is unchanged by the recipient. This means that items unchanged by the insurer are implicitly authorised.
Total Loss
This message is used by either the repairer or insurer. If used by the repairer it acts as a request which the insurer may accept by returning the message or decline by asking the repairer to submit a quotation.
Job Cancelled
This message is sent if the insurer does not wish to proceed with his original request. This may be because of a variety of reasons from the insured wishing to have another repairer allocated to the submission of a totally unacceptable quotation.
Authority Withdrawn The insurer uses this message to notify that the repairer should immediately halt any work on the repair, and not start any new repair work.
Tax Invoice (Payment Request)
A payment request message is sent from the repairer to the insurer to indicate that the job has been completed, and to request payment.
Additional information needed to manage the GST is also included. Due to the GST, a payment request may be a Tax Invoice, an Adjustment Note or a Re-activate Invoice depending on previous workflow.
Payment Authorised
The insurer uses this message to notify that payment has been made, and includes payment details such as invoice number, and actual payment date.
Payment Declined The insurer uses this message to notify the repairer that a requested payment will not be made and provides a reason.
Parts Reference This message is used by the part reference data supplier and is sent to the insurer to communicate the detailed information on car parts.
Vehicle Reference
This message is used by the parts reference supplier and is sent to the insurer to communicate the detailed information of a car.
Error
This message is used by either party to signal any errors encountered in incoming messages. An error message will have 1 of 4 severities:
• Informational - Information for the Repairer.
• Warning - Warning for the repairer, but Inbound Message still processed.
• Critical - Critical error for Repairer. Inbound Message not processed. Needs response by quotation application. • System - Errors indicating that the system is not working. Eg database is down. System errors are not sent to the repairer. An Error message will have 1 of 5 types:
• DataContent - The content of an element is not valid according to the defined business rules. • Miscellaneous - An error that does not belong to any of the other types.
• Message Order - The Inbound Message has an invalid Message Number.
• Data Type - The content of an element does not match the data type restrictions described in the QDE Data Definitions. Eg. Characters for a numeric element. • Validity - The Inbound Message fails parse correctly against the appropriate DTD.
Quotation Markup Language (QML)
The Quotation Markup Language (QML) defines a specification for all messages passed between the insurer and repairers. This specification is defined using the extensible Markup Language (XML), an open standard for the development of industry-specific data formats.
Use of XML brings with it a number of important benefits:
• It is an open, vendor-neutral standard. • It is platform-independent.
• Many software vendors are providing support for XML.
• It allows complex data to be stored in a simple format.
• It is self-documenting: QML can be read and understood directly from the file without needing complex supporting documentation. • Future extensions can be made to the business processes, while minimising the need for systems re-engineering.
• Validity can be easily checked, and integrity ensured.
To a large extent, the XML is self-explanatory, when read in conjunction with the following basic design principles: • XML consists of tags, which are surrounded by angle brackets. An example of a tag: < QuoteDetails > .
• In general, an element consists of a start and end tag. The content of the element is then located between these tags, and can consist of either text, or more elements. For example: <RegistrationNo>UAA 169</RegistrationNo> or:
< Vehicle >
<BuildDate> 199001</BuildDate>
<KilometresTravelled> 25000 </KilometresTravelled> </Vehicle>
• An element may also have attπbutes, which define additional information about the element. For example: <Transmission Value = "Automatic"/ > .
• The rules that define the names of the elements, and how they can be used are stored in a Document Type Definition (DTD). The simplest way of explaining a DTD is to work by example:
• In the DTD, lines such as the following can be found: < !ELEMENT Vehicle (BuildDate, KilometresTravelled, EngineSize)>
This defines the element Vehicle, and indicates that it contains BuildDate, followed by KilometresTravelled and EngineSize. In the XML file, this would allow the following to be used:
< Vehicle > <BuildDate > 199001</BuildDate >
< KilometresTravelled > 25000 </KilometresTravelled> <EngineSize>2.6</EngineSize>
</Vehicle> • These lines are also common:
< !ELEMENT BuildDate (#PCDATA)>
This is just a complex way of saying the content of the element is text. For example:
<BuildDate>199912</BuildDate> • It is also possible to create more complex rules:
< .ELEMENT Model (Make, ModellD, Description?, DateManufactureStart?) >
This means that the Model must contain a Make, ModellD, optionally a Description, and optionally a DataManufactureStart. The question mark is an example of an operator in XML that specifies when an element may appear. The full list: ?=may optionally be used *=may appear 0 or more times -I- = must appear at least once An XML file must meet the rules defined in its matching DTD. If it does so, it is considered valid, otherwise an error is generated.
The DTDs specify the structure of QML, but they do not detail the meaning of the elements, nor the format of the element content. For example, a DTD can only specify that an element contains text, not that it must contain a five digit number.
This document therefore provides a detailed data definition for QML, along with some brief explanatory information about each element.
Note that: • There is one definition for each DTD. • The tag names in the definitions match exactly those defined in the DTD's. In this example the columns in the data definitions are used as follows:
• Tag name - the name of the element in the DTD
• Lvl (Level) - the hierarchical level at which the element exists. This is used to specify the parent child relationships between fields and which elements are grouped together. • Content type - "Group" for an element that only contains other elements; "Char" for character data (text); "Flag" for an empty element; "Attr" for a character attribute assigned to another element; "List" for a list of valid values; and "Numeric" for a decimal or floating point number.
For "Char", "Attr", and "List" types, the maximum allowable length of the data is currently restricted to 4000 bytes due to technical limitations. Note: carriage returns are not a valid value in a Gentran message and should be specifically excluded by the parsing software. In the case of "Numeric", the required format for the data is defined in the description column. This is in the form "zz99.99", where "z" and "9" denotes a single digit. For example, "zz9.99" means that there may be up to three digits, which can be followed by a decimal point and up to two decimal places. The use of "z" indicates that the digit is optional and does not have to be zero-padded. Any decimal places specified in the format description are optional and only need to be included in the data if necessary. Valid examples: "999":987;001;015 "zz9":987;l;15
"zz9.99":2.00,1.7;999.98;15
• Content Length - the length defined for an element is the maximum length expected by the recipient. Note that the exchange mechanism will not enforce this limit but delinquency will be an issue in certification testing.
• Req (Requirement) - the requirement specification for a field. This is defined by a set of codes as follows:
= M - Mandatory. For a Group, must always be present. For an element, if the group the element belongs to is present, the element must be present. Note: if a field is marked as mandatory it may not appear if its parent group is marked as optional. In addition, a mandatory field may not be blank or zero unless specifically described as such. => O - Optional Element Does not need to be sent with every message. => MS - Mandatory Select of Element. This requirement is specified for a group of elements, from which there must always be one and only one of the elements specified in the report.
=- OS - Optional Select of Element This requirement is specified for a group of elements, from which there can either be none or only one of the elements specified in the report.
=> OL - Optional Linked Element This requirements is specified for an element that is linked to another element(s) where either both (all) must be specified or none of them can be present. = M+ - Mandatory List. This indicates that the element can be specified multiple times but there must always be at least one instance of it in a message.
=> O+ - Optional List This indicates that the element can either be specified multiple times or not at all. => MS+ - Mandatory Select List This requirement is specified for a group of elements and it indicates that at least one of the elements from the group must be specified but there can be multiple instances of one or more of the elements.
• Rep (Repairer) - U = Update, R = Read Only, F = Fixed by way of being system generated or derived.
• Ins (Insurer) - U = Update, R = Read Only, F = Fixed by way of being system generated or derived.
• Description - a brief description of the element, along with any default values or other implementation notes.
All QML files created must use 7-bit ASCII. That is, no special characters must appear in the documents, beyond alphanumeric characters and punctuation. If high-order characters are required, they must appear in the form:
&#zzz;
For example, character number 151 would be written as "&#151;". Furthermore, there are a number of special characters that must not be directly used in XML. Instead, the "escaped" form should be used, as follows:
Figure imgf000014_0001
Note: these requirements are part of the XML specification, and are not particular to QML.
Request for Quote
This message is sent by the insurer to the repairer once only. Any information sent that requires updating will be contained in another message.
Figure imgf000015_0001
Figure imgf000015_0002
Figure imgf000015_0003
Figure imgf000015_0004
Figure imgf000015_0005
Figure imgf000015_0006
Figure imgf000016_0001
Figure imgf000016_0002
Figure imgf000016_0003
Figure imgf000017_0001
Figure imgf000017_0002
Declined Repair
This message is sent by the repairer to the insurer once only and is an end state for the referenced Request for Quote.
Figure imgf000018_0001
Figure imgf000019_0001
Figure imgf000019_0002
Quote
This message may be sent by the repairer to the insurer and vice versa multiple times.
Figure imgf000020_0001
Figure imgf000020_0002
Figure imgf000020_0003
Figure imgf000020_0004
Figure imgf000021_0001
Figure imgf000021_0002
Figure imgf000021_0003
Figure imgf000022_0001
Figure imgf000022_0002
Figure imgf000022_0003
Figure imgf000023_0001
Figure imgf000023_0002
Figure imgf000024_0001
Figure imgf000024_0002
Figure imgf000024_0003
Figure imgf000025_0001
Figure imgf000025_0002
Figure imgf000025_0003
Figure imgf000025_0004
Figure imgf000026_0001
Figure imgf000027_0001
Figure imgf000028_0001
Figure imgf000029_0001
Figure imgf000030_0001
Figure imgf000030_0002
Figure imgf000030_0003
Authority Withdrawn
This message is sent by the insurer to the repairer and may occur at any time when the quotation has already been authorised.
Figure imgf000031_0001
Figure imgf000031_0002
Figure imgf000031_0003
Figure imgf000031_0004
Figure imgf000031_0005
Figure imgf000032_0001
Figure imgf000032_0002
Job Cancelled
This message is sent by the insurer to the repairer and is an end state. Note that it may be sent prior to the receipt of a quotation.
Figure imgf000033_0001
Figure imgf000034_0001
Figure imgf000034_0002
Total Loss
This message may be sent by the repairer to the insurer and vice versa. It may occur prior to or subsequent to a quotation.
Figure imgf000035_0001
Figure imgf000036_0001
Figure imgf000036_0002
Tax Invoice (Payment request)
This message is sent by the repairer to the insurer to request payment on the authorised quotation.
Figure imgf000037_0001
Figure imgf000038_0001
Figure imgf000038_0002
Figure imgf000038_0003
Adjustment Note
This message is sent by the repairer to the insurer to adjust a previously submitted Tax Invoice. This message is an increment or decrement to what has been sent previously. It contains a full version of the quotation with only the summary or those items that are added / changed / deleted since the tax invoice flagged.
Figure imgf000039_0001
Figure imgf000040_0001
Figure imgf000040_0002
Re-Activate Invoice
This message is sent by the repairer to the insurer to re-activate a previously submitted Tax Invoice. This implies that the amounts requested are as originally submitted and some variation has been made to the quotation to make the payment requested balance with the authorised quotation.
Figure imgf000041_0001
Figure imgf000042_0001
Payment Authorised
This message is sent by the insurer to the repairer once only and serves to confirm that payment will be made as requested.
Figure imgf000043_0001
Figure imgf000043_0002
Figure imgf000043_0003
Figure imgf000043_0004
Figure imgf000043_0005
Figure imgf000043_0006
Figure imgf000044_0001
Payment Declined
This message is sent by the insurer to the repairer and serves to inform him that the requested payment will not be made for the given reason.
Figure imgf000045_0001
Figure imgf000046_0001
Parts Reference
This message is sent by the Parts Reference data supplier to the insurer.
Figure imgf000047_0001
Figure imgf000047_0002
Figure imgf000047_0003
Figure imgf000047_0004
Figure imgf000047_0005
Figure imgf000047_0006
Figure imgf000048_0001
Vehicle Reference
This message is sent by the Parts Reference data supplier to the insurer.
Figure imgf000049_0001
Figure imgf000049_0002
Figure imgf000049_0003
Figure imgf000049_0004
Figure imgf000049_0005
Vehicle 1 Group M
Figure imgf000050_0001
Error
This message is sent by the insurer to the repairer for the purpose of reporting an error with a previous message. There may be multiple error messages generated for the same original message. Upon receiving one of these error messages, the repairer's system should report the error to the user and if the message has a severity of "Critical" then it should update their system to reflect that the insurer has not accepted their original message.
Figure imgf000051_0001
Figure imgf000051_0002
Figure imgf000051_0003
Figure imgf000051_0004
Figure imgf000051_0005
Figure imgf000051_0006
Figure imgf000052_0001
Figure imgf000052_0002
Figure imgf000052_0003
Figure imgf000052_0004
DataTypeError | 2 [ Group | | MS | The contents of an element does
Figure imgf000053_0001
Figure imgf000053_0002
Figure imgf000053_0003
Figure imgf000053_0004
Figure imgf000053_0005
Figure imgf000054_0001
Figure imgf000054_0002
Glossary
Figure imgf000055_0001
Workflow
Referring to Fig. 3 the workflow can be seen to begin after a vehicle has been damaged and when the claim 31 is lodged. A repairer is allocated 32 and a request for quote 33 is sent to the repairer 34. The repairer has a number of choices. First the repairer may decline the job 35. Second the repairer may quote 36 to repair the vehicle. In this case an on-site inspection may be requested 37 and this on-site inspection may subsequently take place 38. A quotation assessment 39 then takes place.
Alternatively the repairer may request total loss 40. This may be refused 41 and the request for quote 33 may then be repeated. If it is accepted 42 then a total loss advice 43 is made.
The quotation assessment 39 will result in either: the return of a Quote message 44 with possible adjustments, the settlement method (Repair or Cash Settlement) 59 and optional authority to proceed with the repair or; a total loss message 43. The quote authority will then enable the repairer to perform the repairs 45. During the repair additional repairs may become evident, in which case a variation quote 46 may be prepared and assessed 47 before authority is granted 48 for the additional repairs to take place. After the repairs have taken place, or after the total loss advice has been made, the repairer generates a tax invoice (payment request) 49 which is received by the insurer and assessed for payment 50. Payment may be authorised 51 and made to the repairer 52. Alternatively payment may be declined 53 in which case the repairer has three options. The first a variation quote 54 which is assessed at 55 and a quote authority given at 56. An adjustment note may be generated at 57 or an invoice may be reactivated at 58 in which case the process continues at the payment assessment 50. A Job Cancelled message may be initiated by the assessor at any time and has been omitted firn the graphic to aid clarity of the remaining flow.
Authority may be withdrawn at any time between authority being given and the completion of repairs.
It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

Claims
1. A quotation data exchange for the control of an insurance repair process, including: a host computer operating to enable communications between an insurer and a repairer where the communications are selected from a set of electronic messages having predetermined content fields in which data is entered, the message set including: a request for quotation in response to a claim, from insurer to repairer in respect of specified damage; a quotation between repairer and insurer for repair of the damage specified in a request for quotation; an assessed quotation that may or may not contain an authority from insurer to proceed with the repair; a tax invoice (request for payment) from repairer to insurer in respect of an authorised repair; a payment authority from insurer to repairer in response to a request for payment.
2. A quotation data exchange according to claim 1, wherein the quotation contains a request for an inspection from repairer to insurer to cause the insurer to inspect the damage.
3. A quotation data exchange according to claim 1 or 2, wherein the assessed quotation contains settlement information in respect of the specified repair.
4. A quotation data exchange according to claim 1, 2 or 3, wherein the message set includes a total loss request by either the insurer or repairer, which is subsequently rejected or accepted by the insurer.
5. A quotation data exchange according to any of claims 1 to 4, wherein the message set includes a further tax invoice (payment request) in the form of an adjustment note or a re-activate invoice based on a previously communicated tax invoice.
6. A quotation data exchange according to any of claims 1 to 5 wherein the message set includes an authority withdrawn message from insurer to repairer at any time after an assessed quotation has been made containing an authority.
7. A quotation data exchange according to any of claims 1 to 6, wherein the message set includes a cancel job message from insurer to repairer at any time after a request for quotation has been received by the repairer.
8. A quotation data exchange according to any of claims 1 to 7, wherein the message set includes a decline payment message from insurer to repairer upon receipt of any tax invoice (request for payment).
9. A quotation data exchange according to any of claims 1 to 8, wherein the message set includes a decline job message from the repairer upon receipt of a request for quotation, and once included into the message set, prevents the communication of further messages in relation to the specified damage.
10. A quotation data exchange according to any of claims 1 to 9, wherein the message set includes a Parts Reference message from a part reference data supplier to insurer to communicate car part information.
11. A quotation data exchange according to any of claims 1 to 10, wherein the message set includes a Vehicle Reference message from a part reference data supplier to insurer to communicate car information.
12. A quotation data exchange according to any of claims 1 to 11, wherein the message set includes an error message from either the insurer or repairer on the receipt of any message containing invalid fields or is received in an invalid sequence.
13. A quotation data exchange according to claim 1, wherein the host computer resides at the insurer's premises, and the system will typically involve a communications network, such as the Internet, and remote computers that reside at the multiple repairer's premises.
14. A quotation data exchange according to claim 13, wherein the host and remote computers contain relational databases in which their respective quotation data is stored.
15. A quotation data exchange according to claim 14, wherein the data collected and stored within the relational database is used to populate the messages before transmission.
16. A quotation data exchange according to any of claims 1 to 15, wherein the predetermined content fields for each message are expressed in a specific implementation of extensible Markup Language (XML).
17. A quotation data exchange according to any of claims 1 to 16, wherein syntactical facilities of the predetermined content fields are described in a
Document Type Definition (dtd) that is a de-normalised data definition that contains syntax and nesting of elements such that complex relationships and data categorisation of the target relational database are implied in the message and the Document Type Definition defines each message, mandatory fields, field grouping, limited data reference sets and allowable values.
18. A quotation data exchange according to claim 17, wherein the syntactical facilities within the Document Type Definition (dtd) are translated to predefined identifying tags that surround each specific occurrence of a message and individual fields during transmission.
19. A method for controlling an insurance repair process using a quotation data exchange according to claim 1, comprising the steps of: entering and storing the required quotation information into an insurer's computer system in response to a claim; sending a request for quotation that is automatically populated with stored quotation information in respect of specified damage; receiving a quotation for the repair of the specified damage; automatically retrieving information contained within the quotation and storing the information on the insurer's computer system; sending an assessed quotation that is automatically populated with quotation information stored on the insurer's computer system, that may or may not contain an authority to proceed with the repair; receiving a tax invoice (request for payment) in respect of an authorised repair; automatically retrieving information contained within the tax invoice (request for payment) and storing the information on the insurer's computer system; sending a payment authority in response to a request for payment that is automatically populated with quotation information stored on the insurer's computer system;
20. A method for controlling an insurance repair process according to claim 19, further comprising the step of inspecting the damage upon receiving such a request from the repairer within the quotation.
21. A method for controlling an insurance repair process according to claim 19 or 20, further comprising the step of including settlement information in the assessed quotation.
22. A method for controlling an insurance repair process according to claim 19, 20 or 21, further comprising the step of sending or receiving a total loss request, automatically retrieving information contained within the total loss request and storing the information on the insurer's computer system.
23. A method for controlling an insurance repair process according to ay of claims 19 to 22, further comprising the step of receiving an additional tax invoice (payment request) in the form of an adjustment note or re-activate invoice, automatically retrieving information contained within the additional tax invoice (request for payment) and storing the information on the insurer's computer system.
24. A method for controlling an insurance repair process according to any of claims 19 to 23, further comprising the step of withdrawing authority at any time after an assessed quotation has been sent containing an authority.
25. A method for controlling an insurance repair process according to any of claims 19 to 24, further comprising the step of cancelling a job at any time after a request for quotation has been received by the repairer.
26. A method for controlling an insurance repair process according to any of claims 19 to 25, further comprising the step of declining a payment upon receipt of any tax invoice (request for payment).
27. A method for controlling an insurance repair process according to any of claims 19 to 26, further comprising the step of receiving a decline job message from the repairer and sending the request for quotation to an alternate repairer.
28. A method for controlling an insurance repair process according to any of claims 19 to 27, further comprising the step of receiving a parts reference message from a part reference data supplier, automatically retrieving information contained within the parts reference message and storing the information on the insurer's computer system.
29. A method for controlling an insurance repair process according to any of claims 19 to 28, further comprising the step of receiving a vehicle reference message from part reference data supplier, automatically retrieving information contained within the vehicle reference message and storing the information on the insurer's computer system.
30. A method for controlling an insurance repair process according to any of claims 19 to 29, further comprising the step of receiving or sending an error message based on any message containing invalid fields or is delivered in an invalid sequence.
31. A protocol for the control of an insurance repair process, involving the steps of exchanging electronic communication between an insurer and repairer including the following message set: a request for quotation in response to a claim, from insurer to repairer in respect of specified damage; a quotation between repairer and insurer for repair of the damage specified in a request for quotation; an assessed quotation that may or may not contain an authority from insurer to proceed with the repair; a tax invoice (request for payment) from repairer to insurer in respect of an authorised repair; a payment authority from insurer to repairer in response to a request for payment.
32. A protocol for the control of an insurance repair process according to claim 31, wherein the protocol is expressed in a specific implementation of extensible Markup Language (XML) containing syntactical facilities for mandatory fields, field grouping and allowable values for the specific set of allowable messages within the transmissions.
33. A protocol for the control of an insurance repair process according to claim 31 or 32, wherein each message is described in a Document Type Definition (dtd) detailing the syntax and nesting of each element including limited data reference sets and allowable values for each element and its attributes.
34. A protocol for the control of an insurance repair process according to claim 31, 32 or 33, wherein each message is regulated during transmission through the use of predefined tags that enclose each message and each specific occurrence of a field contained within a message transmission.
35. A protocol for the control of an insurance repair process according to any of claims 31 to 34, wherein the possible transmission order of the allowable messages is predefined.
36. A quotation data exchange for the control of an insurance repair process as herein described with reference to the accompanying drawings.
37. A method for controlling an insurance repair process as herein described with reference to the accompanying drawings.
38. A protocol for the control of an insurance repair process as herein described with reference to the accompanying drawings.
PCT/AU2001/001078 2000-08-29 2001-08-28 Quotation data exchange WO2002019179A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU2001281606A AU2001281606B2 (en) 2000-08-29 2001-08-28 Quotation data exchange
AU8160601A AU8160601A (en) 2000-08-29 2001-08-28 Quotation data exchange
NZ524397A NZ524397A (en) 2000-08-29 2001-08-28 Quotation data exchange

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
AUPQ9750 2000-08-29
AUPQ9750A AUPQ975000A0 (en) 2000-08-29 2000-08-29 Quotation data exchange (qde)
AUPR3297 2001-02-22
AUPR3297A AUPR329701A0 (en) 2001-02-22 2001-02-22 Quotation data exchange (qde)

Publications (1)

Publication Number Publication Date
WO2002019179A1 true WO2002019179A1 (en) 2002-03-07

Family

ID=25646424

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2001/001078 WO2002019179A1 (en) 2000-08-29 2001-08-28 Quotation data exchange

Country Status (2)

Country Link
NZ (1) NZ524397A (en)
WO (1) WO2002019179A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5128859A (en) * 1990-09-12 1992-07-07 Carbone Albert R Electronic accident estimating system
US5504674A (en) * 1991-02-19 1996-04-02 Ccc Information Services, Inc. Insurance claims estimate, text, and graphics network and method
US5950169A (en) * 1993-05-19 1999-09-07 Ccc Information Services, Inc. System and method for managing insurance claim processing

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5128859A (en) * 1990-09-12 1992-07-07 Carbone Albert R Electronic accident estimating system
US5504674A (en) * 1991-02-19 1996-04-02 Ccc Information Services, Inc. Insurance claims estimate, text, and graphics network and method
US5950169A (en) * 1993-05-19 1999-09-07 Ccc Information Services, Inc. System and method for managing insurance claim processing

Also Published As

Publication number Publication date
NZ524397A (en) 2003-11-28

Similar Documents

Publication Publication Date Title
US7231354B1 (en) Method, apparatus, and computer-readable medium for administering the implementation of product change notices
US7742958B1 (en) System and method for preparing a tax return using electronically distributed tax return data
US7941744B2 (en) System and method for electronic document generation and delivery
US7181420B2 (en) Methods and systems for online self-service receivables management and automated online receivables dispute resolution
CA2488477C (en) Payroll processor system and method
US7958046B2 (en) Computer systems and methods for providing credit information data
US20080243556A1 (en) Historical insurance transaction system and method
US20020069096A1 (en) Method and system for supplier relationship management
US20060053168A1 (en) Document processes of an organization
JP6259421B2 (en) System and method for submitting legal documents
US20040199413A1 (en) System and method for providing service for a product
WO2005059690A2 (en) Method and system configured for facilitating management of international trade receivables transactions
CN102216926A (en) Remote web-based document creation system and method
CN109062872B (en) Method for uniformly processing customs files with different formats
US20030101114A1 (en) System and method for collecting and analyzing tax reporting surveys
KR100339643B1 (en) System and method for trading business management in Internet web
US7774352B2 (en) Method of reversing an erroneous invoice
AU2007229413A1 (en) Quotation data exchange
CA2913198C (en) Managing customs information
WO2002019179A1 (en) Quotation data exchange
AU2001281606A1 (en) Quotation data exchange
CA2655000A1 (en) Method and system for managing vendor information
AU2001281606B2 (en) Quotation data exchange
NZ548455A (en) Quotation data exchange
US20020069273A1 (en) System and process for administration of databases

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2001281606

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 524397

Country of ref document: NZ

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
WWP Wipo information: published in national office

Ref document number: 524397

Country of ref document: NZ

WWG Wipo information: grant in national office

Ref document number: 524397

Country of ref document: NZ

NENP Non-entry into the national phase

Ref country code: JP

WWG Wipo information: grant in national office

Ref document number: 2001281606

Country of ref document: AU