Global Insurance Ontology
The global insurance market is a huge data exchange ecosystem. To enable integration between players, many components need to be standardised, including data models, available services, and authentication flows. There are many standards in place that vary in scope, structure, age, and other characteristics. For example, many countries are using their own national data models. Meanwhile, existing players and new tech companies are pushing for innovation. Many of these initiatives are facing issues due to the following problems some of the existing standards have:
In order to support developers, our initiative is focused on creating and continuously improving a set of schemas to model data in the insurance context. The main benefit of our schemas is that they can be used to model API resources, i.e. JSON data being exchanged in RESTful APIs. We aim to make our schemas
It is important to note: the idea is not to replace but to supplement local standards like BiPRO, OMDS, EIAC, etc. since those commonly standardize various things like service structure and authentication flows as well. We intend to add a contribution and to drive innovation by making our work public.
Our guiding principle for data modelling is simplicity. Highest-level classes and entities should be as close to the real world as possible. They should be intelligible in a broad context - and not overly technical or intelligible in very specific contexts only.
When thinking about insurance, people think of their belongings, health and risks, of future damages that could affect them. Ultimately, they think of how to mitigate those damages. So to create customer-centric services, the underlying data-model should also focus on these things. This is why we built our high-level model as follows:
simplified model
To make sure it is complete, the ontology has been validated against various existing APIs and standards. It is designed to serve as the common denominator underpinning all standards and models. This is particularly important given that the data flow involving insurance providers and other players needs to contain the necessary information to process requests and provide services - and each data model encodes information a bit differently. The schemas will be extended permanently to keep increasing completeness.
Our schemas are all json-schemas structured in the following way.
Schemas are classified into 2 groups. Each of them are available in a full variant containing every possible field and a minimal variant containing only the most important fields. Minimal variants coming soon.
$ref
references$ref
references.To strike a balance between simplicity/practicality and expressiveness, parameters in the schemas are modeled exclusively by basic data types as described in the following table:
type | additional formats | arrays thereof |
---|---|---|
string |
date |
Yes |
integer |
- | Yes |
number |
money |
No |
boolean |
- | No |
Recurring definitions are factored out for reuse, e.g. money fields. Every schema includes all relevant definitions so that the schemas look like this:
{
"type": "object",
"properties": {
...
},
"definitions": {
...
}
}
For core schemas, all the definitions are in definitions.json
.
Core Schemas are found in /schemas/core
. Example: person.json
contains all properties to describe a person:
{
"type": "object",
"properties": {
"birthdate": {
"description": "birthdate of the person",
"type": "string",
"format": "date"
},
"gender": {
"description": "gender",
"type": "string",
"enum": [
"m",
"f",
"o"
],
"enum-description": [
"male",
"female",
"other"
]
},
...
}
}
Note that the meta-tags description
and enum-description
are not part of standard json-schema - we added them to make schemas more self-descriptive. Json-schema is based on the tolerant reader principle, so that this data won't hurt any parsers or tools.
Product reference model schemas are found in /schemas/products
. Note that the fields in these schemas are paths to the respective classes, containing the relationships between them. Actually, a product reference model schema is not strictly defining a class. It is a set of parameters needed to describe a complete situation involving many classes and relationships in an efficient way. Example: accident.json
contains all parameters to describe an accident insurance situation, including information about the insured person, the included coverages, limits and deductibles.
{
"type": "object",
"properties": {
"person.birthdate": {
"description": "birthdate of the person",
"type": "string",
"format": "date"
},
"person.gender": {
"description": "gender",
"type": "string",
"enum": [
"m",
"f",
"o"
],
"enum-description": [
"male",
"female",
"other"
]
},
"product.accident.coverage.accident-costs-and-medical-expenses.deductible": {
"description": "deductible for given coverage(bundle) or product",
"type": "number",
"format": "money"
},
"product.accident.coverage.accident-costs-and-medical-expenses.is-included": {
"description": "coverage is included in the product",
"type": "boolean"
},
...
}
}
Anyone can download our schemas and use them in their APIs, databases and more. Current users include riskine (docs) and koble (docs)
Since all of the schemas are json-schema, you can use the wealth of json-schema utilities to get started - or build your own.
AccidentInsurance
from the accident.json
using quicktype.io. You can, of course, omit fields from the schema as neededaccident.json
into your OpenAPI 3 definitionAccidentInsurance
classDon't hesitate to reach out with feedback or input.
We will keep improving the existing schemas. At the same time, we are looking at ways to expand our offering into the following directions:
The Global Insurance Ontology is created and maintained by riskine.com in co-creation with koble.io. Chief maintainers are riskine CTO Johannes Seebacher and Bettina Ponleitner.