Attention!
The interface to subscribe, receive, and notify events is not described here. It has not been decided if it is worth defining a neutral interface abstracting the broker and making the CR & CI provider independent from the broker selected by the integrator, or if it is better to use the native interface of the broker.
The first solution means an abstraction of the broker must be implemented, adding possible source of bugs or failures.
The second solution means the CR or CI cannot be simply replaced by a CR or CI from another vendor without some adaptation to use the interface of the broker.
To all reviewers: please comment and propose on this topic.
When exchanged in the services described in this document, the persons attributes will apply the following rules:
Person AttributesAttribute Name | Description | Format |
---|---|---|
uin |
Unique Identity Number | Text |
firstName |
First name | Text |
lastName |
Last name | Text |
spouseName |
Spouse name | Text |
dateOfBirth |
Date of birth | Date (iso8601). Example: 1987-11-17 |
placeOfBirth |
Place of birth | Text |
gender |
Gender | Number (iso5218). One of 0 (Not known), 1 (Male), 2 (Female), 9 (Not applicable) |
dateOfDeath |
Date of death | Date (iso8601). Example: 2018-11-17 |
placeOfDeath |
Place of death | Text |
reasonOfDeath |
Reason of death | Text |
status |
Status. Example: missing, wanted, dead, etc. | Text |
This section describes the messages exchanged through notification. All messages
are encoded in json
. They are generated by the emitter (the source of the event)
and received by zero, one, or many receivers that have subscribed to the type of event.
Event Type | Message |
---|---|
liveBirth |
Example: {
"source": "systemX",
"uin": "123456789",
"uin1": "123456789",
"uin2": "234567890"
} |
death |
Example: {
"source": "systemX",
"uin": "123456789"
} |
birthCancellation |
Example: {
"source": "systemX",
"uin": "123456789",
} |
foetalDeath |
Example: {
"source": "systemX",
"uin": "123456789"
} |
marriage |
Example: {
"source": "systemX",
"uin1": "123456789",
"uin2": "234567890"
} |
divorce |
Example: {
"source": "systemX",
"uin1": "123456789",
"uin2": "234567890"
} |
annulment |
Example: {
"source": "systemX",
"uin1": "123456789",
"uin2": "234567890"
} |
separation |
Example: {
"source": "systemX",
"uin1": "123456789",
"uin2": "234567890"
} |
adoption |
Example: {
"source": "systemX",
"uin": "123456789",
"uin1": "234567890"
} |
legitimation |
Example: {
"source": "systemX",
"uin": "987654321",
"uin1": "123456789",
"uin2": "234567890"
} |
recognition |
Example: {
"source": "systemX",
"uin": "123456789",
"uin2": "234567890"
} |
changeOfName |
Example: {
"source": "systemX",
"uin": "123456789"
} |
changeOfGender |
Example: {
"source": "systemX",
"uin": "123456789"
} |
updatePerson |
Example: {
"source": "systemX",
"uin": "123456789"
} |
newPerson |
Example: {
"source": "systemX",
"uin": "123456789"
} |
duplicatePerson |
Example: {
"source": "systemX",
"uin": "123456789",
"duplicates": [
"234567890",
"345678901"
]
} |
Note
Anonymized notification of events will be treated separately.
Attention!
Should the UIN be mandatory? What happens when a person has no UIN?
A list of:
Matching Error ObjectAttribute | Type | Description | Mandatory |
---|---|---|---|
attributeName |
String | Attribute name (See :ref:`person-attributes`) | Yes |
errorCode |
32 bits integer | Error code. Possible values: 0 (attribute does not exist); 1 (attribute exists but does not match) |
Yes |
Attribute | Type | Description | Mandatory |
---|---|---|---|
attributeName |
String | Attribute name (See :ref:`person-attributes`) | Yes |
operator |
String | Operator to apply. Possible values: < , > , = , >= , <= |
Yes |
value |
string, or integer, or boolean | The value to be evaluated | Yes |
Attribute | Type | Description | Mandatory |
---|---|---|---|
code |
32 bits integer | Error code | Yes |
message |
String | Error message | Yes |