[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Health-dev] About name on Party

From: Cédric Krier
Subject: Re: [Health-dev] About name on Party
Date: Wed, 19 Aug 2015 16:15:17 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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.

> > 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 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 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 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).

> > - 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.

> 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].
The identifier which could be reused by GNU Health for the

Cédric Krier - B2CK SPRL
Email/Jabber: address@hidden
Tel: +32 472 54 46 59

Attachment: pgps9zkSTpsGs.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]