Business Intelligence Network - The Vision for BI and Beyond

Insurance Data Standards – Designing XML Messages (continued)

Accounting for the Unknown

Published: May 23, 2006

This is the final article in a series that explores the issues around using XML to develop data standards in the insurance arena. This series addresses how to design XML messages for standards purposes.

In the third article of this series, I described some basic reasons for success behind one of the insurance XML standards. One key reason for its success was how the transactions were defined in the XML data stream. Instead of a specifically named aggregate, they made a controversial choice and went with a type code. At first glance, the power behind this decision may not be apparent. Only after trying to use the standard for more than what it was originally defined do we really recognize the strength – its reusability. If the standard is reusable in ways not previously defined, only then will we see widespread adoption. In this case, if I want to use the standard for a business process not yet defined, I simply add a new code value. I don’t have to create a new schema or jump through any other hoops. I just use a different code value. This allows me to use the standard both for the transactions that are specifically defined along with all my unique internal proprietary purposes without having to do anything extra. It makes it quite powerful.

To continue in this vein, a related reason why this particular standard has seen such success as both an internal and external standard is the methodology used to add new data to an aggregate. Insurance processing is all about the data. No matter how fully defined a standard becomes, there will always be a need for more data elements than what is available, either because it is a new requirement or it is something unique and proprietary to a company. One attempt to support this concept is using the abstract class and inheritance concept that was discussed in my previous article. So, to add a couple of elements to the Insured aggregate, you create a new aggregate, say InsuredExtended, derive it from Insured and add your unique requirements. You then have to notify your trading partners that you are using this new custom schema and that you are using InsuredExtended in the place of Insured in your message. To support this, everyone would have to do custom development.

The standard that has seen success uses a radically different approach. Instead, it took advantage of an XML schema concept called “ANY.” This is a specialized data type that says you can put anything into this space as long as it is well formed XML. To support data elements not defined in the schema, they added a section on every single aggregate that acts as a “bucket” to put anything additional that is needed. This allows companies to easily extend a data stream without having to touch the schema. They can define with their trading partners which new elements to process. If not required, they can all be ignored. This flexibility is tantamount to being able to take a standard to a level that it can be used within an enterprise.

Much of my business is spent with companies on how to best extend an existing XML schema for use for additional data elements not defined or business processes not yet addressed. In most cases, because of the methodology employed in the original schema, it requires a significant effort in both defining the data elements and schema constructs and, more importantly, communicating with your trading partners to accept and process the custom XML message. Bottom line is that it becomes rather costly. What happens in practice is that companies abandon their effort to reuse the standard and develop something custom anyway. Why? It just seems easier… and no more expensive.

Companies that started with a schema that took advantage of the basic principles described in this series achieved tremendous success because what they built was completely reusable.

In this series of articles, we covered the main reasons why we’re seeing great adoption of one standard in the insurance space, while another standard struggles along. Following is a summary of the success factors:

1. Maintain true backward compatibility. This allows you to build to multiple versions of the same standard, depending on when you start a particular implementation, and be able to communicate with systems on other versions.
   
   
2. Use code values for transaction identification. This provides the facility to use the standard for other transactions not defined without having to touch the schema.
   
   
3. Use a data model structure in the XML itself. This gives you consistency across messages, giving you a huge payback after you roll out more than one or two messages. Also, it is a necessary component for being able to reuse the standard for messages and business processes not specifically defined.
   
   
4. Provide “buckets” for extending the schema throughout the hierarchy so that the data stream can be processed by someone who doesn’t know anything about your extensions as well as someone who does. Minimize the amount of work and thus the cost associated with accepting extended data sets.

Finally, the two overriding factors behind the success of any standard: Just keep it simple and reusable. If you maintain that mantra, you’ll achieve the adoption for which you are striving.