The HL7 version 3 data type task group has had its nineteenth conference call on Monday, March 1, 1999, 2:00 PM EST to 4:00 PM EST.
Attendees were:
Agenda items were:
There is a PAFM working group on person names that continues
discussing Person Name in the scope of HL7 version 2.x context. This
group will have a first conference call at Thursday March 11, 16:00
U.S. East Coast Time. Klaus Veil will be chairing those calls an he
welcomes people to join. The dial in number is the same. Contact Klaus Veil
KVeil@compuserve.com.
The proposal of the new person name type is layed out in the notes of the last call. Today we wanted to get more clarity on the various name types and classifications, etc. The outstanding issues of last call were:
name type, such as: legal, alias, tribal, maiden?
name context such as tribal "Bill Smith (known by hospital A) and "Willy Hammer (known by hospital B)"
degrees of formality: sloppy (Kiki), familiar (Kathy), nick (Kathrin), of record (Katharina) highly official (Ekatharina).
record, alias, pseudonym
name role vs. name type: type is what it is inherently, role is what it is used for (purpose).
The XPN data type of HL7 version 2.3.x may serve as a starter to see what other name types may be needed. Of course, there is also the issue of compatibility between version 2 and version 3 of HL7.
Irma read the following list for us:
| code | meaning |
|---|---|
| A | alias |
| L | legal |
| D | display |
| M | maiden name |
| C | adopted (name acquired through the person being adopted) |
| B | name at birth |
| P | name of spouse (name taken from) |
| U | unsepcified |
One problem that we have mapping those name type is that our new person name type id structurally different from the old one. It is not possible therefore to simply reuse those codes without further thoughts.
The first issue is that the old person name had a bunch of fixed slots and a name type code affecting the interpretation of data found in all slots. Our new type has name parts wich are individually classified and it has a purpose code for name variants which affect all name parts of the name variant. The semantics of the name parts, i.e. what those parts are, is described entirely in the name part classifiers. Each name variant has a certain use case, purpose or context.
Let's go once again through the table of v2.3.x name type codes trying to determine whether those codes stand for an inherent meaning of a name (part) or its purpose. I'll also make other annotations that might be helpful in sorting things out.
| code | meaning | comments | |
|---|---|---|---|
| A | alias | purpose, a person uses different aliases or pseudonymes in different contexts (i.e. when refering to himself as an author of a book, an actor, your friend, a customer in a bank, or a patient in a hospital. | |
| L | legal | purpose, this is the name of public record (if any) Such records do not exist in all countries. In Germany legal names definitely exist, I am not so sure about the U.S. | |
| D | display | purpose: for the purpose of "displaying"; however, this is quite vague. See below. | |
| M | maiden name | inherent meaning, but there are also quite pragmatic implications. See below. | |
| C | adopted | inherent meaning | |
| B | name at birth | inherent meaning | |
| P | name of spouse (name taken from) | inherent meaning | |
| U | unsepcified | ?? (obsolete) |
We habve not talked a lot about the alias, but one main part of our new approach includes to allow different "alias" names. So, every name variant baiscally is an alias for a person. Thus there is no need to further qualify that. May be "pseudonyme" is a somewhat stronger term that could be used as a classifier for name parts to show that those are not "real" names, but names that were somehow assumed off record.
In opposition to alias and pseudonymes, in some countries there are legal acts of name changes. In Australia, for instance, this is called "deed poll".
In Germany such name changes happen under exceptional conditions only and are always subject to official recording. The naming system in Germany is quite tightly regulated and you are not supposed to use any other name, except in certain situations where one would expect pseudonymes (e.g., book authors, actors, etc.)
In the U.S. name changes seem to be more frequent as in Germany and the naming system is less regulated as in Germany. One issue that one would need to clarify is the meaning of "legal" name. Legal name, obviously, has different meanings in different countries, depending on how the naming system is regulated.
The concept of display name was vague all along. The question is what display? The whole idea of names is that they are "displayed" on paper, computer screens and in spoken language. The use case of display names thus is not clear. Basically there is no longer a need to have a name type "display name" in our new person name type. This is so, because we no longer distort the natural (or purposeful) ordering of the name parts by requiring name parts to be put in different slots. Name parts occur in some order that is defined or selected by someone, either the holder of that name or the computer system, or the citation style guide, etc.
We will come to the "context" and name "purpose" that define different display styles below. Also, we'll have to talk about this more next time.
Joann Larson noted that some names are used in Licenses or other accreditations and it is quite important to record the name as such. Examples are: school records, graduation certificates, license to practice a profession, etc. Notably, women who had a Doctoral degree were the first ones who assumed double names in Germany many decades ago. The reason was that their dissertations and certifications were issued for their maiden names. Then when those women married they would have lost their certifications by switching their family names entirely.
The question here is whether keeping a name history is enough or whether we have to actually associate name variants with particular licenses or other certifications.
This was a very difficult discussion, where a lot of arguments were exchanged but where people also said they could not even see the issue being so lively discussed.
Let's put this into historical perspective.
In versions 2.1 and 2.2 of HL7 there was no name type code at all, and the only place a "maiden" name was even mentioned was "PID-mother's maiden name". There was obviously no place to specify the patient's maiden name. This seemed to be somehow less of a problem in the U.S., but it was definitely a problem in Germany, which is why HL7 Germany redefined mother's maiden name to patient's maiden name.
Then came the name type code, and with it came the maiden name type code. The meaning of which was clear at that time, since there was just the maiden name and adopted name. It probably was not quite clear what would happen with a female that was adopted at 5 years, had a family name before and switched the family name through adoption and later married and switched the name again. We had a way to express the name she had after adoption, we were able to specify the name befor marriage, which in this case are the same! Two ways to specify the same name, but on the other hand, there was no way to specify neither the name before adoption, nor the name after marriage. Which is pretty odd, but, again, didn't seem to matter very much.
The famous Dutch name change initiative that started with a Sermon by John Baptist in summer 1997's meeting in San Francisco (or was it Tampa?), was the major driving force for bringing in "birth" name and "spouse" name types. As far as I know, the rationale was not to address the oddities mentioned in the last paragraph. Rather, the issue was that "maiden" seemed to imply "female before marriage" or even stronger cultural connotations. Since the people of the Netherlands have long had a very reasonable and free culture, the Dutch did away with those sexist traditions long before the rest of the world even realized the issue.
So the driving force behind "birth" name was to open up the narrow sense of "maiden". In that sense, "birth" was clearly meant to subsume "maiden".
The "spouse" name type on the other hand was meant as kind of the antonyme of "birth". The last conference notes have a pretty extensive description of the dutch naming system which essentially explain why "birth" and "spouse" name types are so important in the Netherlands. It is all because a married (or otherwise officially associated) couple of persons (not necessarily of opposite gender), will sort of combine their family names while both names remain as independently useful family names. That's why birth name would be the "birth" name and "spouse" the name of the spouse.
From that perspective it seemed like "maiden" was subsumed by "birth", as a way to express the same concept with less sexist connotations.
But this was everything else than agreed to by everyone on the call.
It turned out that the dutch reform has created more different notions than was originally expected. For example, again, what happens if someone changes his/her name before marriage? And we went deeply into arguments. We don't have results from those arguments, and we even have doubts what the issue is. Of course, Klaus, for example, maintains that "maiden" and "birth" should not be merged, so there seemed to be no issue in the perspective of the v2.3 XPN data type.
However, there is an issue with the new data type, since the list of name part classifiers does not yet contain a classifier for "maiden". So, the question is whether or not we introduce one. We certainly need to be sure we understand and can explain crisply what those classifiers are used for, since a common standard is the basis of all interoperability. It may turn out, as Dawid said, that different cultures must retain their classifiers independently, and thus, that we were unable to do some inter-cultural name mappings. But let's first try before we resign.
So we tried to define. We made the observation that the above mentioned name types have different "directions" of meaning in time. They do not so much express what any name part is semantically, since family names are family names, but they try to capture how names come about. Dawid added, that those name types not only capture how names came about, but also, how names ceased to be used.
In the "anciant" U.S. name system of the 1950s and the German name system that losened up only recently the issues were simple. For instance, my wife's name is "Dorothea Schadow" but her maiden name is "Riemer".
Riemer <---MAIDEN|
-----------------------+------------------------------> lifetime
|CURRENT---> Schadow
If we mention the maiden name of my wife, we indicate that this maiden
name, "Riemer", was used for her before she assumed my family name,
"Schadow", through marriage. So her current name is "Schadow" and will
remain "Schadow" for the unforseeable future. Her family name
was "Riemer" but no longer so. Now, it is just her maiden
name. This is just what Dawid said: "maiden" applied to my wife does
not explain how her name "Riemer" came about, but it tells how the
name part "Riemer" ceased to be used.
From the perspective of this very traditional naming scheme "maiden" and "current" is all you need to distinguish. And indeed most existing information systems are build based on this traditional misconception that this is how the world works. It is not. Anyway, since "maiden" is a term routed in the traditional patriarchal system, we can define "maiden" name as:
A "maiden name" is the surname of a woman before she marries.at lest, this is what Webster's has to say about "maiden name". Clearly, this notion appears archaic today. But still ADT system's data bases, data entry forms and even application logic sometimes is built on this misconception.
Again, the Dutch people are the avant-garde of a more reasonable approach to looking at things. In the dutch naming system the "directions" are different, as Irma's example showed that "maiden" is not an issue here:
|BIRTH---> de Haas
-----------------------+------------------------------> lifetime
|SPOUSE---> Jongeneel
In the Dutch system, all name parts point forward. The name types
explain how name parts came about, not how they ceased to be used.
From that perspective, "maiden" and "birth" do have different meanings. In the Dutch system the entire concept of "maiden name" simply does no longer exist. In Germany and the U.S. it still exists.
I would agree on the difference between birth and maiden, if we could agree that maiden marks a name that ceased to be used. But that seemed to be exactly the point of our disagreement. At the most I would open up the concept of "maiden name" to be less sexist so that I would like to see the definition to read as follows:
A maiden name is a name part that a person had immediately before this person's first marriage and that was given up due to that marriage.By "marriage" I understand any kind of "culturally accepted personal association between human beings." This is open enough to include the wildest things as long as they are accepted in that culture (not necessarily accepted in other cultures). This includes homosexual marriages, religous (non-civil) marriages civil (non-religious) mariages; simply anything that causes someone to give up some of his/her name parts.
This is not just semantic talk. Practical connotations to a name part classified as "maiden" would be "don't use it", except in special circumstances or with special prefixes.
What happens if someone get's married and does not change her/his name?
From my perspective this is simple: "maiden name" simply does not apply.
However one can argue the other way: since "maiden" means young unmarried girl, you do have a maiden name even though you might have never gave up your name. Notably every maiden would have just a maiden name. Every unmarried person would have only a maiden name. Here it all depends on whether we think of names as slotted parts or as tagged parts. If name parts are slotted in data fields, the maiden name of a maiden is duplicated:
Pippi LangstrumpfIn our new system, however, we tag names without duplications:(SlottedName :given-name "Pippi" :current-name "Langstrumpf" :maiden-name "Langstrumpf")
Pippi Langstrumpf
(PersonNameVariant
(PersonNamePart :value "Pippi"
:classifiers (SET given))
(PersonNamePart :value "Langstrumpf"
:classifiers (SET family maiden (current))))
What it all boils down to is the following problems:
Klaus and others maintained the following rationale: birth name is the name you have at birth. Maiden name is the name you have just before your first marriage. Adoption name you have since your having been adopted (note the ambivalence with "adopted name").
The immediate question becomes: what happens when you marry a second time? What if you are adopted after you first married (this can be done in some countries)? For me the question is, how many reasons of name changes do we have to capture? When is it enough to just keep a history of names?
The answer is proably: "it depends". In Some cultures becoming a widow is a reason for a name change. In others you might change names as you give birth to children. You might also change names as you enter a religious community (e.g., as you become a monk, or a pope :-) Do we want to keep track of all this? Probably, it all depends.
Larry Reis reminded us to stick to practical use cases. This is of course an important perspective. Howeve, if we design the name data type according to a majority of existing information systems, we would still get stuck with the "first-mi-last" name pattern.
A lot of the argument about maiden name was due to existing systems that either require a certain input or give a certain output. What should we do?
Here is my proposal, and you may or may not agree. We only use the Dutch system, where we have a
Mapping from slotted name to new name style is also simple: "maiden name" is translated to "birth", and current name to "spouse" if different from maiden name. If maiden name is not filled out, then the current name gets the "birth" flag.
Of course this mapping is not isomorphic. But I just don't see the point why our new improved system should care for transmitting all the inappropriate misconceptions that are artificially held up by badly designed forms and data bases? Especially since this is no critical clinical data. There is no business for "faithfulness" (Rector, Nolan et. al) or exactness of this data. Why bother?
Why bother! You can say this to me and convince me to get in the maiden name as an additional name part classifier on Axis 2. Consequently we would also have relax the notion that axis 2 classifiers need to be mutual exclusive. O.K., you have got me, I don't want to waste any more time on this "maiden" name. Here you go:
| SYMBOL | SHORT | DESCRIPTION |
|---|---|---|
| Axis 1 This is the main classifier. Only one value is allowed. | ||
| given | G | Given name (don't call it "first name" since this given names do not always come first) |
| family | F | Family name, this is the name that links to the genealogy. In some cultures (e.g. Eritrea) the family name of a son is the first name of his father. |
| prefix | P | A prefix has a strong association to the immediately following name part. A prefix has no implicit trailing white space (it has implicit leading white space though). Note that prefixes can be inverted. |
| suffix | S | A suffix has a strong association to the immediately preceeding name part. A prefix has no implicit leading white space (it has implicit trailing white space though). Suffices can not be inverted. |
| delimiter | D | A delimiter has no meaning other than being literally printed in this name representation. A delimiter has no implicit leading and trailing white space. |
| Axis 2 Name change classifiers decribe how a name part came about. More than one value allowed. | ||
| birth | B | A name that a person had shortly after being born. Usually for familiy names but may be used to mark given names at birth that may have changed later. |
| maiden | M | A name that a person (either sex) had immediately before her/his first marriage. This concept of maiden name is only for compatibility with cultures that keep up this traditional concept. In most cases maiden name is equal to birth name. If there are adoption or deed polls before first marriage the use remains often ambiguous in practice. |
| chosen | H | A name that a
person assumed because of free choice. Most systems may not track
this, but some might. Subsumed in the concept of "chosen" are
pseudonyme (alias), and deed poll. The difference in civil
dignity of the name part is given through the R
classifier below. I.e. a deed poll creates a chosen name of record,
whereas a pseudonym creates a name not noted in civil records.
|
| adoption | C | A name that a person took on because of being adopted. Adoptions may happen for adults too and may happen after marriage. The effect on the "maiden" name is not fully defined and may, as always, simple depend on the discretion of the person or a data entry clerk. |
| spouse | P | The name assumed from the partner in a marital relationship. Usually the spouse's familiy name. Note that no inference about gender can be made from the existence of spouse names. |
| Axis 3 Additional classifiers. More than one value allowed. | ||
| nick | N | Indicates that the name part is a nickname. Not explicitly used for prefixes and suffixes, since those inherit this flag from their associated significant name parts. Note that most nicknames are given names although it is not required. |
| callme | C | A callme name is (usually a given name) that is preferred when a person is directly addressed. |
| record | R | This flag indicates that the name part is known in some official record. Usually the antonyme of nickname. |
| initial | I | Indicates that a name part is just an initial. Initials do not imply a trailing period since this would not work with non-Latin scripts. Initials may consist of more than one letter, e.g., "Ph." could stand for "Philippe" or "Th." for "Thomas". |
| invisible | 0 (zero) | Indicates that a name part is not normally shown. For instance, traditional maiden names are not normally shown. Middle names may be invisible too. |
| weak | W | Used only for prefixes and suffixes (affixes). A weak affix has a weaker association to its main name part than a genuine (strong) affix. Weak prefixes are not normally inverted. When a weak affix and a strong affix occur together, the strong affix is closer to the its associated main name part than the weak affix. |
This table is not yet complete. We need to find markers for noblety titles and academic and other professional titles. Please make suggestions.
We recognized the the term "initials" may have slightly different meanings in an international context. In the Netherlands "initials" are all the first letters of your given names and family names as you choose.
In Holland there is also the concept of "voorletters" which are the first letters of the given names. In Holland adults are normally recorded only using their voorletters and family names. This is similar to the vancouver citation style that never spells out first names.
However, we confirmed that the term "inital" means first letter (of whatever), regardless of given or family name. The beautiful initials that start a chapter of medieval books are called "initals" too (e.g., the Schwabacher initals). When "initals" is used in the plural form in context of names and signatures, it usually refers to all the initials of given and family names. It is then used as a short form of a signature.
Irma confirmed that a typical name using only voorletters would be recorded as a person name variant. We would not need to associate initals with spelled-out name parts.
If it turns out that we have to strongly define name contexts we will have to do so in a similar fashion as we did for the Stakeholder Identifier. This has heavy methodological ramifications. We'll have to flesh these out on the next call.
The problem is that the use cases that Dawid contributed (person named X at hospital A and Y at hospital B) seem to be properly supported only through an association from name variant to an Organization class in the RIM.
However, Joanne Larson's examples did not bind a name to an organization but rather to a License! The typical Doctoral thesis name does not have any organization to associate with. And a "doctoral thesis" is not a RIM class. So how can we ever strongly associate with such things?
After all, what are the "purpose codes" for name variants. Please contemplate this issue, since I still don't have any clue. Our name type codes were either related to name parts "A, L, M, C, B, P" or they were useless "D - display".
We need use cases for the Australian "tribal" names that have been mentioned. Please give some real examples which look credibly and can published ("Bill Smith" doesn't sound like a tribal name to me.)
How do we deal with contexts (see above)?
Degrees of formality are not relevant in Holland, but might well be in Asia? E.g., sloppy (Kiki), familiar (Kathy), nick (Kathrin), of record (Katharina) highly official (Ekatharina). We need input from Japan on that.
The name part classifier table is not yet complete. We need to find markers for noblety titles and academic and other professional titles. Please make suggestions.
Next conference call is next Monday, March 8, 1999, 2:00 PM EST.
Note the unusual time. This is because we will have Irma, Klaus and Dawid with us again.
Agenda items are:
We need to get closure on those three items now so that we can move on. Please, please, read and think about the notes of the last three conference calls to make sure you fully understand and can "sbuscribe" to what is proposed. We need a concentrated and informed discussion or we can not finish.
Unfortunately we haven't even touched the organization name yet. However, I presume that this is simple. We just do the same as in person name just with other tags. There are much less tags.
We have never accomplished four agenda items in one call, so it seems likely we have to split into two. However, please, please get yourself a strong and informed oppinion so we can move on quickly.
regards
-Gunther Schadow