REQUEST FOR PROPOSAL
CIVIL REGISTRATION
FUNCTIONAL REQUIREMENTS
FOR
DATABASE DESIGN AND DEVELOPMENT
Table of Contents
Table of Contents ...............................................................................................................................1
Introduction ......................................................................................................................................3
Current Situation ...............................................................................................................................3
Request for Proposal (RFP) .................................................................................................................4
Proposal Guidelines and Requirements ..............................................................................................4
Standard Proposal Format ..................................................................................................................6
Important Dates ................................................................................................................................6
General Functional Requirements ......................................................................................................8
1.
Authentication and Authorisation .................................................................................................... 8
2.
Database Management Tools ........................................................................................................... 8
3.
Automatic Alert Trigger..................................................................................................................... 8
4.
Interface ............................................................................................................................................ 9
5.
Database Security ............................................................................................................................. 9
6.
Audit Trail and Log ............................................................................................................................ 9
7.
Certificates Production and Printing ............................................................................................... 10
8.
Reports Generation......................................................................................................................... 10
9.
Correspondence Generation........................................................................................................... 11
10.
Data Validation............................................................................................................................ 11
11.
Data Input Format Correction ..................................................................................................... 11
12.
Search and Retrieve .................................................................................................................... 12
13.
Modification of Key Life Events Records..................................................................................... 12
14.
Deletion of Invalid Records ......................................................................................................... 13
Keystrokes Reduction and Data Entry .................................................................................................... 13
15.
Future Technological Integration ................................................................................................ 13
16.
Historical Birth Record Migration (HBRM) .................................................................................. 14
Birth Registration Module ................................................................................................................ 15
On Time Birth Registration ..................................................................................................................... 15
a.
Parental Search and Link ............................................................................................................. 15
b.
Incomplete Registrations ............................................................................................................ 16
c.
Automatic Calculation ................................................................................................................. 16
1
d.
Assignment of Birth Registration Numbers ................................................................................ 16
e.
Data Fields Disablement and Data Sharing ................................................................................. 17
f.
Late Birth Registration ................................................................................................................ 18
g.
Birth Registration Data Requirements ........................................................................................ 20
h.
Linking of Birth and Death Records............................................................................................. 21
i.
Birth Certificates Production and Printing .................................................................................. 21
Change of Name Module .................................................................................................................. 22
a.
Legal Change of Name ................................................................................................................ 22
b.
LCN Registration Data Requirements ......................................................................................... 22
c.
Assignment of LCN Registration Numbers .................................................................................. 23
d.
LCN Certificate Production and Printing ..................................................................................... 23
Adoption Module............................................................................................................................. 24
a.
Registering an Adoption.............................................................................................................. 24
b.
Adoption Registration Data Requirements ................................................................................. 25
c.
Data Fields Disablement ............................................................................................................. 26
d.
Assignment of Adoption Registration Numbers ......................................................................... 26
Deaths Module ................................................................................................................................ 27
a.
Data Matching ............................................................................................................................. 27
b.
Incomplete Death Registration ................................................................................................... 27
c.
Automatic Calculation ................................................................................................................. 28
d.
Death Registration Data Requirements ...................................................................................... 28
e.
Modifications and Updates ......................................................................................................... 29
f.
Assignment of Death Registration Numbers .............................................................................. 29
g.
Certificate Production and Printing ............................................................................................ 30
h.
Statistical Reports Generation .................................................................................................... 30
i.
Stillbirths ..................................................................................................................................... 30
j.
Assignment of Stillbirth Registration Numbers .......................................................................... 30
k.
Certificate Production and Printing ............................................................................................ 31
l.
Stillbirth Registration Data Requirements .................................................................................. 31
2
Introduction
Civil registration refers to universal, continuous, compulsory and permanent
recording of key life events such as births, deaths and marriages. In the Solomon
Islands, the Civil Registry Office is responsible for registering and maintaining
records of births and deaths for all indigenous Solomon Islanders. The estimated
population of Solomon Islands in the 2009 census was 515,087 and the
projected average population growth is 2.3 per cent per annum.
Current Situation
The duties currently performed by the Civil Registry Office include receiving
notifications of key life events (births, deaths and adoptions) from other
stakeholders, registering these events, generating and issuing certificates, as
well as correction and maintenance of records. Although the Civil Registry Office
works collaboratively with other stakeholders and government agencies, the
Ministry of Health has a direct involvement in the birth registration process
because it provides virtually all birth notifications. The current system is largely
paper-based and the Civil Registry Office does not have a database
management system. The absence of a database management system affects
organisational performance and effectiveness because of operational and
productivity constraints associated with the current manual system. The current
system suffers from inadequate security, limited file sharing, and lack of data
integrity. The absence of a database management system also affects the
collection, analysis, and generation of reports from aggregated data. In addition,
there is no auditable electronic record of what was issued, to whom, by whom,
and when. In order to improve operational efficiency and effectiveness, as well as
resolve the issues identified above, the Civil Registry Office has decided to
acquire a database management system.
3
Request for Proposal (RFP)
The purpose of this RFP document is to invite qualified companies to submit
proposals for designing, building, and installing an integrated, reliable, secure
and easy to use database management system capable of supporting the
functions of the Civil Registry Office. The proposal must include the costs of
ancillary professional services such as software documentation, training,
maintenance and support and all travel costs.
Proposal Guidelines and Requirements
a) By submitting a proposal, participants accept that this is an open and competitive
process and they are solely responsible for all costs incurred in preparing and
submitting a proposal. In addition, participants agree to indemnify the Civil
Registry Office, the Ministry of Home Affairs, the Government of Solomon
Islands, and any other affiliated parties in relation to any costs, expenses or
liability incurred in responding to this RFP.
b) Participants agree that all submitted proposals and associated documentation
will become the property of the Civil Registry Office and will not be returned to
participants.
c) Participants accept that all information obtained from the Civil Registry Office as
a result of their participation in this RFP process is proprietary and confidential
and shall not be disclosed or used in any other manner without prior written
permission from the Civil Registry Office.
d) The successful bidder will be required to work and coordinate development
activities with an appointed consultant, as well as periodically meet with
nominated staff, key stakeholders and sponsors, to discuss development
progress.
4
e) The Civil Registry Office has sole discretion and reserves the right to reject any
or all proposals received in response to this RFP or withdraw this solicitation for
any reason at any time. Participants agree that the Civil Registry Office is not
bound to accept any proposal solely on the basis that it contains the lowest price.
f) The Civil Registry Office reserves the right to make amendments to this RFP by
issuing notice of amendments to all participants.
g) Participants may be required to give an oral presentation to the Civil Registry
Office concerning their proposal.
h) Participants must understand the realities and limitations of working in an
environment with very limited resources and agree to remain flexible and
responsive at all times.
i) The bid must contain the signature of a duly authorised officer or agent of the
company submitting the proposal.
j) It is acceptable for participants to submit alternate (functionally equivalent)
solutions or “in production” software capable of meeting the Civil Registry Office’s
operational needs.
k) The software developed from the functional requirements document will be
considered ‘work for hire’ and the Civil Registry Office will have sole and absolute
ownership of the source codes and any other intellectual property rights.
l) The laws of the Solomon Islands shall govern any contractual agreement
resulting from this RFP.
m) Participants are required to disclose any hypothecation of right, assignments or
pledges to any entity that might affect their ability to execute the project.
5
n) Participants are required to disclose in their proposals any intention to subcontract all or any part of the project. While sub-contracting is acceptable under
certain circumstances, the winning bidder shall not sub-contract any part of the
project without the written permission of the Civil Registry Office.
o) In relation to the sub-contracting matter, the Civil Registry Office retains the
rights to veto or refuse the use of any sub-contractor appointed by the main
contractor.
p) For updated data fields, please refer to the Appendix.
Standard Proposal Format
Participants should prepare and submit their proposals in the following format:
Title Page and Table of Contents
Summary
Organisational profile
Experience with similar projects
Project planning methodology
Proposed project team members and their experiences
Proposed development technologies and architecture
Testing and quality assurance system
Training, support and maintenance plan
Value added
Any other relevant information participants would like to add
Important Dates
Whilst the Civil Registry Office will endeavour to comply with this schedule of
events, it reserves the right to change the dates.
6
By submitting a proposal, participants accept that these dates are tentative and
the Civil Registry Office will not be liable for any losses incurred as a result of
participants’ reliance on this schedule of events.
Date
Event
29 April 2013
Public notice of RFP
06 May 2013
Deadline for receipt of written questions
10 May 2013
Response to written questions
27 May 2013
Deadline for submission of proposal
14 June 2013
Notification of outcome to participants
21 June 2013
Contract negotiations
28 June 2013
Contract ratified and signed
7
General Functional Requirements
1. Authentication and Authorisation
The proposed system must provide an authentication mechanism for ensuring
that only registered users have access to the database system. Once a person
has been authenticated, the system must apply access control mechanisms to
ensure that a user’s access to system functions and data resources corresponds
with their assigned level of authority or access rights and privileges. The system
must also provide a means of separating roles and duties. For example, a rolebased access control might be used to limit access to data resources at folder
and data levels. The proposed system must provide the ability to lockout a user’s
account after three failed logon attempts as well as provide a means of recording
and retaining both successful and failed logon attempts. The proposed system
should also provide the ability to enforce minimum password length and strength
as well as password expiration rules.
2. Database Management Tools
The system must provide the administrative tools necessary for managing the
database, including the creation and assignment of user rights and privileges; the
deletion of users and modification of access rights; scheduling of events; reports
generation; backup and recovery; database optimisation; and general database
security management. In terms of backup mechanism, the system should also
support dynamic backup.
3. Automatic Alert Trigger
The proposed system must have the ability to create an alert to any life-event
record, which is automatically activated if certain conditions are met.
8
4. Interface
The database system must provide a Graphical User Interface (GUI) for data
entry and associated activities. The interface must be user friendly, clear,
predictable, consistent and efficient.
5. Database Security
Due to the sensitive nature of the data elements that are intended to be held in
the database, the proposed system must provide an encryption mechanism for
securing the entire database (data at rest) as well as ensuring that transmitted
data between two end points (externally and internally) are not compromised. As
encryption affects data size and impacts on database performance, the system
architecture should be designed to minimise any performance degradation.
6. Audit Trail and Log
The proposed system must provide a secure and automated audit capability for
recording activities in the system as well as changes made to data records. All
suspicious activities must be logged and reported to the Administrator.
The proposed system must record the following audit trail activities:
Nature of the event (for example, access to records, insertion and deletion)
Identity of the user or system component
Point of origin of the event
Date and time
Identity of data or system resources affected
The proposed system must record and keep information about unsuccessful
attempts to access data and system resources. The log file must be secured and
only authorised people should have access to the file.
9
In addition, the proposed system must provide a means of ensuring that the audit
trails and log files cannot be altered or deleted.
7. Certificates Production and Printing
The system must provide the ability to produce, view and print birth, death and
change of name certificates. In so doing, the system must be able to produce
individualised certificates by allowing automatic extraction of relevant data from
the database.
The proposed system should provide a text field for certificate numbers because
the certificate will be printed on pre-numbered security paper. The certificate
should have an electronic seal or stamp and a digital watermark. The certificate
should also contain a bar-coded identification number of the operator as well as
the computer identification number. Once printed, a copy of the certificate should
be saved in a portable file format. In addition, the system should keep a log of all
certificates produced, including the particulars of the operator, date and time of
production, and paper number used for the production of the certificate.
8. Reports Generation
The proposed system must provide the ability to generate, print, and/or save
different types of reports including predefined routine reports as well as ad-hoc
reports. The reporting capability must include the generation of reports using
multiple categories as well as provide automatic calculation features. The system
must also have the ability to generate, view, print, and/or save audit reports,
including exception reports.
10
9. Correspondence Generation
The proposed system must provide the ability to generate and print operational
letters. For example, letters to parents or medical workers requesting additional
information or documentation. In addition, the system must have the ability to
store template letters and forms as well as keep electronic records of all outgoing
correspondence.
10. Data Validation
The proposed system must provide the ability to validate data inputs. Data
validation functions are required to ensure data entry completion and to prevent
the entry of invalid/incorrect information into the database. As input validation is
crucial to the overall functioning of the database, the proposed system must
ensure that illegal or invalid values are not passed to the database. The system
must provide a means of ensuring that the user has completed all mandatory
data entry fields before enabling the registration of a new record.
The system must have the ability to display warning/alert messages as well as
provide the ability for soft and hard edits.
For example, if the date of birth
entered is in the future, an instructive pop-up warning/message should inform the
user of the data entry error as well as the reasons for the error (context sensitive
help).
11. Data Input Format Correction
The proposed system must provide the ability to change certain data inputs to
conform to the desired format. For example, if the date of birth does not conform
to the desired format, the system should automatically change it to conform
rather than reject the input. The system must have the ability to capitalise (auto
covert) all proper nouns.
11
For example, if the first letter of a name is not capitalised, the system should
automatically capitalise it.
The proposed system must ensure that the date text fields contain a pop-up
calendar.
12. Search and Retrieve
The proposed system must provide the functionality for searching and retrieving
any potential duplicate record before enabling the creation of a new life event
record in the database. If a duplication record is found, the system should
provide a means of handling the duplicate record.
The proposed system must provide the ability to search for records of births,
deaths, legal change of names, stillbirths and adoptions using either a single
criterion or multiple criteria. The system must also provide support for wild card
searches.
The proposed system must ensure that the search functionality is not case
sensitive.
The proposed system must provide the functionality for the user to sort search
results in either ascending or descending order.
13. Modification of Key Life Events Records
The proposed system must provide the ability to modify records (births, deaths,
change of names, adoptions, stillbirths) of key life events. In so doing, it must
also provide a means of ensuring that only authorised high-level users are
allowed to modify or change completed records of key-life events. The history of
the modification must be permanently retained.
12
14. Deletion of Invalid Records
As there may be cases where completed records of life events are no longer
valid for one reason or another (for example, an erroneously or fraudulently
created record), the proposed system must provide a means of voiding such
entries. However, the system must ensure that invalid records can only be
voided, and not deleted from the database.
The proposed system must also provide the ability to permanently archive voided
records, as well as a means of retrieving and viewing these records. It must also
provide a way of ensuring that only authorised high-level users have access to all
voided or cancelled life events records.
Keystrokes Reduction and Data Entry
The system must provide mechanisms to enable data entry efficiency and
keystroke reduction wherever practicable. For example, an auto-populate
functionality can be used to populate certain text fields based on input selection
from a drop down menu. For example, when a health facility is selected from a
list of health facilities, the location and province text fields should be
automatically populated.
The system must provide the ability to dynamically suppress or disable text fields
based on the data entered in the previous fields. For example, when creating a
birth record, if the mother has not named the child’s father, the relevant data
entry fields for the child’s father should be disabled.
15. Future Technological Integration
It is anticipated that medical workers from provincial health facilities should be
able to electronically transfer vital events data to the Registrar of Births and
Deaths.
13
Accordingly, the proposed system must have the ability to securely interconnect
with the Ministry of Health’s Health Information System (HIS) via a web-based
interface. The web-based interface should support the use of Secure Socket
Layer (SSL) for data transmission.
The proposed system must ensure that incoming data input are validated,
evaluated for expected size, format and type before acceptance. Because of the
sensitive nature of the information being transmitted, the system must have the
ability to reject unencrypted data.
16. Historical Birth Record Migration (HBRM)
It is anticipated that the existing electronic records of births and deaths will be
migrated to the new database system. As such, the proposed system must
provide data migration functionality. In addition, it must provide a means of backcapturing paper-based records (through scanning and manual data entry).
The proposed system must have the ability to manually generate and assign
registration numbers to historical birth records that are migrated from existing
paper-based and electronic records. The proposed system should support the
importation and exportation of electronic records using a number of formats
including .txt, .xml, .csv and .xls.
14
Birth Registration Module
The proposed system must provide the data entry and processing functionalities
necessary for creating and recording two types of birth registration records: on
time birth registrations and late birth registrations (OTBR and LBR). In the
Solomon Islands, a birth that is registered after the child’s fifth birthday is
deemed a late registration. Accordingly, the proposed system must provide a
means of differentiating between the above-mentioned types of birth registrations
because of the variation in information requirements for each type.
When creating a new birth record, the proposed system must provide the ability
for the user to select a ‘Registration Type’ as defined below:
 OTBR – On Time Birth Registration
 LBR – Late Birth Registration
Depending on the ‘Registration Type’ chosen by the user, the system should be
able to provide appropriate data entry fields as shown in the next section of this
document.
On Time Birth Registration
The proposed system must provide the functionality for capturing, processing
and adding a new birth record.
a. Parental Search and Link
The proposed system must have the ability to search for parents’ records in the
database. The system should provide a means of linking parents to a child if the
operator confirms a positive match. As there may be cases of erroneously linked
records, the system should also have the ability to unlink records.
15
The system should provide a means of auto-filling the parents’ data fields if a
match is confirmed. Finally, the system should provide the ability to update the
parents’ records if required.
b. Incomplete Registrations
The proposed system must have the functionality to save incomplete
registrations as well as provide the means to retrieve and complete a registration
when the missing information becomes available. The system must also provide
the ability to track and report on partial registrations.
c. Automatic Calculation
The system should automatically calculate the age of mother and father from the
information entered in the relevant dates of birth fields. The system must also
provide a means of dealing with cases where the date of birth of either parent is
unknown.
d. Assignment of Birth Registration Numbers
The proposed system must provide the ability to automatically assign a unique
birth registration number to every new birth record. The number assignment
method should be in the following format: DD/MM/YYYY/001/XXXXXXXX for a
male child and DD/MM/YYYY/100/XXXXXXXX for a female child.
Items
Representations
DD
Represents day of birth
MM
Represents month of birth
YYYY
Represents year of birth
001 and 100
Represents sex (male and female)
XXXXXXXX
Represents the assigned unique number
16
On 1 January each year, the numeric portion of the assigned number must reset
to XXXXXXXX (for example, 0001) for the first registration of the year and
continue from there.
e. Data Fields Disablement and Data Sharing
The proposed system should provide a means of suppressing the father’s text
fields in cases where the mother either does not know the father or refuses to
name the father.
If the father and mother are living together, the system should auto-fill the father’s
address fields. Accordingly, a checkbox (or an equivalent method) should be
provided to enable this function.
The default country of birth should be Solomon Islands. If the child was not born
at one of the health facilities, then the system should have the ability to disable
the health facility fields. If the birth occurred overseas, the system should
suppress the ‘province’ and the ‘health facility’ text fields.
In cases of multiple deliveries, the proposed system needs to generate a crossreference number. It should also provide a means of data sharing given the
inherent presence of shared data such as parents’ details.
If the child’s place of birth is in the ‘Facilities Lookup List’, the system must have
the ability to auto-fill the facility data fields.
Information used for recording a new birth is obtained from the ‘Notice of
Live/Still Birth form’ (please see appendix).
17
For ‘OTBR’ registrations, the proposed system must be able to record the
following information:
Child’s Birth Details







Health Facility Details






Child’s Surname
Child’s Given Name(s)
Child’s Sex
Child’s Date of Birth
Child’s Place of Birth
Child’s Country of Birth
Number/Order of Birth
Health Facility Name
Facility Type (drop down)
Location (Look up List)
Province (drop down)
Name of Attendant
Attendant’s Qualification (drop
down)
Mother’s Details
Father’s Details
 Mother’s Surname
 Father’s Surname
 Mother’s Maiden Name
 Father’s Given Name(s)
 Mother’s Given Name(s)
 Father’s Date of Birth
 Mother’s Date of Birth
 Father’s Country of Birth
 Mother’s Country of Birth
 Father’s Age
 Mother’s Age
 Nationality (Default Solomon
 Number of Live Born Children
Islander)
 Marital Status
 Father’s Occupation
 Nationality (Default Solomon
 Father’s Address 1
Islander)
 Father’s Address 2
 Mother’s Occupation
 Province (drop down)
 Mother’s Address 1
 Country (Default Solomon Islands)
 Mother’s Address 2
 Province (drop down)
 Country (Default Solomon Islands)
Registration Details
Registration File Note
 Registration Officer’s Surname
 Registration Officer’s Given
Name(s)
 Date of Registration
f. Late Birth Registration
The system must provide a means of identifying late registration of births. As
mentioned earlier, a birth registered after the child’s fifth birthday is legally
deemed a late registration.
18
Information used to record late birth registrations is obtained from a number of
sources. In some cases (such as the registration of minors), the birth details are
supplied by the child’s parents or by other adult family members.
In the self-reported cases (such as the registration of adults), the birth details are
usually provided by the applicant. However, evidential documents are still
required to support the information supplied by the applicant or informant. For
these reasons, the system must have the ability to handle proof of evidence
before allowing a late registration.
If the child is under the age of five and was not born in one of the health facilities,
the parents will be required to complete an affidavit as well as provide other
types of documentary evidence, such as a hospital record or a baptismal
certificate.
If the person being registered is over five years old and was born in one of the
health facilities, an affidavit will be required from the person’s parents stating
their reasons for delayed registration. In addition, the parents will also be
required to provide other documentary evidence such as a hospital issued birth
notification document.
If the person being registered is 18 years old or over, he/she will be required to
complete an affidavit as well as provide documentary evidence proving the date
of birth.
If the informants are the child’s parents, the system must be able to copy and
transfer data from the parents’ data text fields to the informant’s data text fields.
If the person being registered is over 18 years old and it is a self-reported birth,
the system must have the ability to copy and transfer data from the child’s data
fields to the informant’s data fields.
19
g. Birth Registration Data Requirements
For late birth registrations, the proposed system must have the ability to record
the following information:
Child’s Birth Details






Particulars of the Informant






Child’s Surname
Child’s Given Name(s)
Child’s Sex
Child’s Date of Birth
Child’s Place of Birth
Child’s Country of Birth



Mother’s Details
 Mother’s Surname
 Mother’s Maiden Name
 Mother’s Given Name(s)
 Mother’s Date of Birth
 Mother’s Age
 Mother’s Country of Birth
 Nationality (Default Solomon
Islander)
 Mother’s Occupation
 Mother’s Address 1
 Mother’s Address 2
 Province (drop down)
 Country of Birth
Registration Details
 Registration Officer’s Surname
 Registration Officer’s Given
Name(s)
 Date of Registration
Informant’s Surname
Informant’s Given Name(s)
Informant’s Occupation
Informant’s Address 1
Informant’s Address 2
Self-Reported (yes/no radio
button)
Relationship to the Registrant
Proof or Evidence of Relationship
Type of Evidential Document
Father’s Details
 Father’s Surname
 Father’s Given Name(s)
 Father’s Date of Birth
 Father’s Age
 Father’s Country of Birth
 Nationality (Default Solomon
Islander)
 Father’s Occupation
 Father’s Address 1
 Father’s Address 2
 Province (drop down)
 Country of Birth
Registration File Note
20
h. Linking of Birth and Death Records
The proposed system must provide the ability to create and maintain a link
between a person’s birth record and death record. As such, the system must
have the ability to search and compare death records against birth records in the
database. If a match is found, the system must have the ability to mark the birth
record as ‘deceased’.
i. Birth Certificates Production and Printing
The proposed system must provide the functionality to produce and print
abridged and unabridged birth certificates. The user should be given the option of
viewing and/or printing the certificate.
The proposed system should provide a dialog box for the user to enter a unique
paper number before enabling the print dialog box.
The proposed system must have the ability to generate a time-specified batch of
certificates in order to facilitate the distribution of complimentary birth certificates
(for OTBR registrations).
If a birth record is flagged as ‘deceased’, subsequent reprinted birth certificates
must be stamped ‘deceased’.
If a Legal Change of Name record exists, the system should have the ability to
extract the person’s current legal name from LCN records and all subsequent
reprinted birth certificate should contain the change of name details (see sample
certificates).
21
Change of Name Module
The proposed system must be able to accommodate a legal change of name as
well as the inclusion of other additional names, such as baptismal names, to birth
records. Changes can be made to the surname and/or given names of the child.
a. Legal Change of Name
The proposed database must have the ability to add a new Legal Change of
Name (LCN) record to the database. Before a LCN can be completed, the
system must provide the ability to search the existing change of name records,
as well as the birth and adoption records.
b. LCN Registration Data Requirements
For ‘LCN’ registrations, the proposed system must be able to record the following
information:
Birth Details
New Name Details
 Surname
 Given Name(s)
 Sex
 Date of Birth
 Place of Birth
 Country of Birth
Registration Details





Surname
Given Names
Change of Name History
Registration Officer’s Surname
Registration Officer’s Given Name(s)
Date of Registration
From:
To:
Date
Registration File Note
If the person was born in Solomon Islands but their birth was not registered, the
system should provide the ability to register the person’s birth before enabling the
completion of a change of name. The classification of the birth type will depend
on whether the registration is an OTBR or a LBR.
22
If the change of name is completed before the child’s fifth birthday, the system
should allow an overtype of the previous name, but should retain the history.
When entering a change of name in this case, the system must ensure that other
bio-data text fields (for example, date of birth, sex and place of birth) are not
enabled. If the change of name is after the child’s fifth birthday, then the
proposed system must activate the LCN procedure.
c. Assignment of LCN Registration Numbers
The proposed system must provide the ability to automatically assign a unique
registration number to every new Legal Change of Name record. The registration
number assignment should be in this format: LCN/DD/MM/YYYY/XXXXXXXX.
Items
Representations
LCN
Legal Change of Name
DD
Represents day
MM
Represents month
YYYY
Represents year
XXXXXXXX
Represents the assigned unique number
On 1 January each year, the numeric portion of the assigned number should
must reset to XXXXXXXX for the first registration of the year and continue from
there.
d. LCN Certificate Production and Printing
The proposed system must provide the functionality to produce and print LCN
certificates. The user should be given the option of viewing and/or printing the
certificate. If the change of name is completed before the child’s fifth birthday,
there should be no separate change of name certificate. If the change of name is
23
completed after the child’s fifth birthday, the system should enable the production
and printing of a certificate.
Adoption Module
Legal adoptions differ from customary adoptions. Legal adoption refers to the
process of transferring parental rights and duties from the child’s biological
parents to the adoptive parents. Once the adoption order has been granted, the
biological or natural parents’ rights and duties are extinguished. In the Solomon
Islands, a legal adoption can only be registered through the presentation of a
court issued ‘Adoption Order’.
a. Registering an Adoption
If the child was born and registered in the Solomon Islands, the proposed system
must have the ability to record the adoption details. Once a new adoption event
has been completed, the proposed system must be able to create a new birth
record reflecting the details of the adoptive parents and the child’s new name.
If the child’s birth was not registered, the system must have the ability to register
the child, seal the old record of birth and then create a new post-adoptive birth
record using the child’s adoptive parents’ details and the child’s new name(s) (if
applicable).
The proposed system must provide a means of reusing the original birth
registration number, as well as being able to link the pre-adoptive birth record,
the adoption record and the post-adoptive birth record.
Once the adoption registration process is completed, the child’s pre-adoption
birth certificate should be sealed and made inaccessible to an ordinary user.
24
The proposed system must ensure that subsequent birth certificates printed after
the registration of the adoption do not contain name-related information from the
sealed original birth record.
b. Adoption Registration Data Requirements
Child’s Pre-adoptive Birth Details






Child’s Post-Adoptive Details


Child’s Surname
Child’s Given Name(s)
Child’s Sex
Child’s Date of Birth
Child’s Place of Birth
Child’s Country of Birth
Biological Mother’s Details
 Mother’s Surname
 Mother’s Maiden Name
 Mother’s Given Name(s)
 Mother’s Date of Birth
 Mother’s Age
 Mother’s Marital Status
 Nationality
 Mother’s Occupation
 Mother’s Address 1
 Mother’s Address 2
 Province (drop down)
 Country of Birth
Child’s Post-Adoptive Surname
Child’s Post-Adoptive Given
Name(s)
 Date of Adoption
 Age at the Time of Adoption
 Court Adoption Reference Number
(CARN)
 Adoption Type (local or foreign)
Adoptive Mother’s Details
 Mother’s Surname
 Mother’s Maiden Name
 Mother’s Given Name(s)
 Mother’s Date of Birth
 Mother’s Age
 Mother’s Marital Status
 Nationality
 Mother’s Occupation
 Mother’s Address 1
 Mother’s Address 2
 Province (drop down)
 Country of Birth
Biological Father’s Details
 Father’s Surname
 Father’s Given Name(s)
 Father’s Date of Birth
 Father’s Age
 Nationality
 Father’s Occupation
 Father’s Address 1
 Father’s Address 2
 Province (drop down)
 Country of Birth
Adoptive Mother’s Details
 Father’s Surname
 Father’s Given Name(s)
 Father’s Date of Birth
 Father’s Age
 Nationality
 Father’s Occupation
 Father’s Address 1
 Father’s Address 2
 Province (drop down)
 Country of Birth
Adoption Registration Details
Registration File Note
25


Registration Officer’s Surname
Registration Officer’s Given
Name(s)
Date of Registration

c. Data Fields Disablement
For adoptions of persons not born in the Solomon Islands, the system should
provide the ability to suppress irrelevant text fields such as the ‘province’ text
field.
d. Assignment of Adoption Registration Numbers
The proposed system must have the ability to automatically assign a unique
registration number to every new adoption record. The adoption registration
number should be in the following format: A/DD/MM/YYYY/XXXXXXXX.
Items
Representations
A
Adoption
DD
Represents day of adoption order
MM
Represents month of adoption order
YYYY
Represents year of adoption order
XXXXXXXX
Represents the assigned unique number
On 1 January each year, the numeric portion of the assigned number must reset
to XXXXXXXX for the first registration of the year and continue from there.
26
Deaths Module
The proposed database should have the ability to add a new death record. In the
process of creating a new death record, the system should provide a means of
searching the database for a potential matching birth record, as well as checking
for a potential duplicate death record before accepting any new entry. If no
matching birth record is located, the system must be able to add a new birth
record to the system. Once completed, the system should flag the birth record as
‘deceased’ and allow the user to create a death record.
a. Data Matching
The system should have the ability to data-match birth records against death
records as well as enable the flagging of birth records as ‘deceased’. The
purpose of this functionality is to prevent fraudulent use of birth records. The
system should provide a mechanism for the database administrator to ‘un-flag’ a
record as ‘deceased’ in cases of erroneously flagged records.
b. Incomplete Death Registration
The proposed system must be able to save incomplete death registrations. The
system should also have the ability to retrieve and complete a registration when
the missing information becomes available. The system must have the ability to
track and report on partial death registrations.
27
c. Automatic Calculation
The system should automatically calculate the deceased’s age from the
information entered in the date of birth field. The system must provide a means of
dealing with cases where the date of birth of the deceased is unknown.
d. Death Registration Data Requirements
For death registrations, the proposed system must be able to record the following
information:
Deceased’s Details
Death Details




Surname
Given Name(s)
Sex
Marital Status (if married, enable
text fields for spouse details)
 Number of Surviving Children (if
applicable, enable text fields )
 Occupation
 Address 1
 Address 2
 Province
 Country
Mother’s Details
 Mother’s Surname
 Mother’s Maiden Name
 Mother’s Given Name(s)





Health Facility Details
 Facility Name
 Facility Type (drop down)
 Location
 Province (drop down)
Certifier’s Details
 Surname
 Given Names
 Certifier’s Qualification (drop
down)
Registration Details
Date of Death
Place of Death
Causes of Death
Age
Autopsy Required (yes/no)
Father’s Details
 Father’s Surname
 Father’s Given Name(s)
 Father’s Date of Birth
Registration File Note
28

Registration Officer’s Surname
 Registration Officer’s Given
Name(s)
 Date of Registration
e. Modifications and Updates
The proposed system must allow for error corrections in relation to any data
collected during the process of a death registration. The system must be able to
update an existing death record if certain defined conditions are present.
However, ordinary users must not have the rights to modify completed records.
In performing these functions, the system must have the ability to capture and
permanently keep records of previous, amended, or deleted data.
f. Assignment of Death Registration Numbers
The proposed system must have the ability to automatically assign a unique
registration number to every new death record. The registration numbers for
death records should be in the following format: D/DD/MM/YYYY/XXXXXXXX.
Items
Representations
D
Death
DD
Represents day of death
MM
Represents month of death
YYYY
Represents year of death
XXXXXXXX
Represents the assigned unique number
On 1January each year, the numeric portion of the assigned number must reset
to XXXXXXXX for the first registration of the year and continue from there.
29
g. Certificate Production and Printing
The proposed system must provide the functionality to produce and print death
certificates. The user should be given the option of viewing and/or printing the
certificate. In some cases, the family of the deceased may not want the cause(s)
of death to be printed on the death certificate. Accordingly, the system must be
able to either print or supress the cause(s) of death data when printing a death
certificate.
h. Statistical Reports Generation
The proposed system must provide a means of deriving statistical data from the
database. For example, it should be able to generate reports regarding infant
mortality and causes of death.
i. Stillbirths
A stillbirth refers to a situation where a baby is delivered without noticeable signs
of life. Although there can be no death without birth, it is considered that stillbirth
should be subsumed within the death module.
The proposed system must provide the ability to add stillbirth records to the
database without the need for a corresponding birth record because a stillbirth is
not legally a birth.
j. Assignment of Stillbirth Registration Numbers
The proposed system must have the ability to automatically assign unique a
registration number to every new stillbirth record.
30
The registration numbers for stillbirth records should be in the following format:
SB/DD/MM/YYYY/XXXXXXXX.
Items
Representations
SB
Stillbirth
DD
Represents day of delivery
MM
Represents month of delivery
YYYY
Represents year of delivery
XXXXXXXX
Represents the assigned unique number
On 1January each year, the numeric portion of the assigned number must reset
to XXXXXXXX for the first registration of the year and continue from there.
k. Certificate Production and Printing
The proposed system must provide the ability to generate and print stillbirth
certificates.
l. Stillbirth Registration Data Requirements
For new stillbirth registrations, the proposed system must have the ability to
record the following information:
Child’s Stillbirth Details
Facility Details








Child’s Surname (optional)
Child’s Given Name(s) (optional)
Child’s Sex
Child’s Date of Delivery
 Child’s Place of Delivery
 Causes of stillbirth
Mother’s Details
 Mother’s Surname
 Mother’s Maiden Name
 Mother’s Given Name(s)
Health Facility Name
Facility Type (drop down)
Location (Look up List)
Province (drop down)
 Name of Attendant
 Attendant’s Qualification (drop
down)
Father’s Details
 Father’s Surname
 Father’s Given Name(s)
 Father’s Date of Birth
31





Mother’s Date of Birth
 Father’s Country of Birth
Mother’s Country of Birth
 Father’s Age
 Nationality (Default Solomon
Mother’s Age
Islander)
Marital Status
 Father’s Occupation
Nationality (Default Solomon
Islander)
 Father’s Address 1
 Mother’s Occupation
 Father’s Address 2
 Province (drop down)
 Mother’s Address 1
 Country (Default Solomon Islands)
 Mother’s Address 2
 Province (drop down)
 Country (Default Solomon Islands)
Registration Details
Registration File Note
 Registration Officer’s Surname
 Registration Officer’s Given
Name(s)
 Date of Registration
32