Digital information interchange in the insurance industry - Transfer of electronic documents - Part 2: Implementation of EN 17419-1 in Open API 3.0 specification

This document specifies a concrete REST webservice API description of the processes and data
(see EN 17419-1:2020 for more information) as an OpenAPI definition specified by the OpenAPI
specification.

Digitaler Informationsaustausch in der Versicherungswirtschaft – Übertragung elektronischer Dokumente – Teil 2: Implementierung der EN 17419-1 in Open API 3.0 Spezifikation

Digitalna izmenjava informacij v zavarovalniški dejavnosti - Prenos elektronskih dokumentov - 2. del: Izvajanje EN 17419-1 v odprti specifikaciji API 3.0

General Information

Status
Withdrawn
Publication Date
03-Aug-2021
Current Stage

Relations

Buy Standard

Technical report
TP CEN/TR 17419-2:2021
English language
61 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)


SLOVENSKI STANDARD
01-oktober-2021
Digitalna izmenjava informacij v zavarovalniški dejavnosti - Prenos elektronskih
dokumentov - 2. del: Izvajanje EN 17419-1 v odprti specifikaciji API 3.0
Digital information interchange in the insurance industry - Transfer of electronic
documents - Part 2: Implementation of EN 17419-1 in Open API 3.0 specification
Digitaler Informationsaustausch in der Versicherungswirtschaft – Übertragung
elektronischer Dokumente – Teil 2: Implementierung der EN 17419-1 in Open API 3.0
Spezifikation
Ta slovenski standard je istoveten z: CEN/TR 17419-2:2021
ICS:
03.060 Finance. Bančništvo. Finances. Banking. Monetary
Monetarni sistemi. systems. Insurance
Zavarovanje
35.240.20 Uporabniške rešitve IT pri IT applications in office work
pisarniškem delu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TR 17419-2
TECHNICAL REPORT
RAPPORT TECHNIQUE
August 2021
TECHNISCHER BERICHT
ICS 03.060; 35.240.20
English Version
Digital information interchange in the insurance industry -
Transfer of electronic documents - Part 2: Implementation
of EN 17419-1 in Open API 3.0 specification
Digitaler Informationsaustausch in der
Versicherungswirtschaft - Übertragung elektronischer
Dokumente - Teil 2: Implementierung der EN 17419-1
in Open API 3.0 Spezifikation
This Technical Report was approved by CEN on 11 July 2021. It has been drawn up by the Technical Committee CEN/TC 445.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2021 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 17419-2:2021 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 3
1 Scope . 5
2 Normative references . 5
3 Terms, definitions and abbreviations . 5
3.1 Terms and Definitions. 5
3.2 Abbreviations . 5
4 Technical basis for OpenAPI definition . 5
4.1 Cloud services and REST . 5
4.2 JSON data format . 6
4.3 YAML data format . 6
4.4 OpenAPI Specification . 6
5 OpenAPI specification for EN 17419-1:2020 . 7
5.1 Introduction . 7
5.2 OpenAPI document . 7
5.3 OpenAPI document in YAML format . 7
6 Data samples for Request body . 33
6.1 Insurance Transaction – maximum expression . 33
6.2 Sample – Transfer from insurer to intermediary with insurance transaction issued by
insurer and addressed to intermediary . 47
6.3 Sample – Transfer from intermediary to insurer with insurance transaction issued by
intermediary and addressed to insurer . 49
6.4 Sample – Transfer from insurer to intermediary with insurance transaction issued by
insurer and addressed to client . 51
6.5 Sample – Transfer from service provider to intermediary with insurance transaction
issued by insurer and addressed to client . 53
6.6 Sample – Transfer from intermediary to insurer with insurance transaction issued by
client and addressed to insurer . 55
6.7 Sample – Transfer from insurer to intermediary with insurance transaction issued by
insurer and addressed to client, with a document that is to be signed by the client . 57
6.8 Sample – Transfer from intermediary to insurer with insurance transaction issued by
client and addressed to insurer, with a document that has been signed by the
client . 59
European foreword
This document (CEN/TR 17419-2:2021) has been prepared by Technical Committee CEN/TC 445
“Digital Information Interchange in the Insurance Industry”, the secretariat of which is held by DIN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
Introduction
The EN 17419-1:2020, Digital Information Interchange in the Insurance Industry — Transfer of electronic
documents — Part 1: Process and Data Model, defines the transfer of electronic documents between
stakeholders in the insurance industry (for example between insurers and intermediaries):
• the semantic process for the transfer of documents that may be transferred as an attached file; and
• a limited number of meta data describing the document.
The definitions are described in the standard on a semantic level with process and data models in a
syntax-neutral format independent from its representation in a concrete implementation syntax.
This document exemplifies a concrete implementation of the EN 17419-1:2020 as an OpenAPI
specification. The OpenAPI syntax is published by the OpenAPI Initiative, an open-source collaboration
project of the Linux Foundation, and is a specification for machine-readable interface files for describing,
producing, consuming, and visualizing RESTful web services.
This document is a guide for organizations that want to implement the EN 17419-1:2020. Even more, the
specification contained in this document can be directly implemented with OpenAPI tools that can
automatically generate code, documentation and test cases.
All stakeholders that want to implement EN 17419-1:2020 will benefit from the implementation guide
described in this document due to:
• Uniform implementation of EN 17419-1:2020 across the industry, based on a common technology.
• Avoidance of divergent implementations, thus avoiding incompatible digital interfaces between the
stakeholders.
• Implementation for RESTful web services, a common micro-service technology.
• Specification in OpenAPI syntax, a common basis for the definition of RESTful web services.
• Automatic generation of code, documentation and test cases, based on OpenAPI tools.
• Facilitated implementation will accelerated the application of EN 17419-1:2020.
• Facilitated implementation will accelerated the usage of EN 17419 by SMEs.

1 Scope
This document specifies a concrete REST webservice API description of the processes and data
(see EN 17419-1:2020 for more information) as an OpenAPI definition specified by the OpenAPI
specification.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 17419-1:2020, Digital Information Interchange in the Insurance Industry — Transfer of electronic
documents — Part 1: Process and Data Model
3 Terms, definitions and abbreviations
3.1 Terms and Definitions
For the purposes of this document, the terms and definitions given in EN 17419-1:2020 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at https://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
3.2 Abbreviations
API Application Programming Interfaces
JSON JavaScript Object Notation
OAS OpenAPI Specification
OAI OpenAPI Initiative
REST Representational State Transfer
SOAP Simple Object Access Protocol
XML Extensible Markup Language
YAML Yet Another Markup Language
YAML Ain’t Markup Language
4 Technical basis for OpenAPI definition
4.1 Cloud services and REST
In a more and more communication based and service orientated IT infrastructure, the ease of use,
implementation, operation and maintenance of IT-services as main economic success factors determine
the type of underlying architectures and tools to be used. Cloud enabling of services as one strategic
aspect allows to reduce the time to market of products while focussing on core competence – the business
aspects - of IT activities.
REST APIs as a software architecture describe interfaces to communicate through the HTTP(S) protocol
between distributed client and server systems as an alternative to SOAP. RESTful implemented services
are stateless. That means, all data required for creating a service response is transmitted in the
corresponding service request. Advantages of RESTful services are a better visibility, reliability and
scalability.
4.2 JSON data format
IETF RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format
(https://tools.ietf.org/html/rfc8259)
ECMA-262, ECMAScript® Language Specification (https://www.ecma-international.org)
With REST-Services usually the JSON data format, as a derivation or concretization of the YAML format is
used, which is very slim and better human readable in contrast to the structure description orientated
language of XML. JSON is more a syntactical convention for describing data in a given context by allowing
an easy machine processing and parsing because of its strict structure definition.
Based on the JavaScript Programming Language Standard ECMA (http://www.ecma-international.org),
the data interchange format JSON was first specified by Douglas Crockford in 1999.
4.3 YAML data format
Oren Ben-Kiki – Clark Evans – Ingy döt Net, YAML Ain’t Markup Language (YAML™) Version 1.2
(https://yaml.org/spec/1.2/spec.html)
YAML is a simplified markup language to describe data in a more human readable way. It was invented
in about 2001 and the most current version 1.2 (3rd Edition) was published in 2009.
YAML can be viewed as an easy to implement and use natural and consistent superset of JSON. Every
JSON file is also a valid YAML file. The main focus on YAML is to provide a programming language
independent data interchange format as a technical markup language with a maximum in human
readability and information providing.
It consists mostly of a kind of key-value mechanism where values also may be lists (arrays) itself.
4.4 OpenAPI Specification
The OpenAPI Specification (OAS, https://www.openapis.org) defines a vendor neutral and human
readable interface description for REST APIs, originally based on the Swagger Specification (Open Source
Framework Swagger for HTML-Webservices) and was provided in 2016 by the OpenAPI Initiative
(https://www.openapis.org). Further development and maintainance is done by the initiative and is
supported of the Linux Foundation.
OpenAPI descriptions of REST APIs are implemented in OpenAPI documents. An OpenAPI document that
conforms to the OpenAPI Specification is itself a JSON object, which may be represented either in JSON or
YAML format.
There is an uncountable number of tools available in the world wide web for creating or dealing with
OpenAPI documents. One important Open Source tool is the Swagger-Editor
(https://swagger.io/tools/swagger-editor/), which allows the creation of OpenAPI conformed REST API
definitions and the generation of documentation and code stubs for several client and server
programming languages and runtime environments.
-----------
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.