AI-capable OMDS Services

OMDS LD (OMDS Linked Data) is the working title of this project. It is a revision of the OMDS 3 interface definition. It is being developed by a VVO working group as part of the OMDS 3 project. The results of the working group are evaluated by the steering committee and may be incorporated into a new standard.

A summary of the benefits is available on the page Motivation.
Try it instead of reading: the sample broker runs at /omds-ld/ and walks through the application process against the three example insurers. In the chatbot (Open WebUI) you can register and, once approved, have premiums of the example insurers calculated right in the chat.

Starting Point

The OMDS 3 interface of the Austrian Insurance Association is used to calculate insurance quotes and to submit insurance applications from intermediaries (brokers, agents) to the insurer. There are complete concepts for

  • new applications,

  • conversions and conversion support: replacement of contracts by new contracts based on a current product,

  • contract changes, e.g. changes of collection,

  • business case log: report on asynchronous status changes or events at the insurer,

  • postal service: asynchronous provision of documents.

Goals

  • Standardised business processes as business case types (Geschäftsfalltypen) on a common model: application process, contract change, conversion as well as claim notification and claims handling are described in the same grid – a business case as a bracket, business objects with states of their own, six operation kinds, the same checks and a declaration per type as process knowledge (Business Objects and Operations). The application process is the first example and is implemented and tried out first.

  • Services through which an insurer can provide its product knowledge at runtime at low cost. The product knowledge is described declaratively. The calculation remains with the insurer; the client can, however, validate product configurations itself.

  • Services that brokers can integrate easily with the help of AI.

  • For every use case it is clear which service calls to use (process knowledge):

    • The permitted process variants are listed exhaustively in the standard. Arbitrary deviations are not permitted.

    • Every insurer declares in machine-readable form which of the permitted variants it implements. A client queries this at runtime and adapts to it.

    • Where one variant clearly predominates, the standard defines it as the default case; only the deviation then has to be declared. The default case simplifies the declaration, not the client: a client must also support the deviating variant, otherwise it loses the insurer concerned.

  • The service definitions are to be backward compatible with the previous concepts. Ideally a technical wrapper makes the previous SOAP services AI-capable.

How the structural pillar (exchange objects, "what") and the process pillar (business objects, states, operation kinds, process knowledge, "how") of the vocabulary interact is described in Vocabulary Layers.

Non-Goals

  • Defining insurance products. Insurers must remain free to define any products they like.

  • Covering all lines of business at once. The work starts with motor insurance.

  • Forcing all insurers onto exactly one process path. Where no agreement can be reached, the standard lists the permitted variants and makes them queryable in machine-readable form instead of enforcing one variant.

Also out of scope: production client, contract server, person management, country-specific processes and object models, industries outside insurance, and the settlement of benefits in the insurer’s claims system. Claim notification and claims handling as a business case type, by contrast, belongs to the model; it is implemented after the application process (Approach).

Benefits

  • Lower integration costs: Brokers and software providers integrate the services with the help of AI instead of implementing every interface by hand.

  • Shorter time to market for insurers: Product variants and new product generations go to market without a software release because the product knowledge is transmitted at runtime. Products no longer have to adapt to a generic interface.

  • Greater distribution reach: If the integration effort drops, more brokers and service providers actually integrate.

  • New forms of use: AI agents can operate the services themselves. This enables applications that cannot be implemented today.

  • No more bilateral coordination: Standardised processes and machine-readable process knowledge replace the need to clarify which services are to be called in which order.

  • Verifiable conformance: Self-tests and a conformance register turn a promise into a verifiable statement.

  • Backward compatibility: Insurers can offer the new services as a wrapper on top of their existing SOAP services and thus make use of existing investments (see Backward Compatibility).

Target Group

  1. Insurers, to offer their products on the market and to enable changes to contracts.

  2. Independent intermediaries (brokers and agents), to compare insurance products, conclude insurance contracts and change existing contracts.

  3. Software providers working on behalf of brokers or with brokers as customers, such as broker management systems, aggregators and comparison services.

How the goals are to be achieved is described in Solution Approach, Business Objects and Operations, Tools and Approach.

Licence

This project is licensed under the Apache License 2.0.