Health Care Inbound Message

On calling the C1-HCInboundMessage web service, you can create a health care inbound message using a health care inbound message type. You can create a health care inbound message type using the Health Care Inbound Message Type (C1-HCInboundMsgType) business object. The health care inbound message type helps the system to determine:

  • Inbound Message Business Object - The business object using which the health care inbound message should be created in the system. You must specify the Health Care Inbound Message (C1-HCInboundMessage) business object in the health care inbound message type.

  • Customer Registration Type - The health care inbound message creates the person, account, policy, and policy plan through a customer registration object. The system creates the customer registration object using the customer registration type specified in the health care inbound message type. The customer registration type helps the system to determine:

    • Customer Registration Business Object - The business object using which the customer registration object should be created in the system. You must specify the Customer Registration - Health Care (C1-CustomerRegistrationHC) business object in the customer registration type.

    • Person Business Object - The business object using which the person should be created in the system. You must specify the Person BO (C1_​PERSON_​BO) business object in the customer registration type.

    • Account Business Object - The business object using which the account should be created in the system. You must specify the Account BO (C1-AccountBO) business object in the customer registration type.

    • Policy Plan Business Object - The business object using which the policy plan should be created in the system. You must specify the Policy Plan (C1-PolicyPlan) business object in the customer registration type.

    • Membership Business Object - The business object using which the membership should be created in the system. You must specify the Membership (C1-Membership) business object in the customer registration type.

    • Address Business Object - The business object using which the effective dated address should be created in the system. You must specify the Address (C1-Address) business object in the customer registration type.

    While creating a health care inbound message type for the fully-insured group health insurance business, you must use a customer registration type where the Approval Required, Final Approval Required, and Manual Billing Hierarchy and Pricing options are not selected. However, while creating a health care inbound message type for the self-funded health insurance business, you must use a customer registration type where the Final Approval Required and Manual Billing Hierarchy and Pricing options are selected, but the Approval Required option is not selected.

The following table lists the various activities that you can perform for the respective combination through the C1-HCInboundMessage web service:
Person Type Policy Category Enables you to:
Parent Customer Self-Funded

  • Create or edit a parent customer

  • Create or edit a bill group of the parent customer

  • Create the derivation and pricing parameters for the bill group

  • Create or edit the accounts of a bill group

  • Create or edit the policies of a bill group
Fully-Insured Group

  • Create or edit a parent customer

  • Create or edit a bill group of the parent customer

  • Create the derivation and pricing parameters for the bill group

  • Create or edit the accounts of the parent customer and bill group

  • Create or edit the policies of the parent customer and bill group

  • Create or edit the plans of the policies

  • Associate one or more pricing rule types with a policy plan

  • Create or edit the pricing rules of the policy plans

  • Terminate, reinstate, or renew policies of the parent customer and bill group
Bill Group Self-Funded

  • Create or edit a bill group

  • Create the derivation and pricing parameters for the bill group

  • Create or edit the accounts of the bill group

  • Create or edit the policies of the bill group
Fully-Insured Group

  • Create or edit a bill group

  • Create the derivation and pricing parameters for the bill group

  • Create or edit the accounts of the bill group

  • Create or edit the policies of the bill group

  • Create or edit the plans of the policies

  • Associate one or more pricing rule types with a policy plan

  • Create or edit the pricing rules of the policy plans

  • Terminate, reinstate, or renew policies of the bill group
Any Other Person Type -

  • Create or edit a person

  • Credit or edit the accounts of the person

  • Create or edit the memberships of the policy plans

  • Add or remove members from a membership

  • Create or edit the one-time or recurring pass-through billable charges for a membership

  • Create or edit the benefits charges for a membership

The following table describes how the system behaves when the respective entity information is given in a health care inbound message:

Entity System Behavior
Person The system uses the C1-PERSTYPE feature configuration to decide whether the person type specified in the health care inbound message represents Parent Customer or Bill Group. If the person type specified in the health care inbound message matches the person type specified in the Bill Group Person Type or Parent Person Type option type of the C1-PERSTYPE feature configuration, the system creates or updates the person, account, policy, policy plan, and address through a customer registration object. Note that the memberships, pass-through billable charges, and pricing rules are created directly and not via customer registration object. However, if the person type specified in the health care inbound message does not match the person type specified in the Bill Group Person Type or Parent Person Type option type, the system creates or updates the person and its other entities directly and not through a customer registration object. In this case, the system only refers the customer registration type for the business objects using which the person, account, policy plan, membership, and address should be created or updated in the system.

If the related person information is given for a bill group and the person type of the related person is Parent Customer, then the bill group is related to the parent customer using the person relationship type which is specified in the Person Relationship Type option type of the C1-ASOBLLNG feature configuration.

If the derivation and pricing parameters are specified for a bill group, the system automatically creates one sort record for the bill group. Here, the sort ID is set to the bill group ID. The start and end dates of the sort record are set to the bill group and parent customer's relationship start and end dates. Once the sort record is created, the system creates the derivation and pricing parameters for the bill group and sort ID combination.

Note: The system supports the Add and Update operations for all entities except the derivation and pricing parameters for the bill group. Through the health care inbound message, each time, the system creates a new derivation and pricing parameters record for the bill group and does not update the existing derivation and pricing parameters record of the bill group.
Account While creating an account, the system defines the Invoice Type characteristic for the account. It stores the account type given in the account information in the characteristic type which is specified in the Invoice Type Characteristic Type option type of the C1-ASOBLLNG feature configuration.
Policy If the fully-insured group policy information is given for a bill group, the system does the following:

  • Associates the bill group with the policy using the policy person role which is specified in the Bill Group Policy Person Role option type of the C1-ASOBLLNG feature configuration

  • Associates the parent customer with the policy using the policy person role which is specified in the Parent Customer Policy Person Role option type of the C1-ASOBLLNG feature configuration

However, if the fully-insured group policy information is given for a parent customer, the system does the following:

  • Associates the parent customer with the policy using the policy person role which is specified in the Parent Customer Policy Person Role option type of the C1-ASOBLLNG feature configuration

If the self-funded policy information is given for a bill group, the system does the following:

  • Associates the bill group with the policy using the policy person role which is specified in the Bill Group Policy Person Role option type of the C1-ASOBLLNG feature configuration

  • Associates the parent customer with the policy using the policy person role which is specified in the Parent Customer Policy Person Role option type of the C1-ASOBLLNG feature configuration

On renewing a fully-insured group policy, the system removes the end date from the policy and stamps the renewal date against the policy.

Note: You can renew a policy where the policy category is set to Self-Funded from the user interface and not through a health care inbound message. However, you can renew a policy where the policy category is set to Fully-Insured Group through a health care inbound message and not from the user interface.

On terminating a fully-insured group policy, the system updates the end date of the following entities with the termination date:

  • Policy

  • Policy Person

  • Policy Plan

  • Membership

  • Membership Person

  • Pricing Rule

However, before updating the end dates, the system stores the original end date in the ORG_​END_​DT column of the respective table for all the above entities. The status of the policy is changed to the status which is specified in the Policy Termination Status option type of the C1-ASOBLLNG feature configuration.

On reinstating a fully-insured group policy, the system updates the end date of the above entities with the original end date. In addition, the status of the policy is changed to the status which is specified in the Policy Reinstatement Status option type of the C1-ASOBLLNG feature configuration.

Note: The Policy entity is applicable only for Self-Funded Group Health Insurance and Fully-Insured Group Health Insurance businesses.
Policy Plan While creating a policy plan, the system requires either the price item or at least one pricing rule type. The system allows you to associate only those pricing rule types where the category is set to Age Based, Tier Based, or Pass-Through Billable Charge.
Note: The Policy Plan entity is applicable only for Self-Funded Group Health Insurance and Fully-Insured Group Health Insurance businesses.
Pricing Rule Type The system does not allow you to create or update a pricing rule type through a health care inbound message.
Note: The Pricing Rule Type entity is applicable for Self-Funded Group Health Insurance, Fully-Insured Group Health Insurance and Individual Health Insurance businesses.
Pricing Rule The system allows you to define and edit the age-based and tier-based pricing rules of the policy plan. Note that the system supports the Replace operation and not the Update operation when you are editing these pricing rules through a health care inbound message.
Note:

You can define and edit the age-based and tier-based pricing rules through a health care inbound message and not from the user interface.

You can create the following pricing rules from the user interface and not through a health care inbound message:

  • Claim

  • Specific Stop-Loss

  • Aggregate Stop-Loss

  • Retention Type Claim Based

  • Retention Type Enrollment Based

  • One-Time Flat Fees

  • Recurring Flat Fees

  • Ancillary

  • Discount Arrangement

  • Level Funded

Note: The Pricing Rule entity is applicable for Self-Funded Group Health Insurance, Fully-Insured Group Health Insurance, and Individual Health Insurance businesses.
Pass-Through Billable Charge If the price item, account identifier type, and account identifier are given in the billable charge information, the system directly creates an SQI based billable charge when you process the health care inbound message. But, if only the price item is given in the billable charge information, the system checks whether the price item is included in any pricing rule type where the pricing rule type category is set to Pass-Through Billable Charge. If so, the system checks whether the pass-through billable charge pricing rule type is associated with the policy plan to which the membership belongs (for which the billable charge information is received). If so, the system creates an SQI based billable charge using the respective pass-through billable charge pricing rule type.
Note: The Pass-Through Billable Charge entity is applicable only for Fully-Insured Group Health Insurance and Individual Health Insurance business.
The following table recommends the sequence in which the respective entities should be created for the different line of business through a separate healthcare inbound message.
Line of Business Sequence Entity
Fully-Insured Group Health Insurance 1 Parent Customer (along with policy details)
2 Bill Groups (along with policy details)
3 Pricing Rules
4 Member Persons (along with policy details)
Individual Health Insurance 1 Member Person (along with health product, health plan, and pricing rule details)
Self-Funded Group Health Insurance 1 Parent Customer (along with policy details)
2 Bill Groups (along with policy details)
3 Pricing Rules
4 Member Persons (along with policy details)
The following table lists the details which you need to provide either in full or partial while editing the entity information through a health care inbound message.
Entity Information Tag Name In case of edit, you need to provide details in...
Person Person Name <personName> All the tags within the <personName> tag
Identifiers <identifiers> All the tags within the <identifiers> tag
Address <address> The following tags within the <address> tag:

  • <addressEffDate>

  • <addressType>
Phones <phones> All the tags within the <phones> tag
Related Persons <relatedPersons> All the tags within the <relatedPersons> tag
Characteristics <characteristics> The following tags within the <characteristics> tag:

  • <characteristicType>

  • <effectiveDate>
Bill Level Parameters <billLevelParameters> The following tag within the <billLevelParameters> tag:

  • <sequence>
Account Identifiers <identifiers> All the tags within the <identifiers> tag
Account Person <accountPerson> All the tags within the <accountPerson> tag
Account Autopay <autoPayDetails> All the tags within the <autoPayDetails> tag
Characteristics <characteristics> The following tags within the <characteristics> tag:

  • <characteristicType

  • <effectiveDate>
Policy Policy Person <policyPersons> All the tags within the <policyPersons> tag
Characteristics <characteristics> The following tags within the <characteristics> tag:

  • <characteristicType

  • <effectiveDate>
Plan <pricingRuleTypeList> All the tags with the <pricingRuleTypeList> tag.
Characteristics <characteristics> The following tags within the <characteristics> tag:

  • <characteristicType>

  • <effectiveDate>
Pricing Rule <pricingRuleData> All the tags within the <pricingRuleData> tag.
Membership Membership Person <memberData> The following tags within the <memberData> tag::

  • <sequence>

  • <membershipIdentifierType>

  • <policyNumber>

  • <sourceSystem>

  • <planNumber>

  • <healthPlanCode>
Characteristics <characteristics> The following tags within the <characteristics> tag:

  • <characteristicType>

  • <effectiveDate>
Membership Person Characteristics <membershipPersonCharacteristic> The following tags within the <membershipPersonCharacteristic> tag:

  • <characteristicType>

  • <effectiveDate>
The following table lists the details which you need to provide while carrying out a specific action for an entity through a health care inbound message.
Entity Action You need to provide the details in the following tags...
Fully-Insured Group Policy Policy Renewal 
<policyData>
  <policyType></policyType>
  <policyNumber></policyNumber>
  <sourceSystem></sourceSystem>
  <renewalDate></renewalDate>
  <endDate></endDate>
</policyData>
Policy Reinstatement 
<policyData>
  <policyNumber></policyNumber>
  <sourceSystem></sourceSystem>
  <reinstateInformation>
    <reinstatementDate></reinstatementDate>
    <reinstateReason></reinstateReason>
  </reinstateInformation>
</policyData>
Policy Termination 
<policyData>
  <policyNumber></policyNumber>
  <sourceSystem></sourceSystem>
  <terminationInformation>
    <terminateDate></terminateDate>
    <terminationReason></terminationReason>
  </terminationInformation>
<policyData>
Individual Membership Manual Renewal (only renews the membership) 
<memberData>
  <sequence></sequence>
  <startDate></startDate>
  <endDate></endDate>
  <autoRenew></autoRenew>
  <membershipRenewalDate></membershipRenewalDate>
  <membershipPersonStatus></membershipPersonStatus>
  <membershipPersonstatusReason></membershipPersonstatusReason>
</memberData>
Manual Renewal (of a dependent person) 
<memberData>
  <sequence></sequence>
  <endDate></endDate>
  <membershipPersonStatus></membershipPersonStatus>
  <membershipPersonstatusReason></membershipPersonstatusReason>
</memberData>
Termination 
<memberData>
  <sequence></sequence>
  <endDate></endDate>
  <membershipPersonStatus></membershipPersonStatus>
  <membershipPersonstatusReason></membershipPersonstatusReason>
</memberData>

On calling the C1-HCInboundMessage web service, a health care inbound message is created in the Pending status. When the Health Care Inbound Message Periodic Monitor (C1-HCINB) batch is executed, the system checks whether there are any health care inbound messages in the Pending status. If there is a health care inbound message in the Pending status, the system validates the inbound message. If the health care inbound message is successfully validated, it is processed further and the entities are either created or updated in the system based on the available information.

Alternatively, the system enables you to submit the health care inbound messages for validation and processing from the user interface. On submitting a health care inbound message, the system validates the health care inbound message. If a health care inbound message is successfully validated, it is processed further and the required entities are created or updated in the system based on the available information.

If the person type is Parent Customer, the customer registration object is created in the Complete status. However, if the person type is Bill Group, the customer registration object is created in the Bill Group Approved status. The policies are created in the In Force/Active status and the pricing rules are created in the Active status. Finally, the status of the health care inbound message is changed to Processed.

Note: The above status transition is mentioned for a customer registration object based on the assumption that the data sent through the health care inbound message will be pre-approved and does not require any approval in the system.

If any error occurs while validating or processing a health care inbound message, the status of the health care inbound message is changed to Rejected. The system enables you to either reprocess or void a rejected health care inbound message. The system can reprocess a health care inbound message when its status is changed to Pending. Using the Retry option, you can change the status of the health care inbound message from Rejected to Pending. The Health Care Inbound Message Periodic Monitor (C1-HCINB) batch will then reconsider and reprocess the health care inbound message.

You can also configure the system such that the batch can automatically retry to process the rejected health care inbound messages. However, it will attempt to retry when the Maximum Retry parameter in the Retry for To Dos (C1-TODORETRY) algorithm is set to a value greater than zero. Also, the maximum number of times the batch can attempt to retry and reprocess a health care inbound message depends on the value defined in the Maximum Retry parameter.

At present, if a customer registration object is created through a health care inbound message, you cannot edit the customer registration object from the user interface. You can only edit such customer registration objects through a health care inbound message.

Related Topics

For more information on... See...
How to setup the C1-ASOBLLNG feature configuration Setting the C1-ASOBLLNG Feature Configuration
How to setup the C1-PERSTYPE feature configuration Setting the C1_​PERSTYPE Feature Configuration

Parent Topic: Inbound Message