EntityNameParts

[system]

I will come back to the answers I got about II later.
Thanks for this.

I have another question: about EntityNamePart in the CEN-standard.

There seems to be no way to tell if a certain namepart actually are
name-initials.

f.e.
Sometimes people often have more firstnames.

Often they have a name that is used for casual contacts, and they have names
which are in their passport, their official firstnames, which are often long
names.

Often, these long names are only known by initials

Now I am extracting data from a local GP-system, and there is stored the
shortname (f.e. Johnny) and the initials J.B.
His friends call him Johnny B. Good. The second name in that system is only
known by Initial. I have to deal with that.

Because I want to present as much information as is possible in the standard,
and I want to present the shortname (GIVEN NAME=Johnny), FAMILY NAME=Good,
and because I want to give as much information as possible, because this can
be important to identify a person, I want to add an extra entityNamePart:
J.B.
And now I am looking for a namepartType or namePartQualifier for initials.

Someone have an idea?

Thanks

[Isabel_Roman (Isabel Román)]

In my opinion this is a new namePartType, better than namePartQualifier.

I think that as namePartType is a coded simple value, you only have to add a
new code for initials...
      namePartType
     O
     CS

The standard gives you some namePartType values, but this doesn´t mean that
you cannot add others. Does it? I think that this codes (and all codes)
should be managed by a terminology server to ensure the interoperativity.
This is only my opinion of course...

Regards
Isabel Román

[USM_Bish1 (USM Bish)]

Naming conventions and methods of writing vary all over the
world. It may be difficult finding a common rule fitting all.

I thought all that the CEN/TC251 specified for Class:EntityName
was merely 'a character string' (or several entity name parts
in sequence). This is applicable for a person, organisation or
even place or an object. 'EntityNamePart' would therefore be
sub-components of the above.

But how do you define the sub-componets, as far as name is
concerned ?

There are no fixed patterns for names or naming conventions.
There are many societies where there are no 'Family' names at
all. Some have Tribe names in lieu, some with father's or
village name as 'names' somewhere wedged in the name string.
Some with just unique names with nothing else. To add to this
confusion you would then have to find sub-components for nick
names and aliases.

Bert, like your query regarding short-name and initials, I am
also curious in knowing how these name issues are planned to be
tackled ... Are there any thoughts in this direction ? Or is it
better to leave EntityName simply as a 'character string' with
no futher qualifications.

Bish

[system]

Isabel Román Martínez wrote:

In my opinion this is a new namePartType, better than namePartQualifier.

I think that as namePartType is a coded simple value, you only have to add a
new code for initials...
     namePartType
    O
    CS

The standard gives you some namePartType values, but this doesn´t mean that
you cannot add others. Does it? I think that this codes (and all codes)
should be managed by a terminology server to ensure the interoperativity.
This is only my opinion of course...

I guess, you relay the problem to another location, this way, because a terminology-server must be able to express the added code for automated processing. or do I misunderstand something?

regards
Bert Verhees

[system]

USM Bish wrote:

I will come back to the answers I got about II later.
Thanks for this.

I have another question: about EntityNamePart in the CEN-standard.

There seems to be no way to tell if a certain namepart actually are name-initials.

f.e.
Sometimes people often have more firstnames.

Often they have a name that is used for casual contacts, and they have names which are in their passport, their official firstnames, which are often long names.

Often, these long names are only known by initials

Now I am extracting data from a local GP-system, and there is stored the shortname (f.e. Johnny) and the initials J.B. His friends call him Johnny B. Good. The second name in that system is only known by Initial. I have to deal with that.

Because I want to present as much information as is possible in the standard, and I want to present the shortname (GIVEN NAME=Johnny), FAMILY NAME=Good, and because I want to give as much information as possible, because this can be important to identify a person, I want to add an extra entityNamePart: J.B.
And now I am looking for a namepartType or namePartQualifier for initials.

Someone have an idea?

Naming conventions and methods of writing vary all over the
world. It may be difficult finding a common rule fitting all.

I thought all that the CEN/TC251 specified for Class:EntityName
was merely 'a character string' (or several entity name parts
in sequence). This is applicable for a person, organisation or
even place or an object. 'EntityNamePart' would therefore be
sub-components of the above.

Following the CEN standard, an EntityName is a list of entityNameParts, which are objects having three properties:
I qoute from the CEN documentation I am using:

entityName: SET<EntityNamePart>

EntityNamePart:
- entityNamePart: The name part represented as a string
- namePartType: VALUES: family name, given name, prefix, suffix
- namePartQualifier: VALUES: preferred, birth, professional, maiden name

But how do you define the sub-componets, as far as name is
concerned ?

As I understood from the previous email concernig this question, from isabel@trajano.us.es the qualifiers in the standard document are only examples, I thought, they were rules. So, at the moment, I define the nameparts using the qualifiers provided by CEN.

There are no fixed patterns for names or naming conventions.
There are many societies where there are no 'Family' names at
all. Some have Tribe names in lieu, some with father's or
village name as 'names' somewhere wedged in the name string.
Some with just unique names with nothing else. To add to this
confusion you would then have to find sub-components for nick
names and aliases.

Bert, like your query regarding short-name and initials, I am
also curious in knowing how these name issues are planned to be
tackled ... Are there any thoughts in this direction ? Or is it
better to leave EntityName simply as a 'character string' with
no futher qualifications.

My two cents are that in fact the system is good, you need qualifiers for automated processing, same problem as with OID.

The case is, I am implementing it in a commercial product. These are only minor issues, but you run against them quick. I have no time to wait what will come out in years to follow. The questions I ask are so much at hand. In the first twenty lines of code, you run against a entityName, or a II-object.

If I start interpreting the standard for my own needs, were or when must I end doing that.
As a programmer, I am used to exact thinking, this byte is there and that is there.
I am used to standards exactly telling me what or how to do something. Thinking should already have been done.

I did not see one line of code written by someone else, that is implementing the CEN standard, and even if I did see that, how could I trust it, if there is so much confusion in minor issues. I am spoiled by open source communities were tons of source-code (often too much) are available.

Anyway, thanks for your suggestions.

Regards
Bert Verhees

[system]

Hi,

As convenor of CEN/TC251wg1 responsible for the EN13606 EHR standard I'm reading with interest the e-mail exchanges.

It is good to understand that:
- the EN13606 EHR standard is a European standard that contains several open ends (optionalities, abstract data types instead of implementable data types, etc)
- the application of the standard needs an Implementation Specification that is valid in a certain domain.

Discussions like these between implementers are very valuable.
a) they result in implementation specifications.
b) they inform the standards makers and help improve the standard.

I support Thomas idea to summarise important threads and store them in a FAQ repository.
This will help produce localised Implementation Specifications.

Gerard Freriks

ps: Hopefully an national implementation process will this year start in the Netherlands.
The proposal is to produce a Controlled Open Source Reference Implementation of OpenEHR that will be conformant to CEN/Tc 251 EN13606.
(Today the Dutch Government is discussing it)
When that implementation process starts, I expect that more discussions will arrise.

[system]

Hi,

As convenor of CEN/TC251wg1 responsible for the EN13606 EHR standard
I'm reading with interest the e-mail exchanges.

It is good to understand that:
- the EN13606 EHR standard is a European standard that contains several
open ends (optionalities, abstract data types instead of implementable
data types, etc)
- the application of the standard needs an Implementation Specification
that is valid in a certain domain.

Discussions like these between implementers are very valuable.
a) they result in implementation specifications.
b) they inform the standards makers and help improve the standard.

I support Thomas idea to summarise important threads and store them in
a FAQ repository.
This will help produce localised Implementation Specifications.

Very good, Gerard, me too, can support this idea, difficult about a not fully
completed standard is that the interfaces will change, but I can survive
that.
On the other hand, localised specifications could make international traffic
of medical data complicated, but I guess, wise men and wise women find
solutions for that.
Also will be good that CEN reports back, f.e. to this list, that there are
changes, extensions, etc.

A good idea would be if there would come a CEN specific and if possible, a
developer-oriented public website, maybe for a small fee, if necessary. This
would very much stimulate organisations and companies to implement the
standards. I wouldn't mind CC-ing my questions to two lists, if necessary in
the beginning when not many are using the new list.

Thanks for your attention

Regards
Bert Verhees

[Karsten_Hilbert]

There are no fixed patterns for names or naming conventions.
There are many societies where there are no 'Family' names at
all. Some have Tribe names in lieu, some with father's or
village name as 'names' somewhere wedged in the name string.
Some with just unique names with nothing else. To add to this
confusion you would then have to find sub-components for nick
names and aliases.

Yes, the whole gamut

In GnuMed we deal with it like this:

person:
title
name:
  lastnames
  firstnames
  preferred

Eg. a person can have any number of name records. Only one of
them can be active, eg the "valid" one at any one time, eg the
one being displayed in the EMR after the patient is called up.

Each name record consists of lastnames, firstnames and
preferred name.

Lastnames is akin to "major name", eg a "group identifier"
(family, tribe, village, you name it).

Firstnames is a collection of "minor names" all in one string,
eg the identifier within the group.

Preferred is a name the person wants to go by such as a
nickname, warrior name, etc.

Notice that title is a property of person, not of name !

Karsten

[USM_Bish1 (USM Bish)]

As convenor of CEN/TC251wg1 responsible for the EN13606 EHR
standard I'm reading with interest the e-mail exchanges.

Gerard, it is nice to have voices from the standards bodies
piping up on the list

It is good to understand that:
- the EN13606 EHR standard is a European standard that contains
several open ends (optionalities, abstract data types instead
of implementable data types, etc)
- the application of the standard needs an Implementation
Specification that is valid in a certain domain.

The Implimentation Specs (or absence thereof) is likely to have
problems if implementors divert with their 'local' inter-
pretations, making interoperability of the EHR a major issue
in the furure, when data accumulates.

Besides, as Bert put it : "I am used to standards exactly
telling me what or how to do something. Thinking should already
have been done". Surely, this makes a lot of sense.

I also echo the sentiment, that if freedom is granted for local
implimentations, the limits must be known.

When applied to demographic entities like 'EntityName' which
would be important in every record, effort needs to be made to
make it as generic as possible to cover the widest possible
spectrum of human population.

I would suggest the following components for EntityNameParts:

IndexName - viz. A single name by which the record would be
               indexed, be it Surname, family name, tribe or
         any other name the person opts to insert.

OtherNames - viz. other components of the person's name in
               full
         
AKANames - viz. Nickname, or any other name the person is
               normally known by. NULL () if none.

Initials - viz. initials for the name (to exclude accepted
               things like bin, al, etc.) This also helps in
         sequencing the name components.

A few examples to illustrate the above are:

1. 'Shaw, George Bernard (GBS), GBS'
2. 'Gandhi, Mohandas Karamchand (Mahatma), MKG'
3. 'Denzong, Mao (Mao-Tse-Tung), MD'
4. 'Minh, Ho Chi (), HCM'
5. 'Al-Busaidi, Suleman bin Said bin Mohammed (), SSMB'
6. 'Taylor, Elizabeth (Liz), ET'

With a EntityNameParts of this sort virtually every name from
any part of the world can be covered. The situation of change
in name, like for ladies after marriage (in most societies), or
the in few odd cases, like 'Cassius Clay' becoming 'Mohammed
Ali' the change would have to be reflected by versioning.

Just a suggestion (wild or otherwise) for enlarging the scope
of demographic data.

Bish
Bangalore

[thomas.beale]

You will be unsurprised to learn that we agree with USM Bish, and that names and other demographic entities should be archetyped. We don't seem to have a person name archetype yet, but you will get the idea from the location address one at http://www.openehr.org/repositories/archetype-dev/latest/adl/archetypes/openehr/demographic/openehr-demographic-address.location_address.draft.html.

I believe the approach of trying to have these as types in a RIM is problematic, for exactly the reasons Bert mentions.

- thomas beale

[system]

-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800

[system]

CEN/TC251 has an european standard: General Purpose Information Components.
These 170 GPICS are proto-archetypes that can be contrained into archetypes.

One of those is the proto-archetype for Patient demographic information.

In the institute where I work we used the GPICS to make an information domain model of one sector in Dutch Healthcare: pediatrics.
All the GPICS we needed we available.
One GPIC had to be changed in order to become usable in the Netherlands: the demographic one!

Gerard

-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800

[system]

My problem is not that there are areas which are not covered by a GPIC. But I
am not the person to judge that. I am a programmer with some experience in
medical informatics.
My problems are in the area of technical implications about how details are
worked out, or not worked out.

The problems I mention are minor issues about details. I have more then I
mentioned on this list.

And it is impossible to wait for a committee to finish discussions and being
uncertain about the outcome.

Let me see how much time the responsible committees need to address the
problems I mentioned. I can afford to wait three days. My projects are under
time pressure.

Medical Informatics in the Netherlands is a very much closed society. A lot of
people do not discuss much, do not help each other, are not honest, hide
their weaknesses and misunderstanding.

A GP in the Netherlands who writes once in a while to a mailinglist, which is
(not surprisingly) called "Openkaart" (meaning: Open Information Exchange),
which of course it is not, he wrote: "ICT is an Image of reality, this makes
painfully clear a lot about the Dutch healthcare"

[system]

> There are no fixed patterns for names or naming conventions.
> There are many societies where there are no 'Family' names at
> all. Some have Tribe names in lieu, some with father's or
> village name as 'names' somewhere wedged in the name string.
> Some with just unique names with nothing else. To add to this
> confusion you would then have to find sub-components for nick
> names and aliases.

Yes, the whole gamut

In GnuMed we deal with it like this:

Where do you put initials and how do you qualify them as such so they can be
recognized in an automated process.

regards
Bert Verhees

[Karsten_Hilbert]

We don't have dedicated initials support. Most of the time (I
know no other use) initials are the first character of the
first name(s). So we either store them as first names (if we
don't know the first name but know the initial) or we do not
store them.

I do not completely understand why you need to be able to
*process* initials ?

Karsten

[system]

> > > There are no fixed patterns for names or naming conventions.
> > > There are many societies where there are no 'Family' names at
> > > all. Some have Tribe names in lieu, some with father's or
> > > village name as 'names' somewhere wedged in the name string.
> > > Some with just unique names with nothing else. To add to this
> > > confusion you would then have to find sub-components for nick
> > > names and aliases.
> >
> > Yes, the whole gamut
> >
> > In GnuMed we deal with it like this:
>
> Where do you put initials and how do you qualify them as such so they can
> be recognized in an automated process.

We don't have dedicated initials support. Most of the time (I
know no other use) initials are the first character of the
first name(s). So we either store them as first names (if we
don't know the first name but know the initial) or we do not
store them.

I do not completely understand why you need to be able to
*process* initials ?

I am extracting data from existing systems, and put them in a CEN-structure
(this is simplified saying of what I am really doing).
I do not want to loose vital information in this process
There is one system that stores person-data as
- Roepnaam (dutch for "call name")
- Initials

It is necessary that to distinguish as much as possible one person from
another, both are known in the extracted data. The extracted data can be used
for automated processing, so an automated process needs a qualifier to
distinguish as callname from initials.

That's why

[Karsten_Hilbert]

I am extracting data from existing systems, and put them in a CEN-structure
(this is simplified saying of what I am really doing).
I do not want to loose vital information in this process
There is one system that stores person-data as
- Roepnaam (dutch for "call name")

Pretty close to German: Rufname

- Initials

It is necessary that to distinguish as much as possible one person from
another, both are known in the extracted data. The extracted data can be used
for automated processing, so an automated process needs a qualifier to
distinguish as callname from initials.

Aha. You don't want to loose information you already have.

In GnuMed there are several ways to solve this:

a) add initials to firstnames
   - this loses some information but does not make it wrong

b) put initials into firstnames
   - set the name comment to "initials only"
   - if the source system does not have firstnames
   - loses no information
   - could be processed but is not clean

c) extend the lacking specs
   - in our case extend the GnuMed schema
   - in your case add a name part initials and use that

Can you precisely say what your initials stand for ? Here in
Germany they are *always* the first letter of the first
name(s). In other countries, too (US, AU AFAICT). In a name,
that is. A sig may consist of initials only - first/last names
both included - such as on charts etc.

Karsten

[Karsten_Hilbert]

I forgot to mention one solution we could use in GnuMed:

Attach another name to a person (they can have any number of
names), put the initials in one of the fields and mark that
name (eg set the comment) to be only initials.

Not clean but doable.

Karsten

[system]

> I am extracting data from existing systems, and put them in a
> CEN-structure (this is simplified saying of what I am really doing).
> I do not want to loose vital information in this process
> There is one system that stores person-data as
> - Roepnaam (dutch for "call name")

Pretty close to German: Rufname

> - Initials
>
> It is necessary that to distinguish as much as possible one person from
> another, both are known in the extracted data. The extracted data can be
> used for automated processing, so an automated process needs a qualifier
> to distinguish as callname from initials.

Aha. You don't want to loose information you already have.

In GnuMed there are several ways to solve this:

a) add initials to firstnames
   - this loses some information but does not make it wrong

This can not be processed automatically

b) put initials into firstnames
   - set the name comment to "initials only"
   - if the source system does not have firstnames
   - loses no information
   - could be processed but is not clean

This makes it impossible for an automated process to know with what it is
dealing

c) extend the lacking specs
   - in our case extend the GnuMed schema
   - in your case add a name part initials and use that

Yeah, that is a possibility, but then I am alone, no standard supports this.
But that is what I am going to do, I guess

Can you precisely say what your initials stand for ? Here in
Germany they are *always* the first letter of the first
name(s). In other countries, too (US, AU AFAICT). In a name,
that is. A sig may consist of initials only - first/last names
both included - such as on charts etc.

Karsten

In that system, initals stands for the first characters of the christiannames,
but that said, it depends on what the GP has used the field for.
But that was what the interface asked him/her to do

[system]

I forgot to mention one solution we could use in GnuMed:

Attach another name to a person (they can have any number of
names), put the initials in one of the fields and mark that
name (eg set the comment) to be only initials.

This is done really smart in CEN, they have an EntityName, which consists of a
set of EntityNameParts, the number is unlimited, but the
qualifier-possibilities are limited. The only way is to add a qualifier, that
is extending the standard