3.1.3 Time Valid Details

This category refers to a list of details within a parent entity that is time valid (i.e. each item of the list has a start and an end date). The items of the list have one or more single value attributes (in addition to the start and end dates) and may themselves contain a list of details. For example, a product (parent record) may have multiple provider groups (time valid details). The link between each product and provider group has a start and an end date.

Lists of details may have a 'detail functional key'. A detail functional key refers to a key of list items / detail records that is unique within a list of details at a specific point in time. In effect a history of values is maintained per detail functional key. An example of a list of details with a detail functional key is relation addresses. In this case, address type is the detail functional key and there may only be one address of each type current at any point in time; however, there may be more than one address current at the same point in time if they are of different types. An example of a list of details without a detail functional key is marital status of relations. In this case, there may only be one marital status current at any given point of time. The following sections describe how the various conditions related to time valid details are handled.

3.1.3.1 Parent Record Creation

When the OHI application creates a new record (for an entity with a time valid list of details),

if the list element is not included, no details are added,
if a list element is included, one detail record is created for each item of the list.

3.1.3.2 Parent Record Update

When the OHI application updates an existing record (for an entity with a time valid list of details), one of the following situations applies:

no list element is included
the list element is included without list items and without a resendFromDate
the list element is included without list items, but with a resendFromDate
the list element is included with list items

In the first two situations, no changes to current details are made. In the third and fourth situation, i.e., a list with items or/and a resendFromDate, the OHI application updates the list on the existing record. How that detail list is updated depends on several conditions related to the message contents and what is already stored in the OHI application. This decision table indicates for the various combinations of conditions which updates are made. Each of these scenarios is described separately following the table.

	Conditions			Expected Results
	Start Date Match	Starts During Period	Starts Before Last Period	End Overlap Period	Update Matched Period	Create Period	Delete Later Period(s)
1.	Y	N	Y		X		X
2.	Y	N	N		X
3.	N	Y	Y	X		X	X
4.	N	Y	N	X		X
5.	N	N	Y			X	X
6.	N	N	N			X

Essentially, the detail list in a parent record update replaces the detail list of the existing record, going forward from a specific date. That date can either be explicit in the update request (the attribute 'resendFromDate') or, if not made explicit, it defaults to the earliest start date of the detail list in the update request.

For example, suppose a relation has had a number of addresses starting on from the 1st of Jan 2008. The relation is updated with a list of addresses in which the first address starts on the 1st of Jan 2009. The update does not specify an explicit resendFromDate, so it defaults to the 1st of Jan 2009. The existing address history between Jan 1st 2008 and Dec 31st 2008 remains intact.

The following two diagrams illustrate the scenarios using marital status. Scenario 1 through 6 presume no explicit resendFromDate is specified. Scenario 7 clarifies what happens in the event that the resendFromDate is explicit.

'Create' indicates what has already been created and is present in the OHI application when the 'Update' is received. The result indicates what the situation will be in the OHI application once the update is processed.

3.1.3.2.1 Matching Start Date (Scenarios 1 and 2)

Figure 3-1: Examples of scenario 1

Figure 3-2: Examples of scenario 2

Detail Functional Key

If a new item is received in a message and there is a record present with the same detail functional key and a matching start date, this record will be updated with new values from the message (if any of the values differ). Any record with the same detail functional key that starts after the start date of the new item that has not been resent will be deleted. Note that end date is treated in the same way as other fields.

No Detail Functional Key

If a new item is received in a message and there is a record present with the same start date, this record will be updated with new values from the message (if any of the values differ). All records that start after the start date of the new item that have not been resent will be deleted. Note that end date is treated in the same way as other fields.

Examples

An address (that is already stored in the OHI application) is corrected in the source system by changing it from

Site (S), 122 Jefferson Ave, New York (2005-1-1 - 2008-6-30)

Site (S), 128 Jefferson Ave, New York (2005-1-1 - 2008-6-30)

The external interface needs to send the latest details:

<address
  type="S"
  houseNumber="128"
  startDate="2005-1-1"
  endDate="2008-6-30"
/>

The OHI application will then update its previously stored copy of the address.

An address (that is already stored in the OHI application) is ended in the source system by changing it from

Site (S), 1422-3rd Ave, New York (2008-1-1 - )

Site (S), 1422-3rd Ave, New York (2008-1-1 - 2009-8-31)

The external interface needs to send these details:

<address
  type="S"
  startDate="2008-1-1"
  endDate="2009-8-31"
/>

The OHI application will then update its previously stored copy of the address with the new end date.

Note: In this example, <address type> is the detail functional key.

3.1.3.2.2 Values Updated (starting a new period during an existing period) (Scenario 3 and 4)

Figure 3-3: Examples of scenario 3

Figure 3-4: Examples of scenario 4

Detail Functional Key

If an item is received with a start date that is after the start date of the last record with the same detail functional key and the last record has no end date , the last record will have its end date updated to the day before the start date of the new detail record and a new record will be created with the new details from the message.

Likewise, if an item is received with a start date that is between the start date and end dates of a record with the same detail functional key:

this record will have its end date updated to the day before the start date of the new detail record
any record with the same detail functional key that starts after the start date of the new item that has not been resent will be deleted
the new address will be stored

No Detail Functional Key

If an item is received with a start date that is after the start date of the last record and the last record has no end date , the last record will have its end date updated to the day before the start date of the new detail record and a new record will be created with the new details from the message.

Likewise, if an item is received with a start date that is between the start date and end dates of a record:

this record will have its end date updated to the day before the start date of the new detail record
any record that starts after the start date of the new item that has not been resent will be deleted
the new address will be stored

Example

A new address is recorded in the source system when there is already an address (for the same detail functional key, in this case address type) stored in the OHI application.

Address before adding new address:

Site (S), 1223-9th Ave, New York (2008-7-1 - )

New address with effective date 2009-8-1

Site (S), 544-E 35th Street, New York (2009-8-1 - )

The external interface only needs to send the new address details:

<address
  type="S"
  street="E 35th Street"
  houseNumber="544"
  startDate="2009-8-1"
/>

The OHI application will then update its previously stored copy of the address with an end date and store the new address.

Site (S), 1223-9th Ave, New York (2008-7-1 - 2009-7-31)
Site (S), 544-E 35th Street, New York (2009-8-1 - )

Alternately, the external interface could send both addresses with both changed and unchanged details:

<address
  type="S"
  street="9th Ave"
  houseNumber="1223"
  city="New York"
  startDate="2008-7-1"
  endDate="2009-7-31"
/>
<address
  type="S"
  street="E 35th Street"
  houseNumber="544"
  city="New York"
  startDate="2009-8-1"
/>

This would have the same result in the OHI application.

Example 1

A new (past) address is recorded in the source system when there are already addresses (for the same detail functional key, in this case address type) stored in the OHI application.

Addresses (in both the source system and the OHI application) before adding new address:

Site (S), 122 Washington St, New York (2007-1-1 - 2008-4-30)
Site (S), 185-7th Ave, New York (2008-5-1 - )

Addresses after adding new address:

Site (S), 122 Washington St, New York (2007-1-1 - 2008-1-31)
Site (S), 342 E 46th Street, New York (2008-2-1 - 2008-4-30)
Site (S), 185-7th Ave, New York (2008-5-1 - )

The external interface needs to send the new addresses and all addresses that start after it:

<address
  type="S"
  street="E 46th Street"
  houseNumber="342"
  city="New York"
  startDate="2008-2-1"
  endDate="2008-4-31"
/>
<address
  type="S"
  street="7th Ave"
  houseNumber="185"
  city="New York"
  startDate="2008-5-1"
/>

The OHI application will then update the end date of the address that end after the start date of the new address and replace later addresses with the newly provided addresses resulting in:

Site (S), 122 Washington St, New York (2007-1-1 - 2008-1-31)
Site (S), 342 E 46th Street, New York (2008-2-1 - 2008-4-31)
Site (S), 185-7th Ave, New York (2008-5-1 - )

Alternately, the external interface could also send the address that needed to be updated with the new end date:

<address
  type="S"
  street="Washington St"
  houseNumber="122"
  city="New York"
  startDate="2008-2-1"
  endDate="2008-4-31"
/>
<address
  type="S"
  street="E 46th Street"
  houseNumber="342"
  city="New York"
  startDate="2008-2-1"
  endDate="2008-4-31"
/>
<address
  type="S"
  street="7th Ave"
  houseNumber="185"
  city="New York"
  startDate="2008-5-1"
/>

with the same result in the OHI application.

Example 2

A new maritalStatus is added 'within' the periods of a previous status:

Original maritalStatus list:

Single (2007-1-1 - 2008-4-31)
Married (2008-5-1 - )

List after adding new status

Single  (2007-1-1 - 2007-10-31)
Married (2007-11-1 - 2008-1-31)
Single  (2008-2-1 - 2008-4-30)
Married (2008-5-1 - )

The external interface will need to send all periods starting with the period that has been added:

<maritalStatus
  status="Married"
  startDate="01-11-2007"
  endDate="31-01-2008"
/>
<maritalStatus
  status="Single"
  startDate="01-02-2008"
  endDate="31-04-2008"
/>
<maritalStatus
  status="Married"
  startDate="2008-5-1"
 >

The OHI application will then end the first status and replace the later statuses with the new ones from the message.

3.1.3.2.3 Late Addition of a Detail Item (Scenario 5)

Figure 3-5: Examples of scenario 5

Detail Functional Key

If an item is received with a start date before the start date of the last record with the same detail functional key and it does not start between the start and end dates of another record with the same detail functional key:

any record with the same detail functional key that starts after the start date of the new item that has not been resent will be deleted
the new address will be stored

No Detail Functional Key

If an item is received with a start date before the start date of the last record and it does not start between the start and end dates of another record:

any record that starts after the start date of the new item that has not been resent will be deleted
the new address will be stored

External Interface Design Notes

In effect, what this approach means is that when a time valid detail record is sent, all subsequent detail records (for the same detail functional key if applicable) need to be sent as well.

If a given type of data is a time valid detail list in an Integration Point message definition and a single value attribute (set of attributes) in the source system, the external interface is expected to send the current values in the time valid detail list with a fixed start date (earlier than would ever be referred to) and a null end date.

If a given type of data is a time valid detail list in an Integration Point message definition and a non time valid detail list or otherwise not a one-to-one match in the source system, the external interface is expected to apply (dynamic) logic needed to determine what value should be provided.

3.1.3.2.4 No Overlapping Dates and No Later Periods (Scenario 6)

Figure 3-6: Examples of scenario 6

Detail Functional Key

If a new item is received in a message and for the item:

there are no records present with the same detail functional key,
there are records present with the same detail functional key but the new item starts later then any of these records ends,

a detail record is created for the item.

No Detail Functional Key

If a new item is received in a message and:

there are no current items, or
all current items end before the new item starts,

a detail record is created for the item.

3.1.3.2.5 Explicit Resend Date (Scenario 7)

Figure 3-7: Examples of scenario 7

In scenario 1 through 6, the detail item list is updated going forward from the start date of the first list item in the update request. As a consequence, the updates in these scenarios always entail the creation of a new item on that date going forward. In order to update a detail item list in such a way that a list item is removed without replacement, the list header element must specify a resendFromDate. This has the following effect:

All existing list items that start on or later than the resendFromDate are deleted
All existing list items that start before and end on or later than the resendFromDate are ended one day prior to the resendFromDate
All existing list items that end before the resendFromDate remain untouched
The existing list is updated with the list items in the update request.

In the event that one of the list items in the update request has a start date prior to the specified resendFromDate, the resendFromDate is ignored and the update will be accordance with scenario 1 through 6. In the event that the update request only specifies the list header element with a resendFromDate, the existing list is simply updated in accordance with the bullets above, but no new items are added to that list as a result of the update.

Note that lists with and without detail functional key are handled in the same way, i.e., a specified resendFromDate removes all items from that date going forward.

External Interface Design Notes

When using the resendFromDate all items of a given list for all detail functional keys with a start date on or after the resendFromDate need to be resent. This is different than in the other scenarios where only items of a single detail key need to be resent.

Example 1

Original maritalStatus list:

Single (2007-1-1 through 2008-4-31)
Married (2008-5-1, no end date )

Update request message:

<maritalStatusList
  resendFromDate="2007-07-01>
  <maritalStatus
    status="Married"
    startDate="2007-11-01"
  />
</maritalStatusList>

This update will remove all marital status information going forward from the resendFromDate, i.e., 2007-07-01. This will cause the existing item "Single" to be end dated on 2007-06-30, and will entirely remove the existing item for "Married". A new "Married" item is added to the list. List after the update:

Single  (2007-1-1 - 2007-6-30)
Married (2007-11-1, no end date)

OHI Value-Based Payments
Previous	Home	Next
3.1.2 Non Time Valid Details	Book Index	3.2 Dynamic Free Fields, Codes and Records

Previous	Home	Next
3.1.2 Non Time Valid Details		3.2 Dynamic Free Fields, Codes and Records