SOAP cleans up Health Benefits processing

XML and SOAP were just emerging standards when Health Benefits started building its online claims system two years ago. The resulting Generic Transaction Processing System went live in October and XML and SOAP are now accepted as the way of the future.

XML and SOAP were just emerging standards when Health Benefits (HBL) started building its online claims system two years ago. The resulting Generic Transaction Processing System (GTPS) went live in October and XML and SOAP are now accepted as the way of the future.

IT consultant John Anderson, who worked on the project to create the GTPS, which processes health subsidy claims for pharmacists and GPs, spoke about it to IT professionals at an IBM WebSphere integration seminar last week.

HBL, which used to be called the Health Funding Authority, distributes $1.2 billion in primary health care subsidies each year. It wanted a system that could validate and process 72 million transactions a year. The claims criteria is complex and changes regularly, so the system had to be flexible to cope with volatile business rules. A lot of the processing is still done by batch so it also had to be capable of random online transactions and batch processing. Another requirement was to provide an audit trail of what happened to each claim as it was processed.

There are 30 different claims types coming in from 6000 claimants with every system imaginable — legacy, email, floppy disk, EDI and web forms.

Derek Williams was project director and Laurie Hope, project manager. The project team was very senior, with each person having a “big systems” background, says Anderson.

The aim was to use out-of-the-box product as much as possible. Architecturally the objectives were robust, flexible, fast, scalable, extensible and cost-effective. Because of the volume of transactions, there was a requirement for asynchronous processing so that additional hardware could be added to a farm of machines as needs grew. The architecture settled on was one of message processing.

“It’s not a transaction-processing system, it’s a message-switching system,” says Anderson.

HBL standardised on a generic message format, with lots of loosely coupled sub-systems. Messages flow from sub-system to sub-system (such as transaction routers, rules engine and data warehouse) using IBM MQSeries. Instead of the system having to keep track of the state of interaction (usually by setting values in a storage field designated for that purpose), an approach called “message enrichment capsulating state” was used, whereby the message holds the state inside if from beginning to end and it grows as it goes through the system.

If a message doesn’t go through MQSeries sends it again, but if a message goes through twice it is picked up by the rules engine. By the time a message gets to the rules engine, Attar X-pert Rules, all the information is inside it for a decision to be made. Having made a decision, the entire message is archived.

The system was built adhering to Java, XML and related standards. Java MX, an emerging standard for managing remote Java processing, was used. Apache SOAP was chosen as the transport mechanism to other systems with the thinking that if SOAP didn’t take off HBL would only be committed to a certain document type definition structure. However, HBL now uses SOAP to talk to all other systems. IBM WebSphere was chosen as the application server. Server side development was done with IBM VisualAge for Java and client side was built with Borland Delphi and Visual Basic.

Join the newsletter!

Error: Please check your email address.

Tags soap

More about ApacheBorland AustraliaIBM Australia

Show Comments

Market Place

[]