In France, most of the signals come from Health Insurance but can also be sent by other institutional partners such as national education, local authorities (town halls, departmental council, etc.). The methods currently proposed in the “TYPE OF SOURCE” variable do not meet the needs of France.
We propose to complete the modalities of the “Source Type” variable with the “institutional partner” modality. The selection of this modality then opens a new variable which specifies the partner: National education, Health insurance, Health establishment, Medico-social establishment ... This new variable can be configured by each user from a repository table loaded in the "Configuration" part of SORMAS.
@ftavin @bernardsilenou @olivierleuci
@ftavin @bernardsilenou
I changed this issue after our discussion this week
@carolinverset we need to come up with a mocup on how this should look like
@bernardsilenou @carolinverset
In the event screen, if "Institutional partners is selected, another combobox is available beneath it like in this mockup :

The propositions of this combobox are listed in a new postgresql table and can be managed in a new page in the configuration section of the application (you should be able to add/modify values in this table but not delete one that is already used for an event)
@MateStrysewske any comment? servers that do not need this additional variable will not see it in the first place
@MateStrysewske We plan to work on this issue for 1,53, Please can you comment is there is something that can be improved?
In the near future, I think we may also use a similar design for the "contact identification source" variable.

@bernardsilenou @ftavin I'd think it should be fine to display this by default, irrespective of the country. If a country has no institutional partners, they should be able to just ignore that value (since it's not a new field, but just an additional option in an already existing dropdown). What do you say?
Concerning the possibility to configure the values - I don't know whether having the configurations in the database is the optimal approach. I'd like to discuss this internally once we have time for it, but I'm not sure when this will be the case. Is the configuration part absolutely needed for this feature or could we move it to a separate issue that can be implemented at a later point in time?
@MateStrysewske We though of making the variable configurable because other countries may need to have other options that are not mentioned here.
If you do not mind, we can just hard code this variable. This will also be beneficial to the long term goal when we will have the flexible from designer.
So, @MateStrysewske are you fine if we hard code it?
@bernardsilenou Yeah, I'd prefer that for now until we've discussed how we want to approach the topic of configurability for these things.
@ftavin Fine with you also? makes the work easier.
I'm not sure that the list provided by @carolinverset is exhaustive. If we hard-code it, the complete list should be provided has soon as possible ! (@alexandre-gille already started implementation on this one)
The list of institutional partners in France are as follows:
Hope this list can be considered generic enough to match all countries?
@ftavin @MateStrysewske @bernardsilenou : what do you think about ?
@carolinverset ok for us
do you need the full sentences (with informations in the parenthesis) or just "National education", "Health establishment", ... ?
@ftavin
No, no need to specify the elements in parentheses. I specified them to explain who our institutional partners were. We then manage the translations in the crowding file
@ftavin @carolinverset tomb-up to all the comments
@carolinverset @bernardsilenou should this new field be reported to the event directory (and basic export) ?
if so, should it be :
if not so should it be added to detailled export ?
@carolinverset @bernardsilenou
@MateStrysewske is asking in the review :
There should probably also be a srcInstitutionalPartnerTypeDetails text field in case "Other" is chosen (to allow users to specify it); we have this pattern for all other enums that allow the selection of "Other"
Can you confirm as soon as possible ?
@ftavin @bernardsilenou
Yes, this is a good idea. It has the advantage of clarifying the information and also of reproducing the behavior of SORMAS from other parts of the application
Tumb-up !
Verified issue on SORMAS Version: 1.53.0-SNAPSHOT