Sormas-project: Introduce overall person search by name [8]

[max-hzi]

Situation Description

Some health departments would like to search the whole database to see if a person is already entered into Sormas.

Feature Description

Introduce a new overall person search across the case and contact directory. Event participants should also be included in this overall search.
The suggestions of the system could look similar to the duplicate detection system. The user should be able to open a person record from there.
I am not sure where the button could be placed and would make sense, maybe at the top right on the dashboard within a drop-down menu named 'more'.

Possible Alternatives

Suggestions are very welcome.

[bernardsilenou]

If a person is linked to a case (multiple), contacts ( multiple) and events (multiple), all will be presented to the user as a drop down to choose.
We can also have this feature to search for persons from the event line list (based on event id, person name, case name, ,,,). This will limit the search only to persons or cases assassinated to events,

[bernardsilenou]

• we should include all person identifiers we use on the case directory and return a table with person name, associate entity name (case/contact/event), region district, dates
• Save cache and user should be able to navigate front and back to explore each of the entities
  -We can use similar design as in #2619

[bernardsilenou]

Add a description that only person identifiers (list them) are accepted in this search field

[markusmann-vg]

• [ ] Please add a mockup of the expected person directory.

[bernardsilenou]

ok, noted, will add tomorrow

[bernardsilenou]

@markusmann-vg @MateStrysewskeSym Mockup below, please have a look and update of I may have forgotten something.

• Each row correspond to an entity (case, contact, event) that the person is associated to. Multiple rows per person
• The captions: region, district, report date, quarantine end, disease corresponds to those of the entity that the person is associated to. e.g responsible region of contact if entity is a contact.
• Filter should be activated for all columns on table as on case table
• The main search function should take any of the person identifiers that we already use in other directories
• Activate search only after clicking on apply filter icon
• Filter should correspond to entity state active/archived/all
• Clicking on person id should open the person form within the entity
• Clicking on entity id should open the entity form
• Save cache/ search result such that users can navigate back to person directory in case the first entity opened is not the right one
• Add filter for disease and date interval (entity report date only) on the main panel as on case directory (no space to add in mockup)

[Johannes-Schmidt-GA-RT]

I thought it might look something like this

On the first page of "Personen" there must also be a search function like under cases or contacts.

The "Person" should contain the personal data as well as all events, cases and contacts of the person.
From there you can switch to the person's cases or contacts.
And there should also be an posibility to switch from an case or contact into the person.

[bernardsilenou]

@Johannes-Schmidt-GA-RT thanks for this nice design, it looks good.

• Please can you also add a mockupf on haw the person directory would look like? ie view of many persons at a time
• An option can be to combine both designs

[Johannes-Schmidt-GA-RT]

@bernardsilenou I Think it should look like the case or kontact directory just with some less filters. There shuould be filters for:

• Name
• Person-ID
• Birthdate
• Adresss
  

Maybe somthing like this

[bernardsilenou]

@Johannes-Schmidt-GA-RT this your last mockup is similar to what we initially had in mind. The limitation that i see is that for each person in the table (there can be many people with the same name), you have to open each person to see the associated entity (case, contact event). That is why we came up with the other design to show the information contained in the 2 mockups you proposed on one form.

Will it be possible for you, and some of our team members to come up with an updated version?

[Johannes-Schmidt-GA-RT]

I don´t think that this is a problem. When i search for a person i can identify it with the adress or birthday. When i´m looking for an special case or contact, i can find it in the case/contact directory.
I am happy to support you with the "development". For further coordination you can contact me by email or phone.

[ChristopherRiedel]

Hi @Johannes-Schmidt-GA-RT, your mockups look really good. But it would be nice if they were in English next time, because many people here don't know German and therefore can't join in the conversation or can't implement the issue based on your mockup. Thanks a lot in advance.

[Lucas-Walter-GA-Tuebingen]

I think the Option Johannes Schmidt included here in this topic is relevant for multiple health authorities in Germany. We at Tuebingen are searching also for an digital solution for the covid19 contact person tracing and the option to filter for persons not only for cases and contact persons is a missing part in SORMAS to work more efficient with it.

[kwa20]

We discussed how to integrate and develop a general person entity in Sormas. We suggest that this should be done on a step by step basis since this will be a larger endeavour. According to this issue, the integration of a person search resembles the first step and requires the development of a person directory.

This directory displays persons in the database and provides an overview of their person information. Filters above the list should allow filtering and searching by personal identifiers. Furthermore, I suggest to be able to filter the directory by cases, contacts and event participants, meaning that persons will be displayed that have at least one entry in the associated entity. The displayed numbers on the filter button will most likely differ from overall numbers in respective directories but hopefully emphasize how we differentiate between persons and cases/contacts/event participants. This often seems to be hard to understand by users thus far.

Clicking on the Person ID should open respective person forms. These forms basically resemble the ones that already exist in existing entities. These forms should provide the linkages to entities and allow navigation to them by clicking the respective ID. When linkages are abundant (theoretically one person can have many cases/contacts/event participants) a button to redirect to the filtered directory would be helpful as seen in events. The linkages should also be shown elsewhere in duplicate forms (e.g. case person/contact person).

Further steps and refinements are mentioned in this issue (#3560 ).

@JonasCir @bernardsilenou If I have missed anything please feel free to comment and correct.

[bernardsilenou]

@kwa20 your last comment is perfect for this issue.
@Johannes-Schmidt-GA-RT if this last refinement OK for you? We plan to do further refinement latter as Kay mentioned

[Johannes-Schmidt-GA-RT]

@kwa20 @bernardsilenou Thats exactly what I was looking for. I just miss the Buttons to create new cases and contacts.
I think that's important because you don't have to create a new case / contact with all personal data. We also have the problem that the duplicate check sometimes does not work. I hope we can see this in the next sprint :-)

[kwa20]

@Johannes-Schmidt-GA-RT Since this will be the first step, you can find more detailed mock-ups in issue #3560.

[markusmann-vg]

Person directory will include (Distinct Persons) with the following columns:
PersonID | First Name | Last Name | Birthday | Sex | Phone Number | Zip | City | Address | Link to latest reported entity

(E.g. Clicking on the PersonID => open the person,
If the latest reported entity is a case, you will be redirected by clicking on the link to that case.)

@kwa20 Please consult @MateStrysewske for further refinement

[bernardsilenou]

@markusmann-vg, @MateStrysewske

Person directory will include (Distinct Persons) with the following columns:
PersonID | First Name | Last Name | Birthday | Sex | Phone Number | Zip | City | Address | Link to latest reported entity

Suggested ordering and added some missing variables from Kay Mockup. On smaller screens, i think it would be good to have Link to "latest reported entity" on the left so that users see it always and can directly click on the uuid and open the entity without opening through the person form itself.

PersonID | Link to latest reported entity| First Name | Last Name | Birthday | Sex | Phone Number | email| Zip | City | home Address (region) may be not needed on table but needed as a filter | district| community| external id

(E.g. Clicking on the PersonID => open the person,
If the latest reported entity is a case, you will be redirected by clicking on the link to that case.)

This means we have to create another issue for the other refinement, right ?

@kwa20 Please consult @MateStrysewske for further refinement

[kwa20]

Can we please split the address into street and house number? This will then be consistent to what we have on case and contact directories and allow independent sorting.

@bernardsilenou I'd also prefer the external ID next to the person ID because they're directly related and the link to the latest reported entity can be at the end of the list as Markus mentioned

[bernardsilenou]

Dear All,
I read a second time and wish to say that we had series of meetings with the GE users and a vital need is that,
by looking at the person form, they should be able to see all the associated un-archived entities (cases, contact, event) linked to the person.
Showing just the last reported entity will be hiding some information from the users since a person can be at the same time a contact (to another source case person), event participant and even cases (co-infection).

I would suggest that we work with this minimum requirement even if it cut across 2 sprints?

I am talking about this mockup from Kay which we can still adjust but keeping the same information

@MateStrysewske @kwa20 Whats your opinion please? Should we have a call to discuss this?

[kwa20]

@bernardsilenou As far as I understood, "link to latest reported entity" will be shown in the directory. In the person form itself, all linked entities should be visible.

[bernardsilenou]

@kwa20
I also think the @markusmann-vg specification to add "link to latest reported entity" to the person directory is vary good.
I may have also misunderstood his specification by thinking that the person entity view would not include link to other entities.
I think we are on the same page and just have to wait to get the final say from @markusmann-vg

[Marko-ilmkreis]

Thanks for your work so far. We also would agree that we need a person directory. As far as I understood is, at the moment, the person entitity still in the database, even if the case/contact/event participant is deleted. In my opnion it bring problems with the data protection rules if we still keep datas of deleted cases/contacts/ event participants.

[kwa20]

Thanks for your work so far. We also would agree that me need a person directory. As far as I understood is, at the moment, the person entitity still in the database, even if the case/contact/event participant is deleted. In my opnion it bring problems with the data protection rules if we still keep datas of deleted cases/contacts/ event participants.

@Marko-ilmkreis That is correct, there is a separate deletion concept being worked on that will take care of these concerns.

[Marko-ilmkreis]

@kwa20 @bernardsilenou When, hopefully soon, the new person directory is introduced thre should be also a duplicate search like in cases. I guess that there will be a huge amount of duplicate persons.

[kwa20]

@Marko-ilmkreis The already existing person duplication recognition should work as usual with some refinements and we also plan on having a "merge duplicates" option for persons then. Feel free to have a look at #3560 for further refinements.

[MateStrysewske]

Out of scope for the first version: Showing and toggling between displaying and hiding disease-specific fields when viewing a person

[MateStrysewske]

• [ ] Discuss how to handle pseudonymisation (could have a major impact on performance as well)

[Candice-Louw]

@bernardsilenou @kwa20 - any input on the pseudonymisation or related aspects, perhaps please?

[kwa20]

@MateStrysewske @Candice-Louw For the first step integration I suppose we should ,by default, only show persons that have at least one linked entity in the users jurisdiction or if the user is also the reporter. We should also let the directory load lazily because it will have many entries to improve performance.

This will work for the first step integration because no person can stand alone in the system. However, for next steps in #3560 we need to discuss how to handle pseudonymization when persons could possibly stand alone in the system @bernardsilenou.

[bernardsilenou]

@MateStrysewske Thanks fro raising this point. We did not think about it.
I agree with @kwa20 and would add more details.

• For now, persons are linked to cases, contacts, event participants and soon there would be immunization.
• When a user search for a person, then we compare the access rights (write or read only) + pseudonymization between user and entities of the person.
• On the person directory, we always show the full view of the person if user has a read/ write access to at least one of the entities
• If 1. is false and user has pseudonymization access to at least one of the other entities of the person. This is the tricky part. I would suggest that we still show the name of the person on the person directory for now. This is the same challenge we have when a user who has pseudonymization access to a case search for the case through the case directory using the name of the person.
• If 1. and 2. are false, then we do not show the person even if the person exist in the database

I have adjusted the ordering of columns using @kwa20 comments. Since personid and link to latest reported entity are
reactive links, I kept them on the left. Hope this is fine by you?

PersonID | Link to latest reported entity| external id| First Name | Last Name | Birthday | Sex | Phone Number | email| Zip | City |
home Address (region) may be not needed on table but needed as a filter | district| community| postcode | city | street | house number

[bernardsilenou]

Out of scope for the first version: Showing and toggling between displaying and hiding disease-specific fields when viewing a person

I also think we do not need to border about the disease specific filters in this ticket. Users just need to see the summary of the entities linked to the person (right box) and should be able to navigate to any of them by clicking on the uuid

[bernardsilenou]

Our wish is that we get this ticket done in 1.54

[bernardsilenou]

• When user then opens the person form, then all rules apply: access rights (write or read only) + pseudonymization

[Marko-ilmkreis]

Our wish is that we get this ticket done in 1.54

We would really appreciate that as our colleagues currently struggling the problem to find persons which are event participants. There is no search for person in the events view and they had to go through every possible event to find a person.

For the background: Our health department is doing mass tests if a case is in a retirement home, school class or similar. They then create a event for that and import the persons into it.