Re: [Health-dev] About name on Party

[Luis Falcon]

Hi there !
On Wed, 19 Aug 2015 16:15:17 +0200
Cédric Krier <address@hidden> wrote:

> On 2015-08-19 14:34, Luis Falcon wrote:
> > On Tue, 18 Aug 2015 19:52:05 +0200
> > Cédric Krier <address@hidden> wrote:
> > >
> > Good to resume the discussion we started a couple of weeks ago :)
> > 
> > When dealing with (physical) person demographics, we need to have a
> > data model that allow us to interact with other systems. 
> > Today GNU Health not only deals with people and health information
> > systems, but with civil offices (birth and death certs), and other
> > entities.
> > 
> > Today, most documents and forms (passports, civil certificates,
> > national IDs, clinical records ...) include different attributes
> > for the name (First, given, middle, last, mother's maiden name) ,
> > and it's important that we can easily can interchange information
> > with them.
> 
> Of course, but being interchangeable doesn't mean we must copy their
> faulty design. Moreover if there are no need for such interchange why
> will we have to get the bad database schema.
> 
Agree. And I also think that "standards" are heavily biased by western
culture. But if we want to exchange data with these systems, we need to
map elements. So if they ask GNU Health for HumanName.family , or
HumanName.given, GNU Health / Tryton should be able to map them.

> > > So for me, there are two options to make GNU Health works better
> > > all around the world:
> > > 
> > > - Remove lastname field because we don't need it.
> > > 
> > This would break interoperability .
> > 
> > As a matter of fact, in HL7, the human name elements should not
> > have spaces HL7[1].
> 
> No, it is only the parts that should not have (which I think is wrong,
> there are some people with composed given name without hyphenate),
> indeed there is the field text which is exactly the same as the
> Party.name. Moreover, here we can even see that they designed the
> format to allow many family and given names. So for now, the GNU
> Health model is not fully interchangeable as it can not manage many
> family names.
> 
> > Besides that, having all name elements in a single
> > field separated by spaces/commas, would need yet another convention
> > to know where is the given, last, middle name in the same field.
> > Would not work.
> 
> No, I really don't want to add any convention on the Party.name field.
> People must enter the data that represent their fullname.
> After that, if the system needs it, we should be able to add data for
> many family names (without forget that Iceland doesn't have or at
> least they will not put it in Party.name) and the same for given
> names.
> 
> I also like the prefix/suffix of the HL7 which could be just one more
> type of data (probably ordered).
Me too.
> 
> > > - Change lastname field for a (or many) field(s) for which the
> > > usage will be clearly defined like: "called name" for sending
> > > mail.
> > > 
> > 
> > We can study this option. The problem I see with this method is
> > that it would take a toll on usability and operator time to enter
> > data (selecting the name element type ). We could minimize the
> > impact by having default selection values depending on the region.
> 
> Of course you could pre-fill such field using some on_change method
> but remember that in my link, they clearly says it is very hard to
> made it right. But it is not a big issue as anyway the user could
> edit them.
> 
> > We already have the "Alias" field for "called name" or nicknames.
> 
> So this field could be moved into this list of parts.
Yes. If we use the functionality on the module party_name_parts
that you refer, would fit very well there.

> 
> > At the end of the day, as with many other things, it's not always
> > easy to marry "standards" and cultures. Human naming conventions
> > and naming order is an anthropological matter, so localization
> > would be important for the "front-end", yet a universal "back-end"
> > should allow to exchange the information with different systems
> > around the world. 
> 
> Be careful that localization doesn't mean you will have to deal with
> single culture people.
> 
> I have more and more the feeling that this changes could be done in a
> Tryton module (party_name_parts) and it could have a similar design
> with the identifier change [1].
That would be great, and would allow maximum flexibility and
interoperability, as we can see in some examples[1]. We would have to
work on making it easy to enter the name elements. 

Something similar to the model of contact mechanism would work for name
elements.

How about the current party.name ? We're using it both for physical and
non-physical persons (like companies). When is a person, we also should
to be able to assign it an element type (first, given, ... ).

I propose taking the HL7 FHIR HumanName [2] data type as the base for
the party_name_parts. The element "use" and "text" elements will be very
helpful to display the full name format and order, depending on the
culture and context.

The party_name_part.text can be a function field and generate the
name format automatically, for example, based on the country.

> The identifier which could be reused by GNU Health for the
> alternative_ids.
Yes. I looked to your code, and we could use the new party.identifiers
for the person's alternative_ids.


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

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

pgpaaQ4NkTwJc.pgp
Description: OpenPGP digital signature