To integrate or not integrate…that is the question

How much system integration is the right amount for health insurance administrators? Is it best to aggregate or disaggregate some of the core components such as premium billing, enrollment/member demographics, claims processing, care/disease management, provider demographics, benefit/contract design and configuration, and provider reimbursement?

This is the first in a series of blogs focused on the integration of systems, data, and partners in the delivery and administration of health care and health insurance.

Healthcare payers have long struggled with which items to consolidate to a single platform and application module. Let’s consider claims processing:

  • How many adjudication engines are needed to administer professional, facility, pharmacy, and dental claims?
  • Should all the various data elements and historical information for each be combined together for a single member?
  • Is it best to put all your eggs in a single basket for administration, or might performance be enhanced, and flexibility of benefit structures for these various product lines be increased by porting the adjudication aspects across more than one processing system?
  • Would administration of the claims sent to the CMS Edge Server be better supported if a dedicated processing and reporting structure were available?

Trying to support so many claim types for both manual and electronic submission and processing is a valid argument for dividing the applications to their own environments.

There may be merit in separating the rules and criteria for manual versus electronic submission to their own platforms. Required claims history and accumulators can be supported and provided by an appropriate backend database which is tuned to address the needed adjudication elements. Separate warehouse or data marts can support the required operational and ad hoc reporting that is needed. The backend databases will also scrub and build the inbound and outbound ANSI ASC X12N and NCPDP formats and associated code sets.

The lines of business may drive the decision regarding how much and how many core components have to be consolidated to a single adjudication model. For example, a TPA with a more limited customer base and scope of work may have differing factors to consider than a large national payer that must provide for Federal as well as commercial and individual lines of business.

Another consideration is the old world versus new world underwriting guidelines and policies that exist. In the past, the out-of-pocket onies / stoploss / accumulations / limitations were complicated to administer and explain. These structures weighed in to the design and configuration of benefits against which claims were adjudicated. In the new world, many items have been revisited due to health care reform which removes or forces a restructuring of these items in to a more simple and straightforward compliance model.

So why do I need to tie all aspects of health insurance in to a single delivery model? Please share your thoughts and comments with me on this topic.

My next blog entry, “Data, data, who has the data?” will focus on ‘with whom should health insurance administrators consider integrating/exchanging data?’

Margaret Shilling

Senior Manager – Business Consulting, Virtusa. Margaret is a seasoned and experienced Information Services Leader with over 32 years of experience in medical health insurance, business process improvement, and project management. At Virtusa, she is part of the business consulting group, manages HIT integration, health insurance, and healthcare business intelligence projects. Prior to Virtusa, Margaret has worked with leading health organizations such as TriZetto Group, Group Health Cooperative, The Regence Group, etc. She has completed various undergraduate courses in Tacoma Community College.

More Posts