3.2.3 Dynamic Records Values

Many of the entities that can be sent in through an integration point can be extended with dynamic fields and / or dynamic records. The values for these records and fields can be set through the integration points as well. Dynamic record values are set by using the <dynamicRecordTables> element. The following pseudo XML snippets illustrate the structure of this element.

<dynamicRecordTables>
  <dynamicRecordTable
    name
  >
    <row
      startDate
      endDate
      indDeleted
 >
      <column
        name
        flexCodeDefinitionCode
      />
        value
      </column> 

The name in the <dynamicRecordTable> element maps on to the dynamic record usage name. Each <row> represents a dynamic record value. The startDate and endDate are used in case the dynamic record usage is set up to be time valid.

The indicator indDeleted of a row can be used to delete specific dynamic records. This is only possible for dynamic record definitions where a particular column is set up to be 'key'. The dynamic record to delete is then determined by matching the key column value in the request to the key column values present in the database; any dynamic record with the same key value (and the same parent data element) will be deleted. If the dynamic record definition does not specify a key column, indDeleted cannot be used (if sent in anyway it will be disregarded).

Each <column> element sets a value in a single dynamic record. The name attribute maps on to the dynamic record field usage code. The field usage can refer to either a field (such as a date or a number) or a code definition (such as a diagnosis or a procedure). If it refers to a code definition, the <column> value maps on to the key field of the code definition. The schema definition does not allow <column> elements without a value; if a column within a record should remain blank, no <column> element for that column should be included.

All integration points that accept dynamic record tables include a de-duplication feature. For each <row> element, the application checks to see if an identical <row> exists in the message; if it does, then the duplicate is removed. If the dynamic record definition specifies a key field, then de-duplication is based on the key field value alone. For time valid dynamic records, de-duplication is based on the combination of the key field and the start date. If no key field is specified, a <row> is considered a duplicate when all field values in the record are the same as in another record.  

The following table describes the update behavior of dynamic records through integration points. The assumption is that one or more dynamic record values are already present in the database when the request is processed. The behavior differs based on whether the dynamic record usage allows for multiple values, time valid records and/or has a functional key field.

Specifying a <dynamicRecordTable> element without any <row> element will clear all dynamic records for that particular usage. In case the request does include (a) <row> element(s) then the following logic applies:

Multi	Time	Key	Update behavior
N	N	N	Replace the existing record with the new
N	N	Y	Replace the existing record with the new
Y	N	N	Replace all existing records with the new record(s)
Y	N	Y	Existing records with a key value that matches the key of a record in the request are replaced. Existing records with a key value that is not in the request remain untouched.
N	Y	N	Existing records with the same or later start date are removed The existing overlapping record with an earlier start date is cut off All other existing records remain untouched
N	Y	Y	Existing records with the same or later start date are removed The existing overlapping record with an earlier start date is cut off All other existing records remain untouched
Y	Y	N	The earliest start date of the records in the request message is considered to be the as-of-date from which point onwards only the records included in the request message are valid. Existing records that overlap in time are ended or deleted automatically: Existing records that start before and end on or later than the as-of-date, are ended one day prior to the as-of-date. Existing records that start on or later than the as-of-date are deleted. All other existing records remain untouched
Y	Y	Y	Existing records with the same key value and with the same or later start date are removed The existing overlapping record with the same key value and with an earlier start date is cut off All other existing records remain untouched