taskGNU Health - Tasks: task #13769, Flexible name on party (person)

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #13769: Flexible name on party (person)

Submitter:  Luis Falcon <meanmicio>
Submitted:  Fri 09 Oct 2015 07:04:48 PM UTC
   
 
Should Start On:  Fri 09 Oct 2015 12:00:00 AM UTC Should be Finished on:  Sun 22 Nov 2015 12:00:00 AM UTC
Category:  Data model Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  meanmicio Percent Complete:  100%
Open/Closed:  Closed Release:  2.9.0
Module:  health Component:  None

Jump to the original submission

Wed 16 Dec 2015 11:01:31 PM UTC, comment #17: 

I'm sad because at the end this is still a design based on the fact the people has first name and family name (not following my email that initiates those changes).
Also it still keeps the introduction of a field lastname on party which is against the initial design of Party.name from Tryton.
Finally the design of PersonName is very very complex, I'm not sure it will be used and so users will keep using the previous fields.

Cédric Krier <cedk>
Wed 16 Dec 2015 07:45:49 PM UTC, comment #16: 

Hi team !
The task main functionality is done. Brief summary

- Multiple names and uses (official,nickname/alias, anonymous,usual, maiden.. )  for a single person
- The representation selection field allows to give the name format for each person ("Family name(s), first", "Prefix Given Family, Suffix", ... ) for each person. This is quite useful for different nationalities / cultures, where the name representation format varies significantly.
- The list of person names are at the "Identifiers" page on the Party form.
- It's is possible now to search for a particular individual or patient using any of the given names, name types, and IDs.
- The given name / family name are still in place for faster encoding, and compatibility with the Tryton party name.
- Writing the main given and family names in the main person (party) form automatically creates / updates the official name.
- Name representation format is valid across the reports and fields in GNU Health, since it's implemented at the get_rec_name method.
- The PersonName model is heavily based on HL7 FHIR standard. Big plus for interoperability.

That's pretty much it for a summary :) .

Many thanks to all of you for the suggestions ! Time to test now :)

Luis Falcon <meanmicio>
Group administrator
Mon 14 Dec 2015 07:42:13 AM UTC, comment #15: 

I think it is too complex to use a function field, for me the Party.name is the official 'text' value. So it is better to just store it there instead of the list of PersonalName.

Cédric Krier <cedk>
Mon 14 Dec 2015 07:12:19 AM UTC, comment #14: 

Hi Cedric !

It's great to know that the party name field is no longer required.

As I suggested a while ago, we could use a functional field for the "text" field in the rec_name.

For the party name, it can write the values of the given name on the "official" type, but still would be hidden if we use the functional field.

On Sunday we should have online the testing version of the upcoming 3.0 on the community server, so we can check how good/bad is the encoding time of the name

Suggestions are welcome !

Luis Falcon <meanmicio>
Group administrator
Sun 13 Dec 2015 09:20:49 AM UTC, comment #13: 

FYI, the Party.name in trunk is no more required.

I think it is wrong to compute or hide the Party.name because this name could be different from any of the parts.
Also I think we should add a deprecation warning on the usage of Party.lastname as for me it is only kept for backward compatibility and it will be removed in the future.

About the PersonName design, I think we don't read the same from the HL7. For each 'use' value, it should have a 'text' field, a list of 'family', 'given', 'prefix' and 'suffix'.
Of course such design will make the form quite complicate, I think we can simplify by saying that we add a single one2many with a field type ('family', 'given', 'prefix' and 'suffix') and a field value. This single field will represent the official 'use'. If someone wants to be able to add different 'use', he could add other one2many fields.
Also in this case the 'text' from official 'use' will be the Party.name

I think this example page is quite informative: http://www.hl7.org/implement/standards/fhir/datatypes-examples.html#HumanName

Cédric Krier <cedk>
Sat 12 Dec 2015 06:51:12 PM UTC, comment #12: 

Hi, team !

At this point, we have the way of having multiple person names for a single individual, as well as different uses and name representation formats.

The final touches would be:

- Single source : When name of type "official" is updated, the party.name attribute will also be updated (with the person_name.given attribute. If the family name is updated, the party.lastname will also be updated.

- The party.name is a Tryton required field, so we will leave it like that keep compatibility. This requires to update the value whenever the PersonName official given name is updated (should be minimal)

- Have a functional field in the main party form, to display the person name as in rec_name,  with the format used in name_representation.


- The party.name will become invisible and read-only. The new place to enter the person names will be in the identifier section.

- The party.lastname will become a functional field (it will no longer exist at DB level) and its value will be retrieved from the PersonName family field.

- In the register section, the current DB party and lastname will be copied or update PersonName . This will happen only if there is no person name of type "official".

Let me know your thoughts and have a great weekend !

Luis Falcon <meanmicio>
Group administrator
Sat 12 Dec 2015 01:14:28 PM UTC, comment #11: 

Improve naming formatting options.


Luis Falcon <meanmicio>
Group administrator
Fri 11 Dec 2015 07:02:09 PM UTC, comment #10: 

changeset 2226:6c01efd232c6 tip

- Use the name format representation of the official name
- Use a selection field with a predefined name representation options

Luis Falcon <meanmicio>
Group administrator
Fri 11 Dec 2015 07:00:02 PM UTC, comment #9: 

Thanks.
In any case, since that column was to be dropped, the workaround was OK.

best,

Luis Falcon <meanmicio>
Group administrator
Fri 11 Dec 2015 04:57:53 PM UTC, comment #8: 

Because alias is a method of Table.
In such case, you must use: Column(table, 'alias')

Cédric Krier <cedk>
Fri 11 Dec 2015 04:46:16 PM UTC, comment #7: 

Move the person alias on the party to the PersonName model of type "nickname", and drop the field name.

 
PS: I had to rename the "alias" attribute / field name to "nick", on the party, since Python SQL tracebacked with this party.alias.

Luis Falcon <meanmicio>
Group administrator
Fri 11 Dec 2015 01:44:23 PM UTC, comment #6: 

changeset 2224:6993f32d7154 tip

health : Allow searching for any alias(nickname), temporal, oficial person name

Luis Falcon <meanmicio>
Group administrator
Thu 10 Dec 2015 08:16:17 PM UTC, comment #5: 

Initial work done on changeset 2221:4eabcf6cbf1b

http://hg.savannah.gnu.org/hgweb/health/rev/4eabcf6cbf1b

Luis Falcon <meanmicio>
Group administrator
Thu 10 Dec 2015 08:12:48 PM UTC, comment #4: 


- Add initital PersonName class and views,
- O2M editable field to hold the different party names and uses (official, nickname, maiden, ... )
- Fields are on the Party Identifiers page, displayed only for parties that have the is_person attribute set.
- Added a field that sets the format of the person name. This will be used by the rec_name method on the party.

TODO Next :

- Fill in the party name with the official name
- register : update the official name field with the current name and lastname.
- Allow to search by any of the possible person names .
- Remove the lastname from the view


Luis Falcon <meanmicio>
Group administrator
Sat 10 Oct 2015 04:48:25 PM UTC, comment #3: 

I don't think so. For me, the way the name of a person is displayed depend on the person not of the country of the institution or the person.
I'm pretty sure that the current design of Tryton (simple free format char field) is the best option to manage the format of the name.
The extra list of the name parts should only be optional and only for specific purpose.

Cédric Krier <cedk>
Sat 10 Oct 2015 04:38:04 PM UTC, comment #2: 

Having this feature as a standard Tryton module would be great !

We can discuss the best way to approach to the development of it, to both include it on GNU Health 3.0, yet keeping in mind that it could become a standard Tryton module.

From the functional point of view, I was thinking that we could even have the display name and probably views dynamically based on the country of the institution or person.

Thoughts are most welcome.

Best,

Luis Falcon <meanmicio>
Group administrator
Fri 09 Oct 2015 08:10:49 PM UTC, comment #1: 

This could be done as a proposal for a standard Tryton module.

Cédric Krier <cedk>
Fri 09 Oct 2015 07:04:48 PM UTC, original submission:  

We should allow more flexibility in order to encode the patient names and order, depending on the country / language of the institution.

We will be incorporating a model that allows different types of names, and a contextualized representation of it, based on HL7 FHIR HumanName [1]

There is an interesting thread that Cedric started some weeks ago [2] on this matter, and that we expanded at IWEEE.

1.- http://www.hl7.org/implement/standards/fhir/datatypes-examples.html#humanname

2.- https://lists.gnu.org/archive/html/health-dev/2015-08/msg00024.html

Luis Falcon <meanmicio>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by cedk (Posted a comment)
  • -email is unavailable- added by meanmicio (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-12-20 meanmicio StatusReady For Test Done
        Open/ClosedOpen Closed
    2015-12-16 meanmicio StatusIn Progress Ready For Test
        Percent Complete90% 100%
    2015-12-16 meanmicio Percent Complete80% 90%
    2015-12-11 meanmicio Percent Complete50% 80%
    2015-12-10 meanmicio StatusNone In Progress
        Percent Complete0% 50%
    2015-10-09 cedk ReleaseNone 2.9.0

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code