CIVIL REGISTRATION FUNCTIONAL REQUIREMENTS FOR DATABASE ... · REQUEST FOR PROPOSAL CIVIL REGISTRATION FUNCTIONAL REQUIREMENTS FOR DATABASE DESIGN AND DEVELOPMENT ... The current

REQUEST FOR PROPOSAL

CIVIL REGISTRATION

FUNCTIONAL REQUIREMENTS

FOR

DATABASE DESIGN AND DEVELOPMENT

Civil Registry Office

Ministry of Home Affairs

Level 6, Anthony Salu Building

Honiara

Solomon Islands

1

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

2

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 ................................................................................................................. 27

d. Death Registration Data Requirements ...................................................................................... 28

e. Modifications and Updates ......................................................................................................... 28

f. Assignment of Death Registration Numbers .............................................................................. 29

g. Certificate Production and Printing ............................................................................................ 29

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

3

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.

4

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.

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.

5

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.

6

n) Participants are required to disclose in their proposals any intention to sub-

contract 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.

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.

7

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.

8

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 role-

based 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.

9

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.

10

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.

11

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.

12

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.

13

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.

14

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 back-

capturing 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.

15

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.

16

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/XXXX for a male

child and DD/MM/YYYY/100/XXXX 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)

XXXX Represents the assigned unique number

17

On 1 January each year, the numeric portion of the assigned number must reset

to XXXX (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 cross-

reference 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).

18

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

• Mother’s Maiden Name

• Mother’s Given Name(s)

• Mother’s Date of Birth

• Mother’s Country of Birth

• Mother’s Age

• Number of Live Born Children

• Marital Status

• Nationality (Default Solomon Islander)

• Mother’s Occupation

• Mother’s Address 1



• Country (Default Solomon Islands)

• Father’s Surname

• Father’s Given Name(s)

• Father’s Date of Birth

• Father’s Country of Birth

• Father’s Age


• Father’s Occupation

• Father’s Address 1




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.

19

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.

20

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 Sex




• 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






• Mother’s Age







• Country of Birth




• Father’s Age












21

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).

22

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


• Surname

• Given Names

Registration Details Change of Name History




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.

23

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/XXXX.


LCN Legal Change of Name

DD Represents day

MM Represents month

YYYY Represents year


On 1 January each year, the numeric portion of the assigned number should

must reset to XXXX 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

completed after the child’s fifth birthday, the system should enable the production

and printing of a certificate.

24

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.

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.

25

b. Adoption Registration Data Requirements

Child’s Pre-adoptive Birth Details Child’s Post-Adoptive Details



• Child’s Sex




• 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)

Biological Mother’s Details Adoptive Mother’s Details





• Mother’s Age

• Mother’s Marital Status

• Nationality










• Mother’s Age

• Mother’s Marital Status

• Nationality






Biological Father’s Details Adoptive Mother’s Details




• Father’s Age

• Nationality









• Father’s Age

• Nationality






Adoption Registration Details Registration File Note




26

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/XXXX.


A Adoption

DD Represents day of adoption order

MM Represents month of adoption order

YYYY Represents year of adoption order


On 1 January each year, the numeric portion of the assigned number must reset

to XXXX for the first registration of the year and continue from there.

27

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.

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.

28

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

• Date of Death

• Place of Death

• Causes of Death

• Age

• Autopsy Required (yes/no)








Health Facility Details Certifier’s Details

• Facility Name


• Location • Province (drop down)

• Surname

• Given Names

• Certifier’s Qualification (drop down)





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.

29

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/XXXX.


D Death

DD Represents day of death

MM Represents month of death

YYYY Represents year of death


On 1January each year, the numeric portion of the assigned number must reset


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.

30

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. The registration numbers for

stillbirth records should be in the following format: SB/DD/MM/YYYY/XXXX.


SB Stillbirth

DD Represents day of delivery

MM Represents month of delivery

YYYY Represents year of delivery


On 1January each year, the numeric portion of the assigned number must reset


31

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

• Health Facility Name


• Location (Look up List)


• Name of Attendant • Attendant’s Qualification (drop

down)







• Mother’s Age

• Marital Status











• Father’s Age











Documents

CIVIL REGISTRATION FUNCTIONAL REQUIREMENTS FOR DATABASE ... · REQUEST FOR PROPOSAL CIVIL REGISTRATION FUNCTIONAL REQUIREMENTS FOR DATABASE DESIGN AND DEVELOPMENT ... The current