|
The DSFA's Business Object Model identifies six primary object
classes: Customer, Case, Officer, Communication, Scheme and Payment. The
primary object classes in turn make use of several other objects, which
can be considered secondary in role, but which are nonetheless still
capable of being manipulated as objects by the user. In other words, the
secondary objects are usually 'aggregated' into the primary objects.
Objects are defined in terms of a set of responsibilities that they
fulfil. The 'know-what' responsibilities indicate the attributes and
associations with other objects that a user might expect to see and/or
edit when that object is viewed on the screen. The 'know-how-to'
responsibilities summarize the behaviour of the object. These
'know-how-to' responsibilities will typically translate into methods on
the object, though not necessarily one-for-one.
We have listed the know-what and the know-how-to responsibilities for
each of the six primary business object classes below. We are grateful
to the DSFA for allowing this to be reproduced.
The responsibilities of the secondary objects were defined in similar
manner, but are not included here for space reasons. We have also edited
out certain details that are not important to understanding the object
model.
Some of these responsibilities are not slated for implementation
until Phase II of the project, which was going out for tender as this
book went to press.
We have included this model as a good example of how to go about
designing a system in terms of a small set of behaviourally-complete
business objects. There is no implication that this particular model is
suitable for use outside of the DSFA, although there are certainly
patterns within the model that could have broader application.
Customer object
A customer is anyone who has dealings with the State and has been
assigned a Personal Public Service Number (PPSN). The intent of the
Customer object is to provide a single point of access to any and all
customer-related information that might be of value in more than one
context (e.g. for more than one scheme). Where information is clearly
specific to one scheme, such as the recording of a mouth-map for Dental
Benefit, then this information may be held in the scheme itself - but
the guiding principle is to favour the Customer as the repository. The
Customer is also the point through which any action that pertains
directly to the customer (e.g. authenticate and
communicate) is initiated .
The bulk of the data underlying the Customer object, and of some of
the new secondary objects such as Contribution History, is held on the
Department's existing Central Records database (CRS) . However, with
the advent of the REACH
initiative (the framework for E-government in Ireland) the Customer
object should also be seen as the interface to the 'public service broker'
that forms a major facet of REACH. Several of the responsibilities
listed below are being explicitly planned for the public service
broker.
This underlines the importance of specifying the responsibilities
of the Customer object, and hence the interface to other objects,
primarily in terms of 'know-how-to' responsibilities, rather than
'know-what'. Over time, several of these know-how-to responsibilities
will be delegated to the public service broker, or to other systems,
and the intent of the design is to make this transfer invisible to the
rest of the system that is interfacing with the Customer objects. In
the long run, it may be that the only responsibilities of Customer objects
fulfilled within the DSFA's own systems are the knowledge of other
DSFA-specific objects (see below). In the short to medium term, the
Customer object will have to fulfil most of these responsibilities
directly.
Know-what responsibilities
-
Cases in which the customer is cited.
-
Relationships to other Customers, including
'mother of', 'spouse of', 'nominee for', 'legal guardian of'.
-
Communications to and from the customer (that are
not held within a specific Case e.g. advice of change of
address).
-
Payment Methods - methods through which payments
can be made to the customer e.g. bank account, Post Office
details.
-
Addresses for communication.
-
Schemes in which the Customer is cited.
-
Overpayment recovery objects pertaining to the
Customer.
- Whether the Customer is an employee of the DSFA or other civil
servant - in which case the object may only be accessed by a special
unit of officers.
-
Contribution History - summary yearly details of
the Customers social insurance contributions.
-
Means Assessments.
Know-how-to responsibilities
-
Find and Retrieve. This method allows the user to find
an existing customer instance using any variety of search criteria
available. It is implemented by wrapping an OpenVMS based specialised
search facility and making it available through the Customer
Object.
-
Communicate. The Customer object provides the ability to
Communicate with the customer, using any of the specified media and
addresses (currently surface mail, e-mail and telephone). This method
creates a new Communication object which looks after the transmission
and filing of that Communication. Communication can be in Irish if
the Customer desires, so the Customer object knows the preferred
language of the customer.
-
Authenticate. This means the responsibility to
ascertain that the customer you are dealing with (for example by
phone, face to face, on the web, or by mail) is the person who they
say they are. This facility may use direct input from the customer in
the form of a password, PIN, PKI, smart card, digitized written
signature, or biometrics. At some point in the future it could
evolve full facilities for the issue and maintenance of Public
Services Cards. Authentication is likely to be implemented in
conjunction with the REACH initiative.
-
Create a statement. The customer should be able to list all
Payments (including overpayments) made in a specified period.
-
Update. An officer should be able to request, through
the Customer object, that the customer checks their held information
and updates it as appropriate (subject to the rules for verifying
individual fields). This will usually produce an electronic or paper
communication to the customer and may, in future, initiate and
process data from other applications.
-
Register life event. There should be specific methods
for dealing with the major life events such as birth, marriage,
retirement, or death.
-
Respond to life event e.g. notify the Customer of the need
to claim entitlements three months before their 66th birthday.
Scheme object
A Scheme object is responsible for the administration of a
particular benefit or set of Benefits. Scheme is an interface. Each
benefit scheme that the DSFA administers will be represented by a
Scheme object that implements this interface.
There are, broadly, two different forms of Scheme: composite
Schemes and component Schemes. Component Schemes model individual
benefits. Composite Schemes are containers that hold one or more
component Schemes. Thus, an instance of a Component Scheme can only
exist in the context of a Composite Scheme. Individual Schemes will
vary in the kind of support that they provide to the Officer handling
the claim. At the simplest level, the Scheme instance merely provides
a convenient place for recording the facts and decisions taken. At a
more sophisticated level, the Scheme could implement some form of rules
engine and/or a spreadsheet-like calculator. However, the underlying
philosophy of the design is that the system provides a workbench to
leverage the skills, and increase the productivity of the Officer - not
to attempt to automate a process that necessarily involves
judgement.
A composite Scheme will always exist inside a Case, creating a new
one if necessary, in order to be processed by an Officer. However,
once the Scheme is 'In Payment', then the Case will usually not play an
active role. The batch system will interact directly with the Schemes.
Certain Schemes will need the ability to bring themselves up for review
after a certain period, or upon certain events - via the Case
mechanism.
Any Scheme (composite or component) must implement the following
generic responsibilities, plus any additional responsibilities
specific to their own needs:
Know-what responsibilities
- The
Customer who is claiming the benefit and
any other Customers cited in the claim. (Component Schemes do not
need the former since they can get it from the composite Scheme they
can belong to, but they may need the latter e.g. the Customer object
representing the Child or the Qualified Adult.)
- The
Payment Method that the Customer wishes to be
paid by, including nominee payments. (Component Schemes will
default to the Payment Method specified in their parent Composite
Scheme, but this can be over-ridden if, for example, the customer
wishes different components to be paid to different parties or
different accounts. Note that for the Free Schemes, the Payment
Method specifies the Service Provider and knows how to deal with that
Service Provider.)
- Component
Schemes held within this Scheme (if it
is composite).
- Start and End dates.
- Status.
- Any other information specific to this Scheme (or shared by its
component Schemes) that cannot be obtained from the relevant Customer
object.
- The
Case within which the Scheme is currently
held.
- All
Payments made against this Scheme.
-
Certificates for various decisions made by the
officer, including eligibility and review date.
Know-how-to responsibilities
-
Request needed information. In line with the Service
Delivery Model, this capability could generate a personalized form
(paper or electronic) on which the customer could confirm relevant
existing details and supply any missing ones. For some schemes,
this request could be going to other agencies (e.g. a school/college
or doctor). The request would usually generate a standardized
Communication object, filling in the fields as appropriate. Where
the missing information should be held within the Customer object,
then the responsibility to request the needed information is
delegated to the Customer object.
-
Record the eligibility decision. This is equivalent to
ruling the customer's eligibility for the Scheme. It involves creating
a Certificate which represents the legal decision of the
Deciding Officer. The claim cannot proceed until this stage has been
passed. If the claim is disallowed, then the Scheme object continues
to exist, but the Case that contains it may be closed. Deciding the
claim may automatically generate an advice note, using the Customer's
communicate capability.(Note: it will usually be necessary for the Officer to formally
decide the eligibility for the composite Scheme and for each of the
component Schemes that it contains.)
-
Calculate entitlement for any specified period. This
responsibility is carried out by reference to the particular Scheme
being processed. It implies that the Scheme must know the rates and
rules for previous years, not just the current year. It must also
know the payment frequencies which apply to the particular scheme. As
new rates and rules come into force, these will be added to the
Scheme definition. If the new rules and rates follow the same
structure as the previous ones, then this can be thought of as just
adding a row to a table. If they introduce new structures then the
modifications will be more complex. Note, however, that all changes
to scheme rates and rules are contained within the particular Scheme
- they do not spill over into the Customer or Payment objects. The
calculate entitlement responsibility is used as a prelude to
generating a payment for that period, but may also be used just to
advise the Customer of how much they are due.
-
Calculate claim start date. Where there has been a delay
in submitting a claim, some backdating of entitlement is permitted. A
set of rules exists to calculate the backdated start date.
-
Generate new payment for a given period. Depending on
the Payment Method selected, this capability will typically be
invoked by an external batch process running at a range of
frequencies e.g. weekly, fortnightly or monthly. Application of
taxation rules (with reference to the Customer's taxation status) may
be an embedded part of this responsibility.
-
Generate a schedule of payments. This method will be
used when the preferred method of payment is a book (i.e. it is
necessary to generate payment vouchers at regular intervals - say,
every 6 months or every year - or one-off payments such as a
Christmas Bonus. The frequency of voucher generation and the number
of vouchers in a book will vary from scheme to scheme). It may also
be used during transition, for compatibility with existing
systems.
-
Generate difference payment for a given period. This
method will invoke the Generate New Payment, but will then net the
amount against any existing payments for that Scheme for the same
period. This will be used when, for example, the customer's
circumstances change after a schedule of forward payments has been
generated (e.g. new child born during the year). This responsibility
can also produce a negative Payment (i.e. an overpayment to be
recovered). Note: This is only for making corrections to future
payments, and within a single scheme. In general,
overpayment recovery is handled by a dedicated Overpayment Recovery
Scheme.
-
Split payments in accordance with individualization or
other legal requirements. This could be achieved by generating
separate payments based upon a percentage split agreed with the
Customers involved.
-
Correct an overlap. This means generating an Overlap
object that will, effectively, transfer surplus payments made under
this Scheme onto another Scheme.
-
Guide the user. This means permitting the user to look
up the relevant legislation, or more likely staff guidance notes,
relevant to processing the claim. This may be implemented as
context-specific business help.
The following responsibilities apply only to composite
Schemes:
-
Add component Schemes. This includes enforcing rules as
to which such component Schemes can be added
-
Manage interdependencies between component Schemes. A
simple example of this is that the CB Scheme needs to assign an
'eligibility order' to each of the (component) Child Claim objects -
since they cannot calculate this for themselves.
-
Cascade methods on to the component Schemes. The most
common one of these is the regular Generate Payment method.
-
Aggregate Payments generated by component Schemes. Most
of this responsibility is delegated to the Payment objects
themselves. However, the composite Scheme will need to enforce
certain rules about which Payments can and can't be aggregated (e.g.
because they are legally paid on different days of the week).
-
Bring itself up for review based upon certain events or
the passage of time.
Communication object
The Communication object models a single communication, for example
between an Officer and a Customer, or between two Officers.
The role of the Communication object is not just to allow such
communications to be created, but also to allow them to be
filed.
Communications may be incoming or outgoing. In addition, the
Communication Object is used to record remarks.
The transmission mechanism for a Communication is achieved through
the Address object. The same user interface is used regardless of the
transmission channel chosen.
A Remark is a Communication that has no recipient. It is typically
made within a Scheme, Case or Customer object.
Know-what responsibilities
- Recipient's
Address (obtained from the list of
Addresses contained by the recipient object i.e. a Customer, Officer
or any other object that is communicable). The user may choose the
particular address, but it will default to the first entry in the
list.
- Sender's
Address (obtained from the sending
object). This will default to the first entry in the sender's address
list that is the same type as the recipient's address (although all
written communications will list various ways of replying).
- Subject. If the Communication was generated inside a Case, then
that object will be recorded as the subject. This will not only
allow the Communication to be filed in the right place, but will also
potentially allow any reply to be matched up. This
field could also hold other context objects.
- Date
- Status: draft, sent, received, returned, standard letter
(read-only) etc.
- Content. Text will be held in some generalised mark-up language
(e.g. HTML).
-
Certificate (i.e. digital signature) if
required.
- Attachments. In a wide variety of formats (e.g. Word, Acrobat)
that are themselves capable of being transformed into various forms
such as paper and electronic image. Additionally, the content can
include pointers to any expressive objects in the system, though
these will only be of use to recipients who are on the system (i.e.
internal mail). Attachments could also include digitized voice
recordings.
- Language of content. (English or Irish, initially).
Know-how-to responsibilities
-
Transmit. Execution of this responsibility is fulfilled
through the Address object.
-
Edit. Allows text contents to be created and edited.
-
Reply.
-
Forward. This is done by creating a new communication
that has the current one as the Subject.
-
Retrieve (class responsibility). Previous
communications will be retrieved from lists held in the Customer,
Officer or Case objects.
-
Attach a file such as a scanned image to a
Communication.
-
Confirm successful delivery (also fulfilled in
collaboration with Address).
-
Sign. Create a Certificate digital signature of the
sender. This responsibility may append a digitised
image of a physical signature, if desired.
-
Copy. This copies a whole Communication.
-
Lock. This turns a Communication into a standard read-only
communication that can be copied.
-
Append. Used to create a letter from standard
paragraphs.
Officer object
The Officer object is the single point of contact for information
and functionality associated with an individual (an employee of the
Department or an associate) who may use the information system. There
is one instance for each such individual.
Users of the system have their own Officer object readily
accessible, as this is the means for logging on and off, and for
storing their personal desktop view. In addition the Officer
object provides access to their current workload.
An Officer object may be 'virtual', that is, it may represent
roles and/or departmental sections (e.g. the Claims Registration
Section).
Know-what responsibilities
- Relationships to other
Officers. This includes
supervisors, supervised, and peers.
-
Cases. This means cases that are currently
assigned to the officer.
-
Communications to or from the Officer.
-
Addresses for communication.
- Roles fulfilled.
Know-how-to responsibilities
-
Find and Retrieve. These responsibilities are broadly
similar to those specified for Customer.
-
Log-on and off.
-
Capture and recall the user's desktop.
-
Present caseload. This responsibility can show all
cases currently assigned to the Officer broken down by various
categories including current status.
-
Manage in and out boxes.
-
Manage authorization levels. Authorization (to perform
a specific method on a specific object) will be done by a system-wide
authentication and authorization server. However, the Officer object
will be a principal user interface onto this server (i.e. the means
through which the authorization levels for specific roles and/or
individuals are specified).
-
Communicate. This works in the same way as the
Communicate responsibility of the Customer object.
-
Create a Certificate to record the basis of the
Officer's decision.
Payment object
A Payment object represents a single payment from a payer (by
default, the Department) to the payee (usually a Customer). A Payment
is in many ways analogous to a Communication and shares some of its
structure. Thus, the role of the Address in a Communication is
replaced by a Payment Method, where that may represent a cheque,
electronic funds transfer, electronic information transfer or a voucher
(the latter usually forming part of a payment book).
The amount of the payment will have been determined by whatever
created the Payment object (e.g. a Scheme, or, in rare cases, an authorised Officer),
along with the date due. Payment can
represent negative amounts for the purposes of recovering an
overpayment
Payments are generally created at the lowest level possible to
enable them to be posted accurately into the financial accounting
system. Thus, a claim may give rise to the creation of several Payment
objects representing different component Schemes such as Retirement
Pension, Contributory Pension, Qualified Adult Allowance or Child
Dependent Allowance. Payments that have been created but not yet
executed and which have the same payee and date may be combined or
merged with other Payments within the same payment period to form a
single net transfer.
Know-what responsibilities
-
Scheme that caused the Payment to be
created.
- Payee's
Payment Method. The descriptive label of
the Payment Method includes the name of the Payee, and can provide
direct access to the object representing the payee (e.g. a Customer
or Agency).
- Payment identification. For example, cheque number or
voucher number.
- Component
Payments. This means that any
composite payment knows what other payments it has been made up from.
- Amount (expressed in a currency).
- Status (issued, paid, stopped, reconciled).
- Stop Reason, if status indicates that the payment has been
stopped.
- Payment Type. This indicates if the payment is a regular payment,
a replacement payment, grant payment etc. This is a free-form field
whose contents are typically determined by the Scheme that
creates the Payment.
- Payment period that it relates to.
- Date due. (It may be that this is a function of the payment
period e.g. first Tuesday in the period).
Know-how-to responsibilities
-
Merge with another payment (subject to rules). Typically,
Payment instances are created at the level of Scheme elements (e.g.
child dependent, fuel allowance) and then merged to form a single
payment which is transferred to the Customer.
-
Post into the financial accounting systems.
-
Authorize. Most payments will be generated within
Schemes, which will look after their own levels of authorization.
However, it may be appropriate to put some additional generic
concepts of authorization into the Payment object itself (e.g. for
payments over 5,000 Euros).
-
Stop the individual payment or the entire book of payment
vouchers.
-
Issue in the manner appropriate to the Payment
Method.
-
Deduct tax, if appropriate, by reference to the taxable
status of the payee and/or the reason for payment. (This can be
thought of as splitting the payment between the payee and the
taxation authority).
-
Advise. Generate an advice or payment to the payee, by
generating an appropriate Communication object or by generating an
advice note for inclusion in the PPO Book.
Case object
The Case Object is currently used to hold Scheme instances and is
the mechanism whereby a Scheme instance can be linked to an Officer.
Case can act as a holder for any supporting communications (including
Remarks) and could in future hold scanned images of other documents
associated with Schemes being processed, but which may not be
explicitly held within the Scheme. However, the work contained in a
Case does not have to be related to a Scheme. Instead it can be any
type of Departmental work from correspondence to investigations.
Case provides certain workflow-like characteristics, including the
ability to forward the case on to another officer.
Know-what responsibilities
- The
Officer currently responsible for the
case.
- The
Officer to whom the Case was previously
assigned (if any).
-
Schemes that form part of the case (which in turn
know the Customers).
-
Communications relating to the case.
- Other relevant documents (including, potentially, scanned images)
and notes.
- Current status. For example: Pending - customer;
Pending - other; In payment; Closed.
- Review Date - the date when the case is to be brought to attention
for review. This date will usually be determined by the
Officer.
Know-how-to responsibilities
-
Refer to another Officer. This referral may be
temporary (e.g. for authorization to proceed) or a permanent handoff.
The nature of the referral will make that clear. The referral may be
initiated merely by dragging the Case object onto the appropriate
Officer object. As well as changing the Officer assigned, the
referral will generate a standardized Communication to appear in the
in-tray of the recipient.
-
Alert. Publish and subscribe is a generic capability of
the Expressive Object Architecture. Case is expected to be a
significant user of this capability - using a specified event on an
object within a Case that may change the status of the case
itself.
-
Maintain history. All objects maintain a full history
of both accesses and changes for audit purposes. However, for the
Case object, the history of changes needs to be maintained in a form
that is easily accessible by an officer - for example whilst dealing with a
customer on the phone.
|