Implementing a BPM Architecture for Claim Processing in Health Insurance Industry

 Roy Abraham



1. Introduction: Business Process Management deals with defining, analyzing, managing and implementing the interaction among internal systems, people and external trading partners. BPM provides a holistic approach to Software development involving technology (objective) and human behavior (subjective). In traditional systems, Business Logic (objective part) and Business Rules (subjective part) in a Business Process are tightly coupled. Hence, any requirement change, in either one, results redesign or re-factoring (depends on the extent of the change) of business process. However, laws, rules and regulations of certain business processes change constantly. This necessitates the decoupling or loose coupling of Business Rules and Business Logic. Business Logic is hard coded (means, business logic change depends only on requirement change). On the other hand, transient changes in rules, laws and regulations are encapsulated in Business Rules. These Business Rules may or may not need human intervention. Business Logic is implemented in Application server (for example, an EJB or IoC container). Business Rules, which need human intervention is implemented in Workflow server. Business Rules, which do not need human intervention is implemented in Rules Engine.

2. Components of BPM: The major components of BPM are described below.

a) Business Logic: Defines the objective behavior of permanent nature. In software terms, this attribute never changes unless and until requirement changes. This also implies that there is nothing absolutely permanent in software development. The core business model of the enterprise is captured in the business logic.
b) Business Rules: Defines the objective behavior of transient nature. However, this attribute changes within the confines of the requirements. This encapsulates the forces outside the enterprise which influence the core business model such as market forces and government policies. The daily or weekly promotion sale of the company or changing the sales tax structure due to government policies are few such examples.
c) Work flow: Defines the subjective behavior of transient nature. This is where the human aspect interacts with the core business model. For example, a customer agent partially forgives the overdue penalty of a customer and her supervisor completely forgives it due to good payment record of the customer.
d) Trading Partner Interaction(B2B integration): Defines the business relationship with other enterprises. In the current integrated business environment, business to business transaction is inevitable one way or the other.
e) Enterprise Application Integration(EAI): Defines the integration of various software and data assets within the enterprise. It can be legacy assets accrued over the years such as main frame or software written in C language.
f) Life cycle management: Almost every business model has to perform a sequence of tasks from inception to fulfillment, to complete the business process. It can be a claim processing, an order fulfillment of a shopping cart or a loan processing etc. BPM provides the state management of individual steps involved in the Business Process.

Figure 1: Components of BPM



g) Monitoring: The entire software development project is business requirement driven. The business requirement is stake holder driven. Hence, directly or indirectly the business manager is the ultimate stake holder of the software development. However, the business manager may not have the technical acumen to understand the complexities of the software process. She has to believe what she is told by the development team. This poses considerable challenge to the Business Manager on day to day operations of Business Process. The monitoring tools of BPM provide such a visibility to the business process. Monitoring may include but not limited to Business Activity Monitoring (BAM) of Key Performance Indicators(KPI), Six-Sigma, compliance monitoring (like SOX), process analytics etc.


3) Necessity of BPM:
A typical example in health insurance industry is the life cycle of a claim processing. Rules and laws continuously change as new legislation come into effect every year. However, it is extremely difficult to change or re-factor the existing applications which process the claims as per every change in the health care law. The best strategy is to separate business logic and business rules from the business process. The subjective and transient claim features are encapsulated in business rules. The objective and permanent claim logic is encapsulated in business logic. The Business logic may reside in various disparate systems which needs to be integrated (EAI) using EJB, JMS, JDBC etc. Whenever a health care law changes, the business manager create a business rule associated with the new law and stores it in a rules engine. When the system receives a claim, the application server applies business logic and rules engine applies business rules on the claim data. The claim is sent through a Workflow if it needs to go through human intervention such as evaluating various steps in the claims. In most of the cases external trading partners (B2B integration) are to be involved such as health care providers. In many cases, data and software assets reside in legacy systems and other disparate systems which needs to be integrated. For example, medicare claims are processed in C based systems while medicaid are processed in COBOL systems. Above all, an oversight by the Business stake holder or upper management (using BAM) is essential for the proper management of the life cycle of the claim. To integrate such a complex and disparate business process, a BPM system is absolutely necessary.

Figure 2: BPM Project life cycle in modified waterfall methodology


4) Architecture of BPM: A BPM system must be able to integrate with Application server environments, Workflow servers, Rules engines, B2B trading partners, Legacy systems and Enterprise application Integration systems. The BPM system must provide a design environment to capture and model the business process and create compile time stubs. The BPM application must have a process engine to monitor the run time processing and KPIs. A high level, logical, design time and run time architectural topologies are shown below.

Figure 3. BPM Logical Architecture

Figure 4. BPM Design Time Architecture

Figure 5. BPM Run Time Architecture

Figure 6. BPM Run Time Architecture in Amazon Cloud

5) Design and Building a BPM application: The following steps describe salient features of a BPM application from design to production release.

a) Capturing and Modeling Business Processes. The first step is to capture the logical business process with the help of a business stake holder (or business analyst). Coarse grained processes may be sub-processed to capture underlying fine grained processes. The business analyst may iterate through the processes to refine the business process model. Steps are used to capture the business process and transitions are used to direct the flow among the business process. Such a logical Business process model is shown below.

Figure 7. Logical Business Process Model

Figure 8: Logical Business Process Model using BPMN notation


Using a Modeler or Designer, create a physical business process model out of the logical one. Create stub to develop code to represent the inlaying process. Such a physical model is shown below.

Figure 9. Physical Business Process Model



b) Creating and mapping Logical Data Dictionary (LDD). The LDD is a master reference table containing each and every attribute used in the business process. The meta data pertaining to each attribute is described in the table such as data type, data size, default value, list of values if enumerated, definition of attribute, container hierarchy (xPath) and type of attribute. The relative location of the attribute depends on the structure of the format where the attribute is located as shown in the figure below.

Figure 10. Data transformation and mapping in data formats.



The naming convention and associated meta data information are captured under each domain specific formats. For example, three attributes - order number, social security number and credit card type as it passes through different domain formats are shown below.

Figure 11. Logical Data Dictionary



The LDD is used as a reference document by analysts, architects, designers, developers, managers and testers for their respective needs. If LDD becomes too big to manage, it can be split into domain specific categories. The initial investment in the form of effort and time to build a Logical Data Dictionary is considerable. However, it is worth every penny as it prevents potential problems during the subsequent application development.

c) Creating the Canonical data structure. A canonical document, usually in XML format has to be derived based on the attributes collected in LDD. Thus, the LDD contains every attribute and its structure based on xPath. Different types of strategies can be used to arrive at the canonical XML. The canonical XML can be a subset of industry standard (as HL7 or HIPPA as in health care industry), a combination of HL7, ACORD and trading partner proprietary XML, derived from Business Objects or entirely a new XML structure as shown below.

Figure 12. Derivation of canonical data structure



d) Identifying and creating Unique Id. Every instance in the Business Process is identified by a unique id, similar to RFID (Radio Frequency IDentification). This id enables to maintain the life cycle of the instance even if it leaves the business process engine. For insurance claims, it can be social security number.

Figure 13. Canonical document based on HL7


e) Develop necessary code within the created stub. once physical BPM model is created, a stub code can be generated to hold the underlying business process. Generate and test the code within the stub.
f) Monitoring the Business Processes. Once deployed into production, each instance can be monitored using a monitor or BAM enabled portal interface as shown below.

Figure 14. Monitoring of a BPM instance at run time, Successful processing of the claim.

Figure 15. Monitoring of a BPM instance at run time, claim fails at process consumer step.

Figure 16. Monitoring of a B2M instance at run time, resubmitting the failed step




6) Big Data analysis in BPM:As BPM claim process gather large amount of data, those data can be used for big data analysis. These data can reside in various sources in various format such as Object data in S3, NoSQL data in DynamoDB, Relational data in RDS,  Warehouse data in RedShift, Archived data in Glacier and Streamed data in Kinesis. These data can be used, for example for predictive analysis. To test the billing claim variables against the time series (ARIMA - AutoRegressive Integrated Moving Average) model or against random walk (MCMC - Markov Chain Monte Carlo) using Python as shown below.

Figure 17. Big Data analysis using EMR (Elastic Map Reduce) Cluster.

 • EC2 instances are created in a VPC(Virtual Private Cloud) in the respective Availability Zone.
 • A master node and slaves nodes are created in each EC2 instance.
 • Hadoop, Spark and Python code to run ARIMA mode is installed in the Master node. Hadoop and Spark are managed by YARN in the master node. Fail over is managed by AutoScaling group in the cluster.
 • Input data is read from any of the data sources and processed by the Python code. The results are written to one of the data storage for further analysis.

5) Conclusion.
Most of the ills associated with the current application development is the inability of the business stake holder to have proper oversight. Most of the software development environment do not provide any such tools. The important benefits of BPM are

a) SAVING MONEY: By completely automating all the business processes, virtually eliminates the unnecessary overheads in the loan processing and saves millions over the years.
b) LESS HUMAN ERROR: By automation, business processes have less human intervention and thus human error is minimized.
c) INCREASED PRODUCTIVITY: Faster loan processing enables better throughput (loans processed per unit time).
d) SUPERIOR OVERSIGHT: Upper management or business stakeholder gets a birds eye view of the entire loan process. In other words, management knows what is exactly going on rather than being told.
e) MONITORING AND OPTIMIZATION: In-depth monitoring of data at every step of the business process.
f) SUPERIOR ERROR HANDLING: Easy resubmission of process at a failed step.
g) ROI: Investing in BPM implementation gives the best return in the long run.
h) USER FRIENDLY: These models are extremely user friendly and provide a visual representation of the business processes which can easily be understood even by non-technical or uninitiated.
i) Fast Development and Implementation: Very fast and easy development life cycle and process refinement.

__________________________________________________
This document is for reference only. For actual implementation, please contact the author. No part of this document is to be used or reproduced without the written consent from the author (roychettan@gmail.com).

e-Business Standard Implementation in Health care industry

Roy Abraham

The eBusiness standards come in different flavors based on vertical industry, horizontal industry, proprietary, non-proprietary and so on. Most commonly used across the enterprises are EDI, ebXML, RosettaNet, UCCNet, FIX, HL7, SWIFT and HIPAA. These standards have their own proprietary messaging standards and some provides XML equivalent. In this section, we describe briefly how an enterprise built on Java and XML technology can accomplish business to business integration with trading partners who follow these eBusiness standards. For more detailed specification of each standard, refer the specification standard provided by the respective standards organization. Since these standards has been continuously evolving with the advancement of technology, it is very important for the readers to check the latest specification the respective standards.

1)HL7(Health Level 7)
Health Level 7 (HL7) is a specification standard designed to facilitate the data exchange among computer systems in the health care industry. Interoperability among the disparate computer systems such as Electronic Medical Record (EMR) systems, Laboratory Information (LIS) systems, Patient Administration Systems (PAS), Pharmacy Management Systems (PMS) and Electronic Practice Management (EPM) systems. The message model of HL7 has undergone considerable change since the release of version 3.0 and later versions. In the traditional HL7, prior to version 3.0, the message model is ASCII based segmented model. Since version 3.0, Reference Information Model (RIM) became the basis of development process. Version 3.0 supports XML based messaging structure. However, all the versions are backward compatible.

In the segmented Model, each HL7 message is comprised of segments which are delimited by carriage return characters (“\r”). Hence each new line in the HL7 message is a separate segment and each segment has its own semantic meaning. Each segment consists of composites which are delimited by pipes (“|). Each composite consists of fields which are delimited by carets (“^”). Fields within fields (sub-sub fields) are delimited by ampersand (“&”). Repeating fields are separated by tilde (“~”) character. The message structure of segmented model and an example are shown below.

Figure 1: Message structure of HL7

MSH^~ VALSYSVALCLINWIR19990802091524VXU^0400000124P2.3ALPID6678223LK729DOE^JANEDOE^MARY19980413FRXA09991999012319990123^^^90700^DTaP^CPT0.5VALCLIN
Figure 2: HL7 message

The multiplicity constraint for HL7 segment grammar notations are represented using different types of brackets. A segment without bracket means that segment must be present as in segment 1 shown in figure 1. (exactly one). A segment with a square bracket implies an optional segment as in segment 2  (i.e. [] means zero or one occurrence, which, is equivalent to “?” in XML DTD notation). A segment with a curly bracket implies the segment must be present one or more times as in segment 3  (i.e. {} means one or more occurrence, which is equivalent to “+” in XML DTD notation). A segment with both a curly bracket and square bracket implies the segment must be present zero or more times as in segment “n” (i.e. [{}] or {[]} means zero or more occurrence, which is equivalent to “*” in XML DTD notation).

The Reference Information Model is UML (Unified Modeling Language) based pictorial representation of clinical data objects and the state machine (for life cycle) for the messages of each domain. The RIM is an object oriented architecture with a shared model among all the domains in which each domain is responsible for creating the messages. With the advent of XML technology, HL7 specification created Clinical Document Architecture (CDA), which define an XML based architecture for clinical document exchange. The HL7 version 3 supports XML DTD based encoding. The root element of the CDA document release 1.0 is level one. This root element consists of two child containers, clinical document header (header) and body. The header element has four logical child containers: Document information, encounter data, service provider and service targets. The body element of the CDA document contains either one or more section elements or a single non-xml element which refer to an external file that provides the content of the body of the document. Within section element, information content is represented in paragraph, list or table containers. The structure of such a CDA document is shown in figure 3.

Figure 3: The structure of CDA document.

The semantics of the DTD are derived from RIM and domain vocabularies. The CDA document is embedded in a MIME document before sending the HL7 message to the trading partners. The CDA document is base64 encoded in the MIME document. Any clinical images are also bas64 encoded as MIME attachments. For more details about MIME, refer section 2.3. Prior to version 3.0, the CDA document is exchanged in the OBX segment as an encapsulated data type (ED) as shown in figure 4. In version 3, the MIME message is embedded in the Service.txt element within a user defined element.HL7 is a messaging format which can be sent over a transport protocol with de facto standard is TCP/IP point to point exchange. However, other protocols can be used such as FTP, SMTP and HTTP(S). B2B integration between trading partners exchanging HL7 messages using J2EE technology is described below.

Figure 4: HL7 message prior to version 3.0 with embedded CDA message

2) HIPAA (Health Insurance Portability and Accountability Act): The Health Insurance Portability and Accountability Act of 1996 is to improve the portability and continuity of health insurance coverage in the group and individual markets, to simplify the administration of health insurance and to mitigate waste, fraud and abuse in health insurance and health care delivery. The HIPAA also has provisions to address the security and privacy of health care data. The objectives of these standards are to improve the efficiency and effectiveness of the

health care system by the use of EDI. The key EDI based HIPAA transactions envisaged are,
a) 270,271 : Eligibility benefit enquiry request and response,
b) 276,277 : Claim status enquiry request and response,
c) 278 : Health service review request and response,
d) 820 : Sending payment order and remittance advice,
e) 834 : Sending benefit enrollment and maintenance,
f) 835 : Electronic remittance of claim payment,
g) 837 : Health care claims of institutional, professional, and dental types.

The HIPAA implementation incorporates the standalone or the encapsulation of HL7 Clinical Document Architecture (CDA) in the BIN (Binary Data Segment) of the EDI for the above transactions as shown in figure 5. For more information about the HL7 CDA, refer section 1.


Figure 5: Structure of HL7 CDA document embedded in a EDI message.

A typical health care transaction flow involving a provider and payer using HIPAA transactions are shown in figure 6.


Figure 6: Health care transaction flow.

Process Flow:
1) The provider sends a health care claim request to the payer. The claim can be either standalone 837 or attachment of additional information 275 with HL7 CDA embedded in it.
2) Payer sends back a functional acknowledgement 997
3) If the additional information 275 was not sent with the claim as described in 1, or the information 275 was not sufficient, payer may request for additional information 277.
4) The provider responds to the request for additional information by sending the 277 transaction containing HL7 message to the payer.
5) When the payer completes the adjudication process, it sends the health care claim remittance transaction 835 to the provider.

B2B integration architecture between trading partners exchanging HIPAA transactions using EDI messages with J2EE technology is described below.

3) HL7 (Health Level 7) Architecture
A general description of HL7 protocol and usage is described in section 1. This section shows how two trading partners exchange HL7 message between them. The trading partner sends a request HL7 message (inbound) to the enterprise which process the message and creates a HL7 response message (outbound) and sends back to the trading partner. The application layer protocol used is HTTPS. Since the HL7 protocol does not specify the security, it is the responsibility of the trading partners to implement transport level and message level security. The inbound and outbound message flow are shown in 7 and 8 respectively.

Process Flow:
a) The trading partner creates a HL7 message and sends to the enterprise.
b) The request is intercepted at the DMZ of the enterprise. The request is authenticated against a security system (see chapter 18 on security for more details) either using basic authentication or certificate based mutual authentication.
c) If the request is authenticated, HL7 document is sent to the integration server. If not, a HTTP error message is sent back to the trading partner in the same connection. Integration server checks the syntax of the inbound HL7 document and creates an Acknowledgement and sends back to the trading partner. This is to notify the trading partner that the HL7 document is received.

Figure 7: HL7 based B2B integration with J2EE – inbound HL7 message.


Figure 8: HL7 based B2B integration with J2EE – outbound HL7 message.

d) If the message is based on traditional HL7 message, the HL7 message processor maps the inbound HL7 message to a canonical flat file schema (at design time). At run time, the inbound HL7 message is mapped to the XML instance and sent to the down stream application. If the message is based on XML, the HL7 message processor extracts the XML message from the inbound HL7 message (in MIME format) and maps to a canonical XML and sends the XML instance to the downstream applications.
e) Once the downstream application completes the business process, it creates a response XML message and maps to the HL7 response message and sends to the trading partner.

4) HIPAA (Health Insurance Portability and Accountability Act) Architecture
Trading partners such as providers and payers exchanges HIPAA transactions using EDI messages are described in this section. The payer’s enterprise system is assumed to be built on J2EE platform. HIPAA transaction is a message based protocol. The client (in this example, the provider) may use HTTP(S), FTP, EDIINT AS1 or EDIINT AS2 as the transport protocol. The inbound and outbound HIPAA transaction flow is shown in figure 9 and 10 respectively.


Figure 9: HIPAA request transaction with J2EE – inbound EDI message.

Process Flow:
a) The trading partner (for example, the Provider) creates an EDI message with HIPAA request transaction and sends to the enterprise over HTTP (for example, the Payer).
b) The request may be intercepted at the DMZ of the enterprise. The request is authenticated against a security system (see chapter 18 on security for more details) either using basic authentication or certificate based mutual authentication.
c) If the request is authenticated, EDI message is sent to the integration server. If not, a HTTP error message is sent back to the trading partner in the same connection. Integration server checks the syntax of the inbound EDI message and creates an 997 Functional Acknowledgement and sends back to the trading partner. This is to notify the trading partner that the EDI message is received.
d) The EDI message processor maps the inbound EDI message to a canonical flat file schema (at design time). At run time, the inbound EDI message is mapped to the XML instance and sent to the down stream application. If the EDI message contains HL7 CDA documents, the EDI message processor extracts the XML message from the inbound HL7 message and maps to a canonical XML and sends the XML instance to the downstream applications.
e) Once the downstream application completes the business process, it creates a response XML message and maps to the EDI response message and sends to the trading partner (HIPAA response transaction).


Figure 10: HIPAA response transaction with J2EE – outbound EDI message.

__________________________________________________
This document is for reference only. For actual implementation, please contact the author. No part of this document is to be used or reproduced without the written consent from the author (roychettan@gmail.com).