This community is in archive. Visit community.xprize.org for the current XPRIZE Community.
Entry Fields
XPRIZE
Posts: 193 admin
Here is a list of the potential entry fields that teams would need to build capabilities for in their solutions and fill for each individual child birth notification. These would be included in the dummy database. Should any of these be made optional? Are there any additional entry fields that should be added?
1. Child
a. Full Name:
b. Sex:
c. Date of Birth:
d. Place of Birth:
e. Weight at Birth (optional):
2. Mother
a. Mother’s Maiden Name:
b. Mother’s Address of Residence:
c. Mother’s Marital Status:
d. Mother’s Proof of Identity:
i. Type (Birth Certificate, National ID, Passport, etc.):
ii. Number:
iii. Image:
3. Father
a. Father’s Full Name:
b. Father’s Address of Residence:
c. Father’s Marital Status:
d. Father’s Proof of Identity:
i. Type (Birth Certificate, National ID, Passport, etc.):
ii. Number:
iii. Image:
4. Notifier
a. Date of Notification (Date this information was submitted):
b. Notifier Full Name:
c. Notifier Address:
d. Notifier Contact Information:
e. Notifier Relationship to the Child:
f. Notifier Signature:
5. Certificate Issued by Hospital, Physician or Midwife (If none, then names, addresses and contact information of two witnesses other than the mother or the father)
6.Space for Remarks and Comments
---
Please share any thoughts, ideas, or comments in the discussion below!
1. Child
a. Full Name:
b. Sex:
c. Date of Birth:
d. Place of Birth:
e. Weight at Birth (optional):
2. Mother
a. Mother’s Maiden Name:
b. Mother’s Address of Residence:
c. Mother’s Marital Status:
d. Mother’s Proof of Identity:
i. Type (Birth Certificate, National ID, Passport, etc.):
ii. Number:
iii. Image:
3. Father
a. Father’s Full Name:
b. Father’s Address of Residence:
c. Father’s Marital Status:
d. Father’s Proof of Identity:
i. Type (Birth Certificate, National ID, Passport, etc.):
ii. Number:
iii. Image:
4. Notifier
a. Date of Notification (Date this information was submitted):
b. Notifier Full Name:
c. Notifier Address:
d. Notifier Contact Information:
e. Notifier Relationship to the Child:
f. Notifier Signature:
5. Certificate Issued by Hospital, Physician or Midwife (If none, then names, addresses and contact information of two witnesses other than the mother or the father)
6.Space for Remarks and Comments
---
Please share any thoughts, ideas, or comments in the discussion below!
2
Comments
Mother and father fields will need to be optional, to cater for children that have been abandoned by their parents, or have lost their parents.
We might want to add biometric fields. The specifics of this will vary depending on each team's solution and what they measure. Examples for consideration include, but are not limited to, the following:
* portrait photo
* iris scans
* fingerprints
* DNA analysis data, and
* other biometric parameters that are unique to an individual.
All of these fields could be made available (each being optional).
We want to ensure this data is secure and encrypted.
The fields need not store actual raw data for a given biometric. Instead, an algorithm might be used to derive a unique (hash) value. This might be preferable on grounds of privacy (especially with regard to DNA).
The algorithm would have to provide unique values and be robust enough to cater for changes in the individual's corresponding biometric as they age (e.g. cataracts partially obscuring an iris image; damaged fingers obscuring fingerprints; facial and hair changes; epi-genetic changes).
1. The fields above do not include any statistical information, which is a key component and value driver of civil registration (see https://crvsgateway.info/What-are-vital-statistics-~306). It would be ill-advised to include the full set of UNSD recommended statistical fields as that would be prohibitive to form completion, but I would recommend making the choice of fields part of the innovation challenge i.e. Question: which set of fields can be demonstrated to be (i) realistic to capture at scale and (ii) the best to maximize the value for policy making?
2. There is a danger of being too prescriptive if we define the set of fields in terms of current laws. We should allow for greater information by describing the information to be gathered in terms of its purpose. For example, basic biographical information of the child would obviously mean name, sex, DoB etc. Information sufficient to prove the uniqueness of the child could be done in a number of ways and it should be left to the XPrize applicant to determine the most efficient and cost-effective way of doing this. This might be details of the notifier or document from the hospital, but there might be other ways...
3. Details of the father should not be mandatory. This can cause discrimination towards women where children are born out of wedlock or are the result of rape etc.
@duffus75 Ed, can you expand a bit on your 1st two points? On the first one, do you mean that States would be interested to collect additional information on demographics and social characteristics through the birth notification system? What would be the most common examples? And would these be necessary for the purposes of notifying the authorities of the birth and providing the needed information to register the child and produce a birth certificate? For the purposes of this competition, how would it be different than requiring that the system/solution has the ability to add additional fields (which is sort of a given)?
On your second point, there's been a change in the direction of the challenge which will now replace the field testing with testing with a dummy database. This means that we need to be prescriptive to then test for accuracy against data and in light of different laws (or rules for the fields and their aggregate). Having said that, it would be very interesting to be able to add competition components, such as bonus prizes or elements, that would incentivize what you are mentioning. On the specific point of the notifier, there has to be someone who's doing the notification and there are the classical examples of who those agents are. But what could be an alternative to a human agent doing the notification?
So, I think that collection of DNA in situ (e.g., at a refugee camp) -- which is now quite possible with portable sequencing technology (nanopore, MinION, etc.) -- should be eschewed. You have mentioned iris scans (and I have previously mentioned ear morphology photography/prints) as likely biometrics; I think we should stay (if utilized for the offical ID) with these for now.
*this is known as 'forensic genealogy' and has been recently used successfully to track down and arrest the 'Golden State Killer' by running DNA sequences collected at his crime scenes through public genetic databases such as GEDMatch, using a procedure known as 'identity-by-descent' (IBD), wherein key segments of DNA indicate shared ancestors, etc. This long-sought criminal was identified by contacting his family members (who were unaware of their relative's crimes) through the website and obtaining family member information which was then used to track down all members of the family and eliminate each one as a suspect.
I agree, we must be very careful with all applications that use DNA data.
Using iris, fingerprint or other (non-DNA) bio-metric data does avoid those DNA issues.
Previously I've hinted that we might want to go even further with bio-metric data and never store any raw bio-metric data on any computer, server or other IT device. [On the assumption that every device can be hacked either directly or indirectly via human factors.]
I would think the greatest innovative component to (potentially) arise from this XPRIZE would be the creation of an algorithm that immediately converts the read bio-metric data into a unique value (or hash). Future authentication of an individual would again convert a user's current bio-metric to a hash and this would be compared against the original hash to see if they match (and hence authenticate the user).
A similar technique has been used to authenticate passwords on login. However, the innovative challenge here is creating an algorithm that can authenticate the correct user when part of their original bio-metric has changed later in life for some reason (e.g. aging, accidental damage, or cataracts (iris scan)).
As of today, nearly all of the well known bio-metrics can be faked / duplicated. This is why the data should not be stored, because the owner cannot create a new set of bio-metrics once they have been compromised. Once hacked an individual is compromised for life!
New types of bio-metrics are being discovered, but with some innovative approaches those too could be compromised.
In short, to protect bio-metric data avoid saving it on any device.
Even the above hashing technique isn't a guarantee because future super-computers, quantum computers, and AI might find a method to compromise the algorithms, at some point in the future.