12.2. AFD Short

Based on the article ‘AFD Short – AFD 2.0-structuur met AFD 1.—attribuutnamen’ (in SIVI AFS Magazine June 2023).

Transition to AFD 2.0

The transition from AFD 1.0 to AFD 2.0 was necessary for many reasons. In addition to the switch from SOAP/XML to REST/JSON, various editorial changes have been made to the AFD. For example, the data catalog has been reformed into a structure that is easier to understand and implement. Around thirty core entities, each with different entityTypes, provide clear subsets of attributes. We performed a cleanup on code lists, attributes, and entities that were erroneous, duplicated, or had been in the data catalog over the years but are no longer in use. In addition, we have added structures to SIVI AFS for the exchange and registration of different message types, such as the policyStructure for policy-related messages, claimStructure for claim-related messages and partyStructure for structuring party data.

With the transition to JSON, we have moved away from the outdated data formats of AFD 1.0 and in AFD 2.0 we keep the common data types of JSON: string, integer, decimal, boolean, date, time and datetime, with the option to add specifically defined attributes. pass multiple values through an array. The attribute names are also written out in full and in English, making them a lot more readable than the seven-letter abbreviations in AFD 1.0. For example, MRHSNRS from AFD 1.0 is now called buildingWithMultipleHouseNumbers in AFD 2.0. All changes that are necessary for our customers. After all, with regard to use, they want a standard with a relatively low learning curve, which fits in well with the tooling they use. In addition to employability, applicability also plays a major role in the transition from AFD 1.0 to AFD 2.0. AFD 2.0 is essential for setting up database structures based on semistructured data and NoSQL, because AFD 2.0 has unambiguous naming of attributes across entities and supports explicit references.

Stay connected to existing systems

The transition from AFD 1.0 to AFD 2.0 can have a significant impact. Especially if you want to use a service based on AFD 2.0, while your application is used to handling AFD 1.0 messages. Or when you build an application yourself that uses AFD 2.0, but needs to exchange data with outdated 1.0 applications. Some of these applications have been in use for so long that an update to a new data model cannot be arranged at the touch of a button, or does not fit into the schedule.

In AFD 1.0, the attribute names are always formatted in the same way according to _, as in PP_NUMMER (policy number). Many applications that process AFD 1.0 messages therefore do not – or only to a very limited extent – look at the structure of a message, and look primarily at the naming of attributes. Adjusting the message structure or syntax is therefore not the biggest problem for such applications; the bottleneck in the transition to AFD 2.0 is primarily the completely different naming of attributes.

AFD Short: AFD 2.0 with AFD 1.0 attribute names

It should be easier for organizations to process AFD 2.0 messages, or to develop their own software based on AFD 2.0, while there are also applications that are set up for AFD 1.0. That is why SIVI comes up with a hybrid intermediate form: AFDshort. In terms of syntax, structure and content, AFDshort is completely identical to AFD 2.0, but – the name says it all – the labels are written in AFD 1.0. If the 2.0 label also exists in AFD 1.0, then the label in AFDshort is equal to the AFD 1.0 label. If the label does not exist in AFD 1.0, then a unique, abbreviated label has been included for AFD 2.0 according to the spelling of AFD 1.0. For example, the “addressRef” attribute, which is not present in AFD 1.0, translates to “ADDREF” in AFDshort. And also for entities, we’ve included short, two-letter codes when an AFD 2.0 entity is not in AFD 1.0. For example, the ticket entity from AFD 2.0 with entityType “default” has an AFDshort equivalent with code “YK”.

In terms of content, there is only one difference between AFD 2.0 and AFDshort messages: the entity type. The entity type in AFD 2.0 is in AFDshort the reference to the specific entity and has a value based on the AFD 1.0 naming convention (two letters). In the example above you can see that “entityType”: “policyDetails” translates to “PP_ENTITEI”: “PP”. We translate the entity itself using the combination entity and entityType: you can see above that coverage with entityType “accident” (AFD 2.0) corresponds to “OD” in AFDshort, while coverage with entityType “legalCounsel” translates to “RP” .

Look at the example again, and note that nothing else changes in terms of content when translating from AFD 2.0 to AFDshort. In other words, booleans remain booleans, date fields remain in AFD 2.0 format, and the number of decimal places does not change. That is why AFDshort is emphatically not AFD 1.0: after all, there are no booleans (only “Y” and “N” fields), date fields have the old EDIFACT notation (without dashes) and almost all decimal fields have a maximum of three decimal places. This is a conscious choice that ties in with the challenge we identified earlier: many applications for which we offer this mapping can easily handle the switch to JSON and associated formats, but are very much geared to the AFD 1.0 naming convention when processing messages. attributes.

Support through the SIVI mapping-API

For easy integration, SIVI will soon offer a mapping in the SIVI mapping API that converts AFD 2.0 messages to AFDshort. If you are interested – for example in test files – or if you have any questions, please contact Robin Oostrum via robin.oostrum@sivi.org.