Scenarios

This paragraph presents a number of use cases to clarify the interaction between Claims and an enrollment system. The purpose of these use cases is to illustrate the expected response to a given request. The situations that are described reflect the situations in an arbitrary enrollment system. To avoid unnecessary complexity, some simplifications are applied:

The identifiers are assumed to be the same in Claims and the enrollment system.
To improve readability, the relations are identified by a name rather than a code.
Dates are all in the format YYYY-MM-DD

Table 1. External Enrollment System, Policy Products
Serviced Person	Product Code	Enrollment Status	Start Date	End Date
Mrs. Jones	EXTRA	Active	2007-01-01	n/a
Mrs. Jones	BASIC	Active	2007-01-01	n/a
Junior 1	BASIC	Active	2007-01-01	2008-12-31
Jane Mills	BASIC	Active	2008-01-01	n/a
Dale Cooper	BASIC	Active	2008-01-01	n/a

Table 2. External Enrollment System, Policy Families
Serviced Person	Family	Start Date	End Date
Mrs. Jones	FAM01	2007-01-01	n/a
Junior 1	FAM01	2007-01-01	n/a
Jane Mills	FAM45	2008-01-01	2008-05-31
Jane Mills	FAM67	2008-06-01	n/a
Dale Cooper	FAM33	2008-01-01	n/a

Scenario 1

Claim 1234 is processed and the serviced person is Mrs. Jones. Within the claim, the claim line service dates span from 2008-02-25 through 2008-02-28. Mrs.Jones is subscribed to products BASIC and EXTRA. Claims sends out the request and receives the following response:

The enrollment system responds:

<enrollment
>
   <families>
      <family
         code="FAM01"
         startDate="2007-01-01"
      />
   </families>
   <products>
      <product
         code="BASIC"
         contractDate="2007-01-01"
         startDate="2007-01-01"
      />
      <product
         code="EXTRA"
         contractDate="2007-01-01"
         startDate="2007-01-01"
      />
   </products>
</enrollment>

The following information is stored in Claims:

Table 3. Claims, Policy Products
Claim	Serviced Person	Product	Subscription	Start	End
1234	Mrs Jones	BASIC	2007-01-01	2008-02-25	2008-02-28
1234	Mrs Jones	EXTRA	2007-01-01	2008-02-25	2008-02-28

Table 4. Claims, Policy Families
Claim	Serviced Person	Family	Start	End
1234	Mrs Jones	FAM01	2008-02-25	2008-02-28

Note that Claims stores only the policy product and family information for the requested period. So even if the enrollment system responds by sending the full policy product history, Claims stores only the information valid within the request period.

Scenario 2

A claim is processed for serviced person Junior 1. The claim has a single line with service date 2009-02-25. Rather than sending the full policy product history, the enrollment system is set up to respond only with the policy enrollment products valid in the request period. The request time period is set to have a start date of 2009-01-01 and end date of 2009-12-31.

In this particular use case there are no policy enrollment products for the person in the request time period, so Claims expects HTTP Response code 204 (No Content).

Scenario 3

Claim 6555 comes in with serviced person being Jane Mills. The claim line service dates span a period from 2008-05-25 through 2008-07-03. This use case reflects the situation where a person has multiple family codes over time, for example, due to marriage

The response:

<enrollment>
>
   <families>
      <family
         code="FAM45"
         startDate="2008-05-25"
         endDate="2008-05-31"
      />
      <family
         code="FAM67"
         startDate="2008-06-01"
         endDate="2008-07-03"
      />
   </families>
   <products>
      <product
         code="BASIC"
         contractDate="2008-01-01"
         startDate="2008-01-01"
      />
   </products>
</enrollment>

The following information is stored in Claims:

Table 5. Claims, Policy Products
Claim	Serviced Person	Product	Subscription	Start	End
6555	Jane Mills	BASIC	2008-01-01	2008-01-01	n/a

Table 6. Claims, Policy Families
Claim	Serviced Person	Family	Start	End
6555	Jane Mills	FAM45	2008-05-25	2008-05-31
6555	Jane Mills	FAM67	2008-06-01	2008-07-03

Scenario 4

This scenario clarifies how to sent in dynamic field values through the enrollment response. Consider a scenario where the CLA_POLICY_PRODUCTS table has been extended by the dynamic field "studentStatus". The value domain for this field is defined by the flex code definition STUDENT_STATUS. The definition allows the values "NO STUDENT", "IN STATE" and "OUT OF STATE".

Claim 8444 comes in with serviced person Dale Cooper. The claim has five lines, all with service date 2008-04-04. Dale is an OUT OF STATE student.

This scenario can initiate with a POST request to:

https://<context:root>/api/enrollments/search

Request body
<enrollmentRequest endDate="2021-07-29" insurableEntityCode="PC0011_4_1_1_1_RELA_001" insurableEntityType="servicedMember" identifierTypeCode="" startDate="2021-07-29" insuranceTypeCode="HEALTH_INSURANCE" />

The response:

<enrollment>
   <families>
      <family
         code="FAM33"
         startDate="2008-04-04"
      />
   </families>
   <products>
      <product
         code="BASIC"
         contractDate="2008-01-01"
         startDate="2008-01-01"
         studentStatus="OUT OF STATE"
      />
      </product>
   </products>
</enrollment>

Table 7. Information Stored in Claims
Claims, Policy Products						Dynamic Field
Claim	Serviced Person	Product	Subscription	Start	End	Student Status
8444	Dale Cooper	BASIC	2008-01-01	2008-01-01	n/a	OUT OF STATE

Table 8. Claims, Policy Families
Claim	Serviced Person	Family	Start	End
8444	Dale Cooper	FAM33	2008-04-04	2008-04-04