ЕСОЗ - публічна документація

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

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:

  • ACTIVE

  • INACTIVE

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.

  • No labels