Writing Life Event IEG Scripts

Writing a Life Event IEG script is much like writing any other IEG script for more information on writing IEG2 Scripts in general please refer to the Developer Guide Authoring Scripts In IEG2. However there are some special considerations for Life Event scripts. In the main these depend on whether the Life Event is a Round Tripping Life Event or a Standard Life Event. Recall that in a Round Tripping Life Event, Citizen Data is read into the Data Store used by the IEG script and then this data can be modified by the Citizen as they go from page to page in the Life Event script. Take for example a piece of Income data that is read into the Life Event script. The Citizen modifies this Income information and then submits. The Life Event Broker must ensure that when the Citizen changes the Income data, that this change is detected and that the changes are correctly propagated back to the Income entity from which the data was originally read. The Life Event Broker needs a way to "track" data from its origin in the Income entity, through the Life Event Script and back to the same Income entity. In order to facilitate this the IEG script designer must place a "marker" into the data store schema. Here is an example of the definition of an Income Data Store:

  1 <xsd:element name="Income">
         <xsd:complexType>
            <xsd:attribute name="incomeType" type="INCOME_TYPE"
               default=""/>
  5        <xsd:attribute name="cgissIncomeType"
                type="CGISS_INCOME_TYPE"/>
           <xsd:attribute name="incomeFrequency"
                type="INCOME_FREQUENCY" default=""/>
          <xsd:attribute name="incomeAmount" type="IEG_MONEY"
 10            default="0"/>
           <xsd:attribute name="localID" type="IEG_STRING"/>
         <xsd:complexType>
      </xsd:element>

The attribute localID is used by the Cúram Life Event Broker to track the unique identity of the entity from which the Income Data was drawn. When this entity is changed by the user and submitted, the Life Event Broker can use the value of localID to locate the correct entity to update as a result of the changes in the Life Event. There are some other special markers that can be placed in the schema to aid with providing automatic updates to Cúram evidence entities. These will be discussed in subsequent sections.

When designing a script for a Round Tripping Life Event the designer should bear in mind the effects that pre-population of data can have on the flow of the script. One particular example of this is conditional clusters. Life Event Scripts should avoid conditional clusters that are associated with pre-populated data. These are common in Intake scripts but don't work well when the data store has been pre-populated. Take for example a Life Event around losing a job, a boolean flag on the Person entity, hasJob is used to indicate that person has a job. The IEG script presents the user with a question: "Does anyone in your household have a job?". This is used to drive the display of a conditional cluster that identifies which household members who have jobs. If the data in the data store is pre-populated however, there's a good chance that one or more there will be one or more Person entities with hasJob already be set to "true". In the current implementation of IEG2 however it is not possible to get the "Does anyone in your household have a job?" Control Question to default to true even when hasJob is true for one or more household members. For this reason the general rule should be to avoid control questions for conditional clusters like this when the fields they control are pre-populated.