| Table of Contents |
|---|
...
| Table of Contents |
|---|
Option 1
Prepersons stores in the same table as persons - MPI.persons. Thus all constraints should be removed from this table except status field. For prepersons needs will be added:
external_id field of varchar(1000) type - external identifier of preperson in MIS (also can be used as note?)
unidentified field of bool type - needed to specify if person identified or unidentified. Helps to implement separate logic for prepersons, for example, inform user who gets person via API that he recieve preperson (because in Get person API will be used the same schema on response as for the identified person
Option 2
Prepersons stores in separate table - MPI.prepersons
Scema
...
Table Description
prepersons
Name | Type | M/O | Description and constraints | |
|---|---|---|---|---|
1 | id | uuid | M | Identifier of preperson (PK) |
2 | person_id | uuid | O | Reference to person (if preperson becomes identified) |
3 | external_id | varchar(1000) | M | External identifier of preperson in MIS. Also can be used as note? |
4 | status | varchar(10) | M | Status of the preperson. Allowed statuses:
By default is NON_IDENTIFIED |
5 | is_active | bool | M | Technical flag. By default is true |
6 | inserted_at | timestamp | M | Insert date and time |
7 | inserted_by | uuid | M | User id who inserted the entry |
8 | updated_at | timestamp | M | Update date and time |
9 | updated_by | uuid | M | User id who updated the entry |
Option 3
MPI not used as storage for prepersons. Prepersons will be store in eHealth as patients (mongo db) that have no related person in MPI.