Analysis

This section describes how to undertake the analysis needed to design a Life Event for Universal Access. It is possible to build Life Events for case workers or indeed to use Life Event infrastructure to drive other processes like certification, but these topics are beyond the scope of this chapter. Java coding skills are not a prerequisite for developing all Life Events. Depending on requirements, many and in some cases all of the artifacts required can be developed by an Analyst. This section will help Analysts to determine whether Java developers will be needed to complete the implementation of a Life Event.

Broadly speaking, Life Events for Citizens come in two flavors:

Standard Life Events allow the Citizen to enter new information and then submit it to the agency. For example: Imagine, that Linda logs into Universal Access and submits a "Having a Baby" life event. This is all new information, it doesn't really need relate to anything that has gone before. If it turns out that she has made a mistake in the information she submitted, say the name of the obstetrician, then she simply launches a new Life Event and re-enters all the new information again before submitting.

Round Tripping Life Events are more complex. The distinction between these Life Events and Standard Life Events is determined by whether the data that is pre-populated into the Life Event is allowed to be changed by the user. If the Citizen is expected to update pre-populated information, rather than just adding new information then the Life Event should be considered a Round Tripping Life Event. It is considerably harder to design scripts for this type of Life Event.

The primary artifacts that constitute a Simple Life Event are:

All of these artefacts can be configured using the Administrator's User Interface. For more information on configuring Simple Life Events using the Administrator's UI, please refer to chapter "Configuring Life Events" in the Cúram Universal Access Configuration Guide

The Life Events system can take information entered by the user and do either of two things with that information:

  1. If the user is linked to the local Cúram case processing system, then the Life Events system can update related evidence in any cases they have.
  2. If the user is linked to remote systems then the Life Events system can send updates to related remote systems via web services.

If the Life Event is a Round Tripping Life Event or it is required to update the person's evidence in Cúram then some development work will be needed. This chapter outlines the APIs needed to meet these requirements or indeed to supplement the standard Life Event behavior with additional custom functionality.