Optimal methods and effective approaches of development of enterprise information systems using customized java-based technologies and tools

Problems and specific features of working out of corporate information systems with use Java of technologies are considered. The developed methods and unique architecture which have been put into practice are offered.

The developed information system allows hospitals and insurance companies to manage claim submission and claim processing functionalities. These types of systems make the business more efficient. The new Java-based information system was implemented to improve the information processing approaches. The project modernized the claims processing environment by enabling web-based product services and enabling new technologies. Many modern computer applications have features that are web-based and delivered to the end users over an Internet. Real-time web-based access to health insurance software applications becomes a critical part of many medical systems. Intensive technological change in hardware and networking software [7] provides more choices than in the past [8]. The development of computer- assisted health insurance claim processing systems is of increasing importance for the whole area of medicine and its numerous applications [6].

Transformation Process component encompasses the receipt of transmission of real-time transaction from boundary systems by self-detection of a new real-time medical insurance claim and then performs verification to transform the claim into a common internal format of the organization.

Integration component supports database update, when messages transmit from WebSphere Transformation Extender (WTX) and Core application for real-time claim transaction [4].

Core Application component is tasked with identifying claim metadata and then validating the claim to ensure presence of accurate claim information. Also, this application stores claim information into a database. Based on the results of the validation process, a claim may be “Rejected”, “Released”, or “Suspended”.

The Message Driven Beans (MDB) reads the XML message asynchronously from the queue and parses the message [6]. The XML claim document is passed to Core Application input queue [5]. It then flows through the Core Application component, where business rules and validations are applied. All these interactions happen via message queues, between the various components [5].

Core Application component receives claim XML from a separate queue, validates the information and undergoes business rule validation and verification.

The claim XML Schema Definition (XSD) is a schema definition for the Claim Object Model, which acts as a base for the WTX to construct the claim XML file and put into the queue in compressed format [4]. The integration component receives claim information in XML format from the queue. XML is transformed to a Java Object based on the claim XSD by using Apache XMLBeans [6].

Graphical User Interface (GUI) provides claim displaying and claim correcting features. Claim operators can search for different types of claims andaccess various details of the selected claim. The information presented by the web interface is geared towards displaying claim-related information from the Database.

The application has a presentation layer, business logic layer, and data access layer [1][2][3][6]. A separation of design into code layers has advantages: the convenience of maintenance, the convenience of using various design patterns, and the convenience of selecting certain techniques for certain concerns. The team consisted of front-end developers, service developers, and integration developers [1][6]. The application consists of two distinct parts: configuration and code. [1][4]

Table 1 - Internal Dependency

Table 2 - External Dependency

The Struts framework was used to develop the front-end application. The application layer calls to the Data Access Layer (DAL) and has a dependency on the DAL physical names. Linking to external applications, such as Member Inquiry, Provider Inquiry, and Pricing Applications are limited to opening these application home pages in a new window. Single sign-on is used to open external applications. Single sign-on is used to open the Provider Inquiry application. Single sign-on allows operators to access multiple applications after login in just once.

The following is a brief description of a scenario where a user/operator can access the search functionality and search for claims. Access by user:

1. Any logged-in user/operator who has “Claim Inquiry” permissions (role-based) can access the Claim Inquiry application.
2. The application displays the medical advanced search screen by default, where the operator can key in required fields (e.g. Claim Type etc.) before hitting “Search” button.
3. Claim Type drop down menu is populated based on the access privileges given to user/operator. If the user has access to (Medical, Pharmacy) claim types, then claim type drop-down in the advanced search page will have medical, pharmacy values in the drop-down.
4. When the user/operator hits the “Search” button, the application captures the user input data, constructs the Search Criteria Object and then calls the ClaimDao via the ClaimLookupService.
5. The ClaimDao returns a list of matching claims based on input search criteria.
6. The application renders the list of matching claims (output) as the search results in a separate page. The search criteria and the selected claim type from the advanced search page is selected and displayed in the search results page.

An Operator clicks on Document Control Number of a particular “Claim” to fetch the respective Claim Details. The application then calls the ClaimDao via ClaimLookupService to obtain all the details of the selected claim as a Claim Object. The information returned via the Claim Object is then used to render the various applicable fields on the screen.

The auditing component provides the capability for an auditing function that tracks the processing of incoming medical insurance claims [6][7]. During the development, we have suggested ways for capture of auditing data at several points in the system. The functional component uses the data gathered to generate a report from the Reporting Database.

Exception Handler is needed to handle the errors that raise within the Core Application component [6]. Without the Exception Handler, Application components will not be able to handle the exceptions as expected [6]. As soon as any exception occurred, throw exception and handle this exception in Flow control, so that transaction can be rolled back and Message will be sent back to the inbound queue [6][7].

Audit data is accessible via reporting. If reporting is not available, audit data will not be accessible by end-users. The desired outcome is that the reporting system will make various audit reports available to end-users. Components of the system that are used to track insurance claim processing for performance purposes are also used to track additional processing modules for audit purposes.

The audit component does not persist data to Database directly. The data is persisted to Database during the normal flow of the claim. The data is updated to the claim object as part of the audit component. The entries stored in this table include a text field that labels a particular point in the process flow. Each entry also stores a beginning or/and ending timestamp that captures the exact time that the claim passed through the point.

The table used to store these entries is also used to track other points in the process flow that are being tracked for system performance monitoring.

The database contains the membership information. The information system makes the call to the database using Group Number and Subscriber Number, and finds a match. This part is intended to give a description of the Group and Membership Information. This is used in the process of lookup, validation and edit of the claim data during the claim processing and is invoked from the component called Core Application.

In the process of validating Claim the Core Application can make 4 call types.

1. To get Group Number with subscriber number as input, it will invoke invokeGroupBySubscriberId() method of the ServiceInvoker interface.
2. To get Group Number, without subscriber number as input, it will invoke invokeGroupByGroupNumber () method of the ServiceInvoker interface.
3. To get Group Number and subscriber details with subscriber number as input, it will invoke invoke GroupSubscriberDetailBySubscriberId() method of the ServiceInvoker interface.
4. To get Group number from alpha Prefix and subscriber number as input, it will invoke invokeGroupBySubscriberIdAlphaPrefix() method of the ServiceInvoker interface.

ServiceInvoker interface is a single point of entry for all lookup services in Core Application. ServiceInvokerImpl has the implementation for all methods in ServiceInvoker interface. GroupMemberLookupServiceImpl class makes call to the Lookup DAL layer. The DAL layer talks to the database and fetches the response data. All the call types have returnCode attribute in the response object. The returnCode has the status of the lookup performed.

• ServiceInvoker class: Is the main invoker interface for all the lookup services calls from core application.
• ServiceInvokerImpl class: Is the implementation for

ServiceInvoker Interface.

• LookupService class: Is a marker interface.
• GroupMemberLookupService class: Is an interface; it has the invoke GroupMemberLookupService method called by the ServiceInvoker.
• GroupMemberLookupServiceImpl class: This class implements the GroupMemberLookupService and is responsible for handling business logic and which in turn will make a call to DAL layer.
• GroupMemberLookupRequestImpl class: This is a data transfer object which holds the input passed from the Core Application component.
• GroupMemberLookupResponseImpl class: This is a response object that is returned back to calling application.

The Unified Modeling Language (UML) was used for specifying requirements from the technical perspective. UML use cases were developed to describe the major functionality of the proposed system, including components such as: claim processing, claim display, and claim correction. The information system was implemented with a relational database. UML was heavily used in the development of class diagrams. The use of Object Oriented (OO) principles and mechanisms, such as encapsulation and inheritance, was made. UML sequence diagrams were also used to create a technical design.

The core application calls the Provider Tax ID lookup:

1. Core application makes a call to the invokeProviderTaxIDLookupService method of the ServiceInvoker, which internally calls the implementation class ServiceInvokerImpl.
2. ServiceInvokerImpl class calls the ProviderTaxIDLookupService interface, which internally calls the implementation.
3. ProviderTaxIDLookupServiceImpl class calls method is database DAL Layer.
4. ProviderTaxIDLookupService will send the response object back to ServiceInvokerImpl class.

50

1. ServiceInvoker will send the response object back to the core application.

Table 3 - Java pseudo code

Table 4 - Java pseudo code

Following framework configuration files were updated with the entries as shown below: applicationContext-service-default.xml

<context:component-scan

base-package=" com.lookup.serviceimpl" use-default-filters="false">

<!-- Include all objects annotated with @Service --> <context:include-filter type="annotation" expression="org.springframework.stereotype.Service" /></context:component-scan>

REFERENCES

1. Boranbayev A.S., Defining methodologies for developing J2EE webbased information systems, Nonlinear Analysis (2009), doi: 10.1016/j.na.2009.02.002.
2. Boranbayev A.S., Concepts of Development of Web-based Information Technology Systems for Business Operations in an Insurance Industry. Reports of the National Academy of Sciences of the Republic of Kazakhstan, 2009, №3, pp. 8–12.
3. Boranbayev, A.S., Improving Data Quality and Enhancing Maintainability of the Component Based Computer Automated Enterprise Information System, The IABPAD Conference Proceedings, Memphis, Tennessee, USA; Volume 6, Number 3, October 22-25, 2009, pp. 990-998.
4. N.Hritonenko and Yu.Yatsenko, Creative destruction of computing systems: Analysis and modeling, Journal of Supercomputing, 38(2006), 143154.
5. Yu.Yatsenko and N.Hritonenko, Network economics and optimal replacement of age-structured IT capital, Mathematical Methods of Operations Research, 65(2007), 483-497.
6. Boranbayev,A.S., Designing and Optimizing Data Access and Processing During the Development of an Information System in an Enterprise Environment. Proceedings of the 2009 International Conference on E-Learning, E-Business, Enterprise Information Systems, & E-Government, EEE 2009, July 13-16, 2009, Las Vegas Nevada, USA. CSREA Press 2009: pp. 432-438.
7. Boranbayev A. S., Methods of Optimization of Data Access Using Queues while developing Information Systems. Proceedings of The Third Congress of The World Mathematical Society of Turkic Countries (June 30 - July 4, 2009), Republic of Kazakhstan, Almaty, 2009. Al-Farabi Kazakh National University.
8. Boranbayev,A.S., Error Handling Methodology While Developing Modern Information Systems Using Service-Oriented Architecture (SOA). Reports of the National Academy of Sciences of the Republic of Kazakhstan, 2009, №4, pp. 5–10.